[chuck-users] I like alias-noise and 8bit

Kassen signal.automatique at gmail.com
Sun May 18 10:24:23 EDT 2008


Atte :

Thanks alot. I feel embarrased that I didn't know about last being available
> for all ugens. I (believe it or not) did look in the documentation, but for
> ugens and no last is listed there, however I should have looked at
> http://chuck.cs.princeton.edu/doc/language/ugen.html
>

Yes, it is. Back when I was a young little ChucKer I -for a while- had the
impression ChucK was a bit like a Buchla modular; Buchla uses/used different
types of plugs for control and audio signals. It's not at all but the key is
.last() on the one end and Step (or Impulse) on the other. This might be a
good candidate for a small section in the manual because you (and me)
weren't tthe only ones that were confused by it for a while.

I would, BTW, be in favour of allowing Envelope to ramp to negative values.
I think we could do this by removing a single check from Envelope's C++ code
and as far as I could tell when I looked at that there wouldn't be any real
repercussions but I might be wrong there. (Perry? Ge?). This would allow for
linear interpolation when we go from code to Ugens if we don't like (too
much) aliassing (at the moment).


>
> I'll have a look at your examples, and modify for my needs.
>

Great. I think the aliassing one is correct (but no waranties!), this should
be fairly easy to work with.

Ok, so you're in chuck, I was thinking about going c++...
>

Me too, that's why I used the word "also". I think the two would both be
nice on their own but I also think that prototyping in ChucK could help in
developing the C++. ChucK is after all faster and easier to write.

>
> Anyways, I had the impression that defining our own ugens in chuck-code
> wasn't supported, but I sure hope I was wrong.


Well, the example I just send (extending Step) was my best shot. I don't
think we can and considdering how much stuff I tried I'd be very surprised
indeed if this was possible. Frankly I think that bit of code demonstrates a
issue. I feel that either we should be able to extend a Ugen (and have the
result be a Ugen) or it should throw a warning like trying to extend a
primitive does.


==================
//example of this
//this doesn't work which is documented and correct behaviour

class value extends int
    {
    //stupid example function
    fun void increment()
        {
        this++;
        }
    }
==================


> Obviously this would make the LoFi example sooo smooth:
>
> SndBuf s => LoFi l => dac;
> s.read("something.wav");
>
> 22100 => l.rate;
> 8 => l.bits;
>
> 1::week => now;


Yes, I agree. Developing our own Ugens in C++ is possible already but the
lack of documentation on exactly what this would mean makes it a rather
daunting project if you're not already fluent in C++. extending/making Ugens
in ChucK on the other hand would could help maintain readable code in larger
projects, etc.

I think both would be worthwhile aditions.

>
>
> The second last section on
> http://chuck.cs.princeton.edu/doc/language/ugen.html says "creating
> [ugens], comming soon". It seems this (missing) info is exactly what I'm
> looking for.
>

Yeah.... I suspect that's simply one of the bits that has been on The List
for a long time due to other stuff getting more priority. We need it, but we
also need garabage collection, fileIO and (I feel) updating the code of just
a part of a shred, etc, etc, etc.

At least we can be confident that our esteemed DEV's aren't in any danger of
feeling bored and having nothing at hand any time soon, that's at least
something :¬).

Cheers,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20080518/5d8d0e83/attachment-0001.html>


More information about the chuck-users mailing list