Jump to content


Photo

VST Standards and Hosting Curiosity

VST VSTi Linux

  • Please log in to reply
12 replies to this topic

#1 Renoised

Renoised

    Chief Above Chief Member

  • Normal Members
  • PipPipPipPipPipPip
  • 270 posts
  • Gender:Male

Posted 07 January 2018 - 13:12

I'm curious, as VST is a self-contained open standard developed by Steinberg, why there are any issues at all using a Windows VST or VSTi inside a Linux host?

I don't understand why Renoise (or any Linux-based host), cannot just load a VST or VSTi that works on Windows.  As it's the host itself, not the OS, that is responsible for 'hosting' the dll, what's the problem?  It's just a dll file in VST format, so just because a host is running on Linux, why does it suddenly lose the ability to render a VST or VSTi if it's following the VST standard?

Why can't Renoise for Linux host that standard just as it does on Windows?

From now on, all my software purchases are for Linux, and it's great that Renoise is officially available on Linux, but it really pisses me off that as a host, it cannot host a VST dll unless it was specifically designed for Linux.  VST is designed, surely, to be hosted by the "host", not the "OS".  Seems to go against the whole concept of a 'standard' when VST doesn't work between platforms.  Not to point out the obvious here, but if a Linux-based VST host was able to load any Windows VST and VSTi plugin natively, I reckon every Linux-based musician in the world would be using your product cause it would open-up the world of Windows VST and VSTi 'natively' to the Linux musician.  I hear it's the same for those who use the Mac, they're constantly frustrated by not having the "Windows VST" not work on a Mac.

I want to use my PG-8X and other stuff inside of Linux-based Renoise, damn it :walkman: 

 



#2 toimp

toimp

    Big Masta Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPip
  • 516 posts
  • Gender:Male
  • Location:Germany
  • Interests:Music, music, music ...

Posted 07 January 2018 - 14:32

VST is just an interface, it doesn't handle gui or sound generation stuff. So VST devs use own implementation, 3rd party dll's or OS specific functions inside their effects and instruments.


Edited by toimp, 07 January 2018 - 14:33.


#3 radian

radian

    Chief Above Chief Member

  • Normal Members
  • PipPipPipPipPipPip
  • 287 posts
  • Gender:Male
  • Location:Brighton, UK

Posted 07 January 2018 - 15:26

As it's the host itself, not the OS, that is responsible for 'hosting' the dll, what's the problem?


As long as the plugin doesn't do anything that the OS handles, like use CPU time or memory then you're correct. Obviously this is the never actually the case.

#4 OopsIFly

OopsIFly

    Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • 1021 posts
  • Gender:Male
  • Location:Meist völlig betrunken in der Hofnarrenkammer
  • Interests:Lavalampen stundenlang anglotzen

Posted 07 January 2018 - 15:56

VST is a public available in details and headers library interface. It works the same with linux as with windows. It defines entry points and behaviours for...generic software modules, so they can supply dsp generation or processing. It doesn't include other functionality, it gives the developers the freedom to choose further nessecariy software components themselves. VST just defines the handshakes and operation between plugin and host, nothing more.

 

Linux VST is basically the same as Windows. But this specs already include some operation that is defined by the operating system it is running on. It starts with the very file format, which is .so on linux compared to .dll on windows, both are different takes on the same thing, and each is the default format for dynamically linked libraries on the specific OS. And that is just the start, these VST modules can use operating system functionality and other libraries in their operation at will, which can be very different and also incompatible between the operating systems.

 

You CAN try to use Windows VST on Linux, but you need special programs for that. For example the "airwave" wrapper, which will use "wine" in its whole glory to try to simulate stuff that is going on in windows, just running simulated on a linux box. Then all the OS stuff is simulated, also other libraries can be installed and ran inside wine, and airwave will handle all that and generate kind of a loading stub for hosts and an information pipe between the wine world and the linux VST interface. Sometimes it works ok or even close to perfect, but due to the nature of wine that not all aspects of windows are perfectly simulated, there are many plugins that are glitchy or problematic, maybe because they use more deeper in system windows/wine features than other VSTs, or wine just happens to be faulty in certain aspects.

 

When a plugin dev makes a linux version of their VST, they have to replace many components that are specific to windows with functionality that does the same on linux. For example graphics interface is one thing that works very different and that almost every VST has. If the devs are clever, they use external or in-house libraries for all the os dependent stuff, so they can just code away and jsut compile the plugin for win/mac/linux. Mac also works this way, but as mac is more widespread among the target audience, more plugin devs go thru the hassle of developing their plugins in 2 versions (mac/win). I think unlike the wine way it is not really possible to run mac vst plugins on linux?

 

VST devs are challenged with small customer base on linux and especially much more difficult software support - is important for many customers, and a nightmare to do on linux, you have to hire a goddamn linux guru to offer specialised support and even he can't know all the nessecary turns for all supported distros! Also there's no iLok alike mechanisms on Linux, hehe, it probably never will be and would be hacked very soon, some angry men in suits will no be willing to allow their devs to make linux versions unless there are snares like this available...



