Some more Basic Feature requests

[kijjaz]

and I hope chuck can do more console things hmm..
for example....
connect to FTPs... telnet..
wget some stuffs.... connect to www... (text-base is ok hahaha)
log on to IRC... and chat with us!!! -_-"
oh this sounds like a ChucK server.

hmm i'm really interested in the IRC idea now.
is there a simple way to do it with this version of ChucK?
- - -

some more feature requests again:

I'd like ChucK to be able to write and modify a ChucK source...
not neccessarily by writing text to a file..
but right there from the memory..

for example...

["SinOsc s => dac; second => now;",
"s.freq(10000); second => now;"] @=> string Code1[];
somekindofa spork ~ Code1 => int ShredID;

to run the code right away..!!

[kijjaz]

I'd love to have UGens that perform signal transformation with these mathematical operators.
(inspired by how easy I can do it in SuperCollider)

Abs (should be the same as FullRect)
Floor, Ceil, Frac (output only the fractional part of the incoming signal value)

this Frac would be nice for simulating the syncing of Phasor

Sign (output = -1 if negative, output = 0 if zero, output = 1 if positive)
Squared, Cubed, Sqrt, Exp
Mtof, Ftom (for conversion between midi note number and frequency)
Log, Log2 (log base 2), Log10 (log base 10)
Trigonometry functions (also arc and hyperbolic)

[rogan]

@ Kijjaz -- I can totally see how these would be useful, but as UGens, they would have to evaluate every single sample, and this might be a bit much (especially once you get into trig, log and hyperbolic evaluation of the input signal).

What would be interesting is to have different control rates. I've talked to friends about how it would be cool to have different blackholes, that ticked at different rates -- but I'm guessing this would screw things up, because UGens like SinOsc are probably coded as a time-series, that need to evaluate once per timestep in order to keep the frequency on time....

Anyways, that was a bit convoluted, but it's my 2 cents....

[kijjaz]

Yes, I agree. that can be implemented to this kind of UGens also.
For example, we can set 64::samp => (The Operator UGen's Name).kr;
and it'd calculate every .kr

One thing I want it this way is because there are many cases that I just want to do the calculation really every sample,
but don't wanna program a function and spork a shred for that.
especially in live situation where i wanna program quickly.
so with that, more CPU Consumption is okay because we can get the result that we want.

One thing that's gonna be very easy with this,
is designing a feedback system / dynamic system that has these functions as a part of it.
It'd be very easy to connect all the functions in 1-2 lines
and produce very exciting result, without having to spork anything.
and if the user wants to adjust it to be more efficient if some UGens need not to be calculate at sample rate,
kr can be set for an individual UGen.

Hmm.. What do you think?

[Inventor]

I would like to also chime in by mentioning that having these functions as kijjaz describes would enable creative use of ChucK in unexpected ways. For example, I was able to implement a sample-rate neural net by using existing ugens but could not also implement the backprop learning algorithm in this way because of the limited set of ugens.

If we had all of the Math functions as ugens then we could do wild and funky things like that. It would enhance the power of ChucK significantly.

Also I agree that having slower sample rate blackholes would help a lot.

Just my two cents as well, cheers!

[Kassen]

Some notes;

I really don't think control-rate is a problem that we have; we already have one of the most detailed (if not *the* most detailed?) ways of managing it around. You can express control-rate down to a fraction of a CPU cycle of your AMD/Pentium; that's quite impressive.

I do agree with what Kijjaz said above that this can be somewhat involved to set up in improvisation situations and after the first few times such code is quite boring to write.

Because of these factors I'd rather look into importing "libraries" of frequently used functions, as well as advanced code-completion for the (mini)Audicle.

My .02€

[kijjaz]

i just got some more feature requests:

- A Global Patchbay: it can be programmed as an array of Gains that can be accessed by any shreds running in the VM. it'd be like declaring in a public class, but would it be nice to have it available easily?

- A SndBuf-like UGen that does not have to read the whole file into the memory when .read .. so that if we say .read to it, it will begin to read, but won't contain the whole file, and there can be some parameters that says how much of the file have been read and is it all finished. So with this, we can have a SndBuf style UGen that can read a wave file lazily but safely, without taking the risk of glitching the whole virtual machine.

- Fixing Phasor, SawOsc, SqrOsc, TriOsc, PulseOsc's strange phase syncing (especially when it's synced to negative or very negative or very positive value resulting in a strange output)

- can Blit UGen family sync to the signal chucked to it?

Thank you ^_^. nothing more for now.

[Kassen]

[kijjaz]

Hmm.. And how do I make a global Gain array like that? Is it allowed in the public class?

and SndBuf.. OH!! ... hmm ..

and Blit___ .. hmm i see, syncing like SinOsc might not be a good idea for those Blit things mathematically, but being able to chuck in a frequency is gonna be useful.

[Kassen]

[kijjaz]

Oh! Thanks Kassen. this is the patchbay i was looking for.

[Kassen]

You're welcome!

I felt a bit silly posting that code because it's so simple but it's really nice to have a internal pachbay

[kijjaz]

i didn't even know that it's possible coz i only read about the static class that it doesn't support UGens yet, but with this it really does support UGens in another sense.