[sdiy] Re: Why MIDI?

[karl dalen]

Now you got me going!!
 
> 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.

Why would it be hell, skip the bit or nullify it! 
In MCS 8 bits are used all the time!

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

As Dave Smith once said: It will never happend!
And KD extends that to: there is many reasons to that! :-)
Reason 1: Anyone who tries to invent a new Midi protocoll
will fail misserably.
Why, because USB and Ethernet will replace or embed Midi within!
I know that there are hords of people trying to use and promote
cheap ETh10/100 cards and using a new protocoll as Midi.
Thats fine with me but somehow it simply dont happend to reach
the major public?! Wonder why! ;-)

Otherwise, Midi over usb are happening, have done so for a while
and will continue to do so, Midi over ethernet will also do in time. 

>What is required is:

Midi 2.0 will cure your problems a follows:

>* Timing transparancy (there is some technicalities to discuss here)
Midi 2.0 uses "any UART rate" selectable from each machine or automatic
from a "uart speed comando sent in MCS then they will automatically
use the new speed. (OBS machine to machine or multi drop)

>* Open structure to embedd new non-standard signals (compare note on/off with
>  unscaled pitch signal to that of a continous CV signal)

MCS does that allready!

>* High resolution timing events

Dynamic uart rate will do that to some extent!

>* Support for multiple timescales at the same time

MCS does that allready.

>* Support for continous time signals
I imagine Midi time code does that allready!?

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

Why would you need that? I see that as a non musical needed thing, more
of a "im a network system designer letts put in everything".;-) 

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

Syncronus network i suppose, and as such would require a fast
and accurate PLL to lock, particularely if fibre was to be used
in a TDM system to be implemented!, Now is this really needed?
Even a 1Mbit accurete asyncronus system will do in allmost any 
music situation. (exluding graphics and larger sample file transfers).

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

Midi could 2.0 support that if implemented in software and/or by using
e.g Bytheflight and different wave lenghts and synamic uart rates.
Or you could use existing MCS and simply implement that as an
internal layer of MCS. Disneyland are allready doing that!

>* Support hot-swap integration of devices

What on earth would you need that for? Midi is allready
hotswap as long as not sending anything on the line, believe
me i have fall'en over several times due to my feet strangled
into Midi cables, dam me what i have "hotswapped" things then! :-)

>* Support for auto-investigation of new devices

Emagic and Steinberg have done that for ages! 

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

That sound over complicated!
 
>* Be able to build arbitrary structured and sized networks

Now, we are really talking "im a network system design engineer and i whant all
that has ever been created just to play a singe note on my cheasy analog
diy synt"! ;-)

>* Be simple to manage and understand

Well, the you have to start over again with your definition of the new Midi
system!

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

Not at all, however i can agree that a bidirectional syncronus time sliced
system would be nice, but as long as there is no major industry support
for ""VERY LOW COST" transivers forget it!!

So Midi2.0 will do it, its a asyncronus, uses the Midi 1.0 protocoll
but new interface hardware, POF, glas fibre, ISM Radio, RS485,optocouplers,
whatever,and the ""bonafide"" is the dynamic UART rate, all thats needed
for the implementors is a tiny row in the LCD of the machine that says:
Midi speed:.......... (wich infact is nothing more then a baud rate divisor
value) and then all "old 8bitters" can connect to the new 16/32 bit systems
"WITHOU"T making an entire machine park redundant when it comes to networking!

Or if people could agree up on it could be syncronus by using SPI in
half duplex mode and dynamic rates, that would require a separate wire
for CLK if copper would be used or more resonable if a dual wavelength
trancivers over POF where to be used a single POF could be used for lenghts
over 1km. This is a truly syncronus multi master system and/or multidrop.
Everythings depend on the protocoll implemenations.

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

You are making things very complex, few can afford the propietary
DTM chip as the tranciver for the PIC16F87 you know! Very few would
pay for the chip from one wendor even fewer would pay for licencing.
 
>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.

Very complex for what actually in a music sittuation would be needed,
people are about to make music thats why Midi 1.0 made it trough,
its open, litteraely public domain, license free that is, fairly simple
beeing a UART based asyncronus thing. However i do agree that a XML
based format has its strong points.

Dave Smith the orginator did actually continue on what could have 
become Midi 2.0, the Prophet 2000 sampler had 64K rates implemented
but unfortunately the rest of the ratpack (Roland, korg, yamaha, OB
etc) just sat there on their flat butt and being ignorant!

Salout majumba!! 

Reg
KD 

Höstrusk och grå moln - köp en resa till solen på Yahoo! Resor på adressen http://se.docs.yahoo.com/travel/index.html