On Monday 18 October 2010, Matt Giuca wrote: > So my questions for any interested observers (especially FluidSynth developers): > > 1. Is this feature worth implementing at all?
If you are motivated to do this work, then go ahead. Nobody has any right to stop you of adding an improvement that you want to implement, and you believe that it is valuable. I don't want to comment about the implementation details in your proposal, either. If you feel that the current API needs incompatible changes, then this feature should go in a library version 2. That's all. Not a big deal, this is going to happen sooner or later. There was a proposal by Antoine Schmitt in this mailing list some time ago about reimplementing the MIDI player using the sequencer API, in a similar way of James' SDL patches. That may work if some problems are solved first: the current MIDI parser is incomplete, and the sequencer lacks some features. If this refactoring is going to happen some day it would be complementary, not redundant, WRT your feature of reading MIDI data from a buffer instead of disk files. Talking about my personal interests, MIDI applications often need to parse MIDI files to manipulate MIDI events (sometimes interactively) before sending the events to the MIDI sequencer engine. For instance, to change the instrument maps of melodic and percussion instruments (MIDI mappers), or to manipulate controller events (i.e. MIDI volume), muting MIDI channels, transposing MIDI notes on melodic channels, synchronous display of SMF embedded song lyrics, and so on. All these functions belong not only to MIDI editors, but also to players like KMid (http://kmid2.sourceforge.net). This program has backends using the OS native sequencer services for Linux, Windows and MacOSX, and I would like to implement a pure FluidSynth backend. To do that, FluidSynth needs some new features for manipulating the playlists, but more important: a new mechanism in the MIDI player to route selected events to the client application, that may change them before playing. Opinions are welcome. Regards, Pedro _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
