Darwin Grosse

The ReWire concepts we've discussed in the previous ReWire articles were based on the typical needs of most users -- piping information between Max/MSP and a ReWire host or client application. However, ReWire can also be used to take otherwise upstanding audio applications and use them for unconventional purposes. The key to this is the hostcontrol~ object, which allows a Max patch to exert control over the transport of the ReWire host. Combining this with some common Max techniques can turn the most staid audio app into a subservient audio zombie.

I would be remiss if I didn't point out one important issue: different hosts will react differently to "interesting" ReWire manipulation. Some will take all data and either use it or ignore it. Others might choose to crash rather than accept your changes. If you are planning to use any of these techniques in military applications (or even a live show), you should test, test and retest to make sure what you want to do is acceptable to the host you are using.

Download the Max patches used in this tutorial.

I've become a Logic-head of late, so I will be using Logic as the example host for my ReWire manipulation. I've created a simple MIDI-based sequence, and I'm going to start my subversive behavior by using some random techniques to alter the start/stop and location information. The sequence is mostly short staccato notes with a few legato melody phrases, and uses Logic's built-in synthesizers to do playback. There is also a nice delay/reverb effect setup to keep things ringing for a while.

My first iteration of the patch will just randomly start and stop the transport based on some generated numbers. For this, we send the pause and resume messages. Rather than getting into extensive probability programming, I'll just randomize between 0 and 5, then only pay attention to the numbers 0 and 1. Any number other than 0 or 1 will be ignored by the patch - meaning that there will be no change in the transport state.

This is all great fun, but it is a pretty unsophisticated process. I would like the system to hop around the sequence as well as starting and stopping. This is where location support comes into play. The second iteration of my patch includes a change to the current location using the seek message.

In order to understand location manipulation, you need to understand the timing mechanism that our ReWire connection is using. Most sequencing systems use a PPQ (pulse-per-quarter note) mechanism, where some number of pulses (often called ticks) occur at regular timing over the duration of a quarter note. The timing that our ReWire driver uses is very simple - it uses only one pulse per quarter note as its most granular time reference. This means that we only have the opportunity to move through the host sequence in quarter note increments.

This is why the random range used for the seek message is 120 - because the sequence is 30 measures long, and in 4/4 time. With four quarter notes per measure, and 30 measures in the sequence, we have 120 quarter notes to work with. Since the beginning of the sequence is pulse 0, we really need to jump between 0 and 119. Using the random 120 object is perfect for exactly this range.

In order to get more jumping than starting and stopping, we extend the range of random number that are used, and also extend the range of numbers that will generate a seek message. We can also force any change in the location to generate a resume message, since we will want to hear the change in location even if the transport is pause. In this case, we will hear many more location changes than starts and stops.

In order to add a little spice to our playback, we can also manipulate the loop range of the sequence. This works well with slower changes, and requires a little thinking ahead. We will want to set the loop start point within a useful range (0-116 pulses), and will want to have the loop end point to be greater than the start point. We do this by calculating the start point, then adding between one and four quarter notes to create a valid (but short) loop range.

We again change the probabilities of message generation by using different results from the random number creation. We also add a connection from the loop generator to the seek message. This forces a change in loop position to cause the playback location to move to the loop start point.

Playing the above patch, we find that the result is pretty interesting, offering some cycling without boring us with a too repetitive playback routine. However, the tempo is static, giving us sort of a four-square sound. It's time to add a little tempo manipulation to the mix using the bpm message.

A new random number range is used to generate useful tempos. In the case of Logic, there is some sensitivity to extremely fast and slow tempos, so I keep the range within sensible parameters (60 to 240 bpm). Also, I don't want the tempo to always jump from slow to fast, so I've used a line object to ramp the tempo as settings change. The result is a much more interesting result, with both tempos and notes moving around in an interesting manner.

