[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] callbacks
Re: [fluid-dev] callbacks
Sat, 13 Nov 2010 14:28:00 +0100
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:126.96.36.199) Gecko/20101027 Thunderbird/3.1.6
On 2010-11-08 19:32, Element Green wrote:
On Mon, Nov 8, 2010 at 12:37 AM, David Henningsson<address@hidden> wrote:
On 2010-11-07 21:20, Jari Suominen wrote:
I'm developing simple sampler program on top of fluidsynth and am
wondering that is there any way to receive callbacks when voices
Depending on what you're planning to do, you might want to help out with
SWAMI or QSynth instead of building yet another FluidSynth frontend.
Like if I have one sample that is x seconds long
assigned to some key on my soundfont and after that sample has played
Reason for doing this is that I would like to build a custom controller
that would have visual feedback of what is happening inside fluidsynth
Any ideas how to achieve this. Or did I just miss something in the API?
There is no way (in the API) to get such callbacks. It is possible you might
be able to poll for whether a voice has disappeared or not using
fluid_synth_get_voicelist. Note that usage of this function from a
thread-safe perspective might need some additional thought to make sure the
voices don't disappear in parallel with you trying to read them...
This is also some API that I am interested in, for Swami. I'll work
on it at some point, if no one gets to it before me. I think there
may be a callback or something (IIRC) which allows one to know when a
sample is no longer used by FluidSynth, which would help with garbage
sample collection and some limited status. I'm not certain as to the
thread safety aspect of it currently though.
My current FluidSynth API wishlist:
- 24 bit and/or floating point sample data support
...and the easiest way forward, would that be to depend libInstPatch?
How much does libInstPatch currently do and what would need to be
implemented in FluidSynth?
- Voice playback pointer querying
The 1.1.2 engine currently makes it hard to read anything that is
changeable by rendering. I'm not saying it's impossible though, we could
add atomic stuff that updates the playback pointer (and perhaps other
stuff as well). I would like to do that configurable though in order to
get maximum performance from use cases that does not need this
The other option would be that you do this yourself from the rendering
thread, but then you would have to hook into the audio driver and you'll
have to be careful in order to avoid underruns.
Callbacks leaves us the question as of from what thread(s) the callback
should be called. We have two options, either directly from the hard
real-time side, or transferred back to the soft real-time side. Now
remember that the engine does not own any threads on either side, so
you'll get the callback inside a call into the engine (which in turn
could be done by yourself or by a midi/shell/audio driver).
> - Current voice count
Already possible via fluid_synth_get_voicelist.
- Ensure sample garbage collection can occur in a thread safe fashion
Hmm, I haven't looked into this. Looking at the code now, there seem to
be calls for fluid_sample_decr_ref from both threads. It would be fairly
easy to move all calls to the soft real-time side, we should probably do
that. As for thread safety, you would then be guaranteed to only get one
notify callback at a time.
- [fluid-dev] callbacks, Jari Suominen, 2010/11/07
- Re: [fluid-dev] callbacks, David Henningsson, 2010/11/08
- Re: [fluid-dev] callbacks, Element Green, 2010/11/08
- Re: [fluid-dev] callbacks,
David Henningsson <=
- Re: [fluid-dev] callbacks, Element Green, 2010/11/13
- Re: [fluid-dev] callbacks, David Henningsson, 2010/11/14
- Re: [fluid-dev] callbacks, Jari Suominen, 2010/11/14
- Re: [fluid-dev] callbacks, Element Green, 2010/11/14
- Re: [fluid-dev] callbacks, David Henningsson, 2010/11/22
- Re: [fluid-dev] callbacks, Element Green, 2010/11/22