kmidi state of the onion
Russell Miller
rmiller at duskglow.com
Sat Aug 16 04:27:43 BST 2003
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
More information about the kde-core-devel
mailing list