Yes and yes, I use the proprietary drivers and yabridge. I could probably test nouveau, but not right now. Even if that could fix the issue, it won’t be a good solution as it is highly recommended to stick with the proprietary drivers for a number of reasons. I’m not giving up a major chunk of performance for this one plugin. I will also try the Windows version with yabridge tomorrow.
1 Like
I had another idea, what about trying a live distro of your operating system on USB and see if reaper runs in one, and if so, would vital function properly? the purpose would be to determine if it’s a hardware conflict or a settings one.
I realize it can reach a point where it feels like a waste of time, but I remain curious what could be the impediment to Vital working on your Linux setup.
Especially curious are the lack of any useful log messages before Reaper gives up the ghost.
1 Like
That’s a good idea, I’ve actually been trying Arch on a VM recently so if I get around to it I’ll try a fresh Reaper setup there. Also I can confirm that using the Windows VST3 through yabridge doesn’t cause any crashes.
I’m not really discouraged by the lack of speed in getting this fixed, I’ve learned to be patient and understand that most open source projects are the work of volunteers who spend their free time on stuff like this and for that I am grateful. I actually feel more privileged for doing my part in making my favorite software even better.
EDIT: Also would like to mention that it seems to me like the Windows version through yabridge can read the settings from a project where the Linux version was used pretty much without problem, so that means you can use the Windows version as a temporary drop-in replacement for now. Seems like the plugins settings carry over both ways (so also from Win to Linux) but I can’t guarantee that this will work without issue, so save the project as a separate file if you do this.
1 Like
That’s good to hear that the Yabridged Vital is a good “patch” for now.
Do follow up if there’s anything interesting on the VM.
It seems Vital doesn’t like the VM as it complains about not having OpenGL above 1.4 (says supported version is 0) although OpenGL is very much working with glxgears. I do get sound but there is no interface. It seems to be using version 2.1 which is above the 1.4 threshold but maybe I am missing something? I’m going to try a different distro and will see if anything improves. I’m using VirtualBox 6.1.26 with Arch Linux, will probably try Pop_OS or another similar distro.
Here’s the output of glxgears | grep OpenGL if that helps:
OpenGL renderer string: SVGA3D; build: RELEASE; LLVM;
OpenGL version string: 2.1 Mesa 21.2.4
OpenGL shading language version string: 1.20
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 21.2.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:
all you need to do is spoof your version string. i put the command in one of my posts here.
this was for my setup, so change as needed. As I recall it’s not good practice to override the setting in general, only when you need to.
MESA_GL_VERSION_OVERRIDE=4.5 wine ‘/home/username/.wine/drive_c/Program Files/REAPER (x64)/reaper.exe’
1 Like
Sadly that didn’t work, it now says that the supported version is 1.2 when spoofing but still doesn’t show anything.
Could it be that the version is actually referring to the GLSL version? If so, then it would make sense that it would list 1.2 as that is the actually supported version of GLSL on the VM as can be seen in my previous post.
If that’s the case, then I don’t think it is possible to run Vital in a VirtualBox VM as the maximum OpenGL version supported is 2.1/GLSL 1.2, Vital then seemingly needing a minimum of OpenGL 3.1/GLSL 1.4 (that is if my theory is correct).
I will probably try a KVM tomorrow or the next week but that might have the same problem as I can already see from a few quick searches.
1 Like
argh that is a bummer. so VM is a no-go.
Did you try another DAW instead of Reaper to try and load up Vital linux native vst3i and lv2i?
If you have a USB stick handy, install Ventoy on it and simply drop an Ubuntu Studio .iso on it. Boot with it. I just did that and ran Reaper portably, downloaded the Vital linux binaries, pointed the vst directory in Reaper to the Download folder of the Live USB, and Vital does scan and load up in Portable reaper, in Ubuntu Studio LiveUSB using open source drivers at the Ubuntu Studio GRUB prompt.
If it works for you, then it may begin to point toward Linux distro questions.
I tried the same thing with Manjaro XFCE and Vital would not pass the scanning phase in Reaper. I imagine I\d have the same trouble with Manjaro KDE live. Is it an arch thing, who knows but Arch is advertised as being more stripped down and more things need to be configured by the user.
I’m having the same problem with Vital / Vitalium under Ubuntustudio 20.04 with Reaper.
Opening the Vtial GUI the second time makes Reaper crash:
:~/opt/REAPER$ ./reaper
jack: created client
jack: setting TIME_CRITICAL = 4
jack: activated client
Speicherzugriffsfehler
Running Vital as separate process does not help. It was never working for me.
Graphics:
Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics
driver: i915 v: kernel
Display: x11 server: X.Org 1.20.11 driver: modesetting
unloaded: fbdev,vesa resolution: 1920x1080~60Hz
OpenGL: renderer: Mesa DRI Intel HD Graphics 4600 (HSW GT2)
v: 4.5 Mesa 21.0.3
oops, messed up my post
I tried all of them. With native only it crashes also.
The VST3 version seems to be more stable (didn’t crash yet), but as soon I load the normal version it crashes.
are you using the linux zip or the linux deb?
i don’t know if there’s a difference between them but if you’re using one, try the other?
2 Likes
Thanks… will check it
I unzipped the zip and copied the Vital.vst3 directory in my ~/.vst3 folder and the vital.so file into my ~/.vst folder.
After short testing the vst3 version seems to be stable, but the vst makes reaper crash after opening the gui several times:
reaper
jack: created client
jack: setting TIME_CRITICAL = 4
jack: activated client
setNumInputs ( 0 );
setNumOutputs ( 2 );
allocateArrangement ( &plugInput, 2 );
allocateArrangement ( &plugOutput, 2 );
HostPlaying changed: inQuarter: 46.037333, lastQuarter 0.000000 currentQuarter 0.000000
Speicherzugriffsfehler
Same happens in Bitwig. In contrast to Reaper the GUI (e.g. adjusting envelopes) is much smoother in Bitwig than in Reaper. In Reaper it feels a bit sluggish
1 Like
For me the plugin has been otherwise smooth on Reaper, just the crashing is bothersome.
1 Like
I noticed just yesterday that some of the gui controls in Vital were sluggish. but not before yesterday which is weird.
There’s .deb builds of Vitalium (the Vital fork) here: https://kx.studio/Repositories:Plugins
If you don’t have debian, the .deb can be unzipped. In case you wanted to experiment, the LV2i is supposedly working better for some users than Vital’s. Case by case of course.
1 Like
I am having regular crashes with vital.
I am getting regular segmentation faults in the following setup:
- Arch Linux
- Reaper 6.42
- Vital 1.08 (VST3i)
When i have about 6 Tracks of vital and just hit the play button it crashes with a segmentation fault.
Weirdly it crashes more likely when I start sending Midi events to channels with higher numbers.
I am having regular crashes with vital.
Ok, looks like it was a bug in geonkick. After patching it everything run stable so far.
Vital is really awesome. Loving it!