Discussion:
OSCFunc may not respond if triggered quickly
ddw_music
2014-07-21 00:31:36 UTC
Permalink
Bizarro messed up thing #1:

1. Play synth by {}.play. Its duration is very short.
2. Install OSCFunc to watch for the '/n_end' message.
3. The OSCFunc *does not fire*.

(
a = {
FreeSelf.kr(Phasor.ar(0, 1, 0, 1e6) < 2048);
Silent.ar(1)
}.play;

o.free;
o = OSCFunc({ |msg| msg.debug("got it") }, '/n_end', s.addr);
)

This is weird because OSC transmission takes time; d_recv takes time; the
synth takes time (46 ms); and the return OSC transmission takes time, and
somehow all of that takes less time than "o.free; o = OSCFunc..." -- if this
is really true, then the interpreter is running like molasses on my machine.
NO WAY should those two expressions take such a long time.

bench {
o.free;
o = OSCFunc({ |msg| msg.debug("got it") }, '/n_end', s.addr);
};

time to run: 9.8943710327148e-05 seconds.

So basically the OSCFunc should have been put in at least 46 ms before it
would be triggered, but... it didn't trigger.

???

hjh




--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/OSCFunc-may-not-respond-if-triggered-quickly-tp7612372.html
Sent from the SuperCollider Developers New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
James Harkins
2014-07-21 03:55:59 UTC
Permalink
Post by ddw_music
1. Play synth by {}.play. Its duration is very short.
2. Install OSCFunc to watch for the '/n_end' message.
3. The OSCFunc *does not fire*.
(
a = {
FreeSelf.kr(Phasor.ar(0, 1, 0, 1e6) < 2048);
Silent.ar(1)
}.play;
o.free;
o = OSCFunc({ |msg| msg.debug("got it") }, '/n_end', s.addr);
)
Oops, in this example, it should be >= 2048, not <.

It's >= in my original case, but I wrote it wrong here. For me, it didn't fire
in my original case.

hjh


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Scott Wilson
2014-07-21 08:03:51 UTC
Permalink
Hey James,

The time shouldn’t really matter. Since it’s executed as a block, any OSC messages received should cue until the interpreter is free. If you add trace or a manual function via addOSCRecvFunc, you’ll see that is happening. it is weird.

S.
Post by James Harkins
Post by ddw_music
1. Play synth by {}.play. Its duration is very short.
2. Install OSCFunc to watch for the '/n_end' message.
3. The OSCFunc *does not fire*.
(
a = {
FreeSelf.kr(Phasor.ar(0, 1, 0, 1e6) < 2048);
Silent.ar(1)
}.play;
o.free;
o = OSCFunc({ |msg| msg.debug("got it") }, '/n_end', s.addr);
)
Oops, in this example, it should be >= 2048, not <.
It's >= in my original case, but I wrote it wrong here. For me, it didn't fire
in my original case.
hjh
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Scott Wilson
2014-07-21 08:29:48 UTC
Permalink
Okay, I think I see the problem. Shouldn’t be hard to fix.

S.
Post by Scott Wilson
Hey James,
The time shouldn’t really matter. Since it’s executed as a block, any OSC messages received should cue until the interpreter is free. If you add trace or a manual function via addOSCRecvFunc, you’ll see that is happening. it is weird.
S.
Post by James Harkins
Post by ddw_music
1. Play synth by {}.play. Its duration is very short.
2. Install OSCFunc to watch for the '/n_end' message.
3. The OSCFunc *does not fire*.
(
a = {
FreeSelf.kr(Phasor.ar(0, 1, 0, 1e6) < 2048);
Silent.ar(1)
}.play;
o.free;
o = OSCFunc({ |msg| msg.debug("got it") }, '/n_end', s.addr);
)
Oops, in this example, it should be >= 2048, not <.
It's >= in my original case, but I wrote it wrong here. For me, it didn't fire
in my original case.
hjh
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Scott Wilson
2014-07-21 10:10:33 UTC
Permalink
James, can you test the attached patch?

The problem was the old modifying a collection while it’s being iterated over I’m afraid. Function-play adds a oneShot OSCFunc. This was only a problem when you had multiple responders on the same key, with the oneShot running before, which is probably why it hasn’t come up. (Although I have some strange memory of something like this that I thought was fixed?)

Anyway, the approach here defers all adds and removes while a message is in process. This avoids needing to copy the func collection on every message.

(Hmm perhaps one could also copy and replace the collection on adds and removes. That might be simpler. Need to think about it.)

S.
ddw_music
2014-07-22 14:00:34 UTC
Permalink
On Monday, July 21, 2014 6:12:10 AM EDT, Scott Wilson [via New
Post by Scott Wilson
James, can you test the attached patch?
The problem was the old modifying a collection while it’s being
iterated over I’m afraid.
I've applied the patch locally and it does fix the problem, thanks.

Between this approach (the collection of deferred changes) and the
alternative of copying the collection of responders only when adding and
removing, I don't know which would be better. It seems to me that the
approach in the patch adds some CPU time for every evaluation of a
responder (whether it adds/removes a responder or not), whereas the copy
approach would incur CPU cost only when actually adding/removing. Would be
worth benchmarking, though I don't have time to do it.

hjh




--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/OSCFunc-may-not-respond-if-triggered-quickly-tp7612372p7612414.html
Sent from the SuperCollider Developers New (Use this!!!!) mailing list archive at Nabble.com.
Scott Wilson
2014-10-21 10:09:37 UTC
Permalink
Post by ddw_music
On Monday, July 21, 2014 6:12:10 AM EDT, Scott Wilson [via New
Post by Scott Wilson
James, can you test the attached patch?
The problem was the old modifying a collection while it’s being
iterated over I’m afraid.
I've applied the patch locally and it does fix the problem, thanks.
Between this approach (the collection of deferred changes) and the
alternative of copying the collection of responders only when adding and
removing, I don't know which would be better. It seems to me that the
approach in the patch adds some CPU time for every evaluation of a
responder (whether it adds/removes a responder or not), whereas the copy
approach would incur CPU cost only when actually adding/removing. Would be
worth benchmarking, though I don't have time to do it.
Just getting back to this. The copy on add/remove approach works, is simpler, and less overhead in the majority of cases I think. But, it needs to have this added to FunctionList:

copy { ^super.copy.array_(array.copy) }

That’s the behaviour I would have expected for FunctionList:copy anyway, but any reason not to make that change?

S.
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Julian Rohrhuber
2014-10-21 18:36:12 UTC
Permalink
Post by Scott Wilson
Post by ddw_music
On Monday, July 21, 2014 6:12:10 AM EDT, Scott Wilson [via New
Post by Scott Wilson
James, can you test the attached patch?
The problem was the old modifying a collection while it’s being
iterated over I’m afraid.
I've applied the patch locally and it does fix the problem, thanks.
Between this approach (the collection of deferred changes) and the
alternative of copying the collection of responders only when adding and
removing, I don't know which would be better. It seems to me that the
approach in the patch adds some CPU time for every evaluation of a
responder (whether it adds/removes a responder or not), whereas the copy
approach would incur CPU cost only when actually adding/removing. Would be
worth benchmarking, though I don't have time to do it.
copy { ^super.copy.array_(array.copy) }
That’s the behaviour I would have expected for FunctionList:copy anyway, but any reason not to make that change?
yes, please add this, it is really needed.
I've become more aware of making objects better copyable, it is important.
_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Loading...