Difference between revisions of "MuLab notes"

From Helpful
Jump to: navigation, search
m (Tracks and modules)
m (Tracks and modules)
 
(6 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
==Random usability things==
 
==Random usability things==
  
===Tracks and modules===
+
===Tracks, modules, racks===
  
 
<!--
 
<!--
'''Module racks'''
+
'''Modules''' are basically anything with input or output.
 +
 
 +
 
 +
'''Module racks''' are a set of modules
 +
: that have some routing logic - it generally makes sense to handle one purpose per rack
 +
: and e.g. in modular view show up as their overall input and output
  
 
'''Modules''' are most recognizable as  
 
'''Modules''' are most recognizable as  
 
: module racks, presented as modules in the Modular view (e.g. extra outputs)
 
: module racks, presented as modules in the Modular view (e.g. extra outputs)
: modules added in the Modular view exist ''only'' there.
+
: modules added in the Modular view show up ''only'' there.
the things in module racks - though can also be
+
  
 +
There is some possible confusion because both are views on the same thing that both hide some details the other shows.
 +
You may wish, for your own clarity, to focus on one. And often that's
  
  
'''Tracks''' as individual things make sense when you think of recording.
 
  
 +
'''Tracks''' are only necessary when you want to record events/sound for a particular module.
  
'''Audio track''' will record the target module into a waveform.
+
If often makes sense to make tracks only for things you actively play/use,
 +
and only once you want to record something for them.
  
An '''Instrument track'''
+
Often that means racks, because you'll probably have set up each as a
 +
a single sensible functional things.
  
An '''automation track''' (only as sub-tracks on instrument tracks) lets you record events to be sent t
+
But you ''can'' have tracks for every individual module.
 +
: Sometimes that makes no sense
 +
: sometimes it makes automation sense
 +
: sometimes it makes more sense than racks - e.g. when you have a splitter that plays ''several'' racks simultaneously, it makes sense to record MIDI into that splitter
  
 +
 +
Right-click and "Add ''type'' track" creates a new empty rack.
 +
(And if you create racks in the rack list, you may never do this at all)
 +
 +
But it may make more sense to
 +
: create new tracks for a Rack, or modular-view module (drag it onto the + in the track list) as you wish to record them.
 +
: you can also just hit record and play whatever
 +
:: which seems to record the module that you routed to (can be a rack, but also functional routing things before them)
 +
:: but this initially leaves it unassigned to a track, which can be confusing.
 +
::: I guess it does this so that you can always spontaneously record, and ''then'' figure out exactly what to do with
 +
 +
 +
At top level you can
 +
* Add Instrument Track
 +
: asks for internal/VST instrument (also allows tracks)
 +
: seems meant as "start a new rack to make sounds with"
 +
: would record events for that rack
 +
 +
* Add Audio Track
 +
: seems meant to record a module into a waveform
 +
: start a new empty rack
 +
 +
 +
* Add MuSample Track
 +
: adds rack with a MuSample instrument (with the sample you selected when prompted)
 +
 +
* Add Track
 +
: no target module, no created rack
 +
: can be useful
 +
:: as a new parent to visually organize other tracks
 +
:: to drag a rack/module onto (same as draggint to +, though)
 +
 +
 +
Under an existing top-level track you can add
 +
* a sub-track
 +
 +
* automation sub-track
  
  
  
There are multiple ways to get about
 
  
 
A track has a target module (well, can)
 
A track has a target module (well, can)
Line 51: Line 98:
 
===MIDI routing===
 
===MIDI routing===
 
<!--
 
<!--
When
+
 
: you have one controller that you use purely for tweaking and into distinct tracks at a time
+
Mulab MIDI routing is set up with the idea that
then auto focus is probably (see below) is quite convenient.
+
: while fiddling around you often want to play the thing you're currently point at  
 +
: once you've set things up, specific devices routed to exactly the sound producers you want
 +
 
 +
Mulab defaults to the first, and more specific configurations shifts to the latter:
 +
By default, channels that are not routed to a specific place (so ''all of them'' in a new project) go to whatever has MIDI focus -- and once they are routed, focus no longer matters for these channels.
 +
 
 +
 
 +
 
 +
A MIDI channel can be routed to a specific
 +
: track
 +
: rack
 +
: module
 +
:: in a rack, or
 +
:: only present in the Modular area
 +
:: and note that routing it to things like the Midi Channel Splitter (Event Processors) lets you target multiple things in complex ways
 +
 
 +
There is more than one way of routing, but the most flexible way of doing this is probably
 +
: Project &rarr; Edit MIDI Input Channel Targets
 +
 
 +
 
 +
Notes:
 +
 
 +
 
 +
 
 +
 
 +
 
 +
On top of that is a bit of specific logic you need to understand.
  
  
When
 
: you have more than one controller,
 
: a controller sending more than one channel,
 
: external sequencers and using MuLab more as a synth host than a multitrack recorder
 
then you probably care to route specific channels to specific modules.
 
  
  
Line 66: Line 134:
 
'''MIDI Input Channel Targets'''
 
'''MIDI Input Channel Targets'''
  
Each channel can be sent to a specific module.
+
By default, GUI focus alters MIDI focus (see below)
 +
: change that by disable the change of MIDI focus.
  
By by default it goes to whatever has MIDI focus. (in a new project, all of them will)
 
  
And by default, GUI focus alters MIDI focus (see below).
 
  
  
  
Perhaps the clearest overview of channel targets is at ''Project &rarr; MIDI Input Channel Targets''
+
 
 +
...and you can ''still'' get away from under such fixing, by changing the sending channel of the MIDI controller.
 +
 
 +
 
 +
'''Why the following focus / not?'''
 +
 
 +
The idea is roughly that when you have one controller that you use purely for tweaking all the racks, and then record distinct tracks at a time, then auto focus is probably more convenient
 +
 
 +
And when you have more than one controller, OR a controller sending more than one channel, OR are using MuLab more as a synth host than a multitrack recorder, then you probably care to route channels to specific modules.
 +
 
 +
 
 +
Perhaps the clearest overview of current channel targets is at ''Project &rarr; MIDI Input Channel Targets''
  
 
Not that the the module racks are just the most visible thing to send to.  
 
Not that the the module racks are just the most visible thing to send to.  
Line 120: Line 198:
  
 
http://www.mutools.com/info/M8/docs/mulab/main-menu.html
 
http://www.mutools.com/info/M8/docs/mulab/main-menu.html
 +
 +
-->
 +
 +
===Project files===
 +
<!--
 +
By default these are kept alongside the binary, under 
 +
Program Files\Mulab-yourversion\Mulab (32/64-bit)\User\Library\
 +
 +
 +
This is less ideal around updates.
 +
 +
...Also because paths to recorded audio are absolute, so when you move your user folder around you'll get '''"Couldn't find audio file"''' and probably to use Search (all) to have mulab resolve them at their new place.
 +
 +
If you've ''removed'' a file, it's a little annoying that you can't make it remove it.
 +
You may want to point it at a random wav (via Locate), then remove it from the project?
 +
 +
  
 
-->
 
-->

Latest revision as of 22:45, 6 February 2021


Random usability things

Tracks, modules, racks

MIDI routing

Project files