petra needs beta testers - Max Package for granular synthesis
Hi all,
I'm happy to announce petra, my brand new Max Package with external objects for granular synthesis (sample based granulation). I am planning to submit the Package to Cycling '74 to add it to the Package Manager, but first I am looking for beta testers who are willing to give petra a spin.
Some of you might remember the cm.grainlabs~ object I've published a while ago (https://cycling74.com/tools/cm-grainlabs-granular-synthesis-external/#.WJLFCrYrLMU). In the meantime, the project has grown into a family of four external objects and has replaced the cm.grainlabs~ project.
The external objects are compatible with both Mac OS and Windows.
The Package can be downloaded on my GitHub page:
https://github.com/CircuitMusicLabs/petra
Or if you are not comfortable with GitHub, you can get it directly from my website:
http://circuitmusiclabs.com/
You can follow the release cycle here:
https://github.com/CircuitMusicLabs/petra/releases
To install, follow the instructions in the README file.
I'd be thrilled if some of you could give the package a test run and report any findings or difficulties back to me, either via GitHub or the contact form on my website.
I'm also open for feature requests.. :-)
Thanks in advance,
- Matthias
Hey Max Friends,
I have received a number of helpful comments and crash reports over in the facebook group.
This morning, I have released v0.2.0-beta of the granular synthesis package. I have rewritten the basic mechanism for granulation and updated the entire documentation.
I would be immensely grateful if you could give the new version a test run and report back any issues you may have.
Thanks in advance,
- Matthias
this is great!
This is very cool. Good job!
Played with it for hours, no breakage yet.
@Matthias - what's the reason for the values assigned to the object properties such as min/max grain length, pitch value, etc? It might be nice to have a grain longer than 500ms.
Andrew, thanks for testing. Awesome that you like it!
Since v0.2.0-beta, the short answer to your question is memory. Before that, I'm not quite sure why I imposed this limit in the first place. But concerning memory, every grain is cached in memory (RAM) when it is triggered. So I need to be able to reserve a certain amount of memory to hold the longest possible grain that could be triggered. And here, length and pitch have a great influence on the maximum possible grain size I need to reserve (length * pitch = actual grain size).
Hi all,
I've just pushed v0.2.1-beta, which contains some significant changes. You can find the changelog and the downloadable package here:
Again, I'm grateful for any kind of feedback that flies my way. So I would greatly appreciate it if you could try this new version out and see how it works for you.
Thanks in advance,
- Matthias
Hello Matthias,
I like cm.buffercloud~ very much, also because it works both under MacOS and Windows.
However there's a tricky issue, probably not easy to reproduce because it's not systematically appearing: sometimes one cannot load a sound into a buffer if cm.buffercloud~ is simply inserted inside a patcher. The message "can't read file now" appears in Max windows. It happens both under MacOS X and Windows.
If one changes cm.buffercloud~'s name to, say, "_cm.buffercloud~", then quits Max, reopens it, loads the patch, loads a sound into the buffer and then restores the object's original name, everything is fine.
I've seen the issue arose also with karma~ and was solved with a code modification. See this thread.
Hi Roald
Thank you so much for your kind words. It's good to hear that some of you actually like what I'm doing here ;-)
About the buffer issue: Yes, I have stumbled across this very early on and was convinced I had solved it with properly locking and unlocking the buffer sources in the code. This is actually exactly the point that was wrong with karma~ in the thread you posted.
I have now reviewed my code and I do have a few extra safety things going on that might prevent the lock/unlock pair that Raja mentions in his reply. Actually, in my case the lock part would be missing, unlocking would still occur in any case. I've taken care of this now so that locking and unlocking always occurs in a pair. We'll see how that goes.
But I have to say that I was recently working on a patcher totally unrelated to my objects and the message "can't read file now" appears in the Max console when I want to replace the sample in the buffer~. The solution was to look at the way the buffer~ object was initialized :
Original:
[buffer~ name] --> so just giving the buffer~ a name and then trying to use the "replace" message caused the "can't read file now"
Revised:
[buffer~ name 100] --> giving the buffer an initial size solved the issue. Even pre-loading a sample worked, such as [buffer~ name drumLoop.aif]
The problem is, I can't recreate this behaviour now, no matter how hard I try. So I can't tell for sure.
Thanks for looking at it again,
Cheers
- Matthias
Just minutes later, I come in with the updated beta release. 0.2.2-beta is online and can be downloaded on GitHub:
https://github.com/CircuitMusicLabs/petra/releases/tag/0.2.2-beta
Or on my website:
http://circuitmusiclabs.com/downloads/downloads-petra.html
The changelog is quite extensive, so I'm quite hungry for feedback.
Cheers,
- Matthias
Hi Matthias,
The issue with "busy" buffers came again when using several cm.buffecloud~ objects in the same patcher. The current workaround is quite heavy as it implies deleting the buffers and recreating them whenever you want to load a new sound.
Hi Roald,
I must say I'm quite stumped because I double- and triple-checked the buffer lock and unlock procedures, analog to the issues reported for karma~.
Could you post a compressed patcher that shows the issue and let me know about your specs (OS, Max Version, the lot)?
I'll look into it.
Thanks
-Matthias
Hi Matthias,
Here's the patcher (it's included in a .zip archive because of the subpatchers). Open "Interpolation 7-2...". If you need additional precisions please send me an e-mail at roald dot baudoux at brutele dot be.
As I am not at school yet, I can't tell the exact OS and Max versions now. However the issue arose both on a school's computer running macOS (I think it's Yosemite or Sierra)/Max 7.x and on several student's computers (running Windows 7 or 8 with Max 7.x too).
Thank you.
Roald
Thank you so much Roald. I'll look into this this week. I'm a bit busy with other stuff this week, but I'll put it on my agenda. I'll write you an email as soon as I've got something on this.
-Matthias
Hi Roald
I have now been able to take my time with your patcher. Although all comments are in French, I somehow managed ;-)
Anyways, I have not been able to pin the problem down to something with the source code of the petra objects, the buffer operations strictly follow the principles outlined in the examples by Cycling'74 and I couldn't find anything else that could go wrong.
However, as I've mentioned before, I myself have had the buffer~ issues you are describing. And they were completely unrelated to the petra objects.
As posted before in this thread, the solution I have found is to initialize the buffer~ objects with an initial length, such as [buffer~ name 100].
I applied this principle to the patcher you attached and the issue was solved. I've attached the slightly modified patcher to this post.
I don't want to claim that I'm doing everything correctly in my objects, but I just can't find the cause with locking and unlocking the buffer~ objects in my code. Rather, I am starting to suspect that the issue has something to do with an item listed in the "currently unsupported or limited" section of the Max 7.3.3 release notes (https://cycling74.s3.amazonaws.com/support/version_7_3_3.html):
- import features for buffer~ are limited.
Maybe one of the Cycling'74 team could risk a comment on this?
I hope the suggested change in your patcher solves the problems you were experiencing. Let me know if there's anything else I can do.
- Matthias