MU.LAB 1.0 bugs and observations

[muzycian]

Ah, here's an interesting bug. Mu does not seem to like LinPlug's SaxLab at all, and disables it. No issues with their other products. Wonder what this is about?

Edit: And, does the same to SampleTank 2.2 and Sonic Synth2. "Caused a problem during scan, will be disabled"

//fnx

Can others confirm having problems with these plugins?

[muzycian]

Ok, not a big deal, but...
There must be a quicker way to browse presets than is already implemented.
Now that the vst stays "on top", I really miss the preset browser that was added to the gui of each vst. It was ugly, but it was useful, and would be welcome now... expecially if it was 'prettied up' a bit.

Not a priority or anything, but...

It's on the whishlist!

[jpumphandle]

RE: OSX MU.LAB Free

Some observations on this implementation.

1. Most Audio programs seem to be able to locate the Quicktime Instruments as a default Midi Output. MU.LAB does not display this as a selection under Edit>Midi Setup.

2. I am unable to Import some Midi Files using File>Midi Import. The explorer display seems to lead to a Midi file, but when a file is selected and OK is clicked, nothing happens. Some files will load and others will not. I will continue to research this to try to determine the difference that prevents a file from loading. The Midi files that won't import under OSX can be imported using MU.LAB under WIN XP.

3. I am unable to assign a Midi Controller to the Gain control in a rack using the Assign Midi Controller feature. The source and channel can be input but when Ok is clicked, the assignment is not maintained. A message stating that the List has been updated is displayed.

[muzycian]

RE: OSX MU.LAB Free

Some observations on this implementation.

1. Most Audio programs seem to be able to locate the Quicktime Instruments as a default Midi Output. MU.LAB does not display this as a selection under Edit>Midi Setup.

Will researche this.

2. I am unable to Import some Midi Files using File>Midi Import. The explorer display seems to lead to a Midi file, but when a file is selected and OK is clicked, nothing happens. Some files will load and others will not. I will continue to research this to try to determine the difference that prevents a file from loading. The Midi files that won't import under OSX can be imported using MU.LAB under WIN XP.

Can you please email me such midi file that does notload under osx

3. I am unable to assign a Midi Controller to the Gain control in a rack using the Assign Midi Controller feature. The source and channel can be input but when Ok is clicked, the assignment is not maintained. A message stating that the List has been updated is displayed.

The message is ok, given when the same assignment was already made.

Now the question is: does the rack gain reacts when you tweak that midi controller?

(it works fine here (checked the windows version))

[jpumphandle]

RE: OSX MU.LAB Free

Some observations on this implementation.

1. Most Audio programs seem to be able to locate the Quicktime Instruments as a default Midi Output. MU.LAB does not display this as a selection under Edit>Midi Setup.

Will researche this.

2. I am unable to Import some Midi Files using File>Midi Import. The explorer display seems to lead to a Midi file, but when a file is selected and OK is clicked, nothing happens. Some files will load and others will not. I will continue to research this to try to determine the difference that prevents a file from loading. The Midi files that won't import under OSX can be imported using MU.LAB under WIN XP.

Can you please email me such midi file that does notload under osx

3. I am unable to assign a Midi Controller to the Gain control in a rack using the Assign Midi Controller feature. The source and channel can be input but when Ok is clicked, the assignment is not maintained. A message stating that the List has been updated is displayed.

The message is ok, given when the same assignment was already made.

Now the question is: does the rack gain reacts when you tweak that midi controller?

(it works fine here (checked the windows version))

Found the problem with #2 - Midi files would not load on import. The offending files were marked as Permission = Read Only. However, MU.LAB doesn't give an error on this - just nothing happens. So an error message would be appropriate for this condition, so that permissions can be changed.

#3 - Rack Gain control does not respond to Midi CC assignment - The source and channel assignments revert to NONE amd ANY. The Gain control does not respond to any midi CC because the source has been set back to NONE. e.g. in an example, I set up a Volume Control in a sequence and assigned this to Rack B. When I attempted to assign the source of the Gain control in Rack B to the Volume CC, it reverted back to NONE. So the sequence did not take effect on the Gain control. This has worked for me on the WIN XP version.

[davidweese]

The time bar in the Sequence Editor shows the sequence time, not the part time!

So in the above last situation, the part will have started on bar 10, so that's why you see an 'offset' of 10 bars.

hmmm...I may not be being clear. Here's a link to a video that reproduces the bug, and y'all tell me if it's my imagination.

Dave

http://www.premiermediadesign.com/bugs/bug001.htm

I'll try to use videos as much as I can to demonstrate buggy behavior. That ought to help with any gaps in translation...btw this swf player seems to want to preload the video so be patient, and it is picky...appears to be ok w/ ie but finicky about firefox...

[jpumphandle]

David ...
I think you have encountered the same problem that I have. The parts do not reflect their position in the mix. The midi editor only edits the original sequence location. See this post ...

http://www.kvraudio.com/forum/viewtopic ... 57#2866757

I would like to see the Editor display the locations of events in the part as opposed to locations in the original sequence.

[davidweese]

Well, to have to do a little mental translation of the bar position relative to the overall mix does not to my mind represent a bug, just a potentially poor design decision, and that's what user feedback is for - no big deal...

