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
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.
...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
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.
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
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.
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 [1], etc.
// David
[1] This proposal was added by my unconscious, subtly trying to make
me go and have breakfast soon. ;-)
_______________________________________________
fluid-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/fluid-dev