Using MUX

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

Post

I'm using MUX to make "my own" plugin, it's very cool but I have a problem.

For the sake of discussion lets just say that in the MUX Deep Editor I add two modules. One is a LFO and the other a delay module. The LFO is used to control the amount of delay in the delay module. (These are midi modules not analog modules.)

I add the parameters I want to see in play mode and set up the midi controller map as I think it should be and sure enough, it all works fine, does what I expect, mixdown works, all is good. Except ....

The LFO is controlling the delay paramater and when I go into the Deep Editor and open the Delay module I can see the "delay knob" bouncing up and down with the expected timing. Now this "delay knob (paramater)" is also setup in the play Editor. And it does work, it can indeed control the delay paramater of the delay module from the play editor.

The problem is, that when the LFO is controlling the "delay knob" the paramater changes of the knob in the delay module are not reflected back to the dispaly in the Play editor. That is, in the play editor you can't see how the Delay Module paramater is being changed by the LFO module. Another way to say this is the knobs in the play editor don't seem to be bi-directional.

Is there something else that I need to do to make something like this work?

John

(Edit: Since posting I've played around with this some more and noticed something very strange. If I open up the deep modules and the Play editor at the same time I can watch all of the modules. If I tweak a paramater in the deep modules, the Delay knob for example, it does get reflected back in the play editor. The knobs are bi-directional. But when the LFO changes the delay module it is not reflected back. This now feel like a "bug".)

Post

Here's a MU.LAB session that demonstrates the "bug".

http://johnjayplatko.com/Documents/MUX_BUG.MuSession

Open the cutom MUX "Swinger" and go into Deep Editor. Open the two VSTS, midiSimpleLFO and midiExactDelay.

Switch to Play Editor so you can see "Swinger's" controls.

Notice that the "Ticks" control on midiExactDelay is turning up and down (sometimes I have to hit play to make that happen) but the "Ticks" control on "Swinger" is not moving. - The "bug". :help:

Now click the upper left button on midiSimpleLFO to turn it off. Notice that the "Ticks" control on midiExactDelay stops, as it should.

Now tweak "Ticks" on "Swinger's" control. Notice that "Ticks" on midiExactDelay tracks the movement.

Now Tweak "Ticks" on midiExactDelay. Notice that "Ticks" on "Swinger" tracks the movement. It should also track when midiSimpleLFO is causing midiExactDelay's "Ticks" to rotate- but it doesn't.

John

Post

Can you please email me a simple musession demonstrating this, preferrably with free VSTs. Thanks.

Post

mutools wrote:Can you please email me a simple musession demonstrating this, preferrably with free VSTs. Thanks.
I posted a link to a session which demonstrates this in the post just above yours. Just click on the link and download and follow the instructions in the post. The two VSTs that I use are free. midiSimpleLFO and midiExactDelay.

Here's a link to the VSTs. I use the ones without the fancy graphics.

http://www.kvraudio.com/forum/viewtopic.php?t=192282

John

Post

Thanks for the musession, our messages crossed, that's why i didn' see it at first.

On topic: I'm not yet sure whether this should be called a bug or a non-feature. Will be evaluated later.

Current solution: If you want to automatate a parameter that is mapped to a meta parameter, then it's best to automate the meta parameter itself.

Post

mutools wrote:Thanks for the musession, our messages crossed, that's why i didn' see it at first.

.....

Current solution: If you want to automatate a parameter that is mapped to a meta parameter, then it's best to automate the meta parameter itself.
The reason to automate the paramater instead of the meta parameter is for good visulaiton of what's happening with the music. It's very helpful, especially as things get complex, to see the actual knob of interest turn. And, to be clear, the automation does work, and if I go into deep edit I can get the visual I'm looking for. But, for complex situations it's helpful to only have some parameters on screen like the play editor provided for.

On topic: I'm not yet sure whether this should be called a bug or a non-feature. Will be evaluated later.
I was willing to go along with "non-feature" until I saw that when you change the deep paramater manually it gets reflected back to the play editior paramaters. It seems very inconsistant and non-intutative (quirky) the way it is. I mean:

Why wouldn't you want the deep parameter movement reflected back to the play editor- no matter what caused that movement? That is, why sometimes yes, sometimes no? I'm mean, a person (me) can waste a lot of time trying to figure out if their MUX design is working, or there's a bug (or non feature) in Mulab :) )

But call it what you will, bug- non-feature, I don't really care. But please fix it when you get a chance. It really would help my automations and I think it would make MU.LAB more consistant and therefore enjoyable (and friendly to newbees) to use.

John

Post

Thing is that the 'bi-directionality' of the meta-parameters is only working on gui level i.e. when touching parameters on screen, but not (yet?) on realtime level, and there are technical reasons for this. I agree this could/should be improved, but it cannot be realized on short term. Added a note on the whishlist.
johnjaypl wrote:The reason to automate the paramater instead of the meta parameter is for good visulaiton of what's happening with the music. It's very helpful, especially as things get complex, to see the actual knob of interest turn. And, to be clear, the automation does work, and if I go into deep edit I can get the visual I'm looking for. But, for complex situations it's helpful to only have some parameters on screen like the play editor provided for.
IF the bi-directionality would work on all levels, then note that it would not make a difference whether you automate the meta-parameter itself or any of its target parameters. So i think it's stays a good idea to automate the meta-parameter instead. Note however that automating a (meta-)parameter is not the same as what you do in the test session, where you try to use the output of a vst midi lfo to modulate parameters, which will currently only work between vst plugins, not yet towards mu.lab own modules. That's also on the whishlist.
I was willing to go along with "non-feature" until I saw that when you change the deep paramater manually it gets reflected back to the play editior paramaters. It seems very inconsistant and non-intutative (quirky) the way it is.
Why wouldn't you want the deep parameter movement reflected back to the play editor- no matter what caused that movement? That is, why sometimes yes, sometimes no? I'm mean, a person (me) can waste a lot of time trying to figure out if their MUX design is working, or there's a bug (or non feature) in Mulab :) )

But call it what you will, bug- non-feature, I don't really care. But please fix it when you get a chance. It really would help my automations and I think it would make MU.LAB more consistant and therefore enjoyable (and friendly to newbees) to use.[/quote]

I completely agree.

On the whishlist.

Post

IF the bi-directionality would work on all levels, then note that it would not make a difference whether you automate the meta-parameter itself or any of its target parameters. So i think it's stays a good idea to automate the meta-parameter instead. Note however that automating a (meta-)parameter is not the same as what you do in the test session, where you try to use the output of a vst midi lfo to modulate parameters, which will currently only work between vst plugins, not yet towards mu.lab own modules. That's also on the whishlist.
How do I automate a "meta-parameter" and, by the way, what's a "meta-paramater"?

What's wrong with using midi CCs' to control a VST, or any other module for that matter? There are a lot of hooks for doing just that in the structure of VSTs.

where you try to use the output of a vst midi lfo to modulate parameters, which will currently only work between vst plugins, not yet towards mu.lab own modules. That's also on the whishlist.
As a matter of fact I just noticed that doesn't work, I was just about to post my next "bug". What do you meant it only works between vst plugins, not yet toward mu.lab own modules!?!? :roll:

You mean if I use "amplifier" in a MUX I can't control the gain of the amplifier by a midi cc. From what I see, it certainly seems that I can't. What kind of sense does that make? (If you meant something else, I'll go ahead and post what I mean.)

John

Post

johnjaypl wrote:How do I automate a "meta-parameter" and, by the way, what's a "meta-paramater"?
It are the parameters at the top of the MuSynth/MUX deep editor which can be used to control 1 or many parameters in the patch. It are these parameters which appear in the play editor.
What's wrong with using midi CCs' to control a VST, or any other module for that matter? There are a lot of hooks for doing just that in the structure of VSTs.
Nothing wrong with it. And it does work. We're talking about the case where such parameters are part of a meta-parameter mapping.
You mean if I use "amplifier" in a MUX I can't control the gain of the amplifier by a midi cc. From what I see, it certainly seems that I can't. What kind of sense does that make?
It doesn't. It's on the whishlist.

Post

What's wrong with using midi CCs' to control a VST, or any other module for that matter? There are a lot of hooks for doing just that in the structure of VSTs.
Nothing wrong with it. And it does work. We're talking about the case where such parameters are part of a meta-parameter mapping.
It doesn't work! I can set up the Gain paramater to be controlled by a midi CC but the gain doesn't get controled by the CC. That is, It doesn't work. Right?

Maybe I'm confused but that's what I understood you to say in your next sentance. Maybe we have a bit of a communication problem, but to be clear, I'm just trying to understand I'm not trying to be offensive here. Just thought I should say that.
You mean if I use "amplifier" in a MUX I can't control the gain of the amplifier by a midi cc. From what I see, it certainly seems that I can't. What kind of sense does that make?
It doesn't. It's on the whishlist.[/quote]

Post

johnjaypl wrote:It doesn't work! I can set up the Gain paramater to be controlled by a midi CC but the gain doesn't get controled by the CC. That is, It doesn't work. Right?
When you map a CC to a parameter of a MU.LAB plugin, then this only works for MIDI input, i.e. when you turn the MIDI CC on a keyboard, the parameter will react. It does not (yet) work when you sequence CC events to that MU.LAB plugin. It does work however for VST plugins. That's what i meant, as i thought we were talking about connecting VST plugins.
Maybe I'm confused but that's what I understood you to say in your next sentance. Maybe we have a bit of a communication problem, but to be clear, I'm just trying to understand I'm not trying to be offensive here. Just thought I should say that.
Yes it's a bit a difficult communication, but i understand this may be a confusing subject.

So let me try to recap:

* Generally, mapping a CC to a parameter only works for MIDI input.
It was initially meant pure for live controlling of parameters.
Controlling a parameter by e.g. a vst midi lfo is not (yet) supported.
* Exception: it does always work for VST plugins, also for sequenced/patched events. So if you map a CC to a VST parameter and you sequence/patch CCs to that VST plugin, it will work.
* When a parameter is part of a meta-parameter, the 'inverse' behaviour is only applied on the GUI level, not the realtime level

I agree that this is not perfect, there is room for improvement, it's on the whishlist.

Hope this clears things out.

Post

I would suggest a new section to the documentation which talks about "the limits of MULAB", that is capabalities that a reasonable person might expect to work that don't because MULAB didn't get around to implementing them. - Like a ADSR module reacting to midi commands regardless of the source of those midi commands.

John

Post Reply

Return to “MUTOOLS”