[chuck-users] public class connections mystery

[Scott Hewitt]

Hi,

A while ago I was looking at this kind of thing and ended up building CIP

http://cip.ablelemon.co.uk/

I wonder if it offers the behaviour you are looking for?

Scott



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
>