lists@lowfrequency.or

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

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 

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 

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.

js-disobeys-law-of-cause-and-effect

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.

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

> 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

> 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

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.

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
>
>


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 

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.

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

>> 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

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

> 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
>>
>>


One question I have is why don't you just put the jit.lcd object in

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

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

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

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

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

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
> >>
> >>
>
>


> One question I have is why don't you just put the jit.lcd object in

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 

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

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.

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

> 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 

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.

>> 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


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 

> 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 

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.

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

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 

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 

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?

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 

>> 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 

> 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 

> Personally, I'd just use the JS Sketch object with fsaa disabled, 

> but I guess you have a reason for doing it this way.

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?

>
> 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


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 

> 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 

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

js disobeys law of cause and effect