kmidi state of the onion

[Russell Miller]

Well, the musical is now over, and I intend on focusing some attention onto 
kmidi as soon as some of the more pressing things drop off of my plate, which 
I'm slowly starting to get done.  Meanwhile, I thought I'd post my idea of 
the direction kmidi is to go, and get feedback.  Feedback is good.  Well, 
unless it ends up with about 30,000 posts.  Then I'll have to cover it on 
kde-traffic. :(

Anyway, here's the idea.

Kmidi's code, as it stands, is almost inextricably intertwined with an 
obsolete version of timidity.  Upon taking a look through the code, I've 
determined that it will be easier for me to rewrite it, even if in sections, 
than to fix it.  There is already kmid, which does pretty well most of the 
things that kmidi already does, so as it stands, getting rid of kmidi would 
seem to be a viable option.  There is, however, a niche for kmidi.

My goals for kmidi are as follows.  Of course, feedback is welcome, or I 
wouldn't be writing this.

There are several things about kmidi that I consider to be Bad Things.  The 
first being that it has a kind of "kitchen sink" mentality - to the point 
where the UI can barely hold it.  Now, I've done a little work to make the UI 
a little saner, but its design is simply broken.  Another thing is the fact 
that timidity is hardcoded into it.  A third thing is that kmidi can't really 
seem to decide what it wants to be, so it ends up trying to be everything.

I propose splitting midi up into several components.  The first component is 
the core.  It is to act solely as a midi stream broker.  Streams get sent 
into kmidi using stdin, a socket, ip, a file, pretty much anything.  Probably 
using a quasi-plugin mechanism.  Heck, the input could even be a hardware 
interface or a virtual keyboard.

The second component is a filter.  It communicates with the core.  The core 
sends midi events to the filter, which processes them, and can generate 
events of its own.  This filter can also communicate with the core, telling 
it to begin streaming, to end streaming, etc.  The filter will probably be 
the component that will communicate with the end user, but doesn't have to.  
The filter will not know the origin of a midi stream, only that it has come 
in from the core.  It will also be programmable and/or scriptable.  Something 
similar to a mixer or soundboard, but much more versatile.

Of course, there would be limitations to this model.  I can think of a few, 
one of them being that midi is limited to a 31,400(?)kbaud rate over an 
external interface, therefore mixing may not be entirely useful.  Another is 
that it runs the risk of becoming too complicated if design isn't handled 
carefully.  The benefits, however, are versatility, real-time effects 
generation/mixing/modification/interpolation, and other cool things that to 
my knowledge aren't really possible right now.  Essentially kmidi would 
become a midi sequencer/editor/streamer rather then a synthesizer.

Of course, I could be missing something.  Anything I haven't thought about?  
Is it even worth it to try?  Or should I just try to work with a timidity 
server and scrap the rest?

--Russell

-- 
Randomly generated fortune cookie:
management, n.: The art of getting other people to do all the work.

Russell Miller - rmiller at duskglow.com - Somewhere near Sioux City, IA.
Youth cannot know age, but age is guilty if it forgets youth
    - Professor Dumbledore