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

[Pedro Lopez-Cabanillas]

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