Thanks guys, much appreciated! I'll be giving this a spin as soon as I can.
On Sun, May 22, 2011 at 5:08 AM, Pedro Lopez-Cabanillas <pedro.lopez.cabanil...@gmail.com> wrote: > 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 > > _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
