Re: IPC between linux processes and wine processes
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 bique.alexan...@gmail.com 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 triplesquaredn...@gmail.com wrote: Hi On Fri, May 3, 2013 at 2:55 AM, Paul Chitescu pa...@voip.null.ro 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
Re: IPC between linux processes and wine processes
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 triplesquaredn...@gmail.com wrote: Hi On Fri, May 3, 2013 at 2:55 AM, Paul Chitescu pa...@voip.null.ro 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
IPC between linux processes and wine processes
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
Re: IPC between linux processes and wine processes
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
Re: IPC between linux processes and wine processes
Hi On Fri, May 3, 2013 at 2:55 AM, Paul Chitescu pa...@voip.null.ro 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
