[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] [commit] Still More OSCresponder issues

Actually the new version does this too:

		// responder without addr (addr is nil)
all[cmdName.asSymbol].do { |item| item.value(time, msg, addr) };
		// responder at command name
		all[signature].do { |item| item.value(time, msg, addr) };

Should be changed.


On 21 Nov 2004, at 12:06, Scott Wilson wrote:

Okay, this one is really bad and has been the source of some quite annoying bugs:

OSCMultiResponder : OSCresponder {
	var <>nodes;

	value { arg time, msg;
		nodes.do({ arg node; node.action.value(time, node, msg) });
	isEmpty { ^nodes.size == 0 }


-value here iterates over a collection which may be altered by its members before iteration is done (i.e. by removing themselves!). Considering how often I harp at my students for this sort of thing I'm embarrassed how long it took me to figure it out. I've changed it to the code below and committed it, as I think even if the system gets replaced, this is a current source of many bugs.

	value { arg time, msg;
		var iterlist;
		iterlist = nodes.copy;
		iterlist.do({ arg node; node.action.value(time, node, msg) });


of course you are right in general.

but try this:

a = [1, 2, 3, 4];
f = { a.do { arg item; item.value.postln } };
Routine {
	inf.do { arg i;
if(i % 2 == 0) { a.removeAt(0) } { a = a.add(8.rand); a.scramble };


Routine {
	inf.do { arg i;


I think there are no errors due to this. There is a bad OSCresponder problem, but I believe it is not due to this.
Not copying the array saves calculation in this time critical place.