[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] Towards SC 4



Hello,

2 (meta-) thoughts:

(1) How about setting up/applying for (a grant for) an SC developer gathering where SC4 could be outlined and  discussed in persona? Would anyone be up for this? 

(2) What about (officially) extending an existing state of the art programming language such as Ruby ( https://www.ruby-lang.org/en/ ) or JavaScript with 
	(a) guaranteed realtime waiting (as crucial for musical tasks) and
	(b) synthdef generation?

I have the feeling that Ruby is pretty close to SClang, however it lacks both the rt features and the extensive music-oriented library of SC.

The benefit of going in this direction would be that we gain a lot of knowledge and external libraries that will work out of the box and help people in their projects.

cheers
	Till

On 12.11.2013, at 14:52, Jonatan Liljedahl <lijon@xxxxxxxxxxxx> wrote:

> This reminds of something I've thought about a lot but never got
> around to implementing: A stack based synth engine. So instead of
> having a graph/tree, you have a signal stack and a linear array of
> units. Each unit pops from and/or pushes to the signal stack. I think
> this would make it quite easy to repatch algorithmically on the fly,
> etc..
> 
> On Tue, Nov 12, 2013 at 12:35 PM, Kuivila, Ronald <rkuivila@xxxxxxxxxxxx> wrote:
>> Hi all,
>> 
>> A question is whether SC4 would monkey with the server.
>> Here are some wild-eyed ideas for that:
>> 
>> use NodeProxy ideas to restructure the server:
>> 1. Organize synths with an Order (in the manner of NodeProxy) and ditch the node tree
>> 2. Wild card message targeting based on Order indices (i.e., 1.* goes to all synths whose index is in [1.0, 2.0) ) (to replace groups)
>> 3. Wild card targeting for manipulating collections of synths (pausing, moving to a different index, etc)
>> 4. "Local" Buses that are selected by the integer portion of the synth index (so LocalOut.ar(offset, x) would repatch if the synth is moved to a  different integer index)
>> (Definitely half-baked at the moment, but you get the basic idea.)
>> 
>> comment: indices might be made more hierarchical with IP-like addresses  as in 1.2.3
>> 
>> 5. Soundfile player ugen that allocates its own buffer
>> 
>> 
>> RJK
>> 
>> 
>> On Nov 12, 2013, at 4:37 AM, Julian Rohrhuber wrote:
>> 
>>> Here are some issues for the list:
>>> 
>>> (A) Method call extensibility vs consistency and reliability
>>> =============================================================
>>> 
>>> (1) Current problem with the dependency model is that you get dangling references. This basically reintroduces problems that the garbage collector solved.
>>> 
>>> (2) Allegedly, the method table is becoming slow (I haven't measured this, but Tim mentioned it). But when you have to avoid adding methods and classes, code quality can suffer.
>>> 
>>> (3) Object prototyping with Environments is not safe, because pseudo-method names may be overridden by an extension to the superclasses of Environment, including Object.
>>> 
>>> (4) On the fly inclusion of functionality on a class-library level
>>> 
>>> The solution to these problems touch areas beyond my competence. Anyway, here are some ideas that I could think of:
>>> 
>>> Extend the class Object by one extra slot that could hold a reference to an object containing any of the following:
>>> 
>>> (a) dependants dictionary
>>> (b) method extensions / uniqueMethods
>>> (c) meta data and ad hoc features
>>> 
>>> This extra slot could be restricted to non-literals for efficiency. It would add quite a bit of memory requirement, but could directly solve (1), indirectly improve (2).
>>> 
>>> (3) could be solved by either
>>> (a) adding a methodless class (ProtoObject) on top of the tree
>>> (b) by allowing objects to block method calls
>>> (c) allowing uniqueMethods to override existing methods
>>> 
>>> (4) Has been discussed on this thread, yes, this would be very nice, and might make (3) unnecessary. It might be hard to optimise the method table on the fly though? I suppose there are algorithms that exist for these things.
>>> 
>>> 
>>> (B) Duplicate or fragmented implementations
>>> ===========================================
>>> 
>>> Doing the same thing in different ways makes it often hard to understand the system. At the same time it is an important feature (occam's razor doesn't apply here necessarily). Most of the following could be done in 3.8 already, I think, but it is a time intensive and error prone process.
>>> 
>>> 
>>> (1) GUI-redirects (do we want to keep them?)
>>> (2) Move non-ugen classes from sc3-plugins to Quarks
>>> (3) Move useful methods from Quarks to Common
>>> (4) Mark all Quarks how much they are maintained, perhaps refactor and regroup some quarks.
>>> (5) Server and Plus-Gui extensions need refactoring. (https://github.com/supercollider/supercollider/wiki/notes-for-refactoring-the-server-implementation)
>>> 
>>> 
>>> [I guess the list is rather long, adding to what others have said, we'll probably have to move to a wiki]
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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/
> 
> 
> 
> -- 
> /Jonatan
> http://kymatica.com
> 
> _______________________________________________
> 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/