On Tuesday 19 October 2010, Jim Henry wrote: > Pedro, > > It sounds like you are suggesting a feature that the Miditzer virtual > organ uses. A number of years ago Sebastian Frippiat suggested extending > FluidSynth so that the MIDI Player would pass the MIDI events to the > caller rather than playing them.
You mean these patches, right? http://www.mail-archive.com/fluid-dev@nongnu.org/msg00262.html Yes, this strategy may allow to manipulate the events *before* playing them in some cases, or *instead of* playing the events in other cases. This is part of the additional functionality I need for the KMid backend. The tempo factor is also in my agenda. The velocity factor is not, because volume changes should be done using the CC#7 (main volume) controller instead. And I also need a pitch modifier (MIDI note number +/- 12 semitones) but this can be implemented using the events callback. > At the time there was no interest in > his proposal. I think this was in part because he wanted just to use > FluidSynth as a MIDI file reader and it was felt that was not within the > scope of FluidSynth's purpose. He did post patches for doing this. We > picked up those patches for the Miditzer and they are in the version of > FluidSynth used with the Miditzer. Nice, so you have tested this well. May I have your modified source code of FluidSynth, please? > As Pedro suggests, the Miditzer takes MIDI input, including the input > from the FluidSynth MIDI file reader, and vigorously manipulates the > MIDI data before sending it to FluidSynth to be realized in order to > create the organ performance paradigm which just doesn't fit within the > standard MIDI specification. (By that I mean there is no way to fully > encode the performance of an organ according to the MIDI specification.) > > If there is now interest in extending the FluidSynth MIDI file player to > send the MIDI messages to the caller for processing rather than playing > them, I certainly support such an effort. Yes. My plan include some more things. First, I want to parse all SMF meta- events, including all kind of text events. Most of these events are meaningless for the synthesizer, but can very important for applications. For instance, to display song lyrics. The song contents needs to be exposed to the application client, either using another callback function hooked inside the parser that would be called for some types of events, or exposing the whole song structure to the clients after the song has been parsed, with an API to enumerate the tracks, events on the tracks, and so on. It would be nice to have a mechanism to modify, delete and insert events, or even new tracks, and also supporting "user events" defined by the client applications. This would be like the MIDI part of the AudioToolbox framework in MacOSX. Regards, Pedro _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev