Emmanuel Jourdan

For the second object on Edge, let's present 

 intends to facilitate the utilization of multiple 

, for creating samplers for instance. When double clicking on the object, you can access to a window that displays information about the buffers (double clicking on the buffer name will display the waveform). We are looking forward to hearing comments/suggestions/bug reports.

https://cycling74.com/download/polybuffer_42478.zip

https://cycling74.com/download/polybuffer_42478W.zip

- move polybuffer.mx(o|e) to C74:/extensions

- move polybuffer~.mx(o|e) to C74:/msp-externals

- move polybuffer~.maxhelp to C74:/msp-help

Please report any problems you experience with clear and complete

information, including steps to reproduce, software and system

information, and where possible, an isolated example patch and crash

log. Something like the following would be ideal. This makes it

easier for us to find and fix the problems you experience. Without

such clear and complete information, it is less likely we will be

Provide a descriptive summary of the issue.

In numbered format, detail the exact steps taken to produce the bug.

Describe what you expected to happen when you executed the steps above.

Please explain what actually occurred when steps above are executed.

Describe circumstances where the problem occurs or does not occur,

such as software versions and/or hardware configurations.

Provide additional information, such as references to related

problems, workarounds and relevant attachments.

Note that Max 5.1.4 or higher is required.

For the second object on Edge, let's present polybuffer~. Polybuffer~ intends to facilitate the utilization of multiple buffer~, for creating samplers for instance. When double clicking on the object, you can access to a window that displays information about the buffers (double clicking on the buffer name will display the waveform). We are looking forward to hearing comments/suggestions/bug reports.

Macintosh:
https://cycling74.com/download/polybuffer_42478.zip

Windows:
https://cycling74.com/download/polybuffer_42478W.zip

Installation:
- move polybuffer.mx(o|e) to C74:/extensions
- move polybuffer~.mx(o|e) to C74:/msp-externals
- move polybuffer~.maxhelp to C74:/msp-help

Please report any problems you experience with clear and complete
information, including steps to reproduce, software and system
information, and where possible, an isolated example patch and crash
log. Something like the following would be ideal. This makes it
easier for us to find and fix the problems you experience. Without
such clear and complete information, it is less likely we will be
able to.

Summary:
Provide a descriptive summary of the issue.

Steps to Reproduce:
In numbered format, detail the exact steps taken to produce the bug.

Expected Results:
Describe what you expected to happen when you executed the steps above.

Actual Results:
Please explain what actually occurred when steps above are executed.

Regression:
Describe circumstances where the problem occurs or does not occur,
such as software versions and/or hardware configurations.

Notes:
Provide additional information, such as references to related
problems, workarounds and relevant attachments.

Note that Max 5.1.4 or higher is required.


polybuffer-public-beta

i love it! awesome e--j ! thankyou thankyou!

great object. in my opinion, one feature is missing (or i missed it) : being able to destroy one buffer into the polybuffer~ without destroying or renaming the others.

it could allow to 'filewatch' a directory, automatically remove/add buffers accordingly to the directory content without reloading everything...

where is the "save in patcher" option ?.....................

wonderfull !
where is the "save in patcher" option ?.....................
:-)


The day I start a building sampler ! thanks a lot !

+1 on the ability to save in some simple way (without the use of a coll)

The day I start a building sampler ! thanks a lot !
The getsize function is nice.

+1 on the ability to save in some simple way (without the use of a coll)
+1 on the folderwatch feature too

@Leo & Guillaume: while it might be cool to automatically reload, the way it currently works is that it loads an entire folder (or append file by file), so what would you expect if you insert a new sound file in the folder and that it would change the alphabetical order? would this mean that the buffer called yoyo.3 doesn't bind to the same sound file as before?

@thomas: indeed an embed attribute would be cool

@Leo & Guillaume: while it might be cool to automatically reload, the way it currently works is that it loads an entire folder (or append file by file), so what would you expect if you insert a new sound file in the folder and that it would change the alphabetical order? would this mean that the buffer called yoyo.3 doesn't bind to the same sound file as before?


emmanuel, i wasn't thinking of implementing the filwatch directly into the object. just thinking of a clear message that could destroy one buffer (with no rename for the others).

by the way, why don't you just use the filename for the buffer name instead of yoyo.x ?

emmanuel, i wasn't thinking of implementing the filwatch directly into the object. just thinking of a clear  message that could destroy one buffer (with no rename for the others).

by the way, why don't you just use the filename for the buffer name instead of yoyo.x ?


I think there's a misunderstanding between saving the buffer list and embedding polybuffer's gui in the patcher.

Regarding saving, I suppose it could work like the coll in your helpfile, the polybuffer remembers the buffer name and it's (absolute or relative- optionnal ?) filename and load them back when opening the patch.

I guess this list could be saved somewhere in the json structure or in a separate file on demand (read/write).

As always, there's a lot of ways of doing this. The better might be to let the user program it ;).

But it's always difficult when working on big projects to have one or several xml/json pattrstorage files + severals colls + some jxf + ... beside the patch itself.

Regarding the names of buffers, I prefer having yoyo.x, it's easier to process and pretty easy to get the filename with info~.

Anyway, I've played with it all day long, it works like a charm.

I think there's a misunderstanding between saving the buffer list and embedding polybuffer's gui in the patcher.
Both features would be cool.

Regarding saving, I suppose it could work like the coll in your helpfile, the polybuffer remembers the buffer name and it's (absolute or relative- optionnal ?) filename and load them back when opening the patch.
I guess this list could be saved somewhere in the json structure or in a separate file on demand (read/write).

As always, there's a lot of ways of doing this. The better might be to let the user program it ;).
But it's always difficult when working on big projects to have one or several xml/json pattrstorage files + severals colls + some jxf + ... beside the patch itself.

Anyway, I've played with it all day long, it works like a charm.
Thanks again.

There's two good reason for using names like yoyo.x: it's easier to iterate through it (if you want to do a bunch of info~ e.g.), there's a fix name which allow things like 

 which is really cool if you just want to have a bunch of places to record to.

 attribute on my todo list, on the same model as 

Adding specific message to get infos on every 

 is straightforward, so if you have specific utilization in mind that you think might be beneficial for other. It might be interesting to output the loop points for instance or something like that, so if you have a strong opinion or an example don't hesitate to suggest.

There's two good reason for using names like yoyo.x: it's easier to iterate through it (if you want to do a bunch of info~ e.g.), there's a fix name which allow things like appendempty which is really cool if you just want to have a bunch of places to record to.

I added the embed attribute on my todo list, on the same model as table/coll…

Adding specific message to get infos on every buffer~ is straightforward, so if you have specific utilization in mind that you think might be beneficial for other. It might be interesting to output the loop points for instance or something like that, so if you have a strong opinion or an example don't hesitate to suggest.


- when you drop an mp3, the message in Max' window is "couldn't find ", which is a strange message.

- when you drop a folder containing only mp3, nothing happens and no message is displayed in Max' window.

- when you drop an aiff with more than 4 channels, an "empty" buffer entry is created although, as stated in Max' window, more than 4 channels are not supported. In that case the number of channels and SR displayed in polybuffer~'s window are not consistent (see attached file).

- when you drop an mp3, the message in Max' window  is "couldn't find ", which is a strange message.
- when you drop a folder containing only mp3, nothing happens and no message is displayed in Max' window.
- when you drop an aiff with more than 4 channels, an "empty" buffer entry is created although, as stated in Max' window, more than 4 channels are not supported. In that case the number of channels and SR displayed in polybuffer~'s window are not consistent (see attached file).

I've been working on a similar project, and I needed to dynamically create mixer/effects channels for each new sample coming in through a filewatch, and keep track of buffers that had been cleared. The way I did it was to use a simple array of flags inside the object that kept track of which buffers were un/available. Since my custom object is doing the buffer-clearing in the first place, it knows the state of each one. So every time a new sample comes in through my filewatch, my object iterates through the array of flags until it finds an available buffer. This lets you set the total number of buffers through an argument (much like poly~), but lets you recycle old buffers as you clear them and re-use them for new, incoming samples.

Here's a snapshot of my method that fires when a new sample comes in. It finds an available buffer inside an associated poly~ (which is housing my "fileloader" patches, which are basically buffer~/groove~ pairs), and targets the correct voice to send in either a clear command or a filepath to put new data in a buffer.

@Patrick: thanks for pointing this out. This exposes some tricky problems of error handling ;-)

I have a bug report that is just too simple to be reported in the straight-forward way:

if in the patch there is a "send" or "receive" object that has the same name of the polybuffer~, it crashes when you load the sounds.

