Making a MIDI Mixer With Novation Control XL: Questions


I am trying to use the Novation Control XL as a mixer surface (for different parts of my Audulus patches).

I looked at the two threads below (by @stschoen ):

But I cannot seem to find a where the MIDI signal is coming in in the patches…

Is there a general MIDI guide for Audulus: what messages it registers as input? I looked at the MIDI nodes docs… but I’m looking for a more general introduction/explanation, since I am not dealing with a keyboard, a trigger or a pitch bend. :slight_smile:

If there is no general MIDI guide, how could I connect the MIDI from the Control XL (details below) to my Audulus patch?

A little about the Novation Control XL:

There is a template editor where I can make a MIDI template (for Audulus). I can set the channel, min/max values for each button/knob/fader. Faders and knobs are CC messages. Buttons can be Note or CC.

I currently have a template which I use to control my Octatrack loaded. I’m attaching screenshots of the editor as well as some signal examples below.


There are 4 MIDI nodes available in Audulus. The primary node is the keyboard node. It receives MIDI note-on and note-off messages and outputs frequency and a gate who’s height is proportional to the note’s velocity. You can program it for Omni (all channels) or a specific channel. It supports legato (single note) or 2, 4, 8, or 16 note polyphony. Note that when in polyphonic mode the gate height is fixed at 1 although there is a workaround available.
The second node its the pitch bend node. It receives pitch bend messages and outputs values from 1 to -1. It is hardcoded at omni and is not channel specific
The third MIDI capable node is the Trigger node. It also receives MIDI note-on and note-off messages and outputs 0 or 1. It is programmed by using the MIDI learn option in the context menu. It’s also hardcoded at omni. Note that the Toggle option is not applicable to MIDI messages.
The last MIDI capable node is the knob (either version). It receives MIDI CC messages and like the Trigger node, is programmed using MIDI learn.
There are library modules that provide enhanced functionality for the keyboard node like slew, conversion to 1/octave etc.
Finally MIDI functionality is currently limited in the macOS AU. MIDI CC is not available and the keyboard node only receives on channel 1 regardless of how it’s set.

Thanks for clarifying!

The Learn MIDI CC part for knobs and triggers was the missing piece of the puzzle for me!

I also experienced some unusual behavior: the very first time I plugged in the Control XL and tried MIDI CC Learn with the Knob node the signal did not register in Audulus even though I could see it in MIDI Monitor. So I unplugged it to try my Korg nanoPAD2, got that working… and when I plugged the Control XL the 2nd time, the MIDI CC Learn worked. This is all using the same USB port.

@stschoen thank you so much for explaining how this works! A couple of questions:

  1. Have you figured out how/what to use the XY pad on the nanoPAD2 for? I could not figure out how to use it with Audulus.

  2. I am not familiar with pitch bend messages. Is there a software that will allow me to take a CC message and turn it into a pitch bend (or I have to always use a pitch bend controller hardware)? I have a Minilogue here, so I can try it with it, but I don’t want to depend on it.

@biminiroad I think that in the docs the Knob node should either be listed under MIDI OR have a more explicit/prominent way of signifying that it has the MIDI Learn capability. Right now there is this sentence: Typical Use - Creating an interactive parameter that can be dialed in directly by tap/click and drag, assigned a MIDI CC, or modulated directly with a wire.

I recommend at least adding something like:
MIDI CC Learn - To assign the knob to a MIDI knob/control, right-click on the meter section, select Learn Midi CC and then move the knob/control on your controller. To unassign the MIDI key, select Unassign CC from the button’s right-click menu.

I am happy to make small edits like this to the docs and submit them as pull requests on GitHub. But I’m not sure if you see the docs as a collaboration/open source project? :slight_smile:

I’m excited to try making a mixer now. I’ll post here if I run into any issues. Thanks!

1 Like

By default, the X-Y pad on the nano pad is configured for X to send CC1 (mod wheel) messages and Y to send pitch bend. It is also configured to send CC 16 when it is touched. You can change these assignments with the editor software. When touch is enabled the knob will pick up the touch message first so the X direction CC won’t be configured. If you want to use X or Y to send CC messages you will need to disable the touch function.
Pitch Bend is a different MIDI message type than Controller Change but there are several apps that allow you to re-map various MIDI messages, The NanoPad will give you pitch bend so it might not be necessary. Pitch bend actually uses 2 messages to provide 14 bit resolution rather than 7 so mapping a CC message to pitch bend might be a bit jumpy.

