Re: Building a Racket client for SC

On Tue, Mar 2, 2021 at 6:50 PM <[email protected]> wrote:
> 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?

In.ar is more expensive than In.kr, yes.

Also, be aware of a server-side limitation on the number of audio-rate
connection buffers (s.options.numWireBufs). Control-rate inputs don't
use wire buffers; audio-rate inputs do.

a = { In.ar((0 .. 63), 1) }.play;  // ok

a = { In.ar((0 .. 64), 1) }.play;
exception in GraphDef_Recv: exceeded number of interconnect buffers.

And these interconnect buffers are used for signal processing as well,
so, a large number of audio-rate inputs would restrict the number of
parallel chains you could have in one def.

You could define modulation as control-rate by default, and send a new
synthdef only when it's necessary to promote a control to audio rate.

> 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.

This is almost certainly `optimizeGraph` -- in it, the graph is
optimized, but the algorithm to perform the optimization is not
well-optimized -- I'd expect O(n ^ m) where n is the number of UGens
and m is some figure > 1. (SynthDefs are executed in the server many
times, but compiled infrequently, so it's a reasonable trade-off.)

You could test this theory -- go to SynthDef.sc and comment out line
276 (`this.optimizeGraph;`).

hjh

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