#7

I find the controls themselves can map to arbitrary precision, depending on the control. However, MIDI mapping a control limits the increments of the MIDI map to the 7-bit MIDI values, skipping over the control’s possible points in between. My H9 controller, for instance, supports 10-bit values (self-limited from the potential 14-bit maximum) through the extended MIDI CC mechanism to control the H9 pedal with additional precision. This can be recorded as track automation and played back at that precision. Having higher resolution MIDI I/O, though, would allow for EXTERNAL control of Ableton (via MIDI, natch) with the greater precision directly. With M4L, unless you’re translating to (and from) MIDI somewhere, you have full resolution (e.g. arbitrary precision - matching the source or destination) at your disposal with respect to Live’s internal API.

1 Like
#8

thank you for this explanation! so something like an Arc and/or clever usage of M4L could get you full resolution after all, nice!

#9

Yes, I believe so. I’m not sure what resolution the ARC sends and how that might map out of OSC, but if that’s higher precision than 7 bit you should be entirely able to access that. You can take apart my patch at https://github.com/malacalypse/h9-remote if you want to see how I got around the Live MIDI mapping to do my own stuff, and there’s no reason you couldn’t use an OSC or other max library to do a similar thing without MIDI at all. Don’t forget that MIDI provides for 14-bit CCs and there’s always NRPN if you really need to get funky with it. Cumbersome? Sure, a little, but not impossible. There’s a reason it’s been around for so long!

I, for one, would be delighted to see the spec get some love, especially now that USB is such a common implementation on the physical side, but good old DIN MIDI still works just fine when used cleverly!

1 Like
#10

Every ten years, someone almost does this and it never goes anywhere. The proper solution as @ermina pointed out is OSC.

We just continue to create within the limitations of MIDI. Or we hack our way around a few of those limitations. It’s a great reminder that so much we take for granted developed contingently. As true for Western science and the scientific method, philosophy, and music in general as it is for MIDI :wink:

4 Likes
#11

yeah my brain is thinking specifically for a device that would map input to parameters in other devices

1 Like
#12

it sounds like if those parameters are exposed to Live’s automation, @equipoise’s setting would apply. this is entirely armchair thinking on my part though :sweat_smile:

#13

this is marketing, the MMA trying to prove they have a role to play…

they’ve been talking about Midi HD for years - rarely does adding more members to a standards committee help speed things up :wink:

I think probably the biggest reason for Ableton (etc) to join is to get hardware manufactures to adopt/take seriously MIDI-CI - this will allow for more seamless hybrid setups, and reduce the configuration complexity.
we can already see lots of companies trying to tackle this e.g. Novation (SLmk3) , NI (NKS) , Omnisphere (synth mapping)…

MPE - unfortunately, I think Ableton has a lot of work in its underlying architecture to deal with MPE (or anything which has 1 track <> 1 midi channel) , cannot see membership of the MMA is going to change that.

1 Like
#14

I see the membership as simply a statement of increased interest in the subject. I wouldn’t read too much into it other than that yes, MIDI is very much alive and these manufacturers likely want to have a forum where they can share interoperability ideas in common rather than having to do it one-on-one. I also expect Ableton’s interest being to integrate their Link protocol ideas into whatever future MIDI has. Which I hope they’re successful in. Link is rather genius.

1 Like
#15

I think OSC would see more adoption if it was actually easy to use and had some kind of standardization. You need to be a very technical user to make use of it effectively. Getting two devices to communicate is much more complicated and requires a lot more up front work than MIDI.
Check out something like: Reaktor and Monome
Versus a typical MIDI setup which is “connect the MIDI out to MIDI in, set both devices on the same channel”.

3 Likes
#16

The other issue is that implementation of OSC requires a lot more resources on the device. You need to parse and match strings, as opposed to the compact binary format of MIDI. There’s definitely a lot more devices out there now which have the power to do this, but there’s still a lot of things being made with low power inexpensive microcontrollers where adding OSC support would be prohibitive.

#17

This, to me, is by far the biggest reason - you need a UI to be able to configure an OSC controller (or an external editor) to send to the right endpoints, etc., and that’s a lot of work, whereas MIDI is a very limited set of human-scale numbers to match up and that’s about it. Its simplicity is its biggest asset. OSC needs a static, simplified MIDI-like default set of maps (and I’m not talking about MIDI-over-OSC) before it will become widely supported, IMO. And even then, the DIN standard of “just plug an in to an out and boom it works” doesn’t exist for OSC. So even the physical layer simplicity just isn’t there. I don’t see OSC as a real solution to the problem that MIDI solves - simple, minimally configured connections of controllers to noise makers. It may be too technical an analogy, but to me it’s much like CANbus or I2C really aren’t replacements for RS-422 or DMX or standard serial so much as alternatives aimed at specific use cases. Choose the one that best fits the 80% use cases and move on.

2 Likes
#18

Agreed. I’m working on building MIDI interfaces into acoustic instruments at the moment and often get asked “why not use OSC”, and even “why use MIDI, it’s boring, OSC is much more exciting”, but won’t do it due to both the technical complexity and complexity for the end user.

I’d be very happy to see careful, evolutionary, backwards-compatible development of the MIDI protocol. I’m pretty sure most of the problems people have with the current version could be solved by a combination of the new 2.5mm jack form factor, and e.g. a discovery ping using the current baud rate which, if successful, allows the connection between devices to be upgraded to one with a faster baud rate and higher resolution CC and note messages. Of course, I’m just spitballing, and the little experience I have with standards development only serves as a nagging head-voice telling me that there are probably many established usage patterns or edge cases which I’m not considering…

1 Like
#19

Yes, I could easily see a networkable MIDI much like a slimmed-down and standardized OSC able to encapsulate a lightly-upgraded version of the standard MIDI implementation with 100% compatible fallback. Physical standards could then be quite numerous, since the older stuff could work on DIN or 1/8" (3.5mm) and newer stuff could work on Ethernet or USB. Since the newer stuff could encapsulate the older protocol, converting would not be difficult - a translation device would only need to have a way to indicate which level it supports and any older MIDI busses could then be fairly trivially integrated into the higher level network.

#20

Network MIDI already exists. It’s how you can get your phone or tablet to talk to your computer over WiFi for example. I’ve it a fair bit with iPad apps. Ditto with MIDI over USB of course. My computer’s MIDI interface, an iConnectivity MIO also has an ethernet jack which allows me to connect it to any network, and then the DIN or USB MIDI devices it’s hosting can be accessible from anywhere else on that network, and vice versa.

#21

Yeah, I’m aware. I don’t mean that bastardization of the protocol, though. :wink: RTP-Midi and it’s variants have so many problems…

#22

Much of this could be done with another layer on top of OSC, one that mimics the functions of MIDI but with enhanced features. The question then becomes the extent to which this layer would be standardized. Maybe there are several nested standards. Or at least two: simple devices could support this basic functionality and just not respond to other OSC. More complex devices would respond to OSC in its full implementation.

Anyway, I see these proposals every 5-10 years, since the 1990’s, all the major players get involved and it never really goes anywhere.

I also think of getting beyond MIDI more generally, in terms of what it would take to get off the rigid time grid, and have some kind of variable or even interlocking event-based notion of musical time, and have this become expressible in a standard. And how to wrap this up so it’s intuitive for users. I’m fine with music “as is”, but am perpetually curious about these things. All this is already possible to some degree. But it’s not what is possible technically, it’s what kinds of uses occur most often, and standards do have an influence. The notion of musical time just seems very underdeveloped. Automatic tempo tracking is possible, so what do we do with it. How can we anchor events to other events; how do we make a malleable time base.

#23

MIDI has no time grid concept. It has the notion of “beat” in midi clock but technically speaking that can be varied widely even between actual “beats” and in fact the very lack of any timing data whatsoever with respect to note and control events is one of MIDIs two edged swords balancing total freeform nature with complete imprecision. Any update to MIDI would do well to actually incorporate precise timing into the format in a way that is suitable both for precise playback and competent real-time performance.

2 Likes
#24

Yep, I know. The issue is that we have to look at the standard in how it is actually used, in and through the use cases we’ve all kind of converged upon, rather than only the letter of the standard. The standard is one part of an entire ecosystem. Standards don’t determine the ecosystem, but they do have an effect. Standards and constraints can actually create freedoms, they open up a space where it’s possible to think of new applications and hence actually end up diversifying what people do. The question is what higher level constructs beyond precise timing, all optional of course, can help intervene and push things in new and interesting directions.

#25

I mean, HDTV is already obsolete. I have a 5K monitor at home.

1 Like
#26

never a truer word - I was on a standards committee. One memorable meeting we spent the whole time talking about one single word in the standard…

I think the comments about MIDI over OSC are true - MIDI - you can literally just shove a wire in both ends, the manufacturer shoved a chip on the board - it genuinely is plug and play. I’ve rarely had to wonder why two devices wired one to the other can’t “see” each other like I’ve had to endless times with networking…

Some concept of 'time" in Midi would be really nice though - the clock stuff is pretty basic

2 Likes