How to build your own preb99

The information provided here is deprecated; it applies to releases of the Monomodular suite prior to b99. New information will be provided in a different space about how to write your own patches with Monomods_b99, but the documentation provided with the Monomods_help m4l patch in the Monomodular package is much better than previous version, so it's best to start there)

The monomods abstract is the comunication center of every Monomodular patch. It is essentially a small framework of data transmitters and receivers that are able to communicate with the Monomodular host patches. It also includes a couple of utilities that cut down on the bandwidth required for interpatch communication by eliminating the transmission of redundant data from the client patch. I designed it to be a fairly all-purpose conduit for creating or elaborating one's own client patches without having to dig into the deep recesses of the Monomodular host patches in order to make progress.

In order to get started making a client patch for the Monomodular system, all you need to do is place the monomods_b94 abstract into your Max search path, create a new m4l patch, and create an object called [monomods_b94]. This should create an object which has three inlets and three outlets.

The first thing you will want to do is give your client a name. You do this by typing in an argument to the monomods abstract, for instance: [monomods_b94 my_client]. If you save the patch, exit m4l edit mode, and examine the client list in a Monomodular host, you should see an instance of "my_client" in your client list.

The three inlets and outlets allow communication with the host patch. The first inlet sets the status of Nomeout (i.e. whether the midi output of the patch is sent to an external bus via midiOut/lh_midiout/nomeout or directly to the output of the patch). You can change its status by sending it a 1 or a 0 for on/off.

The second inlet accepts grid data that will be displayed by the hardware connected through the host patch. It is filtered by a mechanism inside the abstract that prevents the patch from sending out redundant calls (i.e. if a button is already off and you send it another call to turn that button off, the abstract won't transmit the new call). The format for sending values is x_coordinate, y_coordinate, value. Example: sending the message (3 4 1) will light the button on the fifth row of the fourth column with whatever color corresponds to the value of 1. Sending (3 4 0) will turn off the same button. Sending (0 0 0) will turn off the upper left-most button on the grid.

The third inlet is for sending other messages to the host. This is useful for sending addtional controller information (for instance, if you want to send the Launchpad's top and side strips information, you would do so by sending a message like (key 0 2) to light up the first button on the side-strip with the color value of 2). I don't have a comprehensive list of commands for this yet, but stay tuned. The "key" prefix is most useful, as all of the controllers supported by a Monomodular host implement some sort of feedback feature for this data-set.

Outlets are similar: the first outlet is the output of MIDI data from the client plugin when Nomeout is turned off. This is a special case, since the MIDI data flowing from this outlet actually originates in the plugin that you create. For this reason, you must route the MIDI data from the processes in your plugin to a [s ---midiout] object, which in turn is received in the abstract and routed accordingly. This will be changed in the next abstract update, as (now that I'm writing about it) I realize that it would make more sense to mirror the output of MIDI data from the abstract at outlet 1 an input received at the same inlet. (If Nomeout is turned on, no MIDI data will arrive at this outlet. It is rerouted to two other sends inside the abstraction: one goes to an interpatch send which is receivable within a Nomeout plugin assigned to the same "Nomeout Channel" as the monomod client, and the other is sent to the ~vst object bound to an instance of "midiOut", which can be rerouted through IAC Bus or Bome's or whatever and received at the track input of Live...everytime I try to explain that, my head gets dizzy. Come on, Ableton).

Outlet two sends key presses from the host if the plugin is currently selected. The format is the same as for sending information to the host: x_coordinate, y_coordinate, value. In this case, however, the value will generally be 0 (button released) or 1 (button pressed).

Outlet three sends additional information from the host. Key status is one of the relative data types, in the same format as that sent to the host (e.g. (key 2 1), third key pressed, (key 1 0) second key released). Timing information is forwarded to this output, so if the "Swing" host is being utilitzed, its data will arrive at this port if the patch is one of the Swing's clients.

This is a very general explantion of the monomods_b94 abstract. There are lots of other things going on, particular to each patch. I revise it (as little as possible) ever time I run into a problem that isn't surmountable in the client's code. There have been several instances, however, where something obvious was missing, and I've had to add it. If you have an interest in coding your own patches, please don't hesitate to ask me about the particulars, as I'd like to see this code being used by someone besides me.

Enjoy :)