Open nshaheed opened 1 year ago
@spencersalazar's suggestions:
yeah I guess one fully shaven yak version of this is
support for variable rate processing graphs (e.g. SinOsc lfo.rate(10::hz) => (scaling, etc) => ug.param;
support for arbitrary math in ugen chains (SinOsc s / 2 => dac;) or something
IMO its super useful to just have arbitrary math/expressions/functions instead of a bunch of one-off ugens for scaling/etc. because then you can easily do like dB, exponential, and various other transforms easily
also unlocks fun stuff like exponential FM
Could potentially do this via ugen syntactic sugar or via chugens
More ideas...
@spencersalazar
IMO arbitrary expressions + multi-rate => params is a game changer
probably 75% of the chuck Ive ever written I could just delete haha
Me:
imagine having an envelope follower ugen and just hooking it up like
adc => EnvFollower e => sin.gain;
@spencersalazar
like 🔥 🔥 🔥
SinOsc mod => SinOsc car => dac;
2 => car.op;
Gain g.rate(10::hz) * hid.mouseX * 100 => mod.freq;
Gain g.rate(10::hz) * hid.mouseY * 100 => mod.gain;
the Gain is kinda unsightly but could have some other syntax for stuff to enter into the signal chain domain
Me:
why not just let there be constants?
0.5.rate(10::hz) => osc.gain;
(aka make everything an object)
This is a potential approach for making lfos hopefully both simpler to use and more aesthetically in-line with chuck as a language. What if making an LFO was this simple?
This would ideally combine the ideas from the Patch chugin and @AndrewAday's tweens and signals proposal.
The Patch UGen
Currently the Patch UGen is a little hacky and takes in a function arg as a string and does member func lookup in-chugin due to the lack of function pointers in chuck currently. But ideally, a Patch UGen will eventually look like this:
This is great! And it works with any member function that is
fun Any someFun(float)
or is a member variable that is a floatWhile this isn't completely general, I think it's good enough until chuck has a more robust type system.
However, this still feels kind of annoying to use (you have to remember to feed stuff into blackhole, p.connect has to be it's own separate line) and it doesn't really feel in-line with how chuck handles ugens in general. However, if the Patch ugen existed in this ideal form there's nothing stopping us from using some syntactic sugar to make this a much more intuitive experience.
The Syntactic Sugar
So in order to get this:
we basically need to have a translation step in the compiler to turn it into:
Doesn't seem too hard! The main hangup I see is when someone disconnects the ugen
This would have to somehow become
Performance Questions
One concern is that not all parameters should be updated at signal rate, or it's recommended against because it's worse performance. In the simple case where it's literally just setting a variable the performance loss really isn't that bad and I don't think would be a bottleneck in most situations. However, when it's needed the control rate could be set like this:
Where rate sets how frequently the Patch ugen calls the update function
One weird quirk would be that if you tried to set lfo.rate later in the program, how would chuck know that it's specifically pointing to
s.phase
Edge Cases
this should be allowed, but
Probably shouldn't
Feature Dependencies