Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
linvst now in a single process space : linvst-X
#1
For people using Linux and finding that running Windows plugins can bring creative capabilities and possibilities, linvst has now a variation that allows to run all plugins in the same process space.

Which means ... that suitable plugins that offers inter-plugin communication can now be used on Linux.

For instance some Voxengo and Melda plugins can share data between various plugin instances. It can be to quickly copy EQ curves, spectral analysis, etc. All things that can be done without (of which an extreme expression could be: who needs plugins anyways ? Smile ) but are nevertheless a feature of such plugins. Or can in some cases alternatively be done by saving to file the data of a plugin and loading it in another instance. Or copying the plugin from one track to another, as with Span Plus in order to keep the previous track's data in memory will working on the next. But still, these plugins allows for quick sharing of data between several instances of them and linvst-x allows for this by not running each plugin in its own process space.

All this said, linvst-X is a month old and is made by the people who made linvst. I haven't tried it yet.

https://github.com/osxmidi/LinVst-X

Cheers.
Reply
#2
I don't need that as I use linvst only for ezdrummer but it's incredible what people can achieve!
Reply
#3
I was pretty much surprised when I learned about it. That I did not tried yet has to do with my wanting to keep the current working system as stable as possible. If I upgrade the hardware by leisurely building a parallel machine, then I will certainly give it a try.
Reply
#4
(01-17-2020, 09:47 AM)jonetsu Wrote: For people using Linux and finding that running Windows plugins can bring creative capabilities and possibilities, linvst has now a variation that allows to run all plugins in the same process space.

Which certainly means that when one plugin karks it it takes all others with it.

MMM
Reply
#5
Yes, it does. It's written in the documentation.
Reply
#6
"Forewarned is forearmed"
Reply
#7
(01-19-2020, 06:25 AM)madmaxmiller Wrote: Which certainly means that when one plugin karks it it takes all others with it.

That's why I did not even bother to consider it! :-)
Mixbus/Mixbus32C on Linux (Kubuntu)/KXStudio repositories.
GUI: KDE and Fluxbox
Reply
#8
There are two aspects to this.

1) The first is that in more than a year of use, a Windows plugin crash is very rare, with the plugins that I use. It's exceptional by nature but then, any software can crash. I've seen Mixbus crash, very rarely, and that did not stop me from using it.

If your Windows plugins are crashing on a regular basis, then there's a problem that's not linked directly to the plugins, for a given set of plugins that I also run on a regular basis.

I do not do any 'workaround' and I do not search for 'workarounds' to make a Windows plugin work. It either work right away from the demo, or it is ditched immediately. That could explain part of the stability I experience with Windows plugins on Xubuntu 18.04 and Linux Mint 18 previously.

2) The second aspect has to do with the DAW itself. For instance, a plugin crash can rarely crash Bitwig. That's how Bitwig is made, going squarely and totally against Paul Davis' (and others) point of view on process management. It can crash Bitwig when it induces delays with the audio subsection. In Mixbus a plugin crash can bring down the whole DAW immediately. In that case point 1) remains. If your Windows plugins are crashing on a regular basis, then there's some other problem.

The best would be to offer a common, natural (native-like) sharing space between processes so that Windows plugins would work as if they are running in a same Windows OS main process and not as unrelated processes as they do now under linvst.

If the Windows plugins would communicate say, through TCP/IP (just an example) then the problem would not exist as interprocess TCP/IP comms would basically work on Linux. Not the most efficient way of communicating between processes on a single host, but can be done, and is readily portable regarding scaling of applications.

Although under Windows plugins are using some other mechanism to see each other and be able to share data, as the Voxengo, Melda and many other Windows plugins are doing. Specifically that way would have to be ported to wine/linvst in a transparent way.

Meanwhile I will eventually give linvst-X a try, but since I'm doing very well w/o those inter-plugin communication features, and since I value the stability of the current environment, there's absolutely no rush in doing so.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)