Generic Controlling Language

I'm working on a project that is basicaly, I hope, going to replace midi. While comming up with some ideas, I thought it might be better to go ahead and design a general controlling language that works over multiple connection types(an common interface for usb, firewire, rs232, etc...). Then build my "new" "midi" language on top(and possibly some others).

I'd like to take advantage of using any connection type but keep the specific controlling language seperate from the connection depndent stuff. This is simply so one can simply write a new driver for it to take advantage of a new connection type without changing anything else.

Device 1 .... Device n | | | Driver Driver Driver | | | P P P \ | / G / | M Q

heh, thats the best I can do with ascii.

P is the protocol for the device that interfaces the specific driver for hte device with the G, the general language interface. M and Q are extensions of G that supply the specific control language.

The way I see it, though I have virtually no experience in control theory, is that a control language is simply a network of devices that send control messages back and forth... normally in "real-time". Basicaly for my purposes I need to a standard and efficient way to send real time messages across a host of devices with "special features" that might not be implemented in something like tcp/ip. Though there might be some similar idea out there already?

Here is the way I see how the control data is sent over a connection type:

(A lane is just a byte stream)

--------------------------------- | Ctr. Lane 1

--------------------------------- |

--------------------------------- |

--------------------------------- |

--------------------------------- |

--------------------------------- |

--------------------------------- |

--------------------------------- | Ctr. Lane n


------------- time---------------

So, instead of sending "packets" serially, the packets are interleaved so that one ctr. lane cannot delay the arrivial of another lane. Though the packet idea might work well in most conditions, I feel that it could cause some problems for what I need it to do(I have lots of small packets and lots of large ones that all need to arrive "on-time").

Now that is my basic theoretical idea for packing controler data and there are some problems ofcourse. Since I might have anywhere from 100 to 1000+ langes, each being from 8 to 32-bits wide(even more), the bandwidth could be saturated very quickly. Since alot of my controller data will be very sparse, I figure to reduce the bandwidth I could "compress" the lanes by turning "off" the ones that have not changed.

e.g., suppose you have a knob on one device that is to control something on another device. The knob is a variable resistor that is digitized to take on the values between 0 and 255. The data is send in a lane... so, whatever the rate of the lane is, the knob's values will be sampled at and sent across... even if the knob doesn't change. So to increase the avg. bandwidth, the basic idea is to "turn off" that lane when nothing has changed. That is, its virtually represented in the channel, but not physically. Ofcourse any lane that is changing continuously could not be turned off.

The way I was thinking of keeping track of the lanes was having a "lane" of bits that was as wide as the number of lanes.... the nth bit represented the nth lane being on or off. Also some lanes would be designated ahead of time if they were byte streams or controller info streams(and hence sends packets of info that might represent configuration information, etc...).

I suppose the whole idea boils down to usually have a physical wire for each control, but instead, to combine them into one wire and still have the same response. So if you have 100 controllers, you could have 1 wire for each controller for the best response... instead, go ahead and stick all those

100 physical wires into 1 physical wire that containes 100 virtual wires. (but instead stacking them serially(in some sense), you stack them parallel.)

It might be a moot point, and I might not be making much sense ;/ As any connection is ultimately serial. Basicaly I'm just trying to get away from the idea of each controller lane as being encapsulated by a packet saying what it represents. To do that the host and client will communicate back and forth and to say what lanes are what, so there is no need to for the packet(I might have 1000 "packets" at ones, if each one only had an overhead of 10 bytes, that might just be to much(actually not, but I feel there might be a better solution).

Anyways, I feel like I might not be making a lot of sense right now ;/ So I'll just leave it at that, except to say that there are a lot of issues I have to deal with(such as latency, synchonizing, error correction, bandwidth saturation, buffer sizes, etc...) and was just wondering if its worth looking into, as I'm mainly a software guy and have virtually no experience with networking and its hardware. Basicaly I just feel that if I'm going to go ahead and work on designing a control language for my applications, I might as well try to generalize it a little to work with more stuff.

Anyways, Maybe when I can concentrate I will write something up better if its not a waste of time. Thanks, Jon

Reply to
Jon Slaughter
Loading thread data ...

So..what's wrong with MIDI? (apart from the "non-standard" baud rate..)

The biggest issue you'll have to deal with is that there is no "ideal controlling language" to cover all situations - different applications have different needs. For example: TCP/IP is great if you have large amounts of data to send between multiple hosts and you don't care precisely when the data might turn up - fine for passing files around office LANs, but overkill/expensive for turning a single house light on/off after flicking the switch.

My 2c worth: Do a bit of research into "producer-consumer" and similar communications architectures. Around 10 years ago, the Audio Engineering Society (AES) journal published a series of papers for a true "plug and play" replacement for MIDI along the lines of USB, but I don't know if any of it got off the drawing board..

HTH, Cameron:-)

Reply to
Cameron Dorrough

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.