In the above examples, we've used ReWire to take a simple (and boring) sequence and turn in into a sorta-living, kinda-breathing auto-ambient music generator. This is just one use of the ReWire subversion techniques - you could easily expand these ideas into other genres, and use them to perform mixing and performance ideas that would be impossible to do manually. While working with ReWire isn't always intuitive, seeing the possibilities for unusual sequence manipulation may offer options that neither your sequencer nor Max/MSP can do alone.


The ReWire concepts we've discussed in the previous ReWire articles were based on the typical needs of most users -- piping information between Max/MSP and a ReWire host or client application. However, ReWire can also be used to take otherwise upstanding audio applications and use them for unconventional purposes. The key to this is the hostcontrol~ object, which allows a Max patch to exert control over the transport of the ReWire host. Combining this with some common Max techniques can turn the most staid audio app into a subservient audio zombie. Read more...

rewire-3-subversion-with-rewire

Rewire 3: Subversion with ReWire

Nikolas K

beatlines-step-sequencer

BeatLines - step sequencer

In this second installment of the ReWire Essentials series, we are going to look at hosting ReWire client applications. Clients route their information to the host (or mixer) application through the ReWire mechanism, and using Max/MSP as a host gives us options to have some fun with both the playback and output of the connected application.

The basic connection strategy for hosting ReWire clients involves the rewire~ object. This object gives us the means to select a ReWire client, use the available audio outputs and control the connected devices transport controls.

It doesn't take much for Max/MSP to be a ReWire host - the rewire~ object is the magic ingredient. This object accepts two arguments: the client device's name, and the number of audio outputs to be created. However, both of these arguments are optional; you can use a message to select a client, and the number of channels defaults to a reasonable stereo pair.

In order to know which clients are available to the rewire~ object, you can connect the second outlet from the right (with the hint text: "Menu of Installed ReWire Devices"), and connect it to a umenu object.  Now, when you bang the input (or when you save and open the patcher again), this umenu will contain all of the ReWire devices you have on your system. When you change menu entries, you will see the message "rewire~: opened device XXX" in the Max window.

Once you've selected a device, you need to be able to open the client program. You can do this manually, but it is much more convenient to open the client from your Max/MSP patch. The openpanel message (when sent to the rewire~ object) will open the selected application and create all of the connections between Max/MSP and the client.  The closepanel message is the same as exiting the client from its menu. Not all client applications respond to these messages; for example, Reason reacts to open/close operations, but Ableton Live just ignores them.

Now that we've instantiated a device and opened it, we will want to route the client's outputs to the Max/MSP outputs. ReWire clients can have up to 256 outputs, but not all of them are useful to us. In most cases, the first two available outputs will provide a stereo mix - we just need to expose them to the two outputs of the rewire~ object.  This mapping of client audio signals is accomplished with the map message.

In order to see the available client outputs, we connect umenu objects to the rightmost outlet of the rewire~ object.  When rewire~ receives a bang (or when a saved patch is opened), this will load the menu with all of the outlets provided by the client. In our example patch, we will have two menus - one for the left output (numbered "1") and one for the right output (numbered "2").

Now, the addition of two map messages will allow us to select the client outputs that we want to use within Max/MSP. Once these are set up, and the audio outputs of rewire~ are connected to an ezdac~ object, we are able to create audio in our client that is exposed to our Max/MSP patch and sent to the audio output.

Next up is controlling the transport of the client application (assuming it has a transport). In my examples, I will be controlling the transport of Propellerhead's Reason, but you will find that this mechanism works regardless of the client in use.

Turning the transport on and off is pretty simple: the rewire~ object responds to 0 and 1 as off and on, which is exactly the output of a checkbox object.  So, connecting a checkbox to the input of rewire~ will turn the client's transport on and off.  Tempo is similarly controlled using a tempo message, combined with a floating point number.  In our example, I use a numberbox to control the client's tempo.

