Forums > MaxMSP

MSP granular synth issue


red
October 5, 2011 | 12:12 am

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.

Thanks for any insight.

– Pasted Max Patch, click to expand. –
– Pasted Max Patch, click to expand. –

brendan mccloskey
October 5, 2011 | 2:58 pm

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:

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.

HTH
Brendan


red
October 6, 2011 | 3:43 am

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?

That is, I think my main issue is this:

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.


brendan mccloskey
October 6, 2011 | 9:40 am

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

Brendan


red
October 6, 2011 | 2:59 pm

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.


brendan mccloskey
October 6, 2011 | 4:14 pm

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…

– Pasted Max Patch, click to expand. –

Brendan

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.


AlexHarker
October 7, 2011 | 7:22 pm

Hi,

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.

HTH

Alex


brendan mccloskey
October 7, 2011 | 9:13 pm

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.

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.

– Pasted Max Patch, click to expand. –

Brendan


AlexHarker
October 7, 2011 | 9:33 pm

@Brendan

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.

Alex


brendan mccloskey
October 7, 2011 | 9:37 pm

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

Brendan


pid
October 8, 2011 | 11:37 am

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.


red
October 10, 2011 | 4:14 pm

Hey Alex,

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: http://cycling74.com/toolbox/benson-signal-rate-utility/


red
October 10, 2011 | 6:51 pm

Alex,

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


Dave Mollen
October 23, 2011 | 11:54 am

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?

Viewing 14 posts - 1 through 14 (of 14 total)