Re: [fluid-dev] Patch for handling midi note events

[Dave Serls]

On Sat, 07 May 2011 21:21:10 +0100
David Henningsson <address@hidden> wrote:

> On 2011-05-06 19:03, Pedro Lopez-Cabanillas wrote:
> > Hi,
> >
> > Sorry for coming so late to the discussion.
> >
> > On Friday 06 May 2011, Jonathan Slenders wrote:
> >> One thing, I moved player->user_callback(...)
> >> before fluid_synth_handle_midi_event. Because I sometimes also wanted to
> >> adjust the pan, the volume, and instruments on the channel played for a
> >> note.
> >> I can also image that someone (maybe me too) wants to alter the midi 
> >> events,
> >> supress notes or change pitch an octave up at a certain point.
> >
> > Me too :-)
> >
> > Seriously. This is something that I was planning for using in one of my pet 
> > projects: http://www.kde.org/applications/multimedia/kmid . This program is 
> > a MIDI/karaoke player with features like pitch transpose, tempo control, 
> > channel solo/mute, synchronized lyrics display and integrated pianola. It 
> > plays to hardware MIDI ports or soft synths. The program has three MIDI 
> > backends right now: Linux/ALSA, Windows and MacOSX/CoreMIDI. My plan was to 
> > develop a fourth backend based on FluidSynth only. It would require exactly 
> > the same feature you are trying: a callback just before delivering the MIDI 
> > event to the synth, allowing the client application to change event's 
> > parameters. But for my program this is only one of the required additions 
> > to FluidSynth. Another one would be a callback while FS is parsing the MIDI 
> > file, reporting to the client application all the meta-events like titles, 
> > track names, copyright notices, texts and lyrics, time/key signatures, that 
> > are ignored rig!
 ht 
> no
> > w in FluidSynth but would be required by kmid. Talking about text and 
> > lyrics, these events would be reported by the player callback at playing 
> > time as well, although they would be ignored by the synthesizer.
> >
> > Considering the two proposed callbacks, instead of new_fluid_player2() 
> > perhaps I would prefer two functions: 
> > fluid_player_register_playback_callback() and 
> > fluid_player_register_parser_callback() with their corresponding 
> > unregister() companions.
> >
> > The parser callback would be quite innocuous in process time constraints, 
> > and will be called in the same thread as fluid_player_add(), so there is 
> > little concern about it. The playback callback is another issue: first, it 
> > will be potentially called from a realtime thread, with small time 
> > constraints. If the callback allows event modifications it should be called 
> > synchronously, ahead of the delivering time to the synth, and the client 
> > application would need to return within this time frame. It would be easier 
> > to implement a pure notification callback, called asynchronously from 
> > FluidSynth but without allowing event modifications.
> >
> > Talking about events. The structure fluid_midi_event_t has been opaque for 
> > a long time in FluidSynth, and I think it should remain opaque. There are 
> > API functions to access some event properties, and more API functions would 
> > be welcome if needed.
> >
> > Regards,
> > Pedro
> 
> Hi folks and thanks for the patches and comments,
> 
> I mostly agree with Pedro (e g about letting the fluid_midi_event_t 
> remain hidden), but I'd like the callback function to be used instead of 
> (rather than before or after) calling fluid_synth_handle_midi_event. 
> That means that we'll start off with the player's callback function 
> pointer being fluid_synth_handle_midi_event (for simplicity and 
> backwards compatibility) but we can change it through a new api function 
> called fluid_player_set_playback_callback(). That way you should be able 
> to not only insert your own processing (eavesdropping, changing and 
> removing notes as necessary), but also to insert our existing midi 
> router into the playback chain for midi files.
> 
> Does that make sense or am I missing something?
> 
> (Btw - I'm holding a speech on FluidSynth real-time and thread safety 
> challenges tomorrow morning, if you like you can listen and ask 
> questions on IRC in real-time. [1])
> 
  Lucky you -- first on the agenda, first into the pub.

> // David
> 
> [1] http://lac.linuxaudio.org/2011/?page=program&mode=table&day=3
> 
> 
> _______________________________________________
> fluid-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
>