Re: [sc-dev] Towards SC 4

[Scott Wilson <i@xxxxxxxxxxxxxx>]

Okay, some more general thoughts, as they come:

- I too have wondered about the separation of language and server, but on balance, it's not too much trouble most of the time, and the benefits of the generalisation that provides are great when you want to deal with multi-user servers, distributed computing, network music, etc. So I think I'm with Jakob and feel that this should be kept, and just made better. One thing I would wonder is if it could be made even more general, i.e. how trivial can it be made to deal with multi-user/single server, single user/multi-server, remote vs local, etc. Currently some of these are sort of special cases.

- All asynchronous GUI, more or less for the same reasons above. We have to assume that the future is going to be more distributed. For prototyping it is very nice to be able to test the code for a distributed setup on one machine (we've talked about this with Utopia), and then only have to deal with network issues. (Yes, I know, 'only'!)

- Think about better integrating some of the available approaches to distributed/multi-process computing (e.g. promises) as 'normal' in the language, rather than as exceptions.

- Rationalise all argument orders. The collective waste of time to humanity from people typing 's,' every time they want to read a local buffer must by now represent a tragic loss of world economic output. ;-) Let's take this opportunity to fix that.

- Resolve, or at least make clearer the question of conditionals in UGen graphs. 'If' UGens, etc., seem to make sense but maybe there's a more elegant approach.

- Resolve, or at least make clearer, the distinction between the sub-languages of ugen graph code and everything else.

- Bounded controls. In 2013 (or 2023 when SC4 is finally ready ;-) it is silly to be able to accidentally mess up your synth by setting a multichannel control with a too large array.

- Make sense of the Control / In / Out / map / set / setn muddle. This is a case of too many ways to do (almost) the same thing, and mucks up what seems to me should otherwise be pretty clear semantics when passing a Bus around. I don't have a concrete proposal, but intuitively I think there should just be inputs and outputs at specified rates (i.e. no artificial distinction between controls and signals), and that these should be named.

- Reduce the number of ways of doing things in general. SC now has so much syntax sugar that diabetes seems just around the corner. Some of these are just personal preference variants, which aren't even more concise (or barely are).

- Similarly, it would be nice if things like the server msg/Synth/Event/Pattern duplication of functionality could be resolved into some sort of 'normal' way of doing things. Again I don't have a concrete solution, and each of those existing paradigms has advantages, so perhaps easier said than done. Possibly something along the lines of Ndefs, which could abstract away busses as well (I *think* that would be nice!), would be a good way to think.

- Fix the conflict between OSC arrays and completion messages.

- Integrate graphics.

- Main interpreter thread functions as a Routine transparently

More as I think of them…

S.
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/