Okay so I was thinking this through. I might start working on some grpc endpoints for processing audio buffers that then return data back to the vst3 plugin to communicate to the DAW. client server architecture to be called as an api from the cpp code.
On Friday, April 15, 2016 at 11:30:16 PM UTC-5 [email protected] wrote: > > > On Sunday, March 6, 2016 at 9:48:08 PM UTC-7, [email protected] wrote: >> >> I know this is such an old topic but I'm at it now myself. Any success >> using Go to build a VST? >> >> Any resource or direction is much appreciated. >> >> > Making a Go VST (or VSTi) plugin would be interesting but there are some > immediate obstacles. VST plugins are platform-specific, and on Windows they > must ship as a DLL, OSX VST's are usually multi-architecture bundles also > dynamically linked, and they are required to interface with a really strict > set of APIs and work with host software which is notoriously finicky about > the plugins. > > Right off the bat, I don't believe it is possible using the standard go > toolchain to make a DLL target. Certain callback funcs must be exposed as > entry points. The function that actually does the audio processing is very > simple, but I can't think of a way to organize anything that cgo could use > to fit the interface required for VST fx, VST instruments would present > many more problems of the same flavor, especially when you get into how the > UI hooks work. > > Probably more realistic, but a much more ambitious goal, would be a VST > host written in Go. Loading VSTs into this hypothetical environment would > at least be possible using the standard tools, but I believe you would have > to make a shim in Go that loaded dynamic libraries (a quite un-go thing to > do). This has been done with other platforms including stuff like winelib > shims for linux hosts loading windows VSTs (of course it helps a lot that > the hosts are in languages with native C linkage). > > It would be very simple to make a VST loader in C++, so the problem on the > Go side means we either need shared memory with a C++ process or we need > IPC that performs well enough for multi-channel audio (think "8 channels of > 24-bit audio with sub 1ms latency" as a minimum standard here.) > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/92bd00de-25f8-4c95-9a91-2d1c1ede3f05n%40googlegroups.com.
