Skip to content
stretta edited this page Mar 21, 2013 · 3 revisions

BEAP has sprouted a new subsection of modules.

These new modules extend the philosophy of "appropriate functional-module granularity" to common MIDI and monome functions.

I lost count of the number of times I rewrote polygome. I had a really interesting multiple-instance version of polygome 2 running and I kept adding features to it. The synthesis capabilities could modulated by various inputs from the monome like tilt or the built in pattern sequencers or some LFOs chugging away, why not, and a fabulous matrix modulation system and a complex dictionary-based storage system. Virtual instrument hosting. Built-in effects. It was hopeless. It was needlessly complex. There was no 'right' combination of features.

Some arcs have buttons. Some don't. Maybe controlling the rate of an LFO is from the arc is really important to you, but for someone else, maybe that isn't the case.

So I broke the core idea of polygome out into a module that you can patch with other MIDI modules (or turn into a BEAP signal)

I did the same thing with plane. Plane actually is quite beautiful inside. Since Max 6 includes jitter, I could re-write plane and use a jitter matrix to store my data. The difference this makes in the max code is astonishing. To think of how I was twisting coll grotesquely. Anyway, the patch turns out to be really simple. The main issue really is how the LED data is rendered so I made a thing that takes lists of 1s and 0s and converts them to efficient led/map messages.

There are other quick obvious monome things, like the ability to turn arc into a control voltage, that sort of thing.

The MIDI processing collection is growing. It didn't really click for me until I realized I could just standardize on raw MIDI messages. Then I could treat MIDI patch cords the same as signal patch cords. Also, if I can divert some aletoric techniques back to MIDI, then I can reclaim some CPU power and pursue more complex ideas.