Building on Linux

[tank-trax]

I am using Linux Mint 21.1 and managed to compile binaries but there were issues getting them to work

the build directory has four incorrectly named binaries created and designated as executable rather than as shared libraries

the folders

infernal-synth/build/Release/InfernalSynth/Generic/InfernalSynth.vst3/Contents/
infernal-synth/build/Release/InfernalSynth/Generic/InfernalSynth.vst3/Contents/

have Resources/Presets and Resources/UI sub-folders

but are missing the x86_64-linux folder and subsequently the file named InfernalSynth.so
same for all other builds, Debug and Versioned

my steps were get hiir-1.40, compile VST3SDK, then adjust the folder paths as per the make_linux.sh script

unfortunately not entirely successful
would you have any insights as to where it went awry?

[sjoerdvankreel]

Linux is not an officially supported target at the moment, only windows. However as you noticed I do regularly compile under ubuntu+gcc just to make sure it builds and have the benefit of multiple compiler compatibility. Never actually run the binaries under linux though, didn't fully match the build scripts to the windows version etc. Both VST3 and HIIR support Linux so in theory it shouldn't be too difficult to make infernal run under linux. It's gonna be a bit of work but i would like to work with you on this, let me know if you're interested.

[tank-trax]

Yes, I am interested.

[sjoerdvankreel]

Come to think of it, it may be as simple as replacing x86_64-win by x86_64-linux in the CMake file. Don't have the time to try out myself right now, will check on it in a couple days.

[tank-trax]

thanks for the hint.... I will try that and report back, all clues are welcome

[sjoerdvankreel]

This turns out to be more involved than I hoped for. See branch "linux-build" commit message "take 4" for something that partially works. That branch is a dog-slow debug build of the instrument version only. Does NOT work in reaper, but it actually loads and produces sound in Ardour (cpu usage 100% of course). Can't open the GUI though, freaks out on xcb_aux_get_screen. Probably need to link in some additional libraries. And even if it was to open you cannot load presets via the context menu because of some #IF WIN32 in the menu code. But hey, at least it makes a noise on linux :) To be continued.

[tank-trax]

I hadn't gotten that far yet. Have you considered using JUCE framework?

[sjoerdvankreel]

I had when I started the project. Decided against it b/c the whole thing was meant to be a learning experience, being my first plugin after all. Not sure if I made the right choice in hindsight. OTOH, I already split out the entire UI stuff on another branch and as VSTGUI can be used with other API's than VST3 (say CLAP) AND provided I get the linux builds to run (probably will), I'm not sure what extras JUCE would bring to the table besided mac support. But I wouldnt use that anyway since I dont have the hardware to test on. The VST3 glue code is real thin and I'd actually like to get a feel for what CLAP is all about once I have some spare time.

[tank-trax]

It's interesting that you mention clap. I am a member of Surge Synth Team. I have mostly been involved on the technical side as a Linux tester and participate in many brain storming sessions. Our main developer is deeply involved with clap. As an aside, Surge was migrated from vstgui to JUCE. I can't speak for them but they tend to be helpful. If you'd like to visit our Discord I can drop you an invite. Perhaps we can be of assistance for your project.

[tank-trax]

tried building your branch and it fails at the end

[ 97%] Linking CXX shared library InfernalSynth/Generic/InfernalSynth.vst3/Contents/x86_64-linux/InfernalSynth.so
c++: error: unrecognized command-line option ‘--cflags’
c++: error: unrecognized command-line option ‘--libs’; did you mean ‘--libs=’?

however pkg-config --cflags --libs glib-2.0 pangocairo

returns

-pthread -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lcairo

[sjoerdvankreel]

Gcc chokes on -pthread at the beginning of pkg-config output. Apparently that's a known problem. If you checkout commit id c7dfdf3 you should be able to build, albeit without a working gui. Haven't got the gui to work myself either yet. There's a whole bunch of stuff you need to install, see https://steinbergmedia.github.io/vst3_doc/vstgui/html/page_setup.html. What seems to work is replacing "gcc pkg-config --cflags --libs x11 x11-xcb xcb-util xcb-cursor bla bla with the actual output of pk-config so "gcc -Iblah1 -Iblah2 -llib1 -llib2 etc" in the cmake file, but with -pthread removed.