#5 Renoised

Renoised

    Chief Above Chief Member

  • Normal Members
  • PipPipPipPipPipPip
  • 270 posts
  • Gender:Male

Posted 07 January 2018 - 19:28

Thanks all for the info, especially OopslFly for the detailed explanation, it's very different to what I thought!

These days cross-platform seems to be a buzzword, but the VST format doesn't seem well thought out in terms of cross-platform publishing, even though it works on various platforms.  What we need then, is for some code-master to create something 'invisible' that you install on Linux that basically runs in the background.  I suppose that's what WINE is, but I mean something much more basic and efficient, something purpose designed to allow the running of Windows VST on Linux by any DAW that runs on the OS.

Yeah I know ... stop dreaming :lol:

 



#6 OopsIFly

OopsIFly

    Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • 1021 posts
  • Gender:Male
  • Location:Meist völlig betrunken in der Hofnarrenkammer
  • Interests:Lavalampen stundenlang anglotzen

Posted 07 January 2018 - 23:19

More and more plugin developers do make the jump to offering linux versions, porting their plugins themselves. And that's people like U-He. Also more big daws already went linux, like bitwig and tracktion, and this will create a certain market for plugin developers to sell plugins on, so things will probably tend to expand. Maybe this has to do with the nature of linux systems being nice to customize and maintain for certain professional demands, and also being more stable than windows systems in being set up the right way, while not being such a closed up proprietary licensed world like mac is.

 

I wouldn't bet on some code mastery to make windows or mac stuff compatible the easy way. Look at the wine project, how complex it is, and how many flaws it still has. And it is no small hobby project by any means, there's lots of interests, even commercial ones, behind it as driving force. Also most VSTs are intellectual property of their creators, and those would be the right spot for deciding to make ports to other systems. They have everything needed to make perfect versions for any os and maybe even other processor architectures like arm - they own the source code, and this would be needed, plus some extra work replacing the os/system dependend components with compatible ones. Porting a software/dll plugin to another OS is similar work like porting any other software, and if the software hasn't been designed properly for being portable, the required amount of effort can be much bigger than under other preconditions.

 

Well, search for the "airwave" thing, get in and the right version of wine installed/running, and you might already have good results with many windows vsts.



#7 dblue

dblue

    Dodgy Geezer

  • Admins
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 5685 posts
  • Gender:Male
  • Location:Berlin
  • Interests:Code. Music. Graphics.

Posted 08 January 2018 - 12:28

I think you've simply misunderstood what a VST plugin actually is.

When all is said and done, a VST plugin is an application running binary code that is native to each platform, just like any other application. On Windows they happen to be packaged as DLLs, but a DLL is still an application running native binary code just like an EXE, it just happens to contain a few useful extra features that help other applications to know what functions it provides and how to use them.

VST doesn't provide universal cross-platform methods that the plugin can use for things like displaying graphics on screen or handling user input. Steinberg would have been crazy to attempt such a thing, and would be stuck maintaining such a system for the rest of their days, dealing with every operating system update that inevitably screws something up.

VST simply provides the basic API that is shared between all platforms, dictating which functions are available to the host/plugin, how they must called, what parameters they take, and things of that nature. Everything else — all the actual dirty work and the real inner workings of the plugin — is left up to the developer, so Windows VST plugins therefore rely on Windows related functions, while Mac VST plugins rely on MacOS related functions, and so on.

Even if the VST plugin had absolutely no features that depended on a particular operating system or platform, even if it was just the most simple process() function in the world that simply took the audio input and returned it back to the host unchanged, the plugin binary itself would still need to be compiled and built to target each individual platform.

You cannot take the DLL from a Windows VST plugin and run it natively on Mac/Linux (without serious hacks like Wine) any more than you can take your copy of Notepad.exe and expect it to work on Mac/Linux (again, without serious hacks).
  • Marc Shake and radian like this

#8 Marc Shake

Marc Shake

    Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • 1606 posts
  • Gender:Male

Posted 08 January 2018 - 14:58

The VST just is a container which works like this:

 

Renoise says: Play the note C-4 -> VST interpretes to play C-4 -> VST makes supercool VST-Synth-Stuff ->  VST starts an API-Request to the OS-Soundengine -> Soundengine plays sound -> VST says to Renoise "I did it" -> Renoise says: "yo, cool"

 

The point where it gets complicated is when the VST has its own GUI. While most windows-tools use GDI/DirectX, Linux/MacOS prefers OpenGL/SDL. That's one of the reasons why some Win-VSTs just show a black window when using them in Windows because the gdiplus-library of Microsoft has some undocumented features which Wine cannot handle.


Alles über Renoise und Linux auf meinem Blog


#9 realist

