Audio-rate granular
I've been working on this for a while. I want to create a patch that allows independent control of each grains frequency, duration and delay. Each grain. I don't want a cloud, I want a stream of grains where each grains 3 parameters have been chosen based on what they are set to currently.
Also, I'm not talking about granulating an audio file in some random pulling of grains from it. I want to use an audio file but only as a single grain. Kind of like using a whole carrot instead of cutting it up into sections.
I've made a scheduler-based version but I'm not sure if doing this at audio-rate is possible. Can someone please tell me if they have experience with this? Please don't recommend a package unless you know for sure that what I've just mentioned is possible.
I've tried all of the following in addition to my own:
• granular toolkit
• Max examples
• FTM Gabor
• and others
Would you be able to post a patch/part of a patch to demo what you're having trouble doing at audio rate? I'm not sure I understand exactly what you're trying to do. Do you want the grains to overlap pseudo-synchronously, but each with a different/variable length, and keeping the "phase relationship" constant all the time? That doesn't sound too difficult to do at audio rate.
Is there a problem with your scheduler based version? Or do you just believe it should be done in audio rate?
I would do it with a poly~ and trigger the grains with scheduler events. 1ms is short in comparison to the usual length of a grain...
Stefan
this is from an archive of stuff i have of other people's patches... posted long ago and i can't find the original thread now(hope the author doesn't mind me posting it here). it does the granular-streaming thang pretty well and all within signal realm, but i'm unclear on whether you want more control over the stream of grains(even as the grains keep an ordered phase-relationship, as in a 'granular train', maybe you want to still control more parameters on each grain as the train plays back?) and also what do you mean by using a single file for a grain? does that mean the entire granular synthesis would come from playback of short-duration files? that seems more a matter of sequencing audio files than of granular synthesis(because, in that case, it would be more efficient to take care of the windowing ahead of time right there within each file)...
anyways... this might not be what you're looking for since i'm unclear on that, but in case it helps...
Here's the patch. You'll have to replace it with a 512 sample waveform. You can download the one below if you like.
@Stefan: The problem is the timing. It's not as tight as I would like. Also, I haven't yet been able to figure out a way to use windowing (gaussian, etc) as a stored waveform using phasor~ or wave~ that I can play through to window the grains while also being click free.
@Noob4Life: Thanks for the patch! I'll have a look. Yes, the entire stream would come either from a 512 sample waveform such a sine wav or other sample. Where I could then vary the distance between each subsequent grain. It's described more below what I'm trying to do.
My goal is to have a single numerical control over each grains frequency, the delay between each grain and the duration (in ms.) of each grain. And do all of this at audio-rate if possible. Trying to do this in the past, I've run into issues with having to find zero crossings and such.
Patch:
Here's a quick throw-together of an audio-rate version of your patch, which I'm fairly sure does exactly what you need. It won't sound quite the same with the same settings (you'll need to tweak the dur and delay times), I think just because of the schedular-windowing in yours not being as accurate. You'll need the [shot~ ] external by Andrew Benson. It just provides an easy way of generating a 0-1 ramp of variable duration from a click pulse. That's a bit of a pain to do natively in msp :) You should d/l the rest of his objects from the share pages, they're very useful for this sort of patch. https://cycling74.com/share.html
Thanks so much for posting this Tim! It's exactly what I was trying to build. One thing I noticed though was that when I scale the delay down to 0, the sounds cuts out. Do you know why this is? I don't completely understand how the patch works yet.
Off the top of my head (I've not got max available atm), it doesn't make sense to give [train~ ] a pulse interval of 0, because that would translate to an infinitely high frequency. If you start off at 0 you should see the patch kick back into life somewhere below a pulse interval of 1ms.
I *think* that the smallest pulse interval that will allow output from [train~ ] is determined by sample rate/2 (then convert hz to ms to limit the lower bound of the delay parameter), so running the patch at a higher sample rate will allow you to get closer to 0. The best way to do it in this scenario would probably be to use your grain_pulse subpatch in an up-sampled [poly~ ], if you need to get really close to a delay of 0 :)
this 'thing' is awesome. thanks, Tim!
@Tim: after doing looking again at the patch with some scopes and number~ boxes, I may be wrong, but the change~ object doesn't appear to doing anything. When I took it and the clip object out, things didn't seem to change much in the signal. Thoughts?
You're right Wade. I was using change~ and clip~ in the patch before I remembered shot~. Shot~ creates a ramp on any 0 to non-0 transition so yeah, it can be driven directly from train~. Nice catch, the simpler the better!
I can't find "shot~" in max/msp. It is an external ? Where can I find it ?
Thanks.
As stated before...
"You'll need the [shot~ ] external by Andrew Benson. It just provides an easy way of generating a 0-1 ramp of variable duration from a click pulse. That's a bit of a pain to do natively in msp :) You should d/l the rest of his objects from the share pages, they're very useful for this sort of patch. https://cycling74.com/share.html"
Unfortunately, there seems to be no windows version of Andrew's externals...
@Cheng - Here is an *almost* working shot-less version of the patch I posted before. You have to keep duration less than delay or it doesn't work correctly...........like I said........replicating AB's externals natively is a bit of a pain :)
Tbh, it might be easier to just use Nathan Wolek's grain.pulse~ external, because it does exactly what my patch does already. You just have to bear in mind that the pitch_mult parameter is your control over the read speed of the grain. It may not let you expand the concept of that kind of grain generator in the same ways, but if you simply want a stream of grains of x duration, x ms apart at x pitch, then it's easier and more efficient to use the external.
Here you go anyway if you're interested:
I haven't looked at the patch, but if you don't need uninteruptable output from the shot~ object, I think rampsmooth~ works just as well.
haha, rampsmooth~ would have been a much easier way of doing it I think! One day I'll learn not to do things the hard way :)
Although with rampsmooth~ you're limited, because you can't control the grain duration at audio rate.