[sjoerdvankreel]

Thanks for the discord invite, should be interesting to see what's going on there. Perhaps unsurprisingly I have looked at surge synth many times, playing around with it's gui and matching basic oscillators by-ear (and spectrum visualizer) between infernal and surge. In fact surge is what led me to put in the "mix-oscillator" in the first place. For obvious reasons I never took a look at surge's source code though.

About clap, I know surge to be one of the early adopters (together with bitwig i think?). What I'm really hoping to get out of clap eventually is to be able to do per-voice automation. There's a bunch of butt-ugly code in infernal that basically says, whenever a midi-on and an automation event come in at the exact same sample position, the new automation applies only to the new voice(s) while the previous voice(s) continue to run on the old values. Would be so much better if polyphony was an integral part of the plugin api. Not sure if clap can provide that, but from what i've read so far, i think it can.

Perhaps we can be of assistance for your project
I would like that. And who knows, maybe the other way around, too.

[tank-trax]

thanks for pointing out that Steinberg page, I was missing libx11-xcb-dev

I noticed an update on the linux branch
commit b76a8dc (HEAD -> linux-build, origin/linux-build)
and it built Debug without a hitch, however in Bitwig this error

com.bitwig.flt.library.metadata.reader.exception.CouldNotReadMetadataException: 
could not read metadata: 
Failed to load VST 3 plug-in /home/studio/.vst3/InfernalSynth.vst3: 
/home/studio/.vst3/InfernalSynth.vst3/Contents/x86_64-linux/InfernalSynth.so: 
undefined symbol: pango_layout_set_text

Release gives this error (again in Bitwig)

com.bitwig.flt.library.metadata.reader.exception.CouldNotReadMetadataException: 
could not read metadata: 
Failed to load VST 3 plug-in /home/studio/.vst3/InfernalSynth.vst3: 
/home/studio/.vst3/InfernalSynth.vst3/Contents/x86_64-linux/InfernalSynth.so: 
undefined symbol: pango_font_get_metrics

[sjoerdvankreel]

Same here, mine freaks out on pango_font_metric_get_height. Not only infernal, also the built-in vst3 demos (note expression synth). Got all the recommended packages installed, wonder what's the missing link.

EDIT:
Gets even more interesting. As of the latest commit "take #9" infernal can now load in both reaper and ardour, but crashes both hosts (presumably both of them with an undefined symbol error, but only ardour reports something) when opening the gui. Even weirder, reaper CAN actually load the gui's of the built-in vst3 sdk plugins (again, noteexpressionsynth etc), but ardour chokes on them, again with the same missing symbols from pango.

[tank-trax]

I was able to load the VST3 examples (I only tried the Release versions), except for one... that being said will rebuild the VST3 Debug and Release and try the latest commit soon

I don't have Ardour but I do have Mixbus 7 which is based on Ardour, will see if I get the same

[sjoerdvankreel]

Appears I was focusing on Ardour only. Vst3 example's "NoteExpressionSynthWithUI" loads AND displays ui just fine in bitwig and reaper. It will load, but crash on UI (pango stuff) in Ardour, though. Might still be a clue, but I'm getting tired of figuring out why Steinberg's stuff breaks in Ardour only and rather focus on why infernal breaks (on UI) in all 3 hosts :) BTW, by now I am actually able to load infernal in bitwig. And it renders sound, too. Seems I've gone totally wrong with the UI, somewhere. Rather difficult to find out though when everything compiles and links no warnings, then core dumps.

[tank-trax]

Debug loads with a black screen in Reaper and Bitwig, Release crashes both upon load although is recognized

I can load NoteExpressionSynthWithUI (with GUI) Release without issue, it plays notes too, doesn't crash

this is what Infernal Debug looks like

here's a close up of it in action, Open UI Editor crashes the plugin but not the host

infernal-2023-03-28_15.56.46.mp4

[sjoerdvankreel]

Jup, Steinberg stuff is fine in bitwig. Got infernal to make a noise in bitwig too, now, along with reaper. Still no luck in ardour, but since vst-demo's also don't work there i'm not too worried about it. Both bitwig and reaper crash on the ui, though. Are you able to get any sound out of infernal in either reaper or bitwig?

[tank-trax]

it absolutely makes sound in Bitwig and the controls appear to work in the generic GUI, sounds nice too ;-)
the issue appears to be with VSTGUI but I could be wrong
VSTGUI being difficult is one reason Surge moved to JUCE

[sjoerdvankreel]

Thanks. And yeah, I'm starting to see that now, too. Switching ui framework isn't a small task, though, so i'd rather just get it working.

[sjoerdvankreel]

Finally got a working release build in both bitwig and reaper. Context menu works, nested dropdowns (CV output) are usable but jump around a bit. Unfortunately it relies on a 2-year old bugfix in vstgui that somehow still hasn't made it into the steinberg repo.
In fact it's something you've already seen before: ryukau/VSTPlugins#3. Basically you have to edit cairocontext.cpp from the vstgui source and implement fixes 1 and 2 as described here: steinbergmedia/vstgui#126. How this still hasnt made it into stable release is beyond me.

[tank-trax]

OMG I totally remember that now. The black screen I was encountering did harken me back to when VST3 was new in Linux but I did not make the connection. Memories. It is kind of sad that Steinberg still hasn't been applied the fix yet.

[tank-trax]

this is Release in Bitwig. GUI is a tad slow to respond to mouse gestures. It reminds me of the early iterations of Surge. Especially the menus. That being said it plays nice. Hasn't crashed. There's a slight delay to repaint the GUI when closed and opened but apart that from looks to be functional.

[sjoerdvankreel]

Well, it appears I've got some thinking to do about how to proceed with this. Especially since a full rewrite of the ui is already on the agenda. I want to move away from vstgui's declarative format (.uidesc) into a fully programmatic ui. As it stands, I use the json-based uidescription approach using a custom-written tool to spit out the .uidesc file based on the plugin's internal topology. That's a nightmare json file right there https://raw.githubusercontent.com/sjoerdvankreel/infernal-synth/main/ui/controller.uidesc. I wonder if that causes part of the sluggishness on linux, but upon reading up on some old surge synth github issues it's obvious to me that vstgui is severely lacking in the linux department and that particularly the (animated) dropdown menus are going to be a headache.

I'm still going to play around with vstgui a bit longer in the hope that the situation has been improved since 2 years ago. Who knows, maybe dropping that insane uidesc file in favor of regular c++ code, cut down on the number of layers, alpha blending etc etc will improve performance on linux enough. Probably depends on the amount of code I need to tweak in vstgui, indeed mainly on the menu side of things. I see Steinberg's not been very receptive in accepting fixes otherwise stuff would've been merged in after 2 years already. I've now seen the endless discussions on surge's github issues on ui so don't want to go down that rabbit hole, thanks for warning me.

In case vstgui doesn't work out, I'm still not sure what to do. Go for juce? I'd be fine with that on the ui side of things, not so much on the dsp side. Like I said, this project is very much a playground for me to learn about plugin api's and dsp programming in general. Don't want too much abstraction on top of whatever the host is doing for now. In fact i was really aiming for vnext to have a clean & simple gui that's simple enough for users to start worrying about the actual audio of the plugin instead of the ui. But as it is, if that's blocking a linux release, i will reconsider.

So I see a couple options:

• Ditch linux support. Real shame, all dsp code is perfectly capable of running anywhere. This is a no-go for me.
• Just keep going, maybe (likely) face all of the nastiness that plagued surge before xt.
• Switch to juce. Possible, but i don't like the idea of dsp & ui being tied to the same framework.
• Switch ui only to wx/qt/whatever. Not given this much thought.
• Switch ui only to juce. I don't know how much juce ui is coupled to the full framework.

And then there's the issue of "flexible" ui. Anything that's programmatic would handle this no problem, but for anything declarative (xml/json/whatever based) i'd have to re-write the ui-generator project. I haven't looked into this and I'm sure dedicated ui frameworks like qt and wx natively support a "code based" approach. No idea about juce, but it probably will. Whatever it'll be, atm I only have to change 1 constant in the source code to get a gazillion oscillators/envelopes/lfos/whatever (limited by ui space of course) see https://github.com/sjoerdvankreel/infernal-synth/blob/main/src/inf.synth/inf.synth/synth/config.hpp. Anything I choose should have that possibility.

