My thoughts on MuLab after a few weeks of use

[MuTools]

The exception is MuLab -- every other program on all platforms uses right-click to select the object being right-clicked over, in my experience.

I was amazed by this statement so i checked some other music and non-music apps and almost immediately saw that several apps which don't apply to the rule you're describing. And i would really not want such rule. Imagine that right-clicking a track (eg for deleting a track) would automatically shift MIDI input focus to that track while i don't want that.
I've reread what mehum wrote and i still think he encountered that quick left-right-click = double-click bug, which has been fixed in M7.

[MuTools]

There is just one (1) thing that kills it al for me with MuLab/MUX.
In MUX you can change the font size. The fonts of the browser for example. This is great. But you can NOT change the font size of the audio browser if Sampla.
It shouldn't be a problem to fix this. As the fucntion is allready there on all other browsers - expect this one.
The developer has bee informed about this a couple of times. From me and others...still no fix...

Believe me i'm working on a solid solution wrt font sizes / scalable UI, as those topics are related. It's not yet planned for M7.0 itself, but in the background i'm working on this, step by step.

[sl23]

The exception is MuLab -- every other program on all platforms uses right-click to select the object being right-clicked over, in my experience.

I was amazed by this statement so i checked some other music and non-music apps and almost immediately saw that several apps which don't apply to the rule you're describing. And i would really not want such rule. Imagine that right-clicking a track (eg for deleting a track) would automatically shift MIDI input focus to that track while i don't want that.
I've reread what mehum wrote and i still think he encountered that quick left-right-click = double-click bug, which has been fixed in M7.

As far as I'm aware, any program I've ever used has this function. Whatever the cursor is over when right clicked, focus is moved to that object and the context menu appears with regard to the newly focused object.

Should multiple objects be selected then the right click should be performed within the bounds of the objects selected.

[sfd]

Believe me i'm working on a solid solution wrt font sizes / scalable UI, as those topics are related. It's not yet planned for M7.0 itself, but in the background i'm working on this, step by step.

I'm really glad to hear that !

If it's possible to implement the way one cna change the font size of the general browser to the audio browser it would be really great. Becase for me as visually impaired it's a very very good thing to be able ot pick the font size suitable fo rmy eyes. I liked that a lot with MUX...it's just this audio browser.

Keep up the great work !

[pljones]

I was amazed by this statement so i checked some other music and non-music apps and almost immediately saw that several apps which don't apply to the rule you're describing.

Simple example. Click to start replying to this and then right-click the location bar in your browser. Focus moves, the context menu appears. That's the common expectation for GUI behaviour. Everything else has to be learnt as an exception to that rule. That's my point - it's not that there are no exceptions, it's that that rule is followed - but with exceptions and the exceptions are what make things hard to learn. The more places it's not followed, the more learning there is before the user is comfortable and stops feeling alienated.

[MuTools]

1) For example Firefox: Right-clicking a tab does not select that tab. I can perfectly reload a tab via right-click without having to select it, and that's a good thing. Just a quick example.
2) MuLab: For example: Right-clicking a track should not select that track. I'm convinced about that. Otherwise if i'm playing with a sound and right-click another track to delete it that would kill my sound.

[Grizzellda]

Don't argue with the developer about Right-clicking! He loves Right-clicking!

I think I agree, actually...

[liquidsound]

Don't argue with the developer about Right-clicking! He loves Right-clicking!

I think I agree, actually...

That's why it's called "Right". It must be right!
One of the things I actually like about using MuLab.

[Grizzellda]

That's why it's called "Right". It must be right!

Heh heh, and I've been wondering lately if Jo is gonna change the mouse behavior in the piano roll to be more like Fruity...

The more I think about it, the cooler it gets!

[liquidsound]

That's why it's called "Right". It must be right!

Heh heh, and I've been wondering lately if Jo is gonna change the mouse behavior in the piano roll to be more like Fruity...

The more I think about it, the cooler it gets!

