
Can somebody give me a clue, please!?
Just a screen shot of a working set-up will probably do, but ANY help with this will be very appreciated! TIA!

I haven't yet tried (or even heard of!) the Controller to Mod converter, so yes, this will no doubt be a big help—off to try it:)mutools wrote: Wed Mar 11, 2020 8:03 pm The step sequencer outputs these events as MIDI Controller events.
So then it's a matter of mapping these MIDI CC events to something you want.
If you want them to act as modulation insert a Controller to Modulation Converter and properly connect the Step Seq to that converter, then the mod out of that converter to any parameter modulation input.
If you want the CC events to automate a parameter, then connect the step seq to the module you want to automate and in that module setup a CC map from the CC you use in the step seq to the parm you want.
Hope this helps.
Automation = Changing the parameter value itself.David wrote: Wed Mar 11, 2020 8:46 pm But first, I'm not clear on the distinction between the two goals you describe; can you clarify what the difference is between "acting as modulation" and "automating a parameter"?
Thanks, clearer, for sure:) But still not clear on when there would any advantage or reason to prefer one approach over the other. Or is this mostly to do with which sort of I/O's are most readily available…?mutools wrote: Wed Mar 11, 2020 9:44 pmAutomation = Changing the parameter value itself.David wrote: Wed Mar 11, 2020 8:46 pm But first, I'm not clear on the distinction between the two goals you describe; can you clarify what the difference is between "acting as modulation" and "automating a parameter"?
Modulation = Adding a value upon the current parameter value.
Automation is done using events = the blue signals.
Modulation is done using modulation signals = the green signals.
Pls also see http://www.mutools.com/info/M8/docs/mux ... ditor.html
I think it depends on the context what u want to do.David wrote: Wed Mar 11, 2020 9:52 pm Thanks, clearer, for sure:) But still not clear on when there would any advantage or reason to prefer one approach over the other.
No, not really. (though not every parameter has a modulation in jack)Or is this mostly to do with which sort of I/O's are most readily available…?
I'm not sure if i fully understand the question but i hope it's relevant to say that MuLab is a very modular DAW.In the other daws I use, Automation is only used on tracks in the piano roll directly from the DAW itself, not independently of any tracks and only within or between plugins. That doesn't seem to be an applicable distinction once in Mulab, right?
When i explained the difference between automation and modulation in MuLab/MUX this was unrelated to other DAWs. So sorry if the word "automation" caused confusion for it may be used otherwise in other DAWs.David wrote: Wed Mar 11, 2020 10:51 pm But apparently Mulab's modularity means that "automation" can be used very much like "modulation" in the Logic sense, so I'm having no luck yet seeing why or when one would be preferred over the other.
Well, yeah, whatever works is the main thing, and I'm loving the results in my example above, thank you!mutools wrote: Thu Mar 12, 2020 9:13 amWhen i explained the difference between automation and modulation in MuLab/MUX this was unrelated to other DAWs. So sorry if the word "automation" caused confusion for it may be used otherwise in other DAWs.David wrote: Wed Mar 11, 2020 10:51 pm But apparently Mulab's modularity means that "automation" can be used very much like "modulation" in the Logic sense, so I'm having no luck yet seeing why or when one would be preferred over the other.
Whether you want to use automation (= using parameter events) or modulation (= green signals) depends on the use case i think. And in some cases there is no practical choice: MuLab's composer currently only supports sending automation. And not each parameter has a modulation input, so if you want to apply eg. an LFO on such parameter you'll have to use a Parameter Event Generator in between. Hope this helps.
Glad to hear you found how to automate the step sequencer's Transpose parameter.
(yes in Mux that's called automation as it's done with parameter events = blue signals)
Well, once again, I'm happy with this current approach and don't really even need to know why doing exactly as you describe here NEVER worked for me, no matter how many times I tried it, and tried to vary it to get it working—That's why I started this thread in the first place!mutools wrote: Thu Mar 12, 2020 9:34 pm In fact you could connect the step seq at the top right in your example directly to the event in of the step seq at the bottom, and then right-click that bottom step seq -> Map MIDI Controller and map the CC you're sending out to the parameter you want.
Will do—thank you!pljones wrote: Thu Mar 12, 2020 9:18 am The difference is along the lines of how you're thinking. Event inputs carry exposed parameters that can be automated. In the VST world, that's the only way -- indeed, MuLab automation from the composer targets parameter event inputs on a module, not modulation inputs. So a MUX module can choose to expose parameters that a user is likely to want to automate. Internally, a synth or effect might depend on various modulation to give it its "feel". Of course, the designer might choose to expose aspects of those modulators using parameters.
Take a look at bibit1st's Bass Octavia. The "top level" automation is for Wave Index, Attack Time and Decay Time. If you use MUX as a VST, these are the only visible parameters available for automation. (MuLab lets you "drill down" into each sub-module.) Then open up to the modular view. At the top level, you'll see an LFO as a modulator - runs freely for the duration of the note input. The Poly-synth opens up to show even more modulation going on. The simplest here is the ENV module, doing what you'd expect.
Submit: News, Plugins, Hosts & Apps | Advertise @ KVR | Developer Account | About KVR / Contact Us | Privacy Statement
© KVR Audio, Inc. 2000-2026