REAPER for Linux bugs

[Glennbo]

Originally Posted by Justin

Hmm not sure what you're doing differently here, but this is also on XFCE:

Note that the first click is on the right side of the box, that triggers the menu of recents, and the second click is closer to the text where you can edit it. This is entirely implemented in libSwell so really it should be distro and DE independent...

Does the distro govern how right click menus behave? I'm using xfce on Xubuntu. When I right click the record button on tracks that are near the right edge of the screen, menus begin to display outside of the maximized REAPER container on my left monitor, and popup totally orphaned on my right monitor.

You can see what I'm talking about in this pic of my two monitors, which are not close to each other. I'm right clicking the record button of track 22, but the context sensitive menu and all it's children popup on the other monitor, which frequently is on a security cam, so I don't see the menu at all.

[Justin]

Originally Posted by Glennbo

Does the distro govern how right click menus behave? I'm using xfce on Xubuntu. When I right click the record button on tracks that are near the right edge of the screen, menus begin to display outside of the maximized REAPER container on my left monitor, and popup totally orphaned on my right monitor.

No, this is controlled in swell-menu-generic probably. I'll see if I can set up multimonitor on one of my linux machines to see if I can improve that behavior.

[Glennbo]

Originally Posted by Justin

No, this is controlled in swell-menu-generic probably. I'll see if I can set up multimonitor on one of my linux machines to see if I can improve that behavior.

Thanks! It seems to happen on any right click menu if it's near the right edge of the monitor.

[Justin]

Originally Posted by Glennbo

Thanks! It seems to happen on any right click menu if it's near the right edge of the monitor.

Ah I think I figured it out without testing -- I pushed a fix to the public WDL, you can test it out by compiling libSwell, or you can wait for 5.96rc2

[Glennbo]

Originally Posted by Justin

Ah I think I figured it out without testing -- I pushed a fix to the public WDL, you can test it out by compiling libSwell, or you can wait for 5.96rc2

Very cool, thanks!

[alextone]

Originally Posted by Justin

No, this is controlled in swell-menu-generic probably. I'll see if I can set up multimonitor on one of my linux machines to see if I can improve that behavior.

"one of my machines...."


Congratulations, you're a nerd.

Next you'll be rockin' 3 generators.

[Glennbo]

I think this one is a legitimate bug.

While preparing to add automation on a track with more than a page full of entries, I'm unable to grab the scroll bar at the bottom of the window to scroll right and see more automation entries.

I then noticed that the scroll bar was lighting up when I hovered about a quarter of an inch higher than pointing at the scroll bar, so I tried grabbing it there and it worked.

I thought it might be theme related, so I switched to the default theme, and it still exhibits the same behavior.

[Justin]

Originally Posted by Glennbo

I think this one is a legitimate bug.

While preparing to add automation on a track with more than a page full of entries, I'm unable to grab the scroll bar at the bottom of the window to scroll right and see more automation entries.

I then noticed that the scroll bar was lighting up when I hovered about a quarter of an inch higher than pointing at the scroll bar, so I tried grabbing it there and it worked.

I thought it might be theme related, so I switched to the default theme, and it still exhibits the same behavior.

Cool thanks I'll look into this!

[monty]

@Glennbo
may I ask which theme you have installed?

[Glennbo]

Originally Posted by monty

@Glennbo
may I ask which theme you have installed?

For REAPER I'm using LCS-Mod-Short-Dark.

For Xubuntu I'm using the style Adwaita-dark along with Ubuntu-Mono-Dark icons, but it doesn't have any effect on REAPER, just keeps the dark look in sync.

[Lokasenna]

Unless I'm having a brain fart, script/effect windows on Linux aren't dockable via their title bars.

[Justin]

Originally Posted by JamesPeters

It won't show up in my plugin list. I opened reaper-vstplugins64.ini and this is what I got for its entry:

Signalizer.so=005923C58FFFD201

That means that it could not load the plug-in. It might be helpful to remove that line, run REAPER from a terminal, and see if it prints any relevant output when scanning the plug-in.

I tried loading the plug-in, and on the first scan it reported:[code
swell: dlopen() failed: /home/deadbeef/.vst/sig/Signalizer.so: undefined symbol: glDrawArrays
[/code]
The cause of this is that the plug-in needs to be linked with -lGL, and was not (it assumes the host preloads GL). So, I edited reaper-vstplugins64.ini, removed that line, then ran REAPER using:

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libGL.so ./reaper

(that path may vary on your system)

and lo and behold, the plug-in works. Maybe you can email the author and see if they'll add -lGL to the link line?

Or, if you want to workaround, you could make a tiny reaper plug-in which handles preloading libGL.so. Go to ~/.config/REAPER/UserPlugins/, make a file called "reaper_glpreload.c" with this contents:

#include <dlfcn.h>
int ReaperPluginEntry(void *hInstance, void *rec)
{
  return rec && dlopen("libGL.so",RTLD_GLOBAL|RTLD_LAZY);
}

(if on debian/ubuntu, you might need to run as root:

apt-get install build-essential

)

Then run:

gcc -o reaper_glpreload.so -shared reaper_glpreload.c

[Glennbo]

Originally Posted by JamesPeters

This is using ALSA with blocksize 256 (3 buffers) and even with blocksize 512.

I tried with PulseAudio but I can't get it to do the same thing. That could be due to the fact PulseAudio has a lot more latency (even though it reports very low latency, it must have another component to the total latency that Reaper doesn't "see").

I see MUCH better performance in REAPER using Jack audio than ALSA.

With both ALSA and Jack set for 44.1k, 64 samples latency, 2 periods, and a priority of 80, my most recent project, which is a big stress test in itself, will play without artifacts using Jack, but makes sputtery sounds during playback using the same settings using ALSA. It even makes occasional pops and clicks while not playing if I stop it after getting some while playing. I'm letting REAPER start Jack with the custom command.

/usr/bin/jackd -P80 -dalsa -dhw:M2496 -r44100 -p64 -n2 -Xseq

I just re-tested to confirm and Jack will play the song without issue, where ALSA gets about a minute in and starts frazzing out.

Likely different setups and soundcards will get different results, but in my case Jack is MUCH more efficient with a pair of Delta 2496 PCI cards and a 2.66Ghz i5.

[Glennbo]

Originally Posted by JamesPeters

Isn't JACK a sound server that uses ALSA, and not an audio driver in itself? I thought I had this stuff figured out. Ugh. Information about this is so inconsistent.

I had no plans to use JACK, if it weren't an audio driver. I won't be "connecting" synths etc. to/from Reaper, so I thought I didn't need JACK.

From what I understand, Jack is just an audio sound server. From within Qjackctrl (the gui interface for Jack), I can select ALSA, PortAudio, CoreAudio, and a bunch of other "drivers" for Jack to use.

I don't know why I see very different results, but they are consistent. Maybe one honors the priority and the other doesn't, even though I have them both supposedly set identically.

[Justin]

Originally Posted by JamesPeters

Here's a new one: when using ALSA audio and realtime xruns happen, they don't "settle down" and fix themselves. The realtime xruns keep going even when the CPU settles down again (when plugins are removed/turned off/etc.) This doesn't happen in Windows.

Ah, I think I know why. The next build (tomorrow) of 5.96+dev1011 will have a change that might help this!

[Glennbo]

Originally Posted by JamesPeters

Thanks! After that I'll test it again...and then I'll ask Glennbo if he can compare ALSA to JACK too.

I wanted to switch to ALSA for the same reason as you. Less stuff in the pipeline, and initially it was only the fact that I couldn't get midi happening using ALSA, which I believe I could fix, but then once I had some demanding projects to test with, the difference in audio performance kept me from trying to fix the midi issue.

If I can get the same level of audio performance with ALSA as I get with Jack, I'll spend the time to figure out what is making ALSA think all three of my midi interfaces are in use, when they are not.

[JamesPeters]

Give the new build a test! It's working pretty great here. With ALSA I'm getting equivalent performance to my prior x64 Windows (ASIO) system (and possibly better). Realtime xruns "calm themselves down" if the CPU spikes too. (No media xruns, so no problem in general, but when the realtime xruns happened and wouldn't stop...lol...ugh...)

This is definitely better performance than in Windows 7 x64! My prior "stress test" was to load ReaPitch (default settings), as many instances as possible across a few tracks, and play audio on them. My record was 38 instances of ReaPitch without any audible dropouts. Now although I may get a few realtime xruns (dropouts) when loading all the plugins, they stop and my system is stable while running 55 instances at the same latency (same audio card, same CPU, same MB, etc.) I can adjust track settings, mute/solo, pan, etc. and it works stably. It's a really noticeable performance boost compared to Windows.

I also tested Reaper with JACK talking to ALSA. The performance is approximately the same as using JACK talking to ALSA (when using the same blocksize/numbers/samplerate). The only difference is that the output latency figure is a bit larger when using JACK.

Oh, and I'm not running a realtime kernel! lol. All I did was set the CPU frequency scaling to always be at 100% (same thing that Windows users should be doing, setting their CPU to full frequency in the "power profile" of control panel). Also I left the priority for the audio device at the default of 50. Basically this is a normal setup.

And that prior Windows x64 "stress test" was done prior to the half-assed spectre/meltdown patches (one of which did affect my system performance noticeably especially if I left Chrome open, which I also did in this test on Linux). And this version of Linux has its spectre/meltdown patches.

To be completely fair: I'm not sure if I could've made my prior Windows system perform any better because I didn't do any "hacky" tweaks to it. So maybe I could've milked it somewhat. And maybe Windows 10 would've been better.

[Glennbo]

I didn't fare as well as you. I posted a link to the result of my new test in the ALSA/JACK thread. In my test though, there are audio tracks, midi tracks, bridged Windows plugins, and native Linux plugins, so having all those additional variables might be coming into play. I am running the low latency kernel, and have elevated permissions for priority and memory.

EDIT:

Turns out on my interface, using 2 periods with JACK does not produce the same latency as 2 periods with ALSA.

2 periods with JACK = 1.4/2.9ms
2 periods with ALSA = 1.4/1.4ms

After setting ALSA for 3 periods I get 1.4/2.9 and the performance is similar to JACK.

[TonE]

It is a wine related bug of 32 bit win version. But still related to linux, so I am posting here.

It would be cool if we could dock lua scripts like hackey trackey and hackey patterns in wine in ubuntu.

[Lokasenna]

- Messages printed to the console are consistently being scrolled down so only the last four-ish lines are visible, even if there isn't actually enough content to need it scrolled.

- Context cursors keep getting "stuck" on, notably if the mouse is over something with a context cursor and then moves into a script window.

[monty]

There is a problem with my US-2400 Control Surface and the Reaper linux version ...
If i open a project with 24 tracks, then not all motorfaders will move up to the stored position or they stay at the bottom.
So I have to minimize Reaper or open another app window, then Reaper set all tracks offline and when I activate /select the Reaper window again, all faders are started up - seems it require a short offline period when starting Reaper for linux ...
the problem does not occur with WIN10, the surface is set up correctly.

[Klang]

Hi, thanks for porting reaper to linux.

A strange thing happen when i load windows vst microtonic through airwave. I create a midi item on the track with microtonic, open it, and the keyboard keys start looking really weird, see linked screenshots. Only midi items on same track as microtonic are affected.

[JamesPeters]

I just looked up what airwave is. Seems it has some bugs and the author hasn't been posting on the linux musicians forum for months. This is more likely a bug in that software and not in Reaper.

[nickstomp]

Hi

first of all I love you guys to bringing reaper to linux!!!

finally I can fully record and use linux for audio production!!!

I have only one small issue

I was trying to setup reaper to send video on an external projector to show it during live show (and maybe send some midi automation as well?)

The problem is that the video window can only fullscreen on the same screen where reaper is (I cannot go fullscreen on one monitor and see reaper on the other)

Can you help me?
Many thanks
Nick

[clepsydrae]

Perhaps a developer will have something to say about that, but generally speaking: on most linux window managers you can move windows around (even full-screen windows) using some combination of hotkeys...

The default "meta" or "super" key for most linux distros is Alt, but many of us change that to be the "Windows" key because of the numerous Alt shortcuts that that interferes with.

So, e.g. for me in Kubuntu, once a window is full screen I can Windows-left-mouse-button-drag to move the full screen window to any monitor I want and it just snaps in to place.

I haven't tested this with Reaper's video window, but it works with most full screen windows. Generally, as i understand it, the application just tells the window manager something along the lines of "make a new full screen window on screen X", and once it's there, you can move it wherever you want. It's just that the GUI elements to move full screen windows around are invisible, so you have to use the above-described tricks.

Assuming you're not on Kubuntu, google around to find out what the magic keys are for your distribution. E.g. search terms "window manager hotkey to move windows on kubuntu".

[Klang]

Is it possible to sandbox vsts in reaper linux? I saw this thread explaining how to do it in windows, but cannot find the option.

[Justin]

Originally Posted by Klang

Is it possible to sandbox vsts in reaper linux? I saw this thread explaining how to do it in windows, but cannot find the option.

Not yet, no

[reddiesel41264]

I have a few lua scripts that use gfx.showmenu. They worked perfectly on Windows but don't work on Linux Mint. When I run the action to display the menu nothing happens.

Here's a small test I wrote that doesn't work either.

gfx.init("Test", 1, 1)

gfx.x = gfx.mouse_x
gfx.y = gfx.mouse_y

input = gfx.showmenu("item1|item2|item3|item4|item5")

gfx.quit()

[Lokasenna]

Originally Posted by reddiesel41264

I have a few lua scripts that use gfx.showmenu. They worked perfectly on Windows but don't work on Linux Mint. When I run the action to display the menu nothing happens.

Here's a small test I wrote that doesn't work either.

gfx.init("Test", 1, 1)

gfx.x = gfx.mouse_x
gfx.y = gfx.mouse_y

input = gfx.showmenu("item1|item2|item3|item4|item5")

gfx.quit()

I can confirm that it doesn't work here either (Ubuntu Studio, XFCE). In fact, after a couple of tries I can't get a simple script like that to do much of anything at all.

I haven't noticed any trouble with menus in my own scripts, but that may have something to do with them having persistent windows rather than just a quick open+close. However, I tried making your test script stay open and that didn't improve the menu situation.

[Justin]

Thanks... this one is a bit tricky. If you want to go to the GDK_FOCUS_CHANGE handler in swell/swell-generic-gdk.cpp, you can try commenting out the "DestroyPopupMenus();" line, which fixes. But that might have some less than ideal side effects (menus not getting destroyed immediately when switching to other applications, perhaps?)... Give that a test and report back here.

[reddiesel41264]

Originally Posted by Justin

Thanks... this one is a bit tricky. If you want to go to the GDK_FOCUS_CHANGE handler in swell/swell-generic-gdk.cpp, you can try commenting out the "DestroyPopupMenus();" line, which fixes. But that might have some less than ideal side effects (menus not getting destroyed immediately when switching to other applications, perhaps?)... Give that a test and report back here.

Thanks for the tip. I just tested this. The result is the menu now pops up but then disappears. I also tried it with another script that has a more complex, multi-level menu, what I found was the menu would popup and disappear as before but if I'm quick I can move the cursor over one of the top level menus and the popup remains.

[Justin]

Originally Posted by reddiesel41264

Thanks for the tip. I just tested this. The result is the menu now pops up but then disappears. I also tried it with another script that has a more complex, multi-level menu, what I found was the menu would popup and disappear as before but if I'm quick I can move the cursor over one of the top level menus and the popup remains.

Does it fix if you change the code to be:

gfx.x = gfx.mouse_x-4
gfx.y = gfx.mouse_y-4

[reddiesel41264]

Originally Posted by Justin

Does it fix if you change the code to be:

gfx.x = gfx.mouse_x-4
gfx.y = gfx.mouse_y-4

Unfortunately not. I tried all the way to -25.

[Justin]

Ah I hadn't tried assigning it to a toolbar button, maybe it's getting the tail end of the mouseup or something. looking into it.

Edit: pushed another fix to WDL, try that!

[reddiesel41264]

Originally Posted by Justin

Ah I hadn't tried assigning it to a toolbar button, maybe it's getting the tail end of the mouseup or something. looking into it.

Edit: pushed another fix to WDL, try that!

That seems to have fixed it! Thank you!

[Justin]

It's a bit of a hack but hopefully good enough!

[lilith93]

I don't know if this is a new issue. Yesterday I realized that the GUI is a little bit glitchy (vertical black lines in the items) sometimes when moving items very fast, also in the midi editor when e.g. scrolling. The playhead when zoomed in also looks glitchy. It's not a big issue and I prefer stable audio compared to stable graphics. Acutally I cannot screenshot it. Just wonder if anybody else observed that. I'm using V5.961.

edit: I think it's a problem of my system in general. Never realized it.

[JamesPeters]

Are you running a compositor? I had to enable Compton and also switch to the Intel driver from the default "modsetting" driver, to resolve some screen tear issues and also "glitchy looking stuff" when quickly moving a window around on the screen (or scrolling quickly in a browser).

[lilith93]

Originally Posted by JamesPeters

Are you running a compositor? I had to enable Compton and also switch to the Intel driver from the default "modsetting" driver, to resolve some screen tear issues and also "glitchy looking stuff" when quickly moving a window around on the screen (or scrolling quickly in a browser).

That's a good point !! My Desktop freezed 3 weeks ago and I deactivated the compositor in the XFCE. I check tomorrow if it's better with it.Really strange that I realized it yesterday for the first time. Thanks!

[lilith93]

Originally Posted by lilith93

That's a good point !! My Desktop freezed 3 weeks ago and I deactivated the compositor in the XFCE. I check tomorrow if it's better with it.Really strange that I realized it yesterday for the first time. Thanks!

That was exactly the reason! When I activate composite again it looks much better.