Downsizing the Class Library

[mike]

@jamshark70 arriving at a “standard” way to do things—in terms of documentation, examples, user support—might also suggest what to trim and what not to (there’s a chance i mixed up the context here)

Development Group: class library / sclang

I’ve kept quiet because of other obligations, but feel that the class library is where I can help out the most. (However, due to time zone, and also the fact that semesters get extremely busy, I don’t anticipate joining very many calls.) On the question of breaking compatibility: If we want to do something about the long-standing complaint of “too many ways to do things,” I suppose that a gradual approach might be best. First, identify areas where there are “too many ways,” and decide what sho…

The ClassLib Dev Group meeting touched on this topic:

@mike

Some initial discussion took place…

• The existing directory structure in SCClassLibrary already suggests what might stay and what might better be a Quark.
• Any group implementing this would, in the course of testing, come up with a “Vanilla SC install”, akin to pd-vanilla. This is essentially the goal of the project: to make SC itself “vanilla”.
  • So as a thought experiment: in lieu of consensus or of a successful refactor, what about the possibility of an officially maintained fork: sc-vanilla.
  • • there were murmurs of skepticism, w.r.t. counterproductively growing the maintenance base, but… worth considering?

JitLib surfaces in multiple discussions as a candidate to be Quark’d

@julian is in favour of integrating the functionality into the common library, not of moving it out.

Development Group: class library / sclang

Just to be clear, maybe there was a misunderstanding. Given the fact that JITLib has become a de facto core component, I am in favour of integrating the functionality into the common library, not of moving it out. If anyone likes to help with improving and factoring it, I am very happy to give advice.

@muellmusik sees potential in integrating it (the way buses and node ordering is largely abstracted away) … If that could be abstracted into a middle layer that was clearly part of core…

Development Group: class library / sclang

Thanks Julian! I certainly have no objection to that! I guess the problem is the old one of deciding what is really ‘high’ or ‘low’ level functionality, and what is ‘general’ vs idiosyncratic stuff for a broad swathe of the user base. One could take a number of different views on this, and I’d be curious what people would say, but one obvious subset of functionality to consider is the way buses and node ordering is largely abstracted away. This for me is significant enough to be…

@Dionysis would like JITLib to stay in the core

Development Group: class library / sclang

Sorry if I haven’t understood correctly what has been proposed here but I want to add my +1 to NOT removing JitLib functionality from core. NodeProxys are my preferred style and I know others for which this is the case. Having to use a Quark for something like that would be really inconvenient…

@dsheiba comments on good and bad models in other languages, the role of test coverage in a large library base, also that mono-repos have the advantage of no version-clashes, easy CI/CD, easy testing, easy update procedures

Development Group: class library / sclang

Although I am always in favor of deprecation through an improved implementation, I think SC would loose many users by making their custom written code, compositions and beloved extensions unusable. Already something as “easy” as installing a Quark often results in frustration because it relies on a git which is not a very easy installation on Windows. A heavy transition will also deprecate lots of learning resources. As long as there are unit tests with a good coverage I don’t see the problem…

which is reiterated here, adding also git can be an impediment to new users/students.

Development Group: class library / sclang

Maybe SuperCollider Quarks Web Index and Add infos about each quark on website · Issue #117 · supercollider-quarks/quarks · GitHub helps? As an occasional pd-lurker I found that the split from pd-vanilla and pd-extended to very unfavorable for the userbase of pd, see PD-Vanilla vs PD-Extended: Why such a mess? | PURE DATA forum~ - there should be a good reason to do such fork (b/c many will not follow if it breaks their code) and I fail to see a real justification for such a discontinuation -…

A smaller class library has also shown up on the SC4 Wishlist:

@catniptwinz

A more modular architecture for sc in general, with a smaller “core”. This would ideally make it easier to create “distributions” of sc for particular use cases, and done right, could also make the distinction between the “core” and “periphery” of sc clearer to new users than it currently is.

@jamshark70

Pure Data may be taken as a cautionary tale here, where the core is way too minimal. The Pd community has a curious ambivalence: otoh proud of the way that externals solve the limitations of minimal core, but also skeptical of reliance on externals.

Thinking through concrete examples of what refactoring looks like is useful and necessary, e.g. @jordan has also raised an example in the repo Discussions board Remove Object.as* method to make refactoring easier #6065