[sdiy] Re: Why MIDI?

[Magnus Danielson]

From: cheater <cheater at salsa.pl>
Subject: Re: Why MIDI? (was Re: Why DIY? (was Re: [sdiy] Another new hard to find part....))
Date: Thu, 08 Jul 2004 01:28:04 +0200
Message-ID: <opsasjg2kcwklk6x at mx.salsa.pl>

> My broken one and a half pence:
> 
> I'm a newcomer to the synth world, and one thing I always pretty much hated was:
> 
> *MIDI*
> 
> It's the most awful, crude, proprietary, stupid, unimaginative, handicapped,
> etc standard that I've ever seen.

Beutiful is not the word I normally associate with MIDI, but don't stretch
yourself too much, MIDI is realtively workable considering some utter darkness
which has been used in products and others places.

> It's a relict of the past, and was made in the times and possibilities of
> computers the kind of Atari and Spectrum. We're a bit above that now, aren't
> we?

Actually, sometimes I really wonder how much of advancement it has really been.

> (Disclaimer: anyone firing off with nostalgic paranoia towards old computers
> may be flamed. YMMV.)

Now, lower that flame-thrower or at least point it in another direction,
please!

> And it all was pretty much *forced* into a world of musicians. Where
> musicians should be all of the above, negated.
> 
> Midi requires you to be, pretty much, a programmer to understand it. Sure,
> I'm in Mensa, but I don't think I can be f?cked with understanding just
> another piece of trash information that's required to play a keyboard
> (d'oh!). Midi specification sheets anyone? *puke*

First of all, it takes a specific way of thinking to _decode_ the MIDI
specification. If you don't have that thinking, it will bite you in your chair-
interface multiple times. And then it will bite you some more later on, just so
I've said it.

> Or, take a comparison between an "analog" knob and an "encoder midi knob":
> continuous versus 127 discrete settings? *puke*

This whole 7-bit system over a 8-bit transmission path is really a hell, since
the 8th bit isn't very well used, there is better solutions and it is needed
anyway.

> How about velocity? 127 settings? *puke*

I think I need to clean up my email box about here...

> Or let's take on non-standard scales. *puke*

Oups, now it happend again.

> How about taking a softsynth (like the tasty Arturia Moog Modular) and making
> a patch between that and another softsynth (like Rebirth). Can you do that
> with analog? Yes. With software? *puke*

Shruder!

> How about running 100000 cables from a single keyboard to something else:
> take a Kurzweil 2xxx - s/pdif connector cables, input cables, midi, usb,
> ethernet (no idea if in Kurzweil, but some do have that), then come time sync
> cables, ADAT, etc, etc, etc, etc, etc, *puke*, etc, etc. Again, *puke*

Timing has not the thing people understand... "a few lines of code" will solve
it as allways... :/

> How about non-standard patch memories? Everyone has a kink of their own. And
> managing that is just a big pain in the ass. Come to think of a sound which
> you stored and forgot what synth it was created on - *puke*
> 
> MIDI timing issues? *puke*
> 
> Sending samples down through Midi? *puke*
> 
> Interfacing synths with eachother at all? *puke*
> 
> Midi2CV converters? What the hell is that crap supposed to be? *puke*

Beats me... I can view several interpretations as correct but then, I am not
sure which was intended... :/

How about CV2MIDI? How is THAT intended to work... really? What if one makes
blips, bloops and filifloops?

>   |
>   |
>   |
>  \ /
>   V
> 
> All in all, I think it's easily visible what I'm pointing at.
> If we want the usability of digital to even remotely compete with the
> ergonomics of the analog (note, I'm talking about *ERGONOMICS*, *EASE OF
> USE*, not "hey that prophet vst JUST DOESN'T SOUND RIGHT, aww")
> 
> WE NEED A NEW CABLE.

Not only a cable, we bloody well need a system which is expandable between
different medias and speeds. Look at MIDI, effectively it is still only
available in one contact, one speed and nothing has really improved in timing
either. OK, now MIDI over USB is appearing, but it is too little too late and
still has a number of things to address so it can be bundled on the same
sinking ship, OK? ;O)

> Remember, kids: Midi = *puke*
> 
> 
> So maybe we could talk about the possibilities of this, hm? :o)

OK.

What is required is:

* Timing transparancy (there is some technicalities to discuss here)
* Open structure to embedd new non-standard signals (compare note on/off with
  unscaled pitch signal to that of a continous CV signal)
* High resolution timing events
* Support for multiple timescales at the same time
* Support for continous time signals
* Support for background signals/events (non-timing critical on the same
  degree as "primary signals" of timing events and continous signals)
* Support for multiple samplerates of continous signals (think 8k, 16k, 32k,
  44.1k, 48k, 88.2k, 96k, 176.4k and 192kHz to see what I mean, but other
  rates can and should go in there... for control signals for instance)
* Support for centralized fundamental timing
* Support for bidirection signaling (MIDI is a hell in this respect)
* Support hot-swap integration of devices
* Support for auto-investigation of new devices
* Support for automagical appearance of new resources and their *full* control
  to any controller in the system
* Be able to build arbitrary structured and sized networks
* Be simple to manage and understand

I could say a few more words of truth on almost any of these requirements.
I know how I would do it for most part. Oh, if one only had the time. Well, I
do have the time... slowly... ;O)

I think that a purely asynchronous system is unsuitable and most of those
systems are serious crap and just too much rought edges and incompatibilities
to make a usefull system. I think it needs a truly synchronous core (and not a
plesiochronous core!) and then within this system some signals is either
synchronous or isochronous but asynchronous to the synchronous core. Then, some
signals which is anisochronous can go in full asynchronous mode. The later must
however be divided into groups and not be handled as a flat asynchronous domain
or the mess will be just terrible. Such a system is possible and will work
well. Infact, it excists and works well, but not currently for this
application.

The transport infrastructure for such a system is already in place in its
fundamentals, and basically only a number of signal-specific mappings is
required. Then there is a number of details relating to the more parameter and
signal passing parts which needs attention. It takes some banging of heads to
make all the details work out, but it should be possible to do in a suitable
manner. Some mixture of what is good with SNMP and what is good with XML based
formats should be possible.

Cheers,
Magnus