Looking at vcpkg for Windows readline
Or - could vcpkg be used for universal libraries build on Mac in the future?
Does CI have vcpkg? If it does, then we can use it for some dependencies.
James will look more at vcpkg best practices
5713 - Gianluca thinks we should shrink it down a little with mDone flags
Should be ready soon
How far should we go with adding these on a test suite?
2 more commits coming - one updating what is using this macro, the other with tests
5718 - will update to make sure tests outside the IDE are running ok… Gianluca pushed changes then will approve and MERGED
5702 - looks fine (brought up system libraries question that is somewhat outside this PR - but we think should be on the look out for this)- merged!
=> Please take a look at the dev-board @ 3.14.0 · GitHub to see for open tasks for the 3.14 release
We will also deprecate GitHub milestone in favor of projects - please use them exclusively from now on.
All PRs/Issues regarding the new kwargs functionality should become part of 3.14 release so this feature doesn’t get introduced incremently across releases, so there should be an emphasis on those.
Take a look @ 3.14.0 · GitHub for outstanding issues/tasks/PRs for 3.14
Overview of the future package manager (Dennis and Scott)
Council structure
The council structure should be represented as GitHub teams for the SC repository - this allows to rework repo-permissions and also mentions of the team in review
tricky in regards when using bluetooth devices b/c in this case the input sample rate w/ 22 kHz - this can create problems for people who can’t spot a 22 kHz output sample rate
Reaper doesn’t seem to fix the input sample rate which could create problems - dyfer will reach out to the reaper team and ask them if they could put the device into exclusive mode in order to not allow for sample rate changes
Marcin and Dennis will communicate in the forum dev-chat a final deadline (which will be between 2025-06-03 and 2025-06-08) by which all PRs have to be merged for making it into 3.14.
After the deadline we will publish the first release candidate (RC) to the public.
If no bugs can be found within one week, this will become the official release.
If bugs are found, we need to do another RC (recursively) until we hit the base condition of no bugs.
Add WebSocket support for sclang by capital-G · Pull Request #6615 · supercollider/supercollider · GitHub => Primitives will be included after 3.14, but SC class library code will be developed in a Quark in order to have quicker iterations in the sclang side. Maybe it would be possible to instead go for a C-API/FFI implementation so we have “Primitive extensions for sclang”. Either expose interpreter mechanics (like in Python) vs lua-approach which exposes the stack based approach (keeps internal access to objects)
We will merge #7166 to the develop branch such that it can be tested on a wider variety of configurations and after successful feedback we will have a 3.14.1 release.
The tests of the PR will be reviewed by elgiano, afterwards it can be merged.
We have reports that true - 1 (Marcin) can trigger a segfault as well - we are unsure if this is related, but we are looking into it. => Turns out this is not related.
The literals are not really usable.
Instead of deleting this from the documentation the PR could instead add a warning, explaining that this should not be used as it is not working as expected.
If we decide to deprecate this properly Jordan has an idea how this could be implemented properly as a new type which can be used by degreeToFreq etc., but this should be reflected upon the actual usage.
Maybe instead of deleting the documentation it can be wrapped by a warning?
Pinged James Harkins if issues have been resolved.
Symposium Videos
Dennis will create a call to improve the audio situation of videos.
He will also create a post to mention that these will be uploaded to YouTube, so it is also clear who to contact to take those down.
Baryon
Dennis showed some key-concepts of Baryon, a WIP package manager for SuperCollider quarks and server extensions which has the goal to make project packaging easy and reproducible, such that (older) projects are working on new machines and have an easy setup (ideally: one command).
It will consist of a package index, a backend server through which packages can be added and on which binary files will be hosted.
Currently the backend is implemented and dependency resolving works, next step is to make the publishing of packages work.
Once a first working version is available it will be available for testing before making it available to the public.
Ideally this will be finished for 3.15 - since 3.15 breaks the plugin API, all server extensions have to be re-compiled - and ideally uploaded to baryon.
Next meeting
Next meeting will be organized for the beginning of November.
