On 19/10/2010, at 6:07 PM, David Henningsson wrote:
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
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
Would there be value in looking at the patch than Jim Henry mentioned
(given that it has been effectively tested for many years by hundreds
of users of Miditzer) to see whether it is compatible with the
current code. With any luck it may have
fluid_synth_handle_porridge_event already implemented ;-)
Graham
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev