Re: [fluid-dev] Making MIDI player read from a buffer

[Graham Wykes]

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
> address@hidden
> 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