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 >