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

Re: [sc-dev] Towards SC 4



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/