Timing bug???

Oct 21, 2012 at 3:01pm

Timing bug???

Hello

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?

PB

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

Hi,

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.

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

-110

#233846
Oct 22, 2012 at 7:57am

Hello

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

Pierre

#233847

You must be logged in to reply to this topic.