Enabling hotloading causes zest to crash

[jcfischer]

I have enabled hot-loading as per the contribution documentation.

When starting zest, I get the following error:

[INFO:Zyn] setup_pugl()
[INFO:Zyn] zest_open()
[INFO:Zyn] Starting Zyn-Fusion
[INFO:Zyn] Thanks for supporting the developement of this project
[INFO:Zyn] Creating MRuby Interpreter...
[debug] parsing json file
[debug] json parsed succesfully
superclass mismatch for class Qml::ZynAutomationMidiChan
/Users/fischer/work/ui/jcf-mruby-zest-build/src/mruby-qml-spawn/mrblib/build.rb:183:in QmlIrToRuby.solve_ir
/Users/fischer/work/ui/jcf-mruby-zest-build/src/mruby-qml-spawn/mrblib/build.rb:103:in QmlIrToRuby.initialize
/Users/fischer/work/ui/jcf-mruby-zest-build/mruby/mrblib/hash.rb:94:in Hash.each
/Users/fischer/work/ui/jcf-mruby-zest-build/src/mruby-qml-spawn/mrblib/build.rb:99:in QmlIrToRuby.initialize
/Users/fischer/work/ui/jcf-mruby-zest-build/src/mruby-qml-spawn/mrblib/build.rb:784:in Object.doFastLoad
/Users/fischer/work/ui/jcf-mruby-zest-build/src/mruby-widget-lib/mrblib/script.rb:88:in ZRunner.init_window
trace:
	[0] /Users/fischer/work/ui/jcf-mruby-zest-build/src/mruby-widget-lib/mrblib/script.rb:93:in ZRunner.init_window
/Users/fischer/work/ui/jcf-mruby-zest-build/src/mruby-widget-lib/mrblib/script.rb:93: Impossible Widget (RuntimeError)
[FATAL ERROR] Mruby Is Unable To Continue

[fundamental]

On 06-27, Jens-Christian Fischer wrote: I have enabled hot-loading as per the contribution documentation. When starting zest, I get the following error: ... superclass mismatch for class Qml::ZynAutomationMidiChan ...

I'm pretty sure that can be resolved if you update the mruby-qml-parse submodule to the most recent version. mruby-zest/mruby-qml-parse@a3e6871 Should be the commit in question which fixes the issue. Essentially what's happening under the hood is that while building the ruby objects from the .qml files ZynAutomationMidiChan is first assigned the incorrect super class 'TextBox' from this test set and then after the TextBox.qml file is parsed it's assigned the correct super class 'Qml::TextBox' causing a super class conflict (for which the original exception produced within mruby isn't terribly helpful)

[jcfischer]

thanks - that fixed this problem - but the hotloading doesn't seem to work.
Also - I updated all submodules on my first try which led to a compile error

/Users/fischer/work/ui/jcf-mruby-zest-build/src/mruby-zest/src/quickdraw.c:89:13: error: implicit declaration of function 'mrb_ary_len' is invalid in C99
      [-Werror,-Wimplicit-function-declaration]
    int n = mrb_ary_len(mrb, ypts);
            ^

Only updating the mruby-qml-parse module worked though.

On another [un]related note: While the UI builds and displays, I can't change any controls. Buttons, knobs etc are not reacting to mouse input. (The full downloaded synthesizer works fine, though)

[fundamental]

On 06-28, Jens-Christian Fischer wrote: thanks - that fixed this problem - but the hotloading doesn't seem to work. Also - I updated all submodules on my first try which led to a compile error ``` /Users/fischer/work/ui/jcf-mruby-zest-build/src/mruby-zest/src/quickdraw.c:89:13: error: implicit declaration of function 'mrb_ary_len' is invalid in C99 [-Werror,-Wimplicit-function-declaration] int n = mrb_ary_len(mrb, ypts); ^

It looks like whenever the mruby submodule is eventually updated then that code will need to change to use RARRAY_LEN instead: mruby/mruby@67e2ddd That shouldn't be a huge priority at the moment however.

Only updating the mruby-qml-parse module worked though. On another [un]related note: While the UI builds and displays, I can't change any controls. Buttons, knobs etc are not reacting to mouse input. (The full downloaded synthesizer works fine, though)

So, the full synthesizer (as a plugin) doesn't get events through the version of PUGL (in the deps folder), but a different fork of PUGL within the DPF submodule of zynaddsubfx. The reasons why are a bit convoluted, though it does mean that there could in theory be a bug in the version of PUGL you're seeing that only affects OSX. You should be able to observe a few different types of events. Mouse hover events should display tooltips in the top center info area, Key presses should play notes (though I'm not sure if that would be visible without the synthesizer's feedback). Control should light up the MIDI button and Shift should highlight the 'fine' button. If it looks like nothing is working, then something must be wrong with: pugl_osx.m If it looks like it's partially working then it should be possible to inspect all events within testlibversion.c e.g.: https://github.com/mruby-zest/mruby-zest-build/blob/master/test-libversion.c#L80-L88 Thanks for bearing with the issues

[jcfischer]

it looks like nothing is working, then something must be wrong with: pugl_osx.m

yeah - nothing works... I have tried to compile Zyn from scratch, to see if I can get that to work, but I didn't manange to build gcc (the mpfr archive couldn't be extracted) (and without that specific gcc, the other parts don't compile)

I looked at the version of pugl that is checked out out from mruby-zest in the full Zyn - it looks to be the same one that is here, in this repo - at least they check out the same git version of pugl (I didn't notice anything special in the build script for Zyn about pugl either)

Thank You for bearing with me fumbling my way through things

[fundamental]

https://github.com/DISTRHO/DPF/tree/master/dgl/src/pugl is the version of PUGL which gets used when zyn is used as a plugin. Since that appears to work just fine on OSX, I'd expect something to be right in that variant and something to be wrong in the version used in the standalone. They differ somewhat in terms of API, so it's not a simple copy/paste, unfortunately.

@falkTX Do you recall what changes you needed to make to PUGL to fix up the issues on OSX? I recall there was something with event handling, but not precisely what you had changed to get stuff working.

[jcfischer]

Hmm - ok, I think I will wait for that particular rabbit hole to be dug out.

The only thing that I can think off (and I'm all very new to this world of audio plugins) is that the VST gets a pointer to a parent window to render in - could that be a problem? That is what the Rust guys are fighting with in another UI library rust-windowing/winit#159

[falkTX]

DPF pugl osx code is quite different from upstream.
I imported some ideas and suggestions from rutabbaga(?) (the tookit from wrl), so it works better on OSX.
It is not possible to send these changes upstream now since it changed a lot already.

At some point I need to update DPF pugl code to be more in sync with upstream.
But yeah, there are quite some changes in osx code.
They involve stuff such as not creating a window if embed UI, rewriting pointer/mouse tracking areas, and some thread-safety needed things (for ableton, which uses openGL with multiple threads)

[jcfischer]

Thanks @falkTX . Would it be possible to replace the pugl version that @fundamental is using in this project with yours?