The right click "Pan" of MuLab is the best in the business.
FL uses the MMB and it's a pain for me.

Since I tried most of the DAWs out there I sincerely think that the ergonomic of MuLab pianoroll are near perfection.
In fact it was the reason I gravitated toward it from v2.x.
I could imitate it with Reaper but, when you do it in Reaper, there is a problem with the cursor which it turns into a selector and it looses some functions.
So , there you have it. MuLab has a Unique pianoroll ergonomic. A powerful one.

[Grizzellda]

Hey, I agree, I love MuLab's piano roll, for sure. It is a big part of why I got into MuLab. The colour customization and zooming is superb!!! But in a thread a while back a few guys were asking for Fruity type action. At first I wasn't interested, but when I thought about it, the whole notion began to seem pretty darn cool...

The idea was to develop special tools for the PRV that wouldn't affect the whole "Right-click" flow of the program. That could be pretty interesting.

[liquidsound]

I must agree that FL has a very elaborate and powerful pianoroll.
Too much for me though. With MuLab I can write as fast as I can hear notes in my head.
So simple (yet deep) and with the right actions at my fingertips.
A dream.
FL got my full attention many many times and I'm one of those users that can't get into its flow. Something about it.....
Now I'm using just MuLab and Live (sessions mostly). I feel very fortunate that my search has ended.

[mehum]

As pljones already mentioned: No you're not forced to use racks, you're free.

And as I replied to pljones, sure, but you also lose the benefits of using racks

Yes it is possible. You can combine all kinds of audio, event and modulation signals.

Yeah, but not when they're inside racks... Again, I find that the racks (although limited) are necessary to keep a lean workflow.
I'd like super racks with unlimited space both pre- and post-fader and with possibility to expose specified inputs and outputs from the modules or plugins in each space

It's practically the same: Click a track or rack will route MIDI input to that track / rack.

Didn't you make a track for it? If yes the you can simply click the track to play that MuDrum.

Well, I think that's what I did. As i recall it selecting the track and playing did nothing while moving other midi events to that track did trigger the MuDrum until I also used a rack (which event output I then could connect to the MuDrum in the modular area). I might have just done something wrong though

This simplicity has the advantage you don't have to arm tracks! That's a big advantage imho. Just click record and capture your inspiration.

And this would be easily done with an auto arm-option (as most DAWs have in my experience). The record arm and monitor buttons serve also as visual cues which track(s) are active.

When working alone this is not a very big problem but then I imagine recording someone else and wanting to tweak a reverb or something on another channel...

You can record several MIDI channels at the same time, the resulting MIDI parts will be automatically put on the relevant tracks.

What does "relevant tracks" mean? How is this visually presented? This was very non-obvious to me... Again, since I didn't need to do it I did not bother to lock it up, I just thought about it and didn't understand.
I my mind, this should be an obvious thing. In probably all other DAWs I've used I choose the input I want to use for each track, arm them and press record. In MuLab I don't even see on the tracks which input goes where. Will my guitar go to my hihat track? Which one of my Midi interfaces are connected where?
I think the perceived simplicity comes back and bites you in the neck when setting anything more advanced than one input.

I assume you did some fast left-right-clicking, right?

That was probably it!
Does not, however, explain why double clicking sometimes deletes parts in the composer area...?

Editing part lengths overall is a hassle and often the effect was not obvious. Same thing with notes.

Well, I'm not really sure, actually I ended up trying to not end up having to do it instead. Anytime I was fiddling with loop markers and start/end of a part it just didn't seem to reflect what I wanted to do...

It simply takes 1 key press to select the option you want. In other hosts these options are not available (not ok) or they're hidden under hidden modifier key combies which is not ok either, imho, and certainly also not faster as you need a key press too.
So that's why popping up the available options is a good solution, imho.

Again, I like the options, but being a less than great keyboardist I often end up wanting to do a lot of editing and am used to work really fast. Getting a dialog each time is a bit like getting a dialog each time you write a word that asks if that was really the word you were intending to write
May I propose having for example Alt-Drag always using the last chosen option (and of course describe this behavior in the dialog)?

the difference between Relative and Percent.

I understand your point. Which terms would describe them better?

I don't really know how to describe them better. Would it be possible to actually preview the result while hovering over each option? That would truly be the best way to make it clear.

Only occurs when your parts/notes are very small and indeed i can't change the physical reality that only a few pixels are only a few pixels. Do you see a solution for that?

Well, first of all, many times the notes certainly seemed big enough for it to be unambiguous whether I wanted to select or resize. And even if I only have 3 pixels on screen this should be doable. I'd just recommend trying it in other DAW:s and reverse engineer from there

A shared part is indicated with a 'link' icon in its titlebar. I think that's clear. Maybe you didn't notice it as you're new to MuLab?

Easy enough in the composer area, I was talking more in the edit area. But of course, like many other of my points, part of it is being unexperienced with MuLab.

Happens when you have a mixture of event types eg notes and controllers.

And how do I know this? What I (at least thought I) did was selecting notes in the edit window...

About tracks and racks:
Basically they're indeed independent and free towards eachother but MuLab supports a coupled approach because that's what many users are used too. The support for track-rack coupling can and will be extended and improved in M7. You're right that when using multi-out VSTs the racks may not be the ideal solution, depending on which routing you need. In M7 there will be important improvements in this context.

But hard-linking tracks and racks has the disadvantage that when you have a simple send effect rack then you _have to_ have a track for it, which may be annoying, imho. If you think of it in more real life then isn't it perfectly logical and natural that tracks and racks are independent and free?!

It seems like you're on the right track (no pun intended) here, optionally coupling tracks and racks and extending that coupling when present.
This is a lot about striking a balance between a lean workflow and the freedom of the modular area. And, as you might have gathered, for me this balance has not been struck as of version 6.

The background reason is cause it's a continuous parameter. Showing it as 1/8, 1/16 etc can't be done in a continuous way.

Yes, I realize this, and that's cool, but it takes away some usability. Especially when automating these parameters. This is where I'd propose two things: Have an option to view and snap to standard time for the parameter in question and in automation, always view the common times alongside the Cpb and have gridlines reflecting these values.

Double-click the value and enter eg "1/8" that will do the math for you.

That's good (and not obvious...)! I'm guessing 1/12 for triads then?

it's certainly not my ambition to make MuLab the same as Reaper

Well, if I wanted another Reaper I'd just run another instance of that
So no, of course MuLab shouldn't be Reaper and I've tried not to, at least not explicitly, compare to Reaper either. I've used a great number of other DAWs (going back to Cubase VST, or Amiga trackers if they count ). All have had their strengths and weaknesses...
It's important to be unique but at the same time also important to balance this uniqueness against expectations.

To me this was a great chance to try MuLab out unfettered and I'm pretty happy with resulting tune so that's a compliment to MuLab as well, of course

Here's the track if interested and there's also a link to the project...
http://www.kvraudio.com/forum/viewtopic ... 8#p6276338

[MuTools]

Yeah, but not when they're inside racks... Again, I find that the racks (although limited) are necessary to keep a lean workflow.
I'd like super racks with unlimited space both pre- and post-fader

Super racks already exist: They'er called MUXes. Unlimited pre/post slots, unlimited routing options, ... And it still fits in a single rack slot.

That said: In M7 also the racks themselves will improve, featurewise, without compromising their essential simplicity.

You can record several MIDI channels at the same time, the resulting MIDI parts will be automatically put on the relevant tracks.

What does "relevant tracks" mean?

Same target module, same MIDI channel.

This was very non-obvious to me... Again, since I didn't need to do it I did not bother to lock it up, I just thought about it and didn't understand.

Maybe certain more complex situations can be handled better in more complex organized hosts, but i made certain conecptual choices towards the benefits of simplicity.
Which one is perfect: Simplicity or Complexity? Well both of them and none of them, it depends from person to person and from case to case.
Essentially i choose for simplicity, but not in a dumb simple way, but 'the good simplicity' and backed up by a the deeper modular level, so it's an 'open simplicity'.
That's my view. No doubt that, like almost all other apps, also MuLab and MUX can be further streamlined and extended, that's what i'm working on.

Which one of my Midi interfaces are connected where?

MULAB menu -> MIDI Setup: There you define which MIDI ins/outs you wanna use.
Then MIDI input always goes to the focused track's target module, in short: The focused track.
MIDI output is done using a MIDI out module and so you can choose what event streams go to which MIDI outs.

I assume you did some fast left-right-clicking, right?

That was probably it! Does not, however, explain why double clicking sometimes deletes parts in the composer area...?

Pls see http://www.mutools.com/info/docs/mulab/composer.html

About tracks and racks:
Basically they're indeed independent and free towards eachother but MuLab supports a coupled approach because that's what many users are used too. The support for track-rack coupling can and will be extended and improved in M7. You're right that when using multi-out VSTs the racks may not be the ideal solution, depending on which routing you need. In M7 there will be important improvements in this context.
But hard-linking tracks and racks has the disadvantage that when you have a simple send effect rack then you _have to_ have a track for it, which may be annoying, imho. If you think of it in more real life then isn't it perfectly logical and natural that tracks and racks are independent and free?!

It seems like you're on the right track (no pun intended) here, optionally coupling tracks and racks and extending that coupling when present.
This is a lot about striking a balance between a lean workflow and the freedom of the modular area.

100% agreed.

And, as you might have gathered, for me this balance has not been struck as of version 6.

I know there is room for improvement especially when using multi-out VSTs and side-chaining while still staying in the easy rack world.
The next M7 will have important improvements there.

Double-click the value and enter eg "1/8" that will do the math for you.

That's good (and not obvious...)! I'm guessing 1/12 for triads then?

Sure, also 5/7, 9/12, etc works.

it's certainly not my ambition to make MuLab the same as Reaper

Well, if I wanted another Reaper I'd just run another instance of that
So no, of course MuLab shouldn't be Reaper and I've tried not to, at least not explicitly, compare to Reaper either.
I've used a great number of other DAWs (going back to Cubase VST, or Amiga trackers if they count ).
All have had their strengths and weaknesses...
It's important to be unique but at the same time also important to balance this uniqueness against expectations.

Fully agree. And i understand your constructive feedback. Will do my best to further grow & mature MuLab & MUX. Thx again!

To me this was a great chance to try MuLab out unfettered and I'm pretty happy with resulting tune so that's a compliment to MuLab as well, of course

Cheers!

Here's the track if interested and there's also a link to the project...
http://www.kvraudio.com/forum/viewtopic ... 8#p6276338

Awesome track, nice groove, nice sound, lovely musicality!! Really enjoyed listening to it
Would love to welcome this as a MuLab demo track! Would that be ok with you?

[mehum]

Maybe certain more complex situations can be handled better in more complex organized hosts, but i made certain conecptual choices towards the benefits of simplicity.
Which one is perfect: Simplicity or Complexity? Well both of them and none of them, it depends from person to person and from case to case.
Essentially i choose for simplicity, but not in a dumb simple way, but 'the good simplicity' and backed up by a the deeper modular level, so it's an 'open simplicity'.
That's my view. No doubt that, like almost all other apps, also MuLab and MUX can be further streamlined and extended, that's what i'm working on.

Yes, this is very much personal preferences. To me a slightly more advanced interface would not make it more complex but actually simpler because of the overview it would give me. That is why I think the current approach becomes over simplistic.

Awesome track, nice groove, nice sound, lovely musicality!! Really enjoyed listening to it
Would love to welcome this as a MuLab demo track! Would that be ok with you?

Thank you, I'd be honored to have it featured as a demo track! Not only stock effects used though, but all are of course freeware, this being OSC.