cm.grainlabs~ - granular synthesis external
cm.grainlabs~ is a Max external for polyphonic granulation of pre-recorded sounds, based on Curtis Roads' asynchronous granular synthesis. It can granulate both mono and stereo audio files loaded into the sample buffer~ object. When a stereo file is loaded into the sample buffer~ object and the 'stereo' attribute is activated, cm.grainlabs~ will generate a grain from both channels and send each channel to the respective output.
cm.grainlabs~ makes use of a second buffer~ object for the windowing function applied to each grain. The package available for download contains a full collection of windowing samples. The use of a buffer~ object for windowing also allows for using other sources for windowing than the ones provided with the package.
In addition, cm.grainlabs~ tells us about the number of grains which are currently playing. This facilitates voice management when the external is located inside a poly~ patcher.
Available controls are the following and consist of an upper and lower range, from within which a random value is generated for each grain:
- start position within the selected sample buffer~ object
- grain length
- grain pitch
- pan
System Requirements:
- Mac OS 10.9.5 or above
- Max 6.1.8 or above (compatible with Max 7)
- Max running in 64 bit mode
this looks great. looking forward to checking it out!
Strictly Mac only? Might have to download this at work, to find out what your secret sauce is ;)
Brendan
yeah
I said this elsewhere apparently
Sorry
Thanks for the share, very cool! I have crashed Max twice by switching buffers during playback with this external, but haven't installed 7.0.1 yet, I don't know if that will make a difference...
Impressive! Thank you!
@ Walker Farrell: I concentrated a lot of my work on handling buffer~ objects, especially because the external uses two references. Most of my crashes were buffer~ related, but I was able to eliminate all of the ones I experienced before I released the final version.
Could you get in touch with me at circuit.music.labs@gmail.com and include some details on how exactly you produced the crashes? Maybe you could also include a crash report and your exact system specifications (OS version etc.).
Note the easily overlooked fact that the external will run in 32 bit mode, but it will crash Max eventually. Make sure that you run Max in 64 mode for smooth performance of the external.
Thank you all for your feedback! I would love to see if the external is of any good use at all. So please feel free to leave comments, suggestions, experiences or any thoughts here. You can also get in touch with me directly with the above email address.
All the best,
Matthias
one thing I really like about the TGrains UGen in SuperCollider is that there is an input for position, pan and rate (pitch) and TGrains just 'samples' that value at each trigger. This would make it possible to implement custom algorithms for those values.
In any case, this thing is really cool!
Great, thanks for sharing.
I have one little "tip" (may be useful for some people). On my computer (Yosemite installed) and with Max 7.01 (64bit) help file can't load "window" files into the buffer~. But if you convert the files from .wav to .aiff and load manually (just add "replace" message to the window buffer~, click and load converted .aiff file) everything works fine.
Oh yep, I was running in 32-bit. Hadn't checked the option. Since the external said it required 64-bit I assumed I was running in 64-bit. That'll probably explain it! I'll let you know if it happens again though.
Anyway - cm.grainlabs~ is a fantastic work!
@ YANIKI: This is strange behavior. I never experienced this when preparing and testing the package. I'll definitely check this out tonight (I'm still on 10.9.5, thought, and I'm not planning to move to 10.10 anytime soon). Where did you place the package folder when you installed cm.grainlabs~?
@ Walker Farrell: Yes please, let me know if it happens again. I hope that'll sort things out for you.
@ Nik Inhofe: cm.grainlabs~ actually samples the values at the inlets when triggering a new grain. You could then implement some sort of similar thing when you combine min. and max. values into a single control unit (for example a main control and a range control).
Thanks for all the kind words.
Any chanc to make this run under OSX 10.8.5 ?
Stephane, as far as I know, the external should run on OS X 10.8.5. I can't test because I don't have access to such an environment, but it should work. Are you running Max in 64 bit? Note that you will run into trouble if you don't.
Would you mind posting your exact issues you're having and your Max Support Information ("Copy support information to clipboard" in the About Max window)?
As for Windows compatibility, which has been requested before, I'm by no means an experienced developer and my resources and experience are limited. I seem to be using Mac only libraries which won't port well to Windows. I'm planning to go open source any time soon, so if anyone is interested in porting the external to Windows, give me a shout.
I have updated the external and included some nice new features. Read more about it and get the updated external here: https://cmlabs.wordpress.com/2015/04/20/cm-grainlabs-v1-1-0/
As usual, I'd be glad to receive some feedback on usability and stability.
Cheers,
Matthias
Hi Matthias,
i'm thinking about taking the mission to compile all available OSX only externals for Windows 32bit and 64bit. I'll start on June.
My "mission" is to try to brush off that little layer of "OSX only" matter that still cover Max.
There are so many interesting tools that are Mac only and i think is not so good for the increasing Max users' community on Windows (maybe Linux too in the distant future?).
So i'll be happy to try help you, i'm not an expert coder but i have some roots in C/C++ and OOP.
One thing to know is that at present time the only way to compile for both 32 and 64 bit architectures on Windows is to use Microsoft Visual Studio.
All the open source compiling solutions and IDE i've tried until know make possible compiling on Win 32 only. Cycling '74 is aware of this "issue" but their supporting strategy is not to support third party developed externals ( and i understand very good why..it would be a whole can of worms :-) ).
But maybe things will change with next SDK release?
thanks for your work and all the best
Hi Alfonso,
Thank you for offering your services. I have just opened the project to open source on GitHub. Feel free to clone/fork it. I also wrote a post about it on my blog (which I hope I'll be able to maintain):
https://github.com/CircuitMusicLabs/cm.grainlabs
https://cmlabs.wordpress.com/2015/04/21/cm-grainlabs-goes-open-source-on-github/
There are a few issues open, such as compatibility for Windows and backwards compatibility for Max 5 and Max 6/7 32 bit. Maybe we can join forces and make this happen.
All the best,
Matthias
Hi Matthias.
thanks for all your work.
I'll take a look as soon as i'll have some free time in early May.
Are you using some platform specific libraries?
As i took a quick glance at the code everything seems multi-platform, your own two header files included.
all the best
a.
Hi Alfonso,
Thanks, take all the time you need. In my inexperience, I assumed that arc4random_uniform is platform specific (used in my cmutil_functions.c), but this seems to be part of the C standard library. Apart from that I think it's just down to configuring the Visual Studio project.
Thanks for your interest and all the best,
Matthias
hi Matthias,
at a first look on the net i can't find the definition of arc4random_uniform in the stdlib.h file.
It seems like a specific objective-c/mac specific version of stdlib.h.
but this seems too strange to be true!
why call standard a non standard library?
i'll do further investigation and if i'll get no success i'll find a solution. either another similar function or i'll just implement this one in a custom library.
thanx and all the best
Hi Alfonso,
I was looking for a quick way to implement an easy random number generator without the hassle of using a seed etc., so I stumbled across arc4random_uniform here:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/arc4random_uniform.3.html
This is why I assumed it only works out of the box on Mac OS X. I may be wrong, and I can't test because I have no Windows Dev platform available.
All the best,
Matthias
Hi Matthias, since i can't find a replacement for arc4random i can't compile on windows.
Can you tell me wich kind of random generation the external need? I can try to implement something similar maybe?
all the best
a.
Actually now i managed to compiling it and it works!
I substituted the arc4random_uniform function with a standard rand() one.
The randomness seems pretty random and uniform.
I noticed some crashes when the object is running and changing the buffer content with a "replace" message.
May i upload the windows external to github?
Would be great a forward/reverse for grain playing (with random)
Hey Alfonso! I'm sorry for the late reply. I am moving house and I'm practically offline all the time, next to all the other organizational stuff. Should all be over by the end of the month (hopefully!).
Wow, cool you managed! Of course you can publish to GitHub. It would be cool to have one cross-platform repository for both Windows and Mac versions, even though I'm not sure how to do it right now. I would love to integrate your contribution into the main repo and have you credited for it.
You wrote:
"Would be great a forward/reverse for grain playing (with random)" --> I'm not quite sure what you mean by that.
Relating to the crash when replacing buffer content: I had that annoyance since the very beginning and I can't get rid of it. I also had users reporting crashes. I tried to replicate buffer handling of the external from more than one of the official Cycling '74 examples and I can't locate where I introduce the bug.
Anyway, I should be able to invest more time as soon as the house-moving business is out of the way.
Thanks for your efforts!
Matthias
Alfonso,
I have now included the compiled externals in the repository on GitHub:
https://github.com/CircuitMusicLabs/cm.grainlabs
Would you be willing to share the changes you had to make to the source code with me so we can find a way to publish it into the repo?
All the best,
Matthias
Hi Matthias,
i'm pretty busy right new writing some new music and i am on a tight deadline as always :-)
Basicly i did change the random function.
May i send to you my VS project folder?
Can you give me your email?
thanks and bests!
a-
as a quick note basically i've changed in cmutil_functions.c
double cm_random(double *min, double *max) {
return *min + ((*max - *min) * (((double)arc4random_uniform(RANDMAX)) / (double)RANDMAX));
}to
double cm_random(double *min, double *max) {
return *min + ((*max - *min) * (((double)rand()) / (double)RAND_MAX));
}
Hi Alfonso,
Of course, no problem at all. I don't have a lot of resources available either at the moment :-)
Sure you can. Here's my email: circuit.music.labs at gmail dot com
I'll see if I can get it onto GitHub in a reasonable way.
Best,
Matthias
Great tool !!!
But, i'm experiencing many crashes. I'm in Mac OS 10.10.5 and Max 7 running in 64 bits mode. I'm experiencing constant crashes when i try to use cm.grainlabs~ for live granulation, i'm just recording with record~ in the buffer used by cm.grainlabs~.
I guess this object has not been develop for live use, am i right ? or maybe i'm not using it in the correct way.
Thank you
Hi,
No, you're right, the object is not designed for live granulation. I have made repeated tests and experienced the same crashes as you have. As I am just a free-time leisure programmer, this might take me some time to implement..but this will be a long-term project. So please bear with me here. But thanks for you input.
-Matthias
Published
Author