realist

    Composes without Wires burns Directly from Brain to DVD that is already in Store Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 3090 posts
  • Gender:Not Telling

Posted 08 January 2018 - 20:15

No,
 
the DAW calls process() of the VSTi and reads the audio buffer of each VSTi (a float32 stereo buffer in the size of the latency buffer), and for VSTs, it also writes the current buffer into the plugin and then calls the process() of the VST and reads the result buffer (actually it's process(*processingBuffer, *resultBuffer) or similar, so only one call).  As insert, the result buffer is the final result, as send effect, the result is added to the prior buffer (well this case switch also is done within the plugin). This happens for all the plugins in all slots all the time (except sleeping dsps). The interstep daw calculation will be done each audio buffer / latency.  For midi it is pretty similar from concept, the daw constantly sends midi and vst parameter changes to each plugin. The result is again a float32 stereo buffer/array.
 
The GUI of a VST can use various graphics libs. The most common is VSTGUI, which more or less nicely interacts with VST (SDK) OOTB. The DAW calls "openGUI()" or "closeGUI()" etc. So each plugin must provide these standard methods. If it does not provide it, it will have no standalone gui, only the DAW provided one then. So a plugin in fact can lack of an own GUI.
 
The plugin never has any connection to the audio driver, the DAW sits in between. Only if the plugin itself provides kind of audio driver handling, it can try to access the audio driver, but would not make any sense, because the DAW often opened the driver in exclusive mode, no way to access the audio stream of the DAW from outside.



Actually the above written is quite inaccurate. The vst sdk's process() looks more like this: process(*dawAudioBuffer, lengthOfBuffer). VST was designed for sake of maximum performance, so the daw actually only passes a reference pointing to the DAW's internal audio buffer (per CPU core). The VST plugin then directly writes into/modifies that DAW audio buffer. That's why any VST easily can crash the DAW, e.g. simply by writing a too long data than the buffer length. Also the buffer size can dynamically change. This is a simplified serial model of the dsp processing on one single cpu core only. When it comes to multicore processing, it actually gets very complicated. Each core process will have an own DAW audio buffer. And the DAW later will mix it accordingly to the processing order. The daw needs to schedule the multi core usage of each plugin, so all cores are maximal equally are used. That's why implementing sidechain must be quite difficult.

Edited by guest_ffx, 08 January 2018 - 21:01.

  • Marc Shake and radian like this
.

#10 Renoised

Renoised

    Chief Above Chief Member

  • Normal Members
  • PipPipPipPipPipPip
  • 270 posts
  • Gender:Male

Posted 09 January 2018 - 13:42

After reading the replies here, I've learnt more in this thread than I have in various videos over the years.  I don't mean I've been learning to program, I just mean what I've picked up through seeing others discuss it.

 

Very cool to hear u-he are supporting Linux now, and yep, with DAWs like Renoise and Waveform (Tracktion), as well as the early ones that have been there for a long time, LMMS etc, it all increases the need for developers to support Linux.  I'll have to look into Airwave cause I never tried that on it's own and I couldn't even get WINE to install on the older system I tried before.  Sounds like Airwave is my solution for now then cause PG-8X and the other VST/i I like to use have not been released as a Linux format VST, well not yet anyway, but fingers crossed!
 



#11 gremlin moon

gremlin moon

    New Member

  • Normal Members
  • Pip
  • 3 posts

Posted 10 January 2018 - 00:17

 Also there's no iLok alike mechanisms on Linux, hehe, it probably never will be and would be hacked very soon, some angry men in suits will no be willing to allow their devs to make linux versions unless there are snares like this available...

" unless there are snares like this available..."

I'm sensing a D&D, Malazan, Dragonlance, etc...background here (especially coupled with the Linux talk). Am I close or just a coincidence of word choice?



#12 Marc Shake

Marc Shake

    Guruh Motha Fakka is Levitating and Knows Everything About Renoise Member

  • Normal Members
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • 1606 posts
  • Gender:Male

Posted 10 January 2018 - 12:11

Okay - thanks for correcting my "supersimplenottechnicallycorrectexplaination" ;)


Alles über Renoise und Linux auf meinem Blog


#13 Renoised

Renoised

    Chief Above Chief Member

  • Normal Members
  • PipPipPipPipPipPip
  • 270 posts
  • Gender:Male

Posted 10 January 2018 - 14:32

As long as the plugin doesn't do anything that the OS handles, like use CPU time or memory then you're correct. Obviously this is the never actually the case.


Well "Obviously" if I knew that, I wouldn't have asked.
 

Just thought I'd leave the return of sarcasm until after I'd gotten informative replies from civilised peeps, which I now have, thanks to those peeps.
And you thought you'd gotten away with such primitive sarcasm undetected?

"Obviously" not.

 


Edited by Renoised, 10 January 2018 - 14:35.






Also tagged with one or more of these keywords: VST, VSTi, Linux