MU.LAB 2.0 PreRelease

[Bonteburg]

quick idea for locator handling - "Create locator ever x beats", "Divide into 8, 16, 32 etc equal parts using locators" or something similar for really smooth loop creation! Not sure how easy it is to implement mind...

[MuTools]

What would happen in the Free version? Would all the new parts end up on the last track?

In Free, then IF there are no tracks available, then the new recorded part would come on the focussed track, as is now.

In the situation as described earlier in this thread, this means there will be overlaying parts, which is logical in such case, imho.

[MuTools]

1) it would be real neat if we could organize (group) vsts inside the vst plugin manager:
CHOOSE VST PLUGIN >> effects >> eq >> list of installed eqs
or
CHOOSE VST PLUGIN >> synths >> drum >> list of installed drum synths

Well, it's in there: See Plugin Manager -> 4th column : "Group".

I think it does exactly what you want.

u know how the grid lines in mulab are black and dark gray. also, the vertical line which shows the playback position is black. and this can look confusing when u are tired and still working, so i suggest that the playback line should be red and bold so it could be easily distinguished. or maybe green, but i still vote for red.

Or green when playing, red when recording

I think you're right with your comment, and added a note to the whishlist to make the play position line skinnable, so it will be flexible in the future.

3) is it just me who dont know how to change this, or has mulab become 'always on top'? this isnt good, we should have a choice. i have to minimize mulab every time i want to access the start menu

Mmm, that's strange.

Normally, when you run MU.LAB for the first time, it should come in a maximized window, but that should exclude the taskbar with the start menu etc... Isn't it like that?

Anyway, you can always resize the main window by moving the borders.

[MuTools]

quick idea for locator handling - "Create locator ever x beats", "Divide into 8, 16, 32 etc equal parts using locators" or something similar for really smooth loop creation! Not sure how easy it is to implement mind...

You mean in the audio lab?

[Bonteburg]

yeah . the sample editor ...

On second thought, I think a "create *x* evenly spaced locators" option would be pretty much it - that way MU.LAB wouldn't even have to know the bpm.

[infectedpimple]

I decided I'd try out the pre-release to see how things are coming along, and it's looking rather nice, but I was instantly annoyed with a couple aspects of the interface, the first of which is that I like to use auto-hide on the XP taskbar, and Mu.Lab sits rather rudely over it in such a way that I can't see my taskbar when it auto-unhides. I can use the window key to bring up the taskbar, but that means an extra trip to the keyboard; and I could resize the Mu.Lab window, but that's lame, because the whole purpose of the auto-hide is to maximize screen space while retaining the ability to quickly use the taskbar. Generally I guess maybe I'm kinda da oldskoolz anyhow and like Windows windows to act like other Windows windows, but perhaps I'm in the minority on this. But it brings me to the other aspect that just plain bugs the heck out of me, and that is that I can't drag windows off the edge of the screen. It feels terribly claustraphobic. I can understand the good intentions behind erecting those invisible walls, I suppose, but the end result is that it feels like I'm now having to battle the confines of the DAW itself just to create, on top of my own impatience and inadequacies. Somehow it just makes the software feel quite a bit less transparent and less open than it felt before, and its less conducive to the way I work/think. But then perhaps in this too I find myself in the minority.

Also, one thing I was thinking would be really, really nice, unless there's some detrimental trade-off in implementing it that I don't realize, is to have some basic filter/delay options on the sends themselves. Because I had these strings the other night, and I really wanted to stick them way back in my verb, with some extra pre-delay, without having to add another verb onto my poor cpu's back. Sending to another rack, sticking a delay on that, and then sending that other rack into my verb gets that job done, I guess, and I assume it can be similarly achieved using the modular plug area, but... sheepies, having to make a whole new rack, or connecting all those virtual wires, and adding a whole extra plugin to the heap seems like a lot of work for something that could be more easily done with an option to simply have the send delay itself by an abitrary or tempo-synced amount of time. And having the basic hi/lo/band/notch I could see being really helpful on sends too, like when you might want to do something crazy to the higher frequencies of a bass while leaving the lows. Or is that just something that isn't/can't be done?

Critiques and suggestions aside, though, Mu.Lab continues to give me a mainly positive vibe; I do still look gleefully forward to the day when the automation features are more refined, and probably wouldn't consider purchasing the unlimited license until then, but some great work overall... may your bugs be few in continued development!

-j

[Bonteburg]

But it brings me to the other aspect that just plain bugs the heck out of me, and that is that I can't drag windows off the edge of the screen. It feels terribly claustraphobic.

You know, I was thinking that myself but I thought it was just me - I still like the original "normal" MU.LAB windowing system best to be honest.

When the new windowing system arrived I wasn't all too sure about it but I thought, well nobody else seems to take issue.

There was a bug in it to begin with where you could potentially drag windows right off the screen and couldn't get them back again. Possibly that's why Jo chose to really crack down on those edges!

However when I really got to test the new version last night I did feel it was kind of limiting.
I can see myself getting used to it - what with the tabbed window system and all - but part of me almost wants to have that window-dragging bug back now.

[tomica]

I like to use auto-hide on the XP taskbar, and Mu.Lab sits rather rudely over it in such a way that I can't see my taskbar when it auto-unhides.

what he said.

[pljones]

I like to use auto-hide on the XP taskbar, and Mu.Lab sits rather rudely over it in such a way that I can't see my taskbar when it auto-unhides.

what he said.

Me three.

I'm not keen on messing the sends up with effects on the insides, though. It sounds like you want a MUX patch with two stereo outs.

[goyya76]

hi, i tried the prerelease - here are my quick thoughts:

- MUX + "global routing" view: excellent!:love:
- at a first sight workflow seems pretty fast
- a MUX VST version would rock
- MUX with configurable knobs? i mean, there's a row of 16 knobs - adding the option of more rows (like 1-2-3-4 rows, and maybe 1 or 2 rows of buttons - BCR lover here )?
- no support for two monitors? at least on my system, i didn't find a way to extend Mulab window over two monitors....

Still have to try more deeply all the remote control possibilities, but as far as i have seen not all the controls can be mapped (if i'm not wrong, some knobs on the synths for example) - if Mulab had every GUI / menu control mappable to CCs...(the question may be redundant, maybe it's just that i didnt realize it)

and...feedback to the hardware controller?


Ciao,
Goyya

[vervex]

I just want to say that I think the new windowing system is great. I hate to use the taskbar/Alt-tabbing to get back a window just because I click the main window.

I still have to try out all other new features

[MuTools]

I like to use auto-hide on the XP taskbar, and Mu.Lab sits rather rudely over it in such a way that I can't see my taskbar when it auto-unhides. I can use the window key to bring up the taskbar, but that means an extra trip to the keyboard; and I could resize the Mu.Lab window, but that's lame, because the whole purpose of the auto-hide is to maximize screen space while retaining the ability to quickly use the taskbar.

I'm not sure if i understand.

When i enable "Auto-hide the taskbar", and then maximize the mulab window (which is also done automatically the first time you run mulab), then indeed the mulab window goes full screen and it even covers those 2 blue lines at the very bottom of the screen which are used to unhide the taskbar. That is because mulab asks Windows for the maximum possible rectangle for a window, taking the taskbar into account, and then that's what Windows tells to mulab. So i guess Windows is returning a bad suggestion..?

Anyway, if you resize the mulab window so it becomes 2 pixels less high so to uncover the small taskbar top, then doesn't that solve the problem?

Because if i hit the small taskbar top, then the taskbar unhides, and it's clearly visible on top of the main mulab window, right?

Hey i'm not saying i don't want to do anything about this, at the contrary, the above are just some questions in order to understand what you guys mean, and whether it works the same on your systems than on my local system.

Generally I guess maybe I'm kinda da oldskoolz anyhow and like Windows windows to act like other Windows windows, but perhaps I'm in the minority on this.

The main reason why the new windowing system is built is because as well on Windows as on OSX there are serious shortcomings in the platform windowing API, so that the only way to work 'properly' was to do it in a custom way.

I would prefer i did not had to invest dev-time in that, because i prefer to invest in musical aspects. But 'windowing' is a very important aspect of a gui, and must be good. And that was not possible using the standard platform APIs. Remember previous topics here on the forum about windows not behaving as wanted.

I think the new windowing system is very good, i mean the floating behaviour in combination with the hide button and the window dock.

But of course if some aspects should be finetuned even more, i'm open to that.

Last but not least: Feel free to point to an application where windowing is done 'perfectly' in your opinion. Then we can talk about it.

But it brings me to the other aspect that just plain bugs the heck out of me, and that is that I can't drag windows off the edge of the screen. It feels terribly claustraphobic.

Hey, i thought that would be a user-friendly feature, because it's so easy to align windows near the top/bottom/left/right of eachother!

Also i thought that spreading a single window over two screens is not done because not handy.

I think that having multiple monitors is especially good for "having these windows on screen 1 and those windows on screen 2". But not having 1 window over 2 screens.

Wrong thinking?

Also, one thing I was thinking would be really nice, is to have some basic filter/delay options on the sends themselves. hile leaving the lows. Or is that just something that isn't/can't be done?

Sure it can be done, technically.

But i don't think it's a good idea concept-wise.

In such situation, just plugin a delay in the MPA or a separate rack, and route to that delay, then from delay to reverb, as you described.

That's definitely the right/best way to go!

Because it keeps things open

You could also use an EQ in the send-path to the reverb, or a EQ + delay, or a MUX, or...

It would be limiting to hardwire a delay in there.

Hope you agree.

I do still look gleefully forward to the day when the automation features are more refined

It's clear this is one of the most frequent feature requests!

And be sure that means something!

some great work overall... may your bugs be few in continued development!

Thanks for your feedback!

[MuTools]

There was a bug where you could potentially drag windows right off the screen and couldn't get them back again. Possibly that's why Jo chose to really crack down on those edges!

Indeed, that was 1 of the reasons.

On osx, it should not be possible to drag windows under the menu bar, because then you can't grab the titlebar anymore to move the window to another place.

Besides this, i'm open the remove that 'border limit' thing if the majority thinks this is more bad than good.

[Bonteburg]

I think it makes a lot of sense for the title bar but feels a little limiting applied to all the other edges.

[MuTools]

a MUX VST version would rock

no support for two monitors? at least on my system, i didn't find a way to extend Mulab window over two monitors....

Please see my other post regarding windowing.

I'm eager to finetune this so it's 'perfect' for all of us.

Still have to try more deeply all the remote control possibilities, but as far as i have seen not all the controls can be mapped (if i'm not wrong, some knobs on the synths for example) - if Mulab had every GUI / menu control mappable to CCs...(the question may be redundant, maybe it's just that i didnt realize it)

Indeed, at this point only the 16 Meta Parameters can be mapped to a controller. But you can map anything to a Meta Parameter, and so there always is a way from controller to whatever parameter. That's when talking about MuSynth and Mux.

Regarding Synthia, Sampla and MultiSampla, indeed, only the parameters on the front panel are controllable/automatable, not the ones on the popup panels.

Not yet, i must say.

and...feedback to the hardware controller?

How do you exactly mean?