Re: [sc-dev] Towards SC 4 SERVER?

[Scott Wilson <i@xxxxxxxxxxxxxx>]

This is actually an interesting idea. Currently Node IDs are arbitrary ints, which makes it easy to have multiple clients node-wise. What matters is that the nodes have a unique ID, and that the total number of nodes is not exceeded.

If busses and buffers worked that way, and if Synths explicitly kept track of buffer and bus usage, it would a) be much easier to deal with them in multi-client situations, and b) we would have the makings of a way to very easily model dependancy. Then node order could be implicit rather than explicit, and parallelism could be inferred.

Nice…

S.

On 18 Nov 2013, at 13:41, olaf hochherz <olaf@xxxxxxxxxx> wrote:

> Hi
> (i am not a developer so don't take it to serious what I write)
> 
> I just read the whole threat and think that one question which could structure the ideas a lot.
> 
> What would be a more musical osc-api to the (newly extended) server?
> 
> The bus system of scserver is actually not "non-musical" it is to streamlined to one concept. but the important thing is that the server would be more easy to use and connectable to other systems when it would be more smart in a musical way. For example some of the things which are programmed in sclang could be part of the server already: the graph-reordering of jitlib for example.
> 
> How much work would that be?
> 
> Following this update of the server interface. Other languages can compete more easily with sclang and we can see what is actually used/done/needed ...
> 
> best
> olaf
> 
> Am 12.11.13 00:06, schrieb Josh Parmenter:
>> 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?
>> 
>> 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
>> - build the language as a set if language plugins
>> - retain Qt and the IDE
>> 
>> 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?
>> 
>> Also, what strategies can we use to start and grow as cross platform, rather then working it in after the fact?
>> 
>> No time lines yet, but I seriously want to open this can of worms. I would be interested in hearing who might be up for this project, planning it together and setting some timelines and mapping out tasks.
>> 
>> Go!
>> 
>> Josh
>> 
>> /*
>> Josh Parmenter
>> www.realizedsound.net/josh
>> */
>> _______________________________________________
>> 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/
>> 
> 
> 
> _______________________________________________
> 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/


_______________________________________________
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/