MU.LAB 3.1 test

[mutools]

is it just me; Miroslav Orchestra doesn't seem to work anymore as a vst i get a simple "incompatable plugin" message.
i have checked witht the last ver2 and as a stand-alone and these still work

(I would have to admit to not being on the newest of the new ver3 version though)

anyone else have the smae problem?

On which OS are you working?

Are you trying to load a 64 bit plugin into MU.LAB 3 on Windows 7?

[mutools]

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

What's changed:

• Tuned: Note Editor: Short pencil clicks did not always draw a note
• Tuned: Click on rack name now immediately focuses the rack without a double-click detector delay
• Tuned: Click on rack slot now immediately focuses the rack slot without a double-click detector delay
• Tuned: Click on track name now immediately focuses the track target without a double-click detector delay
• Fixed: Bug regarding lassoing/dragging
• A couple of other tunings regarding lassoing/dragging/double-clicking

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.

[Simon Posford]

Awesome the delay on the rack clicking was very annoying now mulab is very fast!
Thank you Jo:D

[Juan Mendoza]

I found a small graphic glitch using 3.14, i don't know if it's already solved or present in newer versions (i did a quiq read on the fixes in newer versions and found nothing about this) and still i have no idea on how to reproduce it or if it's a system specific error



The missing module is the Balancer 2->1 that's nearby (i swear that's not a photomontage )

After a few i tryed to move that Balancer 2->1 and the glitch dissapeared, but it's weird anyway and i thought i should report it.

If you want i can send you the musession.

BTW, in http://www.mutools.com/mulab/docs/musynth.html > in this sentence You can find more detailed info on the available modules here. the link http://www.mutools.com/mulab/docs/mulab ... ugins.html point to a not found message.

BTW too, i'd like to see a direct link to the modules descrition docs in the main docs menu, easyer to find it IMO.
Also if we got the docs in a single .doc or .pdf or else file would be a lot easyer to do quiq searches by terms.

[Juan Mendoza]

Jo, I've just read this message, sorry for the delay

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.

If there's no solution for this i understand your piont, but i personally find more important to have a single file that can be directly opened by Mulab without need to decompress it before, than use of ogg files. Maybe that's because i mostly use 32 bit wavs and i never thought in using a compressed format for music production. Don't know if ogg is a loosless format but i doubt it.

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.

That would be nice, but i've got problems with certain .zip files in the past, i'd preffer .rar instead, but's not as common as .zip and it's not a mac format though.
A possible finetuning would be that mulab reads and writes zip files. This way you don't have to unzip the musessions in order to use them.

[mutools]

I found a small graphic glitch using 3.14

Is that version 3.0.14 or 3.1.4 or 3.1.14?

If you want i can send you the musession.

Is it repeatable using that MuSession?

BTW, in http://www.mutools.com/mulab/docs/musynth.html > in this sentence You can find more detailed info on the available modules here. the link http://www.mutools.com/mulab/docs/mulab ... ugins.html point to a not found message.

Fixed in the 3.1 docs which will be published when MU.LAB 3.1 is released, normally this friday.

BTW too, i'd like to see a direct link to the modules descrition docs in the main docs menu, easyer to find it IMO.

Done in the new docs.

Also if we got the docs in a single .doc or .pdf or else file would be a lot easyer to do quiq searches by terms.

You can use a Google site search for that.

I've added a Google site search box to the TOC page in the new docs

[mutools]

Jo, I've just read this message, sorry for the delay

No problem

Hey, you're waiting for a reply from me too, sorry for that delay too
(you know which topic i mean)

If there's no solution for this i understand your piont, but i personally find more important to have a single file that can be directly opened by Mulab without need to decompress it before, than use of ogg files. Maybe that's because i mostly use 32 bit wavs and i never thought in using a compressed format for music production. Don't know if ogg is a loosless format but i doubt it.

OGG is lossy. But it has a good quality/compression ratio.

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.

That would be nice, but i've got problems with certain .zip files in the past, i'd preffer .rar instead, but's not as common as .zip and it's not a mac format though.
A possible finetuning would be that mulab reads and writes zip files. This way you don't have to unzip the musessions in order to use them.[/quote]

Yes that's an option.

RAR is not an option as it's closed format.

Anyone heard/experienced anything bad about the interesting BZIP2 ?

Or is it 100% reliable?

[sorohanro]

If there's no solution for this i understand your piont, but i personally find more important to have a single file that can be directly opened by Mulab without need to decompress it before, than use of ogg files. Maybe that's because i mostly use 32 bit wavs and i never thought in using a compressed format for music production. Don't know if ogg is a loosless format but i doubt it.

+1

I'm not for using compressed formats in music production and me too, I'm for having a file that is just one file that can be opened by Mu.Lab instead of messy folders, zip, rar, piling oggs, pilling folders in the project files directory...

[Juan Mendoza]

I found a small graphic glitch using 3.14

