search

DISTRHO / DISTRHO-Ports

Linux audio plugins and LV2 ports
http://distrho.sourceforge.net/ports
252 stars 44 forks source link

Vitalium: Window view vertically offset #68

Closed tank-trax closed 3 years ago

tank-trax commented 3 years ago

I just built the Distrho ports to try the Vitalium build

Am on Debian Buster with OpenGL 1.3

the LV2 requires 1.4 so it would not load, I am going to have to assume the VST3 won't load for the same reason.

my hope is that the community build will be as accessible to hardware and operating systems as the source that it is based on is

currently when building directly from the original source I was able to produce a very workable, very stable, CPU optimized and fully functional VST3 and Standalone

falkTX commented 3 years ago

no interest on my side on this.

linux drivers have come a long way. it is not about lacking gpu power, but lacking implementation. my laptop has a very crappy internal non-discrete GPU, but it still can do GL 4.6.

tank-trax commented 3 years ago

this is my two cents, I apologize for my tone because I am annoyed by this

these are some of my computer specs Processors: 4 × Intel® Core™ i5-3470 CPU @ 3.20GHz Memory: 11.4 GiB of RAM

this is a beast that does not need to be superseded

glxinfo | grep "OpenGL version" OpenGL version string: 3.0 Mesa 18.3.6

this computer is going to last me for a long long time and I have no intention of buying a new one for audio production

it doesn't make sense (at least to me) to make software that is inaccessible to users, or for Ubuntu 20.04 specs when for example when KXstudio and Librazik (as far as I know) are supporting OSes based on Buster

it's like people using GLIBC 2.29 to build Audio software when Buster is at ldd --version ldd (Debian GLIBC 2.28-10) 2.28

why?

I am not a developer but I build software locally... I am not going to up my computer as it stands the current open source version build and loads beautifully

why is it so difficult to stay within those parameters?

also I would have hoped that the community build would have used cmake rather than meson

I am going to continue using my personal build as it's the best version of Vital I have used

no phone home and no TTW, no annoying auth every load

just music

falkTX commented 3 years ago

your anger is understandable. your PC is surely more than capable of running this, my laptop is in comparison much worse than that. I was made aware very recently that vital has custom juce changes, which I think will make its behaviour different from this vitalium fork,

falkTX commented 3 years ago

no phone home and no TTW, no annoying auth every load

note that this vitalium fork has the same. the login options are even removed from the gui, as otherwise you would click it and have it do nothing.

to be clear: it is frustrating on my side to see how this code dump was done. there is no git history and no juce repo (just a full copy without possibility to easily see what was changed). it is a lot more work than it should be.. almost seems intentional.

tank-trax commented 3 years ago

I am not angry, frustrated a bit

your work has allowed me to understand Linux audio better than any help file or manual, once I analyzed what your suite was doing (Cadence) I was able to piece together what Alsa.org was discussing, I am forever grateful

that being said I am professionally a field tech and my role is to be between user and developer, if I as a power user am having difficulties I can't imagine people who look to me for advice are going to fare

I would like to help you in any way that I can, FYI I am involved with Surge Synth Team as oddy.o.trax ;-)

falkTX commented 3 years ago

Thanks.

For now a tip came on IRC, it seems you can export MESA_GL_VERSION_OVERRIDE=3.2 and env var and vitalium works fine. I asked Matt about publishing his custom JUCE changes, so it is easier to merge back the useful/relevant changes.

tank-trax commented 3 years ago

it builds and loads the LV2 however I have to run jalv.gtk3 or jalv gtk from command line using export MESA_GL_VERSION_OVERRIDE=3.2 as you recommended

however it has a GUI offset

also not sure how this is going to be good workflow for those wanting to load it in Ardour or Mixbus

image

resizing does not resolve it

also upon exit

JUCE Assertion failure in juce_OpenGLContext.cpp:797
tank-trax commented 3 years ago

it would be ideal if that variable could be passed prior to building, and although that export provides a workaround, it does not in my opinion provide a good workflow

