Hey squeek - thanks for your help! I looked into SDL's event APIs and they
provide some custom event functions that are thread safe. I changed
everything in the callback to use those and that fixed my problem. Guess I
should be more aware of the threads going on in my app. Thanks again!
---
Paul Cohn
psc...@gmail.com
On Mon, Nov 19, 2018 at 1:35 AM sqweek E. <sqw...@gmail.com> wrote:
> I’m guessing that you’re hooking up Synth::seq_callback via
> fluid_sequencer_register_client or similar.
>
> It seems like a bad idea to be attempting GUI operations from such a
> callback, as GUI APIs generally expect to be driven by a single thread. A
> quick search suggests that SDL’s convention is that only the thread which
> creates the main windows is allowed to access it.
>
> Probably fluidsynth has its own separate thread to drive the midi
> sequencer resulting in this rule being violated, which could have many
> unpredictable consequences.
>
> I don’t know if there are other conventions governing what sort of
> functions are “allowed” to be called from a fluidsynth callback, but my
> instinct here would be that you shouldn’t be doing anything that might
> block for i/o or to allocate memory or any other operation which might hold
> up the midi thread.
>
> The usual workaround is to have the callback post an event to be handled
> by some other thread. The details of how to accomplish that vary from
> platform to platform; for windows PostMessage is a fairly simple way to get
> an event to the thread responsible for the GUI. SDL might provide something
> more portable?
>
> HTH,
> -sqweek
>
> On 19 Nov 2018, at 13:32, Paul Cohn <psc...@gmail.com> wrote:
>
> Hello,
>
> I've been stuck on this bug for a little while now, and I'm not sure it's
> directly related to fluidsynth but I'm hoping someone can shed some light
> even if it's a basic C++ issue.
>
> For context, I have a 2d game map you can move around, The effects of the
> bug I'm seeing are that the screen goes almost entirely black where it
> should be rendering stuff, except for the very top of the screen which
> shows what should be at the bottom of the screen, as if the camera has
> moved almost all the way down. I've checked and I believe the camera/map
> rendering is acting correctly.
>
> This happens only when calling certain SDL functions from the sequencer
> callback, at the very least I've found it happens with SDL_DestroyTexture
> and SDL_CreateTextureFromSurface.
>
> I have a Synth class that has a static seq_callback member. After playing
> something through the sequencer I need to trigger some effects, like
> showing a dialog. I have a reference to the Dialog class set on the Synth
> class as a static variable (since the static seq_callback needs to access
> it), and the dialog does stuff that ends up calling those SDL functions to
> display text.
>
> Example:
>
> class Dialog {
> showDialog() {
> // update label with text
> // this calls SDL_DestroyTexture / SDL_CreateTextureFromSurface
> }
> }
>
> class Synth {
> static Dialog* dialog;
> static void seq_callback(...);
> }
>
> void Synth::seq_callback(...) {
> dialog->showDialog("Text!"); // this succeeds, but creates the black
> screen bug
> }
>
> I've tried triggering the dialog from other static functions in the same
> class and it seems to work fine, the only way I've been able to reproduce
> is by triggering calls to those SDL functions from the sequencer callback.
>
> I am using:
> OSX mojave
> fluidsynth 1.11.1 (using brew, haven't been able to upgrade)
> SDL 2.0.8 (also brew)
>
> I think this actually used to work fine and am wondering if it's due to
> the mojave upgrade (which introduced a different kind of black screen bug),
> but it still seems strange that it only happens when triggered from the
> callback.
>
> Any help would be greatly appreciated.
>
> Thanks,
> Paul
>
> ---
> Paul Cohn
> psc...@gmail.com
>
> _______________________________________________
> fluid-dev mailing list
> fluid-dev@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
>
> _______________________________________________
> fluid-dev mailing list
> fluid-dev@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/fluid-dev
>
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev
