js disobeys law of cause and effect

Nov 6, 2007 at 6:19pm

js disobeys law of cause and effect

Hello,

I am banging my head against the wall with a very strange javascript
problem.

I’ve always assumed that messages passed from a javascript outlet
occur in the order I send them. Apparently, this is not the case.

I have code to draw on jit.lcd automatically – it should move the pen
to an initial spot (“moveto x y”), send a bang (so that the pen is
updated), then get the dimensions of jit.lcd (“getdim”). I have a
function “dim (x,y)” that should receive the jit.lcd dimensions, and
in turn query it for the pen location (via the “getpenloc” message to
jit.lcd). I have a function in js called “penloc (x,y)” that should
receive data from the jit.lcd telling me where the pen is located so
i can continue drawing. Sounds very simple, no? In reality, I run
the code and see the message “getdim” which triggered the “getpenloc”
message AT THE END of the output from the js object. Which makes no
sense, because getdim would have to be sent in order to trigger the
drawing in the first place. Also, the “clear” message to jit.lcd is
executed LAST, even though it appears in the max window as having
been sent in the proper order (FIRST).

In fact, the entire output seems absolutely arbitrary to me, with
“getpenloc” calls all stacked in a row (or not at all). I have tried
using immediate mode to see if there is a difference, and tried
adding and subtracting [deferlow] and [jit.qball] objects after both
the jit.lcd and the js, but no hope.

Please help!

-Evan

#34491
Nov 6, 2007 at 6:22pm

While I understand roughly form your desription what’s going on,
there’s no way to really help you without an actual script and patch.

wes

On 11/6/07, evan.raskob [lists]

wrote:
> Hello,
>
> I am banging my head against the wall with a very strange javascript
> problem.
>
> I’ve always assumed that messages passed from a javascript outlet
> occur in the order I send them. Apparently, this is not the case.
>
> I have code to draw on jit.lcd automatically – it should move the pen
> to an initial spot (“moveto x y”), send a bang (so that the pen is
> updated), then get the dimensions of jit.lcd (“getdim”). I have a
> function “dim (x,y)” that should receive the jit.lcd dimensions, and
> in turn query it for the pen location (via the “getpenloc” message to
> jit.lcd). I have a function in js called “penloc (x,y)” that should
> receive data from the jit.lcd telling me where the pen is located so
> i can continue drawing. Sounds very simple, no? In reality, I run
> the code and see the message “getdim” which triggered the “getpenloc”
> message AT THE END of the output from the js object. Which makes no
> sense, because getdim would have to be sent in order to trigger the
> drawing in the first place. Also, the “clear” message to jit.lcd is
> executed LAST, even though it appears in the max window as having
> been sent in the proper order (FIRST).
>
> In fact, the entire output seems absolutely arbitrary to me, with
> “getpenloc” calls all stacked in a row (or not at all). I have tried
> using immediate mode to see if there is a difference, and tried
> adding and subtracting [deferlow] and [jit.qball] objects after both
> the jit.lcd and the js, but no hope.
>
> Please help!
>
>
>
> -Evan
>
>

#116504
Nov 6, 2007 at 9:03pm

I guess there’s no way around it:

http://lowfrequency.org/stuff/js-lcd-draw-test.zip

I don’t want to make it public, but there it is. I’ll take it down
soon.

Thanks
Evan

On Nov 6, 2007, at 6:22 PM, Wesley Smith wrote:

> While I understand roughly form your desription what’s going on,
> there’s no way to really help you without an actual script and patch.
>
> wes
>
> On 11/6/07, evan.raskob [lists]

wrote:
>> Hello,
>>
>> I am banging my head against the wall with a very strange javascript
>> problem.
>>
>> I’ve always assumed that messages passed from a javascript outlet
>> occur in the order I send them. Apparently, this is not the case.
>>
>> I have code to draw on jit.lcd automatically – it should move the pen
>> to an initial spot (“moveto x y”), send a bang (so that the pen is
>> updated), then get the dimensions of jit.lcd (“getdim”). I have a
>> function “dim (x,y)” that should receive the jit.lcd dimensions, and
>> in turn query it for the pen location (via the “getpenloc” message to
>> jit.lcd). I have a function in js called “penloc (x,y)” that should
>> receive data from the jit.lcd telling me where the pen is located so
>> i can continue drawing. Sounds very simple, no? In reality, I run
>> the code and see the message “getdim” which triggered the “getpenloc”
>> message AT THE END of the output from the js object. Which makes no
>> sense, because getdim would have to be sent in order to trigger the
>> drawing in the first place. Also, the “clear” message to jit.lcd is
>> executed LAST, even though it appears in the max window as having
>> been sent in the proper order (FIRST).
>>
>> In fact, the entire output seems absolutely arbitrary to me, with
>> “getpenloc” calls all stacked in a row (or not at all). I have tried
>> using immediate mode to see if there is a difference, and tried
>> adding and subtracting [deferlow] and [jit.qball] objects after both
>> the jit.lcd and the js, but no hope.
>>
>> Please help!
>>
>>
>>
>> -Evan
>>
>>

