Re: [fluid-dev] Patches for 1.1.1

[Sven Meier]

Hi Elimar,

thanks for looking into these issues. I agree that we shouldn't haste 
into a temporary solution which might introduce other issues.

However I'd like to note that #79 doesn't need any changes to event 
ordering:
Currently all control changes are queued (fluid_synth_queue_midi_event) 
in the order they were received - this should stay the same.

But ALL_CTRL_OFF is handled differently from other controllers:
Resetting all controllers is done only after dequeuing of the event 
(fluid_channel_init_ctrl) while setting a controller is done immediately 
(fluid_channel_set_cc) *before* queuing.
This way the ALL_CTRL_OFF will overwrite all successive controller 
changes *until* its event is dequeued.

Regards

Sven

Am 05.06.2010 18:49, schrieb Elimar Green:
> Hello Sven,
>
> I'm aware that there are rather significant issues with the new version
> of FluidSynth.  Properly fixing them would require a bit more time
> investment than I currently have to offer the project though.  The patch
> to #79 looks like it would introduce another potential event ordering
> issue.  It seems to me, that if an ALL_CTRL_OFF event is received,
> followed by a control change event, they should be processed in the
> order they were received in (how it is now).  Having a combination of
> queued versus non-queued events, leads to non-deterministic behavior
> (the current issue with #65).  There is no guarantee as to which order
> the events will be processed.
>
> I'd like to fix this soon, but I want to do it properly.  I'm not
> convinced yet that these two solutions are the proper way.  Please
> convince me though, if you feel they are, since I haven't researched it
> thoroughly.  When I have some more time, I'll look into re-designing
> FluidSynth, so these queuing issues no longer exist.  Hopefully in the
> next month or two.
>
> Best regards,
>
> Elimar
>
>
> On Sat, Jun 5, 2010 at 7:45 AM, Sven Meier <address@hidden
> <mailto:address@hidden>> wrote:
>
>     Hi Elimar,
>
>     first let me thank you for your efforts on Fluidsynth, especially
>     for the recent migration to Sourceforge.
>
>     Please note that issues #79 and #65 are no obscure feature requests
>     of a few organ enthusiasts but failures to adhere to the Midi
>     specification.
>
>     Could you please take a look on
>     http://sourceforge.net/apps/trac/fluidsynth/ticket/79 ?
>     The attached patch doesn't change the queuing mechanism. Controllers
>     are just reset immediately, so I don't expect any incompatibility
>     with QSynth because of this change.
>
>     Regards
>
>     Sven
>
>
>     On 06/05/2010 01:20 AM, Elimar Green wrote:
>
>         Looking over the mailing list archives, I was able to refresh my
>         memory as to why I reverted the bank queuing.  Programs like
>         QSynth rely on the notion that querying current bank/program
>         numbers assigned to channels will reflect the most recently
>         assigned values.  For some reason I opted to revert the queuing
>         behavior, since it went against the mentioned expectation,
>         rather than try and have the state machine reflect the most
>         recent assignment.  The right way to fix all this is to re-work
>         the FluidSynth core thread related code to get rid of queuing
>         where possible.  As has been discussed a little previously
>         between David and myself, as much of the state machine as
>         possible should be protected by the synth mutex and queuing used
>         only to update the synth core, which would then be purely a
>         voice synthesis engine.
>
>         If there is a quick fix though, to resolve the out of order
>         issues AND also work in regards to returning the latest
>         bank/program number when queried, I'm all for that.  Simply
>         reverting back to the queued case though, will break QSynth.
>
>         Cheers,
>
>         Elimar
>
>         On Fri, Jun 4, 2010 at 3:06 PM, Elimar Green
>         <address@hidden <mailto:address@hidden>
>         <mailto:address@hidden <mailto:address@hidden>>>
>         wrote:
>
>             Ticket reporting on SourceForge is working.  I got an
>         update.     Just haven't gotten around to researching why I
>         originally changed
>             it from queuing program changes.  I'm sure there was some reason
>             to that, but event ordering issues are obviously not
>         acceptable.     I'll try and get around to reviewing this soon.
>           Perhaps there was
>             some mailing list traffic around revision 277 that would clarify
>             why the queuing got reverted.
>
>             Regards,
>
>             Elimar
>
>
>             On Fri, Jun 4, 2010 at 2:01 PM, Graham Goode <ggoode.sa
>         <http://ggoode.sa>
>         <http://ggoode.sa>@gmail.com <http://gmail.com>
>         <http://gmail.com>> wrote:
>
>                 Hi Guys,
>
>                 Sven Meier of the jOrgan project has made some fixes for
>                 fluidsynth
>                 1.1.1 (Tickets 65 and 79). We as jOrgan users have his
>         patched
>                 fluidsynth version but it looks like these have not been
>                 accepted into
>                 the SourceForge repository yet. Is there someone looking
>         into
>                 these or
>                 is sourceforge not reporting ticket changes yet?
>
>                 GrahamG
>
>                 _______________________________________________
>                 fluid-dev mailing list
>         address@hidden <mailto:address@hidden>
>         <mailto:address@hidden <mailto:address@hidden>>
>
>         http://lists.nongnu.org/mailman/listinfo/fluid-dev
>
>
>
>
>         _______________________________________________
>         fluid-dev mailing list
>         address@hidden <mailto:address@hidden>
>         http://lists.nongnu.org/mailman/listinfo/fluid-dev
>
>
>
>     _______________________________________________
>     fluid-dev mailing list
>     address@hidden <mailto:address@hidden>
>     http://lists.nongnu.org/mailman/listinfo/fluid-dev