Re: [chuck-users] public class connections mystery

David O: This is a shot in the dark: does the first shred terminate before you look at connections with the second? - Rob 2012/2/24 David Ogborn :

Hi Mike and Kas,

Mike, you asked what I am trying to do with this code: I am trying to create a basis for doing live coding operations in Chuck with the added constraint that every shred is at most 1 line of code - the kind of thing that could easily be piped in from a terminal or over OSC.

In this sense, it is not necessarily a problem to have to go through a 3-stage process: 1. issue a shred that (using the public class) creates instances of the Ugens 2. issue a second shred that connects them (and, according to my observations, seems to make the connections persistent) 3. issue subsequent shreds that trigger behaviours from, send messages to, etc, the "stored" ugens

It is just that it would be more elegant if it was a 2-stage process: 1. issue a one-liner that creates and connects the Ugen instances 2. issue subsequent one-liners that trigger behaviours, send messages, etc

I take your point (in a later email) about the Event orientation though - I will reconsider to see if that could make things work for me!

Thanks all!

Yours truly, David

On 2012-02-24, at 11:17 AM, mike clemow wrote:

Kas,

On Fri, Feb 24, 2012 at 4:59 AM, Kassen 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

------------------------------------------------------------------- Dr. David Ogborn, Assistant Professor Communication Studies & Multimedia Director, Cybernetic Orchestra & ESP Studio McMaster University, Hamilton, Canada

ogbornd --at-- mcmaster.ca http://davidogborn.net http://twitter.com/ogbornd http://esp.mcmaster.ca (Cybernetic Orchestra) 1-905-525-9140 ext 27603

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