#116505
Nov 6, 2007 at 9:15pm

One question I have is why don’t you just put the jit.lcd object in
your javasript?
wes

On 11/6/07, evan.raskob [lists]

wrote:
> I guess there’s no way around it:
>
> http://lowfrequency.org/stuff/js-lcd-draw-test.zip
>
> I don’t want to make it public, but there it is. I’ll take it down
> soon.
>
>
> Thanks
> Evan
>
>
> On Nov 6, 2007, at 6:22 PM, Wesley Smith wrote:
>
> > While I understand roughly form your desription what’s going on,
> > there’s no way to really help you without an actual script and patch.
> >
> > wes
> >
> > On 11/6/07, evan.raskob [lists]
wrote:
> >> Hello,
> >>
> >> I am banging my head against the wall with a very strange javascript
> >> problem.
> >>
> >> I’ve always assumed that messages passed from a javascript outlet
> >> occur in the order I send them. Apparently, this is not the case.
> >>
> >> I have code to draw on jit.lcd automatically – it should move the pen
> >> to an initial spot (“moveto x y”), send a bang (so that the pen is
> >> updated), then get the dimensions of jit.lcd (“getdim”). I have a
> >> function “dim (x,y)” that should receive the jit.lcd dimensions, and
> >> in turn query it for the pen location (via the “getpenloc” message to
> >> jit.lcd). I have a function in js called “penloc (x,y)” that should
> >> receive data from the jit.lcd telling me where the pen is located so
> >> i can continue drawing. Sounds very simple, no? In reality, I run
> >> the code and see the message “getdim” which triggered the “getpenloc”
> >> message AT THE END of the output from the js object. Which makes no
> >> sense, because getdim would have to be sent in order to trigger the
> >> drawing in the first place. Also, the “clear” message to jit.lcd is
> >> executed LAST, even though it appears in the max window as having
> >> been sent in the proper order (FIRST).
> >>
> >> In fact, the entire output seems absolutely arbitrary to me, with
> >> “getpenloc” calls all stacked in a row (or not at all). I have tried
> >> using immediate mode to see if there is a difference, and tried
> >> adding and subtracting [deferlow] and [jit.qball] objects after both
> >> the jit.lcd and the js, but no hope.
> >>
> >> Please help!
> >>
> >>
> >>
> >> -Evan
> >>
> >>
>
>

#116506
Nov 6, 2007 at 9:30pm

> One question I have is why don’t you just put the jit.lcd object in
> your javasript?

IIRC, jit.lcd has issues when used from within scripting. Regardless,
jit.lcd drawing commands do *not* execute until you trigger a bang,
which is why I believe that penloc doesn’t update when you’re
expecting it.

-Joshua

#116507
Nov 6, 2007 at 9:44pm

Hi Joshua,

I thought I remembered some threads about not using jit.lcd for
scripting, because it doesn’t work properly.

About sending bangs – yes, I noticed that, which is why I am sending
out many bangs to update the pen location after each “moveto” command.

Even with that, try hooking up a print to the output of the js object
and see what kind of funky order the commands are printed out in.

Thanks
Evan

On Nov 6, 2007, at 9:30 PM, Joshua Kit Clayton wrote:

>> One question I have is why don’t you just put the jit.lcd object in
>> your javasript?
>
> IIRC, jit.lcd has issues when used from within scripting.
> Regardless, jit.lcd drawing commands do *not* execute until you
> trigger a bang, which is why I believe that penloc doesn’t update
> when you’re expecting it.
>
> -Joshua

#116508
Nov 6, 2007 at 9:53pm

On Nov 6, 2007, at 1:44 PM, evan.raskob [lists] wrote:

> I thought I remembered some threads about not using jit.lcd for
> scripting, because it doesn’t work properly.
>
> About sending bangs – yes, I noticed that, which is why I am
> sending out many bangs to update the pen location after each
> “moveto” command.
>
> Even with that, try hooking up a print to the output of the js
> object and see what kind of funky order the commands are printed
> out in.

This is expected with @mode defer, no? It pushes it to the end of the
queue. I don’t see anything other than what you’d expect with this
sort of feedback loop and deferred messages. I would recommend you
segment this so that it doesn’t need feedback in this way–e.g. use
two js files one to make the bang, getpenloc calls synchronously as
necessary and pass in to a second js which does the drawing. Or
something along these lines which avoids a feedback loop.

Personally, I’d just use the JS Sketch object with fsaa disabled, but
I guess you have a reason for doing it this way.

