Quark

[ndr-brt]

Hi, thanks for the great work with this library, would be nice to publish a quark to install directly into supercollider.

[v7b1]

yes, agreed. Still have to look into how to do this properly.

[ndr-brt]

Ok, I did some trials.
With the command
Quarks.install("https://github.com/v7b1/mi-UGens")
The quarks is installed, but the eurorack c++ libraries stil need to be compiled and copied into the Extensions folder.

Maybe we can start improving the build script to help people installing it, and defining a *.quark file to show some informations into supercollider, this could be a good starting point

[v7b1]

Thanks for your efforts!
I don't have a lot of time right now to check this out, and I still don't really understand how this is supposed to work: With the method you sketched out, the whole source folder from github is copied to the "downloaded-quarks" folder, ok. But this is not what we want. And as you say, the UGens still need to be compiled. AFAIU we could point the quarks download to a release version of the package on github, but this would mean I need to provide compiled versions of the UGens for all three OS, which I can't right now.
I have a hard time finding any example quarks that actually include UGen plugins. Examples that do rely on server UGen plugins seem to instruct the user to get those in a separate step from the sc3-plugins repository (e.g. SC-HOA). Looks like the Quarks system is only used for sc class files and documentation ?!

[mossheim]

Looks like the Quarks system is only used for sc class files and documentation ?!

that's correct; Quarks is not meant to delivery binaries (yet). last year there was a proposal to change this. right now, SC UGens should only be distributed via manual installation.

[v7b1]

Thanks for the confirmation.

[ndr-brt]

@v7b1 the idea is to make the installation simpler.
Using the quark installation will be possible to handle versioning. Yes, the binaries should be still compiled manually, this could be a first step to a more automated process

[mossheim]

@ndr-brt Quarks is not yet meant to distribute plugins, and to my knowledge there are no other plugins being distributed through it (including sc3-plugins). if you are interested in changing this, i would recommend contributing to the discussion on the RFC i linked above, rather than pressuring individual plugin authors to change their distribution method. Once there are concrete benefits to distributing via quarks (or some other method), it will make more sense for 3rd party plugin authors to invest the time in switching over.

[ndr-brt]

"pressuring" is not a nice word... seems like I'm here brandishing a knife trying to impose a different distribution method.

I'm "proposing". thanks.

taliking about "distributing plugins", I saw a supercollider quark that needs manual code compilation:
https://github.com/supercollider-quarks/MultiTouchPad/blob/master/HelpSource/Classes/MultiTouchPad.schelp

Touchpad support is not integrated into SC at this time, so you need to download, compile and install tongsengmod (an application forked from the tongseng project to be used with SC) to make use of this class. This class handles the execution and termination of the tongsengmod application behind the scenes, so all you need to do is to compile and install it once: ...

[mossheim]

I apologize that my choice of words offended you.

[v7b1]

@ndr-brt I appreciate your suggestions, thanks! I still don't see how 'quark-ifying' this repository would help with the installation of the ugens, though.

I saw a supercollider quark that needs manual code compilation:

yes, but AFAICS that repository doesn't contain the source code that needs to be compiled, but just the sc classes.
If the situation of quarks in sc doesn't change sooner or later (to include plugins), this might be the way to go: have a repository for the plugins sources and a separate one for the sc class files and quark script to facilitate the installation process.
Right now, having separate repositories is not practical for me.