Bonjour Emmanuel,
thank you for developing this object!

I have a bug report that is just too simple to be reported in the straight-forward way:
if in the patch there is a "send" or "receive" object that has the same name of the polybuffer~, it crashes when you load the sounds.

A new version is available bellow. It includes bug corrections and new features you suggested:

- embed attribute allows you to store references to the buffer~ with the patcher

- tinge polybuffer~ when an error is sent from attached buffer

- import mp3 and weird sound files (requires quicktime)

- comments in the poylybuffer window have a fixed size

- abort loading when the symbol is already used for something else than a buffer~ (so it doesn't crash…)

https://cycling74.com/download/polybuffer_42734.zip

https://cycling74.com/download/polybuffer_42734W.zip

Installation and bug reporting guidelines unchanged.

A new version is available bellow. It includes bug corrections and new features you suggested:
- embed attribute allows you to store references to the buffer~ with the patcher
- tinge polybuffer~ when an error is sent from attached buffer
- import mp3 and weird sound files (requires quicktime)
- comments in the poylybuffer window have a fixed size
- abort loading when the symbol is already used for something else than a buffer~ (so it doesn't crash…)

Macintosh:
https://cycling74.com/download/polybuffer_42734.zip

Windows:
https://cycling74.com/download/polybuffer_42734W.zip

Thanks for the examples and the description, this has been fixed for the next beta.

Is there a way to keep the files sorted by names with @embed 1 ?

I have nine soundfiles loaded. The names start as 1.aif to 9.aif

When I drop the folder, 1.aif is loaded in yoyo.1, 2.aif in yoyo.2 etc.

If I save and close the patch then relaunch it the files are randomized(?).

Now If I close the patch without saving anything and relaunch I get exactly the same random(?) sorting.

Hi,
Is there a way to keep the files sorted by names with @embed 1 ?

I have nine soundfiles loaded. The names start as 1.aif to 9.aif
When I drop the folder, 1.aif is loaded in yoyo.1, 2.aif in yoyo.2 etc.
good.

If I save and close the patch then relaunch it the files are randomized(?).
Now If I close the patch without saving anything and relaunch I get exactly the same random(?) sorting.

That's odd it works here. Could you upload the some files somewhere? Thanks.

Here there are:
http://derrickgiscloux.free.fr/polybuff/


great I can reproduce (it just needed a few more samples ;-) It'll be fixed for the next beta.

i just wonder if it's possible to do something like " record~ yoyo.1 "

and then " writewav "...to save the content of a particular buffer.

nice work emmanuel!
many thanks for your effort.
i just wonder if it's possible to do something like " record~ yoyo.1 "
and then " writewav "...to save the content of a particular buffer.
and maybe a " writeall " too?

You can definitely use something like "record~ yoyo.1". You can also send messages to specific buffer~ instance using the send message. If you do 

 for instance you'll have a dialog box for saving every buffer, which might not be really user friendly but... Maybe a 

You can definitely use something like "record~ yoyo.1". You can also send messages to specific buffer~ instance using the send message. If you do send 0 write for instance you'll have a dialog box for saving every buffer, which might not be really user friendly but... Maybe a writetofolder message would be cool.


cool!
thanks emmanuel for the reply.
"writetofolder" is a +1000!!


For some reason it doesn't work in M4L for me. It says it needs max 5.14 or higher. I have 5.14 installed on my machine.

I also updated M4L to the latest version.

Intell macbook pro with snow leopard btw.

For some reason it doesn't work in M4L for me. It says it needs max 5.14 or higher. I have 5.14 installed on my machine.
I also updated M4L to the latest version. 

Intell macbook pro with snow leopard btw. 

This might be already fixed for the next incremental, I can't reproduce the issue.

Hi...I´ve been programming this interface that consist basically in a loop player that reads files randomly stored in multiple buffers (with the polybuffer object) and then these files are routed via series of gates in order to being processed with a "scrubf" abstraction (from percolate library) and a granular and gabor psola from FTM, and finally a reverb also from percolate. The gates are designed in a very simple way in order to have the files routed to one or two of this efects, and also in dry mode. Then, this "module" is duplicated 8 times so you have more diversity to load up differents folders and so on....

So what´s the issue??...well, when i turn the Dsp on, the patch uses around 44% of my cpu being idle (i´m running a Macbook with a 2.4 ghz core2duo with 2 gb ram, and a 003 rack digidesign firewire audio interface) and Max-Msp begins to incrementally hogging ram memory (up to 1.5 gb ram). I don´t know what could it be. Could if be the polybuffer object, or just my programming errors?

Thanks a lot, and i would appreciate your feedback

Thanks a lot, and i would appreciate your feedback
Dario


 doesn't really take CPU, it mainly does nothing in term of processing. It requires RAM however (which is displayed in the right left corner of the 

's window). I would recommend you strip down the patcher, but it's highly unlikely that 

 is the culprit here (the number of sound files, therefore the RAM amount required might be the problem, or not).

polybuffer~ doesn't really take CPU, it mainly does nothing in term of processing. It requires RAM however (which is displayed in the right left corner of the polybuffer~'s window). I would recommend you strip down the patcher, but it's highly unlikely that polybuffer~ is the culprit here (the number of sound files, therefore the RAM amount required might be the problem, or not).


The way I did it was to use a simple array of flags inside the object that kept track of which buffers were un/available. Since my custom object is doing the buffer-clearing in the first place, it knows the state of each one.

The way I did it was to use a simple array of flags inside the object that kept track of which buffers were un/available. Since my custom object is doing the buffer-clearing in the first place, it knows the state of each one.
http://www.creativenexusonline.com


Would it be possible for the numbers in the separate buffer-names to be in front of the name instead of at the end? Like: "1.yoyo" instead of "yoyo.1".

In that way you could refer to the separate buffers with the $1 method ($1.yoyo in a message) and the #1 method which would be a very big plus for me.

I'm using polybuffer (and the readfolder message) to change sample banks on the fly. I numbered my files in each folder so that when the folder is loaded, the files always inhabit the same buffer (e.g. 1music.aif, 2music.aif etc. so that 1music.aif loads in as hello.1 in polybuffer~ hello. My issue is that inexplicably, at times, the correspondances get completely randomized. this issue occurs when I send the readfolder message while the DAC is turned ON. When it's turned off and I send this message, everything corresponds neatly.

I know but [sprintf] allocates memory which is not freed until you close Max, I like to avoid using it ass much as possible.

I thought it should be a very simple change in the code of the object to put the numbers up front so you can use ($1.yoyo) inside a message.

sprintf doesn't really allocate memory for that, any symbol allocates memory for it's life in Max: so the $1.yoyo will also generate a symbol. One important details is that each symbol uses an unique space in memory, so if you take 1.yoyo for instance it only exists once in memory, so no matter how you create it, it will end up using the same memory space, unless you have a gigantic number of symbols you're really fine.

So if I understand you correctly constructing a symbol in a message liek ($1.yoyo) is the same as constructing it with a [sprintff] ?

yes in the sense that any "string" (aka a symbol in the Max terminology) is unique and stored in the memory.

Sure. You can send any message to one or every 

Sure. You can send any message to one or every buffer~ contained by polybuffer~, so for instance sending send 0 crop 200 500 will crop every buffer~ with only the 300 ms after 200 ms.


Someone was asking about the use of sprintf, here i attach a screenshot...

hi great object, is it possible to create a polyphonic sampler with this object? I have got it to make sound but each buffer loads over the other and won't allow multiple playback of files. Is there anyway to do this using play~?

You need a play~ for each voice. There isn't a polyplay~ yet!

Polyplay~ anyone? There's an opening in the market!

Hi - I'm wondering if there's a way to write/record into the polybuffer~ from within a patch? For ex. editing a buffer in waveform~ and then writing that edited version into polybuffer~.

I guess if I want to use polybuffer~ in that way I could manually write the edited waveform~ contents to disk and then load that back into polybuffer~, which just seems unnecessarily convoluted... My preference would be to edit waveform~ and clik on a button that transferred the editied contents immediately to polybuffer~, and then at that point I could decide if I wanted to write the polybuffer~ contents to disk.

Hi - I'm wondering if there's a way to write/record into the polybuffer~ from within a patch?  For ex. editing a buffer in waveform~ and then writing that edited version into polybuffer~.

I guess if I want to use polybuffer~ in that way I could manually write the edited waveform~ contents to disk and then load that back into polybuffer~, which just seems unnecessarily convoluted...   My preference would be to edit waveform~ and clik on a button that transferred the editied contents immediately to polybuffer~, and then at that point I could decide if I wanted to write the polybuffer~ contents to disk.  

is there any chance the mighty polybuffer~ will just be part of the standard distribution for max6? under max5, it has been solid for me, and others i assume, given the absence of bug reports here.

Hi - Answered my own question... I was able to edit a buffer~ and save to a polybuffer~ by writing the edited waveform~ contents into peek~ and then using a buf.Op and its 'copyInto' operation to get it into polybuffer~. Hope that makes sense.

What a great object - I was able to both solve a problem and add some functionality I'd been planning to eventually get to...

Hi - Answered my own question... I was able to edit a buffer~ and save to a polybuffer~ by writing the edited waveform~ contents into peek~ and then using a buf.Op and its 'copyInto' operation to get it into polybuffer~. Hope that makes sense. 

What a great object - I was able to both solve a problem and add some functionality I'd been planning to eventually get to... 

@driftpattern: there's a good chance that it will happen...

@davidsmith: right, the buffer~ created/held by polybuffer~ are just normal buffer that you can manibulate, access, mess with with any buffer~ compatible object, so feel free to have fun with mxj buf.Op and more ;-)

