What Linux Vstis Have You Got Working?

[BYTE-Smasher]

@Suva

I would look into LV2 for linux audio plugin development.

But if I use Juce then I only have to write the plugin once for all 3 platforms

[neocoretech]

That’s why i asked this… : http://www.rawmaterialsoftware.com/jucefor…opic.php?t=1376

LV2 support in Juce would be great

[fred-hal]

[two cents]
A bit off topic, but anyways… I had an idea last night…

Every year KVR has this ‘Developer Challenge’ which takes donations from anyone willing to donate, and people vote over which free VST developed for the event should win. The winner gets the total donated amount. Last year had 41 entries, and the total prize sum was $2200, quite a bit!

Anyways, the challenge’s entries are almost all windows-exclusive, so maybe we non-windowsers could convince next Dev Challenge to have three categories (windows, mac, linux), so people can vote for a winner in each category? Or even start our own ‘Linux Developer Challenge’?

Maybe that would draw more devs over to the linux platform… Who would be willing to donate a bit to something like that?

[/two cents]

[fred-hal]

Aciddose posted a lengthy reply to my ‘port vst to linux’ thread over at KVR. Seems the main concern when porting vsts are the vstgui part… Looks like he’ll port Xhip completely at one point though!

technically, you do not need to use any of the files in the “vst sdk” to create vst plugins anyway.

xhip for example continues to use heavily modified versions, but that is only because there are a few older hosts out there which try to access an audioeffectx class directly on windows without checking the pointers - if that happens, uh oh, exception 0005.

clean-room reverse engineering would take only a few hours, you simply need to find somebody who has never seen those files before and i can describe the interfaces without trouble. the reinvented “sdk” files could then be distributed under gpl or any other license.

technically, again, it isnt possible at this point for anybody to claim copyright over most of the contents of those files as they contain no creative works, apart maybe from certain comments. they claim to possess trademark on “VST”, however as there have been very few cases and trademark infractions occur everywhere including in commercial products it is unlikely they can back that up. in the united states at least, as far as i’m aware they no longer possess “VST” as a trademark due to this.

a majority of the things people bring up against moving code to linux is nonsense anyway.

the single major concern for writing linux vst plugins at this point is here:

• NO VSTGUI.
• NO IDLE CALLBACKS FROM HOST.
• NO WINDOW MANAGEMENT VIA THE HOST AT ALL.

xhip will fail to function correctly and often crash due to this issue. in order to correctly “port” xhip would require that i completely redesign my gui code to manage it’s own window and messages, possibly from it’s own thread. this isnt bad and i will do it at some point in the future, if not for linux just for the fact it is the better way to do things. unfortunately my gui library was designed based upon taking example of a few core files from vstgui so that i could move an already existing gui written using vstgui over to my own library.

the remaining artifacts from this are that 1) the command structure of gui-interface → ‘frame’ <> context <> widgets exists similar to vstgui. actually very different, but the structure is similar. 2) the window messaging is controlled from the host and idle time is given back to the host as in vstgui.

so, those are two things which have to be changed in order to get a xhip version working correctly on linux.

now… regarding other vst code? if they use vstgui you’re completely out of luck - it would mean every gui would have to be completely rewritten from scratch, and not only that but a gui library like mine would need to be written from scratch or taken (juce, etc) to fill the void of vstgui. a large number of vst code also depends upon interfaces that are tied directly to windows, almost none of the code you’ll see ‘in the wild’ is dynamic enough to work with different types of interfaces.

if you’re thinking “just port vstgui…”, well, that isnt really possible due to the way things work in vstgui. i’d have to really take a long look and think about how to work a solution (if one is possible) to tell you for sure that it is absolutely impossible, but practically speaking nobody is going to do it anyway. so, facts are vstgui isnt and wont be available on linux as far as i can see.

[kunitoki (kRAkEn/gORe)]

i’ve already ported vstgui to linux. it isn’t a proper port, mainly because of the limitations of the vstgui code, and you have to live with artifacts using the mouse (an intrinsics problem of vstgui mouse event handling) and gui (just my fault, i haven’t got the time nor the feeling to do a proper double buffering support). But at least it CAN be ported… you only have to find the right mood to do it and the time of course (i have to admit i prefer coding with juce than the horribly stupid vstgui framework).

[fred-hal]

updated the original post, the newly compiled nekobee works great in beta 3, thanks kRAkEn/gORe!

[hihi (zomg)]

hm, bufferoverride works mighty fine except for one thing: i couldn’t figure out a way to store the used preset up until now. (renoise doesn’t remember the settings and exporting and then again importing the settings as an .fxb file didn’t work either.)

anyone suggestions on that?

[kunitoki (kRAkEn/gORe)]

try to download the latest svn and rebuild it as it stated in the jucetice ports page (abviously you will need to download the vstsdk by yourself)

[lroy]

I just found a bug with nekobee (newest version) and Renoise b3 : select nekobee, open ext. editor, close editor, change instrument with another VSTi, open ext. editor -> crash !

[kuniklo]

These were just released:
http://loomer.co.uk/

The 1.0 release of Aspect crashes Renoise but apparently the developer has already fixed this and will be releasing a patch very soon.

Discovery also seems to be working here:
http://www.discodsp.com/discovery/