Can I attach an UGen to control variables?

Slinky · Joined: Jan 09, 2009 Posts: 15 Location: Sweden

How to attach a UGen output to control variables?

Something like: UGen => Filter but instead of doing that for data flow I'd like to do a similar thing for control flow (such that the UGen output feeds to a control parameter inside another UGen).

What I'm trying to build is an envelope-modulated filter. The filter cutoff frequency would be modulated by an envelope (simple decay from max to 0). When the UGen triggers, this thing would run also, modifying the filter cutoff parameter.

Is there some built-in simple and elegant way how to achieve this?

Kassen · Posted: Sun Jan 11, 2009 2:20 pm Post subject: Acidic demo

Slinky · Joined: Jan 09, 2009 Posts: 15 Location: Sweden

Thank you!

How did you know I needed it to make some 303-like sounds Very Happy

Kassen · Posted: Sun Jan 11, 2009 2:55 pm Post subject:

I just felt like doing something a bit acidic. I like the blit-based UGens a lot for acid sounds, don't forget to try to modulate the .harmonics() function on those, you may like the result :¬).

radarsat1 · Joined: Mar 14, 2008 Posts: 85 Location: Montreal

The only problem with this approach (and its currently the only way) is that it leads to zipper noise. Every change to the parameter will be immediate instead of enveloped, so you need to step at very small increments to avoid too much noise (in this case, 1::ms), but then this is quite CPU hungry.

It would be cool if there was a way to chuck a ugen at a parameter. I was thinking that perhaps if parameters were actually UGens it might be possible. For example, dac has "parameters" called dac.left and dac.right, which are actually sub-dac UGens. It would be cool if LPF had a sub-ugen called LPF.cutoff. Or if there was some UGen that could take any parameter and UGenify it, like:

Kassen · Posted: Sun Jan 11, 2009 4:36 pm Post subject:

In some cases that would have clear and unambiguous benefits but in this case that will mean calculating new filter coefficients every sample, I'm not sure how expensive that would be.

I do agree that that would be a very natural step to take in the future, maybe after block processing and clearly in some cases like Pan2.pan() we could have that style of modulation nearly for free.

rogan · Posted: Sun Jan 11, 2009 4:37 pm Post subject:

radarsat1

Kassen · Posted: Mon Jan 12, 2009 7:58 pm Post subject:

I think we have a problem here on a conceptual level.

I think a lot of ChucK's syntax comes from this desire to trade efficiently between sound quality and CPU usage; we already have very powerful means of setting the modulation rate (exactly as in my example above), yet it seems that many people don't find this convenient to write.

Basically; what ChucK does do very well here (the variable control-rate) on a functional level isn't experienced as enough by some people in some contexts. I wonder if this is a lack of clear documentation or whether we need some sort of syntactic sugar.

rogan · Posted: Mon Jan 12, 2009 8:43 pm Post subject:

Kassen said:

Kassen · Posted: Mon Jan 12, 2009 9:07 pm Post subject:

Yeah, I think people simply look at ChucK itself without considering something like CSound as a context. Compared to inter-UGen connections the type of structure I illustrated above makes little sense, compared to CSound it's (potentially) quite powerful and sensible indeed.

I'm hesitant about this. Sugar is nice but I'm not sacrificing tricks like making sure modulations occur only occasionally (on a DSP scale) but always at zero-crossings, for example.

I also think that in some cases optimisations in C could mean UGens could have audio-rate modulation inputs that are way faster, without punishment, then CK code could (currently) hope to be. This would -however- lead to inconsistencies that might be in themselves confusing to some; Pan2.pan() is quite different from LPF.freq() if we want to call it every samp; the first is a mere float, the other is a full-blown calculation of Hard Stuff. Another issue is that some UGens, like the various osc's and Gain already do have UGen rate modulation inputs, but without a syntax for extending that beyond the very simple level.

radarsat1 · Joined: Mar 14, 2008 Posts: 85 Location: Montreal

Kassen · Posted: Tue Jan 13, 2009 1:23 pm Post subject:

This would depend on the function being called though. For functions like Envelope.target() or LiSa.playPos() you wouldn't typically want a gradual slide (though in some cases you might, of course). I don't think automatically sliding in all cases would be a good idea.

Right now I'm inclined to wait for block processing before we make definitive choices here. The only real issues right now are syntactic sugar and CPU usage, it's not like we are unable to do anything we might like to do. I'd like to see how much of a issue there would still be if we'd take a lot of that CPU usage away using block processing.