Rack: LV2 plugin

[Be-ing]

Are there any plans to make this an LV2 plugin? If not, would a pull request for this be accepted?

[AndrewBelt]

Not a bad idea! It would be a good idea to wait until the VCV Bridge is released and make a pull request which adds an implementation to that repo.

[falkTX]

I think the idea here is to have Rack as LV2 plugin itself, not to load other plugins
(although considering LV2 has official CV port support, it's a perfect fit for this app)

Making Rack work as LV2 plugin involves making the usual things for a plugin version:

• no global variables
• abstract engine (seems to be already the case, mostly)
• being able to run at variable buffer sizes and sample rates (seem to be the case too, not sure)

Getting rid of the global variables is the main issue I believe.
I'd be willing to help getting Rack working as LV2/VST plugin, it fits nicely into my DPF stuff with its use of openGL stuff.
(See https://github.com/DISTRHO/DPF)

[AndrewBelt]

I'm not interested in making Rack a plugin in any form, sorry. However, you're welcome to try in a fork.

EDIT: The VCV Bridge will be added later which will allow VST/AU/etc plugins to interface it, not built-in to Rack itself. See below for details.

[Be-ing]

I'm confused. The website seems to say otherwise:

connect it to your favorite DAW using the Rack Bridge VST/AU plugin (coming soon)

So you're planning to make Rack capable of loading VST & AU plugins?

[teotigraphix]

Maybe he is talking about the abstraction needed in the Rack framework itself, seems like VST/AU doesn't care about how you code it since it's a wrapper? LV2 is for Linux right, so they are saying there is a certain format for your DSP code?

[falkTX]

LV2 is not for Linux, it's a generic API like VST.
It is mostly used in Linux because that's also where most opensource stuff is, and LV2 does not have the license issues that VST has, thus making it a better option for opensource projects.
VST already existed for a long time, and LV2 is kinda new, so VST kinda got a monopoly in plugin formats.

[teotigraphix]

@falkTX Ok, thanks, so what is the deal about global variables? Is it technical or design oriented?

[falkTX]

that's something when designing plugins in general.
hosts will likely run multiple instances of a plugin, sometimes in different threads. if your plugin has a global variable, multiple instances will access them at the same time. this leads to all sorts of issues..

[simonvanderveldt]

Would really like this as well.
Also, as falkTX already hinted, LV2 support for modules would also be nice, especially since LV2 already supports CV.

[jackokring]

As long as the MIDI sync is good, One of those loop back audio drivers should work for recording. I'd be more interested in a VST 32 bit for tablet pc.

[AndrewBelt]

The VCV Bridge module will be a socket server. The VST, AU, and potentially AAX and LV2 plugins will be tiny codebases that are simply clients of the VCV Bridge protocol. What I was saying is that I won't embed Rack into a VST because that require global "knowledge" of a particular IO source per Rack, while the Rack engine right now is completely agnostic to the modules inside it. It's up to the modules to do IO, not the engine.

[teotigraphix]

So basically what you are saying is the Rack is just running the API abstraction as a shell and has nothing to do with the DSP?

[AndrewBelt]

Exactly. Rack doesn't know anything about audio. Its engine just copies float values along cables and then calls step() on all the modules. I plan to separate Core from Rack, but there's no real reason to, and there are difficulties on Windows with dlls and dynamic linking.

[teotigraphix]

Nice, yeah I was looking at the source last night, very tight framework and easy to follow. So basically implementing step() and creating the UI view/resources is about it for a module, should be interesting to see where this goes.

[Be-ing]

What if the plugin input & output was represented in Rack like an audio interface?

[jackokring]

like an extra MIDI, audio in and audio out option?

On 12 September 2017 at 21:27, Be [e-mail] wrote:

What if the plugin input & output was represented in Rack like an audio
interface?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/VCVRack/Rack/issues/44#issuecomment-328974723, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAkQlYpfIneRXWJMackL_Bj_MxX3rjhKks5shulPgaJpZM4PUseq
.

--
http://www.kring.co.uk

[jackokring]

Automation controllers? -> CV box would be excellent.

On 12 September 2017 at 21:30, Simon Jackson [e-mail] wrote:

like an extra MIDI, audio in and audio out option?

On 12 September 2017 at 21:27, Be [e-mail] wrote:

What if the plugin input & output was represented in Rack like an audio
interface?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/VCVRack/Rack/issues/44#issuecomment-328974723, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAkQlYpfIneRXWJMackL_Bj_MxX3rjhKks5shulPgaJpZM4PUseq
.

--
http://www.kring.co.uk

--
http://www.kring.co.uk

[falkTX]

I imagine a supposed plugin version would have a static audio and midi IO that cannot be removed.
and adding new IOs would be possibly blocked.

[AndrewBelt]

^ @falkTX is correct. You'd have to impose some limits on the modules.

[ssj71]

You'd have to impose some limits on the modules.

that sounds fine to me, as long as there is some session management type stuff (so when I close my daw and come back a month later the same patch appears). The latter part sounds a bit tougher with the current architecture if I'm understanding properly.

[AndrewBelt]

I don't really want to resolve this issue on my own time, but once VCV Bridge and its corresponding VST/AU plugins are released, I'd gladly take a contribution implementation of an LV2 bridge plugin.

[AndrewBelt]

Thanks @falkTX! I used your carla-discovery-native utility to help me test/build the Linux x86_64 native VST2 bridge plugin.

Here's a deal. If someone can supply me with some very minimal source archive of a "gain" plugin with a single parameter and a script with nothing but direct calls to gcc etc. to make a complete LV2 plugin, I'll add Linux x86_64 LV2 to the build system. I don't want to sift through a makefile/CMake/autoconf script to figure out what I can rip out, but I'll be happy to look at some straight command line calls. I don't know about other people, but it's 10x easier to understand a build system by doing that than any other build system, and 100x easier than cloning the build system from an IDE.

[falkTX]

well, you might want to consider DPF, which uses opengl for UI and works cross-platform.
so instead of implementing vst, lv2, and other stuff, you implement a single API.
I made it purposefully to be as small as possible.

I started some docs, but it's not completed: http://distrho.github.io/DPF/
And a bunch of plugins here https://github.com/DISTRHO/DPF-Plugins/
(they use a simple makefile system, no autohell, waf, cmake, etc)

But as your request, here's a simple lv2 plugin with only a makefile and its C code (plus the meta-data used by LV2):
https://github.com/moddevices/mod-plugin-builder/tree/524faa79f30e1471b67a866a04b39008ae077173/plugins/package/eg-amp-lv2/source

LV2 has a steep learning curve for new developers though, specially handling events (like MIDI, Time and UI messages).

Question though.. are you here talking about hosting plugins or having VCVRack working as a plugin?

[AndrewBelt]

I'm talking about a plugin which is a client of the VCV Bridge network/socket protocol.

The VST/AU/AAX/LV2 plugins will have no GUI, just a single slider handled by the host specifying the bridge "channel". It should be an integer from 0 to 63, but if integers aren't supported, abusing floats is okay. For now, just stereo input and output, later MIDI input (instrument mode). It'll send the buffer to Rack, it'll "come out" of a module, you send audio back into the module, and then it sends a buffer back.

I only care about Linux support because of the few LV2 users, most of them use Linux. In fact, I didn't even know people used it on other platforms at all until you said that. Shouldn't too hard for someone to edit my Makefile build system to run on Windows or Mac though.

Thanks for the mod-plugin-builder link.

[falkTX]

So if I understood correctly, this is going to be a VCV plugin that hosts other plugins - a wrapper around VCV and other formats.
In this case, you need some LV2-host code, not LV2-plugin. Is this correct?

[AndrewBelt]

No, it will be a plugin you use in your DAW like Ableton Live. Place the plugin on a track, and select a channel from 0 to 63. The plugin will connect to the VCV Bridge server running by the standalone Rack process on 127.0.0.1 or a socket. Add a Bridge module to Rack with the same channel as the VST/etc plugin, and audio will "come out" of the Bridge module.

[DarSwede]

I’m certainly lovin it!

[AndrewBelt]

Closing, since this feature won't be added to Rack itself but might appear in Rack for DAWs described in https://vcvrack.com/manual/FAQ.html#is-vcv-rack-available-as-a-vst-au-aax-plugin-for-daws.

[Be-ing]

I just remembered about this software after not paying attention since opening this issue 2 years ago. I'm disappointed that the upcoming "Rack for DAWs" will be proprietary. I would not be surprised if someone forks Rack v2 to implement Rack as an LV2 plugin.

[AndrewBelt]

LV2 Linux support for Rack for DAWs is not confirmed but will be evaluated.

[Be-ing]

That's beside the point for me if it's proprietary.

[Be-ing]

Rereading this old comment, is that still the case since deciding to make "Rack for DAWs" proprietary? Would you still accept a pull request implementing Rack v2 as an LV2 plugin?

[AndrewBelt]

Probably not, it's super low priority.

[Be-ing]

I understand it's a low priority for you; that doesn't mean it's a low priority for others. Why would you not accept it if someone else did the work? Is it such low priority that you wouldn't even want to spend time reviewing a pull request?

[AndrewBelt]

PRs like that take a few hours/days to review and test, not <10 minutes. You can maintain it in a fork if you remove the "VCV" branding though. See https://github.com/VCVRack/Rack/blob/v1/LICENSE.md. If you made a fork, I'll remove LV2 Linux from my list of plugin architectures to consider for Rack for DAWs, since its existence would make it useless for me to spend time developing, releasing, and marketing an official LV2 plugin.