[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] Patch for handling midi note events
From: |
Pedro Lopez-Cabanillas |
Subject: |
Re: [fluid-dev] Patch for handling midi note events |
Date: |
Fri, 6 May 2011 20:03:20 +0200 |
User-agent: |
KMail/1.13.5 (Linux/2.6.34.8-0.2-desktop; KDE/4.4.4; i686; ; ) |
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 now 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
- [fluid-dev] Patch for handling midi note events, Jonathan Slenders, 2011/05/05
- Re: [fluid-dev] Patch for handling midi note events, Matt Giuca, 2011/05/05
- Re: [fluid-dev] Patch for handling midi note events, Jason Vasquez, 2011/05/06
- Re: [fluid-dev] Patch for handling midi note events, Jonathan Slenders, 2011/05/06
- Re: [fluid-dev] Patch for handling midi note events,
Pedro Lopez-Cabanillas <=
- Re: [fluid-dev] Patch for handling midi note events, David Henningsson, 2011/05/07
- Re: [fluid-dev] Patch for handling midi note events, Dave Serls, 2011/05/07
- Re: [fluid-dev] Patch for handling midi note events, David Henningsson, 2011/05/22
- Re: [fluid-dev] Patch for handling midi note events, Pedro Lopez-Cabanillas, 2011/05/22
- Re: [fluid-dev] Patch for handling midi note events, Jason Vasquez, 2011/05/25