< Back to IRCAM Forum

supervp.play and dac

Forumnet Legacy general discussion
#1

By any chance does the supervp.play object internally reinitialize the audio system?

I’m trying to build a modified version of the example SuperVP.Play patcher that integrates into my existing environment. I’ve tried two different mechanisms

  1. Connect it to a [dac~] rather than using the ezdac stuff and configured channels in the patcher.

  2. Connect it to one of my own abstractions [StereoOut~] which essentially routes the audio via send~/receive~ into the mixer of my existing environment.

I’ve noted that in both cases, even if audio is already enabled, i.e. I am able to play sound through my other patcher, I have to turn off audio through the DSP Status and turn it on again to get supervp.play to work.

#2

I have never had this issue (and I use SuperVP.Play in several pieces). Are you copy-pasting the help patch? Note that in the help patch there are loadbangs that modify the DSP stuff that you might want to remove.

Otherwise, your strange behavior might be related to how the buffers are set for SuperVP.play object?!

#3

Thanks for responding — one of my examples is certainly derived from the help patch although I removed the ezdac and all the initialization stuff.

Essentially, I’m working to replace the barely supported [elasticx~] object with supervp. The [elasticx~] also uses buffers and I haven’t had a problem like the one I’m describing here. I’m certain that the buffer is getting loaded properly but it just seems that something in that patcher things that audio is just not “on”, even though DSP Status is “on” and the other main patcher that I’m running continues to generate sound.

#4

I’ve discovered that this behavior is 100% reproducible. if I open the example object via pcontrol from my main patcher, I have to toggle DSP status. If I open the same object directly from File Open, then it works without my having to toggle DSP status.