seems to be inherited from SuperColliderAU…
7 Likes
I would really like to try it on windows, unfortunately I didn’t achieve to build it… someone can share the build files… ?
Go to github now. Project is been worked on actively! There are builds for Win to!
So we could run a scsynth instance inside VSTPlugin inside scsynth 
I mean, why … but fun to ponder.
Seriously, though, this is great – currently my only option to embed custom stuff into a Reaper project is plugdata, which is not bad, but patching makes me rip chunks of hair out of my head. I’ll give this a go when I have some time (couple months later…).
hjh
2 Likes
If each scsynth instance has no issues with performance, the idea is not bad at all. I don’t know if several VST plugins can be parallelized like jack2 clients, so that would make sense in some situations, and I’m not sure how the performance would compare.
Any benchmarks for us?
I’m quite sure that VSTPlugin can’t add any parallelization features to scsynth. It’s just a UGen. In scsynth, all UGens run sequentially, no exception.
In supernova, separate nodes running VSTPlugin instances could run in parallel but all UGens benefit from that, nothing special about VSTs here.
I was joking about scsynth within scsynth of course – because it would add complexity to the setup (a lot of complexity) for no real gain in functionality. Engineering effort for no payoff is a net loss (apart from making a YouTube video to say “look at this funny thing we can do”).
hjh
I mean each instance of scsynth will also be a node and could be parallelized, as all JACK application can be
Not in scsynth. Supernova, yes.
hjh
SuperNova only works with one instance. I am really talking about several scsynth instances of the entire program.
That’s off topic, then, as this thread is about running scsynth as a VST plugin (in any host).
If (hypothetically) one loads plugincollider inside VSTPlugin inside scsynth, you wouldn’t have two instances of scsynth that can be parallelized. Plugincollider instances would be subordinate to scsynth and invisible to JACK. With VSTs, the host is responsible for parallel processing, and scsynth isn’t a parallel-processing host, so this isn’t an end-run around scsynth’s single DSP thread.
I suppose I could be wrong there…? But I think the relationship between plugins and their host is pretty much like that. You don’t have Reaper and 50 instances of Pro-Q showing up in JACK – plugins all run within the host. (Qtractor may be an exception, but I never was able to get anything serious done with it.)
There’s something about the topic of parallel processing where any mention of instances immediately conjures up speculation about achieving parallelism as a side effect – I think that’s normally not realistic.
hjh
DAWs only work now with one VST plugin? This country is going down the tubes! I thought there was something going on there for optimization and parallelization.
Even JACK2 does this.
I didn’t say that. Here’s what I did say: “With VSTs, the host is responsible for parallel processing, and scsynth isn’t a parallel-processing host.” Extending this into a general statement about all DAWs is just not a correct reading.
I’ll try plugincollider sometime but I’m not going to talk about this anymore.
hjh
The curious thing is that with Ardour, jack2 is the component doing all this work regarding optimization and parallelization of the graphs.
FWIW, it’s painless to build in Linux (make sure to git clone --recursive --shallow-submodules https://github.com/asb2m10/plugincollider.git) and Reaper loaded it up with no trouble – here I ran a SinOsc.ar(440) using a remote server in the IDE, as described in the plugincollider README – audio pipes through the DAW channel seamlessly.
I think that’s still consistent with what I said. The parallelization strategy is up to the host. If Ardour leverages JACK2 for this, that doesn’t mean other Linux-compatible DAWs will do the same.
If you load multiple plugincollider instances in the same DAW project, then I’d expect the host would parallelize those in the same way that it would parallelize any other plug-ins (or not parallelize them, if it’s configured for single-threaded processing).
What I don’t see in my quicky Reaper test is freestanding JACK clients for each plugincollider instance – not even freestanding scsynth processes in ps. Like I said – these servers are subordinate to the host. So at least, in Reaper, JACK doesn’t have any opportunity to intervene and parallelize beyond what the host permits because there aren’t any scsynth or plugincollider clients. (How Ardour handles it, I don’t know, and I’m out of time to diddle with it.)
hjh
Ok, it was off-topic on the aspect that the " DAW" was scsynth. But apart from that, there is a field to be explored there. I did some experiments, not writing a " daw", but using the work done already in jack2.
Actually the non-daw ( non-mixer to be more specific) is an extreme and radical example of that!
I second the implementation of the CLAP format. It would be really cool, and with more possibilities too.
Actually, it can! VSTPlugin has a multi-threading option that offloads the plugin processing to a helper thread pool, albeit with a delay of one block. I’m not saying it would be particularly practical, but it’s possible 
1 Like
Interesting – didn’t know that. Is it then up to the plugin to multi-thread its own processing?
hjh
The multi-threading is handled by the VSTPlugin UGen. It’s a crude, but pretty effective way to get CPU intensive VST plugins off the main audio thread, as long as you can tolerate the one block delay. Of course, it’s mainly aimed at scsynth. I think I even disabled the option for the Supernova version. Check the documentation for the multiThreading argument in VSTPluginController.open.
1 Like