I'm creating this thread as a place to discuss the porting of wdl and in particular swell for the purpose of getting reaper running in linux.
Cockos has graciously given us a reaper executable that runtime links to to swell in order to facilitate porting of swell to linux. The executable (both 32 and 64bit) and instructions can be found at http://landoleet.org/dev/.
Differences to upstream release:
- uses GTK instead of GDK (thanks, Dave)
- runs in both GTK2 and GTK3
- open, save dialogs almost fully working
- some widgets already sort of working (buttons, labels, text fields)
I have some experience in coding for Qt and almost none for any other toolkit. Is it feasible for me to try and tinker with Qt port (i mean, without knowledge of WinAPI and all that Swell consists of)?
I have some experience in coding for Qt and almost none for any other toolkit. Is it feasible for me to try and tinker with Qt port (i mean, without knowledge of WinAPI and all that Swell consists of)?
Don't know if it's feasible or not. A Qt port should certainly/hopefully be possible. I am very ignorant of the win api as well as cairo, but I decided to try my best in my spare time. Sometimes ignorance can be compensated with persistence. I imagine that all you stand to lose is time, and the rewards would be a deeper understanding of the apis involved and hopefully a working Qt port.
Best of luck whatever you decide!
__________________ Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040, etc. :)
Don't know if it's feasible or not. A Qt port should certainly/hopefully be possible. I am very ignorant of the win api as well as cairo, but I decided to try my best in my spare time. Sometimes ignorance can be compensated with persistence. I imagine that all you stand to lose is time, and the rewards would be a deeper understanding of the apis involved and hopefully a working Qt port.
Best of luck whatever you decide!
i can be persistent that's for sure - that's kinda how i learned Qt in the first place. so i'm sure i'll try!
i have os/platform independent test code to load a ttf font from file and render (win32 = gdi, linux = low level xlib) a string of characters with anti-aliasing and alpha blending, not using freetype.
it seems that lice has os/platform safe alpha blending already, and i might try to implement this in there. regarding swell, it seems that adding the ttf support in lice-text.cpp and using the already present text alignment code for the default bitmap font in swell-gdi-lice.cpp: DrawText() might be the correct to way approach this...with some mods.
i have os/platform independent test code to load a ttf font from file and render (win32 = gdi, linux = low level xlib) a string of characters with anti-aliasing and alpha blending, not using freetype.
it seems that lice has os/platform safe alpha blending already, and i might try to implement this in there. regarding swell, it seems that adding the ttf support in lice-text.cpp and using the already present text alignment code for the default bitmap font in swell-gdi-lice.cpp: DrawText() might be the correct to way approach this...with some mods.
--
The most straightforward place to put text drawing would be swell-gdi-lice.cpp's DrawText(). You'd also need to implement CreateFont/CreateFontIndirect(), and modify the internal HGDIOBJ__ structure to store the font information.. oh and GetTextMetrics() too while you're at it.
If you implement those, then LICE's text drawing/caching code can just call DrawText() as it does on win32/osx.
I have some experience in coding for Qt and almost none for any other toolkit. Is it feasible for me to try and tinker with Qt port (i mean, without knowledge of WinAPI and all that Swell consists of)?
I've also started porting some code to Qt since it's what I use at work, unfortunately its high abstraction level and intransparent messaging system makes everything much more difficult than it should be. I'd prefer Qt over Gtk in an instant (for development at least - other than that, I'm still a Gnome guy). If you're still interested, I could push my first Qt tries into my public repo.
I've also started porting some code to Qt since it's what I use at work, unfortunately its high abstraction level and intransparent messaging system makes everything much more difficult than it should be. I'd prefer Qt over Gtk in an instant (for development at least - other than that, I'm still a Gnome guy). If you're still interested, I could push my first Qt tries into my public repo.
freetype:
big overhead (in my book), needs extra runtime libraries like zlib, very well written, fast, sophisticated api, multiplatform
stbtt_truetype:
tiny overhead (69kb header with examples and docs), fast, basic api, multiplatform
after noticing that stbtt_truetype may not support hinting, i had a small discussion with the author sean barrett (rad game tools, nothings.org), but he explained that he has no plans to add support any time soon (this means small fonts will always look bad with this library - either fully antialiased or clamped with an aa threshold).
as an alternative i've added support to freetype and a header to switch between the two.
there are things to be added / fixed / optimized in there and after that it can be perhaps used with swell, if convenient enough and unless someone decides to write something similar in c++ in the meantime.
Hi, I just registered here to show my interest in a nativ linux port of REAPER. At the moment im using Ardour, but REAPER is more what I am looking for, I think (I have tested only with the Evalut-Edition on Ubuntu with WINE).
As it is avaible for a good price and has some very interesting features (ReaScript) I will buy it as soon as a nativ Linux Edition is avaible.
Did I understand correctly that you want the community to port your open source engine (WDL) to Linux and then you will port REAPER?
I've got some skills in C++/Qt, maybe I could help. What are your plans atm?
Did I understand correctly that you want the community to port your open source engine (WDL) to Linux and then you will port REAPER?
I've got some skills in C++/Qt, maybe I could help. What are your plans atm?
hello arX160,
cockos, i believe, does not "require" reaper users to port wdl to linux :-). you are on the right path though...one major problem is that new developers will have to understand how swell works. perhaps you can take a look at the git repository that Jack Winter/404 are working on and obtain a better idea on some of the gui issues present currently in the linux port.
Beh, I've been doing other stuff for too long now, summer vacation and all that or
Per se there is no git repo. There are 2 initial patches from me in the cockos public wdl repo, that allows you to link to gtk2/3+cairo but still a lot of work is needed to finish it off. It's still using lice instead of cairo for drawing and there is a lot of detail missing.
404NotFound has done some work on the menu system, but I don't know how far that has come?
And to clarify, it's not really that Cockos requires us to port anything. They simply don't have the time to invest in a linux port, but they compiled an executable that links to wdl, and if we port parts of wdl to linux then it will bring the port a big part of the way.
Things like jack audio/midi support and various FX frameworks would still have to be done.
That being said it already runs somewhat on linux using alsa hw0 as output.
Anyone interested feel free to jump in
__________________ Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040, etc. :)
Beh, I've been doing other stuff for too long now, summer vacation and all that or
Per se there is no git repo. There are 2 initial patches from me in the cockos public wdl repo, that allows you to link to gtk2/3+cairo but still a lot of work is needed to finish it off. It's still using lice instead of cairo for drawing and there is a lot of detail missing.
404NotFound has done some work on the menu system, but I don't know how far that has come?
And to clarify, it's not really that Cockos requires us to port anything. They simply don't have the time to invest in a linux port, but they compiled an executable that links to wdl, and if we port parts of wdl to linux then it will bring the port a big part of the way.
Things like jack audio/midi support and various FX frameworks would still have to be done.
That being said it already runs somewhat on linux using alsa hw0 as output.
Anyone interested feel free to jump in
If I had the ability I certainly would, but I am just starting to learn programming. Thank you guys for anything you do.
quick question, would this build require gtk+ >3.0? I have a setup but for the life of me I cant get GTK to build on my rig past 2.8.
so I cant configure swell (or my sweet blufish 2.0.3 )
If yes then I might start building a new os set-up.
I hope all is well, Let me know If you need anything.
i'm not sure about gtk+3, as i haven't installed it yet, but both the master the 404 repository do not build with libgtk2.0-dev from lucid.
here are a couple of points regarding swell, if its going to support both gtk+ 2 and 3, completely neglecting the "ease of use"(an example) aspect of gtk:
- a low(er) level abstraction between the two libraries would be much more readable, instead of a lot of "#if SWELL_TARGET_GDK == ?" inside code. (see bellow - relevant parts between ------------ ). to what level targeting both versions would be possible is another question.
- i personally question the use of cairo for drawing of more complicated widget sets in regard of the performance penalty. here are some comments from 2007: http://www.osnews.com/thread?290582
i doubt that there are much improvements into that area near the current version 3.x. minor changes that complicate gui rendering can be observed on slightly older machines very easily.
example for the suggestions i mention above:
Code:
#include "stdio.h"
#include "windows.h"
#include "/dev/gdkkeysyms.h" /* just to grab the keys from here */
/* test gdk2 */
#define SWELL_TARGET_GDK 2
/*
some dummy definitions so that we don't include
the entire library for this test
*/
#define gint int
typedef struct
{
gint w;
gint h;
} GdkWindow;
void gdk_drawable_get_size(GdkWindow *wnd, gint *w, gint *h)
{
*w = wnd->w;
*h = wnd->h;
}
gint gdk_window_get_width(GdkWindow *wnd) { return wnd->w; }
gint gdk_window_get_height(GdkWindow *wnd) { return wnd->h; }
/*
actual helper functions
------------------------------------------------------------------------------
*/
inline gint swell_gdk2_get_width(GdkWindow *wnd)
{
gint w, h;
gdk_drawable_get_size(wnd, &w, &h);
return w;
}
inline gint swell_gdk2_get_height(GdkWindow *wnd)
{
gint w, h;
gdk_drawable_get_size(wnd, &w, &h);
return h;
}
/* swell_gdkv_* macros for GDK2 / GDK3 */
#if SWELL_TARGET_GDK == 2
/* gdk keys */
#define swell_gdkv_key(x) GDK_##x
/* window dim */
#define swell_gdkv_window_get_width(x) \
swell_gdk2_get_width(x)
#define swell_gdkv_window_get_height(x) \
swell_gdk2_get_height(x)
#elif SWELL_TARGET_GDK == 3
#define swell_gdkv_key(x) GDK_KEY_##x
#define swell_gdkv_window_get_width(x) \
gdk_window_get_width(x)
#define swell_gdkv_window_get_height(x) \
gdk_window_get_height(x)
#endif
/*
e.g. handling keys in swell-wnd-generic.cpp
------------------------------------------------------------------------------
*/
static int swell_gdkConvertKey(int key)
{
switch(key)
{
case swell_gdkv_key(Home): key = VK_HOME; break;
case swell_gdkv_key(End): key = VK_END; break;
case swell_gdkv_key(Up): key = VK_UP; break;
case swell_gdkv_key(Down): key = VK_DOWN; break;
case swell_gdkv_key(Left): key = VK_LEFT; break;
case swell_gdkv_key(Right): key = VK_RIGHT; break;
case swell_gdkv_key(Page_Up): key = VK_PRIOR; break;
case swell_gdkv_key(Page_Down): key = VK_NEXT; break;
case swell_gdkv_key(Insert): key = VK_INSERT; break;
case swell_gdkv_key(Delete): key = VK_DELETE; break;
case swell_gdkv_key(Escape): key = VK_ESCAPE; break;
}
return key;
}
/* test */
int main(void)
{
GdkWindow wnd;
wnd.w = 211;
wnd.h = 321;
printf("%d\n", swell_gdkv_window_get_width(&wnd));
printf("%d\n", swell_gdkv_window_get_height(&wnd));
puts("");
printf("%d\n", swell_gdkv_key(Home));
printf("%d\n", swell_gdkConvertKey(swell_gdkv_key(Home)));
return 1;
}
/*
211
321
65360
36
*/
a small question regarding WDL structuring and the integration with truetype libraries, wrappers etc.:
i currently have the following directories:
Code:
WDL
lice
swell
...
freetype <- freetype src goes in here
stb <- stb_truetype goes in here
lice_tff <- the ttf wrapper that contains freetype and stb (described in an above post)
this way:
- stb and freetype are exposed to everything WDL
- lice_ttf is exposed to WDL (but contains stb and freetype when built - in the lines of lice_ttf.lib)
- lice is independent of lice_ttf and the font libraries
while stb_truetype can be included in WDL (60kb or so), only the folder + makefiles + readme, should be reserved for freetype as it is basically 11mb source code.
is this structuring ok? i hope it makes any sense.
p.s. the wrapper needs some more general work, so that GetTextMetrics, DrawText and other functions in swell-gdi-lice are much easier to implement. i will probably add the code first in lice_ttf (code like these gdi methods), so that its exposed to lower levels. then swell-gdi-lice would only need to pass the context and other winapi specifics around.
Hi guys.
Did you try that stuff on 64bit linux, or only on 32bit?
I tried to compile both 'regular' and 404 versions of swell, successfully if I only refer to the report, but when running reaper (yep, 64bit version), in the 'regular' case message is : "Error loading '/REAPER/libSwell.so'", and with 404 the message is "SWELL API not found: SWELL_SetListViewFastClickMask"
I tried both linking to or copying libswell, no difference.
Edit: I modified 404 version to add the requested SWELL_SetListViewFastClickMask. The result is now the same than with cockos version.
hi guys, i've been using reaper under wine for the past 12 weeks as part of my university studies doing multi-channel diffusion. things work way better than i expected considering it's a non-native application and i'm really excited about this port.
i run 64-bit arch-linux and have downloaded the beta, i gave it a quick run and couldn't get the menus to work but the fact that it ran made me glad in itself.
i'm a real programming novice so i don't think i'll be able to contribute any code but if there's any testing to be done or any other way i can help i'd love to chip in.
Bump. I Love Reaper, have been following this and have had it running under wine. A ported version would be great.
This thread was very helpfull. http://forum.cockos.com/showthread.php?t=26690
Watched this film yesterday, anyone who hasn't seen it, Richard Stallman is an amazing guy.
This is a bump and a question? any news on this and is there a central repository of progress to date, i'd love to get involved and echo the determination comments above.
It appears to me there was a brief resurgence of activity on the Linux Swell port in December but little if anything has happened since? I hope I'm wrong!
I couldn't believe it when I discovered earlier today that there has been some sort of rudimentary native Linux port of REAPER on LoL since June 2011! I've long known REAPER was supported and ran well under wine but I have a big issue with depending upon wine - I don't really like using REAPER that way because I'm all too aware of the negative impact the wine layer has on (JACK) performance and stability. I only heard about the Linux native port in late December when my current band PistonFunkMachine used it to record our debut album.
For yet another unknown reason, it was only today that I was inspired to find out where the Swell port is up to and if possible give it a go myself. Although it seems to still be practically unusable right now, I was thrilled to see REAPER start up successfully and let me use most of the interface. This was when using the libswell within libSwell-x86_64-debian-wheezy-gtk3.tar.xz running under 64bit KX Studio 12.04.2.
REAPER loads and you can add tracks and browse through the menus here but I realised I wasn't going to get much further when I discovered that the open/save file windows don't appear when you select either option and the same goes for the plugin window. It doesn't appear here!
I compiled Swell from git but had much less success. REAPER failed to start at all and just barfed:
./reaper: symbol lookup error: /home/dan/src/reaper_linux_x86_64/REAPER/libSwell.so: undefined symbol: gdk_init_check
So, I may not be able to enjoy REAPER under my OS of choice properly just yet but I'll be trying some of REAPERS VST plugins under qtractor soon. When I have I'll report back here with the plugin results.
but the package name is actually build-essential without the 's'. Total nitpick, I realise - especially at this stage!
I'm hoping Bitwig and Ardour 3.0 will give reason for more LinuxVST plugin ports in the run up to LinREAPER. I'll certainly be buying REAPER as soon as the Linux port works!
Thanks for sharing that, running reaper under wine is something I have done and want to run a native linux version too. For now I have Refit on my I mac and Dual boot into Windows 7 and run reaper there or of course on the I mac side depending on which plugins I want to use.
Recently I have been using Bodilizer and Red shift from Acme BarGig a lot as I am developing my own Guitar Impulse response plugin. I have been having some success with WineSkin but have not had time to really spend a lot of time tweaking things.
Just as a further explanation as to why Linux is my favoured operating system. Its architecture is very economical on CPU and coupled with reapers excellent architecture it allows much less powerful and older machines which is much more affordable for a wider community.
At a practical level Linux makes huge sense at a philosophical level Richard Stallman and the GNU free software movement are leading the world out of some sort of desert. The practical advantages are more apparent more quickly to most of us at first.
I have tried a few of the REAPER VST FX under qtractor but unfortunately all I get is a stream of various 'SWELL API not found' errors.
I copied libswell (the binary from LoL that lets me start REAPER) into /usr/lib as well as my vst plugins dir but that didn't help.
I'm hoping this thread can stay on topic instead of degrading into some pointless OS war like the other thread on native Linux REAPER did -its done well so far (jinx)!
So, I understand that a Linux Reaper installer is a real possibility . . . of course nobody can say for sure but are we talking months, years, or "probably never?"
If it does happen, what are the practical benefits for the average user? I understand WINE affects performance negatively, but mostly I'm hoping for a much easier setup in terms of compatibility with JACK. If a native port means setup in Linux is only 10 or 20 times more difficult than in Windows, I'm in!
__________________
MS Windows 8 Pro 64-bit, Intel Core i3 370M @ 2.40GHz, 4.00 GB RAM, Acer Aspire 5742
Location: Barcelona / Sevilla / Copenhagen / Warsaw
Posts: 17
can you try to strace qtractor - to find what exactly it is looking for?
You can try it also to add to /etc/ld.conf and run ldconfig
Quote:
Originally Posted by danboid
I have tried a few of the REAPER VST FX under qtractor but unfortunately all I get is a stream of various 'SWELL API not found' errors.
I copied libswell (the binary from LoL that lets me start REAPER) into /usr/lib as well as my vst plugins dir but that didn't help.
I'm hoping this thread can stay on topic instead of degrading into some pointless OS war like the other thread on native Linux REAPER did -its done well so far (jinx)!
It seems the Linux builds of REAPER haven't been updated in nearly a year- but I suppose that doesn't matter much if WDL hasn't got much Linux love either, which it hasn't from what I see in git log.
MS are visibly floundering and doing a damn fine job of killing themselves and pissing everybody (partners, devs and users) off, OSX peaked at 10.6 it seems but Linux continues to go from strength to strength.
Come on Cocko's - you know a proper Linux port is inevitable now! Do the right thing and get serious about Linux sooner rather than later, please!
There is a preliminary executable that is missing a lot of functionality. There's a lib to make it run.
The work that needs doing is to port SWELL to either gtk or qt. SWELL is a subcomponent of WDL that can be found at: http://www-dev.cockos.com/wdl/WDL.git
SWELL is Cockos' Simple Windows Emulation Layer for Linux and is what allowed the OS/X port to be done.
__________________ Reaper for Linux Documentation (WIP). Software: Archlinux/KDE, Fabfilter FX, Komplete 8, Nebula, Schwa/Stillwell, T-racks Max/Amplitube/SVX, etc. Gear: i7-2600k/4700HQ/16GB, RME Multiface/Babyface, Behringer X32, Genelec 8040, etc. :)
Very sad to see this thread seem to die but also the many years with no solid progress. Reaper is the only thing keeping one of my machines running Windows but with the constant missteps MSFT has made with UI and various other things I'm about to leave Reaper for Ardour just be to rid of the on going train wreck this wonderful software has tied itself to. I guess I have until Cockos ports, Win 7 reaches EOL or MS gets a clue and un#ucks the Windows UI to make my choice. I was so excited for Reaper 5
__________________
Human being with feelings it says while in my picture I'm wearing a T-Shirt with "HATE" written across it.
A native Linux version of REAPER would be great. With more serious VST-capable DAW software running on Linux, more professional plugins for that platform might get developed, too.
Ardour isn't really usable - even the latest version 4.1 is a pain in the ass, but Bitwig was a pretty good start, and it would be awesome to add a widely accepted traditional DAW like REAPER to the list.
Come on guys, I'm sure it can be done. 25 - 30 years ago I would most probably have done the port myself.