Re: Building a Racket client for SC

On 02/03/2021 18:49, [email protected] wrote:
> Me ([email protected] <mailto:[email protected]>) again from another 
> account.
>
> On Tue, 2 Mar 2021 at 10:59, <rohrhuber-g/[email protected] 
> <mailto:rohrhuber-g/[email protected]>> wrote:
>
>     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.
>
>
> That is a wise philosophy, and I'm gonna go with it... in part. 
> However, when you declare UGens in SClang, you never specify manually 
> that number of outputs I was asking about. Meaning, each UGen must 
> have it's number of outputs specified somewhere else, in some hash 
> table that the client presumably looks up before sending the synthdef. 
> But in any case, it would help to know cases of multiout ugens (not 
> the same as multichannel expansion, that is a client side concept).


sclang deals with UGen outputs while generating the synthdef. there is 
no lookup table with ugen specifications. But a Datastructure with UGen 
specificiations would be useful for the implementation of supercollider 
clients. Victor-Bombi created a ugen json:

https://github.com/sonoro1234/Lua2SC/tree/master/lua2SC/genugens

This works for standard UGens ... some behave special and are 
handwritten by him.

You work in a lisp dialect maybe you should check how overtone created 
its UGen definitions.



>
> On Tue, 2 Mar 2021 at 03:10, <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     On Mon, Mar 1, 2021 at 9:25 PM <[email protected]
>     <mailto:[email protected]>> wrote:
>     > 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.
>
>     "/n_map" is your friend here.
>
>     // just defining normal Controls, nothing special
>     a = { |freq = 440, amp = 0.1| SinOsc.ar(freq, 0, amp).dup }.play;
>
>     ~fbus = Bus.control(s, 1);
>     ~fbus.set(440);
>     a.map(\freq, ~fbus);
>
>
> Oh, yes, I knew there was some way to map a control bus to a 
> parameter! However, adding an In.ar for each parameter (which in most 
> cases won't be used) - is that CPU expensive?
>
> I don't think I will anyway, since sending a modified synthdef might 
> be faster than I expected. Last night I was concerned about big 
> synthdefs, so I tried making a synthdef with 700 UGens (25kb). First I 
> made it in SCide, the computer hung for ~10 seconds writing the 
> synthdef to a .scsyndef file. Then I parsed the file from Racket and 
> wrote it to another file in an instant. Sure, this was writing the 
> binary form to a file, not sending it directly to the server, but it 
> seems SClang was the one introducing the delay here.
>