[chuck-users] public class connections mystery

Mon Mar 5 09:56:17 EST 2012

Hi Robert,

Yes, it does - and that's kind of the point - I want a style of programming where each shred has one "atomic" effect on a system that persists between and above the shreds...  (Although it does suggest one workaround - to allow the simple "atomic" shreds to persist for a very long time, piling up even when they aren't doing anything.)

Yours truly,
David

On 2012-02-27, at 3:32 PM, Robert Poor wrote:

> 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 <ogbornd at mcmaster.ca>:
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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