Re: [fluid-dev] Qsynth broken with FluidSynth 1.1.0

[josh]

Hello Rui,

Quoting Rui Nuno Capela <address@hidden>:
> Rui Nuno Capela wrote:
> > address@hidden wrote:
> > > Looking forward to hearing your results of recent SVN commits.  Once we
> > > know things are working right, I want to release 1.1.1 ASAP!
> >
> > yesss, i can confirn that fluidsynth svn r264 is doing it all the way:
> > qsynth build and runs ok, without major itches.
>
> however,...there might be some remaining issues.
>
> the most annoying being the apparent deferral of stable channel preset
> data, as is retrieved by fluid_synth_get_channel_preset() and listed on
> qsynth channels window.
>
> evidence may be noticed when looking at the initial channel preset
> assignments (bank, program, instruments) as seen on the qsynth channels
> window. more than often, all presets are shown unassigned at first
> glance. you'll have to refresh the view and retrieve all channel presets
> yet again to see the actual presets.
>
> can it be that fluid_synth_get_channel_preset() is also having some kind
> of new asynchronous semantics, like the queued event processing? then
> i'll ask which new api call gives us certainty of stable fluid_synth_t
> descriptor state, for sure? that is, some way to mimic older < 1.1.0
> synchronous/blocking api semantics ?
>
> seeya
> --
> rncbc aka Rui Nuno Capela
> address@hidden

Your observation is correct, as far as preset assignments being  
asynchronous.  That one may prove a little more difficult to implement  
in a thread safe manner AND allow for immediate accurate querying.   
I'll delve into it..

Other areas that are currently asynchronous in regards to set/get state:

fluid_synth_cc/fluid_synth_get_cc
Any preset change functions and fluid_synth_get_channel_preset
fluid_synth_set_gen(2)/fluid_synth_get_gen

It hadn't occurred to me before that this would be problematic, since  
there weren't really any guarantees that the API was synchronous.  I  
have every intention of making FluidSynth 1.1.1 as compatible as  
possible and still have improved multi-thread safety too.  So I'll  
look into fixing these incompatibilities.

Ciao!
Josh