[sdiy] Re: Why MIDI?

[cheater]

On Thu, 08 Jul 2004 02:39:49 +0200 (CEST), Magnus Danielson <cfmd at bredband.net> wrote:



> 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.
>

That's kinda like comparing a Talon to a kids' rover.
Sure, it's an argument, but not a very valid one in perspective ;)

>
> Actually, sometimes I really wonder how much of advancement it has really been.
>
Times have changed - the interface hasn't. Sadly.

>
> Now, lower that flame-thrower or at least point it in another direction,
> please!
>
*ignites* ;)


> 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.

Exactly. Should we really have that?

>> 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... :/

I wish we could have digitized audio, digitized control voltages, control messages,
files, time sync, samples, service messages, all running through one cable.
It's a nice wish.



>
>> 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?

turning a midi knob = step step step step crack step


>> 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.

That's what I *did* mean. Maybe a bit too methaphorically ;)

> 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)
>

It requires you to have a computer.

And using that on a live gig would be awful.

Making a 20-meter USB cable?
Pre-installing a USB cable for later gig purposes?
I'm feeling nauseous again.


>> 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)

I think we should even go as far as putting CV and audio in the same bag.
Who knows, maybe someone will use it one day? Let's not get limited here. Or we could
end up with an equivalent of 127 knob settings.

> * Support for continous time signals

What do you mean by that?


> * Support for background signals/events (non-timing critical on the same
>   degree as "primary signals" of timing events and continous signals)

Yes - for e.g. sending samples to a rig while playing. You don't want swapping samples
to crap up your performance.

> * 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)

Again, same goodies bag as CV.

> * Support for bidirection signaling (MIDI is a hell in this respect)

I'd go for arbitrary topologies - so you can just hook anything up to anything
and it *just works*. Don't want to end up using hubs or any crap like that.

> * Support hot-swap integration of devices

Yes!

> * Support for auto-investigation of new devices

Yes!

> * Support for automagical appearance of new resources and their *full* control
>   to any controller in the system

Yes!

> * Be able to build arbitrary structured and sized networks

Yes!

> * Be simple to manage and understand

Plug&Play (pun intended :> )

>
> 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)
>

Maybe we could start some kind of bigger collaboration with that? ;)


> 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.
>

My thoughts - TDM. Crude, but simple pre-requested time division multiplexing,
where bandwidth would be pre-requested (like booking a flight), and could be changed
every (specified) n cycles.

> 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.
>

XML could give big companies a good place to start integrating all kinds of weird stuff
into one, big, *compatible* system.

> Cheers,
> Magnus
>
>