Condition has always been in core, along with Semaphore.
Probably around 2021, I proposed a fix for Condition, for true timeout support. The decision at that time was that Condition wasn’t a real condition variable, and that this would lead to a variety of structural problems down the road, so it would be better to add a real condition variable class, as a replacement for Condition. Since Condition is in core, it made sense to put CondVar in core.
Of libraries, I wouldn’t have a problem with moving some feature sets out of core (even patterns). However, while I can agree that SC’s core library is too big, I’m also not fully convinced by Pd’s concept of minimal core. If you have to install externals to get a decent sounding set of basic filters (sorry, vcf~ doesn’t cut it), that’s a bit dogmatic to me. (Took me ages to find the ELSE library.) Somewhere in the middle is the better answer.
CondVar is an interesting case though – every user, sooner or later, will run into thread sync problems. CondVar and the derivative classes Jordan has been working on are a solution to problems that, when you start with SC, you don’t know you’re going to have. To me, it makes sense to have these available without user action.
Definitely in favour of a smaller class library. JITLib on particular could be moved out. There is also a bunch of old unused code floating around.
What annoys me about quarks is that they don’t have descriptions, and when you go to the GitHub page, most people’s quarks don’t have a readme either. Some stricter requirements might be needed before quarks are added. I’d be in favour of kicking all those that don’t meet the requirements out (after a request to update the description/documentation). There could be some really good code in there, but personally I’m never going to install something with an indecipherable name and no complete description, doubt I’m alone.
Regarding synchronization stuff, supercollider deals with asynchronous relationships in almost every action the user makes because of the server. For that reason, I think this should be baked into the core library in a far more substantial way, and all classes should be more aware that something might wait. One example, if you wait in the .asString method you break the interpreters ability to post window, which isn’t It’s an unreasonable thing for the user to want to do.
Can’t see how you would implement this without altering the c++ language code. Would love this, but it’s quite challenging.
One alternative is if the Quarks installed into a project local directory and scide included that folder when it loaded. This does move away from the file based approach, to more of a directory based approach. Personally, I do this anyway, but many people don’t.
Another useful addition to quarks would be the ability to search for class names and/or keywords.
IIRC, Pure Data’s package manager “deken” lets you search for object names, such as, search for “gate” and one of the search results should be cyclone.
One glaring issue we haven’t discussed is our position on changes that breaks:
people’s supercollider only code,
supercollider code that uses things we consider backend
quarks
The issue with the second point is that there is no private implementation and all the ‘backend’ is actually public, meaning any changes will break something.
We have an ‘ObeaseObjectProgramming’ model where the smallest thing possible in supercollider (Object) is overburden with too much responsibility. Each method in there could be used in all objects in all code.
If we do go down the route of separating things into libraries and decoupling/refactoring stuff - which will break something - how do we deal with this? Do we have a responsibility to be an archive of work, as well as a tool? To be a piano and a historiy instrument museum?
I’m just concerned that we won’t be able to do anything (even splitting things into libraries) if we fully commit to the latter, whilst also don’t want to alienate the userbase. Perhaps some of what has already been discussed might be better under an SC4 name? Or perhaps we have a parallel class library that the user can opt in and out, with the notice SC3 will not be updated? I do not know… if anyone has any professional experience managing such changes please do jump in
The ‘tradition’ in SC is to allow substantially breaking changes for major new versions, which have usually been fairly big rethinks. An SC4 would be great, and would definitely be the time for major cleanup, but would need a large amount of commitment and vision. It’s been discussed for years, with lots of contradictory proposals, so I think it can only happen if one or a few core people really commit to a coherent plan.
Regarding breakage: I think moving some things into Quarks is okay, as long as there’s a reasonably painless way to get that stuff back. eg a download package that included JITLib. We don’t want people to have to hunt around a lot to get back to their status quo.
Regarding async stuff (slightly tangentially): Some years ago I proposed an approach which would essentially move ‘allocators’ into the server. When creating a new Buffer object the lang would assign a UUID which the server would use to identify the object it assigned. This would vastly simplify multiclient situations (which despite being a supposed strength remain awkward), and remove a little async pain in some cases.
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 in having a big code base, and I think NodeJS ecosystem is a perfect example what happens if the standard library is not powerful enough vs having batteries included such as in Python3. So maybe there should be a focus on writing more tests for already existing code?
And there is also the infamous Torvalds quote “we do not break user space” which seems have been proven beneficial by time.
It will be also interesting how Max MSP “vs” RNBO will play out over time? But Cycling74 has probably enough resources to support both applications for a long time.
The question should be which benefits could justify breaking the current code base? I for myself don’t see any kind of feature which would justify this.
edit: Also after working some years in bigger projects I learned to love the mono-repo which just makes life easier: No version-clashes, easy CI/CD, easy testing, easy update procedures
Supercollider does not have non-user space because there are no private methods. Every method is available everywhere at all times. With that in mind, I don’t see how it is possible to make any changes, only add new features, without breaking something.
Breaking everything and implementing access specifies might allow us to never break anything again… that might be worth it.
I think what @muellmusik suggested was that a ‘painless’ breaking of user code might be a pragmatic metric.
As a non-windows user, I always assumed supercollider came with git - if the install process is painful then this is definitely unacceptable based on the idea of painlessness.
This is true in a formal sense, but by convention some methods are marked as private, eg with pr prefix or noted in the documentation. I don’t think there’s any issue with changing private implementation in this way, especially as in most cases the intended public interface is clear. Such changes have been relatively common over the decades for what it’s worth. I think a common sense approach to this is okay.
Yeah. Though to be honest I sometimes think the case for splitting things should consider the specifics carefully and where things are really causing issues. I personally think there is some higher level functionality in JITLib for instance that probably should be provided in core (even if it might ideally have taken a slightly different form) and its implementers have been very good about maintaining it, so I’m not sure it’s a huge debt problem. But those authors have also suggested it might be split off, so I’m not so inclined to object.
I guess it’s the Linus thing of we should look like we care. If that means offering a package with the split off libs automatically included or something similarly easy, I’d be okay with that.
Based on a quick (and perhaps slightly inaccurate) grep there are 2671 methods in Common (not just Core), but only 132 private methods. Leaving us with only 5% of SC to make changes to, considering there are about 180 classes, that is less than one private method per class… I don’t think anything significant can be done in such a small space.
Personally, I’m not in favour of splitting into separate libraries, but I am in favour of decoupling the existing code. I think what has happened is that when implementing some systems, people have made methods public anticipating they might be useful later. One example here is the archiving system, which conceptually has only two methods, toArchive and fromArchive, but actually introduces many methods into Object (all the slots ones), thereby forcing an interface onto all classes. I think there is a conflation between private (this class only), backend (core classes only), public (overideable user methods), and fixed (non overideable but still public) methods which will make changing and improving supercollider impossible without breaking something.
We’d have to ask James, but I suspect it all dates back to the Smalltalk like design, which also has no concept of a private method I believe.
To be clear, I think a significant number methods are implicitly private, and clearly part of backend implementation. Many such are undocumented. Speaking pragmatically I wouldn’t worry about changing those as they’re highly unlikely to break anything. This should be approached case by case of course.
Can you sketch out what decoupling might look like from your perspective?
Decoupling definitely not the word I meant to use!
Perhaps going through, figuring which methods are private and marking them as such might be worthwhile. What I was concerned about was a user accidentally changing an important feature by reusing a name. At the moment, if you want to write a class from scratch you’d need to check none of the method names collide with any of Object’s - I know that’s unavoidable but the list could definitely be shorter. I’ll change these and see what happens. What I might do is make some logging thing that records when every method of Object’s gets called and run some example code to see if there are some implicit private methods. Busy this week though.
I would have liked to participate in this group if my programming skills were good enough… Unfortunately I have no experience with C++ and my programming skills are very basic. (I am not a computer scientist.)
Anyway, I think it would be very useful if SC could support musicXML export, and I tried it for three weeks with a function. You can find it in the following thread
I do not know how many people in this group are interested in such work. I would like to participate in this group if my design could be a starting point for musicXML support in sclang.
Hi @prko - happily no C++ knowledge is needed to get started working on the class library since it is written in sclang. For what its worth, a number of people in this group, and indeed some of the maintainers of the project, come from a musical background rather than computer science.
For those of us that can’t regularly make the meetings, but would like to track the progress, it would be great to see the meeting minutes continue to be tracked.
Now that there are multiple working groups, perhaps a separate wiki of minutes for each group would make sense, or otherwise just a clear title denoting the working group for each entry (more convenient for readers IMO).
I would like to attend the meeting, but it is on Monday 7 August at 2:00 AM here in my local. So I may not be able to attend as I will certainly be asleep at that time.
I will try to attend the meeting, but I would appreciate it if the participants could discuss the classes and methods presented in the following post in case I am not at the meeting:
The methods and classes should be improved, but it seems not bad to discuss their implementation as primitives of sclang as an idea.
I am not sure
whether SPN should be a subclass of the collection class, or a class under the object class. N.B.: Scientific Pitch Notation is a naming system for pitches that combines pitch class and octave.
whether PitchClass could be added independently of @josh’s PitchClass. If it could, where should it be? a subclass of the collection class, or should it be a class under the object class?
I hope that SuperCollider users will be able to create musicXML files by simply using some subclasses of the collection class with sclang presented in the following post to further work seamlessly with their preferred notation software, and I think that implementing SPN and PitchClass is the first step towards making the function in this post a class with a method:
Hi @prko - if I do the next group poll, I will be sure to include better time choices for your time zone - still no guarantee that an acceptable time will be chosen but at least there will be a chance. My apologies for the poor planning. We will be sure to discuss your post.
@mike This strikes me as a good idea - (I would add, looking over the wiki it seems a lot there is out of date!)
