Update: for some reason my node-webkit port starts up either with audio on, or in a loop trying to connect to a nonexistent backend on the virtual machine. Pd-Vanilla starts up in a better state, but when I turn on its audio I get the same behavior as it continually tries and fails to connect. In both cases it throttles all gui calls that are waiting in the queue, causing the greater than 2x slowdown in the [bng] button flashing off. (Mouse motion messages aren't queued which is why I wasn't seeing the slowdown until now.)

-Jonathan

On Wednesday, January 21, 2015 6:40 PM, Jonathan Wilkes via Pd-list <pd-list@lists.iem.at> wrote:

Hi list,

Any idea why clock_delay would create a delay that is rougly 2.5 times longer than what it is supposed to be?

It's weird because I can send a long stream of mouse motion messages from node-webkit to Pd, and receive the response fast enough that I can't detect the latency when I move objects around on the screen. When I click a [bng], the message to change the button black is received immediately, but the message to "un-flash" the button is sent way too late. I don't think it's a problem with socket latency, but on the other hand I can't think of what I've changed on the Pd side that would mess with the clock.

This is on a virtual machine running Debian testing (Jessie) 32-bit. Pd Vanilla's bng time looks fine on the same machine.

-Jonathan

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list