#1

I’m having trouble finding an answer via searching…

so monome grid 128 would seem a perfect match for MIDI CCs (of which there are 128). Send a MIDI CC to change the brightness of a button. Grid could send a CC to indicate a button has been pressed. Or a note on/off message (128 of those as well).

This would mean:

  • compatibility with iPads
  • plug-and-play support in hosts
  • no need for developers to integrate 3rd party code to talk to the device
4 Likes
Your iOS arsenal
Just got my Grid64, some questions
#2

@tehn would be the best person to answer that obviously, but the main reason i’d see is that OSC is infinitely more flexible than MIDI. I think Monome products in general are about total flexibility more than compatibility. There’s a lot of MIDI compatible grid controllers, but Monome is about more than that.

#3

What flexibility does OSC bring in this context?

#4

This chart will explain it better than I can.

3 Likes
#5

Please correct me if I’m wrong: every advantage on the left side column is of no use to a monome grid.

Atomic Update of Multiple Parameters: not needed for a 128 button thing.
Unlimited channels: don’t need it, just send/receive on channel 1.
Data formats: don’t need floating point, etc. (the grid isn’t pressure sensitive)
Message Structure: don’t need user defined messages. (I’m not sure that’s even an advantage as a protocol)
Clock-sync accuracy, theoretical limit: not needed.
Data Rate: not needed.

What am I missing?

1 Like
#6

I’m no expert but the fact that OSC isn’t bound to midi’s only having 128 steps for a value would be one thing that pops into my head.

#7

Monome grid doesn’t have knobs. 128 levels of illumination is plenty for a LED.

Please bear in mind: I’m not saying OSC is useless… it just doesn’t seem to give a monome grid any advantages over using MIDI. In fact, it hampers compatibility, and makes it harder for developers like me to support it on all platforms. Or impossible in the case of iOS, because good luck convincing Apple to support OSC.

#8

I think this question has been occasionally asked for 10+ years.

the grid doesn’t operate as a native OSC device, rather as a serial-over-USB device which is commonly translated to OSC. my understanding is that this decision was made in order to offer maximum flexibility. further, not many/any MIDI hosts would support bidirectional communication to provide decoupled visual feedback to the LEDs without customization anyway, in which case - why use MIDI? There isn’t an industry standard for bidirectional MIDI feedback, so in most cases you’d just have an awkward keyboard which doesn’t even light up. I do understand that “why use MIDI?” might have a different answer when it comes to iOS since it is such a controlled environment.

also, the grid’s predecessors (40h, etc), which are still largely compatible with current grids, predate iOS by a few years, so the possible requirements of a highly restricted OS which doesn’t easily allow user-built programs and which didn’t yet exist presumably weren’t a concern back then and likely aren’t a large concern now. all that said, my understanding is pretty rudimentary so there may be other reasons/better explanations from folks like @tehn.

4 Likes
#9

I think from your perspective “why” might be the wrong question to ask. I think it was just a strong choice that Monome have stuck by.

The grid used to come in sizes larger than 128, which starts to require multiple channels over MIDI, OSC seems like a better fit for the Arc (although who knows, clever MIDI programming obviously can get one pretty far).

But I think the main reason is conceptual, and thus probably unsatisfying: The Grid does nothing on its own; its function has to be defined by the program creator (and Monome encourages all of its users to learn how to create their own software). Some MIDI CCs have a default interpretation, so using them (a) could theoretically create unwanted interactions and (b) doesn’t present a blank slate.

11 Likes
#10

Why use MIDI? It’s dirt simple and supported all over the place. So if your controller maps to it well, then it makes a good protocol to use.

“awkward keyboard which doesn’t even light up” … MIDI is just a protocol. With something like a grid, it still takes a host which knows how to communicate with a grid. Why overcomplicate that?

#11

I suspect the question would be better posed as:
Why not make the monome products USB midi class compliant ?

For sure grids over 128 are slightly problematic, but frankly no more problematic than using a custom usb serial driver !

Also I don’t think backwards compatibility is a reason, things have to move forward - usb class compliance is pretty universal now.

1 Like
#12

just because MIDI has been adapted to do lots of things beyond what it was originally intended for doesn’t mean it is the best protocol to do those things.

in the early days of Monome, at least, I think there was a philosophical/hopeful push towards OSC becoming more widely accepted. even though that hasn’t really happened industry-wide, I believe there is/was a desire to use the same protocol for grid & arc, and MIDI is definitely not satisfactory for the resolution of arc.

1 Like
#13

What resolution does arc need? MIDI can do 16k via NRPN.

#14

Good suggestion… I changed the thread title :slight_smile:

#15

are you sure? what about using relative midi (like encoders)? or 14 bit midi?
again, they might not be as well support as 7 bit midi, but they are considerably easier for end-users than having to install drivers etc.

I’m not a midi fan particularly, I actually like OSC for the ML Soundplane, and am very familiar with the failing of midi for MPE, (esp hi res) given Ive coded for both device side (eigenharp) and sound generator side (axoloti).
but despite having my reservations, I think the ease of connectivity of usb class compliance midi devices (or midi generally) is undeniable… and that’s been true for quite some time now.

3 Likes
#16

if we’re talking about 14-bit MIDI, that’s certainly enough resolution. I don’t think that was being implemented at all when arc was first designed, so I was referring to 7-bit.

I’m not saying there aren’t logical arguments in favor of using a different protocol, but I think it is important to keep in mind how/when arc & grid (and their predecessors) were designed rather than thinking about it strictly from a present-day perspective. USB-MIDI could allow iOS use, sure, but would break all of the existing uses built over the past decade+.

#17

I don’t have the golden answer that will satisfy the midi question.

But… if we change the question to ‘why can’t I use my grid with iOS?’, then the answer is because iOS is a proprietary and closed platform. To me it seems that the frustration should be directed at iOS, not grid.

4 Likes
#18

it’s not really a question about the past… rather as a current product, why not move to it?
(a direction has been id say fairly clear for quite a while now)

not necessarily, since you have to have a driver on your host computer anyway, there is nothing stopping that driver also supporting the midi protocol, and then translating it to the existing protocol for backwards compatibility.

hmm, a mobile OS thats extremely popular for music software :wink:

besides its not just about iOS is it?
how many threads are there for support issue with serialosc, or asking about if it currently serialosc support is currently supported on the latest version of an OS?

the reason many manufactures have moved to USB class compliance (generally, not just midi) is it moves part of the burden to the OS developers.
the product developer just needs to concentrate on compliance to the standards, once thats done they dont have to worry too much about new OS versions etc.
this is also why end-users prefer it, since it means they dont need to worry if the product owner will update their drivers for new OS … which given the trend to OSs updating frequently this is a good thing.

Im not saying usb class compliancy has to be for everything e.g. the Eigenharp could not use it, you’d not get the throughput required, but the grid and arc have reasonably limited interfaces and data rates, so seem like good candidates.

4 Likes
#19

what about the various Euro host modules? why break those at this point?

#20

they have firmware that can be updated - no?
why can they not be updated to support a new protocol in addition to the existing one?
(also i suspect many of them already support midi, so they already have much of the code required - no?)

1 Like