A Note About Live Coding in IRB with OSX

Apparently some versions of readline for OSX cause IRB to block thread-passing while it's waiting for user input at the prompt.

If you're experiencing problems live coding in IRB, such as starting the Diamond arpeggiator and nothing happening, it could be because of this. Unfortunately, as far as I know, the only way to fix it is to disable readline. You can do this by adding this line to ~/.irbrc

IRB.conf[:USE_READLINE] = false

This is annoying, because then you'll no longer have the ability to recall previously used commands and things like that. I've been meaning to get text editor based live coding up and running so maybe this is the time

More MicroMIDI Tricks

MicroMIDI has a few less obvious features that may be useful once you have the basics down.

Sans block

In addition to how I worked in the other examples, MicroMIDI can be used outside of the context of a Ruby block. This allows you to integrate it as a more conventional Ruby library.

Here is the first example from this post redone without a block

@o = UniMIDI::Output.use(:first)

midi = MIDI::IO.new(@o)

midi.note("C")
midi.off 

midi.cc(5, 120)

midi.play("C3", 0.5)

Note that you can also re-open the IO object in a block later using the edit method

midi.edit do 
  play "G3", 1
end

Performance Shortcuts

There are also performance shortcuts that generate messages based on past messages or common conventions.

• off - this generates a note-off message based on the last note-on message created
• quiet! - sends note-off messages to all MIDI channels on all outputs
• repeat - generates a copy of the last message created

Super Sticky Mode

Again in this post, I explained how MicroMIDI uses sticky values. There is also a super sticky mode that allows you to change the values inline with each message you create. Here's an example:

MIDI.using(@o) do

  super_sticky

  channel 1

  note "C4"
  off

  octave 5
  velocity 60

  note "E", :channel => 2
  off

  note "C3"
  off

end

When this program is run, these messages are sent to @o:

* note C4 (channel 1, vel 100)
* note-off C4 (channel 1, vel 100)
* note E5 (channel 2, vel 60)
* note-off E5 (channel 2, vel 60)
* note C3 (channel 2, vel 60)
* note-off C3 (channel 2, vel 60)

As you can see, when I sent :channel => 2 to the second note command, the MIDI channel remained for the commands that followed rather than just being transient for that command.

Message Cache

MicroMIDI keeps a timestamped log of the messages you create. You can access this log using the cache command, like this:

M do
  note "C4"
  cc 5, 120
  play "C2", 3
  
  puts cache
end

This code gives you this output:

{ :message=>#<MIDIMessage::NoteOn:0x007fbb6092baf8 
    @const=#<MIDIMessage::Constant:0x007fbb60930eb8 @key="C4", @value=60>, 
    @status=[9, 0], 
    @data=[60, 100], 
    @channel=0, 
    @note=60, 
    @velocity=100, 
    @name="C4", 
    @verbose_name="Note On: C4">, 
  :timestamp=>2.513885498046875 
}

{ :message=>#<MIDIMessage::ControlChange:0x007fbb60924e10 
    @const=#<MIDIMessage::Constant:0x007fbb6093df00 @key="Portamento Time", @value=5>, 
    @status=[11, 0], 
    @data=[5, 120], 
    @channel=0, @index=5, 
    @value=120, 
    @name="Portamento Time", 
    @verbose_name="Control Change: Portamento Time">, 
  :timestamp=>2.7201175689697266 }

{ :message=>#<MIDIMessage::NoteOn:0x007fbb60921558 
    @const=#<MIDIMessage::Constant:0x007fbb60931f48 @key="C2", @value=36>, 
    @status=[9, 0], 
    @data=[36, 100], 
    @channel=0, 
    @note=36, 
    @velocity=100, 
    @name="C2", 
    @verbose_name="Note On: C2">, 
  :timestamp=>2.961874008178711 
}

{ :message=>#<MIDIMessage::NoteOff:0x007fbb60917c38 
    @const=#<MIDIMessage::Constant:0x007fbb60931f48 @key="C2", @value=36>, 
    @status=[8, 0], 
    @data=[36, 100], 
    @channel=0, 
    @note=36, 
    @velocity=100, 
    @name="C2", 
    @verbose_name="Note Off: C2">, 
  :timestamp=>3003.7591457366943 
}

http://github.com/arirusso/micromidi

Generating Sysex Messages with MicroMIDI

Recently, the idea of converting MIDI Control Change messages to Sysex on the fly has come up a couple of times. One could use this to control a synth such as a Roland MKS or Yamaha DX7 that only accepts Sysex for control with a regular MIDI knob controller.

The following is a simplified example of doing this with MicroMIDI.

@i = UniMIDI::Input.use(:first)
@o = UniMIDI::Output.use(:first)
  
MIDI.using(@i, @o) do
  
  node :roland, :model_id => 0x42, :device_id => 0x10
  
  *@my_map =
    [0x40, 0x7F, 0x00],   
    [0x41, 0x7F, 0x00],
    [0x42, 0x7F, 0x00]
  
  receive :cc do |message|
      
    command @my_map[message.index - 1], message.value
      
  end
  
  join
  
end

Defining a Node

I won't get into too much background on Sysex but there are two concepts that one must understand in order to generate Sysex with MicroMIDI.

The first concept is what I call a Sysex Node: there are up to three bytes of data used in each Sysex message to identify the synth/module/destination/node/etc where the message is intended to be sent. This is not unlike the MIDI channel in a regular short message except that it's three bytes. Two of those bytes pinpoint the make and model of the synth while the third byte identifies the individual synth (device ID) in case you have multiple Yamaha DX7's or whatever the case.

MicroMIDI allows you to define these bytes as a sticky value using the node function.

Since I'm only using one synth for the entire example, I call the node function before setting up the input event to catch Control Change messages. (If you are using multiple synths and multiple events you would call node in each event block). The arguments represent the Manufacturer ID and the optional Model ID and Device ID. The Manufacturer can be referred to by a symbol (as above) or a string if its name is found in the manufacturer constants in midi.yml (by all means, add yours and do a pull request).

Now here's the annoying part: different brands and synth models use this Node data differently. For instance, I believe some devices don't understand messages with a model ID in them. In those cases just leave out whatever needs to be omitted from your messages. As I learn more about this myself, perhaps I can have this function streamline accepting the proper data for major synth types.

Command vs Request

The other concept to understand is that Sysex messages can (in theory) either be a command or request. This is pretty simple, and if you are creating a controller program you'll deal mostly in commands. In the case of the example above, we send a command

command @my_map[message.index - 1], message.value

When using the command function, the first argument is the sysex address and the second is the value to assign. The value can either be a number, as in this case, or an array of bytes. When making a request, the first argument is also the address but the second argument is the size of the response (in bytes) that you expect to receive

request 0x43, 43

If all else fails...

Due to the fact that Sysex hasn't had a truly concrete spec, some devices will use messages that don't really adhere to the command/request format. In those cases, you can just use the generic sysex command like this

sysex 0x1, 0x2, 0x3, 0x4

With no node specified, this will give you a message composed of

F0 01 02 03 04 F7

In other words, sysex will create a message and not perform any validation or add a checksum to it. You can still use node with these message-- it will append those bytes immediately after the F0 start byte as it would with a command or request.

tldr, Sysex is tricky to to objectify

If you'd like to gain a deeper understanding of how sysex messages work, this is a good tutorial (if Roland-centric) and I often referred back to it while creating MicroMIDI and the libraries that support it.

http://github.com/arirusso/micromidi

Next: More MicroMIDI Tricks