Anyway, end of long rant. Guess I just had to write down my thoughts. Thank you for working with me on this so far.

EDIT:
I don't think vstgui is difficult per-se, it's just that it vastly relies on the uidescription format. You get a whole bunch of stuff out of the box when using the wysiwyg editor. There's a VST3Editor class in there that parses and builds ui from a json file no problem, lovely. Things go awry when that same vst3editor is also responsible for setting up the ui event/idle loop surge-synthesizer/surge#514. I can't imagine anyone in their right mind thinking "hey you only got a ui event loop if you're using xml, but not regular c++" being a good idea, but whatever. That's a couple dozen lines to fix, no need to change the sdk code. The cairo stuff, that i find more disturbing. That's some low-level vstgui code right there with no way to plug-in to without actually editing the sdk. End of long rant, again.

[tank-trax]

I am glad you are committed to Linux. Thanks in advance.

As for VSTGUI, the Surge Synth Team dropped it because it didn't have a multi-line text editor widget which would have impeded the direction Surge was heading.

That being said Surge 1.9 is built using VSTGUI, the port to JUCE (no trivial undertaking either) was made for Surge XT. VSTGUI is not impossible to work with.

I think the other advantage of using JUCE is that it works well with cmake. When Surge started it was using premake.

[sjoerdvankreel]

Currently using cmake already no problems. Also for all the things wrong with vstgui, it handles custom controls pretty well actually. There's a bunch of them in infernal, the tab headers are custom-draw, the knobs are, and a couple minor stuff. I can't imagine surge switching frameworks just because of a single control missing? Bet it was a bunch of stuff that when combined lead to the decision for juce.

[sjoerdvankreel]

Just merged v1.1.3. That gets you a "workable" linux build without having to fiddle with the source code (decided to fork vstgui just like everyone else).

• Implemented fix for painting of the knobs in vstgui using the patch mentioned above.
• Applied surge's fix for disabling animation in the dropdown menus, that speeds them up a bit.
• Menus still jump around a bit unfortunately and I have seen reaper crash on them. Bitwig and renoise seem ok.
• Debug build freaks out on vstgui, release is ok.

Since this is still very much experimental I decided not to include binaries yet so you'll have to build from source. I modified the build scripts to do all the work (except for HIIR, that's a manual step. It has no public github repo that I know of). Script clones vst3sdk including the necessary forks, runs cmake, runs make for both vst3 and infernal. Would you care to give it a try again?

I am particularly interested in the gui performance/sluggishness. So far I've been testing on a VM. Maybe it's time to dust off my old dual-boot desktop but I don't even know if it still works :) Thanks for your time so far.

[tank-trax]

It built successfully as per the instructions running the build_linux.sh

just an aside it wasn't set to execute, I ran bash build_linux.sh /path/to/hiir

so far runs in both Reaper and Bitwig, but it crashes in both

in Bitwig it only crashes the plugin so it can be restarted, it appears to crash on mouse down events on certain areas of the GUI

in Reaper it crashes the DAW and the x server, in which case I go to a TTY and kill the PID, fortunately it isn't locking up the system aka anything realtime as the mouse moves (but mouse down doesn't) and keyboard work, so this looks to be a graphics thing rather than a DSP one, but I could be wrong

the menus are quicker, I noticed one area where they are incorrectly floating, up/down arrow gestures work better than using the mouse and this is something we encountered with the menus in Surge, thinking about it more, I do recall we spent a lot of time and work on the menus (for Linux)

the menus in Surge 1.9 built using vstgui are still very stable, the ones in 1.6.0-beta-5, not as much

I will play around with it more to see if I can isolate when the crash happens, will attempt to build a debug and see if I can get a traceback using gdb

[sjoerdvankreel]

You might wanna try to open all dropdown menus (not only the context menu) by right-click instead of left. Somehow seems much more stable (even if counterintuitive). I also have a gut feeling that vstgui with my changes in it is less stable than without. Will try out another way to speed up the menu's, maybe with a no-op timer for the animations. Another thing to investigate is that i branched from a relatively old commit of vstgui because that is what vst3 sdk is currently pointing to. Maybe the current develop branch of vstgui will be better.

