In the Class Lib Dev Meeting @josh floated the intriguing idea of “Project as Quark”
What if your art-work, your project, was a Quark?
When you “open” such a project, Quarks it depends on are loaded and all others unloaded.
You could have .newWithAllLoadedQuarks .newTemplate(\myTemplate) and .newClean methods. These methods would create a directory with enclosed .quark file - set up the sclang.conf.yaml and recompile.
One of the goals is to make projects which can be easily distributed. It would also be super nice to be able to go to a clean setup with no Quarks (and back).
Problems: this can only be a practical approach once the Quark system can install appropriate Plugin binaries!
I use the Quark system to organize all of my projects. It’s really great because you can install all dependencies with it. Recently, hooks were added as well so you can automatically run code before/after install/update/removal which may come in handy. See this commit or check out “Using Quarks” help file if you have the latest SC installed.
I install most C++ based plugins using this Quark:
And Faust plugins may be automatically installed using this quark:
Also, note that if you want to include larger files (like soundfiles) in your quark, you can use git lfs to do so as part of the git versioning as well:
Regards moving more of the standard class library to quarks… we would have to think very carefully about how this would interact as this would make Quark apart of the ‘Core’ functionality of supercollider. Essentially the problem is ‘what happens when Quark tries to install or update the quark ‘‘Quark’’, or any other quark it depends upon?’.
Just looking through the classes Quark makes use of (which would all be required before Quark can be used)
these include…
Quark (obs)
Git
File
Pipe
UnixFile
Routine
CmdPeriod
Thread
SystemClock
Prout (for some reason this is used by Routine bring the whole pattern EventStreamer stuff with it)
LanguageConfig
QuarksGui has all the Gui stuff…
That’s not to say this list couldn’t be trimmed, but Quark is quite complex and requires many parts of the class library.
To be clear, I’m not against this… but it is a big set of classes with a lot of functionality, and if the class library is currently being trimmed, this goes against that.
I’d much rather see this done by a whole new tool, perhaps using it might look like this…
In terminal, or from the IDE’s gui… scproject new MyProject --version=current
This could install the CLASS library in the current folder and makes a sclang_config pointing it to load it when opened. Currently a few things would need to change before that can happen… but it should be do-able.
Then when you install quarks, they are install locally in a folder (perhaps added to the yaml), meaning moving your project is just moving the directory and making sure any version of supercollider 3 is installed.
regarding shrinking the ‘Core’ though - my assumption has been that the parts of the library that are stripped out would be Quarks and so we would need Quarks to be in the ‘Core’ to be able to install these?
OT Routine uses Prout in the method p { ^Prout(func) } I suppose that should be moved to the Patterns.sc file as +Routine{ p {^Prout(func)} } …