40 ms·
Details about MIDI 2.0
- vkaku 7y agoNot as fun to read, outside the music industry. Lack of consistent samples has been MIDI's major issues, and even in games these days, nobody uses it, sadly.
- dmoreno 7y agoIt does not make sense to use it in games. It would need a good synthesis engine plus samples which consumes much more CPU than reproducing a MP3. If in your game you go the synthesis mode (chiptunes and whatnot) MIDI is a comunication protocol between devices.. if you want to use it to communicate a game with its own synthesis engine it makes less sense. Buy you may want MIDI so you compose in a standard music composing program. It is used also in other areas that need automation, as lighting (DMX). But I agree it would be nice to have better examples.
- hedora 7y ago> It would need a good synthesis engine plus samples which consumes much more CPU than reproducing a MP3. My 386 could do a decent job running DOS trackers (software synths) years before mp3’s were feasible on PC hardware (there was not enough storage, bandwidth or compute for MP3’s). The Kosmic Free Music Foundation published a ton of music on one CD-ROM this way: https://archive.org/details/KOSMICD1.tar https://archive.org/details/KOSMICD1.tar
- vnorilo 7y agoMIDI is just a control protocol. You are thinking of General MIDI [1], which defined a vague set of sounds associated with a program number, that allowed playing a sequence on different engines with horribly mixed results as you said. MIDI 2.0 brings additional capabilities to device interconnection, and AFAIK has nothing to do with GM (which not many people care about anymore) 1: https://en.m.wikipedia.org/wiki/General_MIDI https://en.m.wikipedia.org/wiki/General_MIDI
- burfog 7y agoLack of consistent samples is far worse without General MIDI. You could get a flute switched with a snare drum.
- ThJ 7y agoThis is going to be hard to explain without outlining a whole recording setup, but basically, a lot of the time, in a given musician's studio, the program numbers are going to refer to different things depending on how he chose to configure the patches (presets) on his synthesisers. In some cases, patches aren't even used, such as when an old Minimoog is retrofitted with MIDI and the notion of "Flute" or "Piano" becomes meaningless. In other cases, the synthesiser is a sampler and the samples were programmed by the musician at custom program numbers. In the case of software instruments in a DAW, patches are usually chosen by the DAW itself and no program message is sent to the synth, just note on/off, modulation, pitch bend and other controller messages, and if a switch of instruments is needed during a song, you just add a new track for that. Basically, MIDI began as a protocol used between hardware devices. General MIDI is a product of the ROMpler era, a ROMpler being a sampler that can't be reprogrammed, i.e. what most people know as a "keyboard", and it's far from universal. Musicians often don't care about standardising. They're hooking up all sorts of wonky instruments to their rig and reconfiguring it for one-off projects. There is often no need to recall specific patches after you've recorded the part you wanted.
- deleted 7y ago[deleted]
- vnorilo 7y agoMIDI is like HTTP, while GM is like, maybe, the named CSS colors. edit: TCP -> HTTP.
- coldtea 7y agoLack of consistent samples is not an issue with professional use of MIDI. Professionals (musicians, engineers, etc) don't use MIDI as a general-purpose playback method, they use it to control their samplers, synths, external effects units etc. They don't need "consistent samples" because they provide their own samples, different for every song (plus pure synth sounds, etc).
- matchagaucho 7y agoMIDI actually allowed game designers to decouple samples from the events that triggered them.
- coldtea 7y ago>Lack of consistent samples MIDI has nothing to do with samples itself. >and even in games these days, nobody uses it, sadly. Most recorded music, soundtracks, and almost 100% of game music is been done with MIDI. MIDI doesn't amount to the .mid files that people used to download / play on some player on their PC and which sound tinny. It's a professional specification that's used in every single studio, and is the basis of every professional digital workstation for recording music and sequencing electronic instruments. What you're describing is like confusing the JVM with Java applets, as if that's its only use.
- dmoreno 7y agoAs I read it, in brief, it adds much more resolution, and a introspection protocol using bidirectional communication which allows property exchange and profiles. Both very welcome additions! Finally no stepping on CC and note velocity, and the DAW can really know about the synth / controller capabilities, as it knows already with VSTs. And keeps MIDI 1.0 compatibility.
- mathnmusic 7y agoI feel MIDI is severely underutilized outside music. It's a simple, standard protocol that relays switches being turned on/off, and knobs being turned high or low. The only standard alternative that I know about is would be USB HID interface which has its limitations. What are some cool uses of MIDI you have seen outside music-making?
- iforgotpassword 7y agoMidi maze? :) https://en.wikipedia.org/wiki/MIDI_Maze https://en.wikipedia.org/wiki/MIDI_Maze
- boomlinde 7y agoI haven't listened in on the data but it seems likely that MIDI Maze only uses the electrical standards, i.e. a proprietary protocol over MIDI ports
- iforgotpassword 7y agoIt's a midi port. It does midi. Hence the limit of 16 players. Every player is using a dedicated midi channel.
- boomlinde 7y agoI agree that it's a MIDI port. That's not under contest. Because every claim that it's MIDI I've seen has failed to substantiate it, I searched around a bit today and found the developer of MIDI-Maze II and contacted him. Only the physical layer of MIDI is used. He furthermore said that MIDI doesn't allow a ring network anyway, in which case this must also be true for the first MIDI-Maze. So no, the player limit has nothing to do with MIDI channels. Maybe be more clear about whether what you're saying is an unsubstantiated guess or something that you actually know. Your message reads a lot like you know it for a fact.
- iforgotpassword 7y ago
- yc-kraln 7y agoIs the connector still that only DIN+USB-Micro hybrid? It looks like it's expensive and fragile.
- matchagaucho 7y agoFor backwards compatibility, all MIDI 2.0 features will still work over 5 Pin DIN cable.
- makomk 7y agoAccording to the linked page, 5-pin DIN still only supports traditional MIDI 1.0 and there's no plan to change this currentlyt.
- TheOtherHobbes 7y agoThe old 5-pin DIN hardware doesn't have anything like the bandwidth needed for MIDI 2.0. In fact it can struggle with MIDI 1.0.
- elihu 7y ago...which means that almost everyone using midi 2.0 between multiple devices will be doing it over USB, which is a shame because very few hardware synthesizers or controllers can act as a USB host. That's fine if you're connecting everything to a computer, but it's kind of a step backwards from what MIDI used to be, which was an easy way to connect almost any keyboard to almost any synthesizer made in the last three and a half decades or so. I've wondered if CAN bus would be a good modern-ish alternative to DIN-5 and USB, but I don't know enough about it to say if it has some limitation that's not immediately apparent but which would become a problem. (On the plus side, it's much faster than plain DIN-5 midi, allows longer wires than USB, and it seems to be supported natively on a lot of cheap microcontrollers.)
- brokenmachine 7y agoI reckon CAN would be a great alternative. It has inbuilt support for message prioritization, so important stuff like timing sync messages could have higher priority. Also it's differential so long cable runs are not a problem and it has good noise immunity. Oh, and it's a bus so virtually unlimited devices on the same bus, in any topology. Oh, and also I've always wanted to use my synths in the car! It would be nice if the protocol of the future was wireless and could support the actual audio as well though, but all that adds extra complexity of course.
- dmoreno 7y agoI for one expect that MIDI 2.0 helps to boost the RTP MIDI protocol adoption (over ethernet). It has much more speed, longer distances, less latency, proper packet loss recovery (which is not a problem on local networks) and overall much better hardware ecosystem. Even on WiFi it is useful although latency is very jittery. Disclaimer: I'm working on a RTP MIDI implementation for linux (https://github.com/davidmoreno/rtpmidid https://github.com/davidmoreno/rtpmidid)
- paranoidrobot 7y ago> Even on WiFi it is useful although latency is very jittery. Could you elaborate on why Wifi latency jitter would be an issue for MIDI? From an outsider's perspective and with only a vague knowledge of MIDI, it doesn't seem to be something that should be any more sensitive to latency jitter than other realtime applications like audio/video.
- salicideblock 7y agoIn broad terms, performing music is much more sensitive to latency than A/V playback is. Think of it like playback vs a phone call. If you have 0.5s gap between audio and video, you hardly notice. But the same latency in a phone call makes it very awkward. In music performance, the awkwardness would be multiplied by the number of spectators cringeing :)
- anonymfus 7y ago> If you have 0.5s gap between audio and video, you hardly notice. If your video comes later than audio and depicts human mouth talking you would notice it ever for 1 frame (0.02s for 50 frames/s) delay; but it's true that if audio is delayed relative to video, then 0.5s is hardly noticeable.
- xf00 7y agoThis is because in the real world audio always arrives late compared to images. Our brain is trained to compensate. Personally I start getting annoyed when the delay is above +200ms or under -50ms.
- yardie 7y agoWow. This took so long to happen that I assumed it had already happened, a decade ago. Early RFCs went out while I was in college.
- tsegratis 7y ago> 16bit note velocity For electronic drums I would of much prefered at least 24bit. Volume is by far and away a drum's most expressive dimension, so it will be limited by a 16bit velocity range. Adding velocity curves just masks the problem Though of course 16bit is orders of magintude better than the current 8bit range
- royjacobs 7y agoWhy wouldn't 65536 separate velocities not be enough, even for the most expressive drummer (or indeed for any other instrument)?
- coldtea 7y ago>For electronic drums I would of much prefered at least 24bit. Volume is by far and away a drum's most expressive dimension, so it will be limited by a 16bit velocity range. It wont be limited at all, real human players have no control as subtle as 256 levels, much less 65K levels... Nobody would even notice anything...
- edejong 7y agoNot my experience. The expressive control is exponential, so either you clip on either end of the velocity spectrum, or you get discrete steps at the lower end.
- coldtea 7y agoYou wouldn't be able to tell between a hit in velocity 1 or 2 or between 254 vs 255 is my point.
- edejong 7y agoIf the velocity is a^x, with a a number like 1.1 and v a number between 0 and 255, I would agree. However, what I’ve seen is that 2 is twice as loud as 1 and 256 twice as loud as 128. That means soft passages become discretized and uneven.
- tnolet 7y agoI once had a dream that every new synth, sampler or drum machine I brought into my studio would automatically recognize the local MIDI network, joined it and would pop up as a new device in my Cubase sequencer. All wireless of course. Like Bluetooth but actually working. A man can dream. PS: it would also stream multitrack audio over ASIO wireless and expose its inputs and outputs.
- okket 7y agoAlso: - perfectly synchronised - zero latency This may be hard to realise with lots of devices and wireless connections.
- tnolet 7y agoYes! Also, my dream included vintage synths with just cv controls that would just connect to some dongle/wireless CV converter and boom, integrated. The dongle converted perfectly between all the various Yamaha, Roland and Moog standards.
- hnarn 7y ago> This may be hard to realise with lots of devices and wireless connections. Assuming that the latency of the wireless connections is at least relatively predictable, you could just introduce a suitable delay like with NTP time syncing, right? Of course, it's possible that the latency will be wildly unpredictable and in that case it's pretty much impossible, but that doesn't have to be the case.
- barryfandango 7y agoIn the parent's case this latency includes time from a human key press (piano key). The other cases you mention can be compensated for but of course the human input is non-predictable.
- munificent 7y agoI think a lot of performing musicians actually prefer the reliability of a wired connection with no handshaking going on.
- thefounder 7y agoThe future of MIDI is AVB and/or AES67 with OSC
- stuntkite 7y agoYou seem to be the only person commenting that gets it. I think that might be because anyone who cares just skipped this press release. Even calling this MIDI 2.0 is a deception. We have MIDI, it's great. The tools that follow exist already and MIDI 2.0 doesn't appear to add any value. Whatever this hustle is, it can fuck right off in my book.
- kitotik 7y ago> Property Exchange uses JSON inside of the System Exclusive messages. For some reason this made me lol. The idea of cramming some JSON inside a SysEx seems crazy. Hopefully the timing is actually improved in 2.0. Once you are past “hello world” getting midi gear to sync up has always been a nightmare.
- VLM 7y agoOne of ESR's relatively recent rants about protocol design is optimizing the right thing vs scaling a protocol for use over long time, so he's a big fan of using JSON in the next generation of NTP. One quote summarizes a couple thousand words "We should be designing to minimize the cost of human attention." http://esr.ibiblio.org/?p=8254 http://esr.ibiblio.org/?p=8254 when you can run all the world's stratum 1 traffic on a raspberry pi, you shouldn't be optimizing for bw and speed, but for bug-free-ness and security and ease of use. Likewise back when a minimal computer system was a multicard S100 Z80 system minimal midi made sense, but now a days it should be like adhoc wifi with a REST API or something similar.
- Ericson2314 7y agoText is not how we optimize for correctness. I can already see my cheap synth failing on scientific notation oddities, BOM, and other JSON gotchas. Please read up on langsec.
- Uristqwerty 7y agoJSON exposes implementors to all sorts of recursion, numeric precision, etc., where the only advantage is that you can consume the data through whatever JSON library already exists (but also having to handle that library's unique quirks). When you look into it, while ESR says he's using JSON, he's really using a custom format that is readable by typical JSON libraries, but his format has very strict limitations, and his implementation is designed to error out early, rather than parsing an entire 10MB object tree before handing anything back to the application. He does not acknowledge this inconsistency in the article, only mentioning it late in the comment section. Extensibility is valuable, but does that mean the format should support '"position": {"x":5,"y":[7.2,"XXIV"],"font-face":"Comic Sans"}', where every single object can have arbitrarily-many unrelated fields inserted? HTTP is better, with a flat key-value list, but if you build on top of HTTP itself, you now do not know if any of the systems on the network or libraries used might respond strangely to some obscure old header. Personally, I think transmitting integers as text is at best rude, and somewhat comparable to Java allowing any reference to be null: Every client now has to handle an extra error condition on every parse. With binary integers, every bit pattern is valid, so you can perform a single range check to handle every type of bad input. Use 0x1234 as a magic number somewhere, and endianness errors are trivially debugged from a single sample packet.
- diydsp 7y agoThis bothers angers me: >To implement MIDI-CI and MIDI 2.0, you need a manufacturers SysEx ID. A SysEx ID by itself is $250 a year That would be a re-hash of the hobbyist USB VID/PID fiasco. MIDI synthesizers are one of the main non-activities which non-professional people have been doing. So many amateurs and educators whip up MIDI synthesizers in a few hours in a workshop or after work. And that is thanks to MIDI being a dirt-simple, unlicensed standard. >You will also have access to the MMA Github which has code for MIDI 2.0 to MIDI 1.0 translation (and vis versa)
- yrro 7y agoCan amateurs club together and form an organisation to administrate allocations from a common ID range? Or just liblically declare that they are going to squat on a particular range?
- dmoreno 7y agoI was just listening to the midi 2.0 webminar from the midi association, and as I understood there are some free sysex and ci id for non profits / hobbists, but if you make money out of it you should register. I guess mainly to prevent ID collisions.
- mrob 7y agoIt's pure money grabbing. They could just as well avoid collisions by specifying a UUID for the SysEx ID, and then everybody could generate their own independently.
- stevehiehn 7y agoI'm trying to understand the 'bi-directional' part. There used to be a idea of midi out & midi in. So does this mean you only need one cable connected now?
- ductionist 7y agoIt sounds that way - but they also say that connections over 5-pin DIN is/will be MIDI 1.0 only.
- habosa 7y agoI have just started to play around in the world of electronic music and have had my first real exposure to MIDI. I just want to say ... wow. Something like this is so rare. I have pieces of equipment from different decades that can talk to each other using a $2 cable and no computer in between. As a programmer I'm used to walled gardens and competing standards. MIDI is a breath of fresh air. I hope whatever 2.0 brings can keep this spirit alive.
- 781 7y agoThere is MIDI competition, more open and some say better, it just never caught on outside open-source/hacker/maker circles. https://en.wikipedia.org/wiki/Open_Sound_Control https://en.wikipedia.org/wiki/Open_Sound_Control
- seandougall 7y agoOSC is fantastic in many ways, but it makes for a pretty inefficient (and unnecessary) replacement for the primary use case of MIDI, which is note on/off messages. It’s much better suited to some of the other layers that got bolted on top of MIDI, such as MIDI Show Control. For most musical purposes, MIDI v1 is perfectly sufficient, well-documented, optimized, and open (from the standpoint of being free to implement). OSC absolutely has caught on in a lot of professional applications, just not the ones that MIDI was initially designed to serve. It’s huge in the world of theater, for example. (Background: I wrote the initial OSC implementation for QLab [a theatrical show control application].)
- unsatchmo 7y agoMy main beef with OSC is that there is no “there” there. It is hyper flexible at the cost of you needing to design your own meta-protocol. Like every single instrument that supports OSC has a different API with a mess of docs you need to read. Doesn’t really get me in the mood for making music. The DAW manufacturers had a very hard time creating user interfaces that studio engineers could use to configure OSC, and I think that was a main reason nobody ever used it as a synthesizer control protocol.
- elihu 7y agoMidi 2 adds some much-needed features (per-note pitch bend, for instance), but what I expect to happen is that the major manufacturers are going to only implement the parts they care about. I'd kind of like to see MIDI replaced outright with something built on a somewhat different (less piano-centric) abstraction; something more voice-oriented rather than note-oriented. Instead of having some number of fixed pitch notes that you turn on and off and settings that apply to all notes, you have voices that you can control independently (set volume, filter cutoff, control the envelope, disable and enable, and so on). You can do that now with the one-note-per-channel trick or MPE if it's supported, but it's kind of kludgy and only works with synths that are multitimbral to begin with.
- stuntkite 7y agoMIDI 2.0 looks like garbage and it barely features what Open Sound Control has been doing forever. I'm interested, but the demos here were made by people that don't make music and suck at hardware, software, blogging, and video presentation. Whatever this is, I'm hard pressed to care.