MuLab 10.1.25

[MuTools]

The default for these 2 preferences is to auto create transient markers and to snap the loop length.
Based on what i read in your posts i assume you will keep these default preferences. But, again, for clarity, these prefs are not yet used when dropping a sample into the audio seq editor, only when dropping a sample in the time line / live clip matrix. Taken note of that feature request.

[jd88]

Step-Seq Controller-Line

This is definitely just only a feature request (yes, sorry, but I'm noticing these kinds of things during some beta testing):

It would make sense to be able to solo or mute individual lines in the MuLab StepSequencer (Controller section).

The reason is this:

Many VSTs have a MIDI learn function for their parameters (controls). This means you could click on the respective parameter and play the individual line of the MuLab StepSequencer (which is set to solo), and the controller of that line would then be assigned to the corresponding parameter of the target VST.

This is often much faster than laboriously navigating through the VST's controller mapping window.

This (Solo/Mute Line) is implemented this way by many third-party step sequencers (or similar plugins).

- - - - -

--> (It would be nice if MuLab-Mux could do this too.
OR / AND At least a significant improvement regarding the mapping of controllers to *.Mux parameters. In my opinion, the current implementation is very chaotic and confusing.) <--

(see my vid-mails too: Problem "Parameter swap" / "CC --> Parameter"

CC --> Parameter !!!! I KNOW: The workaround here is to load the Arp or StepSeq or whatever in another Rack and "send" its Output to the Rack of the Synth that have to receive the controllerdata. But why so complicated????)

Thx for your support

reg.

[MuTools]

At least a significant improvement regarding the mapping of controllers to *.Mux parameters. In my opinion, the current implementation is very chaotic and confusing.)
(see my vid-mails too: Problem "Parameter swap" / "CC --> Parameter"
CC --> Parameter !!!! I KNOW: The workaround here is to load the Arp or StepSeq or whatever in another Rack and "send" its Output to the Rack of the Synth that have to receive the controllerdata. But why so complicated????)

About MIDI CC mapping, first of all please read this doc page: https://www.mutools.com/info/M10/docs/m ... llers.html

It's important to understand that MIDI CC mapping is organized per module!
And that MIDI CC events simply travel thru the blue lines in the modular area from blue output to blue input.
When a module receives CC it looks in its CC map whether its mapped and if yes it applies the mapping.

Does that clarify it?

I think once you know how it works it's quite simple and clear yet allows all kinds of CC mappings in MuLab's modular architecture.

[MuTools]

Attached a draft little example project where a Step Sequencer drives a Basic Synth, both notes and mapped MIDI CC1.
Note that the MIDI CC1 mapping is in the Basic Synth CC map.
Hope this helps.

[jd88]

Attached a draft little example project where a Step Sequencer drives a Basic Synth, both notes and mapped MIDI CC1.
Note that the MIDI CC1 mapping is in the Basic Synth CC map.
Hope this helps.

This is a method I've known for a long time. In principle, it's easy to understand, and I use it for simple projects. Alternatively, if it makes sense, I assign parameters directly within the *.mux project/plug using mod-cables and CC filters, etc.

(See my corresponding plugins, which also run multiple Stepseq and Players.)


The issue is this:

In projects or *.mux plugins where this approach inevitably results in a list of over 500 (some of them unusable?!) target parameters. These target parameters are neither sortable nor properly explained, and you have to scroll through the entire (unsorted, unfiltered) list every time. This makes this type of CC assignment completely unusable.

As I mentioned today, even using a second level (MP controls) isn't much better, as it introduces other problems.

-----

Therefore, in my opinion, the only option, especially for complex plugins, is:

Right-click on the plugin's target control, assign a MIDI CC, and it should work.

This method of CC assignment works perfectly with the MuLab plugin within any third-party DAW. It just doesn't work within the MuLab DAW itself.

ALTERNATIVE 1:

If users could limit the target parameter list to the relevant parameters and sort them accordingly. This would allow the list to display only the relevant parameters and be sorted by priority.