Is that version 3.0.14 or 3.1.4 or 3.1.14?

3.1.4, and i've only readed the update fixes from 3.1.14 and newer versions, sorry.

Is it repeatable using that MuSession?

Not by now, just happened once.

BTW, in http://www.mutools.com/mulab/docs/musynth.html > in this sentence You can find more detailed info on the available modules here. the link http://www.mutools.com/mulab/docs/mulab ... ugins.html point to a not found message.

Fixed in the 3.1 docs which will be published when MU.LAB 3.1 is released, normally this friday.

BTW too, i'd like to see a direct link to the modules descrition docs in the main docs menu, easyer to find it IMO.

Done in the new docs.

Also if we got the docs in a single .doc or .pdf or else file would be a lot easyer to do quiq searches by terms.

You can use a Google site search for that.

It's not the same. E.g With the .pdf search function you can enter a search term and navigate with a single clic with next previous buttons. Also, i found important to have an offline version of the docs, i'm not allways connected when i use mulab and sometimes i use a labtop without internet connection. I know many musicians that work with offline DAWs as a basic safety/security rule.

I've added a Google site search box to the TOC page in the new docs

Thanks

[cytone]

I can see both sides of the argument but the idea of a folder for the project files seems a good idea. Especially if a freeze function is added to MU.LAB so all files for the project are self contained.
Is there much benefit to compressing audio files with standard file compression though?

The latest beta is running really well. All the fine tuning has paid off as the interface feels more responsive.

[Juan Mendoza]

Jo, I've just read this message, sorry for the delay

No problem

Hey, you're waiting for a reply from me too, sorry for that delay too
(you know which topic i mean)

No problem, i was not expecting a reply at least untill you release v 3.1
First things first On the other hand i've needed this delay too, you know why.

If there's no solution for this i understand your piont, but i personally find more important to have a single file that can be directly opened by Mulab without need to decompress it before, than use of ogg files. Maybe that's because i mostly use 32 bit wavs and i never thought in using a compressed format for music production. Don't know if ogg is a loosless format but i doubt it.

OGG is lossy. But it has a good quality/compression ratio.

Don't want to go much offtopic with this, but then, could we consider OGG as a good/alternative format for releasing Mulab sample libraries?. If yes, that makes sense, if not, i'm not sure how many would benefit of such format

Anyone heard/experienced anything bad about the interesting BZIP2 ?

Or is it 100% reliable?

First time i've heard of it, i'll do a quiq research.

I can see both sides of the argument but the idea of a folder for the project files seems a good idea. Especially if a freeze function is added to MU.LAB so all files for the project are self contained.
Is there much benefit to compressing audio files with standard file compression though?

Me too, that's why i vote for adding such feature but maintaining and improoving the embed function. It's not double functionality IMO, each feature has it's very singlular benefits.

[jpumphandle]

Don't want to go much offtopic with this, but then, could we consider OGG as a good/alternative format for releasing Mulab sample libraries?. If yes, that makes sense, if not, i'm not sure how many would benefit of such format

The combination of WAV and OGG would be an excellent way to be consistent and also offer the choice of quality vs. compressed.

+1

[The Kob]

On which OS are you working?

Are you trying to load a 64 bit plugin into MU.LAB 3 on Windows 7?

win xp 32bit
win7 not yet!

[mutools]

The new MU.LAB 3.1.20 pre-release package and patch are available in http://www.mutools.com/mulab/chestnut

Latest changes:

• Tuned: When choosing a session sample, the samples within multisample groups are sorted alfabetically
• Fixed: When renaming a module that was used as the output for a rack, the rack's output field wasn't immediately refreshed
• Fixed: Audio Lab: Deleting the part start locator did not immediately refresh the indicative background display
• + some minor tunings

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.

Important note to registered users:

Note that from version 3.1.20 on, MU.LAB uses a new User License Key format!

Some of you may already have received an email with their new MU.LAB 3.1 key.

If you did not yet receive such email and you can't wait until the MU.LAB 3.1 release email is sent out (which will contain your new MU.LAB 3.1 key) feel free to request your new MU.LAB 3.1 User Key via email and i'll be happy to already send it to you

MU.LAB 3.1 is planned to be released this saturday.

[mutools]

Don't want to go much offtopic with this, but then, could we consider OGG as a good/alternative format for releasing Mulab sample libraries?. If yes, that makes sense, if not, i'm not sure how many would benefit of such format

Well that's effectively one of the main reasons why i added OGG support.
You can use OGG for library packs already.

I can see both sides of the argument but the idea of a folder for the project files seems a good idea. Especially if a freeze function is added to MU.LAB so all files for the project are self contained.
Is there much benefit to compressing audio files with standard file compression though?

Me too, that's why i vote for adding such feature but maintaining and improoving the embed function. It's not double functionality IMO, each feature has it's very singlular benefits.

I think i understand your needs/wishes and will think of this more.