Re: Building a Racket client for SC

Hi,

as far as SynthDef building is concerned, I'd recommend you to first cover all possibilities. Do the simplification on a higher level. Then you don't have to care about those details later and experiment with systems on top – you don't know what you are going to need later.



> On 1. Mar 2021, at 14:23, [email protected] wrote:
>
> Hi! I'm building a Racket client for SC and I have a few questions about design, because I'm at a point where I might regret some choices later.
>
> So far, I've built the part about parsing .scsyndef files into a client side representation and viceversa, from a client side representation to the binary scsyndef format. I've assumed you send synthdefs via OSC using more or less the same binary representation. I'm happy with the result, but I don't know to what extent I can simplify things:
> · In the scsyndef representation, ugens have a list of outputs specifying their rate, like [kr kr kr]. First of all, is there any case where you would have 'kr and 'ar outputs from the same ugen? And second, what are some cases of ugens that have multiple outputs? Because so far I've only seen the Control ugen that SClang generates automatically for the synth's parameters.
> · Because of this, ugen inputs have two indexes, one for the input ugen, another for which output of that input ugen, which seems to be always 0 for the reasons above.
>
> Also, a few stylistic choices I'm pondering, tell me if there's something wrong with them (I haven't used SC for a couple of years). My philosophy on this is mostly about making it easier to use, more accessible, but always leaving some option to do things in a more technical fashion:
> · instead of having to declare an Out.ar at the end of each synthdef, the last expression will be automagically wrapped around one and an out parameter will be added to the synthdef before sending it to the engine or writing it to a file.
> · for this reason, synthdefs will have a rate (ar by default if unspecified, but kr in case it's something you would rather output through a Out.kr)
> · ugens like Out, SendReply, XOut, etc... will be classified as sender-ugen subclass. Those won't be wrapped around an Out.
> · no distinction between synths and groups.
> · I guess there's no way to make all parameters susceptible to modulation other than creating an In ugen for all of them, but that might introduce a performance penalty. The other alternative would be making synthdefs and calling them on the fly, but that wouldn't be very efficient in some contexts. In this respect, I prefer Puredata's flexibility and the fact it makes no distinction between ugens and synths.
> Of course, that also has to do with the fact that Puredata uses what I call 'static polyphony': if your synth is gonna use a maximum of 9 voices at the same time, you just create 9 instances of such synth and leave them there, even if silent. This way, creating a synthdef on the fly that automatically includes an In.ar for the modulator is feasible.
> However, the 'dynamic polyphony' that I think is more common in SC culture (where you create and kill synths for each note) imposes restrictions on flexibility to make sure the calling of synths is fast enough.
> One advantage of focusing more on 'static polyphony' is that it would let me do away with the group/synth/ugen distinction that always bothered me so much, using instead Puredata's boxes-within-boxes representation on the client side (later transformed under the hood into a more Sc-like representation).



_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/