Side note, I'm starting to see where steinberg is coming from here. All their linux menu code is custom-made. I guess they have to commit to using the raw X api's only and refrain from gtk/gnome/whatever because they can't dictate what the host uses? That probably complicates stuff a great deal compared to win32 which just dispatches to ::CreateMenu. No such thing in linux apparently. Just yesterday I was looking for an equivalent to windows' ::MessageBox, no such thing on linux without resorting to any particular graphics toolkit. Doesn't help my case at all of course, but i'm beginning to better understand the state of vstgui. Although I find it more than a bit misleading that it advertises as a "cross-platform gui library" when parts of it's linux implementation reads "#warning TODO: Implementation".

[sjoerdvankreel]

I've been reading up a bit on plugin development on linux in general and the gui side of it specifically, and tbh I don't like what I'm reading so far. Also, your name keeps turning up every now and then (f.e. here https://gist.github.com/abique/4c1b9b40f3413f0df1591d2a7c760db4). As you've probably guessed by now my knowledge of developing gui for linux is next to nothing. Hoping you can help me out with a couple of questions:

• Am I correct in thinking you cannot mix and match toolkits (gtk / fltk / whatever) between plugin and host unless hosting out-of-process?
• If so, does that mean that plugins have to resort to the "greatest common denominator"?
• Is that greatest common denominator X Windows/X11?
• Does that also mean that any UI-library (say, wxwidgets) which does NOT do it's own rendering, but rather delegates to the/an underlying toolkit, is a no-go?
• And by implication, anything that does not create native controls, but does it's own painting (say, SDL or Qt, but apparently also vstgui and, from what I've seen, juce) is an option?

