Mattijs

Hi everyone, I could need some help with this one.

I'm working on a modular effects stack. This means I need to load msp patchers during runtime.

The problem is that when I create an abstraction with script, the whole dsp chain is rebuilt. If I load 10 msp abstrations with script, the dsp chain will be rebuilt 10 times. I'm running a big dsp patch simultaneously, so a rebuild could take 200ms, for example. This would amount to 2 seconds of clickery noise when loading a new stack of effects.

My question: is there way to load an abstraction without rebuilding the dsp chain?

I've been trying several things (creating abstractions inside a poly~, disabling dsp before creating the 10 patchers, etc) but so far every approach ended in crashes or other problems.

Is there someone out there that had this problem and found a solution?

how-do-i-load-an-msp-patcher-without-rebuilding-the-complete-dsp-chain

adsr~ would be a good solution for muting/unmuting. However there are some basic problems with creating patches with script inside a poly~.

Please see my previous post for an example patch.

In this example it appears that creating a subpatcher inside a poly~ even while the poly~ is disabled, updates the whole dsp chain. To test this, try my example while a big msp patch is running.

Quote: Emmanuel Jourdan wrote on Wed, 02 May 2007 14:29

----------------------------------------------------

> Since 4.5, I would recommend using adsr~ for the muting/unmuting 

> part. It's really convenient because it allows you to make the fadein/ 

> fadeout and it sends the mute messages at the right time for thispoly~.

adsr~ would be a good solution for muting/unmuting. However there are some basic problems with creating patches with script inside a poly~. 

In this example it appears that creating a subpatcher inside a poly~ even while the poly~ is disabled, updates the whole dsp chain. To test this, try my example while a big msp patch is running. 

Quote: Emmanuel Jourdan wrote on Wed, 02 May 2007 14:29
----------------------------------------------------

> Since 4.5, I would recommend using adsr~ for the muting/unmuting  
> part. It's really convenient because it allows you to make the fadein/ 
> fadeout and it sends the mute messages at the right time for thispoly~.
>
> ej
>
----------------------------------------------------


On 2 mai 07, at 14:56, Mattijs Kneppers wrote:

> adsr~ would be a good solution for muting/unmuting. However there 

> are some basic problems with creating patches with script inside a 

> Please see my previous post for an example patch.

> In this example it appears that creating a subpatcher inside a 

> poly~ even while the poly~ is disabled, updates the whole dsp 

> chain. To test this, try my example while a big msp patch is running.

Scripting msp object while the dsp is on is not a good idea. Each 

time you add/remove a dsp object, the dsp chain have to be recompiled 

(which causes clicks). As far as I remember, the only option for 

dynamic dsp process is to use the vst~ object. I never done that 

though, I usually prefer to put everything in poly~ objects and then 

use the mute/unmute mechanism in order to get something dynamic.

> Thanks EJ,
>
> adsr~ would be a good solution for muting/unmuting. However there  
> are some basic problems with creating patches with script inside a  
> poly~.
>
> Please see my previous post for an example patch.
>
> In this example it appears that creating a subpatcher inside a  
> poly~ even while the poly~ is disabled, updates the whole dsp  
> chain. To test this, try my example while a big msp patch is running.

Scripting msp object while the dsp is on is not a good idea. Each  
time you add/remove a dsp object, the dsp chain have to be recompiled  
(which causes clicks). As far as I remember, the only option for  
dynamic dsp process is to use the vst~ object. I never done that  
though, I usually prefer to put everything in poly~ objects and then  
use the mute/unmute mechanism in order to get something dynamic.

While it is true that your patch must have all of the DSP objects in 

place at startup, they don't have to be running and using CPU. The way 

that most people do things like this is to create a poly~ object for 

each module that can be muted or unmuted as needed, and then use matrix~ 

to do the routing. You might also look into some clever use of bpatcher 

If you really need to be able to script dynamic DSP chains, and 

