IPC between linux processes and wine processes

[Alexandre Bique]

Hi,

I plan to write a Linux VST bridge to Windows VST. This could improve
windows VST support in our native DAW.

I wonder what is the best strategy and what do you recommend?
 - spawn a wine vst host process from the linux vst and then do IPC
through unix socket
 - spawn a wine vst host process from the linux vst and then do IPC
through tcp socket
 - spawn a wine vst host process from the linux vst and then do IPC
through shared memory
 - load the windows vst into the Linux process and directly call its
functions (with appropriate calling convention).

Thanks a lot!
Regards,
--
Alexandre Bique

[Paul Chitescu]

On Wednesday 01 May 2013 10:37:38 pm Alexandre Bique wrote:
> Hi,
>
> I plan to write a Linux VST bridge to Windows VST. This could improve
> windows VST support in our native DAW.
>
> I wonder what is the best strategy and what do you recommend?
> - spawn a wine vst host process from the linux vst and then do IPC
>
> through unix socket
> - spawn a wine vst host process from the linux vst and then do IPC
>
> through tcp socket
> - spawn a wine vst host process from the linux vst and then do IPC
>
> through shared memory
> - load the windows vst into the Linux process and directly call its
>
> functions (with appropriate calling convention).
>
> Thanks a lot!
> Regards,
> --
> Alexandre Bique

Hi!

The IPC methods are feasible, UNIX sockets being the simplest and shared 
memory the most complex. The host process should probably be a Winelib 
application so you can call the native API from it.

The last method of running win32 code in a native process is a no go. All but 
the simplest libraries expect a fully prepared runtime and Windows environment 
which only a Wine instance can provide.

Paul Chitescu

[jordan]

Hi

On Fri, May 3, 2013 at 2:55 AM, Paul Chitescu  wrote:
> On Wednesday 01 May 2013 10:37:38 pm Alexandre Bique wrote:
> > Hi,
> >
> > I plan to write a Linux VST bridge to Windows VST. This could improve
> > windows VST support in our native DAW.

Not too long ago the FSThost and myself, were brainstorming about
doing something similar to your idea. it just hasn't been high on the
priority list. ~ FSThost is a winelib application for wrapping windows
VSTs as standalone apps (single VST host).

http://sourceforge.net/projects/fsthost/

it's under fairly active development, with a decent feature set;
jack_session support. 32/64bit plugins, midi-filters, loading/saving
states, gtk+ interface or run without X / no gui, wine-rt / L_pa
support, etc...  but obviously, at this point it doesn't have a linux
VST backend or some kind of proxy-VST who's plugin API FSThost could
tap into (if you wanted to sanbox those VSTs from host), or something
along those lines...

it may be worth having a look at FSThost - since it's already an
existing application that provides a lot of the functionality you'll
probably want. ~ it may save work and projects can always use more
contributions / collaboration. that being said, i am sure some code
would need to be reworked, in order to support using VST interface,
instead of jack.

another app that is similar to what you want to do is dssi-vst - which
from what i gather runs a vstserver - and the IPC is OSC (liblo). But
i haven't used it much, really - so i can't say too much about it;
http://www.breakfastquay.com/dssi-vst/

cheerz

jordan

[Alexandre Bique]

Hi,

Thanks everybody for your help!
I already started to work on it, the application is split into 3 components :
- the linux vst plugin (template)
- the wine vst host (compiled in 32bits and 64bits, with wineg++)
- the plugin maker

First you call plugin make on the windows vst dll, the plugin maker
will basically copy the linux vst (template) and and modify a string
pre-allocated in the .so to store the dll path.

Then the linux vst host (your daw) will load the linux vst plugin
(templatized) which will create IPC stuff (at the moment
socketpair(AF_UNIX, SOCK_STREAM, 0), spawn the wine vst host and
they'll forward calls bi-directionnaly.

Maybe I'll setup shared memory for data process calls, later.

The code will be hosted at https://github.com/abique/vst-bridge yet I
didn't push my code yet, I'll do it the next week.

I had a look to dssi-vst, and fst. But I would prefer 1:1 mapping and
transparent integration into my DAW. And I think that I can finish it
quickly so it may be faster for me to write it from scratch.

Thanks again for your advices :)

