Quarks and Extensions

Resources Libraries and Quarks
1

you may wish to file an issue on Mads’ Codeberg page!

2

I previously reported some issues on his GitHub projects, but he rarely responds, and I do not have a Codeberg account.

added:

Going back to my initial point:

I may have an imperfect view of Quarks and extensions, but my hope is to use them without installation or usage difficulties. Unfortunately, some Quarks still produce warnings or errors, and not all authors are available to respond to issues or pull requests.

This makes me think that SC users should not rely solely on the built‑in documentation or the documentation provided by extensions but also develop the ability to resolve undocumented problems independently.

At the same time, I feel that documentation, plugins, extensions, and Quarks should ideally undergo a certain level of verification before being released so that users can rely on them with more confidence.

The current situation may discourage some users from using SuperCollider, but it may also encourage more proactive SC users to become more capable and self‑reliant.

3

Hi, this isn’t a discussion thread about quarks. Please move that discussion elsewhere. And yes I am slow to reply on Github issues sometimes because I sometimes have to make priorities in life. If you want to see something done differently you are always welcome to make pull requests or forks, that is the nature of open source, or contribute more directly.

1 Like
4

I submitted a PR three years ago, but perhaps my PR didn’t meet your expectations or wasn’t prominent enough. Sorry for the disturbance, but I would still appreciate it if the Quarks could be published without issues.

I posted this here because, based on my experience, this tends to be the most effective way for some Quark authors to notice and respond — even those who don’t usually reply to issues or PRs.

5

Thank you for the update. It seems that the fix addressed the duplicate instance variable name 'data' issue, which is appreciated.

However, the current installation path for FOSC inside your quark still creates a problem.

Users who have already installed FOSC following the official installation instructions still need to:

  • remove the existing FOSC path from SC-IDE Preferences, and
  • delete Platform.userAppSupportDir +/+ "SuperCollider/downloaded-quarks/Fosc" in Finder (or an equivalent file manager)

This creates extra work for users and unnecessary confusion for beginners.

To avoid conflicts and respect existing installations, I kindly suggest considering one of the following approaches:

  • Do not include FOSC inside your quark, and simply instruct users to install it separately as described in the official guide.
  • Or adjust the installation path of FOSC in your quark so that it matches the directory specified in the official FOSC documentation.

This would help prevent issues for users who already have FOSC installed and ensure compatibility with the original author’s instructions.

Thank you for your work on these tools, and I hope this feedback is helpful.

Added 1:

I opened two PRs related to this:

Added 2:
@madskjeldgaard If you would like to keep the FOSC installation in
Platform.userAppSupportDir +/+ "SuperCollider/downloaded-quarks/Fosc",
perhaps you could consider opening a PR at
Pull requests · n-armstrong/fosc · GitHub to make FOSC a proper Quark.

This would help avoid conflicts for users, as resolving issues caused by bundled extensions is generally not something beginners can easily manage on their own.

Added 3:

If some users happen to find and install your Quark even though you have not officially published or announced it, then of course you are free to structure it however you prefer, and in that situation any issues would naturally be handled by the users who chose to install it.

However, since you have publicly introduced and promoted your Quark, it would be appreciated if you could follow the recommended installation paths for third‑party extensions. Doing so helps prevent conflicts for users and ensures smoother interoperability within the SuperCollider ecosystem.

6

Hi,

I moved some posts to a new thread, as I think Mads is correct that “this isn’t a discussion thread about quarks.”

I’d also gently suggest that the preceding post in this thread is (in my personal opinion, not in official capacity as a moderator) edging toward a bit of an uncomfortable line, where it starts to look like an LLM lecturing Mads on how to fix it and not merely language assistance for a non-native English speaker. I know that “lecturing” wasn’t the intent and I don’t think any CoC rules have been broken, but (tbh) if I were Mads, in this context, seeing a big block of clearly machine written text with a general thrust of “you should do x y and z,” I would just skip past and not read it.

It’s a tricky balance between use of ML tools to facilitate participation in English by members from everywhere on the globe, vs what happens when the posts start to sound like AI-slop tech websites. We’re still figuring all of this out. One broad guideline that I try to keep in mind is, I don’t expect anyone to spend more time reading my posts than I took to produce them.

hjh

