goodparleyandorfing

I have a phasor~ reading through two play~ objects, one containing a window and the other containing a sample to granulate. I have an independent control for 'grain period' (the time period inbetween successive grains), and this works by detecting the end of a ramp and then sending a zero to the phasor~. The inert period lasts for the grain period and then the ramp is restarted. It works.

However, as soon as I attempt to introduce another 180º offset granulator all hell breaks loose. The grain period function means that I cannot do the old [+~ 0.5] > [pong 0. 1.] trick to derive an offset ramp, and thus control everything from the one phasor~. Using two phasors is more or less out of the question, due to how difficult it is to reliably sync them. Trapezoid offers a different way of doing this, but one has to fiddle a lot to make the ramp and the offset truly independent, as changing the frequency of the phasor rescales the 'up' and 'down' values. Ideally I would like to stick as close as possible to the original method, but can anyone suggest a way of producing n offset copies when the phasor ramp is not continuous? (i.e. it is broken up by variable gaps: /_/__/___/____/_____/ )

I have a phasor~ reading through two play~ objects, one containing a window and the other containing a sample to granulate. I have an independent control for 'grain period' (the time period inbetween successive grains), and this works by detecting the end of a ramp and then sending a zero to the phasor~. The inert period lasts for the grain period and then the ramp is restarted. It works. 

However, as soon as I attempt to introduce another 180º offset granulator all hell breaks loose. The grain period function means that I cannot do the old [+~ 0.5] > [pong 0. 1.] trick to derive an offset ramp, and thus control everything from the one phasor~. Using two phasors is more or less out of the question, due to how difficult it is to reliably sync them. Trapezoid offers a different way of doing this, but one has to fiddle a lot to make the ramp and the offset truly independent, as changing the frequency of the phasor rescales the 'up' and 'down' values. Ideally I would like to stick as close as possible to the original method, but can anyone suggest a way of producing n offset copies when the phasor ramp is not continuous? (i.e. it is broken up by variable gaps: /_/__/___/____/_____/ )


control-grain-period-and-sync-more-than-one-granulator

a glance at my thread history will tell you that I too have really been round the block on this one myself, so I feel your pain!

https://cycling74.com/forums/gen-and-sah-and-phase-shifting/

The +~ 0.5 trick does create problems once you start to extend your grain algorithm, particularly when sah~ becomes involved too.

leafcutter kindly provided a solution here:

https://cycling74.com/forums/muting-phasor-almost-there/

but of course I managed to break it while trying to adapt it for my own needs. The "best" solution I came up with was to use sampled noise threshold as a trigger to mute the grain window. Might not be ideal for your needs but here it is anyway:

Hi
a glance at my thread history will tell you that I too have really been round the block on this one myself, so I feel your pain!

but of course I managed to break it while trying to adapt it for my own needs. The "best" solution I came up with was to use sampled noise threshold as a trigger to mute the grain window. Might not be ideal for your needs but here it is anyway:


(rate~ object looks kinda pointless in that situation)

Peter McCullough also recommended using a single global phasor, to avoid sync drifting across multiple voices; should also have said that my example above uses only 1 grain per voice, with overlap dependent on voice number and instance; it may serve as a demonstration of alternative approaches rather than a direct response to your question

Excellent, thanks NOOB_MEISTER -- I wondered whether you might have encountered this! Can't just picture how the noise threshold thing would work but I'll take a look at the patch. That point about having the grain period as a function of the phasor~ frequency is something I had overlooked too.

the noise method is sort of a random square wave, with some control over pulse width; it mutes the grain envelope, synced to the central phasor, that way there is a degree of control over the grain interonset time; sadly it doesn't quite give me the huge spread that you get from clouds of random grains. The remainder of the algorithm just ensures that grains are 

 correctly phase shifted, regardless of number of voices or changes to phasor and other parameters.

the noise method is sort of a random square wave, with some control over pulse width; it mutes the grain envelope, synced to the central phasor, that way there is a degree of control over the grain interonset time; sadly it doesn't quite give me the huge spread that you get from clouds of random grains. The remainder of the algorithm just ensures that grains are always correctly phase shifted, regardless of number of voices or changes to phasor and other parameters.


Here's leafcutter's rather elegant little mutable phasor; you may encounter problems when trying to lock down phase offsets though; I seem to remember this was my issue that broke it. It's very good though

Ah yes, doing it with +=~ and bypassing phasor~ altogether occurred to me last night just before I dropped off. Thanks for this, and for your poly~ + gen solution too. It works very well, although there is a slight pitch jump when the grain size is changed. I've attached a slight modification (if I may be so bold!)

Yep, fell right into my trap, mwah ha ha.

This is a previous algorithm I tried, which doesn't work. It 

 allow independent pitch and size variables 

 it de-synchronises the phase offsets. Trust me, multiple phasors is not a solution. I even tried "banging" their unique phases via parameter changes, but it was too glitchy. Hence, PM's method of a single master phasor.

You might have more luck with leafcutter's algo than I did.

This is a previous algorithm I tried, which doesn't work. It does allow independent pitch and size variables but it de-synchronises the phase offsets. Trust me, multiple phasors is not a solution. I even tried "banging" their unique phases via parameter changes, but it was too glitchy. Hence, PM's method of a single master phasor.

unless, of course, de-synched overlap isn't an issue for you; then your solution is fine.

The same solution to the pitch jumping could be applied to a master phasor~ though, without duplicating phasors in Gen/poly~.

The other poster whose patch calculates the derivative of the output of phasor and increments an accumulator by that number is an interesting solution, and a way of doing this without losing a master phasor~

The same solution to the pitch jumping could be applied to a master phasor~ though, without duplicating phasors in Gen/poly~. 

The other poster whose patch calculates the derivative of the output of phasor and increments an accumulator by that number is an interesting solution, and a way of doing this without losing a master phasor~


Correct, but where do you derive the sah~ trigger from, in a polyphonic granulator? Furthermore, leafcutter's solution is equally plausible, but phase-offsetting a mutable phasor cuases further problem when the ramp (of the source) is at 0.; in a phase shifted ramp, 0. will translate to 0.25 or 0.875 etc.

If you can devise an algorithm for sync-locked overlapping and mutable phasor-driven grains, I'd love to see it, cos my gen~ chops aren't that hot!

OK, now I'm with you (and right back at my original query, in a sense). I'll keep hacking away at this. Thanks for your help, it has to be possible...!

look forward to seeing your results . . .

I think the solution to this is much more simple than silencing a phasor~. I've not tried it yet, but I can't see why it wouldn't work to just rescale the window function. For this you would have to read through a table of samples rather than process the phasor~ directly, as you are doing. But one could either rescale the *~ going into play~ (and reposition the starting phase if necessary), or dynamically write a scaleable window into a buffer using poke~. For my purposes I expect this will be case closed...

The other solution which I almost got working yesterday is to sync two or more phasors in gen doing some kind of ducking trick for when the new frequency is less than the previous, as was suggested by the poster in the other thread..

control grain period and sync more than one granulator