Controlling transport position is a little trickier. There is a position message that will tell the client where to go. However, this message takes a position parameter in samples, so you will have to do some calculation to make it work correctly. In the example, I have two position messages: one (the position 0 message) is the equivalent of "Return To Zero", the other takes the output of a numberbox (treated as seconds), multiplies it by 44,100 to turn it into samples, then sends the message to the rewire~ object. Note: this makes a lot of assumption; most importantly, it assumes that you are working at a 44.1K sample rate. If this is not the case, you need to change the calculation to match the sample rate of your project.

Finally, in addition to controlling the on/off state and current position, we can also control the loop parameters of the client. This is done through the loop message, which takes three parameters: loop start (in samples), loop end (in samples) and loop on/off. I've added this to the example program, but didn't convert the numberbox objects from seconds to samples - this is something that you can do for a ReWire exercise!

Controlling a transport may be your cup of ReWire tea, but there are other ways to use ReWire connectivity. One common method is using Max/MSP as a bridge to control and effect instruments within the Reason environment. Reason has a lot of built-in functionality, but its sequencer seems somewhat pedestrian, and the lack of support for standard plug-ins means that you may have trouble using Fragulator (or using any other VST plug-in) on your audio signal.

Sending a MIDI message to Reason is very simple; you format a message the way that is acceptable for the rewire~ object.  This requires a midi message, some number formatting and a little ingenuity. The arguments for the MIDI message are rather low-level (and closely related to the MIDI spec), and may not be totally familiar to the first-time user.

All midi messages are in the format "midi t b c n n...", where:

b is the ReWire MIDI bus (between 0 and 254, but normally 0),

c is the MIDI command (generally called the "status byte"),

n, n ... is the data for the selected MIDI command.

Let's focus on the MIDI command (or status byte). In MIDI world, status bytes are a combination of the command you want to transmit, and the MIDI channel you want to affect. So, for example, a 144 means that you want a note-on to be triggered on MIDI channel 1, while a 146 would represent a note-on triggered on channel 3. You can think of 144 as being the "starting point" for MIDI note-on messages.

Following the status byte, you need to send the appropriate data for the selected command. In the case of a note-on, you need to send the note number and a velocity level. Other messages may require fewer data bytes; for example, a program change command only needs a single data byte: the program number.

Here is a chart of the basic MIDI status bytes and the data they require:

In my example, I've removed all of the transport controls, and am left with a wide-open work area for the new section of the patch. In my particular case, I'm connected to Reason; however, you can tie into the ReWire connection of almost any program that has a performance instrument or synthesizer. Using the midi messages, I can add a couple of messageboxes with various command, and I can easily control the ReWire'd instrument. I can also create my trusty "random note generator", feeding a makenote object, to created the melody of the cosmos…

I also want to run ol' Fragulator on the result, so I've put a vst~ object on the outputs of the rewire~ object. Adding a few controls allows me to open and adjust the VST options, resulting in a live control and effects system for my Reason software system.

In this tutorial, we learned how to connect to a ReWire client application, how to route its audio, how to control the transport and how to send it MIDI messages. Using this information creatively can provide totally new methods of music creation. Some example of interesting applications might be:

A vinyl-style "spin-down" of an Ableton Live client (using the tempo message).

A complex keyboard mapper for Propellerhead's Reason (routing incoming keyboard messages to multiple Reason instruments).

Creating glitch-y playback of an FL Studio project (by rapidly changing the current position and loop points).

As you can see, it is easy to envision ReWire as a starting point for integration of new technology into your Max/MSP programming. It is just as easy to see Max/MSP as a "glue" technology to combine different programs into a single complex environment. In our next ReWire tutorial, we will look into further control of a host program, featuring the hostcontrol~ object.  Until then, have a blast using ReWire client control tools to horrify and mystify your friends and family!


rewire-essentials-part-two

ReWire Essentials 2: Host ReWire Client Applications

toxic

toxic-synth-8-note-polyphonic-fm-synth-with-modular-effects-routing

Toxic Synth (8 note Polyphonic FM synth with modular effects routing)

kenders2000

Max was used to write an advance tap tempo calcualte