I also tried to run Bitwig from the command line with that variable set and it crashed upon loading whereas when run from the command without the variable it runs without issue

taylordotfish commented 3 years ago

Responding to @falkTX's question from #69:

I wonder how @taylordotfish fork can work. @taylordotfish DId you do any changes for that?

Well, the main difference is that my fork uses the old (and custom) version of JUCE in the upstream Vital repo, but I don't see why that would make it work with OpenGL 1.3, given that it still specifies 1.4 as the minimum version.

@tank-trax I suppose you could try changing the version in this line to 1.3, and maybe it'll work, but the minimum might be set at 1.4 for a good reason.

tank-trax commented 3 years ago

I also built using the with upstream Vital repo included JUCE files with success

tank-trax commented 3 years ago

@taylordotfish I tried your hack and the same offset happens with the LV2 and both the VST2 and VST3 although they now load always crash once GUI is displayed in Bitwig and Reaper

falkTX commented 3 years ago

Are you using wayland? Someone on IRC mentioned the same problem, though they have an issue with offset in vertical space, not horizontal.

tank-trax commented 3 years ago 
inxi -Gxx | grep compositor
Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa compositor: kwin_x11
falkTX commented 3 years ago

Very odd, I have kde here too. Though my x11 server is at 1.20.9 (Ubuntu 20.04 base).

falkTX commented 3 years ago

Someone else with similar issue, but gnome as WM.

image

REIS0 commented 3 years ago

Can confirm I'm with the same issue, Gnome in Pop_OS! 20.10 image

falkTX commented 3 years ago

FYI I enabled github's "discussions" for this repo. so things that are not issues can go there now.

before anyone asks, meson is not being replaced by cmake or other system anytime soon. the build system should be mainly for the developers, and meson is the best one we got so far from what I can see. updating meson is trivial, since it is "just" a python package.

magnetophon commented 3 years ago

For me (poster of https://github.com/DISTRHO/DISTRHO-Ports/issues/69), the workaround works, and I don't have the offset problem.

aki-k commented 3 years ago

I compiled taylordotfish's Vial code on Ubuntu 18.04 and the GUI offset problem doesn't happen on that.

xard-dev commented 3 years ago

Yeah I have also the window offset problem with Vitalium build on ubuntu 20.04 with RTX 2070 (450.102.04 drivers).

The UI interaction regions are where they should be but the graphics are not in align with them which means that I need to visually miss click from the elements to activate them.

Comparison between Vital 1.0.7 and Vitalium: offset_problem

Also I think the zoom buttons have something weird going on (perhaps a separate ticket is needed for this?)

Daniele71 commented 3 years ago

GUI vertically shifted also on opensuse TW with Ardour, Carla and Reaper (LV2).

tank-trax commented 3 years ago

I am able to build VST3, Standalone with JACK support and the LV2 ... with no offsets and no OpenGL errors.

Incorporated in my fork are the @taylordotfish LV2 hack and the changes @falkTX made to remove all the phone home, authentication, log in and text-to-wave features.

To build VST3, LV2 and Standalone simply follow these steps....

git clone https://github.com/tank-trax/vital.git
cd vital
git checkout vitality+minus-1.0.6
make

This will produce the Standalone and VST3 in plugin/builds/linux_vst/ and the LV2 in plugin/builds/linux_lv2/

Presets and local store will go in the ~/.local/share/vitality+minus/ folder

I've also built it on Windows. There are two branches, one with VST2 and ASIO support and another without.

I will be uploading changes made to the JUCER to be able to build with Intel Performance Primitives rather than use JUCE shared FFT (yes for Linux)

falkTX commented 3 years ago

I was able to reproduce while using gnome and wayland. Fixed in 228c8eb37af179dba638f4052e2752a98591b57b

tank-trax commented 3 years ago

I noticed that this issue is closed and would like to confirm that the latest commit c81c63 builds successfully on Buster for Vitalium the LV2 loads in jalv.gt3 with no offset also the VST2 and VST3 are stable and load in Bitwig no OpenGL error either

thanks!!