Timing bug???

Oct 21, 2012 at 3:01pm

Timing bug???


In the below patch the getpenloc message looks to be delayed, if you look at max window you see that penloc messages arrive after write messages…
is it a bug or is it normal?


  1. TimingBug.maxpat
Oct 21, 2012 at 3:16pm


IMHO the scenario is :

- write A,
- append penloc attribute to the outlet queue and schedule the dumpout,
- write B,
- cancel the dumpout, append penloc attribute, schedule it again,
- write C,
- cancel the dumpout, append penloc attribute, schedule it again,
- dumpout.

AFAIK, it seems to be implemented with a Qelem task.

Oct 21, 2012 at 3:20pm

requesting the mouseposition from the dropfile object is simply kicked out of the
main thread, the left to right order order of your two messages stops beeing
valid when the penloc message arrives inside the GUI object.

the mouseposition is only tracked every 20 ms (or 50, i can never remember)
and so it would be asked too much to wait for it.

to get back to the desired order just store “write $1″in a buffer (for example
[zl reg] or [list x x]) and fetch it there when the mouse location later is beeing
reported from the GUI object´s output.

of course with “write A, write Z, write E” you will run into trouble.
you´d have to build a shift register to be able to store and fetch those safely.
but i beleive that your application approach will allow you to store multiple
keyboard inputs in another form than as consecutive messages.


Oct 22, 2012 at 7:57am


thanks a lot for your answers,it helps me a lot!



You must be logged in to reply to this topic.