MuTools wrote: Sat Nov 01, 2025 1:40 pmI 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 ripen.
MuLab 10.1.25
-
- KVRAF
- 5378 posts since 25 Jan, 2014 from The End of The World as We Knowit
F E E D
Y O U R
F L O W
Y O U R
F L O W
-
- KVRist
- 183 posts since 10 Dec, 2007 from A'pen
MuTools wrote: Tue Oct 28, 2025 12:24 pmWhether you get a question upon importing a sample as audio sequence depends on the preferences "Auto Create Transient Markers" and "Auto Snap New Audio Sequence Length".tiger001 wrote: Tue Oct 28, 2025 7:33 amhe ?Michael L wrote: Tue Oct 28, 2025 12:21 am 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.
i never get that popup (with transient marker etc etc) when adding a new sample
when i drop a sample on a new track, i only get the popup/question if i want a (new) audio sequence, audio stream etc etc
See MuLab menu -> Preferences -> Audio
i checked and have both values at their default, so YES
but i never get that (second) question/pop-up
-
- KVRist
- 183 posts since 10 Dec, 2007 from A'pen
bug ?
or missing feature?
i have a song which gradually get sped up
the tempo indicator in the composer doesn't reflect this so i thought, maybe because my tempo changes in the tempo track are only 0.1.0 of length, so i extended them over 8 bars, with same result
however, i noticed that when i hover over the tempo indicator, it shows a percentage
can the tempo indicator show the real slim tempo please?
(the percentage only shows very short period only when you hover over it)
-alternatively (have the possibility to) show the percentage permanently, next to the tempo
would be nice if we could see the actual tempo of the tempo change in the editor below
(now we always need to enter the clip to edit or see the tempo)
or missing feature?
i have a song which gradually get sped up
the tempo indicator in the composer doesn't reflect this so i thought, maybe because my tempo changes in the tempo track are only 0.1.0 of length, so i extended them over 8 bars, with same result
however, i noticed that when i hover over the tempo indicator, it shows a percentage
can the tempo indicator show the real slim tempo please?
(the percentage only shows very short period only when you hover over it)
-alternatively (have the possibility to) show the percentage permanently, next to the tempo
would be nice if we could see the actual tempo of the tempo change in the editor below
(now we always need to enter the clip to edit or see the tempo)
You do not have the required permissions to view the files attached to this post.
-
- KVRAF
- Topic Starter
- 13854 posts since 24 Jun, 2008 from Europe
Euh, indeed, that's exactly what Yes does, it does the action without question.i checked and have both values at their default, so YESWhether you get a question upon importing a sample as audio sequence depends on the preferences "Auto Create Transient Markers" and "Auto Snap New Audio Sequence Length".
See MuLab menu -> Preferences -> Audio
but i never get that (second) question/pop-up
If you want a popup question set the pref to "Ask".
-
- KVRAF
- Topic Starter
- 13854 posts since 24 Jun, 2008 from Europe
Indeed a fresh new bug as of M10.1.16.tiger001 wrote: Sun Nov 02, 2025 10:03 am bug ?
i have a song which gradually get sped up
the tempo indicator in the composer doesn't reflect this so i thought, maybe because my tempo changes in the tempo track are only 0.1.0 of length, so i extended them over 8 bars, with same result
Thanks for spotting this so fast
Will be fixed asap.
-
- KVRAF
- Topic Starter
- 13854 posts since 24 Jun, 2008 from Europe
PS: In fact this tempo display bug forced me to remove the M10.1.16 beta, as this bug can have consequences on other display places too. Will double-check all possible places, fix the bug and upload M10.1.17.
-
- KVRist
- 121 posts since 7 Apr, 2008 from germany
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.
1.) The entire context of the recent conversations (email/forum) revolved around assigning MIDI CC data in order to ultimately "automate" parameters (Like you said: Modules).
From my previous perspective: Ultimately, this type of control also falls under the topic of "automation."
2.) Sorry if I misunderstood your comment. If not:
If, for example, I want to automate the "panorama" via CC within a mixer channel (block/module), my experience so far has been that the entire mixer channel is the target module, and the panorama is the target parameter within that module.
Wow, I've been describing this incorrectly to the developers for decades, even during countless beta tests. Thanks, I've learned something new again
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.
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.
Of course, that's understandable. I'm not complaining about that with regard to parameter (or, as you say, module) automation.
My complaint is solely about the available rack send and audio output options. MuLab could (eventually, since it's not a priority) certainly recognize which goals don't make sense.
But it doesn't HAVE to be that way. Change requests and suggestions from us users are just that—suggestions. To reiterate: YOU are the programmer and initiator; ultimately, the software is what it is.
"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?
[/quote]
Yes I'm actually using the wrong term here. Sorry. Yes, I mean knobs. (S. Foto:)
jere The issue is this:
Since the TARGETS (as you say: modules - I always say parameters
) within, for example, the MIDI controller assignment list are displayed in the order of the buttons, it would be very helpful if the button order could be reordered. This way, the order within the list could be arranged logically.
Currently, the only options are "move" and "swap." However, with both actions, the buttons lose their original assignment (module/parameter or control).
I would simply like to be able to change only the order (position) of the buttons. (Reason as above.)
- - - - -
Thank you for your reply.
I'm sorry that the occasional language barrier (despite using Google Translate) caused some misunderstandings.
It'll be alright. You're doing a great job. 
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.
1.) The entire context of the recent conversations (email/forum) revolved around assigning MIDI CC data in order to ultimately "automate" parameters (Like you said: Modules).
From my previous perspective: Ultimately, this type of control also falls under the topic of "automation."
2.) Sorry if I misunderstood your comment. If not:
If, for example, I want to automate the "panorama" via CC within a mixer channel (block/module), my experience so far has been that the entire mixer channel is the target module, and the panorama is the target parameter within that module.
Wow, I've been describing this incorrectly to the developers for decades, even during countless beta tests. Thanks, I've learned something new again
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.
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.
Of course, that's understandable. I'm not complaining about that with regard to parameter (or, as you say, module) automation.
My complaint is solely about the available rack send and audio output options. MuLab could (eventually, since it's not a priority) certainly recognize which goals don't make sense.
But it doesn't HAVE to be that way. Change requests and suggestions from us users are just that—suggestions. To reiterate: YOU are the programmer and initiator; ultimately, the software is what it is.
"buttons"?QUESTION:
By the way, I can't find a way to simply rearrange the MP buttons (above the modular area) without losing any assignments.
"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?
[/quote]
Yes I'm actually using the wrong term here. Sorry. Yes, I mean knobs. (S. Foto:)
jere The issue is this:
Since the TARGETS (as you say: modules - I always say parameters
) within, for example, the MIDI controller assignment list are displayed in the order of the buttons, it would be very helpful if the button order could be reordered. This way, the order within the list could be arranged logically.Currently, the only options are "move" and "swap." However, with both actions, the buttons lose their original assignment (module/parameter or control).
I would simply like to be able to change only the order (position) of the buttons. (Reason as above.)
- - - - -
Thank you for your reply.
I'm sorry that the occasional language barrier (despite using Google Translate) caused some misunderstandings.
It'll be alright. You're doing a great job.
You do not have the required permissions to view the files attached to this post.
-
- KVRAF
- Topic Starter
- 13854 posts since 24 Jun, 2008 from Europe
Hi Jd88,
First of all:
For readability and comformity please use the quote + /quote tags to quote someone, instead of italic text.
Thanks.
Ok, on topic:
In the CC Map dialog, which listed target modules never make sense in an objective way?
"In an objective way" means: It can be programmed to strip meaningless modules from that list. Please give me a concrete example.
MUX meta parameters parameters are identified by an index.
So lets say Sustain = index 3, Release is index 4.
After swap Sustain = index 4, Release is index 3.
However on the front panel your 3rd slider still points to parameter index 3, and the 4th slider to parm 4. So after the swap the 3rd FP slider will change the release, the 4th FP slider will change the sustain.
I can understand that's not always what you want. Maybe a future version will have more options for such cases.
However i'd like to repeat that in the Map CC dialog, the "long list" is the module list, not the selected module's parameter list. So the need for rearranging meta-parameters just to make the Map CC dialog more easy is very limited.
You too!
First of all:
For readability and comformity please use the quote + /quote tags to quote someone, instead of italic text.
Thanks.
Ok, on topic:
Exactly.If, for example, I want to automate the "panorama" via CC within a mixer channel (block/module), my experience so far has been that the entire mixer channel is the target module, and the panorama is the target parameter within that module.
I can only repeat my question:My complaint is solely about the available rack send and audio output options. MuLab could (eventually, since it's not a priority) certainly recognize which goals don't make sense.
In the CC Map dialog, which listed target modules never make sense in an objective way?
"In an objective way" means: It can be programmed to strip meaningless modules from that list. Please give me a concrete example.
As explained via email:The issue is this:QUESTION:
By the way, I can't find a way to simply rearrange the MP buttons (above the modular area) without losing any assignments.
Since the TARGETS (as you say: modules - I always say parameters
Currently, the only options are "move" and "swap." However, with both actions, the buttons lose their original assignment (module/parameter or control).
MUX meta parameters parameters are identified by an index.
So lets say Sustain = index 3, Release is index 4.
After swap Sustain = index 4, Release is index 3.
However on the front panel your 3rd slider still points to parameter index 3, and the 4th slider to parm 4. So after the swap the 3rd FP slider will change the release, the 4th FP slider will change the sustain.
I can understand that's not always what you want. Maybe a future version will have more options for such cases.
I understand.I would simply like to be able to change only the order (position) of the buttons. (Reason as above.)
However i'd like to repeat that in the Map CC dialog, the "long list" is the module list, not the selected module's parameter list. So the need for rearranging meta-parameters just to make the Map CC dialog more easy is very limited.
No prob.I'm sorry that the occasional language barrier (despite using Google Translate) caused some misunderstandings.
Thanks.It'll be alright. You're doing a great job.
You too!
-
- KVRist
- 121 posts since 7 Apr, 2008 from germany
From my perspective (this is how I would solve it):MuTools wrote: Sat Nov 01, 2025 9:22 pm PS: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 wrote: Sat Nov 01, 2025 8:45 pm 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.
Two possibilities:
During creation, or afterwards:
Right-click on the module. Add an option that, when clicked, prevents it from being added to the automation list.
Or (better?):
In the automation overview (existing separate list), add another column where you can select whether this element/module/parameter should be excluded from the automation list.
-----
Set a corresponding flag in the relevant array. When the program reads the data (array) internally, the corresponding entry will then be skipped.
- - - - -
Since this way, users only have to react when they do NOT want something, users who do NOT need such an option will not be bothered with it at all. For them, nothing changes in their current workflow.
-
- KVRAF
- Topic Starter
- 13854 posts since 24 Jun, 2008 from Europe
Thanks for confirming that MuLab cannot reduce that target module list automatically, and that it would involve special interaction from the MUX patch creator, as that's the person who can decide such things.jd88 wrote: Sun Nov 02, 2025 6:13 pm Two possibilities:
During creation, or afterwards:
Right-click on the module. Add an option that, when clicked, prevents it from being added to the automation list.
Or (better?):
In the automation overview (existing separate list), add another column where you can select whether this element/module/parameter should be excluded from the automation list.
-----
Set a corresponding flag in the relevant array. When the program reads the data (array) internally, the corresponding entry will then be skipped.
- - - - -
Since this way, users only have to react when they do NOT want something, users who do NOT need such an option will not be bothered with it at all. For them, nothing changes in their current workflow.
Thx for your suggestions for how to implement this. Sure, there are such technical possibilities. But to be honnest that's not planned on short term. Because it feels to me like something that typically needs sufficient thought and certainly not an impulsive implementation. And also because you currently are the only user requesting such things while i have to take into account that there are many items on the wish list requested by multiple users, some items already on that list for a longer time, and so it's logical i should give more priority to such things.
Hope you understand.
Sorry that MuLab is far from perfect.
-
- KVRAF
- Topic Starter
- 13854 posts since 24 Jun, 2008 from Europe
-
- KVRAF
- Topic Starter
- 13854 posts since 24 Jun, 2008 from Europe
MuLab App M10.1.17 beta is available on https://www.mutools.com/mulab/app/lates ... /beta.html
What's changed:
What's changed:
- Due to a fresh new bug in M10.1.16, several value displays were not updating to newer values. For example the tempo display did not follow tempo automation anymore. Fixed.
- Other small improvements.
-
- KVRist
- 121 posts since 7 Apr, 2008 from germany
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.
I still owe you this answer. (1 example)In the CC Map dialog, which listed target modules never make sense in an objective way?
-----
- - - - -
And now let's end this topic here. I understand your point of view.
I'm excited to see what other great features MuLab will get in the future. Again: Great work!
You do not have the required permissions to view the files attached to this post.
-
- KVRAF
- Topic Starter
- 13854 posts since 24 Jun, 2008 from Europe
FYI: The quotes in your reply are not correct.
About that screenshot: Yes you found 1 exception: A MUX without any used meta-parameters is also listed in the Map CC dialog, while it indeed should not be listed as it has no target parameters. Eventhough that's rather exceptional, i've taken note about it. Thx for reporting that.
Have a good night.
About that screenshot: Yes you found 1 exception: A MUX without any used meta-parameters is also listed in the Map CC dialog, while it indeed should not be listed as it has no target parameters. Eventhough that's rather exceptional, i've taken note about it. Thx for reporting that.
Have a good night.
-
- KVRAF
- Topic Starter
- 13854 posts since 24 Jun, 2008 from Europe
MuLab App M10.1.18 beta is available on https://www.mutools.com/mulab/app/lates ... /beta.html
MuLab Plugin M10.1.18 beta is available on https://www.mutools.com/mulab/plugin/la ... /beta.html
What's changed:
MuLab Plugin M10.1.18 beta is available on https://www.mutools.com/mulab/plugin/la ... /beta.html
What's changed:
- Also MuLab Plugin Demo version now allows saving via its own Project menu.
However MuLab Plugin Demo does not store + restore its data into / from the host, that still requires a user key. - Map MIDI CC dialog: MUX Modulars without any effectively used parameters are not listed as target module anymore.
- Better icon for the converter modules.
- "Default Auto Scroll" preference now itself defaults to Off. (was On)