Supervp.scrub~ - reset internal buffers not working

[srs]

I think there is an issue with the functionality of the ‘empty internal buffers’ feature of the supervp.scrub~ Max object.

Is it meant to completely empty the previous frames in the buffer so that when you send in new position data, there isn’t any audio from the previous buffer position that is still present and heard in the output sound?

Currently, after sending the reset message to the Max object - when I change the position input, there is still a small chunk of sound from the previous position that is heard, as though a single frame in the supervp buffer hasn’t been reset or emptied.

Can someone please advise if this is a bug or if there is another way to reset the buffer so that new position input always results in only audio from the new point in the source buffer being heard?

[srs]

Just updating this question in case I didn’t explain it clearly. The use case that is causing the problem is that I am using a note-on midi event as well as a midi cc value controlling the sample position of the supervp.scrub object. So a new note-on plays a sound taken from the sample position defined by the current cc input.

The issue is that the sound that is always played by a note-on is taken from the whatever the buffer position was when the last note-off was sent. I guess this is expected due to the nature of the window overlap but I would like to use the ‘reset’ message to empty the internal buffers so that a note-on event never plays any of the previously scrubbed material, it always starts from the new sample position defined by the current cc input.

Perhaps that ‘reset’ message isn’t the right approach but if so, is there another way to empty or reset the internal buffer of the supervp.scrub object?

[srs]

It’s clear that this sub-forum isn’t looked at that often (or at all) by any of the Ircam devs anymore but on the off chance someone sees it, I just wanted to ask again…

Is there a way to reset the [supervp.scrub~] buffer so that it is emptied and only plays whatever new sample position is given to it?

[srs]

If anyone else is using this feature of the supervp.scrub~ object, can you add your experience of it to this thread?

Resetting the internal buffer should result in a new position input playing only material from that new position but it currently does not work.

Does anyone else use this feature and does it work as you expect it to?

@schwarz I have tested this on the latest version of the supervp objects (v2.18.9 (2023-06)) and it is still occurring. Do you have any advice on this issue?

[srs]

Solution:

In case anyone else is dealing with this issue, the solution is to send the ‘reset’ message immediately after the new play position is sent to the supervp.scrub~ object (not before).

It seems like this message resets the internal buffer with audio from the current position so if it is sent before the new updated play position, it will play a chunk of audio from the previous position.

If you are using a gate event to trigger an envelope on the audio output, this is when you also have to send a ‘reset’ message (not the ‘note-off’ end of the previous envelope)

Unfortunately this produces a click when the buffer is reset so your audio output envelope has to have a slower attack to hide it, a [rampsmooth~ 20] seems to sort it out.

[srs]

Feature Request:

Hi @roebel @beller
If anyone is still working on updates to the supervp for max objects, it would be great if the reset message didn’t result in loud clicks when it is sent during playback.

Using a [rampsmooth~] or [adsr~] produces unwanted artefacts and doesn’t mask the clicks entirely.

I need to reset the buffer with new play position before the next scrub gesture is heard but using the reset message produced loud clicks.

[schwarz]

Hi srs, I’m not sure I understand your use case. When changing position, the last half synthesis window will fade out, if it is still playing. If it is not playing, could you not go to a silent part, or briefly switch to an empty buffer to clear it?
The reset message is definitely not meant for this, but for heavy internal reconfiguration of the engine.
Best!

[srs]

Ah ok, I thought that the reset message would perform the task of emptying the buffer so that there wasn’t a cross fade between windows.

The specific use case involves changing position without the cross fade. This is very important when it’s not a single scrubbing gesture but is instead two different and consecutive gestures at different positions in the buffer. Switching to an empty buffer and then re-loading the original audio might add a delay which isn’t ideal when performing the scrub gestures in a live recording context.

Using a reset message at the start of the next scrub gesture does sort of work but it produces small clicks which I guess is unavoidable.

Thanks for replying with this info. At least it’s good to know it’s not possible to do this currently so I’ll think about potential workarounds.

[schwarz]

@srs

Ah ok, I thought that the reset message would perform the task of emptying the buffer so that there wasn’t a cross fade between windows.

Probably that’s closer to the truth. The library API is not totally clear: reinitialize internal data to the state after the call to init. preserve all real time parameters. Anyway, that would explain the click. (Side note: in mubu.concat~, I could implement a message to clear the internal buffer with a fade out, to avoid clicks, but for supervp this would require changing the library.)

A possible strategy would be to switch between 2 supervp.scrub~ to start a new gesture with an empty internal buffer.

[srs]

The [adsr~] method seems to do the job if you trigger the buffer reset at the start of the new envelope used on the output of supervp.scrub (i.e. after the adsr fades to zero).