Building a Mux system with a separate Mux for each key...?

Official support for: mutools.com
Post Reply New Topic
RELATED
PRODUCTS

Post

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...)
Last edited by Jake Jackson on Fri Feb 15, 2013 4:58 pm, edited 1 time in total.

Post

why dont you try it and tell us the result? :wink:

Post

> DiGiT < wrote:why dont you try it and tell us the result? :wink:
Cowardice and a fear of wasting time...

Post

Jake Jackson wrote:
> DiGiT < wrote:why dont you try it and tell us the result? :wink:
Cowardice and a fear of wasting time...
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 it :)
My Setup.
Now goes by Eurydice(Izzy) - she/her :hug:

Post

That's how we learn in life! If we just asked questions for fear of mistake we'd never do anything!

Post

If you do this you'll get a free pass to any mental institution :D

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!
:hug:

Post

Jake Jackson wrote:1. Is this the best organization for this project?
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.
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?
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.
3. Will I run out of Muxes?
No. (unless you would run out of RAM, but that's unprobable)
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...)
Yes using many MUXes is possible, the only practical limits are RAM and CPU power.

Enjoy your adventures!

Post

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.)

Post

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?
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.

Post

Many, many thanks.

Post

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.

Image

Uploaded with ImageShack.us
Last edited by Jake Jackson on Fri Feb 15, 2013 11:48 pm, edited 2 times in total.

Post

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:

Image

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.

Post

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.)

Post

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:

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.

Post

Keep em coming, very interesting :)
:hug:

Post Reply

Return to “MUTOOLS”