Andrew;
2010/2/8 Andrew C. Smith
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.