 |
| Complete patch |
In this tutorial I will show you my way of connecting Max/MSP to my DAW of choice – Cakewalk SONAR – and also an approach to handling multi-channel MIDI information coming to Max/MSP over from the DAW. My idea was to use Max/MSP for creating instruments which would then be controlled by the SONAR’s sophisticated MIDI sequencer to which I am more than used to. While it wasn’t particularly hard to achieve this goal, there are some quirks to the approach I would like to point out.
The Max/MSP patch I am building for this is fairly simple
and uses only the basic objects Max has to offer. I would thus recommend even
to the complete beginners in Max/MSP as it offers great results and is very
easy to understand and build.
Please note that I am by no means an expert in Max/MSP and
thus there may be much better ways to achieve the same or better result. This
is simply my way of doing this. By all means please comment if you have better
understanding of the subject and can offer more effective solutions.
CTLIN Versus NOTEIN
The two objects used to send MIDI data from the DAW to Max/MSP
are notein and ctlin. Object notein receives MIDI events and can output the
pitch, velocity and channel of the event, while ctlin receives MIDI controller
data and outputs the value (0-127), controller number and its MIDI channel.
The reason why I use the latter and not the former is that
it seems that ReWire in SONAR can only have a single MIDI channel:
This creates two problems in case you have more than one
MIDI channel sending data as 1) you cannot separate incoming MIDI events by
channels in Max/MSP and 2) the onset of a new event in any of the channels
interrupts performance of the ongoing event in another channel (hence effectively
disabling polyphony). Now, this may be different in other DAWs and I will in
fact test this in the future, but for now it’s more convenient for me to use
MIDI controllers as these do not face these obstacles when using Max/MSP ReWired
to SONAR.
MIDI Controller Data
Different MIDI controllers are easily differentiated by
their numbers as they are set in SONAR. CC01 is usually Modulation, CC02 is
Breath Controller, and so on (these do not have any pre-defined meaning when
sending them to Max/MSP as only their numbers count). An easy way of achieving
polyphony thusly is by writing layer upon layer of different numbered CC data
which are then routed to appropriate inlets upon their arrival to Max/MSP. The
only rule I’ve noticed in numbering these – and it is only a rule of
convenience, not mandatory! – is that the numbers should steadily increase (i.
e. “1, 2, 3”, not “1, 2, 95”). Why this is so, we will see later.
Here’s a short loop I prepared using three controller lanes:
One important thing to note while writing such sequences –
MIDI controllers do not have end times as data attached to their events, unlike
regular MIDI events. It is thus necessary to write in end points to your values
separately, which is what is happening in the third picture with each of the
four notes having rests written after them.
All of these should be written into the MIDI track created
upon inserting the Max/MSP ReWire instrument via Insert\ReWire
Device\Uncategorized\Max 7 (actual path may vary but it’s certainly under Insert
in Cakewalk SONAR).
Grabbing the Data in Max/MSP
Once Max/MSP ReWire device is created in SONAR and the MIDI
CC data typed in, it’s time to start up Max/MSP and create a new patch. First
of all, to make any of this work, you should bring up Options\Audio Status and
select the ReWire device as your driver (in my case it’s “ad_rewire” but yours
may be named differently) and make sure the audio engine is running (the big
switch in the upper left corner).
Once that is done, we’re ready to create our patch.
The Max/MSP Patch
First of all we need the ctlin object which receives the CC
data sent by the DAW. For monitoring purposes attach two integer boxes to its
outputs #1 and #2 so that you can watch the numbers change as the playback
within DAW cycles in a loop. Below is a pic of how it looks on my end.
The next step is to route all those CC inputs according to
their numbers as we will certainly want different controllers to do different
things. The way I do it is by using gate with as many outputs as there are
controllers. This is why I said it’s best to use steadily increasing numbers as
it is most practical thing to have on screen (why have 95 outputs if you will
only use three). As is visible on the image below, output #2 of the ctlin
object controls which gate is open, and the associated CC value is then passed
along the appropriate path.
This is where this tutorial could end basically. The data is
received and directed to different outputs based on their controller numbers.
However, before passing this data onwards to the oscillators I decided to
include a basic glissando engine which could be used either for long glides
between pitches or simply for preventing nasty clicks and artifacts at points
where CC values change. This is handled via sub-patch I called glissandoEngine
and I will describe it more detail next.
The glissandoEngine Sub-Patch
The idea behind this is fairly simple – we want smooth
glissandos between value changes in our controller data instead of sudden jumps
which is how things are by default. The approach is not remarkable though,
again, there are some quirks one should be careful with. Here is how I solved
some of the problems I faced.
We start out with an inlet receiving the controller values
from the main patch. This value is then sent to a trigger which first outputs
that same value and then the bang which is used later – more on that when we
get to that.
The integer then enters a select object which checks if it
is equal to zero or not. This is one of the quirks I mentioned earlier – my
first approach was simply to send integers to mtof objects, expecting them to
return frequency zero in case of receiving zero integers. However, this was not
the case as zero integers translate to some 8. Hz when passed through mtof,
which effectively makes the rests not silent (especially audible when using
phasor~). Thus I had to check the incoming integers and in case of zero (i. e.
rests) I would send them directly to the float outputs without passing them
through mtof. The non-zero integers would of course be run through mtof and
then passed to float outputs. The result is visible in the float box below the
mtof object.
In order to have a glissando ramp at all we need a line~
object driven by an appropriate message. This message has to be in such a
format: “starting value”, “end value” “time ramp”. This translates to: “change
value from starting to end within time ramp period”. The tricky part is that
what is at the moment “end value” should immediately after become “start value”
for the next glissando – this is achieved by using triggers and floats to store
and send out values at appropriate time.
 |