poly~/matrix~ doesn't serve your needs, I might suggest SuperCollider, 

which can be routed to/from MaxMSP using Soundflower and controlled with 

OSC messages. I think it is one of the many languages Brad Garton uses 

in the clever article he posted on the C74 website.

While it is true that your patch must have all of the DSP objects in 
place at startup, they don't have to be running and using CPU.  The way 
that most people do things like this is to create a poly~ object for 
each module that can be muted or unmuted as needed, and then use matrix~ 
to do the routing.  You might also look into some clever use of bpatcher 
if your aim is to reduce visual clutter.

If you really need to be able to script dynamic DSP chains, and 
poly~/matrix~ doesn't serve your needs, I might suggest SuperCollider, 
which can be routed to/from MaxMSP using Soundflower and controlled with 
OSC messages.  I think it is one of the many languages Brad Garton uses 
in the clever article he posted on the C74 website.

I was actually hoping that it wouldn't be necessary to load all patches prior to using them. We plan to have an increasing amount of plugins made by a seperate team of developers. Typically only a few of the many plugins would be used simultaneously.

To load all of them would be highly redundant and over time would cost too much loading time.

Also, we want users to be able to use multiple instances of the same plugin. To facilitate this, we'd have to load every plugin many times. This would increase loading times even more.

Working with other systems outside max has proven to decrease stability and general reliability, but I'll consider the options, thanks for the tip. Btw soundflowerbed still has the latency problem mentioned earlier (

https://cycling74.com/forums/index.php?t=msg&goto=86352&rid=3579&S=2d8f90c1e3f6e4c6e63f92a6aa4af826)

P.S., disabling dsp once, then loading all the plugins, then enabling dsp would still be a workable compromis. The only problem is that this doesn't work when max isn't focused. If you could somehow get that fixed I'd be saved.

Quote: andrewb@cycling74.com wrote on Wed, 02 May 2007 17:34

> While it is true that your patch must have all of the DSP objects in 

> place at startup, they don't have to be running and using CPU. The way 

> that most people do things like this is to create a poly~ object for 

> each module that can be muted or unmuted as needed, and then use matrix~ 

> to do the routing. You might also look into some clever use of bpatcher 

> if your aim is to reduce visual clutter.

> If you really need to be able to script dynamic DSP chains, and 

> poly~/matrix~ doesn't serve your needs, I might suggest SuperCollider, 

> which can be routed to/from MaxMSP using Soundflower and controlled with 

> OSC messages. I think it is one of the many languages Brad Garton uses 

> in the clever article he posted on the C74 website.

I was actually hoping that it wouldn't be necessary to load all patches prior to using them. We plan to have an increasing amount of plugins made by a seperate team of developers. Typically only a few of the many plugins would be used simultaneously. 

To load all of them would be highly redundant and over time would cost too much loading time. 

Working with other systems outside max has proven to decrease stability and general reliability, but I'll consider the options, thanks for the tip. Btw soundflowerbed still has the latency problem mentioned earlier (https://cycling74.com/forums/index.php?t=msg&goto=86352&rid=3579&S=2d8f90c1e3f6e4c6e63f92a6aa4af826)

Quote: andrewb@cycling74.com wrote on Wed, 02 May 2007 17:34
----------------------------------------------------
> While it is true that your patch must have all of the DSP objects in 
> place at startup, they don't have to be running and using CPU.  The way 
> that most people do things like this is to create a poly~ object for 
> each module that can be muted or unmuted as needed, and then use matrix~ 
> to do the routing.  You might also look into some clever use of bpatcher 
> if your aim is to reduce visual clutter.
>
> If you really need to be able to script dynamic DSP chains, and 
> poly~/matrix~ doesn't serve your needs, I might suggest SuperCollider, 
> which can be routed to/from MaxMSP using Soundflower and controlled with 
> OSC messages.  I think it is one of the many languages Brad Garton uses 
> in the clever article he posted on the C74 website.
>
> Good luck,
> Andrew B.
>
>
----------------------------------------------------


