Several bugs in Zest UI

[AnClark]

I've built another Windows version based on the mruby-zest revision 2f1a879. But I found these bugs:

• In stand-alone version, Zest will immediately freeze when I press key Q.
• In SUBFX, once I click the "OSCILLOSCOPE" button to open oscilloscope view, I will not be able to go back to "GLOBAL" panel.
• After Ioading presets, oscilloscope won't render.

[fundamental]

Some of these bugs don't appear to exist on the Linux side, so this might be 'fun'.

Per the first issue, I imagine that any key which triggers a note on has the same behavior. Likely the same goes for clicking on the virtual keyboard. Does that hold true or is it literally only 'q'? Additionally when zest freezes, is there a popup with a ruby backtrace? or perhaps the message 'connection to remote zyn lost'?

Per the second, looks like I can replicate the behavior.
Steps:

1. click on SUB on the left.
2. Click on Oscilloscope on the upper right.
3. Click on global.

Expected: view is changed to global tab.

Actual: view remains on the signal-tap/oscilloscope view.

Per issue 3 I cannot replicate, though perhaps there's a step missing on my end.

[AnClark]

Bug 4 I've discovered right now:

• When loading factory effect "FX HEAVY RAIN", connection to ZynAddSubFX will lost for a while. But other presets doesn't have this issue.

[AnClark]

Does that hold true or is it literally only 'q'? Additionally when zest freezes, is there a popup with a ruby backtrace? or perhaps the message 'connection to remote zyn lost'?

• Not only Q, but also any other keys will trigger this bug. (Even Volume Up/Down and Shift will freeze Zest.)
• Neither "connection to remote zyn lost" nor MRuby popups has shown.
• When I focus to text boxes (FX search, FX info), the cursor still blinks.

[fundamental]

Bug 4 appears to be a non-bug. The patch notes on that instrument indicate that it's slow to load. On Linux the padsynth wavetable generation is multi-threaded (I'm assuming that's where the load time is). Windows needs to have that feature implemented, but I don't consider that a bug.

[fundamental]

Bug 2 should be resolved via: f21c3da

No idea what's causing 1 at the moment and I don't have the ability to replicate issue 3.

[AnClark]

Bug 4 appears to be a non-bug. The patch notes on that instrument indicate that it's slow to load.

I just discover the note after it eventually loads.

Maybe patch notes should be shown before actually loading it's contents, or users may mistake. Besides, an indicator showing "Loading patch" is also a good choice.

---

No idea what's causing 1 at the moment.

I also find that this problem doesn't exist on VST version.

[AnClark]

Bug 2 should be resolved via: f21c3da

Just tested with this revision. Problem still exists on both Windows and Linux version.
Perhaps you need to drop this patch. It corrupts AddSynth's oscilloscope view.

[AnClark]

I've got a solution to Bug 2: #56

[fundamental]

It corrupts AddSynth's oscilloscope view.

Ah, whoops. Ok, I'll revert it as proposed later today and use the same fix in #56 to resolve getting stuck.

[AnClark]

Yet another bug 6:

• When I drag envelopes, the envelope, as well as its values, will "shiver". Just like this GIF:
  

This issue doesn't exist on 3.0.3 demo build.

[fundamental]

Bug replicated. Some commits in zynaddsubfx/zynaddsubfx were reverted. There's also some changes on the zest side, though I have to clean them up still. Current WIP diff attached.
zest-env-fix.txt

[fundamental]

Bug 6 should be resolved. I didn't commit the vector cache line debouncing from the above diff, but I don't think it's strictly necessary.

[AnClark]

Bug 6 should be resolved. I didn't commit the vector cache line debouncing from the above diff, but I don't think it's strictly necessary.

Problem still exists until today (2021/6/24 11:00 BJT, after git-pull).
Perhaps it's not so necessary, however I think it still affects user experience.

Update: Solved. I was careless that I forgot to forcibly rebuild ZynAddSubFX. Now envelopes works well.
Thanks a lot!

---

By the way, Bug 1 seems to be PUGL's issue. The same Windows build works well with Wine, only fails to work on real Windows.

---

[fundamental]

Update: Solved.

Heh, I just pushed the extra cache line debouncing before checking for edits figuring that was the only difference between my side (which it was fixed) and the public git repos. I guess if additional issues crop up because of pushing the debouncing (I don't know why I had disabled it in the past), we can just revert 26ec3c8

Per bug 1 I haven't heard of any issues within the plugin version, so I expect the differences between https://github.com/DISTRHO/DPF/blob/e0d8e14a14d407648768da7e34bcf31812245387/dgl/src/pugl/pugl_win.cpp and https://github.com/mruby-zest/mruby-zest-build/blob/master/deps/pugl/pugl/pugl_win.cpp will reveal what's wrong. I currently don't have a windows VM setup for the bug hunt, but it's just some trial and error.