MU.LAB 2 Test F

[MuTools]

MU.LAB 2.0 Test F is available for download at:

OSX: http://www.mutools.com/mulab/test20/mul ... -f-osx.zip
WIN: http://www.mutools.com/mulab/test20/mul ... -f-win.zip

This update is pure about final fixes and tunings, cfr
http://www.mutools.com/mulab/test20/changes.txt

If you already have installed MU.LAB 2.0 Test E, then you can just replace the Test E application file by the Test F application file in the above package; This way you won't have to re-setup.

Cheers!

[pquenin]

Can you add "New rack" in the "Choose Target" menu ?
Keep on the good work, Mulab is becoming very nice...

[pljones]

Y'know... I'm tempted to ask for something that I think would be very against MU.LAB's philosophy but might be fairly simple as a "quick fix"...

If I set a track to have a track player and a MIDI channel, would it be possible to have any events on that channel recorded to that track and played by that player?

(That way, I could have 16 channels of input -- doesn't get binding to MIDI Port and Channel, which is what I really want but, if it's simple, it's a good enough stop-gap.)

[MuTools]

If I set a track to have a track player and a MIDI channel, would it be possible to have any events on that channel recorded to that track and played by that player?

And what if you have a track set to Kontakt3-channel 5 and another track set to CMPlay-channel 5 and you don't want to play them together?

Anyway, did you find the m.z.s way OK?

Cause intention is to do it in a similar way i.e. you have a table of 16 MIDI input targets, 1 per incoming MIDI channel. You can set it per channel to:

-> Off / Mute
-> Focussed Target (cfr how it is now)
-> Target X (whatever possible target)

The "MIDI Input Targets" editor window could stay open while you're doing other things, and/or you can hide it into the dock. In m.z.s this was a modal window, so you could not use it 'in parrallel'.

(Note: the above is a brainstorming about a future expansion and is not related to version 2.0)

[pljones]

And what if you have a track set to Kontakt3-channel 5 and another track set to CMPlay-channel 5 and you don't want to play them together?

Yes, I know it's not ideal: this was just quick and dirty...

Anyway, did you find the m.z.s way OK?

More or less...

Moving on to the brainstorming:

Cause intention is to do it in a similar way i.e. you have a table of 16 MIDI input targets, 1 per incoming MIDI channel.

See, this is where it can be improved: I want to have control at Port and Channel level: each MIDI Port is an independent set of 16 Channels. Maybe something like the Rack area, one mapping "rack" per Port, 16 slots per "rack"...

You can set it per channel to:
-> Off / Mute
-> Focussed Target (cfr how it is now)
-> Target X (whatever possible target)

Yep, like that (per slot)! But it also needs to allow channel mapping, so if I target any three channels at my B3 emulator, I can get my two manuals and pedals played properly.

[MuTools]

MU.LAB merges all MIDI input ports into 1 virtual input port.

This gives support for up to 16 input channels => up to 16 input devices.

Not too bad i think, especially within the context of a basic easy & fun music app.

E.g. this MIDI setup is perfectly workable:

Imagine you have 2 keyboards, a foot pedal and 2 controller devices, all connected to an individual MIDI input port.

In MU.LAB, you have enabled all these input ports in main menu -> Edit -> MIDI Setup.

Now all MIDI of all these 5 devices is streaming into MU.LAB.

Now in our future situation, you just have to make sure each of these devices is playing on a different channel, that's all.

Then you will perfectly be able to route keyboard 1 to the B3 organ plugin channel 1, keyboard 2 to the B3 channel 2, the foot pedal B3 channel 3, while using the controller 1 on the focussed target (flexible), and controller 2 fixed to MuSynth X.

Of course you could also set it up in total other way too. It's just an example.

I just want to make clear that having 'only' 1 virtual MIDI input port is far from a limited situation, imho.

And also that, as you asked, it will indeed be possible to map the incoming MIDI channel data to whatever plugin, whatever channel on that plugin

[pljones]

Yeah, whilst I use multiple ports, having n*16 channel support is well beyond what I'd ever actually use. So long as the MIDI devices can be set to separate channels then mapped internally, that's plenty for me and, I imagine, many people. It would just be nice not to have to worry about the channels on the devices, if they were on separate ports, is all...

[MuTools]

Yes, i agree.

[KrzysiekK]

Hello,

I am just testing the new F version (thanks for all the fixes mentioned).

I experienced one crash (freeze) after issuing "auto arrange" operation in Deep Editor; this is very easy to reproduce, simply create a loop between MPA blocks and try "auto arrange" function - the app will freeze. In case of problems reproducing, open this project:

http://www.live-styler.de/kksound/MuTest1.MuSession

now open MPA, then MuSynth in Deep Editor view. Rightclick in empty area and choose "Auto Arrange"


Btw. I noticed that when I put something into rack slot ("put into rack" in MPA), the program replaces an existing item in given slot without question (loosing an old object). At least a warning would be nice.

Other minor thing to reproduce:

1. open MPA
2. find an object which has its embed editor. Rightclick it and choose "embed editor". The editor window will show up
3. now in this editor window choose options->switch to play editor (or switch to deep editor)
4. You should notice that the bar of the object in MPA did not resized to the small size but it remained as big as embed editor window - it actually becomes a dummy twin window.

Another small issue:

1. create Synthia instance in MPA (or any other MULAB builtin synth w/patch browser feature)
2. open it as embed editor view
3. in the editor: options -> show patch editor (or hide patch editor) - the window of the whole MPA is resized to the new size of Synthia, while should be left intact

one more - handling MPA window:

1. in main MULAB window select EDIT->Show Modular Plugin Area
2. now when MPA is opened, in same main application window choose EDIT->Hide MPA - the window of MPA does not hide

now naming - when MPA is minimized to MULAB's "taskbar", there is EDIT->Hide Modular Plugin Area option instead of EDIT->Show Modular Plugin Area

Finally a question - is this possible to modulate any VST/VSTi parameter with MU.LAB LFO/ADSR plugin? I connected LFO output to VST/VSTi input but I can see no dialog for routing LFO signal -> VST(i) parameter modulation.

Best regards,
Krzysiek

[MuTools]

Thanks for the feedback regarding embeding editors in the MPA.

In fact, a couple of weeks ago i mentioned the possibility that 'embedding editors' in the mpa would be removed. It's still in there in Test F but please regard it as removed.

Finally a question - is this possible to modulate any VST/VSTi parameter with MU.LAB LFO/ADSR plugin? I connected LFO output to VST/VSTi input but I can see no dialog for routing LFO signal -> VST(i) parameter modulation.

No, not possible (yet?)

[pljones]

Actually... (Here he goes, dreaming again...)

How many "types" of signal are there in MU.LAB, Jo? Audio, MIDI, "control"?

What would I want if I connected an audio cable to a MIDI input? (Apart from locking up? ) How about a popup: "Modulate what?" (or something more polite). The audio signal then provides a bipolar control signal. Probably want a frequency divider (made easy, sample rate to tempo converter...) and range/offset controls, too.

Same deal for audio into a control input...

What if I connect a MIDI source to an audio out..? Fake up a sine wave signal generator for notes events and ignore the rest?

MIDI to control and control to MIDI should be "obvious" - i.e. mappers.

...So, that makes really just the one kind of signal, doesn't it? Hmm, okay, that's really stretching it!

[admc]

Hello,

new MU.LAB is much better than the old one in a lot things, so congratulations, however I have some problems with it.

One is that when I have an audio part that I want to copy and load in it a new WAV file (because so I'll have the same color and rack it is plugged to), then the name of the audio part stays the same, and doesn't appears the just-loaded WAV filename in its title.

Other problem: it's great that when starting a new project I have a new, MASTER rack that is in connection with all the other ones. But what to do when starting a new rack? I have to plug it in MASTER manually. It would be useful to set this as default target for new racks. Then I cannot move the racks, or I just don't know, how to move them - I would like to move the new racks before MASTER, or move MASTER to the first place. So how to move?

Best regards,
Adam

[MuTools]

How many "types" of signal are there in MU.LAB, Jo? Audio, MIDI, "control"?

What would I want if I connected an audio cable to a MIDI input? (Apart from locking up? ) How about a popup: "Modulate what?" (or something more polite). The audio signal then provides a bipolar control signal. Probably want a frequency divider (made easy, sample rate to tempo converter...) and range/offset controls, too.

Same deal for audio into a control input...

What if I connect a MIDI source to an audio out..? Fake up a sine wave signal generator for notes events and ignore the rest?

MIDI to control and control to MIDI should be "obvious" - i.e. mappers.

...So, that makes really just the one kind of signal, doesn't it? Hmm, okay, that's really stretching it!

Essential answer: Audio and MIDI are two different types of signal.

Turning MIDI into audio, well that's in fact what a synth does.

Turning audio into MIDI, well a simple example of that is an envelope follower. But of course it could also be a more complex picth-to-note analyzer.

Anyway, i know what you're dreaming/thinking of. That might be the future.

At the other hand, with MU.LAB 2.0 we have some realized dreams today.

Lets enjoy!

[MuTools]

One is that when I have an audio part that I want to copy and load in it a new WAV file (because so I'll have the same color and rack it is plugged to), then the name of the audio part stays the same, and doesn't appears the just-loaded WAV filename in its title.

I see what you mean.

It's because when copying the part, the name is also copied.

Now if you right-click the new part -> Rename and there you remove the name (i.e. empty name) then the name of the audio file will be automatically displayed.

That's how the system works: When the name is empty, MU.LAB uses the default name (in this case the name of the audio file), else it uses the name you explicitly gave it.

I've finetuned the next MU.LAB so that in the situation you described, it will immediately work like you expected. There was indeed a little finetuning necessary.

Other problem: it's great that when starting a new project I have a new, MASTER rack that is in connection with all the other ones. But what to do when starting a new rack? I have to plug it in MASTER manually. It would be useful to set this as default target for new racks. Then I cannot move the racks, or I just don't know, how to move them - I would like to move the new racks before MASTER, or move MASTER to the first place. So how to move?

The MASTER rack is just an rack like any others, so it's difficult to "automatically" route any new rack to that one. In my opinion, i think it's best that you just do it manually.

Now regarding moving racks around: Shift+click on the name and drag left/right

[MuTools]

one more - handling MPA window:

1. in main MULAB window select EDIT->Show Modular Plugin Area
2. now when MPA is opened, in same main application window choose EDIT->Hide MPA - the window of MPA does not hide

Sorry, overlooked this one.

True. Will be fixed!