> Then here is a request for a new feature: an object that allows to

> add new msp functionality without recompiling the complete dsp chain. 

> For now, I understand the only remaining option is vst~. If anyone

> knows of another option, I'd be very happy to know! Tons of people

> must have built modular fx stacks with max/msp, right?! ;)

I just made a patch with vst~'s which constantly reload. In a way your 

request is fullfilled with vst~. I can't imagine a better solution for 

that anyway. Just go for it, it will have the advantage that your 

modules are also available in your preferred DAW... And you can share 

Mattijs Kneppers schrieb:
> Then here is a request for a new feature: an object that allows to
> add new msp functionality without recompiling the complete dsp chain. 
>
> For now, I understand the only remaining option is vst~. If anyone
> knows of another option, I'd be very happy to know! Tons of people
> must have built modular fx stacks with max/msp, right?! ;)

I just made a patch with vst~'s which constantly reload. In a way your 
request is fullfilled with vst~. I can't imagine a better solution for 
that anyway. Just go for it, it will have the advantage that your 
modules are also available in your preferred DAW... And you can share 
them with your Maxless friends...

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


Quote: Stefan Tiedje wrote on Thu, 03 May 2007 11:03

> I just made a patch with vst~'s which constantly reload. In a way your 

> request is fullfilled with vst~. I can't imagine a better solution for 

> that anyway. Just go for it, it will have the advantage that your 

> modules are also available in your preferred DAW... And you can share 

True, I did something similar with vst~ too. But the extra translation layer is unnecessary for me. Also the development process gets unnecessarily complex. If cycling can make this functionality in vst~, I'd say it should be possible to make a comparable solution that works with abstractions. In fact I expected poly~ to do this.

Btw, I guess it wouldn't be possible to script-create new functionality inside a vst plugin, would it? Hmm, maybe I'll give that a try just to see what happens.

Quote: Stefan Tiedje wrote on Thu, 03 May 2007 11:03
----------------------------------------------------
> I just made a patch with vst~'s which constantly reload. In a way your 
> request is fullfilled with vst~. I can't imagine a better solution for 
> that anyway. Just go for it, it will have the advantage that your 
> modules are also available in your preferred DAW... And you can share 
> them with your Maxless friends...
>

On 3 mai 07, at 11:01, Stefan Tiedje wrote:

> Yeah, but wait at least one vector size till muting or use pass~. 

> At the moment the poly~ is muted it will cycle the last vector, 

> I don't know if adsr~ will wait or not, Emmanuel, do you know this???

As adsr~ send messages to thispoly~, it's not done in the perform 

> I just remember, that I came across these funny noises once in a 

via send~/receive~, isn't it? I can't remember having something like 

that since a long time, cos I use adsr~ a lot.

> Yeah, but wait at least one vector size till muting or use pass~.  
> At the moment the poly~ is muted it will cycle the last vector,  
> which can be a funny noise...
> I don't know if adsr~ will wait or not, Emmanuel, do you know this???

As adsr~ send messages to thispoly~, it's not done in the perform  
method so it's "defered" to the tick.

> I just remember, that I came across these funny noises once in a  
> while...

via send~/receive~, isn't it? I can't remember having something like  
that since a long time, cos I use adsr~ a lot.

I think, if I am right (I remember David Ziccarelli told something

about this), that, in the past, this behaviour was supported but for

If I remember an automatic and fast fadein/out was invoked in such cases.

Could perhaps mxj~ be useful in this case ?

> Quote: Stefan Tiedje wrote on Thu, 03 May 2007 11:03

> ----------------------------------------------------

> > I just made a patch with vst~'s which constantly reload. In a way your

> > request is fullfilled with vst~. I can't imagine a better solution for

> > that anyway. Just go for it, it will have the advantage that your

