public class connections mystery

David Ogborn

23 Feb 2012 23 Feb '12

8:44 p.m.

Hello again Chuckists, This is the second time today that I harangue the list with a question about some unexpected behaviour from code (unexpected to me, anyways!). This one is a bit more complicated… I declare a public class that maintains a static array of oscillators and envelopes (through a helper class). A function in the public class creates a new oscillator and envelope, and connects them both to the dac. Another function in the public class makes the envelope "go". Now here's the funny thing, to my mind: (1) If I call the creation function and the "go" function from the same (second) shred, everything works. (2) If I call the creation function in one shred and the "go" function in another shred, there is no sound - and a little investigation seems to reveal that the ugens all exist and are accessible, but are no longer connected to each other. (3) If I call a special "connect" function - _from any shred_ - that simply reestablishes the connections, then the "go" function works when called _from any shred. Here is an example of "calling shreds" and below that is the public class code: // one possible shred… Cells.sinOsc("low",28); // I want this to work from a separate shred but there is no sound/connections Cells.ad("low",5::ms,5::ms); // However, the above starts to work again if this is called from any shred Cells.connect("low"); // public class code in a separate file and shred class Cell { Osc o; Envelope e; } public class Cells { static Cell @cells[]; function static void sinOsc(string name, float nn) { Cell c; new SinOsc @=> c.o; nn => Std.mtof => c.o.freq; new Envelope @=> c.e; c.o => c.e => dac; c @=> cells[name]; } function static void ad(string name, dur att,dur dec) { cells[name] @=> Cell c; 1 => c.e.target; att => c.e.duration => now; 0 => c.e.target; dec => c.e.duration => now; } // the function below shouldn't be necessary, I don't think // but it is… unless connect is called on a given cell from // a shred other than the shred that calls sinOsc, the // ugens are not connected to the dac! ??? function static void connect(string name) { cells[name] @=> Cell c; c.o => c.e => dac; } function static void note(string name, float nn) { nn => Std.mtof => cells[name].o.freq; } } Cell theCells[0] @=> Cells.cells; while(true) { <<< "public class Cells is still alive" >>>; 10::second => now; } // Thanks for any help! // Yours truly, // David ------------------------------------------------------------------- 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

Attachments:

attachment.html (text/html — 6.4 KB)

Show replies by date

mike clemow

24 Feb 24 Feb

12:07 a.m.

Hi David, Yeah, that's weird. I added these debug statements to Cells: ... function static void sinOsc(string name, float nn) { Cell c; new SinOsc @=> c.o; nn => Std.mtof => c.o.freq; new Envelope @=> c.e; c.o => c.e => dac; c @=> cells[name]; <<< c, cells[name] >>>; <<< c.o, cells[name].o, c.e, cells[name].e >>>; <<< cells[name].o.isConnectedTo(cells[name].e) >>>; <<< cells[name].e.isConnectedTo(dac) >>>; } function static void ad(string name, dur att,dur dec) { cells[name] @=> Cell c; <<< c, cells[name] >>>; <<< c.o, cells[name].o, c.e, cells[name].e >>>; <<< cells[name].o.isConnectedTo(cells[name].e) >>>; <<< cells[name].e.isConnectedTo(dac) >>>; 1 => c.e.target; att => c.e.duration => now; 0 => c.e.target; dec => c.e.duration => now; } ... and get these results: [chuck](VM): sporking incoming shred: 2 (ogborn_2)... 0x21c12010 0x21c12010 0x21c56060 0x21c56060 0x207f7a30 0x207f7a30 1 :(int) 1 :(int) "public class Cells is still alive" : (string) "public class Cells is still alive" : (string) [chuck](VM): sporking incoming shred: 3 (ogborn_2)... 0x21c12010 0x21c12010 0x21c56060 0x21c56060 0x207f7a30 0x207f7a30 0 :(int) 0 :(int) Seems to be the same object references but they are definitely not connected by the time they get that call from the second shred. Almost as if the UGen connections had scope... -Mike http://michaelclemow.com http://semiotech.org 2012/2/23 David Ogborn :

...

Hello again Chuckists,

This is the second time today that I harangue the list with a question about some unexpected behaviour from code (unexpected to me, anyways!). This one is a bit more complicated…

I declare a public class that maintains a static array of oscillators and envelopes (through a helper class). A function in the public class creates a new oscillator and envelope, and connects them both to the dac. Another function in the public class makes the envelope "go".

Now here's the funny thing, to my mind:

(1) If I call the creation function and the "go" function from the same (second) shred, everything works.

(2) If I call the creation function in one shred and the "go" function in another shred, there is no sound - and a little investigation seems to reveal that the ugens all exist and are accessible, but are no longer connected to each other.

(3) If I call a special "connect" function - _from any shred_ - that simply reestablishes the connections, then the "go" function works when called _from any shred.

Here is an example of "calling shreds" and below that is the public class code:

// one possible shred… Cells.sinOsc("low",28);

// I want this to work from a separate shred but there is no sound/connections Cells.ad("low",5::ms,5::ms);

// However, the above starts to work again if this is called from any shred Cells.connect("low");

// public class code in a separate file and shred

class Cell {   Osc o;   Envelope e; }

public class Cells {

  static Cell @cells[];

  function static void sinOsc(string name, float nn) {   Cell c;   new SinOsc @=> c.o;   nn => Std.mtof => c.o.freq;   new Envelope @=> c.e;   c.o => c.e => dac;   c @=> cells[name];   }

  function static void ad(string name, dur att,dur dec) {   cells[name] @=> Cell c;   1 => c.e.target;   att => c.e.duration => now;   0 => c.e.target;   dec => c.e.duration => now;   }

