Could a PR be made for an additional class compliant midi mode? I’ve never actually looked for grid code, but my guess is it’s open source.

RME’s babyface pro implements something sort of similar, where it has its own custom drivers, but also a class compliant usb audio mode for usage with iPads, Linux, etc

You can install drivers on Windows/Mac, not on iOS. Apple has been clamping down more and more on 3rd party software even on Mac though, closing things off.

I totally get the practicality of it though, developers want things to be easier.

I was assuming, perhaps incorrectly, that there isn’t much room left for additional code on Ansible/trilogy modules. certainly could be wrong on that.

couldn’t someone just develop an intermediary device that translates serial-over-USB to class-compliant MIDI if that is a compelling concern?

is there a reason I am missing to use grid instead of something that already has iOS compatibility like a Launchpad?

1 Like

You could probably do this with a headless raspberry pi and pure data – might be a fun project!

you’d have to use a pizero, if you wanted it to act as a ‘dongle’ , for the usb device support.

but probably better would be a PocketBeagle, the gird would be attached to host port, then the beagle would act as a midi class compliant device (already supported by gadget framework) - so shouldn’t really be a difficult task at all… just hack serialosc to output midi.
(will even be bus powered :slight_smile: )

but people dont like dongles much.

i think the assumption here, is they want the grid for other purposes already.
also the monome grid still has some advantages eg. there aren’t 16x8 grids at its size (?)

2 Likes

from a simple user point of view, i am always unsure of what happens whenever i use MIDI, especially to communicate with/between software, because things have a default name that gets in the way, and i’m not a robot. Was my “texture density” control on channel 4 CC 6 or channel 6 CC 4 ? etc. whereas with OSC i get to define meaningful and self-explanatory names (addresses) that i have to explicitly define on the receiving end as well, and that builds trust that things will do what they are supposed to, and nothing more.
Not every product has to be the same. Also, why use iOS ? :slight_smile: (that’s somehow a real question. Systems are difficult enough to maintain through the years with open-source software, to add the burden of a proprietary OS and the unpredictable changes that unavoidably come with it on top of that. Especially when we are talking of an instrument-like / performing system.)

3 Likes

a fair point, and one that the midi association is trying to address with the new capabilities stuff.

but not really an issue for a grid, which can only have note on/off … I think thats well covered by midi :slight_smile:
(and the reverse using note velocity for led intensity is used by pretty much every other grid out there)

a bit off-topic but actually OSC has suffered because there is no standardisation of topics, funny enough was similar with Corba in the early 90’s - very open, but lacked consistency …
midi suffered the opposite, it defined uses for cc but they weren’t broad enough, 7 bit seemed like alot at the time …so starting getting used for other things, so we are now at a state where CC# have lost their meaning.

I suspect most musicians are reliant on close source software, as its a small minority using Linux.

but the point of adding class compliance is so you are NOT reliant on the operating system, you conform to the spec then it is the OS developers how deal with keeping it compatible. a USB midi class compliant device “just works” on windows/mac/iOS/linux …
so if monome used it for their products they would not be specifically support iOS nor any other OS, other than for testing their compliance.

and like midi din, due to its widespread adoption… its likely to require ‘legacy support’ for a very long time.

2 Likes

A lot of these answers/whatifs seem ahistorical in that they rely on developments long after 2006.

In 2006, DIN MIDI is too large for small devices. USB-MIDI existed but didn’t have the broad device support it enjoys today, and high-speed implementations were even rarer. MIDI is not an efficient protocol for sending large multibyte messages like grid quadrant updates. USB is a lot more complex/expensive to implement in hardware and 2006 didn’t have today’s range of cheap chips and decent open-source USB microcontroller stacks. FTDI serial was cheap and straightforward and showing up everywhere. The iPhone didn’t exist. The landscape for portable digital music-making devices was completely different. Max/MSP and Pd were the target development environments, and OSC was the common currency there.

14 Likes

I think the core issue is how does the midi device communicate back to the grid, to tell it which button to light up? I haven’t kept up with evolving MIDI standards, but I don’t think that’s possible without OSC, which would leave you with a pretty boring device IMO

1 Like

I thought the questions posed, were more ‘forward looking’, rather than after a retrospective of why.
whats done in the past usually is done for good reason, I certainly did not question it ,
but technology moves forward, particularly trying to make things easer for end users, and products are often updated to reflect this.

so question is… if monome do a 2019/2020 update, should it be usb midi class compliant?

perhaps the answer is no,
perhaps its too much development effort, that monome feel would be better spent on new products, so it just ‘priority’
(“too much” here means compared to the ‘reward’ e.g. existing users have not requested it much, would not bring many new customers)

thats not an issue… all other grids use note on with velocity to do exactly this.
some then have ‘extended’ apis to go beyond this and improve efficiency, e.g. to clear the entire grids without sending 128 note offs.

(to be clear here, Push/Launchpad all work over midi, for the pads/button… so not only can it be done, it has already been done :wink: )

Push/Launchpad are good examples of why OSC is still a decent choice, actually…

People have done things to extend the functionality and customize those two controllers to unusual ends, but neither philosophically and practically exist as instruments that creatively challenge their users to reckon with ‘designing interface’ on a higher level… neither inspire a community of active, collaborative developers in the same way Monome with OSC has… for that matter, a community that ended up with more non-technical, left-brained musicians being inspired to wade into programming and instrument/interface design and functionality than any other I can think of.

Thinking of OSC vs. MIDI for monome grids from a purely technical spec standpoint misses the point. It was a spectacular choice from a creative and inspirational perspective. It’s more of a summit than MIDI is, but that’s also it’s strength - summits tend to inspire people who are game to scale them.

11 Likes

I agree with @naxuu.

That being said, I longed for a class compliant pressure sensitive rgb 256 for a long time. I love my linnstrument.

(Ok, technically it’s only a “200”)

4 Likes

not to be overly semantic, but the original subject/question was literally: “Why isn’t monome grid a MIDI device?”, which is inherently asking for an explanation of the past/why things are the way they are.

1 Like

I may be wrong, but isn’t UBS class compliant MIDI limited by having to use the comparatively slow MIDI transmission speed (roughly 1 ms per complete three byte command)? If this was the case, changing the state of all 128 LED would require a total of 128 ms (worst case), with running status enabled it would still take around 86 ms.

I had the same thought just now - and I’ve got a possible solution.

I already have monome serial code working very well on a Teensy micro controller (the 3.6 has USB Host). Translating the monome i/o to USB MIdi would be very possible. :grin:

6 Likes

The monome euro-modules don’t fully support class compliant devices (yet). MIDI driver is there, HID I think (on some). But… a “CDC” driver needs to be written for class usb devices.

I’ve started work on a CDC driver, but I’m not much of a C coder so the going is slow. If anyone wants to help with that, please let me know! :slight_smile:

1 Like

Monome uses an FTDI chip and a trivial serial protocol.
This keeps the device open and is easily converted to whatever protocol you want it to speak with minimal effort. Converting from/to MIDI requires way more “3rd party code” than serial does.

1 Like

Even Arduino was using FTDI until the Uno in 2011 or 2012.

This seems like the biggest current and pragmatic reason to me… I can’t imagine backporting all of the existing software and firmware would be fun for anyone, nor would it be an obvious benefit to monome beyond iOS compatibility.

Unfortunately, this isn’t possible because of the FTDI chip.

Do you have an 8x16 Launchpad handy? Button-feel is also a good reason

I believe this was one of the early concerns, yes. The serial protocol also specifies row, col and frame messages to update multiple LEDs with less overhead; those could be implemented similarly via sysex, but then… you have to deal with sysex.

The new proposals that the MMA discussed at Roli’s Audio Developer Conference last month (https://www.youtube.com/watch?v=ytznu35MeiY) paint an interesting picture where 2.0-compatible devices could negotiate a higher-speed transport, but even that is still in development by the standards body, and not anything anyone’s actually built and shipped yet.

This seems like the most pragmatic approach to me – an existing grid would remain compatible with existing stuff, and you could use the dongle for midi things… It should be possible to build a simple translator dongle using a Teensy 3.6, as that has USB-host support… Then it’s just a matter of writing the firmware to do the translations and deciding on how a grid should MIDI…

2 Likes

Using MIDI requires no third party code on iOS and macOS at least. It’s all built into the OS (CoreMIDI).

1 Like

You’re leaving out a myriad number of embedded platforms including microcontrollers, SBC’s, SOC’s, and… uh. Linux. Also there’s the simple case of “what if I don’t need or want MIDI?” In my view the point of a binary serial protocol is being open and easy.

3 Likes