> > modules are also available in your preferred DAW... And you can share

> True, I did something similar with vst~ too. But the extra translation layer is unnecessary for me. Also the development process gets unnecessarily complex. If cycling can make this functionality in vst~, I'd say it should be possible to make a comparable solution that works with abstractions. In fact I expected poly~ to do this.

> Btw, I guess it wouldn't be possible to script-create new functionality inside a vst plugin, would it? Hmm, maybe I'll give that a try just to see what happens.

> Hard- and software for interactive audiovisual sampling

I think, if I am right (I remember David Ziccarelli told something
about this), that, in the past, this behaviour was supported but for
performance reasons this changed.

2007/5/3, Mattijs Kneppers :
>
> Quote: Stefan Tiedje wrote on Thu, 03 May 2007 11:03
> ----------------------------------------------------
> > I just made a patch with vst~'s which constantly reload. In a way your
> > request is fullfilled with vst~. I can't imagine a better solution for
> > that anyway. Just go for it, it will have the advantage that your
> > modules are also available in your preferred DAW... And you can share
> > them with your Maxless friends...
> >
>
> True, I did something similar with vst~ too. But the extra translation layer is unnecessary for me. Also the development process gets unnecessarily complex. If cycling can make this functionality in vst~, I'd say it should be possible to make a comparable solution that works with abstractions. In fact I expected poly~ to do this.
>
> Btw, I guess it wouldn't be possible to script-create new functionality inside a vst plugin, would it? Hmm, maybe I'll give that a try just to see what happens.
>
> Mattijs
> --
> SmadSteck - http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling
>

https://cycling74.com/forums/index.php?t=msg&goto=71133&rid=0&S=b01e0229b37d7fbe60bd5cc2c761cd48&srch=dynamic+patching#msg_71133

> I think, if I am right (I remember David Ziccarelli told something

> about this), that, in the past, this behaviour was supported but for

> If I remember an automatic and fast fadein/out was invoked in such cases.

> Could perhaps mxj~ be useful in this case ?

> > Quote: Stefan Tiedje wrote on Thu, 03 May 2007 11:03

> > ----------------------------------------------------

> > > I just made a patch with vst~'s which constantly reload. In a way your

> > > request is fullfilled with vst~. I can't imagine a better solution for

> > > that anyway. Just go for it, it will have the advantage that your

> > > modules are also available in your preferred DAW... And you can share

> > True, I did something similar with vst~ too. But the extra translation layer is unnecessary for me. Also the development process gets unnecessarily complex. If cycling can make this functionality in vst~, I'd say it should be possible to make a comparable solution that works with abstractions. In fact I expected poly~ to do this.

> > Btw, I guess it wouldn't be possible to script-create new functionality inside a vst plugin, would it? Hmm, maybe I'll give that a try just to see what happens.

> > Hard- and software for interactive audiovisual sampling

2007/5/3, Alessandro Fogar :
> Hi,
>
> I think, if I am right (I remember David Ziccarelli told something
> about this), that, in the past, this behaviour was supported but for
> performance reasons this changed.
>
> If I remember an automatic and fast fadein/out was invoked in such cases.
>
> I'd like to have this back !
>
> Could perhaps mxj~ be useful in this case ?
>
> All the best
>
> 2007/5/3, Mattijs Kneppers :
> >
> > Quote: Stefan Tiedje wrote on Thu, 03 May 2007 11:03
> > ----------------------------------------------------
> > > I just made a patch with vst~'s which constantly reload. In a way your
> > > request is fullfilled with vst~. I can't imagine a better solution for
> > > that anyway. Just go for it, it will have the advantage that your
> > > modules are also available in your preferred DAW... And you can share
> > > them with your Maxless friends...
> > >
> >
> > True, I did something similar with vst~ too. But the extra translation layer is unnecessary for me. Also the development process gets unnecessarily complex. If cycling can make this functionality in vst~, I'd say it should be possible to make a comparable solution that works with abstractions. In fact I expected poly~ to do this.
> >
> > Btw, I guess it wouldn't be possible to script-create new functionality inside a vst plugin, would it? Hmm, maybe I'll give that a try just to see what happens.
> >
> > Mattijs
> > --
> > SmadSteck - http://www.smadsteck.nl
> > Hard- and software for interactive audiovisual sampling
> >
>
>
> --
> Alessandro Fogar
>
> http://www.fogar.it
>

