[iiwusynth-devel] RE: Command response framing and TCP/IP

[Ken Ellinwood]

> One idea that came to my mind is to have a dedicated socket for
> real-time messages ('noteon x y z' when a MIDI key is hit).
> My own GUI is perl based, and perl is very good at string parsing. But
> for the C folks, it may be of advantage, when replies to a command via
> TCP/IP go to a separate socket. But as I said, anything that works...
> 

Lets put off the dedicated socket until someone asks.  Implementing support for
multiple sockets will force the multithreaded command processor feature. 
Personally, I haven't been worrying about performance because my goal for a GUI
is a lighweight wrapper just to be able to graphically load fonts, assign
font/bank/preset to channels, save/load the current configuration, etc.  I
always planned on using MIDI via a sequencer for composition/playback.

I've also been assuming that someone who cares about performance would be
developing an app and linking directly with the internal APIs, bypassing the
command shell altogether.

Regarding the reply buffer issue, I'm now thinking that we should pass the
handlers a pointer that points to a function with the signature of printf(). 
They use the pointer to write the reply output, and the command shell loop
supplies an implementation that does the right thing.  For the existing two
loops that currently output to stdout, we just pass printf.  The TCP loop would
pass a pointer that writes back over the socket.   At least this way  the
handlers don't change much.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com