How do I load an msp patcher without rebuilding the complete dsp chain?
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?
Thanks in advance,
Mattijs
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.
Mattijs
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:
> 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.
ej
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.
Hi andrew, thanks for the summary.
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)
Mattijs
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.
>
> Good luck,
> Andrew B.
>
>
----------------------------------------------------
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
--
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
> 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
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,
> 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.
ej
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
Look at this thread...
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
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
>
----------------------------------------------------
I know but this is what we have now ;-)
All the best
Alessandro Fogar
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
>
--
Alessandro Fogar