Small But Digital
Contact

themidibus

themidibus

themidibus

themidibus is a Processing library which provides easy to use Midi support. It has simple, but powerful, input and output capabilities which can be used with raw Midi messages, NoteOn/NoteOff messages (channel, pitch, velocity), other standard Midi messages or even MidiMessage objects.

Abstract

The Midi protocol itself is very simple and straightforwards. Yet it often seems like it's also very limited (probably because it was designed in 1983). It has no arbitrary length values, no analog pitch control, limited number of channels, no passing of meta data, no human readable address space, etc. Unsurprisingly, over time, many tricks, hacks and workarounds have been thought up, but in general all theses seem to do is over complicate. Fundamentally, I believe that Midi is very simple and that it should stay that way. It does a great job of what it was designed for (no shit) and that's what we should use it for. If you really want other features and functionality there are now viable alternatives.

It's with this idea of sticking to the basics and by drawing inspiration from the amazing minimalism and simplicity of the Processing language that themidibus has been designed. Mirroring (or trying to) the beautiful, simple, elegant and fast nature of processing was the primary concern for this library. Therefor, unlike other Midi libraries which may offer more advanced functionality such as sequencers and note/song/track/controller objects, etc, themidibus tries to stick only to what you need and it tries to do so in a way that is as seamless and invisible as possible.

I want to briefly note, as do extensively in the javadocs that this library is based heavily on the javax.sound.midi package. So, if you're trying to do something more complex or if you're just curious, take a minute to check the "official" Java Midi package.

How it works

Disclaimer: This is a vaguely theoretical, poorly vulgarized explanation of how themidibus works/behaves, if you're trying to cut to the chase why don't you download the examples. and/or read the javadocs

The basic idea in themidibus is that each midiBus object represents an input (inbound) bus and an output (outbound) bus.

So first of all, what is a bus (check it out on Wikipedia)? Think of it in concrete physical terms. Suppose you want to send an audio signal (CD player) to many different places (5 pairs of headphones). This problem could easily, but not practically, be solved by simply by splicing together all the headphone cables into a single plug and plugging in. More practically you could build a very simple box which simulates this splicing: plug-in 5 sets of headphones and a CD player and the internal wiring splices it all together, everyone can listen in. This box would be a simple audio bus. Conversely, you could use the same box to plus 5 CD players into 1 pair of headphones if you wanted to listen to 5 songs at once. In fact, you could plug any combination of headphones and CD players (4 people with 2 songs, 3 people with 3 songs, etc). More generally, a bus indiscriminately and equally mixes all inbound signals and indiscriminately and equally sends this mix to all attached listening devices. Such a bus could be built for any type of analogue or digital signal: audio, electrical, ethernet, Midi, etc.

So each MidiBus object has two buses: an input (inbound) bus to which you, the user, connect your Midi input devices (external keyboards, sequencers, control surfaces, etc) and an output (outbound) bus to which you connect your Midi output devices (Soft/Hard Synths, Midi recording software, other Midi enabled applications or any other midi controlled devices/programs). Because these are buses, it's important to understand the all the Midi messages coming and going on the input and output buses of a single instance of MidiBus cannot be differentiated with respect to their source or destination. For example, say I connect 2 Midi keyboards to the input bus of a single MidiBus object, and suppose one plays F and the other plays C. There is no way for my single MidiBus object to know which keyboard sent which note. Or suppose I connect two synthesizers to a single MidiBus object and that the object sends the note F. There is no way to specify which synthesizer should play the F, both will play the note indiscriminately.

This doesn't mean you can't do theses things. It simply means that if you don't care about the source and destination of your messages (or if you only have one possible source and/or destination) you do not need to instantiate more than one MidiBus object. You want to do visuals using 72 Midi keyboards as live input, don't care who played what? Just one MidiBus object needed. On the other hand if you do care about source and destination, simply instantiate more MidiBus objects. Each MidiBus instance can be uniquely identified and therefor you can tell where your Midi messages are coming from. You want to do visuals using a Midi keyboard and a Midi violin as input, each controlling different visual effects? Instantiate 2 MidiBus object and connect the keyboard to one and the violin to the other, now you can tell who sent what. Even better because each instance of MidiBus can have multiple input and output devices you can effectively group you inputs and outputs by attaching them to different MidiBus objects. You want to do visuals using 72 Midi keyboards and 72 Midi violins as input, with each group controlling different visual effects? Instantiate 2 MidiBus objects and connect the keyboards to one and the violins to the other, now you can differentiate the two groups.

References and Downloads