/ Examples / NoteStream / Midi Device

Projects .. AudioIO .. Control
NoteStreams .. Instruments
Filters .. Effects .. LiCK Effects
Plot .. Utility .. Pure ChucK


Wherein we present intimate details of the MidiDevice node.

Right-click to copy this example to your workspace

This example was constructed with a MIDI Keyboard associated with the MidiDevice node on device id 0. The keyboard was equipped with a pitch wheel, and a few control knobs. These control signals were mapped to connect to StkRhodey's and Chan0's controls. If you don't have a MIDI device you won't get much joy out of this example. If your MIDI devices differ from mine you may need to re-map the control signals as determined by you and your device.

Here is the MidiDevice node in action. There's a lot going on here. The critical components of the graph are the four nodes along the Graph's top row. Only if you wish to get fancy do you need to build a more complex graph like this one.

Role Call

MidiDevice the source of all but one of the control signals in the graph. You can have multiple MidiDevice nodes in a graph and repeating device association is allowed.

Player outputs control signals via two output ports. Its Controller output sends notes plus controls to Stk Rhodey while its CC port delivers the same control stream but with notes filtered out. Player also performs CC name remapping according to its CCAliases connections, each of which is an Alias node.

StkRhodey synthesizes sound based on the incoming notestream.

Chan0 implements an effects chain and responds to the Pan requests deliveredy by Panner and Mix requests deliverd by Player0.

Panner is a CCSampler node that emits a control signal governing Chan0's Pan parameter. It's driven by SinOsc whose values between -1 and 1 are remapped to a different range by the Remapper node.

MidiDevice

Here are the parameters for MidiDevice.

DeviceIndex is the crucial parameter that selects which of potentially multiple MIDI devices to respond to. You can use chuck probe to dump the ids for all your devices. Since device ids can change with changes to your operating system drivers and due to USB port wiring, etc. it's a good idea to name your device node descriptively. It's also a good idea to minimize this sort of churn since it may "break" some of your project files.

PitchWheelGain is a multiplier for the pitch wheel values to allow for a greater range of pitch bends.

VelocityFloor is a minimum value for the velocity of a key-down event. Raise this value if you'd like your notes to ring louder abeit with less expressivity.

Debug is useful to determine which CC events are associated with the extra knobs on your device. When enabled, munging your device's knobs will produce diagnostic messages to appear in the Log Panel.

Alias

While the Alias node is both trivial and generic we present it here because its primary use is to remap MIDI control channel names to arbitrary parameter names associated with downstream nodes in your graph. An Alias, or name mapping, represents a conversion of an input name to the output name. At right we see that the value of the input, CC71 is a selection from a long menu of the most common MIDI control channel names (plus a few extras).

We can also see that the alias for CC71 is LFOTouch which happens to be a parameter of the Stk Rhodey instrument. As described above, you can enable the MidiDevice/Debug parameter to inspect the names associated with your device knobs. Standard MIDI names and numbers are found here.

home .. topics .. interface .. reference .. examples .. tipjar