[chuck-users] Latest on subclassing UGen within ChucK?

[Michael Heuer]

Chris Harris <ryguasu at gmail.com> wrote:
> On Fri, Feb 22, 2013 at 7:55 AM, Kassen <signal.automatique at gmail.com> 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