polybuffer~ public beta
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.
– move polybuffer.mx(o|e) to C74:/extensions
– move polybuffer~.mx(o|e) to C74:/msp-externals
– move polybuffer~.maxhelp to C74:/msp-help
Bug reporting guidelines:
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.
Steps to Reproduce:
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.
a useless post but:
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 ?…………………
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
@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
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.
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.
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.
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.
Thanks for this nice object!
Some remarks (Max5.1.4 under OS X.6.3):
– when you drop an mp3, the message in Max' window is "couldn't find
– 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 ;-)
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…)
Installation and bug reporting guidelines unchanged.
haven’t tested it yet, but great :)
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.
What am missing?
That’s odd it works here. Could you upload the some files somewhere? Thanks.
great I can reproduce (it just needed a few more samples ;-) It’ll be fixed for the next beta.
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 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.
thanks emmanuel for the reply.
"writetofolder" is a +1000!!
Thanks for this very usefull object.
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.
Do you know what’s going on?
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
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).
any new version?
Not yet ;-)
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.
you could use sprintf :
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.
Otherwise, it’s a fabulous object.
"you could use sprintf :
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.
Thanks for your reply.
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.
Hey edge people,
Can you ‘crop’ with polybuffer~ ?
If not that would be a nice feature
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.
Thanks a lot for polybuffer~
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!
polybuffer is a sexy mama
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…
FYI, he Max 6 Public Beta ( http://cycling74.com/forums/topic.php?id=35581 ) 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 @ http://cycling74.com/max6betabug_form/
Thanks for all the feedback.
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?
Anyway thanks for this useful object!
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")
var result = f.isopen
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.
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
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.
I am starting to use Polybuffer~ I would appreciate nice help, please.
I can tot make Polybuffer~ to play my audio files from the beginning (but the first one it plays).
I have 5 different audio files. When I send an integer to Polybuffer~ (in order to tell it which file to play) all the files start playing at the same time.
I need to play one file since the beginning , and once it is over to start playing the next one since the beginning as well and so on. Or at least make just a little crossfade between them.
In essence, The point is, how start each file play since the beginning. (or can I choose an specific point to start reading the audio file?)
Thank you very much in advance.
Im a little late for the party but i have a question. I am ‘clearing’ buffers by sending a message "send N clear" but the file is still in the index. Is there a way to remove that index? if i have a sound in index 1 and i clear index 2 it is still in the list (when double clicking polybuffer) so now i cant add a new sound to index two.
can anyone help?
Is there any way to load files with more than 4 channels without having to split them beforehand?
I have a question regarding polybuffer~ and its memory usage:
There may be holes in my general understanding of memory usage and Max, but I found it odd that small mp3-files down to 3MB (16bit,44.1kHz) actually report MORE memory usage in the polybuffer~ than for instance wav. files or aiff-files with same bit-and samplerate of about 40MB size).
Is is really supposed to be like this?
I am working on a patch where I need to lower memory-usage as it can not load all the files I need
(I use 4x polybuffers, each loadbanging 10x soundfiles in whichever format be the least memory-consuming one).
I figured initially that my Max 7.2.4 with my MacbookProRetina 2.7 GHz 16GB memory, (still on) mountain lion would handle this, but it falls short (out of memory) reading the last aif-file (49 out of 50) as seen in the max console in built standalone app.
See text in example patch for my findings.
Thank you for your help/ potential clarification.
----------begin_max5_patcher---------- 1474.3oc4ZtraaaDEFdszSw.tJEvQkyURFTTzzUcS1zssAFTRirY.uAxgN1I H8YuyEJIpXoQisHoXPLfsfnGQdNe7b4eNTec9LukEOxq8.uC7OfYy957YyzG RcfYsuelWV7iqRiq0KyaUQVFOW3ci4+I3OJzG+ywO71MIobvaPjkIha.jPee ++5K+x6927P5hPevG9SPFOqn5IPSc7c7smgzjb9phlb8oA0dvxJds7pDKRJx ushuRXLwPFcAMJJJfcC.RgK7uA329GvGa+n4MYI4obg1bgsGrV7TJWamd6WV QiX657aOZxZ8hJV9o2hB1tzxXwp6SxuqqgPH6MDFRYCPJU8BFqrE0G7aymq9 yMWHXyJwFvhVDJQ3apq.DBz2WA1fvEQ8BXCvgZeffGVlRsvTFInCSYFlxFDl tOXExV1nBVUD0Dr1aLkJ8AjzeBCkNBdfAKwBXIQnmCV+gMXUGlpp.zq4+3Hn ILkNrzDaglX4Ee2s0VZRFlvzLRbGZN.gnvn.s8apfMb7DYgmvnHiMv5TAp2Q 46S1rOiO4Ry36Mv.s.FDqKWtvD1b9mkWvmgkxhzmV1rYCu5+.Bds3ue+GXfc 2sLFu3oRtwhjNFvaYb9cdWVHB54j.F5Z211PVrFKHTmv053G3quUd1jevaiE hpDYsci5lY6vxLOd1Rt9B6qOfFjCGNoWGbF3Zi1IAN2jVHco9mSaJpxh0dMy YxQsVqRWch.0PKD+LlUFWEmwE7pa44wKMVie+Ee8q.YQK0OmDUIpBUGkRHGi lfGgI15GBQnNLgQ1yjWgemwq6V7cmiuJkGWc53i92is1whhWvj2DPPU+Js2i CtH218xIjqR4j.WUW9CVwY7UglLWUW9CFMQWEZRcPa4j.jmRZZ88EUhbYaCO 2Hy87zRkT1aSiWxScVqI0VQbZGEVnP8lrBLUx86Yg3lXlzjZw.6t1pfSjt01 rrV2kAGD2cDbTq6gPtgYjrUEDsyQQAChiVm7kgN.12VltR3gxQo6bT7vD.a1 L3f5ojHacHXeuiZ1x7q1QOQA9UEooVKmu62Wtp7bgNbQsJkseLrPNBVrICgF pK0iY5QCwLHA2oRu5ppqxpGGPUR7NuaD6AbJ8sEk779SdqS.9HpdI1TlPw6m 8NVVDQF+YlIw4nbOp4nhK4zZPsnnh+RwEr+wE1g3QCohviKopjVNGrtHmaOE dPhrNhHMBwwHKTjlWAnED0NrHia3kb2y.k6A9ixhxlR.rOlBnSL6HcAvPG2C ZaMu.yyeJr+wUirxW0PLclWWvD10MmiMR.BIuflA80DbNUk963htRktdE6w1 RIgD3NUFlMOQQp7xwNYTmyMMxFso9DQ+oMYDE4HWth4h+vnvEYS.lRs+18xM wk41H24Ti0YT+ZI6gHDejI2ZeuSjc66GGnqn09raOXnPIBdlwQ9MdVo3oeej BH2puMtT8x0WfKzV3HwObQvVVZRtg9g+bKyE56Hv1JyM5ZvKSSUsNW03o.6G IG3YyhzdcQ6YwrKiurirMhy93xQL8dRYz.s9EFbPvqEwcGLdnqm5NaRjUQcG nsiMT6i+Tb50Uf6Bddd3yF3zpxENROGO304qEv4+5lLnOpD84RKe+69NmpsG 0wODt0EMUq1hksOWVvdSZsDlI45uUScWT3AK59j0q44ck0uNoV08d8oae2u1 Sv3YOgNXOjwybBlVliK2sBlVlCaZYNzwybvtjZMd1iJLEdNyAOwp7LZlyzJQ mMorF5jxZvSp3FLYRYNSqjJ3zp6ouKU.Gw9UtjkqFGzXE6D4f8nFi7H1vBeN 7LtlC5LlChMply4tYghlTpKvnQ0bHmqxyH1yxk5x3wqvLwklnjwamDDWBeH3 w0dNKeFwjc1Pd+xLUi3xxG3U0smSso3kE+ohJ0aCtQ+1jbya0ilwqh+Px10q eXPdwUqtOQvWIZpLS14QlYjmdYEq4U4MI5A.MWck+17+G1+IrvA -----------end_max5_patcher-----------
Forums > Beta