MU.LAB PreRelease

[muzycian]

Dave: Yup, not likely. Sounds like a hole in the MuLab net for the workings of that controllers particular tech. Bless M-Audio, hunh?

Folks, I've spent about 10 hours on MuLab 1.0 prerelease and, oh wow, do I second the merge track function need. I've done OK copying and pasting sequences but...I keep looking for merge thinking it's hidden in there somewhere. )

Some workaround for now:

* Select all parts you want to merge
* Save as MIDI file
* Reload that midifile (it will be in a new composition)
* Copy the midifile part on the clipboard
* Switch to the original composition (via right-click composer -> "Select Next Composition")
* Paste the midifile part in this composition

I know, this is a long way around. But at least there is a way

As said: a real sequence part merger is on the whishlist with raised priority.

[jpumphandle]

Bug - Editing MIDI in track with multiple sequence clips using Split

I entered 12 bars of midi sequence, then split it into 3 parts of 4 bars each. Splits at bar 5 and bar 9. The 3 clips can be moved around and have been assigned to 3 different MuSynth presets. They play normally and are looped at bar 13.

Double-clicking on any clip displays the entire 12 bars in the Midi editor, but the last 4 bars are empty and cannot be edited. (i.e. only bars 1 - 8 are visible to be edited and also these are the only bars that appear in the Event List. The Midi Editor and Event list show the events starting at bar 1 no matter where the clips are positioned. Bars 9 - 12 are missing.

My preference: To be digitally correct, I would expect to see only the midi events in each clip that was selected for Midi Edit and arranged at the bar numbers where the clips are positioned.

[muzycian]

Bug - Editing MIDI in track with multiple sequence clips using Split

I entered 12 bars of midi sequence, then split it into 3 parts of 4 bars each. Splits at bar 5 and bar 9. The 3 clips can be moved around and have been assigned to 3 different MuSynth presets. They play normally and are looped at bar 13.

Double-clicking on any clip displays the entire 12 bars in the Midi editor, but the last 4 bars are empty and cannot be edited. (i.e. only bars 1 - 8 are visible to be edited and also these are the only bars that appear in the Event List. The Midi Editor and Event list show the events starting at bar 1 no matter where the clips are positioned. Bars 9 - 12 are missing.

Can't repeat that here.

Can you please email me the musession file.

[muzycian]

OK, musession well received.

The sequence in this musession file only has events up to measure 8.

No events in bars 9-12.

Maybe you accidently deleted them??

Could that be?

[davidweese]

Jo

As I recall I tried it both ways. Since the issue, I have had instances where mulab detected XBoard controllers just fine. Consider this a dead issue until it comes up again and/or I can get you better data to recreate. Same with the weird audio muting option. I need to start being more meticulous about bug/feature reports.

[davidweese]

re : controllers - bug or feature?

I assume GLOBAL means program wide, LOCAL means relating to a target, so if you assign controller 73 to multiple faders, each locally, then ctl 73 will control whichever of the racks is the current target...?

At this point choosing the same controller even with Global OFF asks to replace or merge - if Local does not relate to target, then how is it different from global?

Dave

[jpumphandle]

OK, musession well received.

The sequence in this musession file only has events up to measure 8.

No events in bars 9-12.

Maybe you accidently deleted them??

Could that be?

Thanks for looking at this. I found my problem.

I had moved the clip around on the track and then when I entered the split point, I entered the bar number for the clip location. The split point that is actually used is the original bar in the sequence. I didn't notice the switch at the time. To find the real split point, you have to open up the Midi Editor and determine the bar number of the original sequence.

So I guess this goes on my wishlist:

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 just display the events in the clip.

Another wishlist item:

Provide a method of displaying the playing time of a clip. This is especially important for Audio clips when trying to match them up with existing tracks.

[jpumphandle]

Running MU.LAB Free on OSX

Just some observations:

I am able to run MULAB Free on OSX 10.3.9. This is an iMAC with 256MB of memory and a 1.6GHZ processor and lots of dust on the keyboard. Everything runs except the Demo.MuSession. This goes into OVERLOAD almost immediately - not a very good first impression. (I am really checking this out because I was notified that MU.LAB would not run on OSX)

It appears that the Demo uses too many of the MuSynths, which apparently are not that efficient.

Normally I run MU.LAB on a PC with more substantial resources, where the CPU usage is apparent but not a killer.

As a comparison, the KraftGroove.MuSession file results in peaks of about 75% CPU on the lowly iMAC (according to the teeny, tiny meter). I am also running the MuSessions that I created for the http://johnnypumphandle.com/johnny/tutor/MuLab.htm on the iMAC to add some OSX specific details. So far these don't peak above about 35%.

My suggestion:
Pick another Demo that doesn't use quite so many resources, so light weight machines can easily get started with MU.LAB. Let the user create his own problems.

[muzycian]

Which MU.LAB version are you using, and which version of the demo song?

Because since the first public beta, each MuSynth patch can have its "Main Envelope", which defines when the sound is finished. And this definitely optimized things.

But i'm confident that you're using a later version already.

So with the demo song, when you solo each track after the other: which of the tracks takes most cpu?

And how many musynth voices are playing then?

You can see the voice count in the top right of the musynth editor (tiny number).

About the tinyness of things: which screen resolution are you working on?

[muzycian]

re : controllers - bug or feature?

I assume GLOBAL means program wide, LOCAL means relating to a target, so if you assign controller 73 to multiple faders, each locally, then ctl 73 will control whichever of the racks is the current target...?

Indeed.

At this point choosing the same controller even with Global OFF asks to replace or merge - if Local does not relate to target, then how is it different from global?

Have to check this.

Note, for now, that the "local" mode has been (temporary?) muted out of mu.lab as it could be too confusing. Global mode is simple and fun

[jpumphandle]

Which MU.LAB version are you using, and which version of the demo song?

Because since the first public beta, each MuSynth patch can have its "Main Envelope", which defines when the sound is finished. And this definitely optimized things.

But i'm confident that you're using a later version already.

So with the demo song, when you solo each track after the other: which of the tracks takes most cpu?

And how many musynth voices are playing then?

You can see the voice count in the top right of the musynth editor (tiny number).

About the tinyness of things: which screen resolution are you working on?

The Demo song is dated 4 Dec 2:14pm, no version #
The MU.LAB is named Pre Release and is dated 15 December

Turning the PROCESS OFF on all synths, the CPU is 5% (at rest - not playing)
Turning the PROCESS ON on all synths raises the CPU to 19% (at rest - not playing)

Soloing the tracks:
Track 1 - Drums = 24% peak
Track 2 - Hats = 26% peak
Track 4 - Snare = 23% peak
Track 5 - bass = 35% peak
Track 6 - Vogel = 65% peak

My screen resolution is 1440 x 900 and the CPU meter is grey on yellow on the iMAC. The CPU percent is also teeny tiny on my PC where the screen resolution is 1280 x 960.

Fun with numbers

[muzycian]

Thanks a lot for the detailed feedback: interesting!

2 specific questions:

1) what type of cpu is the iMac: PPC or Intel?

2) If you solo the "Vogel" track, and open the MuSynth editor for that one, how many voices are playing then? (see top right in the musynth editor, little number there that shows the number of active voices)

