MU.LAB 2 Test E

[MuTools]

After a long thought, decission has been taken to implement Track Targets.

This means each track can now have it's own target, which then is the target for all parts on that track:



This way, users will be able to work in a more 'traditional' way, which will boost the ease and fun

Note that you can still work with 'free' tracks like before if you want. And combining 'free' and 'traditional' tracks is definitely very interesting too!

Some more things have been fixed and tuned, cfr
http://www.mutools.com/mulab/test20/changes.txt

MU.LAB 2.0 Test E can be downloaded from:

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

MU.LAB Test E is intended to be the last test version before PreRelease. (except for some final fixes where necessary)

It's clear that 2.0 is not fulfilling all feature requests, but of course that's impossible.

But i'm confident this version is ready to rock!

[pquenin]

This Track Target thing is a good thing, especially for newbies.
And the fact that the "default song" is track targeted is good for the same reason. But now, I think it would be natural that when you add a new track, it also add a new rack that is the target of the new track. Some people not used to the Mulab approach may spend hours to figure out how to make the new track work the same as the pre-made ones. Sorry, my english is too bad.
,

[pljones]

That's a tricky one. Part of the point of MU.LAB is to break down those preconceptions. If they're not challenged early, they'll only get more difficult to change.

I wouldn't want "new track" to mean "new rack". I definitely would want it to be a conscious decision to choose whether a track was in rack mode. Being able to create a new rack at that point would be a good usability feature, though (i.e. when you've said "rack mode, please", you can pick an existing rack or "new rack").

[pquenin]

Yes I understand your point of view. I was just pointing this out because of the coherence of the whole thing.
Perhaps there must be an option to choose the behaviour ?

Now, I have noticed this in version E, I cant remanber if it was here before : when I launch Mulab, It doesn't ask if we want to open the latest session, or a new session -> we go directly in the latest session opened.

[oldguy]

Hi Jo,

Playing around with Mutool 2.0 test D today, but probably still has the same issue in E if you haven't heard of it.

The problem appears to occur when importing midi tracks for drums that have 'Trigger' length notes. First, it doesn't display properly, length is messed up. Mulab just doesn't comprehend how long the midi is, and can't properly display it either.

Second, (and more of an issue) is that trying to edit midi import tracks with 'trigger' length notes in the piano roll causes MULAB to freeze up. It's like the piano roll doesn't know what to do with the 'Trigger' length notes.

I know that it's the triggers because I edited them in the list editor to be a short length note and all problems were solved.

Also, not sure if it was just the midi file itself or not, but the drum beats came in slightly early.

I would suggest that you just have Mulab convert all "trigger" length notes to a short length upon import of midi files.

A sample file that has this issue is found here: (Beat6.mid)

http://www.mediafire.com/?sharekey=0ce5 ... b9a8902bda

Also, minor bug: when editing in list editor, holding down the shift key and clicking down on the right scroll bar (page down) causes the selection to miss lines which aren't explicitly shown on in the window as highlighted. It would also be helpful to have a 'select all' and 'clear selection' button visible on the windown instead of digging for it in a menu. For those used to windows, the persistant selection seems baffling until you find those hidden menu options...especially when you close the list editor, open it again, and still find all your notes selected.

Rgds, -Oldguy

[pljones]

I would suggest that you just have Mulab convert all "trigger" length notes to a short length upon import of midi files.

Very bad move -- this will break play back on many drum samplers. They're "trigger length" (i.e. no Note Off event) for a reason.

[MuTools]

Now, I have noticed this in version E, I cant remanber if it was here before : when I launch Mulab, It doesn't ask if we want to open the latest session, or a new session -> we go directly in the latest session opened.

Isn't it that the demo session that is opened?

Once you open/save another session, that should be remembered.

[MuTools]

The problem appears to occur when importing midi tracks for drums that have 'Trigger' length notes. First, it doesn't display properly, length is messed up. Mulab just doesn't comprehend how long the midi is, and can't properly display it either.

Did some finetunings in case of such MIDI file.

Second, (and more of an issue) is that trying to edit midi import tracks with 'trigger' length notes in the piano roll causes MULAB to freeze up.

Indeed. Fixed in the next version.

Also, not sure if it was just the midi file itself or not, but the drum beats came in slightly early.

Please research this more on your end.

If mulab does something wrong, please let me know the details.

When editing in list editor, holding down the shift key and clicking down on the right scroll bar (page down) causes the selection to miss lines which aren't explicitly shown on in the window as highlighted.

This is not a supported action, i.e. clicking the scrollbar has nothing to do with making event selections.

It would also be helpful to have a 'select all' and 'clear selection' button visible on the windown instead of digging for it in a menu. For those used to windows, the persistant selection seems baffling until you find those hidden menu options...especially when you close the list editor, open it again, and still find all your notes selected.

You're right, the context menu was too hidden there.

In the next version, there also is an 'Options' button at the bottom

[lucknow13]

What do the different options in the Rack selection do. ie. rack only or whatever plugin is in the rack or the other?

[pquenin]

pquenin wrote:
Now, I have noticed this in version E, I cant remanber if it was here before : when I launch Mulab, It doesn't ask if we want to open the latest session, or a new session -> we go directly in the latest session opened.


Isn't it that the demo session that is opened?

Once you open/save another session, that should be remembered.

You're right, sorry.

[MuTools]

What do the different options in the Rack selection do. ie. rack only or whatever plugin is in the rack or the other?

The target list contains all possible targets.

When you target a 'Rack itself' the audio/events (whatever you're sending) come at the input of the rack and will stream from slot 1 down to slot 6 and so to the output of the rack.

When you target a plugin, the audio/events are directly going to that plugin.

Does this answer your question?

[Bonteburg]

OSX 10.4.11:

-if a track is in "target mode" and the target is a VST/VSTi, parts don't show the "parameter" option in the automation lane. Bug or feature?

-VSTi "Remedy" (keytosound.com); window is missing the little close/minimize window thingies so I have to replace or delete it to get rid of the window.

[MuTools]

OSX 10.4.11:

-if a track is in "target mode" and the target is a VST/VSTi, parts don't show the "parameter" option in the automation lane. Bug or feature?

Bug.

Fixed in the next version.

-VSTi "Remedy" (keytosound.com); window is missing the little close/minimize window thingies so I have to replace or delete it to get rid of the window.

Mmm, i see. Remedy is acting strange... Will research more.

[MuTools]

-VSTi "Remedy" (keytosound.com); window is missing the little close/minimize window thingies so I have to replace or delete it to get rid of the window.

Mmm, i see. Remedy is acting strange... Will research more.

To me that looks like a Remedy issue.

I've emailed keytosound to sort this out.

[Bonteburg]

and indeed I encountered the same issue in Test D just now ...

I only discovered it in Test E for some reason.