Sounds interesting, but making an object in mxj~ is different from loading an existing patch in a seperate dsp chain.

Quote: sfogar wrote on Thu, 03 May 2007 13:53

> > I think, if I am right (I remember David Ziccarelli told something

> > about this), that, in the past, this behaviour was supported but for

> > If I remember an automatic and fast fadein/out was invoked in such cases.

> > Could perhaps mxj~ be useful in this case ?

> > > Quote: Stefan Tiedje wrote on Thu, 03 May 2007 11:03

> > > ----------------------------------------------------

> > > > I just made a patch with vst~'s which constantly reload. In a way your

> > > > request is fullfilled with vst~. I can't imagine a better solution for

> > > > that anyway. Just go for it, it will have the advantage that your

> > > > modules are also available in your preferred DAW... And you can share

> > > > them with your Maxless friends...

> > > True, I did something similar with vst~ too. But the extra translation layer is unnecessary for me. Also the development process gets unnecessarily complex. If cycling can make this functionality in vst~, I'd say it should be possible to make a comparable solution that works with abstractions. In fact I expected poly~ to do this.

> > > Btw, I guess it wouldn't be possible to script-create new functionality inside a vst plugin, would it? Hmm, maybe I'll give that a try just to see what happens.

> > > Hard- and software for interactive audiovisual sampling

Quote: sfogar wrote on Thu, 03 May 2007 13:53
----------------------------------------------------
> Look at this thread...
>
> https://cycling74.com/forums/index.php?t=msg&goto=71133&rid=0&S=b01e0229b37d7fbe60bd5cc2c761cd48&srch=dynamic+patching#msg_71133
>
> All the best
>
> Alessandro Fogar
>
> 2007/5/3, Alessandro Fogar :
> > Hi,
> >
> > I think, if I am right (I remember David Ziccarelli told something
> > about this), that, in the past, this behaviour was supported but for
> > performance reasons this changed.
> >
> > If I remember an automatic and fast fadein/out was invoked in such cases.
> >
> > I'd like to have this back !
> >
> > Could perhaps mxj~ be useful in this case ?
> >
> > All the best
> >
> > 2007/5/3, Mattijs Kneppers :
> > >
> > > Quote: Stefan Tiedje wrote on Thu, 03 May 2007 11:03
> > > ----------------------------------------------------
> > > > I just made a patch with vst~'s which constantly reload. In a way your
> > > > request is fullfilled with vst~. I can't imagine a better solution for
> > > > that anyway. Just go for it, it will have the advantage that your
> > > > modules are also available in your preferred DAW... And you can share
> > > > them with your Maxless friends...
> > > >
> > >
> > > True, I did something similar with vst~ too. But the extra translation layer is unnecessary for me. Also the development process gets unnecessarily complex. If cycling can make this functionality in vst~, I'd say it should be possible to make a comparable solution that works with abstractions. In fact I expected poly~ to do this.
> > >
> > > Btw, I guess it wouldn't be possible to script-create new functionality inside a vst plugin, would it? Hmm, maybe I'll give that a try just to see what happens.
> > >
> > > Mattijs
> > > --
> > > SmadSteck - http://www.smadsteck.nl
> > > Hard- and software for interactive audiovisual sampling
> > >
> >
> >
> > --
> > Alessandro Fogar
> >
> > http://www.fogar.it
> >
>
>
> -- 
> Alessandro Fogar
>
> http://www.fogar.it
>
----------------------------------------------------


