
Sorry to bother you again, but I'm experiencing difficulties using the new Chubgraph feature. Using v1.3.0.2 of course. class TestChubgraph extends Chubgraph { SinOsc o => dac; 400 => o.freq; } TestChubgraph c; 10::second => now; This code does the sine wave sound but it should be silent since "c" is not connected to dac. Reading the Chubgraph example, I thought that the dac in the Chubgraph class is local to the object instance - as a way to connect to the UGen's output. Also what's strange is that the number of channels reported for dac in the class is the same as the number of output channels I've requested for ChucK. Did I miss something or is it a bug? 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)? Thanks in advance, Robin

Robin Haberkorn
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

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
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

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.
I think I mixed up the Chugens with the (C++ based and compiled) Chugins? So many new words, sorry about the confusion.

On 29 August 2012 19:53, Robin Haberkorn
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)?
I think the ChubGraph just encapsulates a set of UGens. ChuGins should be about as fast as UGens. Exactly how fast that is will -of course- depend on the programmer and the compiler. How much faster a more involved GhuGin will be than a series of more simple UGens performing the same task will depend on how much this task can be simplified when we put it in a single object. I'd only do this is situations where performance is really critical or where you anticipate you'll re-use a given technique a lot. Interestingly it turned out that ChuGins can out-perform regular UGens; Caspar's interpolating delay seems to out-perform the most similar UGen. How that is possible, considering that Caspar is using more high quality interpolation is still a bit unclear. Yours, Kas.

ok, I think I found another problem... or at least undocumented feature ;-) class Test extends Chubgraph { Step s => outlet; 1 => s.next; } Test t => Gain g => blackhole; 1000 => t.gain; samp => now; <<< t.last(), g.last() >>>; it prints "0.000000 1.000000" instead of the expected "1000.000000 1000.000000", The reason is that the standard UGen methods gain() and last() are there but unimplemented. For "Test" to behave like other UGens you have to extend it like that: class Test extends Chubgraph { Step s => outlet; 1 => s.next; fun float gain(float g) { return g => outlet.gain; } fun float gain() { return outlet.gain(); } fun float last() { return outlet.last(); } } 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. Any thoughts on that? On 29/08/12 19:53, Robin Haberkorn wrote:
Sorry to bother you again, but I'm experiencing difficulties using the new Chubgraph feature. Using v1.3.0.2 of course.
class TestChubgraph extends Chubgraph { SinOsc o => dac; 400 => o.freq; }
TestChubgraph c;
10::second => now;
This code does the sine wave sound but it should be silent since "c" is not connected to dac. Reading the Chubgraph example, I thought that the dac in the Chubgraph class is local to the object instance - as a way to connect to the UGen's output. Also what's strange is that the number of channels reported for dac in the class is the same as the number of output channels I've requested for ChucK. Did I miss something or is it a bug?
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)?
Thanks in advance, Robin

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;
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.

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
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

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. ...
for the people who are interested in the new ChucK features. I'm now using all of them in my little project. https://github.com/rhaberkorn/digitale-debutanten * lib/ChugraphStd.ck is the aforementioned Chubgraph base class * lib/SampOsc.ck and lib/ClipperGraph.ck are Chubgraphs * lib/ClipperGen.ck is a Chugen * finally chugins/Clipper.cpp is a Chugin signal clipper. Using the Clipper implementations (a very basic task) you can quite impressively see the differences. A single ClipperGraph connected to dac, results in about 7% more Jack DSP load on my computer. The ClipperGen needs ~14%!!! And the Chugin Clipper results in almost no additional DSP load. So thanks for your help and patience. cheers, Robin
participants (4)
-
Kassen
-
Michael Heuer
-
Robin Haberkorn
-
Spencer Salazar