| Newsgroups |
gmane.comp.audio.supercollider.user |
| Message-ID |
<[email protected]> |
> But in any case, it would help to know cases of multiout ugens
There are quite a few multiout ugens. Just open the SC IDE, open the
help for MultiOutUGen and click on "Subclasses".
> Meaning, each UGen must have it's number of outputs specified
> somewhere else
The ".ar"/".kr" methods for multi-output UGens return an Array of
"OutputProxy" instances (or a single "OutputProxy").
Generally, UGens have a "source" and "outputIndex" method. For a regular
single-output UGen, "source" always returns the UGen itself and
"outputIndex" always returns 0. "OutputProxy" is a fake UGen where
"source" returns the source UGen and "outputIndex" returns the desired
output index.
Christof
On 02.03.2021 11: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).
>
> 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.
>