I see. Thank you for explaining how it works! Has anyone made a patch where the XY of a device like the nanoPAD2 is mapped to something like a filter frequency + resonance or some other functionality which lands itself to an XY control?

I don’t have a classic or synthesis background so pitch bending is a new thing for me. I will try it though. Maybe I am missing out. :slight_smile: I’m just wondering what other creative uses people have come up with already for an XY control surface. I’m not sure if that’s a common thing in hardware modules. And I’d love to play with KaosPad 3+. Or something with similar logic.

I haven’t actually played with the XY pad on the Korg very much, but Ableton Live has an XY device that the Korg would map to very well. No reason that you couldn’t use it for filter freq/resonance or any other pair of parameters you might wish to modulate at the same time. I do use pitch bend but it’s a bit more controllable with a traditional pitch bend wheel.

1 Like

@stschoen does audulus take midi program change messages? if yes, which module do i use to receive them? if no, what workaround is there to trigger patch changes?

The current version of Audulus cannot receive MIDI program change messages, only note on/off (keyboard node and triggers), pitch bend and control change (knobs) messages. Currently there is no mechanism to dynamically load a patch. Of course you can change the behavior of a patch by using a knobs or triggers to control parts of the patch.

I see.

I did not mean to change the patch that’s currently loaded. I meant to make a mega patch and switch between different parts of it.

I think that in the present my best bet is to use an on/off (or CC) message to make this happen. How would you recommend I setup the receiving logic for this? What is the simplest way to accomplish:
A) a basic conditional statement: if ON follow this part of the patch, if OFF follow the other?
B) a switch statement: if CC value 1, follow this part of the patch… if CC value 2 follow that part… and so on?


An incoming CC message will be a value between 0 and 127 but will be translated by the knob into a 0 to 1 output. Since the output from the knob will be a fractional floating point value, using an == in a conditional may cause you some problems due to rounding errors. It somewhat depends on what you’re sending from. If it’s practical, the most reliable way is to use an expression like: knob > 0.5. This will output 0 if the the CC is below 63 and 1 if it is above. Use a CC value of 0 for off and 127 for on and you should have a reliable switch. You can feed the output of the expression into a crossfade node to select different signal sources.

For more than 2 sources you could use a demux and divide the knob output into multiple sections, but you need to be careful that the CC values you send are in the center of each sub-range.

Okay. I understand the logic for these. I will try them. Thank you!

Now a question on CPU resources:

If I have “megapatch”, meaning a patch that holds instruments for an entire set (say 5 sections/parts with 5-6 “instruments” per section/part), would you recommend that when I switch away from a part (section of “instruments” in my patch) I figure out a way to turn that part of the patch off so (there is no signal going through it and thus) no CPU is used for the parts which are currently not audible?

P.S. I will likely run some samples on a separate machine (Octatrack or Akai Force) in parallel with Audulus in this scenario… so not every sound will be coming from Audulus… but a substantial part would. Like playing live with a drum machine + modular… Audulus being the modular. :slight_smile:

Unfortunately there isn’t any way to currently shut off part of a patch. Any signal path that is connected to an output node is live. An output can be a light, a value node, a meter, a DAC, speaker, etc. The only way to “shut off” a path is to physically remove a connection. This might be possible to do between sections if you have the patch laid out so that the connections are easy to make and break. I’ve made a feature request for a switch that could break a signal path and shut off processing, so maybe in Audulus 4. I would love to have a set of toggles that could turn on and off parts of a patch.

Hmmmm… I use value nodes + meters rather liberally… so it does not sound like it will be easy for me make switches which turn off entire parts of a patch.

Is there any estimate or place to follow on updates related to Audulus 4 or is it the kind of thing where we won’t know when it will be released until it is out? :slight_smile:

Even lights, meters, value nodes etc. that are within sub-patches and aren’t exposed cause the circuit to be processed, so I typically remove them once I’ve finished debugging unless they’re part of the UI.
The forum is the only public source of info regarding future releases. Since things have a habit of changing as development proceeds, it’s difficult to have a firm release date. I know @Taylor is hard at work, but V4 is a pretty significant rewrite, so I think there’s still quite a lot to be done. In addition to the V4 stand-alone there is also the AUv3 for iOS and macOS that needs to be developed. Probably best to focus on what we have at the moment rather than worry too much about the next release.