4 Likes
7

a big block of clearly machine written text with a general thrust of “you should do x y and z,”

Well…,
After I wrote the initial sentences, I felt they could hurt the emotions of Mads and other readers, so I had an AI correct them to avoid discomfort for the readers (multuple times…).

The very initial sentences I wrote are as follows:

Thanks, but you seem to have fixed only the `duplicate instance variable name 'data'`....

With the current installation path for `fosc` in your Quark, every user who installed `Fosc` according to the `Fosc` installation instruction should remove `Fosc` path from SC-IDE and should remove `Platform.userAppSupportDir +/+ "SuperCollider/downloaded-quarks/Fosc"`. This is very noisy and not understandable.

You should do one of the following:
- Do not include `FOSC` in your quark, but only mention it for the user to install it separately.
- Change `FOSC` path to the folder described in the `FOSC` instruction guide.

You should have respect for the `FOSC` author and other users who already installed `FOSC`. With the current installation path, you may lose the time of users.

In future, I will be very careful in using should. I thought that AI filters inappropriate expressions, but it did not. (At least, using should is better than imperative forms in my own sentences, I felt.)

Mads’ programming is much higher than mine, so I think he may feel that he was insulted by my expressions since one would, if they read advice or guidelines from someone with lower skills, not be welcome. However, I do not really understand why people with better skills announce/publish quarks containing issues… I understand that many users wrote quarks for their own purposes, but when publishing/announcing, it is better that the published/announce quarks work without issues. (Sorry, this paragraph is very uncomfortable and may break some CoC rules. However, I think it is better to write this so as not to be interpreted as if this were written using an AI.)

8

I changed the title.

The initial title gives me an impression as if FOSC’s path is an issue and the responsibility is up to the author of FOSC. However, I think the real issue is that FOSC is installed within the Quarks folder on the local machine when installing Performative, so the responsibility is up to the author of Performative. Please let me CORRECT if my thought is incorrect…

added:

If the way FOSC is treated in Performative is better for dependencies, then every extension, including SC3-Plugins in Platform.userAppSupportDir +/+ "SuperCollider/Extensions" should be moved to Platform.userAppSupportDir +/+ "SuperCollider/downloaded-quarks/ folder, I believe.

9

I’d like to clarify that I don’t think the post was “inappropriate” exactly.

I was trying to say that there’s an area of very clearly appropriate remarks, and an area that is clearly inappropriate, and between them, a quite large area that is ambiguous. I think this post is maybe 5-10% away from the good border of that area.

I guess here that the issue is that quark dependencies should be quarks. I think it’s invalid to list a non-quark extension as a quark dependency. So Mads’ Monolithic should remove the dependency and recommend manual installation of fosc. (Or more broadly, if it’s not a quark containing a *.quark file, then don’t Quarks.install it.)

And, if fosc can’t adapt to being installed in locations other than those it expects, then maybe its file location handling isn’t robust enough.

I think it’s quite common for newly-published code to need a round of testing in environments other than the author’s own machine. SC itself goes through one or two beta versions before each stable release; it would be really rather extraordinary for extension authors to release near-perfection without any community testing. Some initial issues with new extensions are to be expected, I think.

hjh

1 Like
10

A developer has opened a PR to turn FOSC into a Quark: Add a quark file and update installation instructions by dyfer · Pull Request #13 · n-armstrong/fosc · GitHub.

Perhaps I’m being inflexible, but I believed that the original author’s intention for FOSC should be respected, since it was already published as an extension. As a regular user (not a developer), I simply wish that such matters could be settled before a new project is announced.

11

maintainer can certainly accept the PR or not as they see fit - but making it a Quark looks to me a like very sensible change.

12

Then that would seem reasonable. It would be best to remove any remaining manual installation. To do so:

  1. SC3-Plugins should not be installed manually either. In this case, it might be helpful to offer two versions of SC:

    1. a vanilla SC
    2. an SC with the plugins included

  2. Ideally, every package should be published as a Quark, and the following two folders would no longer be needed (though they could remain for backward compatibility):

    • Platform.systemExtensionDir
    • Platform.userExtensionDir

I’ve changed the title of this thread to “Quarks and Extensions”.

13

