[chuck-users] GenX subclasses not assigning properly (using @=>)

[Kassen]

Andrew;

2010/2/8 Andrew C. Smith <andrewchristophersmith at gmail.com>

> I've got this public class that goes like this:
>
> Phasor p => GenX g => env;
>
> with the assumption that I can just do a Gen9 gen @=> myObject.g; and have
> it all work out. However, this doesn't seem to be working. I do this:
>
> Gen9 gen;
> [1.0, 0.6, 0.3, 1.75, 0.1, 0.1] => gen.coefs;
> gen @=> s[i].g;
>
> and it gives me no sound, but if I change the GenX in the public class to
> Gen9 then it works. I've seen this work before with other things, so what am
> I doing wrong here? I'm not getting any compiler errors or warnings,
> either.
>


I'm actually a bit surprised that it would work when changing the GenX to
Gen9. As I understand the current situation assigning to a existing UGen
will drop the reference count of the UGen being assigned to, kicking in the
sort of GC for UGens which will disconnect it from the graph. Then new UGen
will have the same reference in the same namespace but *not* the same
connections in the graph, you'd need to connect it manually to have sound.
I'm not sure about the exact types of the Gen UGens but off hand I would
have expected a need for some casting here.

I think that's what's going on; that would explain why you get no sound and
no warnings either. I don't feel the current system should be the desired
behaviour, to me assignment to UGens should "hot-swap" the two, maintaining
the same links in the UGen graph, in addition to any links the UGen being
swapped in may have.

For a long time I've been thinking that we should have two member functions
for all UGens;
UGen[] .connectsTo()
UGen[] .connectsFrom()

These two should return a array of UGen references each, allowing us to
write our own "hotswap" scripts like we want it to be. I haven't yet send my
proposal (I have a draft somewhere) because there are a few complications.
We could for example call
fun void traverse( UGen foo)
{
for (int i; i< foo.connectsFrom().cap(); i++)
  {
//do something with these UGens
.........
.........
..........
traverse(  foo.connectsFrom()[i]);
}}

traverse(dac);

and so recursively traverse the whole UGen graph for the whole VM. Right now
we don't have the tools to do much useful stuff with the results as we can't
poll UGens for their type or name. We'd need some good ideas there.

I do think that this would fly with regard to how the VM works, there would
be no need to restart any shreds and lose data as the UGen graph is quite
independent from shreds. This would allow us to pull stunts like put a lpf
after all LiSa UGens in the whole vm without restarting anything. All of the
data needed to do this is there, I think the capabilities are there, we just
don't have the functions.

This would obviously also lead to prime opportunities to cause crashes and
dropped shreds but then we can do much of this already with public UGens and
maintaining the required data manually; you could still easily crash it all
with a wrong cast somewhere, this way it would just be easier.

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20100208/feb31450/attachment.htm>