dropdown menu opens patch
Hi,
I'm trying to make a 'FX selector' patch that allows the user to select from
a drop-down menu of effects (which are themselves patches). I would rather
not instantiate every effect in the list, better would be to create the
effect you select and destroy an effect when you de-select it.
I'm not sure what the best way to do this is. What say y'all?
Regards,
George
hmm, would scripting be the best way to do this? I'm just looking over the
tutorials again....
On 5/21/07, George Locke wrote:
>
> Hi,
>
> I'm trying to make a 'FX selector' patch that allows the user to select
> from a drop-down menu of effects (which are themselves patches). I would
> rather not instantiate every effect in the list, better would be to create
> the effect you select and destroy an effect when you de-select it.
>
> I'm not sure what the best way to do this is. What say y'all?
>
> Regards,
> George
>
either that or pcontrol to open up a patcher.
On May 21, 2007, at 3:09 PM, George Locke wrote:
> hmm, would scripting be the best way to do this? I'm just looking
> over the tutorials again....
>
> On 5/21/07, George Locke < george.locke.maxmsp@gmail.com> wrote:
> Hi,
>
> I'm trying to make a 'FX selector' patch that allows the user to
> select from a drop-down menu of effects (which are themselves
> patches). I would rather not instantiate every effect in the list,
> better would be to create the effect you select and destroy an
> effect when you de-select it.
>
> I'm not sure what the best way to do this is. What say y'all?
>
> Regards,
> George
>
v a d e //
www.vade.info
abstrakt.vade.info
If you're dealing with MSP patches, creating/destroying in real time will create pops/clicks in your DSP chain. May need to look at Mute or [Poly~] or other solutions.
it is a matter of taste, buti also use poly~.
all possible effects would be cconnectied already and the
menu only chooses which poly~ is turned on.
i usually combine it with bpatcher offsets for parameter access.
i'm confused about how to put several different patches into a poly~....
On 5/21/07, Roman Thilenius wrote:
>
>
>
> it is a matter of taste, buti also use poly~.
>
> all possible effects would be cconnectied already and the
> menu only chooses which poly~ is turned on.
>
> i usually combine it with bpatcher offsets for parameter access.
>
> --
> http://vst-mac.info/
>
i use [mute~]
very satisfied
be sure to use [pass~] ala [mute~] help
George Locke schrieb:
> I'm trying to make a 'FX selector' patch that allows the user to
> select from a drop-down menu of effects (which are themselves
> patches). I would rather not instantiate every effect in the list,
> better would be to create the effect you select and destroy an effect
> when you de-select it.
>
> I'm not sure what the best way to do this is. What say y'all?
You can turn each of your FX patches into a pluggo and then load them
into a vst~ object. This has three advantages:
It won't interrupt the DSP chain, you only need to load one FX, and you
can easily incorporate any vst, not only your own effects...
George Locke schrieb:
> i'm confused about how to put several different patches into a
> poly~....
He suggests to put each into its own 1-voice poly~, but then you'd need
to load all of them what you didn't want...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
I have built a system that allows you to build a stack of FX and change each one. As i'm only working in Max (no vst), switching audio FX does indeed require the DSP chain to be rebuilt - but the system wasn't designed to do this real-time, it just allows you to build the chain and save one particular setup with parameters.
The way I built it isn't too complicated: I select the FX from an ubumenu which populates from a dir. An FX abstraction and an interface bpatcher (separate, useful when multivoicing the entire thing) are then loaded by scripting to a thispatcher (the old ones are deleted as well). I communicate by send/receive with patcherargs though the various FX.
Stefan Tiedje's solution would be better, but i'm not into VST's, and I don't really need the realtime swapping of FX, just fast swapping is ok.
i like the pluggo idea a lot, it seems to handle the problem very nicely!
I'll try that and report back if i hit a snag.
Meanwhile, maybe you can help me with my max programming
technique/planning. One of the main reasons i watned to avoid instantiating
every effect is that, as far as i can tell, this makes switching between
them loads more complicated and it also makes adding new effects much
harder. Let me show you the beginnings of the patch that i was building
with this scheme (you'll see it's not finished but i think i make the point
clear).
In this patch, there are gate~ objects that send the input to the
appropriate effect, and a sub-patcher that activates the effect that's
active and whenever a new effect is selected the same subpatcher deactivates
all the other effects. I can see now that if i just remember which effect
was previously active then i can route the active/inactive messages in a
more automated fashion, but that would still means having at least 3 gate
objects that would have to connected to every effect, which means a lot of
annoying connect-the-dots with the patch cables. it'd be very annoying to
have like 20 effects, and adding 5 more would be even more aggravation.
If you can think of a better way to do this, other than having a bunch of
gates and what not, then please let me know, this is one part of max
logistics that i haven't figured out very well.
On 5/23/07, Bas van der Graaff wrote:
>
>
> I have built a system that allows you to build a stack of FX and change
> each one. As i'm only working in Max (no vst), switching audio FX does
> indeed require the DSP chain to be rebuilt - but the system wasn't designed
> to do this real-time, it just allows you to build the chain and save one
> particular setup with parameters.
>
> The way I built it isn't too complicated: I select the FX from an ubumenu
> which populates from a dir. An FX abstraction and an interface bpatcher
> (separate, useful when multivoicing the entire thing) are then loaded by
> scripting to a thispatcher (the old ones are deleted as well). I communicate
> by send/receive with patcherargs though the various FX.
>
> Stefan Tiedje's solution would be better, but i'm not into VST's, and I
> don't really need the realtime swapping of FX, just fast swapping is ok.
> --
> SmadSteck - http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling
>
The way you're doing it seems ok with me, so your problem remains the number of gates and cords? I'll try to outline what i would do, even though i don't know much about msp at all.
You could still put every effect into a separate subpatcher or even instance with a named recieve and send. Since it doesn't look like you're using voices or multiple effects in a chain, the receives can be the names of the effects themselves, and the sends can all send to one receive. See below.
Sorry i need to go now, no time to think the patch over, ill post what i have now...
PS - can receive and receive~ have the same name?
thanks Bas, that looks a lot cleaner. If i can't get the pluggo solution
to work then i'll use your solution as a model. In the larger context i
have planned, i'll be putting one of these bpatcher on the output of some
file players and a few other things, so being able to have several of them
is key, but clearly using "send #0.name" will solve that problem.
On 5/23/07, Bas van der Graaff wrote:
>
>
> The way you're doing it seems ok with me, so your problem remains the
> number of gates and cords? I'll try to outline what i would do, even though
> i don't know much about msp at all.
>
> You could still put every effect into a separate subpatcher or even
> instance with a named recieve and send. Since it doesn't look like you're
> using voices or multiple effects in a chain, the receives can be the names
> of the effects themselves, and the sends can all send to one receive. See
> below.
>
> Sorry i need to go now, no time to think the patch over, ill post what i
> have now...
> PS - can receive and receive~ have the same name?
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P comment 243 222 100 196617 outgoing signal;
> #P message 62 158 30 196617 open;
> #P message 153 145 33 196617 close;
> #P newex 411 199 51 196617 r effect2;
> #P newex 411 219 47 196617 pcontrol;
> #N vpatcher 590 511 911 766;
> #P inlet 202 56 15 0;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 109 153 67 196617 send~ output;
> #P window linecount 0;
> #P newex 109 99 35 196617 *~ 2.;
> #P newex 109 56 86 196617 receive~ effect2;
> #P connect 0 0 1 0;
> #P connect 1 0 2 0;
> #P pop;
> #P newobj 411 239 51 196617 p effect2;
> #P newex 411 124 51 196617 r effect1;
> #P newex 411 144 47 196617 pcontrol;
> #N vpatcher 590 511 911 766;
> #P inlet 202 56 15 0;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 109 153 67 196617 send~ output;
> #P window linecount 0;
> #P newex 109 99 41 196617 *~ 1.5;
> #P newex 109 56 86 196617 receive~ effect1;
> #P connect 0 0 1 0;
> #P connect 1 0 2 0;
> #P pop;
> #P newobj 411 164 51 196617 p effect1;
> #P newex 257 103 108 196617 sprintf send effect%s;
> #P newex 244 39 29 196617 sig~;
> #P newex 28 200 108 196617 sprintf send effect%s;
> #P newex 14 221 47 196617 forward;
> #P newex 116 120 108 196617 sprintf send effect%s;
> #P newex 411 53 51 196617 r effect0;
> #P newex 411 73 47 196617 pcontrol;
> #P message 102 145 47 196617 enable 0;
> #P newex 244 129 72 196617 send~ effect1;
> #N vpatcher 40 104 640 504;
> #P inlet 93 47 15 0;
> #P pop;
> #P newobj 244 202 76 196617 p mycrossfade;
> #P newex 244 175 81 196617 receive~ output;
> #P newex 102 168 47 196617 forward;
> #P message 14 158 47 196617 enable 1;
> #P newex 50 57 66 196617 t b l b b l;
> #P newex 116 96 36 196617 zl reg;
> #N vpatcher 590 511 911 766;
> #P inlet 202 56 15 0;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 109 153 67 196617 send~ output;
> #P window linecount 0;
> #P newex 109 99 35 196617 *~ 1.;
> #P newex 109 56 86 196617 receive~ effect0;
> #P connect 0 0 1 0;
> #P connect 1 0 2 0;
> #P pop;
> #P newobj 411 93 51 196617 p effect0;
> #P user ubumenu 50 31 60 196617 0 1 1 0;
> #X add 0;
> #X add 1;
> #X add 2;
> #X prefix_set 0 0 0;
> #P comment 275 39 100 196617 incoming signal;
> #P fasten 25 0 14 0 67 182 19 182;
> #P connect 4 0 5 0;
> #P connect 4 0 25 0;
> #P connect 4 1 15 0;
> #P fasten 4 1 3 1 69 87 147 87;
> #P fasten 24 0 6 0 158 164 107 164;
> #P connect 4 2 10 0;
> #P connect 4 2 24 0;
> #P connect 5 0 14 0;
> #P fasten 4 4 17 0 111 80 262 80;
> #P connect 17 0 9 0;
> #P connect 15 0 14 0;
> #P connect 3 0 13 0;
> #P connect 13 0 6 0;
> #P connect 23 0 22 0;
> #P connect 12 0 11 0;
> #P connect 1 0 4 0;
> #P connect 22 0 21 0;
> #P connect 19 0 18 0;
> #P connect 20 0 19 0;
> #P connect 16 0 9 0;
> #P connect 4 3 3 0;
> #P connect 10 0 6 0;
> #P connect 11 0 2 0;
> #P connect 7 0 8 0;
> #P window clipboard copycount 27;
>
>
> --
> SmadSteck - http://www.smadsteck.nl
> Hard- and software for interactive audiovisual sampling
>