Re: [sc-dev] Towards SC 4

some thoughts

So, with the current state if things being what they are, what are the major changes / major things we want to keep from SC 3 going forward to SC 4?

Will it be worthy of a digit change from the user point of view too?

Breaking backward compat is of course more in the table then not, though anything that does (I think) should be done with good reason. I think a new project should aim to-

- Cleanly deal with future bit changes (64 bit compatibility, and thinking ahead to things we can do to make any future changes easier)

- Would like to keep the basic language and class structure

but... to make consistent updates can always break something.

- retain Qt and the IDE

I don't know what this means nowadays... really. Except for the mac-os-centric people the ide is the best thing that ever happened to sc since sc. I do not mean to provoke people (only) but to make them realize that SC did not work nicely either in linux nor windows. However it is critical to implement the Document interface related to editors and very specially to files.

Aside that I only have thoughts that break things (I'm such a bad boy) related to the class library:

- Improve the class library clarity and documentation (private vs public eternally).
- Modularize the built in libraries -e.g. jitlib, I was agree with its inclusion but we loose some modularity, and it is a particular paradigm which doesn't directly derives from the sc machine- and I mean specially to keep the core classes and method not shared, not overwritten and with neutral names.

- Include useful ("should be there") methods form quarks like mathlib, crucial, ctk, wslib, etc coherently in the core and synced with the quarks.

- Make a rule that quarks should never overwrite built in library methods (I stopped using some quarks because that, breaks things in the worst moment).

- Include crucial .gui semantics (a very nice idea that could be systematic), e.g. as it does with patchs, jitlib and a lot of gui stuff from quarks that generates a slider-based-gui from synth(def) controls and specs. { SinOsc.ar(\freq.kr(440)) }.gui; freq: // 0 --------|--- sr/2
- Make peace all with all once and forever.

- Include a better NRT rendering/score api, the problem is not in the score or calling another process but in the lack of automation of the methods. { ...my patch... }.render(someSecs); // at least
- Include a better NRT rendering/score api.
- Include a better NRT rendering/score api.

- If there will never be any kind of on-the-fly class definition, improve the prototype mechanism, maybe with a special class not interfering with Event, maybe with a syntax shortcut.

As for the overall architecture, I personally could think of reasons to keep the lang / server divide, but also reasons to bring them closer together as SC 2 did... Thoughts?

Confused.

Best

Lucas