Kas,
On Fri, Feb 24, 2012 at 4:59 AM, Kassen
On Fri, Feb 24, 2012 at 12:07:49AM -0500, mike clemow wrote: ... In that case s will be disconnected from the dac (and should be garbage collected, not sure that happens yet, fairly sure it doesn't).
*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? 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? 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. ;) Can I ask what it is that you want from this code? It seems to me that your goal is a publicly available Cell[] array. Is that the case? Perhaps there's a better approach. For instance, connections can be made on-the-fly within the shred you're currently executing. I think that this is similar to the use of Kassen's snippet on the wiki (correct me if I'm off-base here, Kas): //increase the size of the array to get more channels public class bus { static Gain @ chan[8]; } new Gain[8] @=> bus.chan; Kassen runs this in one shred and then connects UGens to the busses and the busses to other things on-the-fly in other shreds. The Cell objects in Cell.cells[] are still available. Connect them in your "client" code from other shreds on the fly. Alternatively, have Cells.ad() call Cells.connect() internally. I hope this helps. -Mike
"s" should be disconnected because there are no longer any references to it. More exactly; all connections from a UGen (to it doesn't matter) that has no references any more should be removed once the reference count reaches 0, regardless of what shred made those connections.
Here the issue may well be that this mechanism somehow counts references incorrectly. The algorithm was changed a few times, first to stop double connections. That change was undone when it turned out those were extremely useful for squaring signals using a Gain set to multiply. That resulted in UGens with double connections potentially keeping (at least) one of those when they went to 0 references. That last bug was fixed, but the fix may have been too agressive, leading to the current behaviour?
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users