https://cycling74.com/forums/max-6-public-beta-is-here

If you have any reports or problems, we will be funneling them in with the rest of the Max 6 feature set so please use the form @ 

FYI, he Max 6 Public Beta ( https://cycling74.com/forums/max-6-public-beta-is-here ) now includes polybuffer~.

If you have any reports or problems, we will be funneling them in with the rest of the Max 6 feature set so please use the form @ https://cycling74.com/max6betabug_form/

I am using polybuffer~ from its JS interface. I load a collection of samples from a config file using the append method, and I noticed that the response is always the same. There is no distinction between successful loads and missing files. In my particular situation it would be very helpful if you can get an error code as a result from the append call.

Is this not possible currently or am I overlooking something?

I am using polybuffer~ from its JS interface. I load a collection of samples from a config file using the append method, and I noticed that the response is always the same. There is no distinction between successful loads and missing files. In my particular situation it would be very helpful if you can get an error code as a result from the append call. 

Is this not possible currently or am I overlooking something? 

Just realized there's a simple and effective way to know if the file exists before calling append. Something like:

    var f = new File(filepath, "read")

function isFile(filepath){
	var f = new File(filepath, "read")
	if(f){
		var result = f.isopen
		f.close()
		return result
	}

Feature request: concatenate multiple buffers into one, and dump out a list of start/end points.

Could be very useful for audio-rate sample switching; unless you need a release tail this could enable highly-optimised monophonic playback. Think: drums, one-shots, etc.

Great object here! Very useful in cleaning up patches.

I was wondering if I could request a feature.

A lot of my sample folders have .als files from using them in Ableton.

This means when loading in a folder I get lots of error messages in the Max window saying it couldn't read the .als files.

Maybe if the object could have a similar feature to umenu (File Types) where you can specify the file types polybuffer~ will notice and ignore all others.

Or if it simply just ignores all files other than what it can recognise.

Not really a problem with functionality it just would clean up the max window.

Great object here! Very useful in cleaning up patches.
I was wondering if I could request a feature.

Maybe if the object could have a similar feature to umenu (File Types) where you can specify the file types polybuffer~ will notice and ignore all others. 

This is a fine piece of software indeed, but it does not solve my problem.

My question is probably a request for the buffer object itself.

I am looking for a way to open directly in a buffer 8 track files; i.e. not converting them out of max/msp in mono tracks or two 4 track files which is actually a useless pain and make all patches a mess.

Do you see any solution or could you add this feature on the which list if it is not already there ?

Hello Emmanuel,
This is a fine piece of software indeed, but it does not solve my problem.
My question is probably a request for the buffer object itself.
I am looking for a way to open directly in a buffer 8 track files; i.e. not converting them out of max/msp in mono tracks or two 4 track files which is actually a useless pain and make all patches a mess.
Do you see any solution or could you add this feature on the which list if it is not already there ?
Thanks a lot
Best regards
Roland


We have a feature request like that logged. I don't see it happening in a near future, this requires a lot of rewrite in every objects to support that.

I'm having a problem with Polybuffer~ on Max 5. It isn't sending a bang out of the right outlet when a file/folder is loaded.

I've downloaded the latest version from this thread, trashed preferences, but no change.

polybuffer~ public beta