Re: [fluid-dev] callbacks

[Jari Suominen]

David Henningsson wrote:
> On 2010-11-14 02:34, Element Green wrote:
> > On Sat, Nov 13, 2010 at 5:28 AM, David Henningsson<address@hidden>  
> > > > - 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 functionality.
> > >
> > > 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.
> >
> > I don't think it is possible though to get access to a single voice's
> > current sample playback position, even if handling the rendering, from
> > the public API though.  Or am I overlooking something?
>
> You're correct, this is more of a discussion on how such a thing 
> could/should be implemented.

Yep, for me having a callback or a way to poll whether voice has reached 
its end plus some way to get the playback position would be ultimate 
addition to API as it would give me a method to visualize the state of 
audio engine back to GUI. I'm thinking about stuff like using devices 
like Launchpad with applications built on top of fluidsynth.

But also I meant to ask whether adding stuff like this to API of 
fluidsynth makes sense from project perspective. As the application I'm 
working on isn't most typical fluidsynth app. But then again looking 
from MVC point of view, I think stuff like this would make sense even if 
you would be developing even the most simple front end to fluidsynth.

I think that even with current API I should be able to get some results 
with get_voicelist, but am a bit confused from where I should call it to 
make sure that everything works as it should thread-safety-wise?

Best,

...........j