< Back to IRCAM Forum

Supervp for max and sample rate

SuperVP for Max
#1

Dear all,

I’ve noticed that many objects from the supervp for max collection (at least supervp.play~, supervp.scrub~ and supervp.sfplay~) present a bug when loading a soundfile with a different sample rate as the actual one, since they don’t seem to compensate this always at first loading (supervp.play~ does that “from time to time”, supervp.scrub~ never compensate the sample rate at startup). This can be corrected after loading by switching the “transpose on/off” setting to “off” and then back to “on”, however I did not find a way to automate this so that the speed is correct when loading the patch.

On top of that, supervp.play~ and supervp.scrub~ throw out the following message in the console:
“svp buffer sample rate change: 0.000000 -> 0.000000”

Is there a reliable way to avoid this?

Best

Alexis

#2

Dear Alexis,

I am encountering the same issue, although I’m getting a supervp.play~ error message like this “supervp.play~: buffer sample rate change: 48000 -> 44100.”

The transpose off/on trick you mention will work but not programmatically. For instance, if I use a trigger to send “transpose off/on” before or after setting the buffer and then triggering buffer playback it still plays the buffer at the incorrect sample rate. But if I do it with some delay, it will play at the correct sample rate.

Did you ever find a workaround to this issue?

Do any SuperVP developers have suggestions on working with supervp.play~ and using sounds that have different sample rates?

Chris

#3

Hi all, there’s nothing worse than an occasionally reproducible bug. I had it once with audio from mubu when switching buffers, but am not able to get it again.
What are your steps to reproduce it most likely?
(And btw, the buffer sample rate change message is for info and not an error, otherwise it would be red.)
Cheers.

#4

Hi Diemo,

well, meanwhile (in december) Supervp 2.18.5 has been released. The weird message "svp buffer sample rate change: 0.000000 -> 0.000000” is gone, and as far as I can tell, the objects seem much more stable regarding sample rate mismatch than the previous version from 2016. I had once one problem while using it, in the other direction (a 44.1k file was played too low at a Max sample rate from 48k), but I suspect Max itself to be guilty.

I just try the previous version from 2016 to try to reproduce it, noticed the same bug immediately, but again was not able to isolate a way to reproduce it with 100% probability. But again, it seems to be history, so if it ain’t broken (any more) don’t fix it.

Alexis

1 Like
#5

Hi Diemo,

Thanks for checking in on this question. I am not getting the same "svp buffer sample rate change: 0.000000 -> 0.000000” message as Alexis.

What I am hearing is supervp.play~ playing back sounds with different sampling rates incorrectly (or at incorrect speeds). I’ve put together a portion of a patch where I am hearing the problem, and you can download it in the Drive folder below. There is a supervp.play~ patch as well as three sounds with different sample rates. The sounds are all the same D4 pitch, but when I alternate playing back the three buffers with the messages in the patch, I get inconsistent results. For instance try pressing message 1 and then alternating between message 3 and 5.

https://drive.google.com/drive/folders/1Pv204uik1v79ns2TBA0bZUkyaJBKUV6E?usp=sharing

It’s entirely possible that I am doing something wrong on my end. But hopefully this might reproduce the problem I am experiencing.

Thanks,
Chris

#6

Hi Chris, thanks for the perfectly clear bug report and example patch.
It allowed me to reproduce and fix the problem of changing buffer sr.
On the go, I also implemented that supervp.sfplay~ resamples the input file.
New release to come soon.
Best,
Diemo

1 Like
#7

Excellent! Glad it was helpful and I look forward to the new release. Thank you!