Latest on subclassing UGen within ChucK?

Chris Harris

22 Feb 2013 22 Feb '13

4:08 a.m.

Can you create a UGen in the ChucK language, by subclassing the UGen class? Because I just tried to do it for a couple hours and it was frustrating the heck out of me. The documentation makes it seem like it should work. (ChucK has virtual methods, and you can subclass UGen. So why wouldn't it work.) So something like this should be viable: class IGen extends UGen { SinOsc osc => blackhole; // Docs don't make it clear how all the methods should work, but // at least last() seems more or less straightforward: 1 => int first; fun float last() { if (first) { return 0.0; } else { 0 => first; return osc.last(); } } } IGen fg => dac; 4::day => now; This whole thing compiles fine and runs in the VM without errors. The only problem is that none of the methods defined on IGen get called, nor does any sound come out. Unless I'm totally doing it wrong, I'm suspecting you can't, in fact, make a viable UGen subclass using the ChucK language itself (vs C++ or whatever). If this sort of subclasses can't work, a nice improvement would be for ChucK to provide an error here. Is there any legitimate reason to subclass a UGen in ChucK language? If not, attempting to do so should generate a compile error. Alternatively, maybe trying to chuck a non-C++ Ugen subclass into another Ugen (and especially into dac) should throw a runtime error. I did finally find about the chugen facility, which seems like a neat alternative. But it was not an easy find. So I guess some documentation updates might be in order too. A note that you can't write UGens in ChucK and a mention that chugen stuff exists. Not sure if I'll have time to look into all this or not. But I wanted to start by getting the facts straight. Thanks, Chris

Show replies by date

Kassen

22 Feb 22 Feb

10:55 a.m.

On Fri, Feb 22, 2013 at 01:08:00AM -0800, Chris Harris wrote:

...

Can you create a UGen in the ChucK language, by subclassing the UGen class? Because I just tried to do it for a couple hours and it was frustrating the heck out of me.

Yes, you can but sadly the result won't work as we'd like it to right now.

...

Unless I'm totally doing it wrong, I'm suspecting you can't, in fact, make a viable UGen subclass using the ChucK language itself (vs C++ or whatever).

Yes, unfortunately that is correct.

...

If this sort of subclasses can't work, a nice improvement would be for ChucK to provide an error here. Is there any legitimate reason to subclass a UGen in ChucK language? If not, attempting to do so should generate a compile error. Alternatively, maybe trying to chuck a non-C++ Ugen subclass into another Ugen (and especially into dac) should throw a runtime error.

As I see things there are valid reasons to want this and wanting to extend UGen or a particular type of UGen makes sense, both syntactically and as a way of working with sound. While it is not a "error" I could this see being grounds for a "warning" that points the user towards ChuGins. For me a "error" is going too far; these are classes and classes can be extended, while the end result is not what we'd intuitively want there is no error on the syntax level as such, I feel. I can see how this might be grounds for debate though.

...

I did finally find about the chugen facility, which seems like a neat alternative. But it was not an easy find.

So I guess some documentation updates might be in order too. A note that you can't write UGens in ChucK and a mention that chugen stuff exists.

Not sure if I'll have time to look into all this or not. But I wanted to start by getting the facts straight.

Yes, you got all of it right. What you tried, though it doesn't work, looks perfectly coherent to me. It is also true that ChuGins are the actual solution in practice now. They are outside of the language, indeed, but in return you get GCC (or whatever your compiler of choice is) to optimise for you; that's not a bad trade, I'd say. The documentation situation here is need bad, I agree. ChuGins were documented in their own paper but indeed not in the manual yet. The documentation is always lagging behind the development and that is particularly a issue if you are new and didn't get to follow the new stuff as it was announced. When things look very confusing, as they do here, they simply might be. I recommend a mail to the list over staring at things for hours. Chances are good that somebody who knows what's up will be around and able to send you in the right direction. That's what the list is for. Yours, Kas.

Chris Harris

12:55 p.m.

On Fri, Feb 22, 2013 at 7:55 AM, Kassen wrote:

...

...
If this sort of subclasses can't work, a nice improvement would be for ChucK to provide an error here. Is there any legitimate reason to subclass a UGen in ChucK language? If not, attempting to do so should generate a compile error. Alternatively, maybe trying to chuck a non-C++ Ugen subclass into another Ugen (and especially into dac) should throw a runtime error.

As I see things there are valid reasons to want this and wanting to extend UGen or a particular type of UGen makes sense, both syntactically and as a way of working with sound.

While it is not a "error" I could this see being grounds for a "warning" that points the user towards ChuGins. For me a "error" is going too far; these are classes and classes can be extended, while the end result is not what we'd intuitively want there is no error on the syntax level as such, I feel. I can see how this might be grounds for debate though.

Agree that you might want to be able to extend a particular UGen. For example, something like this might be useful for something or other: class MyCosine extends SinOsc { 1 => int timesPlayed; fun void increment() { 1 +=> timesPlayed; } } And clearly you should also be able to have a variable of type UGen, that could hold any concrete ugen. I think if we were handling this sort of situation in Java, then UGen would be an abstract class; you can't instantiate it, only subclasses that actually implement certain critical methods. And you can't actually write the relevant methods in the ChucK language, so attempting to extend a UGen in ChucK would fail. Of course, that would require abstract classes, which may not be worth adding for for that.

...

I recommend a mail to the list over staring at things for hours.

Oh, you must mean the dev list? I was wondering if I was getting too technical here anyway.

Michael Heuer

2:12 p.m.

Chris Harris wrote:

...

On Fri, Feb 22, 2013 at 7:55 AM, Kassen wrote:

...
...
If this sort of subclasses can't work, a nice improvement would be for ChucK to provide an error here. Is there any legitimate reason to subclass a UGen in ChucK language? If not, attempting to do so should generate a compile error. Alternatively, maybe trying to chuck a non-C++ Ugen subclass into another Ugen (and especially into dac) should throw a runtime error.

As I see things there are valid reasons to want this and wanting to extend UGen or a particular type of UGen makes sense, both syntactically and as a way of working with sound.

While it is not a "error" I could this see being grounds for a "warning" that points the user towards ChuGins. For me a "error" is going too far; these are classes and classes can be extended, while the end result is not what we'd intuitively want there is no error on the syntax level as such, I feel. I can see how this might be grounds for debate though.

Agree that you might want to be able to extend a particular UGen. For example, something like this might be useful for something or other:

class MyCosine extends SinOsc { 1 => int timesPlayed;

fun void increment() { 1 +=> timesPlayed; } }

You can do something similar with class MyCosine extends Chugen { SinOsc _osc => blackhole; 1 => int timesPlayed; fun void increment() { 1 +=> timesPlayed; } fun float tick(float in) { return _osc.last(); } fun float gain() { return _osc.gain(); } fun void gain(float gain) { gain => _osc.gain(); } ...etc. } but of course MyCosine would not be an instance of UGen.

...

And clearly you should also be able to have a variable of type UGen, that could hold any concrete ugen.

I think if we were handling this sort of situation in Java, then UGen would be an abstract class; you can't instantiate it, only subclasses that actually implement certain critical methods. And you can't actually write the relevant methods in the ChucK language, so attempting to extend a UGen in ChucK would fail. Of course, that would require abstract classes, which may not be worth adding for for that.

...
I recommend a mail to the list over staring at things for hours.

Oh, you must mean the dev list? I was wondering if I was getting too technical here anyway.

Too technical for this mailing list? Not possible. :) michael

