make play~ work like groove~
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?
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.
Here is how to get rid of the crackles:
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.
Thanks
Brendan
(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! :-)
LMAO; actually I'm doing a PhD in DMI design, so I really really need it by three years from now!
@tim
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.......
Cheers
OK
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).
Regards,
Alex
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?
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.
lh
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
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
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.
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.
Alex
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?