Kas,

On Fri, Feb 24, 2012 at 4:59 AM, Kassen <signal.automatique@gmail.com> wrote:

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

_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users