If yes to all of the above that kinda cuts down my options. SDL and the likes are basically "paint it yourself". WxWidgets explicitly states (https://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits) "wxX11 is sub-par compared to other toolkits and unstable. You should use the wxGTK port instead".

If I want a UI library that does regular stuff (menu's, buttons, dropdowns etc) and not relies on any particular toolkit, I think I'm limited to:

• Qt - too heavyweight, also dont like the signal/slots extentions to c++
• Juce - even more heavyweight, seems exceptionally well designed though (been spelunking the source)
• Roll my own (no thanks)
• Vstgui, again...

Any thoughts?

[tank-trax]

I am not a developer. By profession I am computer technician, troubleshooter and repair person. I've been using Linux since RH6 and am into audio production and home studios. My preference for OSes is Linux by design even though I work with and use Macs and Windows too. I am hacky though and can apply myself to learn things. I am pretty good at tweaking. My computers tend to run very well. I take things apart and put them back together. I can read code and imitate and apply what's been done to other projects. Sometimes I wonder if I am too much of a Linux gadfly or if I am just being too overly self conscious while actually being helpful.

So whatever I say is either going to be opinion, up to my understanding or wrong.

My suggestion would be reach out to devs involved with Linux. You can always visit our Discord server and ask around. We've covered a lot of ground in terms of Linux support, however much of it is better fully understood by the Surge Team's maintainer. Falk (KXStudios) is another good person to get to know and ask questions with regards to anything Linux Audio related. Our maintainer has said may times, if we were a commercial project, we wouldn't have Linux support. (I am not sure if they really mean it)

As for JUCE, if not mistaken the GUI is not necessarily integrated when using its framework, it can be but it can also be decoupled, and if not mistaken this is what happened when Surge was ported from vstgui to JUCE, as we have a skinning engine. Again, asking baconpaul would provide a more accurate and helpful answer.

from my experience using apps built with JUCE, I've never felt any lag due to graphics, even with OpenGL enabled or disabled... some of CHOWDSP's deeper plugins have had lag issues but they appeared to be heavy on the DSP side at times, memory leaks and such

as for VST3, it's Steinberg, they've been not always helpful or understanding... the VST3 spec is not great, they treated VST2 underhandedly imho, and those are some of but not the only reasons that CLAP was developed

on Linux it's worse, there was a time when VST3 was not a thing... I remember very well when Surge VST3 loaded for the first time in Reaper, JUCE had a lot of trouble getting VST3 to work in Linux because of a memory loop

not to sound biased because of proximity to the project, but CLAP appears to be a superior plugin format to VST3 possibly even in terms of performance... I haven't done serious benchmark testing, it just feels more optimized... you may want to consider CLAP

as it stands, there are so many excellent synths available for Linux audio, a large bulk that weren't even available 5 years ago, not all use JUCE, but many do, and for the ones that don't in Linux I think it's QT, GTK or X11 for GUI and apparently X11 is simplest/easiest/most transferable across DE's

as a Linux aficionado I am always on the lookout for new Linux synths and audio tools, I read the article on bedroomproducersblog about Infernal and it mentioned being similar to Tranzistow, which is not a bad comparison at all

you may also get annoyed with me because I would eventually ask you to add MPE and microtonal support to Infernal Synth :-)

[sjoerdvankreel]

<< My suggestion would be reach out to devs involved with Linux
Dropped a message on surge's linux channel. Hoping someone can clarify things to me a bit.

<< if not mistaken the GUI is not necessarily integrated when using its framework
Otherwise I can always just refrain from using any stuff but juce's ui classes, although that seems a bit tricky

<< the VST3 spec is not great, they treated VST2 underhandedly imho
I find vst3 to be reasonably well designed although not so well documented particularly wrt the gui integration. Indeed it's weird how steinberg actively wants to kill vst2 though

<< CLAP appears to be a superior plugin format to VST3 possibly even in terms of performance
Can't imagine any particular plugin format doing much for performance? 99% of processing time should be spent in the plugin itself, not in the glue code that connects host and plugin. That being said it's an interesting format and I'd like to support it alongside vst3 someday. But, for example, clap+vstgui is also an option (provided i can get vstgui to work of course).

<< being similar to Tranzistow
Tranzistow sounds way better. But hey, if i understand correctly it's been in development for 30 years or so.

<< you may also get annoyed with me
Absolutely not, you've been a great help so far. I am a bit annoyed with plugin ui development on linux in general but that's just you pointing out the facts to me. Better i learn now than later on when i've spent more time on the plugin's ui.

[sjoerdvankreel]

Progress! Although I really hoped this rewrite-ui thing would be doable in a couple months but TBH I'm guessing end of the year is more likely. Especially with the summer coming up. Very happy with the switch to juce so far, thanks for pushing me in the right direction ;)

[tank-trax]

excellent news!!... so happy that you paid us a visit at our Discord server.... and on first glance that looks great too!

not sure if this could help but it may be worth checking out, I know Jatin uses it to build his CHOWDSP plugins

https://github.com/ffAudio/foleys_gui_magic

[sjoerdvankreel]

Thanks for the hint, but that seems like the exact opposite of what i want to achieve which is plain c++ for the gui.

Just out of curiousity, what's in all this for you? I can tell you straight off the bat what's in it for me: over 2/3 of all infernal code is dsp stuff which i would love to see running on more than just windows. I know it can, it's just the ui thats been blocking me. There's a bit of personal pride there :). Are you a linux-only user?

Anyway, will keep you posted here every now and then about the state of things.

[tank-trax]

I am an almost exclusive Linux user.

What's in it for me? Another Linux synth... but it's more than that. I enjoy promoting Linux as a viable OS for music production and apps for musicians who use Linux. So it's more for other Linux users than me really.

[sjoerdvankreel]

I like your dedication. I have sort of a love/hate relationship with Linux. We use it at work all the time for server-side stuff, works flawlessly. Linux desktop has caused me quite some headaches in my other hobby project though, see f.e. sjoerdvankreel/xt-audio#8 and sjoerdvankreel/xt-audio#13. Never could get pulse and jack to play nice together. But I'm guessing you probably know how it's done.

That being said I'm all in favor of a free OS that's also worthwhile for desktop users. Windows is getting kind-of pushy with it's "i wanna be a tablet" mindset and last time i checked, i actually had to pay apple to be able to distribute free software on their platform. So it's great there's more options out there.

Still very busy with the UI rewrite, I've opened a new issue here #4 to track progress and hopefully get some feedback. The whole linux thing is pretty much tied up to the new UI, too. I'm really hoping you can help me out with testing on linux during development, would you be ok with that? Nothing too fancy, just check progress every other month or so, and of course before I push v-alpha-01 to kvr.

[sjoerdvankreel]

Closing, discussion moved elsewhere.