On 2010-10-19 00:02, Pedro Lopez-Cabanillas wrote:
On Monday 18 October 2010, Matt Giuca wrote:
So my questions for any interested observers (especially FluidSynth
1. Is this feature worth implementing at all?
If you are motivated to do this work, then go ahead. Nobody has any
stop you of adding an improvement that you want to implement, and you
that it is valuable.
...as long as it doesn't break anything else, which is the hard part.
I don't want to comment about the implementation details
in your proposal, either. If you feel that the current API needs
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.
If you're talking about dropping backwards compatibility, then that is
a big deal IMO. We might come to a point where we believe it is
necessary, but I don't see it coming right now. It would mean all
distros shipping with two FS library versions, then someone finds a
bug in the old one, and we only support the new one, and so on...
There was a proposal by Antoine Schmitt in this mailing list some
about reimplementing the MIDI player using the sequencer API, in a
of James' SDL patches. That may work if some problems are solved
current MIDI parser is incomplete, and the sequencer lacks some
this refactoring is going to happen some day it would be
redundant, WRT your feature of reading MIDI data from a buffer
instead of disk
Talking about my personal interests, MIDI applications often need to
MIDI files to manipulate MIDI events (sometimes interactively) before
the events to the MIDI sequencer engine. For instance, to change the
instrument maps of melodic and percussion instruments (MIDI mappers),
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
editors, but also to players like KMid
program has backends using the OS native sequencer services for
and MacOSX, and I would like to implement a pure FluidSynth backend.
that, FluidSynth needs some new features for manipulating the
more important: a new mechanism in the MIDI player to route selected
the client application, that may change them before playing. Opinions
I think inserting a hook would be quite easy.
fluid_synth_handle_midi_event is called from fluid_track_send_events,
and it seems like that would be a good place to insert the hook - let
the fluid_track_send_events call a user-specified callback, then let
the user-specified callback call fluid_synth_handle_midi_event, or
call some other fluid_synth_* function, or write to the console, or
eat porridge , etc.
 This proposal was added by my unconscious, subtly trying to make
me go and have breakfast soon. ;-)
fluid-dev mailing list