MU.LAB 1.0 bugs and observations

[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.

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

Just deleting and "reinstaling", you can "reinstall" the .dll wherever you want.

[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))

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.

OK, will check this

#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.

When the Assign MIDI Controller dialog opens, the source does not refelect what's assigned now; It's just about which controller you want to use.
Note that multiple controllers can be assigned to a single parameter, and a single controller can also do multiple parameters!

I'll check midi controller assignments in OSX.

[muzycian]

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.

IMO the ruler should reflect the timeline, period

You may be right. I'll rethink this.

[muzycian]

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

Will check this.

[muzycian]

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).

Right-click the composer background => Edit => Select Grid => Bars

This will snap all actions to bars.

[muzycian]

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.

I emailed the developer of Loopazoid about this, but didn't receive an answer yet

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.

What you could do is use a "helper track" with empty sequence parts that you give the proper labels (and colors) like "verse", "chorus" etc...

Ok, this is not 100% the same, but it works very fine!

[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

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.

I'm surprised by the "delete-dll-then-copy-again" thing too

<edit>
Ah, ok, now i read that it was about "delete-dll-then-reinstall-again".
OK, that sounds much more natural/logical.
</edit>

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

For MU.LAB it doesn't matter where the plugin is, because you just tell MU.LAB where the plugin is! (via the Plugin Manager)

[muzycian]

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

It's because of the "split".

When splitting a part, MU.LAB memorizes the offset into the sequence.

I also realized that currenly there is no way to reset or edit that offset.

Will be tuned in a next version!

This fact, together with the composition-time/sequence-time confusion (to be tuned also) should explain everything.

[jpumphandle]

It's because of the "split".

When splitting a part, MU.LAB memorizes the offset into the sequence.

I also realized that currenly there is no way to reset or edit that offset.

Will be tuned in a next version!

This fact, together with the composition-time/sequence-time confusion (to be tuned also) should explain everything.

I am really looking forward to this.

If MU.LAB is going to allow MIDI Edits, it should be able to address all of the parts from the original sequence independently. To re-iterate my whishlist ...


When a sequence is split, each clip should be able to be edited separately. i.e. display the midi event position where it will actually be played in both the Editor and the Event List. Also limit the display/edit to the events in the clip both in the piano roll and the event list.

[pljones]

When a sequence is split

Rather than a Part being split. Currently, it's acting like the Part is being split, which means you have two parts pointing at the one sequence, with each part addressing the sequence appropriately (except not quite ).

If I used the same sequence in two parts already, then split one of the parts, I end up with three parts but still one sequence. Opening the full sequence in the un-split part and editing it there will affect one or other of the split-parts (depending where I edit).

I want to tell the part where:
1. in its sequence to start playing
2. in its sequence to stop playing (see below)
3. its loop start point is (if appropriate)
4. its loop end point is (if appropriate)
Each part should have those attributes independently of the sequence being used.

I want a separate marker for Play Start, like the Loop Start marker. The Loop End marker can double as Play Stop, I think? Dragging the Loop End marker beyond the end of the Part should... mmm..? Make the part longer?

I want the timeline at the top of the part when I open the sequence window to reflect the position of the part in the composition. (Moving Play Start will make the timeline change relative to the sequence, in other words.)

I should be able to scroll "earlier" (left) until the (actual) start of the sequence is displayed. Ditto for scrolling "later" (right) past the sequence stop point to the end of the sequence. (i.e. Not be limited to where the start and end of the part are within the sequence.)

(Duplicate sequence - and the equivalent gestures - should carry on doing what it does now and leaves the part attributes alone. You'd still have the whole sequence there.)

[jpumphandle]

Amen!

[DaveL60]

Amen!

I think I agree, but then again, maybe my head just hurts!

DaveL

[muzycian]

If MU.LAB is going to allow MIDI Edits, it should be able to address all of the parts from the original sequence independently. To re-iterate my whishlist ...

Euh, not sure what you mean by this?

MU.LAB already does 'midi edits' in the Sequence Editor.

When a sequence is split, each clip should be able to be edited separately.

If you want 'independent sequences' then use 'Duplicate Sequence' to make an fresh new copy of it.

If you copy a part via control+drag, you can also hold shift to also make a duplicated sequence at the same time.

i.e. display the midi event position where it will actually be played in both the Editor and the Event List.

Agreed; Will do.

Also limit the display/edit to the events in the clip both in the piano roll and the event list.

Does everyone agree with this?

I agree though that there should be at least a visual indication which events are 'active' in the part and which ones are not (because they fall outside the part span)

But NOT showing them may be confusing...

[Bonteburg]

MuSynth:

When running a WTF oscillator through a filter, there will be an audible *click* when the sound stops at certain filter settings (medium to high reso, low cutoff). I have only tested it with a lowpass filter within MuSynth as yet, and I could provide a patch.

[muzycian]

MuSynth:

When running a WTF oscillator through a filter, there will be an audible *click* when the sound stops at certain filter settings (medium to high reso, low cutoff). I have only tested it with a lowpass filter within MuSynth as yet, and I could provide a patch.

That is normal: because of the medium/high resonance the filter needs some time to decay.

So what you need to do is make sure the patch has an amplifier + envelope for it and set the decay/release time high enough for the filter to fade out.(e.g. 20 ms)

Tip: If you have multiple envelopes in a patch, make sure to mark the most relevant envelope as the main envelope.

Otherwise the patche voices make take more time to end (and use cpu) than the time you're hearing them.

Cfr http://www.mutools.com/mulab/docs/musynth.html

This has not specifically to do with your filter question, but thought i just added this info here again