UI bugs in my homebrew ZynAddSubFX 3.0.6 #33
Comments
That's an old bug, I guess the fix (a windows only padding constant) must have been overwritten at some point
I still have to look into that one, I'm guessing it's just a widget layout bug with the MRuby 3.0 update
Resolved locally (I think). Still have to push that commit
I'm not 100% sure what you mean
I'm not 100% sure there's a way around this one. AFAIK the host regulates how often the plugin is given a chance to do UI processing. |
Here's a brief example:
By the way, would you love to have a check with my Pull Request? |
|
@fundamental And another bug I found just now: When choosing any file-browser-related items (e.g. "Load / Save Instruments") in Zyn-Fusion's menu, the window becomes black. But when click that black window, it will go back to the last screen. This issue doesn't exist in Would you love to take a look at it?
|
Found, replicated, and fixed locally. I'll try to send out a note when I push the changes. |
|
Thanks a lot! Waiting for your updates. |
|
And would you love to check my pull request #32 for fixing build issues on Windows? |
|
Ok, a few of the fixes have been pushed to the mruby-zest repo. Keep in mind the submodule version in mruby-zest-build has not been updated as well (I'm thinking for next release to just eliminate the submodules in the src/ folder since IMO all they've done is increase the complexity of development. submodules for deps/ still seems to make sense though. Per the PR I tend to work on Zyn programming/issues/etc in larger chunks of time. Right now I've got ~19 emails related to zyn which need some level of response (my primary workflow is to leave stuff in my inbox until it's at least somewhat addressed). I'll have a block of time tomorrow, but there's a chance that I won't have the PR merged until the weekend. |
|
Great! After replacing |
|
What about a solution to UI displace?
Looking around through my older folders I'm not seeing the fix.
Comparing pugl_win.cpp with DPF's pugl_win.cpp
( https://github.com/DISTRHO/DPF/blob/master/dgl/src/pugl/pugl_win.cpp )
I can note that one difference is the window size event corresponding to
the window size on our end and the client paintable area on DPF's side.
I'm not sure that's the only difference, but there's a chance that it
might be the source of the offset.
The following diff is what I was looking at, but testing is needed to
validate this approach and I'm guessing some more hacking is needed.
I'll pause investigating this for the moment to address other
issues/PRs.
diff --git a/pugl/pugl_win.cpp b/pugl/pugl_win.cpp
index 83d4474..d63252b 100644
--- a/pugl/pugl_win.cpp
+++ b/pugl/pugl_win.cpp
@@ -470,12 +470,12 @@ handleMessage(PuglView* view, UINT message, WPARAM wParam, LPARAM lParam)
case WM_CREATE:
case WM_SHOWWINDOW:
case WM_SIZE:
- GetWindowRect(view->impl->hwnd, &rect);
+ GetClientRect(view->impl->hwnd, &rect);
event.configure.type = PUGL_CONFIGURE;
event.configure.x = rect.left;
event.configure.y = rect.top;
- view->width = rect.right - rect.left;
- view->height = rect.bottom - rect.top;
+ view->width = rect.right;
+ view->height = rect.bottom;
event.configure.width = view->width;
event.configure.height = view->height;
break;
|
|
OK, thanks a lot. |
This patch works. Now UI displace has been resolved. diff --git a/pugl/pugl_win.cpp b/pugl/pugl_win.cpp
index 83d4474..5333375 100644
--- a/pugl/pugl_win.cpp
+++ b/pugl/pugl_win.cpp
@@ -470,12 +470,12 @@ handleMessage(PuglView* view, UINT message, WPARAM wParam, LPARAM lParam)
case WM_CREATE:
case WM_SHOWWINDOW:
case WM_SIZE:
- GetWindowRect(view->impl->hwnd, &rect);
+ GetClientRect(view->impl->hwnd, &rect);
event.configure.type = PUGL_CONFIGURE;
event.configure.x = rect.left;
event.configure.y = rect.top;
- view->width = rect.right - rect.left;
- view->height = rect.bottom - rect.top;
+ view->width = rect.right;
+ view->height = rect.bottom;
event.configure.width = view->width;
event.configure.height = view->height;
break;
|
|
Thanks a ton for verifying the fix in pugl_win.cpp. I'll have that updated later today and I'll carve out some blocks of time tomorrow to address some of the sanity checks in docker. Then I should be able to resolve a few of your contributions. It's great to see all the positive interest in improving the builds :) |
|
My pleasure! I'm fond of ZynAddSubFX so much, and I'd love to continue making contributions. |
|
Hello, same for me on openSUSE Tumbleweed (rolling distro). This is what the settings window looks like (version from this repo's master branch + zyn 3.0.5):
Also, in the same window, + and - do nothing. In the Browser window, overwriting preset names does not update them automatically. You have to select another bank and then go back to the one you modified to see the updated preset names. |
@fpesari So it is with me. This is also an issue to be resolved, but I'm not familiar with MRuby, and I cannot find the related codes.
Yes, it's another bug. But currently there's no need to use this setting windows if you are using a DAW. |
|
The settings window never really got fleshed out. The code is https://github.com/mruby-zest/mruby-zest-build/blob/master/src/mruby-zest/example/ZynSettings.qml |
|
@fundamental Maybe comparing with the settings window, this issue needs help:
So it is with preset's comments. For example, I choose a preset with a comment, but it doesn't load in the comment box (on the right of preset browser). But when I switch to another page and switch back to preset browser, the comment can eventually load. |
|
On 05-21, AnClark Liu wrote:
@fundamental Maybe comparing with the settings window, this issue needs help:
> In the Browser window, overwriting preset names does not update them automatically. You have to select another bank and then go back to the one you modified to see the updated preset names.
So it is with preset's comments.
For example, I choose a preset with a comment, but it doesn't load in the comment box (on the right of preset browser). But when I switch to another page and switch back to preset browser, the comment can eventually load.
Strange. I can't replicate. Perhaps this is something which is fixed in
my copy, but was buggy in a prior version?
I know recently some changes were merged for the textbox widget which is
used to load those comments, but I wouldn't have thought it would impact
the described behavior
|
Is this bug exist in your current copy? If it's OK, I think that change can be merged into online repo. |
|
Looks like my current setup is a fairly vanilla 8bca22b2ed4e29f8edd56097ebb77ccfe9e434eb based copy without much in the way of local changes. Usually that means I'm just doing something slightly differently. At least in my experience in the past 95% of the time failing to replicate if two people are on the same version is me doing something slightly different and 5% is system to system differences. Usually to resolve those 95% of cases I resort to the very pedantic formula of: Almost always it feels unnecessarily pedantic, but it does do a good job at eliminating ambiguities. |
Yesterday (1/19/2020 Beijing Time), I successfully built my own ZynAddSubFX, for both Windows and Linux. But there are some bugs which occurs in both builds:
1. [Windows only] Standalone version: UI displace
2. Browser: Cannot preview preset information (circled area)
3. Effects/Part Insersion: Cannot show effect controller
4. Effects/System:
5. Presets: When reloading my DAW project, it doesn't locate to the preset name in browser.
Other VST instuments will automatically indicate the preset name in their preset pickers.
6. VST version's UI is much slower than standalone version.
VST UI has lags and much lower framerates. But it's extremely fluent in standalone version. Both Linux and Windows builds have this issue.
The text was updated successfully, but these errors were encountered: