| Newsgroups |
gmane.comp.audio.supercollider.user |
| Message-ID |
<CAN4YmRHETKsTKJykc=hJmtb6SmsxgzpcJZK2HuLbKd-0rwNaSQ@mail.gmail.com> |
Interesting, this is the kind of info I needed! Also I love Bombi's
experiments.
That json is pretty much equivalent to the hash table for ugens I was
writing, except for two things:
· arguments for .ar and .kr versions are specified independently - are they
really ever different?
· ugens apparently have a parent - what for? what do they inherit from it?
As for Overtone... it being a lispy language would make it easier for me to
read, but other than that it's no difference. All I need to know is the
informational structure, so things like this Json save me from a lot of
headaches.
On Tue, 2 Mar 2021 at 13:35, <olaf-xpEK/[email protected]> wrote:
> On 02/03/2021 18:49, [email protected] wrote:
>
> Me ([email protected]) again from another account.
>
> On Tue, 2 Mar 2021 at 10:59, <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]> wrote:
>
>> On Mon, Mar 1, 2021 at 9:25 PM <[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.
>
>
>