I'd heard good things about MU.LAB so I put it on my list as I look for a replacement for energyXT (which replaced Cubase SX which replaced Logic, over the years). I write up notes on things while I'm trying them out so I can remember what I liked/disliked about various programs. If anybody's interested, here's what I wrote to myself about MU.LAB. There are many things I couldn't figure out, even though I read all the documentation. This is not an extensive list, it's just what I noted while getting far enough into MU.LAB to decide whether to continue. At this point I'm thinking the windowing issues I mention may kill it for me. That and it was crackling.
Overall:
Definitely promising. The modular plugin area seems well-done and allows feedback loops. I like the separation of tracks from instruments. The per-part output assignments are a little strange, but would allow per-part effects. Hmm. Although MU.LAB looks powerful and flexible, the workflow didn't seem streamlined enough to examine the midi and audio capabilities in much detail at this time. I could look harder if the bar lines in the midi editor were fixed.
Likes:
- No installer!
- Pre/post fade control is easy.
- Independent panning of left/right channels, although I couldn't figure out how to use it.
- Multi-out VSTs are handled in racks and the modular area.
Problems:
- Using top-level windows for everything doesn't work so well on Windows. It makes it hard to switch applications (e.g., between MU.LAB and viewing a tutorial), and Windows' insistence on bringing a window to the top of the stack when it's clicked on means that clicking on the timeline often causes the VSTi GUI window you're working with to be covered by the composer window instead of alwayas floating on top of it.
- I recorded a midi part starting on beat 2. When I double-clicked it to open the editor, beat 2 was on the first beat of the editor and all the bar lines were subsequently misplaced. This made it impossible for me to understand the part's rhythm as I edited it.
- It's difficult to see what's routed where. For example, in KraftGroove I can click on "Control2" and see it's routed to MuSynth, but where is the MuSynth? In the rack I see Base, BlipSnare(3), etc., but nothing called MuSynth. Where is Control2 routed?
- I couldn't figure out how to route control parts, e.g., Control2 in KraftGroove.
- The modular plug area looks cool, but I couldn't figure out how to open it. The documentation explains what it can do once it's opened, but not how to create/open it. Ok, I found it, it's in Edit menu > Show Coposer & Plug Area (F3). Parts can be routed to synths in this area.
- I couldn't figure out how to assign CCs to VSTi parameters, despite it being in the FAQ. Ok, I figured it out. It seems the CC always controls the parameter, no matter what is active or whatever. Now, how to see what controls what? "Edit MIDI controller map" under "assign MIDI controller" just brings up an empty grid.
Things that could be better:
- Need to create and populate a rack, or add a synth to the modular area, before routing to it.
- The sends are nice. Muting them could be easier.
- Turning processing on or off could be easier, and there should be visual feedback for whether processing is on or off. Oh, the text gets somewhat gray, that's hard to notice.
- Doing "expand all" on the rack, then setting "auto collapse/expand", then clicking on a rack slot, causes the slot to move to the left as the rack is collapsed.
Random feedback while evaluating MU.LAB
-
- KVRAF
- 1645 posts since 24 May, 2002
-
- KVRist
- Topic Starter
- 253 posts since 29 Nov, 2004
You're welcome. I liked mu.lab and hope my feedback is helpful; it's meant to be.
For me, small issues like how the bars line up in the midi editor aren't a big deal because I suspect they'd be fixed rather quickly (if they're bugs, and not just me not getting something). Other things like send mutes I'm less sure about since there's no telling what might happen with that. At the top of the scale is the way windows are used in the interface such that I was constantly having to restack plugin GUIs above the composer window (I've only got one monitor); that was frustrating and it's probably a deep part of the design that isn't likely to change. But maybe I'm missing something there as well, like a "plugin guis are always on top" preference.
For me, small issues like how the bars line up in the midi editor aren't a big deal because I suspect they'd be fixed rather quickly (if they're bugs, and not just me not getting something). Other things like send mutes I'm less sure about since there's no telling what might happen with that. At the top of the scale is the way windows are used in the interface such that I was constantly having to restack plugin GUIs above the composer window (I've only got one monitor); that was frustrating and it's probably a deep part of the design that isn't likely to change. But maybe I'm missing something there as well, like a "plugin guis are always on top" preference.
-
- KVRAF
- 1645 posts since 24 May, 2002
Yo atomota,
Better late than never, and so here is my in-depth reply:
They both have advantages and disadvantages as you also wrote.
Like in this case: The 'Control2' sequence part targets the plugin named 'MuSynth' (which can be renamed as you like) which is inside Rack named 'Line2'.
Some tip: In the Part Property Panel (top right) you can also click on the 'Edit Target' button (info: next version will show tool tips for those buttons there) to popup the target plugin editor.
So it's not always necessary to search the Racks or the MPA (Modular Plugin Area) to open a plugin editor
Now if you would look in the sequence editor, you would see that it is controlling the 'Cutoff' parameter.
Of course i agree that it may be more clear to have this sequence named 'Cutoff control'.
In fact, MU.LAB offers 2 MIDI controller mapping modes: "Global Span" or "Focus Span".
When you map a MIDI controller with "Global Span", then the mapping is always active.
When you map a MIDI controller with "Focus Span", then the mapping is only active when the respective plugin is focussed.
But in version 1.1, you can only do global mappings. The 'Edit MIDI Controller Map' in the plugin context menu edits the mappings when that plug has the focus, and so this maps stays empty.
So in the current version, you need to do main Edit menu -> Edit Global MIDI Controller Map to edit the MIDI controller assignments. The 'Edit MIDI Controller Map' in the plugin context menu is currently unused.
This will change in the coming version 2.0, as then you'll be able to choose whether a MIDI controller must be mapped with "Global Span" or "Focus Span".
Do you see a neat alternative?
Thanks again for your detailed feedback!
Better late than never, and so here is my in-depth reply:
The new docs for the next version (ETA end of june) include info on this.atomota wrote: - Independent panning of left/right channels, although I couldn't figure out how to use it.
So what would you like most for plugins: top-level windows that stay on top all the time? Or standard windows that get behind other windows which you click on?Problems:
- Using top-level windows for everything doesn't work so well on Windows. It makes it hard to switch applications (e.g., between MU.LAB and viewing a tutorial), and Windows' insistence on bringing a window to the top of the stack when it's clicked on means that clicking on the timeline often causes the VSTi GUI window you're working with to be covered by the composer window instead of alwayas floating on top of it.
They both have advantages and disadvantages as you also wrote.
Originally it was intended behaviour. But it will be changed so that the Note Editor also shows the Part time.- I recorded a midi part starting on beat 2. When I double-clicked it to open the editor, beat 2 was on the first beat of the editor and all the bar lines were subsequently misplaced. This made it impossible for me to understand the part's rhythm as I edited it.
Note that parts and sequences not only can target Racks, but also every individual plugin within or outside a Rack.- It's difficult to see what's routed where. For example, in KraftGroove I can click on "Control2" and see it's routed to MuSynth, but where is the MuSynth? In the rack I see Base, BlipSnare(3), etc., but nothing called MuSynth. Where is Control2 routed?
Like in this case: The 'Control2' sequence part targets the plugin named 'MuSynth' (which can be renamed as you like) which is inside Rack named 'Line2'.
Some tip: In the Part Property Panel (top right) you can also click on the 'Edit Target' button (info: next version will show tool tips for those buttons there) to popup the target plugin editor.
So it's not always necessary to search the Racks or the MPA (Modular Plugin Area) to open a plugin editor
Now if you would look in the sequence editor, you would see that it is controlling the 'Cutoff' parameter.
Of course i agree that it may be more clear to have this sequence named 'Cutoff control'.
The new docs are updated, thanks.- The modular plug area looks cool, but I couldn't figure out how to open it. The documentation explains what it can do once it's opened, but not how to create/open it.
This indeed is an ambiguous issue in version 1.1.- I couldn't figure out how to assign CCs to VSTi parameters, despite it being in the FAQ.
Ok, I figured it out. It seems the CC always controls the parameter, no matter what is active or whatever.
Now, how to see what controls what? "Edit MIDI controller map" under "assign MIDI controller" just brings up an empty grid.
In fact, MU.LAB offers 2 MIDI controller mapping modes: "Global Span" or "Focus Span".
When you map a MIDI controller with "Global Span", then the mapping is always active.
When you map a MIDI controller with "Focus Span", then the mapping is only active when the respective plugin is focussed.
But in version 1.1, you can only do global mappings. The 'Edit MIDI Controller Map' in the plugin context menu edits the mappings when that plug has the focus, and so this maps stays empty.
So in the current version, you need to do main Edit menu -> Edit Global MIDI Controller Map to edit the MIDI controller assignments. The 'Edit MIDI Controller Map' in the plugin context menu is currently unused.
This will change in the coming version 2.0, as then you'll be able to choose whether a MIDI controller must be mapped with "Global Span" or "Focus Span".
How could this be better in your opinion?Things that could be better:
- Need to create and populate a rack, or add a synth to the modular area, before routing to it.
How so?- The sends are nice. Muting them could be easier.
Yes, otherwise there would be 'gaps' between the Racks which would not be very neat.- Doing "expand all" on the rack, then setting "auto collapse/expand", then clicking on a rack slot, causes the slot to move to the left as the rack is collapsed.
Do you see a neat alternative?
Thanks again for your detailed feedback!
-
- KVRist
- Topic Starter
- 253 posts since 29 Nov, 2004
Thanks for your very considerate replies!
I'm looking forward to trying the next version, hopefully around the end of June as you say. I'll get back to you on the ambiguities you pointed out in my post. Some of it was a bit of a first-impression ramble; I thought it might be interesting for you, who understands MU.LAB literally inside and out, to see a bit of the view from a first-timer who's puzzling out "I know you can do this . . . but how?" kinds of things -- and sometimes getting stumped. Because you never get a second chance to make a first impression, as they say
I should have mentioned under "likes" that I do like the short and sweet doc, which is a good omen, but there were things it seemed to be missing.
I'm looking forward to trying the next version, hopefully around the end of June as you say. I'll get back to you on the ambiguities you pointed out in my post. Some of it was a bit of a first-impression ramble; I thought it might be interesting for you, who understands MU.LAB literally inside and out, to see a bit of the view from a first-timer who's puzzling out "I know you can do this . . . but how?" kinds of things -- and sometimes getting stumped. Because you never get a second chance to make a first impression, as they say
I should have mentioned under "likes" that I do like the short and sweet doc, which is a good omen, but there were things it seemed to be missing.
-
- KVRAF
- 1645 posts since 24 May, 2002
-
- KVRist
- Topic Starter
- 253 posts since 29 Nov, 2004
IMHO, the only reasonable choice for plugins is windows that stay above MU.LAB, but beneath any other app that is on top of MU.LAB, and that disappear/reappear when MU.LAB is minimized/restored. (Really I'd like multiple desktops ala Unix/Linux and forget minimize/restore, but this is Windows . . .) And, for it to be possible to bring all the MU.LAB windows to the top with one action.muzycian wrote:So what would you like most for plugins: top-level windows that stay on top all the time? Or standard windows that get behind other windows which you click on?Problems:
- Using top-level windows for everything doesn't work so well on Windows. It makes it hard to switch applications (e.g., between MU.LAB and viewing a tutorial), and Windows' insistence on bringing a window to the top of the stack when it's clicked on means that clicking on the timeline often causes the VSTi GUI window you're working with to be covered by the composer window instead of alwayas floating on top of it.
Ok, it took me a while, but I found it. I think I wasn't realizing that plugins and racks both have names, and I wasn't looking at the plugins inside the racks.Note that parts and sequences not only can target Racks, but also every individual plugin within or outside a Rack.- It's difficult to see what's routed where. For example, in KraftGroove I can click on "Control2" and see it's routed to MuSynth, but where is the MuSynth? In the rack I see Base, BlipSnare(3), etc., but nothing called MuSynth. Where is Control2 routed?
Like in this case: The 'Control2' sequence part targets the plugin named 'MuSynth' (which can be renamed as you like) which is inside Rack named 'Line2'.
It's ok how it is, I was thinking of say energyXT's right-click to select a plugin and you get a new track routed to that plugin, which may not work with MU.LAB's way of doing things.How could this be better in your opinion?Things that could be better:
- Need to create and populate a rack, or add a synth to the modular area, before routing to it.
As far as I can figure, you have to right-click a send or plugin and select process off to mute or bypass it. That's a lot of work; I mute/bypass a lot when I'm working. (And I'm always getting confused: Process OFF means the processing is actually ON, and can be turned OFF.) It's easier to just click a mute or bypass button, or even ctrl-click the plugin name or something. That's how edit works: there is a button, and double-click also works. I personally don't like my scarce screen real estate taken over with lots of little buttons (one of the reasons I didn't like working with Cubase). My ideal system? Click to mute/bypass/whatever, double-click to edit, no buttons, no modifier keys.How so?- The sends are nice. Muting them could be easier.
It's just a little jarring to click on something to use it and then have it be somewhere else. With auto collapse/expand, only one rack is expanded at a time, right? So setting auto collapse/expand could set one rack to expanded. Not a big deal though.Yes, otherwise there would be 'gaps' between the Racks which would not be very neat.- Doing "expand all" on the rack, then setting "auto collapse/expand", then clicking on a rack slot, causes the slot to move to the left as the rack is collapsed.
Do you see a neat alternative?
-
- KVRAF
- 1645 posts since 24 May, 2002
I fully agree that this is the most likable way! But it's really problematic to get it this way on Windows. (otherwise i'm missing the technical point). But finally i seem to have found a stable patch to make it work this way. Please check out the next versionatomota wrote:IMHO, the only reasonable choice for plugins is windows that stay above MU.LAB, but beneath any other app that is on top of MU.LAB, and that disappear/reappear when MU.LAB is minimized/restored.
In the next version, when choosing a Target for a part, you now also have the option "New Plug-In In New Rack", which shortcuts some intermediate stepsThings that could be better: Need to create and populate a rack, or add a synth to the modular area, before routing to it.
...
It's ok how it is, I was thinking of say energyXT's right-click to select a plugin and you get a new track routed to that plugin, which may not work with MU.LAB's way of doing things.
But just clicking a plug in a rack already has a function: it focusses the plug (i.e. it becomes the target for MIDI input).The sends are nice. Muting them could be easier.
...
As far as I can figure, you have to right-click a send or plugin and select process off to mute or bypass it. That's a lot of work; I mute/bypass a lot when I'm working. (And I'm always getting confused: Process OFF means the processing is actually ON, and can be turned OFF.) It's easier to just click a mute or bypass button, or even ctrl-click the plugin name or something. That's how edit works: there is a button, and double-click also works. I personally don't like my scarce screen real estate taken over with lots of little buttons (one of the reasons I didn't like working with Cubase). My ideal system? Click to mute/bypass/whatever, double-click to edit, no buttons, no modifier keys.
Anyway, just like alt-click the mute icon of a track = solo/unsolo, the next MU.LAB will support alt-click on a plugin name to toggle process on/off.
Improved behaviour in the next version.Doing "expand all" on the rack, then setting "auto collapse/expand", then clicking on a rack slot, causes the slot to move to the left as the rack is collapsed.
It's just a little jarring to click on something to use it and then have it be somewhere else. With auto collapse/expand, only one rack is expanded at a time, right? So setting auto collapse/expand could set one rack to expanded. Not a big deal though.
-
- KVRist
- 306 posts since 1 May, 2003
My email has changed and I have not receive updates in a very long time.
-
- KVRist
- Topic Starter
- 253 posts since 29 Nov, 2004
Amazing! Especially so since you're also working with OSX.muzycian wrote:I fully agree that this is the most likable way! But it's really problematic to get it this way on Windows. (otherwise i'm missing the technical point). But finally i seem to have found a stable patch to make it work this way. Please check out the next versionatomota wrote:IMHO, the only reasonable choice for plugins is windows that stay above MU.LAB, but beneath any other app that is on top of MU.LAB, and that disappear/reappear when MU.LAB is minimized/restored.
Yes, the current click and double-click functions are good choices for MU.LAB.But just clicking a plug in a rack already has a function: it focusses the plug (i.e. it becomes the target for MIDI input).The sends are nice. Muting them could be easier.
...
As far as I can figure, you have to right-click a send or plugin and select process off to mute or bypass it. That's a lot of work; I mute/bypass a lot when I'm working. (And I'm always getting confused: Process OFF means the processing is actually ON, and can be turned OFF.) It's easier to just click a mute or bypass button, or even ctrl-click the plugin name or something. That's how edit works: there is a button, and double-click also works. I personally don't like my scarce screen real estate taken over with lots of little buttons (one of the reasons I didn't like working with Cubase). My ideal system? Click to mute/bypass/whatever, double-click to edit, no buttons, no modifier keys.