cgo + vst

[atomly]

Has anybody by chance given VST coding in Go a shot?

I no longer want to write C or C++ code, so it seems like Go might be my best bet at this point. Just wondering if anybody else had ventured down this path and if so, if they had any advice, etc...

For those who are unaware, VST is short for "Virtual Studio Technology," which is a standard developed by a company called Steinberg, makers of Cubase, one of the more popular pieces of music production software, which allows people to write plugins for virtual effects modules and virtual instruments (the later VSTi standard). It has caught on and become one of the most popular formats for virtual effects and instruments.

If you're curious at all: http://www.steinberg.net/en/company/developer.html

:: atomly ::

[ ato...@atomly.com : www.atomly.com  : http://blog.atomly.com/ ...
[ atomiq records : new york city : +1.347.692.8661 ...
[ e-mail atomly-new...@atomly.com for atomly info and updates ...

[Mike Hughes]

Not personally, but I think that channels and go routines for audio signal processing could be phenomenal!

Is there any recommended (non-Steinberg as I don't have a developer account yet) guide on how to implement the API?

If I find the time I'll happily sign up for a dev account and go hunting, but if there's some nice 3rd party overview of what API needs to be defined to implement VST I'd be very interested to read it.

Mike.

[Matt Kane's Brain]

I have an audio project underway, although it isn't VST related.
"goop" is another.

Since go MUST be where main() was called, having a VST plugin written
in go is not exactly possible, except maybe with a Go host. You would
need to write a shim in C++ that uses some IPC method to communicate
with a go subprocess. This probably hurts performance some, but Reaper
does it on OS X to support 64-bit, 32-bit, and PowerPC plugins in the
same project.

Does VST have bindings for other languages besides C++?

> --
> 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 golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
matt kane's brain
twitter: the_real_mkb / nynexrepublic
http://hydrogenproject.com

[atomly]

On Mar 25, 8:06 am, Mike Hughes <intermer...@gmail.com> wrote:
> Not personally, but I think that channels and go routines for audio signal
> processing could be phenomenal!

Yeah, I could really see Go being great for this type of app if it's
possible to pull off.

> Is there any recommended (non-Steinberg as I don't have a developer account
> yet) guide on how to implement the API?

This might be a little outdated, but could be a place to start:

http://asktoby.com/#vsttutorial

There is also JUCE, a C++ project that is designed to allow people to
easily write cross-platform audio software, including writing a plugin
once and being able to use it as VST, AU, etc..

http://rawmaterialsoftware.com/juce.php

JUCE's specific VST wrapper class:

https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp

[abed....@vinelab.com]

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.

Cheers,

Abed

[james0...@gmail.com]

On Sunday, March 6, 2016 at 9:48:08 PM UTC-7, abed....@vinelab.com 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.)

[Justyn Temme]

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.