--- On Wed, 10/21/09, Pedro Lopez-Cabanillas <pedro.lopez.cabanil...@gmail.com> wrote:
> > I used to use Kmid, but no one ported it to Qt4/Kde4 > yet, not sure how long > > before it would be called an orphan. > > I'm already starting the adoption process. Pedro, Alright, good to know. You got SVN/CVS, discussion group for it somewhere? Would it be better depending on just QT4, or QT4.5, instead of KDE. I prefer lighter-weight apps that works well with simple interface, nothing fancy. I just read a couple of articles on Slashdot about Pulse Audio. The project lead, and some of their developers want it on every desktop and claimed that "latency is good" (???, !...@#(!^#!!!), that 20-second audio buffer would help them make less interrupt calls to save power or so. Yeah, right... Saving energy on a few lousy hardware interrupts and blast away on the speakers, or their "continuous reconfiguration daemon". Their idea of "playing music" is to use their couch-potato ears. No wonder the rap craps are everywhere and they think they are great musicians, too. > KMid is about 10 years old. It is time for a revamp. My > plans for it are: > * Remove the deprecated OSS /dev/sequencer interface > support. It has been > dropped from OSSv4, anyway. > * A fair ALSA sequencer implementation: don't > create/destroy the client and > port instances on each play/pause/stop action. This would > allow the usage of > KMid with a MIDI patchbay application like qjackctl. So you spent sometime with the adopted kid (uh... code) already :-) > * MIDI Output implemented on pluggable backends. First one > will be the ALSA > sequencer backend, but I would like to develop win32 and > Mac native backends > some day. Jack-midi could probably help on win32 and even Mac, I think??? > Also, a multiplatform backend based on > libfluidsynth would be > interesting for casual users, needing only to configure a > SF2 file and the > audio output. Some new features would be needed in > libfluidsynth to create > this backen> > Regards, > Pedro d, for instance: parse and process the lyric and > text SMF events. That is if libfluidsynth care to spend time with lyrics and midi-text events at all. Although, I think fluidsynth code is not pretty to add new functions to it. Haven't looked at Gleamsynth (a sort-of Fluidsynth in C++) since the Spring, but I think it did have some performance issues back then. I think the new kmid (or whatever its new name maybe) could do what it always does... send midi events to alsa-seq, or jack-midi, and also parse and display lyrics/midi-text. It may be interesting if it (or its library) also has a separate output port (output-only ???) for lyrics/midi-text events separately from the normal midi port. This way, people can make their own UI, or even network-UI if they want. Jimmy _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev