file open crash in Reaper Linux

[caseybasichis]

System: Linux Mint 19 cinnamon, latest Reaper.

Error: xxx vstrack_plugin: effEditGetRect: (0; 0; 820; 1272) lglw:loc_eventProc: xev ButtonPress lglw:loc_eventProc: xev ButtonRelease xxx osdialog_file: 1

(reaper:13841): GLib-GObject-WARNING **: 11:16:34.131: cannot register existing type 'GdkWindow'

(reaper:13841): GLib-GObject-CRITICAL **: 11:16:34.132: g_param_spec_object: assertion 'g_type_is_a (object_type, G_TYPE_OBJECT)' failed

(reaper:13841): GLib-GObject-CRITICAL **: 11:16:34.132: validate_pspec_to_install: assertion 'G_IS_PARAM_SPEC (pspec)' failed xxx osdialog_file: 2 xxx osdialog_file: 3 xxx osdialog_file: 4 xxx osdialog_file: 5 xxx osdialog_file: 6 xxx osdialog_file: 7

(reaper:13841): GLib-GObject-WARNING **: 11:16:34.285: cannot register existing type 'GdkScreen'

(reaper:13841): GLib-CRITICAL **: 11:16:34.285: g_once_init_leave: assertion 'result != 0' failed

(reaper:13841): Gdk-CRITICAL **: 11:16:34.285: IA__gdk_screen_get_default_colormap: assertion 'GDK_IS_SCREEN (screen)' failed

(reaper:13841): Gdk-CRITICAL **: 11:16:34.285: IA__gdk_colormap_get_visual: assertion 'GDK_IS_COLORMAP (colormap)' failed

======================================================= EDIT:

Note: instantiating modules, connecting wires, turning knobs etc all work. Only the file dialog seems to be a problem.

My use case is weird. I'm writing the rpp directly.

I would use the open dialog to load a patch once. Save the rpp and then analyze the chunk to figure out how to replace the path. From that point on I don't need the dialog.

Is the path easy to get to in the decoded chunk? Do you have an rpp that you could send?

Also, thank you so much for this project! The standalone didn't work for my use case and I was eating my heart out: https://github.com/VCVRack/Rack/issues/924

[cameronleger]

Can you post your GTK and GLib version? Did you use the released binary or build it yourself? Also, if VCVRack works, did you use a release of that or build it yourself?

[caseybasichis]

Downloaded binaries of both. The file dialog works in VCVRack.

ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27 GTK 3.22.30 no gtk+ 2 or 1 found

[cameronleger]

Is it possible for you to build it for yourself? You'll probably need to find and download the necessary VST2 headers, which as of recently have been removed from their source (!), and tweak setenv_linux.sh for the directory locations. Assuming you have the dependencies, first run . /setenv_linux.sh (note the dot and space at the beginning) then a make -f makefile.linux vst should work after that. Unfortunately, that's not the easiest build, so perhaps I can look into providing a build for your setup later.

I think that the owner built the release from a VM with XFCE, so I'm assuming that there's a GTK and/or GLib mismatch that would cause this. Even though my machine has parts of XFCE and a mix of GTK2 and GTK3, my own builds show the dialog in GTK2. I have a feeling that a local build for you would fix this (by using GTK3), or perhaps installing libraries that ldd cannot find, like GTK2. For example, here's some of the related lines for my ldd:

libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0
libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0
libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0

Notice how they're referencing the GTK2 versions of the libraries, even though I have both installed:

local/gtk2 2.24.32-1
local/gtk3 3.24.1+8+g220f77d8c1-1

[caseybasichis]

I tried the GTK2.0 path -- no such luck.

I'm about to embark on the build process.

Would you able to test 'open' on the latest linux Reaper, in case it's Reaper specific? My build backstory is a black cloud of thunderstruck nights -- maniacal laughter and thrashing corpses.

This is the build I'm using: https://www.landoleet.org/reaper5963+dev1128_linux_x86_64.tar.xz

xxx vstrack_plugin: effEditGetRect: (0; 0; 820; 1272)
lglw:loc_eventProc: xev ButtonPress
lglw:loc_eventProc: xev ButtonRelease
xxx osdialog_file: 1

(reaper:29549): GLib-GObject-WARNING **: 16:59:56.396: cannot register existing type 'GdkWindow'

(reaper:29549): GLib-GObject-CRITICAL **: 16:59:56.396: g_param_spec_object: assertion 'g_type_is_a (object_type, G_TYPE_OBJECT)' failed

(reaper:29549): GLib-GObject-CRITICAL **: 16:59:56.396: validate_pspec_to_install: assertion 'G_IS_PARAM_SPEC (pspec)' failed
xxx osdialog_file: 2
xxx osdialog_file: 3
xxx osdialog_file: 4
xxx osdialog_file: 5
xxx osdialog_file: 6
xxx osdialog_file: 7

(reaper:29549): GLib-GObject-WARNING **: 16:59:56.533: cannot register existing type 'GdkScreen'

(reaper:29549): GLib-CRITICAL **: 16:59:56.533: g_once_init_leave: assertion 'result != 0' failed

(reaper:29549): Gdk-CRITICAL **: 16:59:56.533: IA__gdk_screen_get_default_colormap: assertion 'GDK_IS_SCREEN (screen)' failed