- -

ALTERNATIVE 2:

A MuLab mux plugin is treated within MuLab like any other VSTi (everything works perfectly with third-party VSTis).

- - - - -

Like I wrote before:
actually there is the workaround:
Right-click on the *.mux- plugin's target control, assign a MIDI CC, change CC and then load the MIDI-Arp or StepSeq or whatever in another Rack and "send" its Output to the Rack of the .mux-Synth that have to receive the controllerdata.
it's not perfect .... but works for mini-projects. (doubles Racks(Tracks) you need.


- - - - -

[jd88]

Finally, regarding automation/automation lists:

There's an important tip to keep in mind about "automation lists" (target parameters): (Unfortunately, I couldn't find this anywhere)

- - - - -

Each *.mux element within a project creates a new folder within the automation lists.

Therefore, since it's currently impossible to organize or reorganize automation lists after the fact, you should group as many sub-areas as possible into separate *.mux elements from the very beginning of a project.

(This is only possible to a limited extent, as, for example, the polysynth has very limited input/output options, filters/ADSR outside of the polysynth only function monophonically, etc.)

This currently seems to be the only way to gain at least some semblance of order in the target parameter lists.

Implementing this retrospectively within a large project is hardly possible, as subsequently splitting a project into individual *.mux parts means that the corresponding controls on the front panel have to be recreated, especially since they do not follow the resulting additional sub-level (they apparently have no direct/fixed connection to the individual target parameter).

(google translate )

[MuTools]

This is a method I've known for a long time. In principle, it's easy to understand, and I use it for simple projects. Alternatively, if it makes sense, I assign parameters directly within the *.mux project/plug using mod-cables and CC filters, etc.
(See my corresponding plugins, which also run multiple Stepseq and Players.)

For clarity i'd like to ask to use "MUX presets" for MUX modular presets and "plugins" for VSTs or CLAP plugins. A MUX preset is not a plugin. Just for clarity of reading. Thanks.

The issue is this:
In projects or *.mux plugins ...

= MUX presets

... where this approach inevitably results in a list of over 500 (some of them unusable?!) target parameters. These target parameters are neither sortable nor properly explained, and you have to scroll through the entire (unsorted, unfiltered) list every time. This makes this type of CC assignment completely unusable.

I don't understand what you mean.
The "Edit MIDI CC Mapping" dialog lets you select the target module and then the target parameter. If you have a complex MUX modular patch then there can be many modules, but i don't know any module with 500+ parameters. I think a MUX module itself is the module with the most parameters: 128 meta parameters. However these are not listed if they're not in use.

As I mentioned today, even using a second level (MP controls) isn't much better, as it introduces other problems.

Which problems?

Therefore, in my opinion, the only option, especially for complex plugins, is:
Right-click on the plugin's target control, assign a MIDI CC, and it should work.

It's not that simple, unfortunately.
If you right-click a parameter and do "Map CC" then the essential question is: In which module's CC map should that mapping be stored?
The most simple answer is: Well in the CC map of the module of that parameter.
But that does not work in many cases.
For example: Imagine a rack with a synth MUX/plugin in slot 1 and a separate lowpass filter in slot 2. You right-click the cutoff of the lowpass and map CC 1. So lets assume it's stored in the CC map of the lowpass, ie. the most simple case. MIDI input is focused to the rack, and travels on to the synth in slot 1. However the synth in slot 1 does not bypass incoming events. So the lowpass filter does not receive the CC events hence it cannot apply the mapping from CC 1 to cutoff. Result: Turning the mod wheel does nothing. (you could edit the racks internal routing but that's not on topic here)
That's why upon right-click parameter the CC map is stored in the module that has MIDI input focus at that moment. In the above example that's the rack. So when the rack receives CC1 it can apply the mapping of CC1 to the lowpass cutoff in slot 2. Works fluently. No hassle.

I know you are also focussing on other use cases eg. when there are CC generators in the rack. Lets modify above example by moving the lowpass to slot 3 and insert some CC1 generator in slot 2. Besides this modification of above example lets assume all the rest is the same and thus the CC1 mapping is in the rack CC map.
Indeed, then the CC1 generator in slot 2 wont have effect on the cutoff in filter 3 as the CC1 to cutoff mapping is in the rack. In such case you need to specifically map the CC1 to cutoff in the lowpass filter module itself.

It are 2 different use cases, and each case has its own needs.
There is no common solution as far as i see.

I do understand this system can be confusing at first but once you know how it works, it works just fine and you have all flexibility you need.

[MuTools]

Finally, regarding automation/automation lists:
Each *.mux element within a project creates a new folder within the automation lists.

I don't recommend using the parameter list to create an automation track.
It indeed can be a long list of parameters, and even while it's organized in groups per sub-module, it still can be daunting to find the right parameter in that list. Tip: You can limit the list if the track points to a deeper sub-module cause the list only contains parameters of that module and any child modules. So the deeper the track module, the shorter the parameter list.

Anyway there is a very simple and easy way to avoid that list and create an automation track:
Just drag-drop the parameter on the + track button.

Implementing this retrospectively within a large project is hardly possible, as subsequently splitting a project into individual *.mux parts means that the corresponding controls on the front panel have to be recreated, especially since they do not follow the resulting additional sub-level (they apparently have no direct/fixed connection to the individual target parameter).

I understand your constructive criticism here. You certainly are nicely stress-testing MuLab with your extensive MUX modular presets and projects Interesting and challenging.
Possibly not all of these challenges can immediately be handled on very short term, but i appreciate your feedback, and lets see how MuLab continues to grow the coming months and years.

[tiger001]

a shortcut to select (total) lane would be most helpful

please include gain on the work area below the lanes
(there'"s place enough)

2025-11-01 02_58_25-MuLab App _ FBF_A.jpg

[MuTools]

please include gain on the work area below the lanes

It's already there: See the 2 knobs at the right side of that panel:Top one is gain, bottom one is pan.

[MuTools]

Dropping a sample into the Audio Sequence editor does not yet auto slice it.
That's an interesting idea

When adding a new sample to a new lane, the same New Audio Sequence Clip popup with Transient Marker and/or Auto Snap Length could appear.

Yes, that is if that preference is set to "Ask".

I've taken note of this feature suggestion and had a quick look at it but it needs more attention than expected. I also have another related idea of how the audio sequence system could be pushed to another level up and want to give the ideas good time to ripe.
As i'm already late on the M10.1 time schedule (due to a very difficult issue which took me almost a week last week) it will be postponed to later, sorry.

Note however that the next M10.1.16 will use another method of importing samples as audio sequence, a method that leaves the clip's Tempo Factor at 100%.
That has several advantages, also the advantage that you can import a sample as audio sequence and into a new clip and then cut/copy and paste the new sample events into another audio sequence. In previous versions that was more problematic if both clip's Tempo Factors were different.

[jd88]

Part 1 of the answer:

Before we misunderstand each other:

This is NOT about "automation tracks", but about the lists of possible target parameters for a MIDI CC when you want to automate a parameter using a MIDI controller, Arp (Like you postet example).

- - - - -

And these lists often have around 500 entries.

One project even has well over 800 entries.

- - - - -

Such a number of possible MIDI CC targets is not unusual. For example, VSTs repeatedly have an equally high or even higher number of possible target parameters (e.g., some UHE VSTs...).

The point is:

That the lists within the *.Mux contain far too many superfluous targets, which unnecessarily inflate the lists and lead to confusion...

They are displayed in a disorganized manner, and unfortunately, the naming also corresponds to the internal naming within the modular layer, making it difficult to know how to name them meaningfully to serve both purposes.

...I won't elaborate further here, otherwise the text will get too long...

The attached short video briefly shows such a list (part of a plugin). There are over 450 entries... (see fotos from a list )

Bildschirmfoto 2025-11-01 um 21.19.28.png

Many entries are completely unnecessary, as automating these parameters wouldn't make any sense.

- - - - -


PS:

I'll put this on hold for now anyway (I'm currently very busy).

- - - - -

I might come up with a naming workaround. (For sorting the target parameter list...). Perhaps numeric... then a - z. This wouldn't make much sense in the modular area, but it might be useful in automation.

- - - - -

QUESTION:
By the way, I can't find a way to simply rearrange the MP buttons (above the modular area) without losing any assignments.

[MuTools]

Part 1 of the answer:
Before we misunderstand each other:

To avoid misunderstandings please use the right terminology.
1) It's you who were using the word "automations" in your post.
2) The long list on Map MIDI CC is not showing parameters but target modules.

And these lists often have around 500 entries.
One project even has well over 800 entries.

Yes if you have a complex MUX modular patch, like the ones you are building, then indeed it's possible that the target module list gets long. That's simply the consequence of a complex modular patch with many copied deep nested MUXes. If you build a MUX with 100 sub-modules and you copy this MUX 10 times then indeed you have 1000 sub-modules. That's very ok, but it has consequences in that list. There is no option yet for a MUX creator to limit that list by indicating which modules are "important" and which are not.

That the lists within the *.Mux contain far too many superfluous targets, which unnecessarily inflate the lists and lead to confusion...

They are displayed in a disorganized manner, and unfortunately, the naming also corresponds to the internal naming within the modular layer, making it difficult to know how to name them meaningfully to serve both purposes.

Many entries are completely unnecessary, as automating these parameters wouldn't make any sense.

Technically, objecticely, all these listed target modules have at least 1 parameter hence they can be a target for the MIDI CC.
If you say that there are many target modules that don't make any sense, then that's a subjective aspect and MuLab cannot decide that in your place.

Maybe you're saying that a MUX patch creator should have an option to indicate whether a sub module can be a meaningful target for CC map (and possibly also for automation).
Maybe in some future version...? Not a short term plan though.

QUESTION:
By the way, I can't find a way to simply rearrange the MP buttons (above the modular area) without losing any assignments.

"buttons"?
"knobs" you mean?

Tell me in detail what functionality you're missing.
What would you call your requested function and what exactly should it do?

[MuTools]

PS:

If you say that there are many target modules that don't make any sense, then that's a subjective aspect and MuLab cannot decide that in your place.

If you disagree with this statement, thus if you know an objective method to reduce the target module list in the Map CC dialog, a method that would be ok to each and every use case for all users, then i'm curious for what you have in mind.

[MuTools]

MuLab App M10.1.16 beta is available on https://www.mutools.com/mulab/app/lates ... /beta.html

What's changed:

• When importing a sample loop as Audio Sequence and Auto Snap Loop is on, now another import method is used that leaves the Tempo factor at 100%, which is more comfortable.
• There was a microscopic issue with the Bars.Beats.Ticks.Micros times of events, especially when also a tempo factor was used. Fixed.
• In some specific cases Audio Sequences were not drawn correct in the time line. Fixed.
• At places where a Bars.Beats.Ticks time is being edited via a popup now a more luxurious version of that popup is used.
• Clip Property Panel: Via right-click tempo factor you can now do "Consolidate Tempo Factor" which will update the clips content and reset the clip's Tempo Factor to 100%.
  For sequence clips: The other clips playing that same sequence are also taken into account ie. their Tempo Factor is also updated so that they still sound the same as before.
• Clip Property Panel: "Tempo" aka "Tempo Factor" renamed to "Speed".
• Sequence editor: When the edited clip has a non 100% speed factor then rapidly changing event lengths using the length field in the Event Property Panel caused odd results. Fixed.
• Dropping a audio file on the composer's track header area below the + track button caused a pauze in playback while the audio import selector dialog was popped up. Fixed.
• Audio Sequence Editor: More space for the source sample name, if available.
• Other small improvements.

Sorry for the delay on the MuLab 10.1 Plugin beta.
Working on it.