HelpSource/Guides/UsingMIDI.schelp

   1 title:: Using MIDI
   2 summary:: Notes on MIDI support in SuperCollider
   3 related:: Guides/MIDI, Classes/MIDIFunc, Classes/MIDIdef
   4 categories:: External Control>MIDI
   5
   6 keyword::MIDI
   7 section::Introduction
   8
   9 SuperCollider's out of the box MIDI support is fairly thorough (although not as complete as you'll find in commercial sequencers). All MIDI devices accessible to your operating system (CoreMIDI on OSX, ALSA on Linux, PortMIDI on Windows) are accessible to SuperCollider.
  10
  11 note::
  12 This document is written from an OSX perspective. The essential behavior of the MIDI interface classes should be the same on other platforms, despite my continual reference to CoreMIDI here.
  13 ::
  14
  15 SuperCollider does not impose much higher-level structure on MIDI functionality. The core classes are little more than hardware abstractions (see also the link::Reference/MIDI:: helpfile):
  16
  17 definitionList::
  18 ## link::Classes/MIDIClient::
  19 || represents SuperCollider's communications with CoreMIDI
  20 ## link::Classes/MIDIIn::
  21 || receives MIDI messages and executes functions in response to those messages
  22 ## link::Classes/MIDIOut::
  23 || sends MIDI messages out to a specific port and channel
  24 ## link::Classes/MIDIEndPoint::
  25 || a client-side representation of a CoreMIDI device, containing three variables (name, device and uid, which is a unique identifier assigned by the system)
  26 ::
  27
  28 In most cases, each physical MIDI connection (pair of in/out jacks on the MIDI interface) has one MIDIEndPoint object to represent it in the client.
  29
  30 section::Receiving MIDI input
  31 subsection:: MIDIFunc and MIDIdef
  32
  33 For most uses, the preferred way to receive MIDI input is using the link::Classes/MIDIFunc:: and link::Classes/MIDIdef:: classes. The advantage of this approach is that any number of responders can be registered, using extremely flexible matching. (By contrast, using link::Classes/MIDIIn:: responder functions directly means that only one function can exist per incoming message type. That is not an ideal programming practice.)
  34
  35 link::Classes/MIDIFunc:: has a number of convenience methods allowing you to register for the different MIDI message types. It can  filter incoming MIDI messages to respond to a particular device, channel number, or specific message number, or ranges thereof.
  36
  37 See link::#playing_notes_on_your_midi_keyboard#Playing notes on your MIDI keyboard:: below for a simple example using the note-on and note-off MIDIFuncs.
  38
  39 subsection:: MIDIIn
  40
  41 MIDIIn has a number of class variables holding functions to be evaluated when a MIDI event comes in. Technical details on each function can be found in the link::Classes/MIDIIn:: help file.
  42
  43 list::
  44 ## noteOn
  45 ## noteOff
  46 ## control
  47 ## bend
  48 ## touch
  49 ## polyTouch
  50 ## program
  51 ## sysex
  52 ## sysrt
  53 ## smpte
  54 ::
  55
  56 To assign a response to a particular kind of MIDI message, assign a function to the class variable:
  57
  58 code::
  59 MIDIIn.connect;
  60 MIDIIn.noteOn = { |port, chan, note, vel| [port, chan, note, vel].postln };
  61 MIDIIn.noteOn = nil;    // stop responding
  62 ::
  63
  64 MIDIIn provides the responding functions with all the information coming in from CoreMIDI:
  65
  66 definitionList::
  67 ## source (src)
  68 || corresponds to the uid of the link::Classes/MIDIEndPoint:: from which the message is coming.
  69 ## channel (chan)
  70 || integer 0-15 representing the channel bits of the MIDI status byte.
  71 ::
  72
  73 ... with subsequent arguments representing the data bytes. The link::Classes/MIDIIn:: help file details all the supported messages along with the arguments of the responding function for the message.
  74
  75 Because these are class variables, you can have only one function assigned at one time. A common usage is to assign a function that looks up responses in a collection. For example, you could have a separate set of response functions for each channel.
  76
  77 code::
  78 ~noteOn = Array.fill(16, IdentityDictionary.new);
  79 MIDIIn.noteOn = { |port, chan, num, vel| ~noteOn[chan].do(_.value(port, chan, num, vel)) };
  80
  81         // this function will respond only on channel 0
  82 ~noteOn[0].put(\postNoteOn, { |port, chan, num, vel| [port, chan, note, vel].postln });
  83 ~noteOn[0].removeAt(\postNoteOn);       // stop responding
  84 ::
  85
  86 The advantage of this approach over using "if" or "case" statements in the response function is that you can add and remove responses without having to change the MIDIIn function. The MIDIIn function can serve as a "hook" into another structure that distributes the MIDI events to the real responders.
  87
  88 section::Playing notes on your MIDI keyboard
  89
  90 The technical problem is that every note on needs to save its synth object so that the note off message can end the right server-side node.
  91
  92 code::
  93 s.boot;
  94
  95 (
  96 var notes, on, off;
  97
  98 //MIDIIn.connect;
  99
 100 notes = Array.newClear(128);    // array has one slot per possible MIDI note
 101
 102 on = MIDIFunc.noteOn({ |veloc, num, chan, src|
 103         notes[num] = Synth(\default, [\freq, num.midicps,
 104                 \amp, veloc * 0.00315]);
 105 });
 106
 107 off = MIDIFunc.noteOff({ |veloc, num, chan, src|
 108         notes[num].release;
 109 });
 110
 111 q = { on.free; off.free; };
 112 )
 113
 114 // when done:
 115 q.value;
 116 ::
 117
 118 The link::Classes/MIDIIn:: help file contains a more elaborate example.
 119
 120 SuperCollider does not have a built-in class to handle this automatically. However, emphasis::dewdrop_lib::, a third party library mentioned link::#third_party_libraries#below::, includes Voicer (to simplify note on-off bookkeeping) and VoicerMIDISocket (to trigger Voicer notes by MIDI). Users interested in this functionality may wish to examine that library.
 121
 122 section::Sending MIDI out
 123
 124 See the link::Classes/MIDIOut:: helpfile. Unlike MIDIIn, with MIDIOut you create an instance of the MIDIOut class with a port and uid. You can have multiple MIDIOut objects to send MIDI to different physical devices.
 125
 126 Many users have reported timing issues with MIDIOut. When the CPU is busy, especially during graphics updates, outgoing MIDI messages may be delayed. Use with caution in a performance situation.
 127
 128 section::MIDI synchronization
 129
 130 MIDI synchronization may be performed using MIDIIn's sysrt or smpte response functions. It's up to the user to implement the desired kind of synchronization.
 131
 132 For sysrt, external MIDI clocks output 24 pulses per quarter note. The responder should count the incoming pulses and multiply the rhythmic value into 24 to determine how many pulses to wait:
 133
 134 table::
 135 ## 0.25 || wait 6 pulses (16th note)
 136 ## 0.5 || wait 12 pulses (8th note)
 137 ## 2 || wait 48 pulses (half note)
 138 ::
 139
 140 dewdrop_lib (third party library) includes a class, MIDISyncClock, that receives MIDI clock messages and allows events to be scheduled to keep time with an external MIDI device. See the MIDISyncClock helpfile for details.
 141
 142 There are significant limitations, discussed in the helpfile. This is not really a fully supported class, but it's there for users who need rudimentary MIDI sync functionality.
 143
 144 section::Third party libraries
 145
 146 emphasis::dewdrop_lib:: is a third party library providing a number of useful performance features, available through the link::Classes/Quarks:: interface. The library provides a user-extensible framework of MIDI responder classes designed for multiport, multichannel applications.
 147
 148 Among its features:
 149
 150 - user-extensible: simple functions may be used, and frequently-needed responses can be written into classes that inherit from the framework (see BasicMIDISocket and BasicMIDIControl helpfiles)
 151
 152 - easy to use classes for playing MIDI notes and assigning MIDI controllers to synthesis parameters
 153
 154 - a user-configurable array of MIDI controller numbers, to simplify assignment of events to hardware controllers