or for accurate syncronisation of a rewire host application with a live drummer.

project91-tap-tempo-improved-accuracy

Tap Tempo - improved accuracy

nicholassagan

This project uses the Rewire and a series of pseudo-random midi triggers and locators.  It was set up with a quad-speaker array and video of abstract celestial objects was projected within the array.  To hear this version double-click the 'midiout' object and select the internal synth (not Max/MSP!).  Then hit the large toggle and enjoy!

project15-before-we-werearewill

Before We Were/Are/Will

While there are many methods to move MIDI and audio data between programs on a computer, ReWire (developed by Propellerheads) has become the most popular system. It allows a fairly seamless integration of client and host applications, and is also well supported by most major DAW applications.

In this tutorial, we will show connections to two major software packages: Ableton Live and Digital Performer. However, if you use a different application, you should check the documentation to learn more about its ReWire implementation. In most cases, the process is the same:

You create a channel in the host to accept Max/MSP input.

You create (or load) a Max/MSP patch and turn on the DSP output.

In order to allow Max/MSP to speak to your ReWire host, you have to use a special output driver named ad_rewire. This output driver provides a connection to the host for routing audio, MIDI and timing information between the client (Max/MSP) and the host (your DAW application). You select this driver in the DSP Status dialog (available from the Options menu). When selected, you are also given the option to select the number of virtual MIDI ports that will be exposed by the ReWire interface. In this case, we will leave the number of ports set to "1".

In order to create a simple test patch for our ReWire connection, I've created the most simple audio patch possible: a cycle~ object connected to an ezdac~ object. Since I will want to control the volume in my host application, I've avoided adding any other controls to this simple patch. Once created and locked, I can click on the output object to begin audio generation.

Within Ableton Live, I need to set a channel that will receive the ReWire audio input sent from my Max patch. Selecting an audio channel, I've changed the "Audio From" menu to select MaxMSP, and verified that I am using the first two outputs (the default output of the ezdac~ object). Now, if I change the Monitor setting from Auto to In, I can see the level meters light up, and will hear a 74 Hz tone coming through Live's audio output.

Connecting a Max/MSP patch into Digital Performer is equally simple. Since Max (and my patch) is already operating as a ReWire client, there is no need to change anything there. I start DP and change to the Mixer view of my project, then create a new Aux channel – making sure it is routed to an appropriate audio output. I then select MaxMSP 1-2 from the "New Stereo Bundle" list to complete the setup. If I start the output of the patch, I will see that the audio is routed into the Digital Performer channel, and I can change volume, pan or add effects.

While it is nice that we can get audio from Max/MSP into our host application, anything beyond the most basic patch will need to get some information from the host – particularly timing and transport information. This is one of the powerful features of ReWire: it not only pipes audio, but also provides the necessary data to create host-aware patches. In order to access this data within Max/MSP, we need to learn about the hostsync~ object.

The help patch for hostsync~ is very informative; it shows the object retrieving the transport status, current time, current "musical" settings (like time signature and tempo) and even the current loop settings. This is most of the information necessary to make a custom patch interact with the host in a more predictable way.

You have probably noticed that there is a metro connected to the input of the hostsync~ object. Why? Because data streaming in from a ReWire connection happens very fast, and using this data would, in most cases, require more conversion than necessary. By having all of the output as standard Max data types (integers, floats and lists) and using an input bang to "sample" the high-speed datastream, we can reduce the amount of conversion necessary to make use of the output data.

Using the hostsync~.help patch, then running it while connected to our host, we can see the interaction between the host program and a Max patch.

Each time metro generates a bang message, hostsync~ reports the current state to the connected display objects. The next step is to use this information to create a host-aware patch.

To create this patch, I'm going to use a subset of the hostsync~ data: specifically, I'm going to use the beat output to trigger random frequency settings, and the bar output to trigger random filter changes. It's a simple patch, but you should be able to see some of the possibilities when using the hostsync~ object.

