MSP granular synth issue


    Oct 05 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.

    • Oct 05 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:
      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
    • Oct 06 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.
    • Oct 06 2011 | 9:40 am
      OK
      time for me to look at your patches....I'll get back to you later today
      Brendan
    • Oct 06 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.
    • Oct 06 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...
      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.
    • Oct 07 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).
      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
    • Oct 07 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.
      Brendan
    • Oct 07 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
    • Oct 07 2011 | 9:37 pm
      Hey Alex
      thanks for the quick and concise clarification: synchronous v. asynchronous? myKnowledge +20!
      Brendan
    • Oct 08 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.
    • Oct 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/
    • Oct 10 2011 | 6:51 pm
      Alex,
      voicedrive~ (and voicemanager~) are working wonderfully. Thanks a lot!
    • Oct 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?