Audio On/Off problem


Anonymous

Anonymous
May 29, 2007 at 9:56pm

Hi Gary,

I have been having this same problem, and it seems (from my digging around for answers) that creating a new dsp object via scripting will always restart dsp. this in turn caused the click or audio dropout (and i have also seen it change the state of the ezdac~)

it seems also from my investigations that there are no solutions, only workarounds, though i would be extremely grateful if somebody told me i was wrong on this.

andrew

http://www.miscellanea.com

#32171
May 30, 2007 at 8:26am

You are right, the complete dsp chain is rebuilt every time you add an audio object and there is no way around it.

http://www.cycling74.com/forums/index.php?t=msg&goto=103277&rid=3579&S=9453c69ca813b2eb4a339217ad220a5e

The only thing I didn’t try yet is scripting inside vst~ but that feels bad from the start.

When you add a lot of objects, it might be advisable to turn off audio yourself with [adstatus switch] and back on after your scripting operations. Otherwise de dsp chain will be rebuilt after every single object you added.

If you can isolate a reproducable situation where some objects do and others don’t work I think you should post it here or mail to support.

Cheers,
Mattijs

Quote: Gary wrote on Tue, 29 May 2007 23:56
—————————————————-
> Can anybody help with the following problem?
> Occasionally when I dynamically create a new cycle~ object (using scripting) the audio turns ‘off’. Sometimes the audio even appears to be ‘on’ (the ezdac~ object being indented) when it is off. And other times some cycle~ objects fail to work at all even when others created at the same time are working. Has anybody ever had similar audio on/off problems? …and what was the cause/solution?
>
> I can post the patch on here but it is a bit hairy so will take some time to create a simplified version that retains this bizarre problem. Meanwhile, if anybody has had similar experiences and has any solutions/suggestions I’d be glad to here from you.
>
> Thanks,
>
> Gary.
>
—————————————————-

#105354
May 30, 2007 at 6:22pm

Andrew schrieb:
> it seems also from my investigations that there are no solutions,
> only workarounds, though i would be extremely grateful if somebody
> told me i was wrong on this.

Sorry, can’t be grateful…
But what is the difference between a solution and a workaround? Maybe
just aesthetics?
There is only one audio object even I need to be able to script without
restarting and that’s buffer~ and it is keeping audio flawlessly
running, it has no audio connections…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#105355
May 31, 2007 at 2:30am

as this issue has been popping up on the forums for some years, i would think that a solution is differentiated from a work around when someone is able to say “yes, you can dynamically create and delete dsp objects, without interrupting or restarting the dsp chain if you do x,y,z” (the workarounds i have seen differ both conceptually, functionally and yes (and not to be so easily dismissed) aesthetically.)

andrew

http://www.miscellanea.com

#105356
May 31, 2007 at 7:03am

Andrew schrieb:
> as this issue has been popping up on the forums for some years, i
> would think that a solution is differentiated from a work around when
> someone is able to say “yes, you can dynamically create and delete
> dsp objects, without interrupting or restarting the dsp chain if you
> do x,y,z” (the workarounds i have seen differ both conceptually,
> functionally and yes (and not to be so easily dismissed)
> aesthetically.)

For me a solution is something I can use myself to achieve what I want
to do. The main reason to use Max is to be able to find solutions and
not being dependent on others (software company) to deliver a solution.
True, there are things left to do from the software company side, but if
I find a way to achieve what I want to do, I have a solution. In this
regard any workaround is a solution and is fine…
As Max is a programming environment, I can encapsulate my workaround and
don’t need to think about it too much later, which pleases my sense for
aesthetics…

The one DSP language which is able to dynamically change things on the
fly is Chuck. There is even a Max external you can use.
This is no solution for me, as I am faster to create “workarounds” than
learning chuck…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#105357
Jun 1, 2007 at 5:03am

this is a relpy that refers to both this thread and also this one: http://www.cycling74.com/forums/index.php?t=msg&goto=103277&rid=3579&S=9453c69ca813b2eb4a339217ad220a5e

i just wanted to clarify some aspects of the vst~ solution / workaround.

am i correct in my understanding that if i create a vst plugin that deals with all of the dsp functionality of an abstraction that i am ‘creating’ or loading dynamically through scripting, then the dsp chain will not be rebuilt? vst~ is then unique (as a dsp object) in that you can create and delete abstractions containing it without rebuilding the dsp chain?