The output of the bar and beat outlets are used to drive two random objects, scaled to an easily audible note range, changed into frequencies (using the mtof function) then routed to audio objects. If you turn on the ezdac~ and metro objects, then start the transport of your ReWire host, you will hear the output of the patch match the timing of the host.

This patch could easily be improved by turning off the output when the transport is stopped (by using the transport state outlet to control the ezdac~ object), or by speeding up the output (using the fraction beat outlet). But this patch is a good example of using the host information for musical/compositional purposes.

While the output of the hostsync~ object can be useful, sometimes you need a faster or more precise output.  This is the domain of an object named hostphasor~, which provides a synchronized phasor-like output tied to the host transport. Altering the above patch to use hostphasor~ (in this case, for filter cutoff animation) is fairly simple:

Since the one-cycle-per-quarter-note movement of the filter may not be to your liking, you may want to use the rate~ object to speed up or slow down the movement of the waveform, or even use the hostphasor~ output to drive a different waveform (using it as a phase driver, rather than a direct output).

In this case, we've used the hostphasor~ object to drive a triangle~ object (tweaked to our liking), at a rate 16x slower than the typical beat cycle. We've also scaled the output to 0-8000 Hz, giving us a basic filter sweep that occurs in time with the host's timing.

At this point, you are probably getting a little tired of the random note generation, and would like to control the notes from a MIDI channel in the DAW. You might also like to make the sound of the oscillator a little more interesting, so we will use frequency modulation (FM) to make the sound more complex. These two changes will make up the last patch of this tutorial.

In order to create and access incoming MIDI, we need to start at our host. Create a MIDI channel with some notes in it, and route the output to the Max/MSP ReWire MIDI output. In Ableton Live, this means selecting the "MaxMSP" MIDI output (not the "to MaxMSP" outputs!). You will see that the port changes to "ReWire 1", indicating that the first (and only) ReWire MIDI channel will be used for output.

Within our patch, we need to disconnect the random system from controlling the saw~ object, and use the output of the notein object instead. In order to choose the MIDI port, we use the common "midiinfo-to-menu" selection objects that you will see in most MIDI-based patches. We follow it up with a stripnote object (to remove the note-off messages), and route the note number through an mtof object to control the sawtooth waveform frequency.

To make the patch more interesting (and to use that forlorn hostsync~ object), we will extend the patch to use the "fractional position" output of hostsync~ to drive a second oscillator, and have it frequency modulate the main oscillator. The output of hostsync~ is scaled (to +/- 4.0), then combined with the note value to create a fractional note value that is constantly changing. This value drives a cycle~ object, which in turn is scaled and used to drive the sawtooth oscillator. Initially, there won't be any difference in the sound, but if you increase the "FM Depth" number box (especially past a value of .25), you will hear the sound become more uncontrolled and harsh. Large setting will drastically change the timbre and perceived pitch of the base notes.

Finally, in order to make it even less irritating, we can set up the velocity part of the note message to trigger a line~ object, which in turn closes down the output when no MIDI messages are being received. This prevents the patch from squawking when the ReWire transport is turned off.

In this article, we've created a ReWire connection to a host, and used the hostsync~, hostphasor~ and ReWire MIDI connection to create a Max/MSP patch that is controlled by the host. There are many ways you could extend this patch: you could add a synchronized sequencer for the note or filter settings, use the hostphasor~ for adding LFO-like modulations or add time-sync effects. One of the great side effects of the ReWire interface is the ease of creating patches that are responsive to the host environment.

In our next ReWire tutorial, we will look at having Max/MSP be the ReWire host, and using the rewire~ object to create a connection to several commercial ReWire clients.  But until then, patch up a storm!


While there are many methods to move MIDI and audio data between programs on a computer, ReWire (developed by Propellerheads) has become the most popular system. It allows a fairly seamless integration of client and host applications, and is also well supported by most major DAW applications. In our tutorial, we will show connections to two major software packages: Ableton Live and Digital Performer.

Search Results