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.