Quarks vs. Plugins and the search for vbap

Questions
#1

Hi,

I am trying to understand the following:

tells me that plugins are community UGens that run on scserver. And that
“Extensions for the SuperCollider programming language are different”
and are collected within the quarks packaging system.

Now GitHub - supercollider-quarks/quarks: Directory of community contributed Quarks for SuperCollider tells me that
“A Quark is a package of SuperCollider code containing classes,
extension methods, documentation and server UGen plugins.”

So what is the difference between UGens via sc3-plugins and UGens
distruted via the quarks package manager?

In my case I am trying to use vbap
https://doc.sccode.org/Classes/VBAP.html
and I can’t find a quark for it. So it must be a sc3-plugin then?

Confused, thanks for any help!
Peter

#2

yes they are in SC3-plugins.

the online doc file you found, VBAP | SuperCollider 3.12.2 Help,
has this line at the bottom:
helpfile source: [/usr/local/share/SuperCollider/Extensions/SC3plugins/VBAPUGens/HelpSource/Classes/VBAP.schelp]
from which you can tell it is in SC3plugins.

#3

The idea of distributing server Plugins (UGens) as quarks has never been fully realized, though it has been discussed occasionally. For all practical purposes, plugins are installed manually. OTOH language Extensions are typically installed as Quarks, but may also be installed manually.

BTW: one additionally confusing part is that plugins packages also include language extensions, otherwise the plugins wouldn’t be visible in sclang. But these extensions, needed to use the plugins, are part of the plugin distribution, i.e. the don’t need to be installed separately.

PD package manager has been references before. Using an existing package manager would likely make installing both extensions and plugins easier, but it’s a big undertaking to get it right… so for now we’re stuck with the Quarks system, for language extensions only.

Actually, the 3.13 release of sc3-plugins includes a Linux (x64) build. It’s not widely advertised since I’m not sure how compatible it is with different distributions, but it’s worth a try.

#4

The binary needs to be compatible with the server (scsynth, supernova). It should be just fine

#5

BTW: one additionally confusing part is that plugins packages also include language extensions, otherwise the plugins wouldn’t be visible in sclang. But these extensions, needed to use the plugins, are part of the plugin distribution, i.e. the don’t need to be installed separately.
Thank you Marcin, I almost suspected that :wink:

PD package manager has been references before. Using an existing package manager would likely make installing both extensions and plugins easier, but it’s a big undertaking to get it right… so for now we’re stuck with the Quarks system, for language extensions only.
Yes, why reinvent the wheel :slight_smile:
sc3-plugins as Debian package would be totally sufficient (if there were
current versions of sc3 and the plugins available). Can’t comment on the
situation for os x and windows though.

Actually, the 3.13 release of sc3-plugins includes a Linux (x64) build. It’s not widely advertised since I’m not sure how compatible it is with different distribution, but it’s worth a try.
Thanks! As Debian stable currently only provides 3.10 I would have to
compile a 3.13 release of SC myself, in which case I can also do
sc3-plugins on the side. Phew, exactly what I was wanting wanting to
avoid.

much appreciated!
P

#6

This might not work for other reasons, but I don’t think that the plugin interface changed since 3.10 so you might still be able to give the 3.13 Linux build a go.