On Sat, 07 May 2011 21:21:10 +0100 David Henningsson <di...@ubuntu.com> 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 > fluid-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/fluid-dev > _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
