#41

On Linux, I think you just write to /dev/midi… could it be any easier?

#42

Since you’re asking me, yes. Edit: alsamidi kinda sucks to write for imho. Liblo is tres chill

#43

Not a Launchpad, but maybe this would work? It states it is already USB-MIDI, though doesn’t explicitly say “class compliant”.

1 Like
#44

Yeah - the Untztrament runs on an arduino so it’s a class compliant usb device. I think if something says USB-MIDI, then it’s gonna be class compliant.

1 Like
#45

You’d like to think so.

Depends when it was made. I have some older USB midi devices that still require drivers.

1 Like
#46

I’m hoping the forthcoming crow module helps in this space, but I may be totally wrong.

iOS to crow. crow to other modules via cv and i2c. grid and arc via ansible to crow via i2c. everybody happily chatting in 2 directions.

#47

I’m really surprised about the responses here…

I think many are ascribing the monome grid success to osc/serial protocol, when I think its unlikely this was/is an important part of its success
(its just a protocol, a technical interface, midi/osc wouldn’t have made any real different imho)

I think the unique thing for the monome grid was/is :
a) an undefined interface, no button markings, a blank canvas
b) not being mass market and also strongly associated with a product.
c) not being primarily defined as a playing surface
(ok, this is a bit of a and b, but this is why push/launchpad have larger/velocity sensitive pads - and these in turn have quite an impact on ‘use’)

combined these really influence why the Push/Launchpad don’t build up a communities for use outside of their primary market.

I happily use a Push2 beyond Live, I think its great - its is just as programmable as a monome - but honestly, I find few others embracing this side… perhaps its complacency, happiness with what it does already (with Live)

where as with Monome Grid its the norm, it needed the community, as this was how it built its ‘application’.

but, none of that is down to technical implementation, osc/midi/serial.
the monome could have used midi, and I doubt it would have changed anything much.

the monome grid still is unique I think due to its physical nature… small buttons, means smaller size and due to this, the 16x8 format which I think is better than 8x8 (for general use)

interestingly we are starting to see a few large grids emerging now, deluge, polyend… I personally hope this might break us out of the 4x4, 8x8 sets…

5 Likes
#48

@tayholliday

the technical “historical” treason is pretty straightforward as @alanza, @Dewb and @murray suggest: using a third-party chip to handle USB dicovery, endpoints and framing was a very good idea given the experimental nature of the project. (which was not initially conceived of as a product.) similarly, using a standard and transport-agnostic data format (OSC) over a bog-standard transport layer (serial port) was also a sensible decision. (again, iphone wasn’t released and we were a long way from iOS and third-party applications.) monome devices have included tilt sensors and other stuff with 10, 12-bit data over the years (your point re:that is not accurate.) MIDI really is a barrier to entry for DIY host devices, compared to raw serial… the list goes on.

as to the broader historical question i couldn’t agree more with @naxuu’s comment - MIDI is a poor fit, creatively and psychologically, for the de-coupled architecture. the whole point was to get away from the standard industry assumptions about how controllers work (push a button, make a note) and allow(/force) people to come up with their own. look: it worked.

to the question as it stands: i don’t think there is a strong technical reason not to consider a more flexible driver component that could be loaded with class-compliant MIDI firmware. (probably AVR8 running LUFA.) i’d very much worry about the fragmentation of the ecosystem at that point though, and of course it’s a significant investment for monome to change things at that level. (especially with the massive proliferation of actual commercial and DIY MIDI grid products that are now available.)

here are some questions for you, the ios developer:

that is a pretty serious issue. some host apps (audulus) will be able to send stuff back to the “midi grid”, most won’t.

monome devices are utterly minimal: they pass through touches and lights. there is no onboard logic to associate touches and lights. how do you deal with this when connected to a “standard” MIDI host?

two ideas: 1) see if there is a way to talk to a USB-CDC device on iOS, without requiring MFi. if that’s the case you can make an IAB service (audulus module?) and even configure stuff like LED feedback for apps that aren’t MIDI sequencers and/or aren’t set up to perform (vs consume) noteon/noteoff logic.

or 2) just build a small usb serial -> bluetooth MIDI converter. everyone is happy, including those of us who won’t touch iOS development with a 10f pole outside of office hours.

on a different note, i think you’re getting (mildly) defensive answers because of the (mildly) aggressive tone of some of your questions and comments. (“hell, the grid isn’t even pressure sensitive” - no shit?) and not everyone one here is an engineer - people are defending the platform they love.

26 Likes
#49

Another reason for monome success : metal and wood. I’m so done with cheap, throwaway, plastic krap. I want a long term, tactile relationship with an instrument of substance.

6 Likes
#50

MIDI is obsolete. Also…

:point_up_2: :point_up_2: :point_up_2: :point_up_2: :point_up_2:

I wrote a little python thing to map MIDI to OSC values so I could use an Akai APC-40 like a grid. Perhaps that’s a better route for you?

1 Like
#51

Apologies, I edited the the message. I’m actually personally don’t care about pressure sensitivity one bit!

(responding on Audulus account because of new user posting limit)

2 Likes
#52

no worries

excellent pun there

4 Likes
#53

I’m confused about what this means. I described above how a host app could send data back to a grid via MIDI CCs. There doesn’t need to be an industry standard. Hosts would need to be aware that the device connected on the USB port is a monome, and act accordingly. Can you explain further?

#54

i just meant that typically, an app can accept controller input without having to also produce output.

a monome grid wouldn’t really be able to act like a “typical” midi controller even if it used MIDI. it would need some onboard facility to map row/col to note numbers, and to light its leds. immediately, decisions ensue - are switches momentary or latched? what is the scale? &c. we add firmware to the grid to deal with these things. now it’s not a monome anymore, its a boutique Push. that’s fine but i gather that it’s not what brian wants to make.

in short, if monome grids were midi controllers today, user would still not be able to use them them with like a synth or groovebox app. result is Sad Users.

you’re right, i guess this is not really relevant to the developer perspective.

4 Likes
#55

No need to make that decision. A button sends a note (or CC). A LED responds to a CC. Simple :slight_smile:

No need to impose any scale or anything. That’s all up to the host. A host can re-map MIDI note numbers easily.

All you need is a little memory (128 bytes) on the device to store the illumination levels of the LEDs.

#56

yes, i absolutely understand that a host program can do these things. but i think that someone who buys a “plug and play” midi controller expects it to work with their MIDI softsynths, not just with audulus and PD.

other devices in this space (e.g. push) have onboard logic and configuration.

1 Like
#57

Would be fine not to advertise it as a plug-and-play midi controller :wink:

#58

i stand corrected.

nonetheless, my powers of prophecy allow me to see the bug reports now. (it doesn’t light up when i play the iMoog and it only does hella bass notes)

is this making any sense? the thing uses an open and accessible protocol b/c it is supposed to be open and accessible - not just to OS developers but all developers.

the feature set of OSC is actually way beside the point. i agree that the application doesn’t really need OSC.

apple doesn’t let iOS developers talk to raw serial ports. this is a problem with apple.

9 Likes
#59

actually push doesn’t… it merely sends note on/off, and the pads don’t light until ‘host application’ sends note ons to light it up. so in this sense identical to the suggestions here.
and given app developers are already familiar with this for launchpad/push its not really an issue…
(launchpad pro does but that’s because its marketed as standalone)

1 Like
#60

Man, I don’t know where to begin in the category of problems with apple. Gotta just roll with the punches.