> Sounds interesting, but making an object in mxj~ is different from loading an existing patch in a seperate dsp chain.

> Quote: sfogar wrote on Thu, 03 May 2007 13:53

> > > I think, if I am right (I remember David Ziccarelli told something

> > > about this), that, in the past, this behaviour was supported but for

> > > If I remember an automatic and fast fadein/out was invoked in such cases.

> > > Could perhaps mxj~ be useful in this case ?

> > > > Quote: Stefan Tiedje wrote on Thu, 03 May 2007 11:03

> > > > ----------------------------------------------------

> > > > > I just made a patch with vst~'s which constantly reload. In a way your

> > > > > request is fullfilled with vst~. I can't imagine a better solution for

> > > > > that anyway. Just go for it, it will have the advantage that your

> > > > > modules are also available in your preferred DAW... And you can share

> > > > > them with your Maxless friends...

> > > > True, I did something similar with vst~ too. But the extra translation layer is unnecessary for me. Also the development process gets unnecessarily complex. If cycling can make this functionality in vst~, I'd say it should be possible to make a comparable solution that works with abstractions. In fact I expected poly~ to do this.

> > > > Btw, I guess it wouldn't be possible to script-create new functionality inside a vst plugin, would it? Hmm, maybe I'll give that a try just to see what happens.

2007/5/3, Mattijs Kneppers :
>
> Sounds interesting, but making an object in mxj~ is different from loading an existing patch in a seperate dsp chain.
>
> Mattijs
>
> Quote: sfogar wrote on Thu, 03 May 2007 13:53
> ----------------------------------------------------
> > Look at this thread...
> >
> > https://cycling74.com/forums/index.php?t=msg&goto=71133&rid=0&S=b01e0229b37d7fbe60bd5cc2c761cd48&srch=dynamic+patching#msg_71133
> >
> > All the best
> >
> > Alessandro Fogar
> >
> > 2007/5/3, Alessandro Fogar :
> > > Hi,
> > >
> > > I think, if I am right (I remember David Ziccarelli told something
> > > about this), that, in the past, this behaviour was supported but for
> > > performance reasons this changed.
> > >
> > > If I remember an automatic and fast fadein/out was invoked in such cases.
> > >
> > > I'd like to have this back !
> > >
> > > Could perhaps mxj~ be useful in this case ?
> > >
> > > All the best
> > >
> > > 2007/5/3, Mattijs Kneppers :
> > > >
> > > > Quote: Stefan Tiedje wrote on Thu, 03 May 2007 11:03
> > > > ----------------------------------------------------
> > > > > I just made a patch with vst~'s which constantly reload. In a way your
> > > > > request is fullfilled with vst~. I can't imagine a better solution for
> > > > > that anyway. Just go for it, it will have the advantage that your
> > > > > modules are also available in your preferred DAW... And you can share
> > > > > them with your Maxless friends...
> > > > >
> > > >
> > > > True, I did something similar with vst~ too. But the extra translation layer is unnecessary for me. Also the development process gets unnecessarily complex. If cycling can make this functionality in vst~, I'd say it should be possible to make a comparable solution that works with abstractions. In fact I expected poly~ to do this.
> > > >
> > > > Btw, I guess it wouldn't be possible to script-create new functionality inside a vst plugin, would it? Hmm, maybe I'll give that a try just to see what happens.
> > > >
> > > > Mattijs
> > > > --
> > > > SmadSteck - http://www.smadsteck.nl
> > > > Hard- and software for interactive audiovisual sampling
> > > >
> > >
> > >
> > > --
> > > Alessandro Fogar
> > >
> > > http://www.fogar.it
> > >
> >
> >
> > --
> > Alessandro Fogar
> >
> > http://www.fogar.it
> >
> ----------------------------------------------------
>
>
> --
> SmadSteck - http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling
>

How do I load an msp patcher without rebuilding the complete dsp chain?