Q: What's the difference between a 'sequence' and a 'sequence part' ?|
A: A sequence is a sequence of events. It can also define a loop.
A sequence part is a composition part that plays a sequence from a certain position until a certain position, and also defines where the events should go to, i.e. it defines a target module.
A sequence part is not a sequence, it uses a sequence.
Saving a sequence preset will result in a MuSequence file. Saving a sequence part preset will result in a MuClip file.
Q: What to do if there was a crash while saving a project?
When saving a MuProject file, MuLab always first renames the original project file to ProjectName.backup.
If MuLab crashes during writing ProjectName.MuProject file, then the ProjectName.MuProject file will most propably be unusable.
But you can still recover the previous saved version from ProjectName.backup.
Of course this should be done with care, eventually with an extra backup done by you, so that you will not loose this precious backup when the unusable ProjectName.MuProject file is renamed to ProjectName.backup the next time you save ProjectName.
Q: When playing back my composition, sound is bad, music slows down and the CPU meter is in red. How come?
A: You've exceeded the power of your CPU. So the audio engine has not enough time to generate/process all audio in time. That results in clicks in the audio, or in a stuttered sound.
These are the critical parameters that define the CPU load:
- CPU speed (the higher the better)
- Number of CPU cores (the more the better)
- Samplerate (the higher the better sound but the more CPU intensive)
- Blocksize (the smaller the more instant the time between MIDI notes and their sound, but the more CPU intensive)
Q: I sometimes hear short beeps, how come?
A:The integrity of the MuLab.exe file is protected by the MuLab.ID file against illegal cracking.
When the MuLab.ID file does not match the MuLab.exe file you'll hear short beeps and encounter other malfunctions.
Solution: Reinstall MuLab so to make sure you have a properly matching MuLab.exe and MuLab.ID.
Q: How can I import an audio file?
A: You can import audio by using Audio File Parts. There are several ways to insert a new audio part:
- PROJECT menu -> Import Audio File. The audio part will start at the position you last clicked on in the composer.
- Click the track button -> "Add Audio Track".
- Draw a new part in the Composer using the pencil tool, then choose "Audio File", then browse for the file you want to play. This will only work if the track you're drawing a new part on is suitable for audio parts i.e. if it's connected to a rack/module that has audio input, otherwise you would not hear anything of course.
- Drag & drop the audio file(s) onto the track button or onto the composer. You can start the drag from the integrated browser or from outside the app via a OSX/Windows drag-drop.
Once you got your audio part, you can double-click it to edit it in the Audio Lab. There you can also trim the start point.
Q: How can I bounce down MIDI instruments to audio tracks?
A: If you want to get the sound of your MIDI instrument into MuLab, you have to record the audio output of your MIDI instrument.
If you want to turn a sequenced VSTi into audio, then select the relevant parts and choose File menu -> Mixdown Audio.
Q: I did a mixdown with "create new part" checked. The audio part appears in the composer and plays fine but I can't see any meter going up and down in a rack. Why?
By default, the new part which results from a mixdown is routed straight to the main "Audio Output".
This is because a mixdown is expected to contain everything and so MuLab by default assumes it's best to stream it 'dry' to the audio output.
So that's why you didn't see any level meters moving because the mixdowned part didn't go via a rack.
Of course you can easily change the target module for the mixdowned part e.g. to a rack, and so it's easy to further process the mixdown if you want.
Q: I just saved my project and chose to close MuLab. Now it's asking me whether I want to save! Why?
To avoid that question alert there should be an internal mechanism that can track each and every change to your project.
If the project has changed, ask to save, else no reason to ask that. So far so good in theory.
But practically it's not always possible to know whether a project has changed, especially when using VST plug-ins.
Because there is no simple or documented way the host can know whether a VST plug-in has changed or not.
The VST parameter data can be tracked, no problem with that, but it's about the non-parametric VST data.
For example NI Massive's LFO curves are not stored as parameters but as binary data.
That non-parametric VST data is bulk dumped to the host and it's not clear whether anything has really changed in it or not.
A binary compare of such data would not work as certain data could include the current date, or certain random numbers, it all depends on the VST plug-in.
So in the end it will be the user who has to remember whether he/she changed something or not.
Another aspect that complicates analysis whether a project has changed or not:
Imagine you have assigned a MIDI CC to a parameter.
Now you save the project in a certain state with that parameter at value X.
Then you tweak the MIDI CC and so the parameter is changed and your project sounds different.
Should that change be tracked or not? I checked other DAWs and found that this is not always tracked.
An ambiguous case.
Conclusion: It's not that simple to automatically decide whether the "Save project?" question should come on close/quit.
So MuLab stays on the safe side and asks it anyway.
Other DAWs may appear more 'finetuned' at first because they only ask it if they tracked a change but then there is a real risk you will loose untracked changes!
Q: I sometimes hear audio clicks and the CPU meter is high up. What computer do I need to buy in order to avoid getting this overload?
It depends on what up you do. If you're using sample players with lots of big sample libraries then the amount of RAM is very important of course otherwise your system will start swapping RAM to disk which can lead to drop outs.
If you're using very CPU intensive plugins and/or synth sounds with long release times (i.e. many polyphones) then the more CPU power you hav the better.
In general: The more powerful your CPU and the more RAM the better.
Also these 2 tips:
- The smaller the audio buffer size and the higher the samplerate of your audio device the more CPU this will take. Find a good balance.
- Close as many background apps / services as possible i.e. tune your system for music production. Google about it.
Q: Can i use MuLab on Linux?
Although there is no official MuLab version for Linux version (yet), here is a doc page about how to use MuLab on Linux, thanks to Michael Bohle from JackLab: MuLab on Linux.