gen~ version of grooveduck
is there a gen~ version of grooveduck?
I'm asking because I can't seem to avoid the clicks when I change the loop start, and it would seem logical to conclude that a gen version of this would be a lot more efficient
There's not. You can certainly roll your own, of course....
I wish I could, but i'm just a small villager :(
Fade playback till loop points get properly
executed by grooveduck ?
Or for perfect clickless operation crossfade between 2 players ?
xsample~ externals have extended options for loop interpolation and
crossfading.
Not officially released as 64 bit, but do exist.
https://grrrr.org/research/software/xsample/
here the externals :
xsample-objectmappings.txt file must be placed into
Max/resources/init folder (on windows)
regarding xsample:
"Error 126 loading external xgroove~"
oh well
Regarding question:
" Or for perfect clickless operation crossfade between 2 players ? "
^^this
I have run xsample on Max 8.1.5 on Mac - no problem
will try it on windows when I get time, that error means missing library, usually
some runtime DLLs.
Here's the original grooveduck2 ported to gen~, with minor tweaks (latching parameter changes to happen during the duck so you don't hear them).
I also agree that it would be even better to have a clickless, duckless looper by crossfading two players ... maybe that next?
THANKS DOC
this really works better than the original and should be put in the gen examples
@graham wakefield
Perhaps a naive question: is it possible to implement timestretching to this gen patch?
So the speed variable controls only the length of the sample and there is a new varibale that only controls the frequency
It probably could, but I'd imagine you'd want the 2x overlap while reading back the waveform rather than just ducking. I suggest checking out the gen~.slicer example in the max examples folder for an example of how to do that. That slicer patch is designed for pitch-shifting a real-time input, but you could rewrite this with direct control over playback rates from a fixed buffer for timestretching effects.
For extra points, it would be neat to do some analysis on the underlying waveform, and modify the window size accordingly -- so that sharp transients get short windows that preserve their dynamics and softer, more pitched sounds get longer windows that minimize the AM-like artifacts. Maybe also skewing the window shape might help -- or at least exposing that as a parameter.
Graham
thanks, it's a long shot but will try
Here's that gen.slicer example updated to support timestretching of a buffer~.
Notice how the window duration affects the sound. On a transient rich, unpitched source like the drumLoop, it sounds pretty good with very short windows, 10-500 samples, imparting a kind of phasey artifact. On a pitched source however, such a window sizes conflict with the pitched material in a kind of amplitude modulation way; instead, larger window sizes in the thousands of samples are better, leading to less obtrusive echo effects.
The phasey/pitchiness of the artifacts partly comes down to the regularity -- the window size is always the same and repeats with a constant frequency. So the regularity could be reduced by modulating the window duration. This is demonstrated in the gen~.pitchshift.maxpat example, which adds randomized offsets to window sizes for each grain. (This example also shows how to layer four rather than two windowed samples to smear it even more). But it kind of just replaces the ringiness with noisiness.
What I was suggesting is that, if we can tell if the input is more transienty or more pitchy, pick a window size accordingly. For pitched material, an ideal window size would be the fundamental pitch, as this would avoid introducing new frequencies to the output. One of the simplest methods of detecting pitch is to measure the time between zero crossings. It's not a great pitch detector, but for fairly simple waveforms it's not bad considering how simple it is. So, the idea is, if we can guess what the period of the input waveform is, we can align windows to that same period, and the artifacts might not be very noticeable. For transient-rich waveforms this period is going to be really short, so it might just work automatically.
Graham
thanks a lot, will check it out. luckily the project i'm working on has samples that have predetermined and known pitch so windowing will be fine.
@Source Audio
sadly I've the same problem running xsample.
A release of xsample, xgroove, xrecord and xplay for windows 64bit would be very cool,
for ppooll, also.
It looks like xsample is loading xgroove~:
-
If xsample is selected from the pop-up (it's without tilde): Max Console:
Error 126 loading external xgroove~
--
The attempt to open xsample.maxhelp:
xrecord~, xplay~, xgroove~
(C)2001-2014 Thomas Grill
--------------------
xsample.maxhelp: read failed
xsample.maxhelp: can't open, error 0
-
Search in the archives -- I seem to remember there being efforts to port xsample to gen~ (I might have been part of them... many sleeps since then)
The gen port I haven't found yet but -
I was wrong.
The xsample files posted above are working - only the help file is not working.
The thing is - xsample is in fact a collection of three externals xgroove~, xplay~ and xrecord~.
None of them is named xsample but they are all linked to one help file: xsample.help - which is not working.
I have checked the help file from the upload.
It is old max4 help file (in binary format) and it should be named xsample.help
and not xsample.maxhelp
I don't know really how that happened.
One can simply resave it using max 6 or higher to get .maxhelp version.
--------
I did not have time to check windows version myself,
you say it is working as 64 bit in max 8 ?
I ask because of that mentioned error 126
Yes, It's working!
I've tested all three externals via the .maxhelp file quickly and they are working so far.
Thank you very much!
Error 126 is gone, too.
Typing xsample into in object box or selecting xsample from the menu -> object is greyed out, no error message.
I'm experiencing a strange behaviour of grooveduck, wich is randomly appearing (most of the times there he is) when I turn on timestretch. With timestratch's turned on and the playback speed different from 1 it starts clicking. Sometimes it works as it should but I'm having a hard time guessing why the problem shows up.
I've made a mc.grooveduck2, and now I'm trying to find a reason for this ghostly click.
Here a confrontation patcher.
P.S. Graham the gen.slicer sounds really nicely, I didn't knew of it. Inside my sampler I will think of the possibility to change the playback core, or I will simply used this one on other opportunities from now on. Also, what you suggest about a dynamic resizable window sound really intriguing, at the same time messing with it gives a nice palettes of artifacts ; )
Cheers
Oh, I made che confrontation patch thinking the issue was inside my mc. versione, but that is not the case, even due "simple" grooveduck2 has this problem. Maybe this is the same issue of the OP
Many thanks for this 64bit version of xsample.zip , I can now open a 20 years old patch of mine on Max8.5.
As you seem to have access to unofficial versions, are you aware of an ARM version?
Waouh!, many thanks Source Audio. I will test it soon.
I just tried the intel version under 8.5.7 and 7.3.5.
[waveform~] (or [plot~]) is not refreshed when xrecord~ modifies a buffer (it is when [record~] is used instead).
Under Max5 [waveform~] is still refreshed.
The workaround is to send a "set bufferName" message to [waveform~].
I never used any visual link to xrecord~, and did not notice that.
but how did you get that version to run with 32 bit max 5 ?
it supports only x86_64 and arm64 .
maybe it is old original version in max 5 ?
by the way could you test it on M1 Mac ?
I just meant that with the old xrecord~ intel 32bits object from Thomas Grill, under Max5, the buffer displayed with [waveform~] is updated. Maybe some kind of nofication has been added in the meantime in the SDK…
I will test on M3Pro next week, I'm sorry I can't do it earlier.
BTW, although opening xsample's (modified) help file does work without a problem (by double clicking on the help file in the Finder), if I try to open a patch using xrecord~, the object won't instantiate.
To get rid of this problem, without having much time now to investigate further, I had to put a copy of xsample into C74/extensions/msp/
Anyway thanks again for the objects!
I actually duplicate xsample into 3 objects :
xgroove~
xplay~
xrecord~
and don't use object mappings file.
they get loaded without problems.

help file should be rewritten alltogether, it is still initial release
I finally had a chance to test (only) xrecord~ on a M3Pro. It did work with Max857 under latest MacOS.
xplay~ and xgroove~ seem to work too, but I had no time to use them extensively.
I also tried duplicating/renaming xrecord~ with Max857.
Under intel, macOS X.14, I also had to rename the executable inside the package.
Under arm, macOS 14.3, having xsample into a well formatted package (with the maping file into an init folder) did the job.
Thanks again for those objects.