Thanks! Greetings from the Akademy-es 2011 at Barcelona.
Regards, Pedro On Sun, May 22, 2011 at 11:05 AM, David Henningsson <di...@ubuntu.com>wrote: > On 2011-05-07 22:21, David Henningsson 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 right >>> >> 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? >> > > I heard no objections, so this variant has now been committed (r421). Test > and enjoy! > > // David > > > _______________________________________________ > 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
