[chuck-users] public class connections mystery

[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 <signal.automatique at 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 at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
> _______________________________________________
> chuck-users mailing list
> chuck-users at 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






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20120224/2d4eb514/attachment.htm>