Hey all, For the Chubgraph example, you'll want to use "outlet" instead of dac: class TestChubgraph extends Chubgraph { SinOsc o => outlet; 400 => o.freq; } outlet is the local output terminal for the Chubgraph, whereas dac is the same dac it always is. Performance-wise, Chugens are basically doing the exact same thing as a conventional 1::samp/Step loop, so I would expect comparable performance in those cases. Chubgraphs basically plug existing C++ ugens together, so they end up being an order of magnitude faster than Chugens, which execute ChucK VM code for every sample. The main advantage of Chugens in either case is ease of use and clarity, at the potential expense of performance. The paper is here: https://ccrma.stanford.edu/~spencer/publications/CCC2012.pdf (to be published later this year as part of ICMC 2012) spencer On Wed, Aug 29, 2012 at 11:24 AM, Michael Heuer wrote:

Robin Haberkorn wrote:

...

Also thinking about Chugens, could someone comment on the performance aspect of using them for audio-rate processing (in comparison to a traditional 1::samp loop, e.g. in a Chubgraph)?

Spencer's 2012 paper "CHUGENS, CHUBGRAPHS, CHUGINS: 3 TIERS FOR EXTENDING CHUCK" provides examples and performance numbers. Unfortunately I'm not sure where that was published and two seconds with Google can't find the reference. Check the mailing list archives.

michael _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

On 30/08/12 14:27, Robin Haberkorn wrote:

... The point is that you will need that code in virtually every Chubgraph implementation so it should be the default. As a workaround I will define some ChubgraphStd class I will use as a base class for new Chubgraphs. ...

Which leads me to another bug: class ChubgraphStd extends Chubgraph { fun float gain(float g) { return g => outlet.gain; } fun float gain() { return outlet.gain(); } fun float last() { return outlet.last(); } } ChubgraphStd c; 1 => (c $ UGen).gain; setting the gain of a UGen casted to UGen usually works, I use it in situations like that: UGen @gens[3]; new SinOsc @=> gens[0]; //... 10 => gens[i].gain; but above example segfaults. It doesn't for a direct "Chubgraph"-instance. So I guess it is a bug in ChucK's class system. I have a bunch of test cases to segfault ChucK. Would be happy to post them to a bug tracker of some sort...

Robin, Thanks for all of your interesting bug reports, feedback, and experimentation -- we really appreciate it. In SVN now I have patched the Chubgraph implementation to properly account for .gain() and .last() parameters. We anticipate moving ChucK's source code hosting to GitHub within the next few weeks (as soon as our active development initiatives stabilize). At that point we would suggest submitting issues/bug reports to GitHub's issue tracker. Until then, feel free to post them to the mailing list so we can take a look, perhaps to chuck-dev rather than chuck-users. Thanks, spencer On Fri, Aug 31, 2012 at 2:46 PM, Kassen wrote:

Robin;

...

setting the gain of a UGen casted to UGen usually works,

Makes sense as that is one of the members they all have in common; I'd like to know about situations where it didn't.

...

but above example segfaults. It doesn't for a direct "Chubgraph"-instance. So I guess it is a bug in ChucK's class system.

Likely. Barring structural evidence it seems to me that ChucK's type system has particular issues with objects that have multiple types. "foo" might be a object, a UGen, a Filter and a LPF, all at the same time. We should be able to -legally- cast it up and down that hierarchy but this sometimes goes wrong, particularly when as in your example, it is also a element of a array.

That's gut-feeling based on experience, it might be way off in the face of a formal analysis (TODO :-) )

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users