I think removing the Extensions directories is a step too far. For one counterexample, I have some small extensions that I use but which I’m not going to publish. Those files don’t belong in downloaded-quarks (because they’re not quarks, and weren’t downloaded), so… then I would have to create my own extensions directory and manually add it to the sclang config file? I’m not sure that’s an improvement.

Another counterexample is UGen packs (VSTPlugin, PortedPlugins, OversamplingOscillators, etc). There’s been talk about making it possible to distribute these as quarks, but I don’t recall much concrete progress. (Btw in Linux, some of these packs need to be compiled locally, so there is no option other than manual installation… to remove Extensions locations and make everything a quark, we would either need to require UGen authors to build for all platforms, or implement a mechanism to install system dependencies and build automatically… which, I don’t see that happening.)

Not every point of confusion requires a code change in SC itself. That is, one of the traps in software development is, “an experienced user got confused about something, therefore it’s definitively the software’s fault and we must do something about it.” I don’t think it’s possible to remove all confusion from a programming environment, because the task is inherently confusing. It’s important to distinguish between confusion points that can be fixed and those where alternatives are worse. (As LLMs make it possible to implement changes faster, minding this distinction up front becomes even more important.)

hjh

1 Like
14

I think removing the Extensions directories is a step too far.

As I mentioned earlier, they could simply be kept for backward compatibility.

Another counterexample is UGen packs (VSTPlugin, PortedPlugins, OversamplingOscillators, etc). There’s been talk about making it possible to distribute these as quarks, but I don’t recall much concrete progress.

Regarding FOSC, we also don’t know if the author will merge the PR. Until that happens, users who want to try Performative will continue to encounter the error mentioned above.

In situations like this, the unnecessary time cost is ultimately borne by the users, which is highly unfortunate.

I believe this is one of the main obstacles to broadening the SC user base.

While advanced users can easily work around this, and beginners might not encounter it immediately, it remains a silent barrier. I myself hesitated to bring this up earlier because I already knew how to resolve it locally. I don’t want to create unnecessary friction, but I believe addressing this is important for the community.

15

I’d say, the extension directories should be kept because they were a good idea initially, and they’re still a good idea. :wink:

If I understand the initial issue, users would encounter this issue if they had previously installed FOSC into the Extensions directory. If they never installed FOSC before, then the automatic download by Quarks would give the user only one copy.

Btw another solution, within Monolithic, would be to make FOSC a conditional dependency. Because a quark file consists of SC code, the array of dependencies need not be a literal. It can be constructed based on what already exists in the environment.

(
name: "Monolithic",
summary: "An assortment of extensions for SuperCollider",
version: "0.1",
schelp: "Monolithic.schelp",
dependencies: if('FoscScore'.asClass.isNil) {
	// install only if its classes are not there
	["https://github.com/n-armstrong/fosc"]
} { [] }
++
[
	"https://github.com/dathinaios/CuePlayer",
	"https://github.com/supercollider-quarks/wslib",
	"https://github.com/madskjeldgaard/PolyBuf",
	"https://github.com/scztt/Singleton.quark",
	"https://github.com/davidgranstrom/Pxshuf"
],
license: "GNU GPL v3.0",
copyright: "madskjeldgaard",
ext_dependency: nil,
url: "https://github.com/madskjeldgaard/Monolithic"
)

I think it is practically impossible for extension authors to test a wide range of installation scenarios thoroughly before release. The normal open-source process is probably the best: release, receive feedback from users, and (crucially) extension authors need to be responsive to that feedback. There isn’t anything fundamentally wrong with that process.

I’d agree that releasing public code means accepting responsibility to maintain that code. (But… the “make a quark” PR on FOSC is less than a day old, not much time so far for a response from the author. We also need to respect extension authors’ time.)

I really don’t think there’s a better way than to press the normal open-source process forward. IMO, I would prefer to relax, and not raise broader criticism of community processes.

hjh

2 Likes
16

You’ve completely convinced me!

if('FoscScore'.asClass.isNil) {
	// install only if its classes are not there
	["https://github.com/n-armstrong/fosc"]
} { [] }

And yes — this conditional dependency code is awesome!

17

Re iterating something I just wrote on GitHub.

My view is that we should figure out why this wasn’t a quark, and fix what ever prevented it from being so.

1 Like