or

does this approach require everything to happen inside the vst, in that the vst is actually taking the place of the whole abstraction?

i am also interested in Mattijs’s comment that “…scripting inside vst~ … feels bad from the start”, and why this may be so.

(i have a feeling that there is a critical aspect of this approach that i may have missed)

andrew

#105358
Jun 1, 2007 at 6:46am

ok,

i think i see now.. after some experimenting it would appear that i was wrong on both counts in that you can dynamically load and reload vst plugins into an *already existing* vst~ object without breaking the dsp render, you *cannot*, however, create a new vst~ object and expect the same results… i think the tree i am barking up is now the right one…

(after a brief moment of excitement it looks like its back to the old ‘fade out/ create object/ fade in’ trick)

andrew

#105359
Jun 1, 2007 at 6:59am

Hi,

I think that the trick is: ‘fade out/ DSP off / create object / DSP ON
/ fade in’

But for me it’s not acceptable.

All the best

Alessandro Fogar

2007/6/1, Andrew :
>
> ok,
>
> i think i see now.. after some experimenting it would appear that i was wrong on both counts in that you can dynamically load and reload vst plugins into an *already existing* vst~ object without breaking the dsp render, you *cannot*, however, create a new vst~ object and expect the same results… i think the tree i am barking up is now the right one…
>
> (after a brief moment of excitement it looks like its back to the old ‘fade out/ create object/ fade in’ trick)
>
>
> andrew
>
>
>


Alessandro Fogar

http://www.fogar.it

#105360
Jun 1, 2007 at 7:14am

yes, thats the trick ;)

and yes, it detracts somewhat from what i am trying to accomplish (which puts it firmly in the workaround, rather than solution basket) which means i am still trying to decide if it is acceptable for my needs or not…

andrew

#105361
Jun 1, 2007 at 7:34am

Andrew,

for me it’s not, for these kind of things, I’m using Supercollider
(still using Max/Msp for other works), but it’s a very different beast
!

All the best

Alessandro Fogar

2007/6/1, Andrew :
>
> yes, thats the trick ;)
>
> and yes, it detracts somewhat from what i am trying to accomplish (which puts it firmly in the workaround, rather than solution basket) which means i am still trying to decide if it is acceptable for my needs or not…
>
> andrew
>
>
>
>
>


Alessandro Fogar

http://www.fogar.it

#105362
Jun 1, 2007 at 8:20am

Quote: miscellanea wrote on Fri, 01 June 2007 07:03
—————————————————-

>
> i am also interested in Mattijs’s comment that “…scripting inside vst~ … feels bad from the start”, and why this may be so.
>
> (i have a feeling that there is a critical aspect of this approach that i may have missed)
>

With scripting inside a vst~ i don’t mean loading a new vst plugin into a vst~ object. I meant making a vst plugin in which you create new objects with script depending on an input parameter. And then loading that vst plugin into vst~ of course.

If someone feels like trying this I am curious what the results are. Will max crash? Will it simply not work? If it works, is the entire dsp chain rebuilt or only the chain inside vst~?

Mattijs

#105363
Jun 1, 2007 at 9:16am

Mattijs Kneppers schrieb:
> With scripting inside a vst~ i don’t mean loading a new vst plugin
> into a vst~ object. I meant making a vst plugin in which you create
> new objects with script depending on an input parameter. And then
> loading that vst plugin into vst~ of course.

The DSP chain within the vst~ would need to rebuild as well.

I think you should always be able to get around with poly~’s/pluggo’s
within vst~. Just avoid scripting at all. Though in small patches it
might work somehow, as the interuption is eventually short enough to be
unrecognizable. But its kind of ugly and might lead to other problems…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#105364
Jun 1, 2007 at 9:21am

Quote: Stefan Tiedje wrote on Fri, 01 June 2007 11:16
—————————————————-
> Mattijs Kneppers schrieb:
> > With scripting inside a vst~ i don’t mean loading a new vst plugin
> > into a vst~ object. I meant making a vst plugin in which you create
> > new objects with script depending on an input parameter. And then
> > loading that vst plugin into vst~ of course.
>
> The DSP chain within the vst~ would need to rebuild as well.
>

Yeah but if it would be only the dsp chain inside vst~ that would much less of a problem than the complete dsp chain of my monster dsp patch.

Mattijs

#105365

You must be logged in to reply to this topic.