I knocked up a new renderer for my shado sprite library:
http://www.loadbang.net/space/Software/net.loadbang.shado
and pushed it into MfL, with MIDI coming out of Live and to the Ohm64. It didn't do too badly on the animation test set:
http://www.vimeo.com/1224474 (that's the monome version; I've not videod the Ohm yet)
but there were definitely timing issues and audio dropouts (even with the vector size pushed up to 1024).
Accordingly, I think there's a need for sysex support in MfL. (Assuming, of course, that people want to create animation displays on an Ohm64. Assuming, also, that Live's sysex support is solid. I've had numerous pieces of hardware that get it wrong, and in today's world of soft synths and VST preset storage, I don't know how much of a priority sysex is any more.)
MIDI Performance
That's pretty cool. Sysex is probably the way to go. Depending on how fast the OHM can accept Sysex. This way you can set multiple leds at once. Have you tried Sysex from a plain Max patch instead of M4L? This is from the manual, which you have undoubtably looked at.
04 : Set all LED indicators
--------------------
F0 00 01 61 02 04 LL HH LL HH LL HH LL HH LL HH LL HH F7
All (75) LED indicators can be set on or off with this command. There are (12) bytes, or 6 pairs of LL HH.
Values must be 7F or less. The first LL HH pair represents column 1, with each subsequent LL HH pair
representing the next column. Within each pair, LL represents the first 7 rows, and HH represents the
remaining 6 rows. There are (14) bits total for rows, but bit (11) is unavailable and reserved for future
use. A 1 bit turns the LED off, a 0 bit turns it on.
The LED columns and rows do not conveniently match up with the physical layout of the Button columns
and rows. Using codes as C.R to specify column and row, the LED codes are as follows (all codes are
decimal in this table, and all columns and rows are numbered starting at 1 - the first line is the first Button
column from first to last row, etc.):
64 grid:
1.1, 3.2, 5.3, 1.5, 3.6, 5.7, 1.9, 3.10,
2.1, 4.2, 6.3, 2.5, 4.6, 6.7, 2.9, 4.10,
3.1, 5.2, 1.4, 3.5, 5.6, 1.8, 3.9, 5.10,
4.1, 6.2, 2.4, 4.5, 6.6, 2.8, 4.9, 6.10,
5.1, 1.3, 3.4, 5.5, 1.7, 3.8, 5.9, 1.12,
6.1, 2.3, 4.4, 6.5, 2.7, 4.8, 6.9, 2.12,
1.2, 3.3, 5.4, 1.6, 3.7, 5.8, 1.10, 3.12,
2.2, 4.3, 6.4, 2.6, 4.7, 6.8, 2.10, 4.12
Mike
I've not boiled it down to the simplest Max patch, but I did build a Max for Live system with my existing monome renderer (which outputs OSC a row at a time directly from Java) plus Livid's monome-to-Ohm translator, which reads OSC and outputs sysex, in the same Max session, so there's a loopback OSC connection.
Performance was certainly better than Max for Live into MIDI CCs through Live, but still with some dropouts and not as snappy as running OSC into MonomeSerial and USB serial communication to the hardware.
So, perhaps performance issues with CoreMIDI (which is reasonable given that MIDI was never designed as a high-speed pixel animation protocol!). Also, I don't actually know the transfer speed of class-compliant MIDI-over-USB: hopefully, faster than "real" MIDI.