Building a Mux system with a separate Mux for each key...?
-
- KVRian
- Topic Starter
- 858 posts since 14 Sep, 2004
Sorry for so many questions. I'm on the verge of launching into a fairly complex Mux, however, and I don't want to make a beginner's mistake.
I want to build a Mux that lets the user control parameters on a synth key by key with velocity. The front interface for the Mux will ideally have a column of controls, such ASDR, for each piano key. My impression is that the best way to do this would be to build a Mux and then open the Session Mux, add 88 copies of the smaller Mux in, and then set the keyrange to one key within each under-Mux, using the Note Key Velocity Filter module.
Some obvious questions:
1. Is this the best organization for this project?
2. Can this be done? If I open the same Mux in the Session Mux, since each now has a number appended to the name, can I treat them as separate items, so that the changes in one will not affect the others?
3. Will I run out of Muxes? Are 88 Muxes even possible? (I understand that I will probably end up with too much strain on my computer trying to play a large number of notes. But I want to see what can be done...)
I want to build a Mux that lets the user control parameters on a synth key by key with velocity. The front interface for the Mux will ideally have a column of controls, such ASDR, for each piano key. My impression is that the best way to do this would be to build a Mux and then open the Session Mux, add 88 copies of the smaller Mux in, and then set the keyrange to one key within each under-Mux, using the Note Key Velocity Filter module.
Some obvious questions:
1. Is this the best organization for this project?
2. Can this be done? If I open the same Mux in the Session Mux, since each now has a number appended to the name, can I treat them as separate items, so that the changes in one will not affect the others?
3. Will I run out of Muxes? Are 88 Muxes even possible? (I understand that I will probably end up with too much strain on my computer trying to play a large number of notes. But I want to see what can be done...)
Last edited by Jake Jackson on Fri Feb 15, 2013 4:58 pm, edited 1 time in total.
-
- KVRian
- Topic Starter
- 858 posts since 14 Sep, 2004
Cowardice and a fear of wasting time...> DiGiT < wrote:why dont you try it and tell us the result?
- KVRian
- 1441 posts since 4 Oct, 2012 from Utah
But that's the fun of using the MUX. Testing and figuring things out. That includes wasting our time and making fools of our selves. I've done itJake Jackson wrote:Cowardice and a fear of wasting time...> DiGiT < wrote:why dont you try it and tell us the result?
My Setup.
Now goes by Eurydice(Izzy) - she/her
Now goes by Eurydice(Izzy) - she/her
- KVRAF
- 2693 posts since 28 Mar, 2008 from a Galaxy S7 far far away
That's how we learn in life! If we just asked questions for fear of mistake we'd never do anything!
-
- KVRAF
- 2973 posts since 10 Sep, 2003 from Karlskoga, Stockholm, Sweden
If you do this you'll get a free pass to any mental institution
2. You should be able to treat them as separate devices
Maybe start with just an octave (12) and then expand to 88 and see how far you get..
If you decide to pursuit this, please let us know how the journey goes!
2. You should be able to treat them as separate devices
Maybe start with just an octave (12) and then expand to 88 and see how far you get..
If you decide to pursuit this, please let us know how the journey goes!
- KVRAF
- 12739 posts since 24 Jun, 2008 from Europe
As others already wrote: Experimenting is a good thing. The MUX is a modular environment and so there zillions of options. Also i don't know all possible combinations.Jake Jackson wrote:1. Is this the best organization for this project?
One tip: If you build patches, build them in a normal MUX not the session MUX because then you can save them and reload them anywhere you want. The Session MUX is a special MUX and is not compatible with normal MUXes and vice versa.2. Can this be done? If I open the same Mux in the Session Mux, since each now has a number appended to the name, can I treat them as separate items, so that the changes in one will not affect the others?
No. (unless you would run out of RAM, but that's unprobable)3. Will I run out of Muxes?
Yes using many MUXes is possible, the only practical limits are RAM and CPU power.Are 88 Muxes even possible? (I understand that I will probably end up with too much strain on my computer trying to play a large number of notes. But I want to see what can be done...)
Enjoy your adventures!
-
- KVRian
- Topic Starter
- 858 posts since 14 Sep, 2004
Thanks. I'm running into an elementary problem, but I'm unable to find the answer in the help docs or through trial and error: How does one connect the under-Muxes to the uber-Mux in such a way that their events and event modulation are fed into the uber-Mux? Can you point me to a diagram of the wiring for the upper-Mux and the Muxes inside it?
My impression is that the VSTI instrument needs to be in the uber-Mux, that only the events and mods need an input and output to the uber-Mux. Otherwise there will be separate instances of the instrument loaded in each under-Mux. But the under-Muxes, displayed together in the uber-Mux, only have Audio-out connectors along their bottom.
The example Mux at http://www.mutools.com/info/docs/common ... n-mux.html is using different instruments in each under-Mux (and using the Session Mux), so it doesn't show the needed connections.
(Thank-you for the heads-up about not using the Session Mux for this and for using presets for each under-Mux.)
My impression is that the VSTI instrument needs to be in the uber-Mux, that only the events and mods need an input and output to the uber-Mux. Otherwise there will be separate instances of the instrument loaded in each under-Mux. But the under-Muxes, displayed together in the uber-Mux, only have Audio-out connectors along their bottom.
The example Mux at http://www.mutools.com/info/docs/common ... n-mux.html is using different instruments in each under-Mux (and using the Session Mux), so it doesn't show the needed connections.
(Thank-you for the heads-up about not using the Session Mux for this and for using presets for each under-Mux.)
- KVRAF
- 12739 posts since 24 Jun, 2008 from Europe
Insert a audio/event/modulation output in the child MUX (under MUX) and then in the parent MUX (uber MUX) you'll see these outputs as output jacks and so you can use them.Jake Jackson wrote:How does one connect the under-Muxes to the uber-Mux in such a way that their events and event modulation are fed into the uber-Mux?
-
- KVRian
- Topic Starter
- 858 posts since 14 Sep, 2004
Many, many thanks.
-
- KVRian
- Topic Starter
- 858 posts since 14 Sep, 2004
For anyone who may be interested, here is the parent Mux with three piano keys mapped to Muxes. I changed the background color of the Muxes to blue just so I can keep track of them a bit more easily. To see the screenshots better, click on them and then, after you are taken to the ImageShack site, click on the image again to get a full-screen view.
Uploaded with ImageShack.us
Uploaded with ImageShack.us
Last edited by Jake Jackson on Fri Feb 15, 2013 11:48 pm, edited 2 times in total.
-
- KVRian
- Topic Starter
- 858 posts since 14 Sep, 2004
EDIT See two posts below for the corrected version of the child Mux. Beginner's mistake: The screenshot this current post instead demonstrates a simple mistake that was causing cracking and cpu stress: I split the input into the same key again and again using multiple Note Key/Vel Filters. Doing so has an advantage--one can then easily set the min and max velocity values note-by-note. However, the cpu cost is high. Much less of the cpu is used if one routes the Event Input to one Note Key/Vel Filter and then attaches all of the modulations to that filter's output.
And here is the work-in-progress child Mux for C3\Middle C:
Uploaded with ImageShack.us
I do know that the Audio input and output are not needed in the child Mux. I've left them in case I want to use this preset for another instrument that might need them. In the lower right corner are two not-yet-attached modules. Trying to be careful with building this preset, getting it right before I open it and use Save As in the many other Muxes. Many choices to be made, too, about where in the signal chain to put various things, which is making me take care.
If I'm making mistakes, connecting things in ways that will cost me cpu cycles, please let me know.
And here is the work-in-progress child Mux for C3\Middle C:
Uploaded with ImageShack.us
I do know that the Audio input and output are not needed in the child Mux. I've left them in case I want to use this preset for another instrument that might need them. In the lower right corner are two not-yet-attached modules. Trying to be careful with building this preset, getting it right before I open it and use Save As in the many other Muxes. Many choices to be made, too, about where in the signal chain to put various things, which is making me take care.
If I'm making mistakes, connecting things in ways that will cost me cpu cycles, please let me know.
Last edited by Jake Jackson on Sat Feb 16, 2013 9:24 pm, edited 3 times in total.
-
- KVRian
- Topic Starter
- 858 posts since 14 Sep, 2004
Sorry for three posts in a row, but there's a possibly confusing, important thing that is essential in building this kind of parent Mux fed by child Muxes:
In the child Mux, to make a Parameter Event Generator (PEG) control a parameter on the parent Mux's vsti synth, you must first, temporarily, load the vsti synth INSIDE the child. It does not have to be connected to anything except the Event Output of the Parameter Event Generator. You can then select the parameter that you want to control in the Parameter Event Generator. Assuming that you already have the vsti synth loaded in the parent Mux, you can then delete the connection in the child Mux between the PEG and the vsti synth and then connect the PEG to the Event Output. The PEG will remember the parameter and pass your modulations into the parent MUX. You can then delete the vsti synth from the child Mux. (Leaving it there and just running another chord to the Event Output may not hurt things. I don't want to find out. But of course, do not connect it to the Audio Outs, or you will be running two copies of the synth at once and probably get crackles.)
You CAN instead put the parameter into the Parent Mux. Which may work just as well, but for a complex Mux, some confusion and clutter may result. If you do NOT temporarily load the vsti synth into the child Mux, as far as I can tell, there is no easy way (or no way) to assign a PEG in the child to a parameter in the synth in the parent Mux. Double-clicking on it in the child brings up the Edit box with no parameters in the drop-down list of parameters.
One more note: After you have loaded the vsti synth in the child, connected it to the Event Out of your last mod, and assigned a parameter, I'm finding it wise to rename the PEG to indicate the relevant parameter. The PEG will remember the parameter, but it will not remember its name: Once you disconnect the synth in the child Mux, even though the mods are passed into the parent Mux correctly, the name of the parameter cannot be seen. Double-clicking on the PEG will still show no parameter loaded in the Edit dialog box, and will have nothing on the drop-down parameter list. (And remember to save those presets in the Muxes, as well as saving the session.)
In the child Mux, to make a Parameter Event Generator (PEG) control a parameter on the parent Mux's vsti synth, you must first, temporarily, load the vsti synth INSIDE the child. It does not have to be connected to anything except the Event Output of the Parameter Event Generator. You can then select the parameter that you want to control in the Parameter Event Generator. Assuming that you already have the vsti synth loaded in the parent Mux, you can then delete the connection in the child Mux between the PEG and the vsti synth and then connect the PEG to the Event Output. The PEG will remember the parameter and pass your modulations into the parent MUX. You can then delete the vsti synth from the child Mux. (Leaving it there and just running another chord to the Event Output may not hurt things. I don't want to find out. But of course, do not connect it to the Audio Outs, or you will be running two copies of the synth at once and probably get crackles.)
You CAN instead put the parameter into the Parent Mux. Which may work just as well, but for a complex Mux, some confusion and clutter may result. If you do NOT temporarily load the vsti synth into the child Mux, as far as I can tell, there is no easy way (or no way) to assign a PEG in the child to a parameter in the synth in the parent Mux. Double-clicking on it in the child brings up the Edit box with no parameters in the drop-down list of parameters.
One more note: After you have loaded the vsti synth in the child, connected it to the Event Out of your last mod, and assigned a parameter, I'm finding it wise to rename the PEG to indicate the relevant parameter. The PEG will remember the parameter, but it will not remember its name: Once you disconnect the synth in the child Mux, even though the mods are passed into the parent Mux correctly, the name of the parameter cannot be seen. Double-clicking on the PEG will still show no parameter loaded in the Edit dialog box, and will have nothing on the drop-down parameter list. (And remember to save those presets in the Muxes, as well as saving the session.)
-
- KVRian
- Topic Starter
- 858 posts since 14 Sep, 2004
I know. Four posts in a row. But in case anyone is trying something similar, this is the much more efficient next version of the child Mux. Again, clicking on the image and then clicking on it again at the ImageShack site provides a clearer image:
Uploaded with ImageShack.us
The early version was going through too many stages and thus straining the cpu. This version just links the Note Key/Vel Filter directly to ADSR envelopes (black boxes),which in turn go to the parameters (gray boxes), which then link to the Event Output. This version also responds to velocity, since each ADSR envelope has a Velocity control. Seems like a self-evident arrangement, now, after making many mistakes.
Uploaded with ImageShack.us
The early version was going through too many stages and thus straining the cpu. This version just links the Note Key/Vel Filter directly to ADSR envelopes (black boxes),which in turn go to the parameters (gray boxes), which then link to the Event Output. This version also responds to velocity, since each ADSR envelope has a Velocity control. Seems like a self-evident arrangement, now, after making many mistakes.
-
- KVRAF
- 2973 posts since 10 Sep, 2003 from Karlskoga, Stockholm, Sweden
Keep em coming, very interesting