Kassen

2:24 p.m.

On Fri, Feb 22, 2013 at 09:55:14AM -0800, Chris Harris wrote:

...

Oh, you must mean the dev list? I was wondering if I was getting too technical here anyway.

Well, the original topic of extending UGen was very much topical from a user perspective. It should be ok to get "technical" on a list about a programming language. Proposed solutions might indeed be a "-dev" issue.. the line can get a bit blurry. I'm sure that as long as you make some attempt to do The Right Thing nobody will be angry about what you do. Yours, Kas.

Scott Hewitt

6:11 p.m.

I am writing like crazy for other things but perhaps it would be worth having another manual update binge in the near future. Just an thought out loud at the moment classic, Do => future Scott On Feb 22, 2013 7:25 PM, "Kassen" wrote:

...

On Fri, Feb 22, 2013 at 09:55:14AM -0800, Chris Harris wrote:

...
Oh, you must mean the dev list? I was wondering if I was getting too technical here anyway.

Well, the original topic of extending UGen was very much topical from a user perspective. It should be ok to get "technical" on a list about a programming language. Proposed solutions might indeed be a "-dev" issue.. the line can get a bit blurry.

I'm sure that as long as you make some attempt to do The Right Thing nobody will be angry about what you do.

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

4282

Age (days ago)

4282

Last active (days ago)

List overview

Download

5 comments

4 participants

participants (4)

Chris Harris
Kassen
Michael Heuer
Scott Hewitt