-Joshua

#116509
Nov 7, 2007 at 9:48am

Hi Joshua

The jit.qball was in there because I felt that events were getting
lost between the js and jit.lcd. Even taking it out, it doesn’t
appear to work properly. I’m still a bit fuzzy as to how events that
trigger events in other objects could happen after the events that
they were supposed to trigger – perhaps there’s something about
scheduling that I’m missing here?

I’m not very optimistic about using 2 js objects to do this – if the
events are coming from jit.lcd and an uneven rate, will separating js
objects make a difference?

The reason I’m using jit.lcd instead of pure js is because I need to
output to a matrix at some point. But now that you mention it, I’d
forgotten that I could use jsui for this… I can use “tonamedmatrix”
to copy the contents of the jsui to a matrix, right?

Best
Evan

On Nov 6, 2007, at 9:53 PM, Joshua Kit Clayton wrote:

>
> On Nov 6, 2007, at 1:44 PM, evan.raskob [lists] wrote:
>
>> I thought I remembered some threads about not using jit.lcd for
>> scripting, because it doesn’t work properly.
>>
>> About sending bangs – yes, I noticed that, which is why I am
>> sending out many bangs to update the pen location after each
>> “moveto” command.
>>
>> Even with that, try hooking up a print to the output of the js
>> object and see what kind of funky order the commands are printed
>> out in.
>
> This is expected with @mode defer, no? It pushes it to the end of
> the queue. I don’t see anything other than what you’d expect with
> this sort of feedback loop and deferred messages. I would recommend
> you segment this so that it doesn’t need feedback in this way–e.g.
> use two js files one to make the bang, getpenloc calls
> synchronously as necessary and pass in to a second js which does
> the drawing. Or something along these lines which avoids a feedback
> loop.
>
> Personally, I’d just use the JS Sketch object with fsaa disabled,
> but I guess you have a reason for doing it this way.
>
> -Joshua

#116510
Nov 7, 2007 at 4:46pm

On Nov 7, 2007, at 1:48 AM, evan.raskob [lists] wrote:

> The jit.qball was in there because I felt that events were getting
> lost between the js and jit.lcd. Even taking it out, it doesn’t
> appear to work properly. I’m still a bit fuzzy as to how events
> that trigger events in other objects could happen after the events
> that they were supposed to trigger – perhaps there’s something
> about scheduling that I’m missing here?

Well if you take the defer out, you might re-enter the same JS before
the previous function has completed, which also would give you some
odd behavior.

> I’m not very optimistic about using 2 js objects to do this – if
> the events are coming from jit.lcd and an uneven rate, will
> separating js objects make a difference?

You could if you separate the logic of iterating N times (no
feedback), querying values to be used by another one, and the actual
drawing, but perhaps not worth it. Sorry I don’t have time to be more
detailed in my suggestion.

> The reason I’m using jit.lcd instead of pure js is because I need
> to output to a matrix at some point. But now that you mention it,
> I’d forgotten that I could use jsui for this… I can use
> “tonamedmatrix” to copy the contents of the jsui to a matrix, right?

Yes. This is what I’d use. You can use the Sketch.gettextinfo() to
get the width and height of the string for your positioning needs.

-Joshua

#116511
Nov 8, 2007 at 9:29pm

Thanks Joshua for your help. jsui is the way to go.

Best
Evan

On Nov 7, 2007, at 4:46 PM, Joshua Kit Clayton wrote:

>
> On Nov 7, 2007, at 1:48 AM, evan.raskob [lists] wrote:
>
>> The jit.qball was in there because I felt that events were getting
>> lost between the js and jit.lcd. Even taking it out, it doesn’t
>> appear to work properly. I’m still a bit fuzzy as to how events
>> that trigger events in other objects could happen after the events
>> that they were supposed to trigger – perhaps there’s something
>> about scheduling that I’m missing here?
>
> Well if you take the defer out, you might re-enter the same JS
> before the previous function has completed, which also would give
> you some odd behavior.
>
>> I’m not very optimistic about using 2 js objects to do this – if
>> the events are coming from jit.lcd and an uneven rate, will
>> separating js objects make a difference?
>
> You could if you separate the logic of iterating N times (no
> feedback), querying values to be used by another one, and the
> actual drawing, but perhaps not worth it. Sorry I don’t have time
> to be more detailed in my suggestion.
>
>> The reason I’m using jit.lcd instead of pure js is because I need
>> to output to a matrix at some point. But now that you mention it,
>> I’d forgotten that I could use jsui for this… I can use
>> “tonamedmatrix” to copy the contents of the jsui to a matrix, right?
>
> Yes. This is what I’d use. You can use the Sketch.gettextinfo() to
> get the width and height of the string for your positioning needs.
>
> -Joshua

#116512

You must be logged in to reply to this topic.