[chuck-users] problems with chubgraphs

[Robin Haberkorn]

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
>