On Fri, May 3, 2013 at 9:24 AM, jordan  wrote:
> Hi
>
> On Fri, May 3, 2013 at 2:55 AM, Paul Chitescu  wrote:
> > On Wednesday 01 May 2013 10:37:38 pm Alexandre Bique wrote:
> > > Hi,
> > >
> > > I plan to write a Linux VST bridge to Windows VST. This could improve
> > > windows VST support in our native DAW.
>
> Not too long ago the FSThost and myself, were brainstorming about
> doing something similar to your idea. it just hasn't been high on the
> priority list. ~ FSThost is a winelib application for wrapping windows
> VSTs as standalone apps (single VST host).
>
> http://sourceforge.net/projects/fsthost/
>
> it's under fairly active development, with a decent feature set;
> jack_session support. 32/64bit plugins, midi-filters, loading/saving
> states, gtk+ interface or run without X / no gui, wine-rt / L_pa
> support, etc...  but obviously, at this point it doesn't have a linux
> VST backend or some kind of proxy-VST who's plugin API FSThost could
> tap into (if you wanted to sanbox those VSTs from host), or something
> along those lines...
>
> it may be worth having a look at FSThost - since it's already an
> existing application that provides a lot of the functionality you'll
> probably want. ~ it may save work and projects can always use more
> contributions / collaboration. that being said, i am sure some code
> would need to be reworked, in order to support using VST interface,
> instead of jack.
>
> another app that is similar to what you want to do is dssi-vst - which
> from what i gather runs a vstserver - and the IPC is OSC (liblo). But
> i haven't used it much, really - so i can't say too much about it;
> http://www.breakfastquay.com/dssi-vst/
>
> cheerz
>
> jordan

[Alexandre Bique]

Hi,

I got some progress :)
I have working win32 VST under linux Renoise, you gets the parameters,
and save/restore custom data :)

But I have some issues with the UI.

1) Renoises gives me a couple (Display*, Window), can I tell the VST
to draw in this couple (Display*, Window) and how? Because I use
CreateWindow() at the moment and I don't think that it understand Xlib
;-)
2) I split the host in two threads: one thread which block on the
socket for the IPC, process etc.., and the main thread with a loop
PeekMessage()+DispatchMessage().
Then I get the message editOpen in the rpc thread, I show the window,
and the window do not catch events, is not drawn etc... I believe that
there are some issues with threads and stuff, but which one?

Thanks for the help! :)

On Fri, May 3, 2013 at 10:39 AM, Alexandre Bique
 wrote:
> Hi,
>
> Thanks everybody for your help!
> I already started to work on it, the application is split into 3 components :
> - the linux vst plugin (template)
> - the wine vst host (compiled in 32bits and 64bits, with wineg++)
> - the plugin maker
>
> First you call plugin make on the windows vst dll, the plugin maker
> will basically copy the linux vst (template) and and modify a string
> pre-allocated in the .so to store the dll path.
>
> Then the linux vst host (your daw) will load the linux vst plugin
> (templatized) which will create IPC stuff (at the moment
> socketpair(AF_UNIX, SOCK_STREAM, 0), spawn the wine vst host and
> they'll forward calls bi-directionnaly.
>
> Maybe I'll setup shared memory for data process calls, later.
>
> The code will be hosted at https://github.com/abique/vst-bridge yet I
> didn't push my code yet, I'll do it the next week.
>
> I had a look to dssi-vst, and fst. But I would prefer 1:1 mapping and
> transparent integration into my DAW. And I think that I can finish it
> quickly so it may be faster for me to write it from scratch.
>
> Thanks again for your advices :)
>
> On Fri, May 3, 2013 at 9:24 AM, jordan  wrote:
> > Hi
> >
> > On Fri, May 3, 2013 at 2:55 AM, Paul Chitescu  wrote:
> > > On Wednesday 01 May 2013 10:37:38 pm Alexandre Bique wrote:
> > > > Hi,
> > > >
> > > > I plan to write a Linux VST bridge to Windows VST. This could improve
> > > > windows VST support in our native DAW.
> >
> > Not too long ago the FSThost and myself, were brainstorming about
> > doing something similar to your idea. it just hasn't been high on the
> > priority list. ~ FSThost is a winelib application for wrapping windows
> > VSTs as standalone apps (single VST host).
> >
> > http://sourceforge.net/projects/fsthost/
> >
> > it's under fairly active development, with a decent feature set;
> > jack_session support. 32/64bit plugins, midi-filters, loading/saving
> > states, gtk+ interface or run without X / no gui, wine-rt / L_pa
> > support, etc...  but obviously, at this point it doesn't have a linux
> > VST backend or some kind of proxy-VST who's plugin API FSThost could
> > tap into (if you wanted to sanbox those VSTs from host), or something
> > along those lines...
> >
> > it may be worth having a look at FSThost - since it's already an
> > existing application that provides a lot of the functionality you'll
> > probably want. ~ it may save work and projects can always use more
> > contributions / collaboration. that being said, i am sure some code
> > would need to be reworked, in order to support using VST interface,
> > instead of jack.
> >
> > another app that is similar to what you want to do is dssi-vst - which
> > from what i gather runs a vstserver - and the IPC is OSC (liblo). But
> > i haven't used it much, really - so i can't say too much about it;
> > http://www.breakfastquay.com/dssi-vst/
> >
> > cheerz
> >
> > jordan
>
> --
> Alexandre Bique

--
Alexandre Bique