(reaper:29549): Gdk-CRITICAL **: 16:59:56.533: IA__gdk_colormap_get_visual: assertion 'GDK_IS_COLORMAP (colormap)' failed

[cameronleger]

Hm, now I doubt the local build will fix this as I see the same thing on Reaper.

(reaper:15290): GLib-GObject-WARNING **: 20:22:28.808: cannot register existing type 'GdkWindow'
(reaper:15290): GLib-GObject-CRITICAL **: 20:22:28.808: g_param_spec_object: assertion 'g_type_is_a (object_type, G_TYPE_OBJECT)' failed
(reaper:15290): GLib-GObject-CRITICAL **: 20:22:28.808: validate_pspec_to_install: assertion 'G_IS_PARAM_SPEC (pspec)' failed
(reaper:15290): GLib-GObject-WARNING **: 20:22:28.850: cannot register existing type 'GdkScreen'
(reaper:15290): GLib-CRITICAL **: 20:22:28.850: g_once_init_leave: assertion 'result != 0' failed
(reaper:15290): Gdk-CRITICAL **: 20:22:28.850: IA__gdk_screen_get_default_colormap: assertion 'GDK_IS_SCREEN (screen)' failed
(reaper:15290): Gdk-CRITICAL **: 20:22:28.850: IA__gdk_colormap_get_visual: assertion 'GDK_IS_COLORMAP (colormap)' failed

Note that it happens with any GTK dialogs, for example the New button which would prompt about clearing the current patch.

Based on the GUI, I wouldn't think Reaper is using GTK. Using different versions of GTK within the same process would surely cause issues. I checked reaper and its included libraries and didn't see it linked to GTK. Perhaps there's something interesting about its sandboxing that causes this.

Considering this same build works on Bitwig, Ardour, and Renoise, it's looking like a Reaper-specific issue. AFAIK, the GTK dialog portion of this repo is as-is from the original VCV Rack code. I tried the U-he plugins since they do something interesting with the dialogs: they put them into their own executable that the plugin calls in a separate process when necessary. These of course do not crash.

[caseybasichis]

I posted on the Reaper forum, maybe someone will have an idea.

How about the chunk data aspect? Is the vsv patch json being base64 encoded and packed into the chunk?

[cameronleger]

I don't fully understand what you're trying to do there, but I didn't try as it seemed like a workaround to fixing the GTK issue. The VST chunk data is the JSON patch; I don't think it's base64 encoded (Reaper does that).

[caseybasichis]

Thanks! The default json saved with the project and a fresh rpp looks like its enough to work with, even if all else fails.

[falkTX]

The issue here is quite clear to me, as we had to deal with this several times in Linux hosts and system toolkits. Reaper on Linux uses GDK3 for handling Windows and events. The file dialog used in VCVRack uses GTK2 (and thus GDK2), which leads to symbol clashes among other nasty things.

We (linux audio devs) keep repeating this message to plugin developers: do not use big system libraries or frameworks in plugins, make them self-contained!

A hacky fix to make this work under Reaper would be to use GTK3 on the file dialog, but then you will break hosts that use GTK2 like Ardour.

The only solution is to stop using GTK (or Qt, FLTK and similar) for plugin UIs. If you need a file dialog, consider using this project https://github.com/x42/sofd, or perhaps roll your own.

[bsp2]

Keep in mind that this project is based on VCV Rack, so it inherits certain design decisions / implementations.

Cameron and I already swapped out GLFW for something more lightweight (and less problematic for use in a plugin library).

I don't think that re-inventing something basic as a file dialog would be a good idea.

The plan was to use Zenity for GTK based dialogs (via popen()) (also see here).

It simply hasn't been implemented it, yet. Maybe I'll write a little C wrapper for it next weekend.

[bsp2]

done (replaced osdialog_gtk2 with osdialog_zenity)

[maxxatgit]

Greetings!

First, Many thanks to the devs: bsp2, cameronleger, and falkTX (I know falkTX is not a "dev" for this project, but I use many of his KXStudio ports). Thanks you so much for supporting Linux!

I just wanted to report that this fine project works well on Reaper v6.13 on Ubuntu 19.10. I have not tested everything (that will take a very long time), but it loads, plays and saves patches perfectly.

Also, while testing the Wide Stereo Lead patch, I connected the output of the LFO-1 to the FM inputs of both VCO-1s. I then saved and reloaded the modified patch. Using Reaper's parameter assign function, I was able to assign the mod wheel (MIDI input) to the FM-CV inputs of both VCO-1s to produce an intense mod wheel vibrato. I also assigned MIDI pitch bend to both VCO-1's FREQ input to do pitch bend.

I then saved this configuration as a Reaper "FX chain". I successfully reloaded the modified VCV preset and the Reaper pitch bend and mod wheel assignments. So presets can be edited, saved and recalled, and Reaper parameter routings can be configured, saved and recalled. Using Reaper's parameter routing, I should be able to assign any knob, fader or switch whose value I can change in the GUI, to a MIDI CC.

This is first day testing... I downloaded and installed this amazing software 2 or 3 hours ago. So far, it's amazing!

I love the simple install; expand the zip file, and put the folder in the .vst folder. Patches and everything are right there, no digging around in /usr/share where you need sudo privileges...

The sound is amazing! I could spend days and weeks modifying the presets.

Many, many thanks to everyone involved!