Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Zyn fusion exe files do not run GUI correctly #28

Open
fluzz142857 opened this issue Jan 16, 2019 · 7 comments
Open

Zyn fusion exe files do not run GUI correctly #28

fluzz142857 opened this issue Jan 16, 2019 · 7 comments
Labels

Comments

@fluzz142857
Copy link

DLL files work correctly, but exe files on both demo and release versions do not open the interface correctly. Running an exe file opens a terminal and GUI window. The GUI window starts at a black screen. Dragging the GUI window off the screen refreshes the part of the GUI window that was hidden, displaying it correctly until dragged off again. Keyboard and mouse inputs work correctly. Sound works normally.

Terminal window debug information seems to be normal.
Sample release version terminal info:

ZynAddSubFX - Copyright (c) 2002-2013 Nasca Octavian Paul and others
                Copyright (c) 2009-2017 Mark McCurry [active maintainer]
This program is free software (GNU GPL v2 or later) and
it comes with ABSOLUTELY NO WARRANTY.

Try 'zynaddsubfx --help' for command-line options.

Sample Rate =           44100
Sound Buffer Size =     256 samples
Internal latency =      5.8 ms
ADsynth Oscil.Size =    1024 samples
lo server running on 19146
[INFO] Nio::start()
Starting Audio: PA
Audio Started
Starting MIDI: NULL
MIDI Started
[INFO] exec-after-init
[INFO] No Windows MIDI Device At id 0
[INFO] No Windows MIDI Device At id 1
[INFO] No Windows MIDI Device At id 2
[INFO] No Windows MIDI Device At id 3
[INFO] No Windows MIDI Device At id 4
[INFO] No Windows MIDI Device At id 5
[INFO] No Windows MIDI Device At id 6
[INFO] No Windows MIDI Device At id 7
[INFO] No Windows MIDI Device At id 8
[INFO] No Windows MIDI Device At id 9
[INFO] startup OSC
[INFO] UI calbacks
[INFO] OSC replay
[INFO] auto_save setup
[INFO] NSM Stuff
[INFO] LASH Stuff
[INFO] Launching Zyn-Fusion...
[INFO] starting subprocess via <zyn-fusion.exe osc.udp://127.0.0.1:19146/>
[INFO] Main Loop...
[INFO:Zyn] setup_pugl()
[INFO:Zyn] zest_tick()
[INFO:Zyn] zest_open()
[INFO:Zyn] Found Assets at C:\Users\strea\Documents\zyn-fusion\zyn-fusion-build-master\zyn-fusion-build-master\zyn-fusion-windows-64bit-release\
[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
[INFO:Zyn] zest_setup()
[DEBUG:Zyn] setting up animation fps
[INFO:Zyn] zest_close()
[INFO] Closing MRuby Application...
[INFO] UV UDP Stopped
[Warning] UV Loop Cannot be closed [-4082] (UV_EBUSY=-4082)
[INFO:Zyn] Destroying pugl view

Sample demo mode terminal info:

ZynAddSubFX - Copyright (c) 2002-2013 Nasca Octavian Paul and others
                Copyright (c) 2009-2017 Mark McCurry [active maintainer]
This program is free software (GNU GPL v2 or later) and
it comes with ABSOLUTELY NO WARRANTY.

Try 'zynaddsubfx --help' for command-line options.

Sample Rate =           44100
Sound Buffer Size =     256 samples
Internal latency =      5.8 ms
ADsynth Oscil.Size =    1024 samples
lo server running on 19417
[INFO] Nio::start()
Starting Audio: PA
Audio Started
Starting MIDI: NULL
MIDI Started
[INFO] exec-after-init
[INFO] No Windows MIDI Device At id 0
[INFO] No Windows MIDI Device At id 1
[INFO] No Windows MIDI Device At id 2
[INFO] No Windows MIDI Device At id 3
[INFO] No Windows MIDI Device At id 4
[INFO] No Windows MIDI Device At id 5
[INFO] No Windows MIDI Device At id 6
[INFO] No Windows MIDI Device At id 7
[INFO] No Windows MIDI Device At id 8
[INFO] No Windows MIDI Device At id 9
[INFO] startup OSC
[INFO] UI calbacks
[INFO] OSC replay
[INFO] auto_save setup
[INFO] NSM Stuff
[INFO] LASH Stuff
[INFO] Launching Zyn-Fusion...
[INFO] starting subprocess via <zyn-fusion.exe osc.udp://127.0.0.1:19417/>
[INFO] Main Loop...
[INFO:Zyn] setup_pugl()
[INFO:Zyn] zest_tick()
[INFO:Zyn] zest_open()
[INFO:Zyn] Found Assets at C:\Users\strea\Documents\zyn-fusion\zyn-fusion-build-master\zyn-fusion-build-master\zyn-fusion-windows-64bit-demo\
[INFO:Zyn] Starting Zyn-Fusion Demo...
[INFO:Zyn] Creating MRuby Interpreter...
[debug] parsing json file
[debug] json parsed succesfully
[INFO:Zyn] zest_setup()
[DEBUG:Zyn] setting up animation fps
[INFO:Zyn] zest_close()
[INFO] Closing MRuby Application...
[INFO] UV UDP Stopped
[Warning] UV Loop Cannot be closed [-4082] (UV_EBUSY=-4082)
[INFO:Zyn] Destroying pugl view
@fluzz142857
Copy link
Author

Video of this happening: https://youtu.be/oKf6xk7EpHI

@fundamental
Copy link
Member

That sounds like an issue with pugl's handling of redrawing/expose events under your build configuration. Unfortunately I don't have a windows system to directly test this problem.

@ghost
Copy link

ghost commented Sep 30, 2020

@fluzz142857 In mruby-zest-build/test-libversion.c remove puglEnterContext & puglLeaveContext in function main. This should fix it. Let me know if it doesn't

@fundamental This commit: mruby-zest/mruby-zest-build@ef8df03 caused the regression. Not sure what to do. Simply removing it makes it work on my end but could also break something that commit was trying to fix.

@fundamental
Copy link
Member

Interesting. I wouldn't have suspected that chunk of code, but I could see how there could be an interaction there. I'm guessing the safest way of addressing the fix would be to disable those calls only on windows via a quick #ifdef. I'm pretty sure everything should also work fine (outside of the automated screenshot mode) on linux with those disabled, but well a) I do like that mode and b) I can't recall offhand if there were other interactions to be concerned with on linux/macos.

@ghost
Copy link

ghost commented Oct 2, 2020

How do you enter automated screenshot mode?

Maybe it works in windows even without the extra puglLeave/Enter calls. If that's the case, using the ifdef won't even cause an issue and this becomes a no brainer. (Yes, I'm an optimist :) )

Background about this bug: When you call puglEnterContext it issues a BeginPaint call. The ms documentation says to never to call that function unless you're in an WM_PAINT event. WM_PAINT events gets translated by pugl to a PUGL_EXPOSE event. What I think happened is that you called puglEnterContext which called BeginPaint and then marked the window as "updated". This caused windows to not send a WM_PAINT event and therefor the PUGL_EXPOSE was never send to your code.

Please bear in mind the above is just a guess, I was happy to get it working and played with zynaddsubfx instead of debugging the bowels of windows.

@fundamental
Copy link
Member

How do you enter automated screenshot mode?

Personally I'm fine if automated screenshot only works on Linux. If I had the extra development sprint after the main zyn-fusion one I would have pushed to have it run on CI, but some of that required figuring out some headless OpenGL library tricks. Doable, but I've heard tales of that arcane knowledge driving some people mad.

Anyhow, take a look at the base directory of the mruby-zest-build repo. You should see user-manual-screenshots.rb . That file defines a sequence of events to run on the user interface along with delays between them. Personally I'm not entirely happy with the setup and had hoped for a better DSL, but you can feed that file into the GUI with the --script option. (e.g. zyn-fusion --script user-manual-screenshots.rb) at which point it will execute the script and return control to the user afterwards. Though in the case of the specifically mentioned screenshot script, the last command is sched.add lambda {|run| exit}, which unsurprisingly schedules the last scripted event to be the interpreter running the exit function.

The headache with the scripted mode of operation is that the GL context needed to be valid when the scripted commands ran in order to force updates and to have a valid context for capturing the pixel buffer for saving things to file. So there might be some extra commands in there to ensure that the context is valid for any time the script could run which are unnecessary for more typical operation.

Even with the sharp jagged edges, I still love the scripted mode with builtin screen capture. For documentation purposes it seems like a feature which is sorely missing from typical frameworks. Who wants to go through an application regenerating screenshots every time some minor look-and-feel issues are resolved.

@ghost
Copy link

ghost commented Oct 7, 2020

I'm able to make screenshots in windows without the extra puglEnterContext. I got 27 png files in the doc dir.

The only trouble I had running the script was when it tried to exit:

...
(eval):326: undefined method 'exit' (NoMethodError)
(eval):326: undefined method 'exit' (NoMethodError)
(eval):326: undefined method 'exit' (NoMethodError)
[FATAL ERROR] Mruby Is Unable To Continue

But to be honest, who really cares as long as the screenshots gets made.
I've issued a PR to the zest repo. If you prefer a PR to this repo where I add a patch file & do a git apply, let me know.

EDIT: Seeing that script run was awesome. :) I completely get why you want to keep that feature and its abilities to take screenshots.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants