I'm in the first stages of building a granular synth in MSP. I am currently having an issue in which changes in grain duration, either automatically via stochastic duration jitter or manually, often result in changes in pitch.

I believe this may be happening because while the shot~ external does not allow itself to be interrupted by a trigger while it is active, it does respond to changes in Length of Ramp while active.

So, I'm trying to find a way to gate the input to a sah~. Doing this by using the shot~ "busy state" output hasn't been successful.

I'm attaching the patch. It uses the shot~ and random~ externals.

redonegrain~ is first and is used as a poly~ in the second patch.

I'm in the first stages of building a granular synth in MSP. I am currently having an issue in which changes in grain duration, either automatically via stochastic duration jitter or manually, often result in changes in pitch. 

I believe this may be happening because while the shot~ external does not allow itself to be interrupted by a trigger while it is active, it does respond to changes in Length of Ramp while active. 

So, I'm trying to find a way to gate the input to a sah~. Doing this by using the shot~ "busy state" output hasn't been successful. 

msp-granular-synth-issue

forgive me for not looking at your example patches, quite busy currently. My usual response to granulation/pitch issues is to suggest two things:

the granular synth example in the Cycling74 folder, and my own tutorial here:

http://www.youtube.com/watch?v=h-WJucUMeFs

which addresses, amongst other things, the two issues of 'unwanted' pitch modulation, and triggering [sah~]. Other tutorials are available, demonstrating either [groove~] or [2dwave~] in this context - I use [play~].

The video concept and description is high quality; the audio sadly is not.

Hi red
forgive me for not looking at your example patches, quite busy currently. My usual response to granulation/pitch issues is to suggest two things:

Thanks for the suggestions. I haven't gotten through all the videos yet, so forgive me if this is addressed later: my version triggers shot~ using a Poisson process, while it seems that (at least in the initial stages) yours uses a continuously running phasor~. Perhaps this isn't germane, but it seems like a fundamental difference. Any thoughts on how to accomplish this using a Poisson process trigger?

duration is selected and sent to a sah~ triggered by a Poisson process

the trigger tells shot~ to start a new ramp and also changes the duration. However, shot~ does not allow itself to be retriggered mid-ramp, but it DOES accept changes in duration mid-ramp. Thus, when a new duration is sent, shot~'s ramp changes, and I believe this causes the change in pitch.

So, it seems I need to gate the duration input to shot~ based on shot~'s own busy state output. Would the suggested solution be to similarly use send~ to introduce a vector delay? This doesn't necessarily strike me as an elegant solution, but perhaps it is.

time for me to look at your patches....I'll get back to you later today

OK
time for me to look at your patches....I'll get back to you later today

Thanks. I tried sending the busy state output of shot~ to a send~, then the receive~ to !=~ 1 used as a control to a gate~, the input of which was the trigger. This doesn't quite get rid of the unwanted pitch changes.

I had a quick glance at your subpatch, and although I'm not familiar with [shot~] or the Poisson algorithm, it appears that your method is similar to mine, which is summarized in the patch below; again apologies for not being able to offer a solution to your own algorithm - really frikn annoying when you've obviously put the hours in with this idea...

it IS possible to vary the actual grain size in this example, just attach an [int] to the [pak] at top left where the [50] message is. I'm using this method though to avoid pitch change in a phase-shifted duplicate, for overlapping grains.

Hi
I had a quick glance at your subpatch, and although I'm not familiar with [shot~] or the Poisson algorithm, it appears that your method is similar to mine, which is summarized in the patch below; again apologies for not being able to offer a solution to your own algorithm - really frikn annoying when you've obviously put the hours in with this idea...

ps
it IS possible to vary the actual grain size in this example, just attach an [int] to the [pak] at top left where the [50] message is. I'm using this method though to avoid pitch change in a phase-shifted duplicate, for overlapping grains.


I had some problems with shot~ when I tried some similar things - I think it worked OK with float input, but not signals, which I wanted (sample accurate length changes).

As a result I ended up coding my own solutions. The results can be found in the distribution here (mac only currently, although I have beta windows builds here).

http://alexanderjharker.co.uk/Software.html

The object that might help you is voicedrive~.

I believe you can use this to replace the shot~ external and achieve the functionality you need, although it might take you a little while to familiarise yourself with the object. I would hope the transition would not be too painful however.

ASFAIK this is not a problem that can be solved without an external solution.

I'm curious to learn why the [shot~] external may be (or isnt'??) preferable to [phasor~] in this context; am I to assume that the latter is not sample accurate? Such a question reveals my lack of knowledge.

I spent several weeks pounding this forum a while back, trying to determine the best algorithm for granulation synthesis using native objects, and a summary of my findings can be found in the patch below, which I include only for fellow travellers. Key contributors included Alex and Tim Lloyd, without whom etc.

Hi granulators,
I'm curious to learn why the [shot~] external may be (or isnt'??) preferable to [phasor~] in this context; am I to assume that the latter is not sample accurate? Such a question reveals my lack of knowledge.

Depends what you wish to do. phasor~ is fine if you wish to have continuous grain streams, and you aren't insistent upon changing speed only on a zero-crossing (the send~ receive~ hack in your patch will not properly achieve this).

using vb.phasor0~ would solve the change on zero-crossing thing.

shot~ or voicedrive~ are suited to applications in which the grains in any one stream are not continuous and may be triggered at any point in time - sample accurately, although in fact you can also make them continuous by constantly triggering them.

thanks for the quick and concise clarification: synchronous v. asynchronous? myKnowledge +20!

Hey Alex
thanks for the quick and concise clarification: synchronous v. asynchronous? myKnowledge +20!

when did you last download [shot~]? it got a couple of fixes not long ago, including that signal/float issue.

[vb.phasor0~] solved so many issues for me. it is genius.

of course max6/gen will solve all of this.

Thanks for the suggestion. I'll download voicedrive~ and report back.

pid--the most recent version of shot~ I can find at the moment seems to be from 11/24/09: 

https://cycling74.com/tools/benson-signal-rate-utility/

pid--the most recent version of shot~ I can find at the moment seems to be from 11/24/09: https://cycling74.com/tools/benson-signal-rate-utility/


voicedrive~ (and voicemanager~) are working wonderfully. Thanks a lot!

But you can't change the speed midramp, or can you?

Shot~ can do it, but unfortunately I haven't found any version of shot~ without certain bugs.

So yeah, does anybody how to do a oneshot and be able to change the speed midramp?

Voicedrive~ is great indeed.
But you can't change the speed midramp, or can you?
Shot~ can do it, but unfortunately I haven't found any version of shot~ without certain bugs.

So yeah, does anybody how to do a oneshot and be able to change the speed midramp?


MSP granular synth issue