[jpumphandle]

Thanks a lot for the detailed feedback: interesting!

2 specific questions:

1) what type of cpu is the iMac: PPC or Intel?

2) If you solo the "Vogel" track, and open the MuSynth editor for that one, how many voices are playing then? (see top right in the musynth editor, little number there that shows the number of active voices)

Sorry forgot to look before. There's a teeny tiny 4 in that corner on the Vogel when it's playing.

Also this iMAC has a Power PC chip.

[muzycian]

Sorry forgot to look before. There's a teeny tiny 4 in that corner on the Vogel when it's playing.

Also this iMAC has a Power PC chip.

Ok, thanks for the feedback.

Strange, on toxicoh's 2 GHz G5 PPC, the demo only takes 37% when running.

On my Mac mini 1.66 GHz Intel core duo the demo takes 17%

Sounds like that the PPC's are having harder times with it.

I've changed some compilation settings, and have uploaded an alternative MU.LAB Free 1.0 for OSX here:

http://www.mutools.com/mulab/mulab-free ... 22-osx.zip

Please put this app into your existing mulab folder thereby overwriting the current application file (first back up your mulab.app as you have an 'Unlimited' and the above test is a 'Free'), and see how this one runs.

Looking forward to your feedback.

[toxicoh]

Hi Jo,

This new version knocks off about 5% cpu here.

Good luck with the G4s.