make play~ work like groove~

    Apr 21 2010 | 11:51 am
    Ok, don't say "why not use groove~". I've been advised on this forum to try [play~], or other similar objects, as the basis for a granulator instead of [groove~]. Except [groove~] has all the nice functions like loop-interpolation, ducking and sync output etc. I've mimicked groove with this patch using [play~], but (surprise surprise) as I'm not well-versed in vector sizes/scheduler etc, I'll get crackles when any parameter is changed (phasor~ freq, offset etc). Any DSP guru willing to assist please?

    • Apr 21 2010 | 12:25 pm
      I would really use [wave~] for this kind of thing rather than [play~] or [groove~]. Sorry to throw another one in there, but for granular synthesis it really is the best bet. That way you can have the formant, amplitude window and whatever else controlled by a single [phasor~], and use nathan wolek's [phasor.shift~] to keep multiple grains in sync.
    • Apr 21 2010 | 12:48 pm
      Here is how to get rid of the crackles:
    • Apr 21 2010 | 12:48 pm
      This sounds good, but do you have time to demonstrate? I'll have a go myself obviously (how many posts begin like this: "noob needs help with coursework assignment but I can't be bothered to do it myself..."??)
      My challenge is sync-ing grain-windows onset to grain-frequency without drift, even at small values.
    • Apr 21 2010 | 1:09 pm
      (how many posts begin like this: "noob needs help with coursework assignment but I can't be bothered to do it myself..."??)
      Entirely too many, but you're leaving out the really important bit about needing it tomorrow! :-)
    • Apr 21 2010 | 1:17 pm
      LMAO; actually I'm doing a PhD in DMI design, so I really really need it by three years from now!
    • Apr 21 2010 | 1:25 pm
      I guess you can add to your CV the skill of mind-reader! The problem is exactly that: interrupting [phasor~] in mid-ramp. I will dissect this handy patch until I know exactly what every element is doing.
      Thanks man
      @goodparleyandorfing; thanks for the tip, I've got [wave~] doing [groove~]-type stuff, and in conjunction with timlloyd's tools i should have this sorted in a few days/months/years.......
    • Apr 21 2010 | 3:41 pm
      Well - I'm going to have to say these this:
      I DO NOT advise the use of [play~] over [groove~], unless for some reason you need to access the sample in some random way, or have other special requirements - for playback I always prefer [groove~], as it is simply more accurate than [play~] (the internal phasor is able to use 64 bit precision) - play~ is less accurate because of the need to use a 32 bit float signal to drive it's input, which becomes very clear with longer samples (there is a limited length for which play~ will play back at normal speed accurately), So - to those who, advised you to use [play~] I say - why?
      Next up - [wave~] - that is all well and good for multiple in-sync window functions etc., but [wave~] uses linear interpolation, rather than the cubic interpolation used by [groove~] and [play~] - that's really not good enough for decent audio playback most of the time - playing back at low speeds makes the difference in quality more noticeable. Plus - the same problems as with [play~] mentioned above.
      In short - I would always choose [groove~] for audio playback (in terms of standard max objects) based on audio quality - for window functions etc. YMMV - but in these cases quality is not an issue in the same way.
      HOWEVER, just read a couple of posts further down, and for sample accurate applications [groove~] may be problematic. There are areas where the features of other objects might win out, but be aware that [wave~] is not going to offer the same accuracy. Further to this, for accuracy I would prefer [play~} over [wave~] - you can still control multiple [play~s] with one [phasor~] if your scaling is done correctly, so I would see [wave~] as simply a lower quality route to the same solution (although [play~] might require a bit more patching).
    • Apr 21 2010 | 3:45 pm
      I deconstructed timlloyd's simple but effective patch and only one question remains: if I connect the phasor~ signal directly to the first sah~, the patch hangs; why are unique send~ and receive~ objects necessary in this context?
    • Apr 21 2010 | 4:07 pm
      They introduce a vector size of delay, you can't connect the [sah~] outlet back to its inlet because max can't see into the future.
    • Apr 21 2010 | 4:08 pm
      Thanks for your incisive comments Alex; [play~] was one of a list of suggestions, including [wave~] and others. I suppose time-domain granulation in the region of Brendan
    • Apr 21 2010 | 4:12 pm
      And thanks Luke!
      My supervisor keeps saying "use externals for this stuff, that's what they are there for"; But i want to crack the code, the holy grail as it were, artefact-free time-domain granulation.
      stay tuned
    • Apr 23 2010 | 9:56 pm
      Raja, hasn't anyone told you that you can drop the loadmess 1 stuff with gate objects by using a second argument to gate? Perhaps a few minutes to make your patches more readable to the beginners you wish to assist might not be a bad idea, either. I'm sure your mileage will vary.
    • Apr 23 2010 | 11:12 pm
      In terms of windowed sinc interpolation - in my opinion it's only really worth it for the anti-aliasing (faster playback speeds) - I'm not convinced that low speeds work that well for low numbers of crossover points - with volker's external I get high frequency artifacts at low speeds (like sine tones) that are pretty distracting (I haven't tested massively, but that's what I'm hearing here with a couple of different files).
      I've also done my own external from scratch using windowed-sinc and I wasn't that pleased with the low speed sound - I think ideally I'd go for a different approach according to the speed, which I may implement when I revisit my external in the future.
      The cpu hit can be so large (comparatively speaking) however, that for my money it's not worth it for lower speed playback, or for material with not that much HF content, or for small speed increases. Pitch shift a harmon muted trumpet of 3 or 4 octaves however, and you'll for sure notice the difference.
    • Apr 24 2010 | 7:39 am
      This thread is definitely getting added to my favourites - lots of helpful stuff. As to those of you who mentioned poly~.......... of course! I've been variously adapting and breaking timlloyd's patch to get that smooth, blurred wash of timbres (like you do in Jean-Francois' spectral tools), and poly~ is the answer. I shall return with a patch, but I have one final question: do I need to prefix ANY of the objects in this (tim's) patch with the #0 'name argument' I have seen in numerous poly-patches here? I can't find any specific references in the documentation, or understand the necessity/function?