A simple wrapper class for VSTPlugin to play nice with NodeProxies

This post was flagged by the community and is temporarily hidden.

1 Like

thanks this is great.

the cmd period is an issue that has bedevilled me as well - if there were a way for plugins to survive cmd-period it would make VSTPlugin more useful!!

I ended up instatiating the VSTPlugins in the root group and writing an alternative cmd-. that leaves that group alone (probably not an awesome practice but…)

I understand why you’d want to do this - but I think it also shows some misunderstanding of cmd-. That key combo is really a panic situation stop-gap (in my mind). I only use it when prototyping work as quick snippets, or to make sure I can kill everything because things have truly gone wrong.
As with any programming language, I think it’s good practice to build into your work different levels of stop mechanisms and NOT rely on cmd-. For instance, I usually have a simple GUI or functions that will kill groups, send gate commands to my nodes, or will kill a performance with a double-click of a button. That way I’m not in the habit of hitting cmd-. to stop anything during a regular performance or in the situation like you are stating. Cmd-. Really should kill everything for those times you need to kill everything. Even VST plugins may blow up, and you need a way to stop everything now.

A lot of people’s introduction to SC are the tweets where cmd-. is the only way to stop them from playing. Also a large number of the examples in the SC documentation and examples in the wild require cmd-. to stop. Inasmuch as there are bedroom producers using SC and not necessarily creating software for ensembles, cmd-. is as idiomatic as pressing the space bar in a DAW to stop playback.

We should change those. It’s a terrible practice to model for new users. Examples in the main distribution’s help files should always assign things to variables and release them programmatically. Any examples that don’t do this are, IMO, documentation bugs (and I’d welcome anyone to file bug reports for them).

A lot of people’s introduction to SC are the tweets where cmd-. is the only way to stop them from playing. … examples in the wild require cmd-. to stop …

Just because they exist or are popular does not mean that they illustrate good programming practices. Tweets in particular are interesting in that they exploit bad programming practices to do things that should be impossible for the character count… which is fun to imitate if you’re writing a tweet, but not fun to debug if you’re building something for reuse.

With that said, it’s fine actually to customize cmd-. for yourself. (I have a custom version that gives me a popup asking if I really wanted to stop everything.) But I tend to agree with Josh that the main distribution shouldn’t make exceptions for cmd-. It really is a hard stop.


I apologize for driving the thread further off topic. I don’t apologize for my view on it but I see your point that this thread isn’t really the place for it.

On topic, then… https://github.com/supercollider/supercollider/blob/develop/SCClassLibrary/JITLib/ProxySpace/wrapForNodeProxy.sc shows the standard JITLib way that objects hook up with NodeProxy: by implementing ways to become proxy sources, SynthDefs etc. I haven’t done this myself so I can’t claim to be fluent in it, but the proxy asks the source object to convert itself in various ways, e.g. proxyControlClass (what type of object should handle you as a source?) or buildForProxy (make the thing that will play the source) or prepareForProxySynthDef (get stuff ready). With this approach, then you could do myNodeProxy.source = Vst(...).

It would take some time to wrap your head around the way these methods are called and their expected return values (Julian or Alberto could help here) but then the Vst wrapper would be compatible in the same way that functions, synthdef names or patterns are.


realize i’m coming a bit late to this, but:

@droptableuser, this is not an appropriate way to address other members of this forum. everyone is here to learn and share ideas. we should encourage open-ended discussion rather than shut it down, or at least direct it into a new thread if you really do feel like it needs a new home. a more respectful way to say the same thing is “i don’t think this is very relevant to what i wanted to discuss here. please start a new thread if you want to continue talking about it.”

as a reminder, the code of conduct that governs our community spaces can be found here.


you’re right. i was out of line and apologize. i’ve deleted the comment

1 Like

Thanks. I appreciate it.

1 Like