| glissandoEngine sub-patch |
First of all, after the float box showing the current
frequency there is a trigger which sends out two floats one after the other. The
right output is sent out first and it first enters a float number box which I
use simply for control. Afterwards, the float goes to another trigger which
sends out a float and a bang. Float enters input #3 of our pack object (more on
this shortly!) and the bang is sent elsewhere (more on that shortly as well!).
The left output of the earlier trigger is sent to a float’s RIGHT output and is
thus simply stored and NOT fired out right away. What forces this value through
the output is the bang we mentioned just a moment ago – what is important is
that this happens only once all other values necessary for the pack object are
in place as relasing this float completes the puzzle and also triggers the pack
object into action.
Now, regarding the pack object... Its arguments are “0. , 0.
0.” – note that there are FOUR values, as comma also counts as an argument.
This is the skeleton for the message we talked about earlier: “starting value”,
“end value” “time ramp”. Let’s go from right to left, the Max/MSP way! Fourt
(right-most) of all, we have time ramp value which is actually sent
independently from the main patch and which controls how long glissandi last.
Third, we have the end value which is the most recent float received from the
main patch as CC integer and processed within the sub-patch. Second input is
the one opened by our comma – no input goes here as we want our comma never to
change. Finally, the first input is the starting value, i. e. the value
previously received and the one that is still being output to the main patch
(this is made possible by storing it within float object and only outputing it
with a bang sent out by the most recent float arriving from the outside).
Finally, our pack is flushed out into our message’s RIGHT output, as we don’t
want this to trigger the message but instead set its contents.
The message itself is triggered by the bang routed from a
trigger hit by the integer coming in from the main patch. What this achieves is
that the whole right side of the sub-patch is first performed, and only then is
the glissando initated by this one bang. The message then goes to the line
object and then goes back out to the main patch.
Outputing the Glissandi
In this simple example I have used three CC lanes and thus
have three instances of the glissandoEngine and associated controls. This data
is sent to three oscillators and then to the output via gain~ object. As I
said, these flows may be used for all kinds of purposes, but it’s fairly easy
to take it from here once you know the basics and what exactly you want to
achieve.
Conclusion
I hoped I helped clarify some of the problems associated
with ReWiring MIDI data from DAWs to Max/MSP. As I said before, there may be
better approaches to this – this is simply how I prefer to do it at the moment.
If you have any questions or comments, please feel free to write.
In case you would like to take a look at the Max/MSP 7.2.0
patch or SONAR Platinum 23.5.0 B32 project file, you can find them here: https://drive.google.com/open?id=1BMbpK2FlsS063CELmDRvODUbMVYOjQZ7
In case you want this whole tutorial as a PDF, you can have it here: https://drive.google.com/open?id=1jfIy7DHw1rKr1RwLyfZyKYbb1B-iU2Vm
Have fun with ReWire!
Nikola Pacek-Vetnic
