MU.LAB 3.1 test

[robenestobenz]

Hiya Jo, any word on this?

In 3.12 the ability to use shortcuts during drag operations seems to have been lost, which slows down moving notes around if you aren't keeping track of the snap toggle and have to deselect>toggle>reselect.

I tend to use a lot of samples from elsewhere on my hard drive, which makes project portability a pain. Would a "copy files to project audio foldier" command be possible?

[MuTools]

I tend to use a lot of samples from elsewhere on my hard drive, which makes project portability a pain. Would a "copy files to project audio foldier" command be possible?

Samples can be embedded in the MuSession file via EDIT menu -> sample manager.

However this is not the case for audio files as that would make the musession file too big (in most cases).

For this reason, but also for a reason related to Ogg samples, i'm thinking of removing the 'embedding' feature and purely rely on a function "Collect All Audio Files And Samples To Session Audio Folder".

This way we would have a uniform way of collecting all session audio.

What do you think?

[MuTools]

The compressor doesn't seem to be working right to me. Or at least not in a similar way to every other compressor I've used.

For example infinite ratio should mean it is effectively acting as a limiter, yet with a knee smoothing over over about 30% it doesn't reduce the signal much at all, even with the threshold set as low as -52db!

In other compressers, the knee softness usual only affects a fairly small area of the amplitude transfer curve (cf le wiki). This is usually without such dramatic db changes as the bottom 0-20% knee smoothness range in MuLab's module either, so what's it doing?

The smoothness smoothes the transfer curve like in the wiki picture. Smoothing is not limited to a certain 'transfer range'. If you find the smoothing too much, lower the smoothing until it sounds as you like.

Also related to this:

And a little FR...especially for the compressor, some kind of metering would be very nice...I/O and reduction
For me, it's quite better to adjust, if I see what's going on...

I understand that a visual feedback can help in understanding and thus finetuning the compressor settings. Added a note on the wishlist.

[MuTools]

In 3.12 the ability to use shortcuts during drag operations seems to have been lost, which slows down moving notes around if you aren't keeping track of the snap toggle and have to deselect>toggle>reselect.

Indeed, the use of shortcuts is blocked during dragging/lassoing/drawing new parts/notes. The fact that it worked in the previous versions was unintended and had to be blocked for stability reasons.

[Calum]

The new MU.LAB 3.1.12 test patch is available in http://www.mutools.com/mulab/chestnut

Bug report?
Double-clicking in MU.LAB 3.1.12 does not appear to be working at all in OSX version on my iMac running Snow Leopard. In the PC version of MU.LAB 3.1.12, double-clicking works as expected running in Parallels Desktop on the same Mac using the same mouse.

[MuTools]

Confirmed. Fixed in the next version. Thanks!

[robenestobenz]

The smoothness smoothes the transfer curve like in the wiki picture. Smoothing is not limited to a certain 'transfer range'. If you find the smoothing too much, lower the smoothing until it sounds as you like.

But how can infinite ratio (which is limiting) be completely offset by knee smoothness?

I've certainly never used a compressor with such behaviour from the knee softness control - maybe others cap the value range?

No biggie anyway.

Samples can be embedded in the MuSession file via EDIT menu -> sample manager.

However this is not the case for audio files as that would make the musession file too big (in most cases).

I do use this for sampling... but in the cases I was thinking of when I wrote the post, I'm generally dragging audio files straight into the timeline.

For this reason, but also for a reason related to Ogg samples, i'm thinking of removing the 'embedding' feature and purely rely on a function "Collect All Audio Files And Samples To Session Audio Folder".

This way we would have a uniform way of collecting all session audio.

What do you think?

I'd use such a feature a lot (if it copies the files rather than moving them). I wouldn't mind losing the ability to embed feature as I always prefer data to be separated and accessible for editing and easy re-use anyway, but I as I recall some users here on KVR at least are very keen on it.

And while I understand about the shortcuts...

[janamdo]

Hehe, thanks, janamdo! Now you should check out this one... I made a wild sound with the note key splitter! It's got quite some potential...
(although it inspires a few new requests!)

drumSynth04.MuSession

I am sorry i stumbled on your soundexample right now
Well i just examine your example very extensive work you make from it superb... a lot is possible now with the note splitter
Thanks ! .. you must collect all your songexamples also these made with the key note splitter

When Mutools makes more soundtoys to play with than you can experiment further

[Juan Mendoza]

Embedding samples and even audio recordings is one of the most important features IMO, please don't discard it

I saved years of work thanks to this feature in Muzys, and i dont get the point to discard it now. I agree that the copy into the project audio folder feature is a good improovement, but without overwriting the existing functionality.

These days is not a problem to have large files stored into the HDD, i don't care if i have 50 project files of let's say 500mb or more if i'm sure that inside this files is saved everything i need to "rescue" the song later (maybe years later).

[MuTools]

Dear Juan, if we would replace the 'embed' feature by a 'collect' feature, then it's almost the same thing, i think.

I would rather replace 'embed' than add a 'collect' on top for reasons of keeping the app simple and transparant.

The advantages of a 'collect' over a 'embed' are:

* uniform for both audio files and samples (and whatever other external file types a musession would use in the future)

* currently there is a practical problem with embedding ogg-compressed samples. You can embed these samples but they will be embedded uncompressed (even at 32 bit), which is not the intention of using oggs. I would like to take advantage of the small file size of ogg files.

The collect function could even go 1 step further and (optionally) make a zip package of the musession with the audio subfolder included so you can easily transport/backup the zip. But that would take an extra R&D stage <=> we need the zip file writer functionality.

[pljones]

When I change the number of beats per bar, say from 4 to 5, if I've got the composition loop start and end positions set to, say 5.1.0000 and 9.1.0000, should MU.LAB keep those settings, rather than "moving" them to 4.2.0000 and 7.3.0000? (That is, I want to loop the second four bars, not a particular range of ticks.)

Keep as is. It's the user's choice to change things or not.

At the moment, MU.LAB changes from 5.1.0000 to 4.2.0000 when the beats per bar changes.

The collect function could even go 1 step further and (optionally) make a zip package of the musession with the audio subfolder included so you can easily transport/backup the zip. But that would take an extra R&D stage <=> we need the zip file writer functionality.

I was going to suggest something similar, whilst catching on up on this discussion... I'd suggest using a better compression than ZIP: 7z?

[liquidsound]

I was going to suggest something similar, whilst catching on up on this discussion... I'd suggest using a better compression than ZIP: 7z?

I'm not sure about this 7z but in our business (and several I know of) we lost many archives with that thing. I mean, devastating losses! We learned from and moved to Winrar.

[MuTools]

The new MU.LAB 3.1.14 test patch is available in http://www.mutools.com/mulab/chestnut

What's changed:

• Tuned: Further finetuned double-click detection algorithm
• Fixed: Audio Lab: Problem with "Select Between Locators"
• Fixed: OSX: Double-click didn't work

If you already have installed MU.LAB 3.1.4 or later, then simply replace the current MU.LAB application file with the new application patch file.

This is MU.LAB 3.1 release candidate 4.

[Simon Posford]

THX jo for this patch but what to do with the positionline.zip?

[MuTools]

Sorry, forgot to answer that question.

If you're eager to use it now then 1) else 2)

1) Open the zip file and drag-drop the 2 files in it to the Mulab/App/Graphics/LooxSkinName/Common/Common/Formats subfolder.

2) Soon MU.LAB 3.1 will be released and things will be up to date in the release package, so you won't have to worry about it.