On Fri, Feb 24, 2012 at 11:17:08AM -0500, mike clemow wrote:
Mike,
*Lack* of garbage collection might be the problem here. Maybe the connections are collected, but the objects aren't? The objects actually *should* be collected but hang out due to an incomplete gc implementation. Could that be the case?
Hmmmmm. At the very least there is a issue along those lines here. In a way inter-UGen connections that are removed is a sort of GC, in terms of CPU usage, but that's different from GC as keeping memory usage reasonable. Currently those are independent, it seems, for UGens and in the future they should probably be more closely linked. Here, at first glance, it seems to me that the UGens in question are not garbage as they are in the public namespace. As far as I can see they will never be garbage for the rest of the VM's life as long as we don't assign NULL to them. I'll have a more in-depth look at what's going wrong with this code tomorrow.
I guess that what we're saying is that the the original Cell object in the function sinOsc should fall out of scope after the method returns. Should the reference to that object in the static member cells[] hold it in scope as David's code implies?
I don't dare say what this code "should" do right now without a closer look, but I strongly feel that yes, we should be able to put anything we please in the global namespace by assigning it to such a static member of a public class and that that should not lead to disconections.
David, another thing to consider is that this approach may be unhelpful to you for one reason or another; either the Chuck is not complete enough to make it clear that this should not be possible, or Chuck is broken enough to not let this be possible even if it should be. (This is a relatively common occurrence actually. ;)
True, but most practical things we might like to do can be done, though it may take some roundabout ways here and there. That's half the fun. Well, often ;-) Kas.