Re: [sc-dev] Towards SC 4

On Nov 11, 2013, at 4:44 PM, Lucas Samaruga <samarugalucas@xxxxxxxxx> wrote:

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?

see below...

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.

I think the possibility for breaking things should be allowed. Huge breaks possibly (hence, the need to call it SC 4) - BUT - I think anything that would break something should be carefully examined to see if the improvement merits the breaking.

- 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).

I think a private class interface is a great idea.

- 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.

In general, if we can make a plugin based language, I almost think everything beyond basic types should be quarks (or a quark like structure) where a bare bones language is provided, a set of recommended tools to install, and the rest as extras. Overwriting methods I think should not be allowed as well (while subclasses certainly can).

- 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.

I definitely think NRT as part of the architecture is important as well. I don't think something like Ctk would be needed if we are able to put together a real NRT clock, etc., from the get go.

- 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.

In SC 2, there was no language / synth separation. While this made something much easier (NRT, triggering items based on signal, etc. without an OSC responder), I think the benefit of having one lang instance control many servers (local and remote) and the general safety that the division brought about in SC 3 was a strength. Some thoughts and mediation between the two approaches, I think, should be one of the primary considerations with SC 4.

Josh

Best
Lucas

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono
*/