dropdown menu opens patch


    May 21 2007 | 7:05 pm
    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

    • May 21 2007 | 7:09 pm
      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
      >
    • May 21 2007 | 7:28 pm
      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
    • May 21 2007 | 8:15 pm
      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.
    • May 21 2007 | 9:37 pm
      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.
    • May 21 2007 | 10:55 pm
      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/
      >
    • May 21 2007 | 11:27 pm
      i use [mute~]
      very satisfied
      be sure to use [pass~] ala [mute~] help
    • May 23 2007 | 4:56 am
      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
    • May 23 2007 | 9:18 am
      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.
    • May 23 2007 | 3:22 pm
      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
      >
    • May 23 2007 | 4:09 pm
      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?
    • May 23 2007 | 6:08 pm
      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
      >