groove~ shortest loop precision

Jan 5, 2014 at 1:10pm

groove~ shortest loop precision

Hey everyone,

Whenever I want to reduce the loop duration under 5ms, it sounds like if the loop duration was following a “staircase function”, rather than sweeping naturally.

I thought it would be due to sample quality limitations, but even using 32bit float mode and high quality samples, it still sounds that way.

Any ideas on to get a sweeter sound?

Lucas

#277485
Jan 5, 2014 at 6:37pm

Please show us the code for a small example

Cheers

-A

#277495
Jan 5, 2014 at 6:46pm

it sounds like if the loop duration was following a “staircase function”, rather than sweeping naturally.

I’m not 100% sure I know what you mean about sweeping—I’m guessing you are modulating the loop duration?

From doing a quick experiment, it appears as though the loop points are sample accurate (vs having precision based on signal vector size). Since the loop point inlets for groove~ are set in milliseconds, I’m guessing that you are not changing the loop point with enough precision. For example: at a sampling rate of 44.1KHz, the difference between a loop point of 5ms and 4.9ms is about 4 samples. For larger loop lengths, you might not notice this, but you will at loop points of the size you are speaking of.

If you post an example patch showing how you are setting the loop points, I could give a better answer (perhaps it is not groove~ but the way you are driving those inlets).

#277496
Jan 6, 2014 at 12:09am

I don’t need to show you any patch because I even have the same issue with [groove~] help file.
For example, if I drecrease loop duration, sound doesn’t change between 0.9977 and 0.9751 and then doesn’t change until 0.9522, etc.
I have the same problem even with 96000Hz file. I also tried to modulate with signal using [line~] but the problem remains

#277506
Jan 6, 2014 at 7:26am

I tried something different, by modulating the loop duration directly in samples unit. Thing is, even loading a 96KHz file, if I try to create for instance a 10 samples loop, the duration sounds the same as when I load a 44.1KHz file.

Any ideas?

#277524
Jan 6, 2014 at 8:02am

It does not depend on the samplerate of the file, but on the samplerate set in dsp settings.

#277530
Jan 6, 2014 at 8:25am

Well I just tried to change the DSP settings as well as my sound cards settings, and nothing changes :(

Actually I’m trying to make a sort of beat-repeater like iZotope Stutter Edit.
In Stutter Edit, some extremely short manipulation under 1ms are perfectly handled without any problem, even when I run it in 44.1KHz…

#277531
Jan 6, 2014 at 8:27am

Often if we can get a patch we can suggest a workaround if we find a problem and we can see what you are trying to do.

As it is with your description so far, I’m not able to see what it is you are talking about. Maybe some steps and and indication of the type of sound file you are using? Does groove~ interp make any difference? Do you get the same problem with wave~ or play~?

I’m not trying to be difficult, it’s just that we are actively working on things for the future of Max and I am very interested in the way people use groove~

Cheers

-A

#277532
Jan 6, 2014 at 8:48am
– Pasted Max Patch, click to expand. –

Try to modulate loop duration.
I didn’t tried wave~ so far. play~ does not have loop function, does it?

#277533
Jan 6, 2014 at 8:51am

Sorry it seems my code doesn’t load from clipboad.
Here is the patch

Attachments:
  1. shortloop.maxpat
#277534
Jan 6, 2014 at 8:53am

sound doesn’t change between 0.9977 and 0.9751 and then doesn’t change until 0.9522, etc.

As I said in my other post, look at what the ms-to-sample conversion is for those values. At 44.1KHz, 0.9977 and 0.9751 are both convert to factional sample values between 43 and 44 samples. 0.9522 is a fractional value between 42 and 43 samples.

Often if we can get a patch we can suggest a workaround if we find a problem and we can see what you are trying to do.

I’m not trying to be difficult, it’s just that we are actively working on things for the future of Max and I am very interested in the way people use groove~

I second this notion. Some issues raised to the Cycling ’74 developers are hard for them to address because—like every company—they have finite time and human resources. If you have an opportunity to give a developer patch that could give them an idea to code more stuff for Max to help you, I’d jump on that opportunity :D

I don’t know the internal workings of groove~, but I’m guessing that intersample loop points are not possible both from my experiments with the object and from a developer perspective I can see that not being a feature at least with the initial implementation written many years ago due to processing power stuff. This does sound like the sort of thing Andrew and others are looking to update.

Do you get the same problem with wave~ or play~?

I’m guessing with the current implementation of groove~, you may have better luck with what you are trying to achieve with these objects.

In Stutter Edit, some extremely short manipulation under 1ms are perfectly handled without any problem,

I did quickly try to look at StutterEdit, but couldn’t figure things out fast enough to give an real answer. When you say “handled perfectly” I’m guessing there is some interpolation magic going on to deal with intersample loop points. This is not necessarily a sign that groove~ is doing it wrong, but that this was an anticipated problem that was addressed in this complete plugin. I’m certainly not trying to discourage you: if you give us a patch, we might be able to offer feedback of solutions with other objects and, as Andrew says, you may get a chance to contribute ideas to the new version of groove~!

#277536
Jan 6, 2014 at 9:01am

Thank you for your answer Roth^^ I posted a patch.
I will try later today to experiment with wave~

#277540
Jan 6, 2014 at 9:47am

Thank you for your answer Roth^^ I posted a patch.

Cool. I see that and will take a look later. Sometimes my verbose posts take a while to compose and are a little late by the time I submit it ;)

#277547
Jan 6, 2014 at 11:02am

i have never tried it, but if i would have to guess i would also think that groove simply does not interpolate.

you can test that easily by converting milliseconds (float) to samples (float) aside from the groove object.

given that 0.975 milliseconds or 44 samples represents a beat of 1/64 notes at 1885 BPM – or a frequency of 1005 Hz –, so i would like to point out that the groove objects is not meant to be used as an oscillator.

-110

#277554

You must be logged in to reply to this topic.