anonymous

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.

audio-onoff-problem

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

https://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.

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.

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

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.
>
----------------------------------------------------


> it seems also from my investigations that there are no solutions,

> only workarounds, though i would be extremely grateful if somebody

But what is the difference between a solution and a workaround? Maybe 

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 

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


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.)

> 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)

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 

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 

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...

this is a relpy that refers to both this thread and also this one: 

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?

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)

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

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)

I think that the trick is: 'fade out/ DSP off / create object / DSP ON

> 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)

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

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
>
>
>

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...

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

> 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...

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
!

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
>
>
>
>
>

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~?

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.

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...

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.

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...

Quote: Stefan Tiedje wrote on Fri, 01 June 2007 11:16

> > 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.

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.
>

Audio On/Off problem