<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Mike and Kas,<div><br></div><div>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.</div><div><br></div><div>In this sense, it is not necessarily a problem to have to go through a 3-stage process:</div><div>1. issue a shred that (using the public class) creates instances of the Ugens</div><div>2. issue a second shred that connects them (and, according to my observations, seems to make the connections persistent)</div><div>3. issue subsequent shreds that trigger behaviours from, send messages to, etc, the "stored" ugens</div><div><br></div><div>It is just that it would be more elegant if it was a 2-stage process:</div><div>1. issue a one-liner that creates and connects the Ugen instances</div><div>2. issue subsequent one-liners that trigger behaviours, send messages, etc</div><div><br></div><div>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!</div><div><br></div><div>Thanks all!</div><div><br></div><div>Yours truly,</div><div>David</div><div><br><div><div>On 2012-02-24, at 11:17 AM, mike clemow wrote:</div><blockquote type="cite"><div>Kas,<br><br>On Fri, Feb 24, 2012 at 4:59 AM, Kassen <<a href="mailto:signal.automatique@gmail.com">signal.automatique@gmail.com</a>> wrote:<br><blockquote type="cite">On Fri, Feb 24, 2012 at 12:07:49AM -0500, mike clemow wrote:<br></blockquote>...<br><blockquote type="cite">In that case s will be disconnected from the dac (and should be<br></blockquote><blockquote type="cite">garbage collected, not sure that happens yet, fairly sure it doesn't).<br></blockquote><br>*Lack* of garbage collection might be the problem here. Maybe the<br>connections are collected, but the objects aren't? The objects<br>actually *should* be collected but hang out due to an incomplete gc<br>implementation. Could that be the case?<br><br>I guess that what we're saying is that the the original Cell object in<br>the function sinOsc should fall out of scope after the method returns.<br> Should the reference to that object in the static member cells[] hold<br>it in scope as David's code implies?<br><br>David, another thing to consider is that this approach may be<br>unhelpful to you for one reason or another; either the Chuck is not<br>complete enough to make it clear that this should not be possible, or<br>Chuck is broken enough to not let this be possible even if it should<br>be. (This is a relatively common occurrence actually. ;)<br><br>Can I ask what it is that you want from this code? It seems to me<br>that your goal is a publicly available Cell[] array. Is that the<br>case? Perhaps there's a better approach. For instance, connections<br>can be made on-the-fly within the shred you're currently executing. I<br>think that this is similar to the use of Kassen's snippet on the wiki<br>(correct me if I'm off-base here, Kas):<br><br>//increase the size of the array to get more channels<br>public class bus<br> {<br> static Gain @ chan[8];<br> }<br>new Gain[8] @=> bus.chan;<br><br>Kassen runs this in one shred and then connects UGens to the busses<br>and the busses to other things on-the-fly in other shreds.<br><br>The Cell objects in Cell.cells[] are still available. Connect them in<br>your "client" code from other shreds on the fly. Alternatively, have<br>Cells.ad() call Cells.connect() internally.<br><br>I hope this helps.<br><br>-Mike<br><br><br><br><blockquote type="cite">"s" should be disconnected because there are no longer any references<br></blockquote><blockquote type="cite">to it. More exactly; all connections from a UGen (to it doesn't<br></blockquote><blockquote type="cite">matter) that has no references any more should be removed once the<br></blockquote><blockquote type="cite">reference count reaches 0, regardless of what shred made those<br></blockquote><blockquote type="cite">connections.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Here the issue may well be that this mechanism somehow counts<br></blockquote><blockquote type="cite">references incorrectly. The algorithm was changed a few times, first<br></blockquote><blockquote type="cite">to stop double connections. That change was undone when it turned out<br></blockquote><blockquote type="cite">those were extremely useful for squaring signals using a Gain set to<br></blockquote><blockquote type="cite">multiply. That resulted in UGens with double connections potentially<br></blockquote><blockquote type="cite">keeping (at least) one of those when they went to 0 references. That<br></blockquote><blockquote type="cite">last bug was fixed, but the fix may have been too agressive, leading<br></blockquote><blockquote type="cite">to the current behaviour?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Yours,<br></blockquote><blockquote type="cite">Kas.<br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">chuck-users mailing list<br></blockquote><blockquote type="cite"><a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a><br></blockquote><blockquote type="cite"><a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br></blockquote>_______________________________________________<br>chuck-users mailing list<br><a href="mailto:chuck-users@lists.cs.princeton.edu">chuck-users@lists.cs.princeton.edu</a><br>https://lists.cs.princeton.edu/mailman/listinfo/chuck-users<br></div></blockquote></div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><div>-------------------------------------------------------------------</div><div>Dr. David Ogborn, Assistant Professor<br>Communication Studies & Multimedia</div><div>Director, Cybernetic Orchestra & ESP Studio</div><div>McMaster University, Hamilton, Canada<br><br>ogbornd --at-- <a href="http://mcmaster.ca">mcmaster.ca</a></div><div><div><a href="http://davidogborn.net/">http://davidogborn.net</a></div><div><a href="http://twitter.com/ogbornd">http://twitter.com/ogbornd</a></div><div><span class="Apple-style-span" style="font-size: medium; "><a href="http://esp.mcmaster.ca/">http://esp.mcmaster.ca</a> (Cybernetic Orchestra)</span></div></div><div>1-905-525-9140 ext 27603</div></div><div><br></div></div></div></span><br class="Apple-interchange-newline"></div></span><br class="Apple-interchange-newline"></div></span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br></div></body></html>