So the ruler being offset (ie zeroed out) based on the clip position I could handle. I question how useful that is - since music is *almost* always related to the arrangement context it is placed into...and that does not appear to me to be what's happening anyway...

But the idea that you would click here, and the playback head appears 10 bars over there is really questionable behavior. It violates all firmly established conventions of how a mouse is supposed to work IMHO.

UPDATE
Ok, so the ruler offset is relative to the SEQUENCE not the CLIP. I get it, but please someone share a practical application where this is helpful? I mean, if you chop up a sequence into sections in order to reuse certain loops for example, then fine, but shouldn't the offset be clip based, not sequence based - after all your whole point there would be to treat the clip as an independent loopable/instancable/customizable object....? ie a standalone musical entity...or am I missing something?

IMO the ruler should reflect the timeline, period. The programming principle of least surprise plays heavily here I think.

[D-Fusion]

I have a problem with Wusik VM.

I only see half of the VM gui in Mulab When i open it.
And if i manage to add a vsti in there the bottom of the gui misses some pixels.


I am not sure if this is a Mulab issue or Wusik issue so i have added this in both forums

[D-Fusion]

I have a problem with Wusik VM.

I only see half of the VM gui in Mulab When i open it.
And if i manage to add a vsti in there the bottom of the gui misses some pixels.


I am not sure if this is a Mulab issue or Wusik issue so i have added this in both forums

Just talked to William regarding this problem and he told me that it was a Mulab issue:

Sorry, but you would need to contact Mulab about this. It looks like they are not resizing the VST GUI when it changes. As Wusik VM starts small, and resizes itself after it opens.

Wk

I have also starting to look a little closer in on Mulab and it is awesoem

I just love Mux it reminds me of the Combinator in Reason on Steroids, And the Musynth just sounds awesome.

The Cpu usage and Asio is also great 1.5ms latency and no extra cpu hit experienced

I am also looking forward to when Mulab gets Dual/Multicore support

[Bonteburg]

It's very easy to misplace a sequence (ie part) in the arrange window when you've zoomed out far enough to get an overview of your song.

Maybe some kind of 'snap to grid' functionality is in order (Even though I'd consider it low priority).

[NBV]

Ah, here's an interesting bug. Mu does not seem to like LinPlug's SaxLab at all, and disables it. No issues with their other products. Wonder what this is about?

Edit: And, does the same to SampleTank 2.2 and Sonic Synth2. "Caused a problem during scan, will be disabled"

//fnx

I had a similar problem with dmiHammer, a chromatic-percusion synth, and LUNA pr 8.4; when running LUNA for the first time it suddenly quit while scanning the plugins. The second time I ran it, and try to add VST plugins, it prompted a message similar to that "Caused a problem during scan, will be disabled". I just deleted the .dll and then re-copied the .dll to my vst folder and the problem disappeared.

[NBV]

BTW, Loopazoid is still having problems in MUTOOLS as it had in LUNA: you can use loopazoid in a musession and save it, but you can not re-open your session since MUTOOLS seems to be unable to find again the samples used by loopazoid.

It's a pity, I have two drum samplers of choice: sr-202 and loopazoid, but sr-202 cannot play stereo samples, and loopazoid does, besides, it has a lot more pads than sr-202.

Referring to this issue:

It's very easy to misplace a sequence (ie part) in the arrange window when you've zoomed out far enough to get an overview of your song.

I wonder if it's not too much to ask for a "markers" functionality like that in SONAR, that allows you to mark the "verse" and the "chorus" or the "bridge" and relocate the cursor inmediately.

[funkychickendance]

Ah, here's an interesting bug. Mu does not seem to like LinPlug's SaxLab at all, and disables it. No issues with their other products. Wonder what this is about?

Edit: And, does the same to SampleTank 2.2 and Sonic Synth2. "Caused a problem during scan, will be disabled"

//fnx

I had a similar problem with dmiHammer, a chromatic-percusion synth, and LUNA pr 8.4; when running LUNA for the first time it suddenly quit while scanning the plugins. The second time I ran it, and try to add VST plugins, it prompted a message similar to that "Caused a problem during scan, will be disabled". I just deleted the .dll and then re-copied the .dll to my vst folder and the problem disappeared.

Nice to know of a possible solution. Are you saying that the .dll for the program needs to be in the root of the VST directory, rather than in a subfolder, or am I missing something here? Or that deleting then reinstalling is the answer?

//fnx

[pljones]

Not sure if this is related to the earlier comments...

I imported MIDI sequence containing three parts. MULAB put it in a new Session on three tracks. Fine. It was a 12-bar blues MIDI, so I wanted to chop it up into intro/pickup, loop, outro sections.

I selected the first part, hit split part, hit duplicate sequence. So now I have one part for the intro with its own sequence, but the sequence is too long. Easy: open it, select everything past the split, delete. Move on to part two.

I want to delete the intro and set the loop. Hmmm. The start marker is at bar 1, even though the start position is bar 7. There doesn't seem to be a way to get rid of those first seven bars without appearing to get the wrong result. If I move the start marker forwards, the part start position moves forward seven bars ahead. If I shift the events earlier, they don't appear. I'm stumped!

http://www.harmonicalessons.com/sounds/ ... s_in_G.mid <- the offending file