  // the function below shouldn't be necessary, I don't think   // but it is… unless connect is called on a given cell from   // a shred other than the shred that calls sinOsc, the   // ugens are not connected to the dac! ???   function static void connect(string name) {   cells[name] @=> Cell c;   c.o => c.e => dac;   }

  function static void note(string name, float nn) {   nn => Std.mtof => cells[name].o.freq;   }

}

Cell theCells[0] @=> Cells.cells;

while(true) {   <<< "public class Cells is still alive" >>>;   10::second => now; }

// Thanks for any help! // Yours truly, // David

------------------------------------------------------------------- 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

Kassen

4:59 a.m.

On Fri, Feb 24, 2012 at 12:07:49AM -0500, mike clemow wrote:

...

Seems to be the same object references but they are definitely not connected by the time they get that call from the second shred. Almost as if the UGen connections had scope...

Hmmm, yes. But that is not so strange; in a way they *do* and really should. Consider this trivial example of a shred; SinOsc s => dac; second => now; //the end 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). "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.

mike clemow

11:17 a.m.

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

Kassen

1:22 p.m.

On Fri, Feb 24, 2012 at 11:17:08AM -0500, mike clemow wrote:

...

Mike,

...

*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?

Hmmmmm. At the very least there is a issue along those lines here. In a way inter-UGen connections that are removed is a sort of GC, in terms of CPU usage, but that's different from GC as keeping memory usage reasonable. Currently those are independent, it seems, for UGens and in the future they should probably be more closely linked. Here, at first glance, it seems to me that the UGens in question are not garbage as they are in the public namespace. As far as I can see they will never be garbage for the rest of the VM's life as long as we don't assign NULL to them. I'll have a more in-depth look at what's going wrong with this code tomorrow.

...

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?

I don't dare say what this code "should" do right now without a closer look, but I strongly feel that yes, we should be able to put anything we please in the global namespace by assigning it to such a static member of a public class and that that should not lead to disconections.

...

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. ;)

True, but most practical things we might like to do can be done, though it may take some roundabout ways here and there. That's half the fun. Well, often ;-) Kas.

mike clemow

1:56 p.m.

Kas, Yeah, I honestly have no idea what should and shouldn't be happening in GC land. :) It occurs to me that I usually implement this type of mechanism using shreds rather than classes. One thing that Chuck does is nudge you in the direction of asking yourself "do I really need to wrap that in a class/namespace? or is what I really want a shred I can send an Event to?" Just a paradigmatic opinion. -Mike http://michaelclemow.com http://semiotech.org On Fri, Feb 24, 2012 at 1:22 PM, Kassen wrote:

...

On Fri, Feb 24, 2012 at 11:17:08AM -0500, mike clemow wrote:

...
Mike,

...
*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?

Hmmmmm. At the very least there is a issue along those lines here. In a way inter-UGen connections that are removed is a sort of GC, in terms of CPU usage, but that's different from GC as keeping memory usage reasonable. Currently those are independent, it seems, for UGens and in the future they should probably be more closely linked.

Here, at first glance, it seems to me that the UGens in question are not garbage as they are in the public namespace. As far as I can see they will never be garbage for the rest of the VM's life as long as we don't assign NULL to them. I'll have a more in-depth look at what's going wrong with this code tomorrow.

...
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?

I don't dare say what this code "should" do right now without a closer look, but I strongly feel that yes, we should be able to put anything we please in the global namespace by assigning it to such a static member of a public class and that that should not lead to disconections.

...
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. ;)

True, but most practical things we might like to do can be done, though it may take some roundabout ways here and there. That's half the fun. Well, often ;-)

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

David Ogborn

6:14 p.m.

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

Scott Hewitt

6:49 p.m.

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 :

...

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

David Ogborn

27 Feb 27 Feb

1:59 p.m.

Hi Scott, I looked at your CIP with interest. On the surface, it's not straightforwardly related to what I am after: controlling everything with a long sequence of 1-line programs. But I will look at it more "under the hood" - as I suspect there are more connections there! Yours truly, David On 2012-02-24, at 6:49 PM, Scott Hewitt wrote:

...

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 :

...
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

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

Robert Poor

3:32 p.m.

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

David Ogborn

5 Mar 5 Mar

9:56 a.m.

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 :

...
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

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

Robert Poor

12:36 p.m.

...

does the first shred terminate before you look at connections with the second?

...

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...

Okay, I get that. I'm personally happy that ChucK shreds de-allocate the resources that they've allocated upon exit, including connections. In your case, perhaps you could create a long-lived "connection shred" whose contract is to set up the patches, and let the other shreds send messages to it. That's the basic approach I used in my real-time setups.

Kassen

12:44 p.m.

On Mon, Mar 05, 2012 at 09:36:38AM -0800, Robert Poor wrote:

...

Okay, I get that. I'm personally happy that ChucK shreds de-allocate the resources that they've allocated upon exit, including connections. In your case, perhaps you could create a long-lived "connection shred" whose contract is to set up the patches, and let the other shreds send messages to it. That's the basic approach I used in my real-time setups.

Interesting. First of all; I prommised to look at this but then Stuff(tm) came on my path and I had to set priorities. I still mean to. More topically; Robert's approach is sound and a interesting way of dealing with namespace and scope, but it needs events that are static members of public classes. Name-space-wise those should be the same as UGens that are static members of public classes so in a strict way this shouldn't change anything but the syntax for making and breaking connections. (I think....) Clearly it would get arround the matter of connections being potentially unchucked as UGen references disapear so it might help in practice but I'm not sure that this help is desirable and intended behaviour. Yours, Kas.

4506

Age (days ago)

4516

Last active (days ago)

List overview

Download

12 comments

5 participants

participants (5)

David Ogborn
Kassen
mike clemow
Robert Poor
Scott Hewitt