Thijs Koerselman

I want to switch different obj models for jit.gl.model during 

performance, but every time I change a model, jit.gl.render (including 

all other stuff that being rendered) seems to be stuck for a little 

while, making every switch very obvious and unusable.

I tried using a second dummy window + render-> drawto dummy -> switch 

file -> drawto normal window/render. This makes no difference.

I want to switch different obj models for jit.gl.model during 
performance, but every time I change a model, jit.gl.render (including 
all other stuff that being rendered) seems to be stuck for a little 
while, making every switch very obvious and unusable.

I tried using a second dummy window + render-> drawto dummy -> switch 
file -> drawto normal window/render. This makes no difference.

switching-jit-gl-model

I found 2 possible workarounds, but they are really annoying.

1: use different instances of gl.model for every model that you use, and 

switch render context using drawto. I have to keep sending all the 

position, material and other configurations to all of the models. Is 

this going to charge my gpu if the objects are not rendered to a window?

2: Bring all the different object together in one obj file and put them 

in different groups. I think this is a better one than the first, but 

also not very handy if have to make files with all the possible objects 

> I want to switch different obj models for jit.gl.model during 

> performance, but every time I change a model, jit.gl.render (including 

> all other stuff that being rendered) seems to be stuck for a little 

> while, making every switch very obvious and unusable.

> I tried using a second dummy window + render-> drawto dummy -> switch 

> file -> drawto normal window/render. This makes no difference.

> ------------------------------------------------------------ ---------

> To unsubscribe, e-mail: max-msp-unsubscribe@cycling74.com

> For additional commands, e-mail: max-msp-help@cycling74.com

1: use different instances of gl.model for every model that you use, and 
switch render context using drawto. I have to keep sending all the 
position, material and other configurations to all of the models. Is 
this going to charge my gpu if the objects are not rendered to a window?

2: Bring all the different object together in one obj file and put them 
in different groups. I think this is a better one than the first, but 
also not very handy if have to make files with all the possible objects 
that you might want to use one day.

Thijs Koerselman wrote:
> I want to switch different obj models for jit.gl.model during 
> performance, but every time I change a model, jit.gl.render (including 
> all other stuff that being rendered) seems to be stuck for a little 
> while, making every switch very obvious and unusable.
>
> I tried using a second dummy window + render-> drawto dummy -> switch 
> file -> drawto normal window/render. This makes no difference.
>
> How can I solve this? Thanks.
>
> Thijs
>
>
>  ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: max-msp-unsubscribe@cycling74.com
> For additional commands, e-mail: max-msp-help@cycling74.com
>
>

..............................
http://www.nano-soundworks.com


I use your first workaround with no problems (50 to 100 models) to create

I was using the drawto message, and then I discover the "enable" flag.

From my experience, the objects that are not drawn are not charging the GPU.

> I found 2 possible workarounds, but they are really annoying.

> 1: use different instances of gl.model for every model that you use, and

> switch render context using drawto. I have to keep sending all the

> position, material and other configurations to all of the models. Is

> this going to charge my gpu if the objects are not rendered to a window?

> 2: Bring all the different object together in one obj file and put them

> in different groups. I think this is a better one than the first, but

> also not very handy if have to make files with all the possible objects

> > I want to switch different obj models for jit.gl.model during

> > performance, but every time I change a model, jit.gl.render (including

> > all other stuff that being rendered) seems to be stuck for a little

> > while, making every switch very obvious and unusable.

> > I tried using a second dummy window + render-> drawto dummy -> switch

> > file -> drawto normal window/render. This makes no difference.

> > ------------------------------------------------------------ ---------

> > To unsubscribe, e-mail: max-msp-unsubscribe@cycling74.com

> > For additional commands, e-mail: max-msp-help@cycling74.com

I use your first workaround with no problems (50 to 100 models) to create
models animations.

2005/10/7, Thijs Koerselman :
>
> I found 2 possible workarounds, but they are really annoying.
>
> 1: use different instances of gl.model for every model that you use, and
> switch render context using drawto. I have to keep sending all the
> position, material and other configurations to all of the models. Is
> this going to charge my gpu if the objects are not rendered to a window?
>
> 2: Bring all the different object together in one obj file and put them
> in different groups. I think this is a better one than the first, but
> also not very handy if have to make files with all the possible objects
> that you might want to use one day.
>
> Please tell me there is a better way.
>
> best, t_
>
>
>
> Thijs Koerselman wrote:
> > I want to switch different obj models for jit.gl.model during
> > performance, but every time I change a model, jit.gl.render (including
> > all other stuff that being rendered) seems to be stuck for a little
> > while, making every switch very obvious and unusable.
> >
> > I tried using a second dummy window + render-> drawto dummy -> switch
> > file -> drawto normal window/render. This makes no difference.
> >
> > How can I solve this? Thanks.
> >
> > Thijs
> >
> >
> >  ------------------------------------------------------------ ---------
> > To unsubscribe, e-mail: max-msp-unsubscribe@cycling74.com
> > For additional commands, e-mail: max-msp-help@cycling74.com
> >
> >
>
> --
>
> ..............................
> http://www.nano-soundworks.com
>
>
>  ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: max-msp-unsubscribe@cycling74.com
> For additional commands, e-mail: max-msp-help@cycling74.com
>
>


> I use your first workaround with no problems (50 to 100 models) to 

> I was using the drawto message, and then I discover the "enable" flag.

> >From my experience, the objects that are not drawn are not charging 

Thanks Bertrand, that's good news. I couldn't really use the second 

option after all, because it makes the original function of drawgroup 

useless. I'm really happy that the first one seems to be no problem.

bertrand wrote:
> Hello,
>
> I use your first workaround with no problems (50 to 100 models) to 
> create models animations.
>
> I was using the drawto message, and then I discover the "enable" flag.
>
>  >From my experience, the objects that are not drawn are not charging 
> the GPU.
>
> Bertrand
>

Thanks Bertrand, that's good news. I couldn't really use the second 
option after all, because it makes the original function of drawgroup 
useless. I'm really happy that the first one seems to be no problem.

I know this is an old thread, but if you guys are still listening I'm wondering how you implemented this. I recently came up against the same problem.

At first I figured I would use jit.jit.model's matrix output and switch between sending several instances to jit.jit.mesh (which is also nice because I can distort the mesh), but I found this makes it exponentially slower. I don't understand this as I can't see how jit.jit.model would render it as anything other than just a mesh.

I though I could solve this performance problem by saving the matrices as .jxf files, but this didn't work either and I'm not sure why.

I had considered switching between render contexts from the beginning, but ignorantly figured I'd have to duplicate all the jit.gl objects. After seeing your thread I tried using send and recieve with drawto (and name for the window) to switch contexts in all my objects at once. The problem is that when render is changed at all, you have to reload jit.gl.model.

Finally, in a last ditch effort I just used a different jit.gl.render for jit model and turned them on and off. I didn't have to reload the models, but there was still about ten seconds latency when switching.

As always, there has got to be a better way to do this.

I know this is an old thread, but if you guys are still listening I'm wondering how you implemented this.  I recently came up against the same problem.  

At first I figured I would use jit.jit.model's matrix output and switch between sending several instances to jit.jit.mesh (which is also nice because I can distort the mesh), but I found this makes it exponentially slower.  I don't understand this as I can't see how jit.jit.model would render it as anything other than just a mesh.  

I though I could solve this performance problem by saving the matrices as .jxf files, but this didn't work either and I'm not sure why.  

I had considered switching between render contexts from the beginning, but ignorantly figured I'd have to duplicate all the jit.gl objects.  After seeing your thread I tried using send and recieve with drawto (and name for the window) to switch contexts in all my objects at once.  The problem is that when render is changed at all, you have to reload jit.gl.model.  

Finally, in a last ditch effort I just used a different jit.gl.render for jit model and turned them on and off.  I didn't have to reload the models, but there was still about ten seconds latency when switching.  

As always, there has got to be a better way to do this.


i would second the enable $1 method, i also found this works quite well inside poly~. it provides a manageable way of creating n copies of a 3D shape, and routing messages to specific instances (voices), as well as global messaging (all voices).

i havent done this with jit.gl.model yet, but i have done it with jit.gl.gridshape...

how does one create different model groups in maya or cinema4d? Is it just automatic if I group a bunch of objects together and export the whole group?

how does one create different model groups in maya or cinema4d?  Is it just automatic if I group a bunch of objects together and export the whole group?


Can you possibly give a more detailed description of the enable $1 method, or post an example patch? Am I correct that you're still using multiple render contexts? If so, how are using this with poly~ without the drawto message? Also, don't you have to keep simultaneously changing the name of the window as you switch between contexts? Are you sending the enable message to just jit.gl.render or the rest of the objects as well? There must be something I'm not getting here, because this method doesn't seem that different from what I ended up trying, which still resulted in latency. Could this have to do with my .obj files being extremely large (a couple are even over 100 mb)?

Can you possibly give a more detailed description of the enable $1 method, or post an example patch?  Am I correct that you're still using multiple render contexts?  If so, how are using this with poly~ without the drawto message?  Also, don't you have to keep simultaneously changing the name of the window as you switch between contexts?  Are you sending the enable message to just jit.gl.render or the rest of the objects as well?  There must be something I'm not getting here, because this method doesn't seem that different from what I ended up trying, which still resulted in latency.  Could this have to do with my .obj files being extremely large (a couple are even over 100 mb)?

dont really have time to knock something up with jit.gl.sketch...

but if you check out this patch by randy jones, you should get an idea of how it works.

http://2uptech.com/zip/jit.gl.render.poly~.zip

there's no need for multiple render contexts, unless you want to render to different windows (multiple screens). you only need to send enable msg to the objects you need to turn on/off. dont send to jit.gl.render, cos that controls your whole GL scene!

large files could be part of the problem, but i guess that depends on your system specs.

dont really have time to knock something up with jit.gl.sketch...
but if you check out this patch by randy jones, you should get an idea of how it works.

Got it. I had tried using drawto first and somehow made things so complicated for myself that I missed the simple answer.

Thanks for the tip about poly~. It would overcomplicate things for simply switching between models, but I'm already thinking about using it in other gl patches.

What I still don't get is why it takes more juice to patch jit.gl.model through jit.gl.mesh instead of rendering it alone. My intuition tells me this is similar to how sending a movie directly to the window is exponentially faster than using a patch cord. Are patch cords bottlenecks? Can anyone explain this to me?

Got it.  I had tried using drawto first and somehow made things so complicated for myself that I missed the simple answer.  

Thanks for the tip about poly~.  It would overcomplicate things for simply switching between models, but I'm already thinking about using it in other gl patches.  

What I still don't get is why it takes more juice to patch jit.gl.model through jit.gl.mesh instead of rendering it alone.  My intuition tells me this is similar to how sending a movie directly to the window is exponentially faster than using a patch cord.  Are patch cords bottlenecks?  Can anyone explain this to me?


I should also mention for posterity that the decode object was invaluable in controlling the enable messages. Not sure if it is one of the lesser known objects, but it was to me and as usual I tried out several much less elegant methods before discovering it. Oh, so many objects...

I should also mention for posterity that the decode object was invaluable in controlling the enable messages.  Not sure if it is one of the lesser known objects, but it was to me and as usual I tried out several much less elegant methods before discovering it.  Oh, so many objects...


yeah tell me about it, there have been so many times that I make something in some crazy complicated way only to find out there was an object that does exactly what I needed much easier. I wish there was a document in the tutorials/reference that showed all the objects and basic definitions of what they do with a link to their help patch and ref doc.

I also wish that everything was thoroughly documented with all the abilities for each object, as there are so many things that I only found out through random forum posts. IE the waveform message that draws a line at a specified time in the waveform.. I never knew that till I saw a patch with it that was posted on the list, and couldn't find it documented anywhere.

yeah tell me about it, there have been so many times that I make something in some crazy complicated way only to find out there was an object that does exactly what I needed much easier.  I wish there was a document in the tutorials/reference that showed all the objects and basic definitions of what they do with a link to their help patch and ref doc.  

I also wish that everything was thoroughly documented with all the abilities for each object, as there are so many things that I only found out through random forum posts.  IE the waveform message that draws a line at a specified time in the waveform.. I never knew that till I saw a patch with it that was posted on the list, and couldn't find it documented anywhere.


zach wrote on Thu, 26 February 2009 09:53

it's hard to say without seeing your patch. you are only banging the matrix through to jit.gl.mesh once right? not every frame.

other than that, 100mb obj files are probably the culprit. i don't know much about obj but that sounds pretty big.

if you are feeling frisky, you can try out jit-ogre (still only max 4, hope to release new version for 5 and windows this weekend or next week). it should be a lot more efficient at handling large models. only problem is you will have to convert from obj to mesh, but there are converters that do that.

zach wrote on Thu, 26 February 2009 09:53
What I still don't get is why it takes more juice to patch jit.gl.model through jit.gl.mesh instead of rendering it alone.  My intuition tells me this is similar to how sending a movie directly to the window is exponentially faster than using a patch cord.  Are patch cords bottlenecks?  Can anyone explain this to me?

other than that, 100mb obj files are probably the culprit.  i don't know much about obj but that sounds pretty big.

if you are feeling frisky, you can try out jit-ogre (still only max 4, hope to release new version for 5 and windows this weekend or next week).  it should be a lot more efficient at handling large models.  only problem is you will have to convert from obj to mesh, but there are converters that do that.

Axiom-Crux wrote on Thu, 26 February 2009 12:27

...I wish there was a document in the tutorials/reference that showed all the objects and basic definitions of what they do with a link to their help patch and ref doc.

Type "thesaurus" into the help file. I think we're still trying 

to figure out where'd be the best place to put the massive link 

for this. Got any suggestions? It's time to revisit the question.

I also wish that everything was thoroughly documented with all the abilities for each object, as there are so many things that I only found out through random forum posts.

I always recommend www.maxobjects.com for this, since it 

contains all of our stuff and everything that everyone else 

...IE the waveform message that draws a line at a specified time in the waveform.. I never knew that till I saw a patch with it that was posted on the list, and couldn't find it documented anywhere.

I think you're referring to the "line" message, which has been

around for a long time and was and is documented on the refpage

for longer than you've used Max. There has been a recent change

in the functionality of the object (i.e., the line disappearing

from the display when a negative or zero value is sent), which 

As has been said often, the help files are NOT the place you

go to discover everything an object does - listing "everything" 

an object would do isn't the idea behind the help files. They

are supposed to list what is arguably the more general things

that someone would wish to do. This may be one of those features

that should be added, and I'll have a look at it.

That said, Max does continue to reward both the patient 

explorer and the readerly user. Since we have a diverse base

of customers whose notions of "basic" may vary widely

(particularly when we're talking about the usage of objects

that provide high-level functionality), I'm sure there are

going to be all kinds of cases where something that you'd want

to do won't show up in a help file. The refpage is your friend,

and the last authority in cases such as these.

Axiom-Crux wrote on Thu, 26 February 2009 12:27...I wish there was a document in the tutorials/reference that showed all the objects and basic definitions of what they do with a link to their help patch and ref doc.

Type "thesaurus" into the help file. I think we're still trying 
to figure out where'd be the best place to put the massive link 
for this. Got any suggestions? It's time to revisit the question.

Quote:I also wish that everything was thoroughly documented with all the abilities for each object, as there are so many things that I only found out through random forum posts.

I always recommend www.maxobjects.com for this, since it 
contains all of our stuff and everything that everyone else 
makes, as well. 

Quote:...IE the waveform message that draws a line at a specified time in the waveform.. I never knew that till I saw a patch with it that was posted on the list, and couldn't find it documented anywhere.

I think you're referring to the "line" message, which has been
around for a long time and was and is documented on the refpage
for longer than you've used Max. There has been a recent change
in the functionality of the object (i.e., the line disappearing
from the display when a negative or zero value is sent), which 
is probably where you ran across it.

As has been said often, the help files are NOT the place you
go to discover everything an object does - listing "everything" 
an object would do isn't the idea behind the help files. They
are supposed to list what is arguably the more general things
that someone would wish to do. This may be one of those features
that should be added, and I'll have a look at it.

That said, Max does continue to reward both the patient 
explorer and the readerly user. Since we have a diverse base
of customers whose notions of "basic" may vary widely
(particularly when we're talking about the usage of objects
that provide high-level functionality), I'm sure there are
going to be all kinds of cases where something that you'd want
to do won't show up in a help file. The refpage is your friend,
and the last authority in cases such as these.


true, and Ive recently been using the reference more often, mainly due to the fact that the help patches have links to the reference now.

When I started using max I was under the impression that the help files were supposed to show all the features of a particular object, and Ive come to learn the fact that they are not, as you mention.

I didn't think of using maxobjects.com for searching built in objects, good idea!

I love the new feature of clicking on an inlet and getting the full list of attributes and messages, and being able to choose one and get a message set up for that parameter. It would be great if these made more then just message boxes with $1 $2 $3 etc.. I think it could be more useful to have certain messages setup to make pak with floats or ints attached (IE "pak camera 0. 0. 2." or whatever the current value of the attribute is set, possibly even with floats already attached to the appropriate inputs). Just a thought.

I love the new feature of clicking on an inlet and getting the full list of attributes and messages, and being able to choose one and get a message set up for that parameter.  It would be great if these made more then just message boxes with $1 $2 $3 etc..  I think it could be more useful to have certain messages setup to make pak with floats or ints attached (IE "pak camera 0. 0. 2." or whatever the current value of the attribute is set, possibly even with floats already attached to the appropriate inputs).  Just a thought.


Axiom-Crux wrote on Thu, 26 February 2009 19:19

I know this is straying from the original thread, but I also would add that in a lot of cases, there are messages or attributes that are only 1 or 0, or boolean. They show up in the popup list as [int] which is a little misleading. Knowing that a particular parameter only can be on or off, rather than a range of int values, would be helpful. Most of these have check boxes in the Inspector, which is a giveaway for their boolean-type values, but some still have a number (like "interp" for jit.matrix, or "visible" for jit.gl.handle). Also there are a few places where one needs to type a parameter which is a member of a restricted list, like in jit.gl.gridshape @shape, which I think should be a dropdown in the Inspector so that all the choices are evident and one doesn't have to know the possibilities by heart, or type incorrect ones.

I realize that changing all the 0/1 parameters to [bool] in the popup menu when clicking an object's inlet would probably be a ton of work, but for me, this would have made more sense than [int], which implies a whole range of possible numbers. Just a thought, as the docs explain any questions about them, but then again, the inlet menu is faster.

I can definitely appreciate the fine line treaded in the Help files, they really can't provide explanations and examples of every last thing. Personally I'd rather have more than less, and there's a lot of things I found much later than I would have liked. That said, everything *is* available in the excellent documentation, so it's up to me to find the details. With a program this infinitely flexible there's just no way to anticipate every question.

All this said, a fantastic job incorporating the docs right into the help files, the popup menus on the object inlets, the bubble help, and the Clue Window. These have made patching and learning *much* more efficient and enjoyable in Max 5, and I've seen this make a real difference in the beginner Max class that I'm assisting.

I love the new feature of clicking on an inlet and getting the full list of attributes and messages, and being able to choose one and get a message set up for that parameter.  It would be great if these made more then just message boxes with $1 $2 $3 etc..  I think it could be more useful to have certain messages setup to make pak with floats or ints attached (IE "pak camera 0. 0. 2." or whatever the current value of the attribute is set, possibly even with floats already attached to the appropriate inputs).  Just a thought.

All this said, a fantastic job incorporating the docs right into the help files, the popup menus on the object inlets, the bubble help, and the Clue Window. These have made patching and learning *much* more efficient and enjoyable in Max 5, and I've seen this make a real difference in the beginner Max class that I'm assisting.


sorry for pursuing this very off topic discussion, but i'm not sure how to split it off into another topic...

I just checked out the thesaurus, this is exactly what I was talking about!! I think you guys should add this to the front page of the help, in the top bold list with whats new/compatibility/how the doc works. Even maybe add it with the little drop down that comes up when you click table of contents at the bottom. Also would be nice to have a bookmark feature for your favorite pages in the documentation.

It may be more beneficial to split max/msp/jitter up, but I am not sure if its more useful with them all together.

Something that helped me learn new objects when I first started was the old method of creating objects, where you had the category/object list dropdown when you created an object. Is this still around somewhere in max 5? It was really great to go through the list and just explore. I think the new method is really great for speed and if you know what your looking for, but the old method was fun for exploration.

Gregory Taylor wrote on Thu, 26 February 2009 16:07

I just checked out the thesaurus, this is exactly what I was talking about!! I think you guys should add this to the front page of the help, in the top bold list with whats new/compatibility/how the doc works.  Even maybe add it with the little drop down that comes up when you click table of contents at the bottom.  Also would be nice to have a bookmark feature for your favorite pages in the documentation.

It may be more beneficial to split max/msp/jitter up, but I am not sure if its more useful with them all together.  

Something that helped me learn new objects when I first started was the old method of creating objects, where you had the category/object list dropdown when you created an object.  Is this still around somewhere in max 5?  It was really great to go through the list and just explore.  I think the new method is really great for speed and if you know what your looking for, but the old method was fun for exploration.

Gregory Taylor wrote on Thu, 26 February 2009 16:07...I wish there was a document in the tutorials/reference that showed all the objects and basic definitions of what they do with a link to their help patch and ref doc.

I'm just unpacking the matrix from jit.gl.model and packing it into the mesh. I'm not banging jit.gl.model at all. My fps drops from around 35 with no mesh to around 3.5 with mesh. The only thing I can think of is that jit.gl.model uses a different rendering algorithm that is optimized for wavefront files.

Btw, I actually downloaded your jit.ogre and am excited to start playing with it. I hear realtime animation is quite difficult so I don't know when I'll have the time, though...

I'm just unpacking the matrix from jit.gl.model and packing it into the mesh.  I'm not banging jit.gl.model at all.  My fps drops from around 35 with no mesh to around 3.5 with mesh.  The only thing I can think of is that jit.gl.model uses a different rendering algorithm that is optimized for wavefront files. 

Btw, I actually downloaded your jit.ogre and am excited to start playing with it.  I hear realtime animation is quite difficult so I don't know when I'll have the time, though...

Axiom-Crux wrote on Thu, 26 February 2009 20:39

If you make a new object, before you type into it, click the left side of it (where usually there's the Inspector button, here it looks like an equals sign). On a new blank object it will give the dropdown categories.

Although, I did notice that if I delete jit.gl.model after sending the matrix, the framerate shoots up to 20. It stays there, even if I undo the delete. This makes me think the problem is with jit.gl.model's matrix output, as the now small discrepency could be explained by simple message passing costs. However, the only thing I'm sending jit.gl.model is a loadbang. What's up here?

Although, I did notice that if I delete jit.gl.model after sending the matrix, the framerate shoots up to 20.  It stays there, even if I undo the delete.  This makes me think the problem is with jit.gl.model's matrix output, as the now small discrepency could be explained by simple message passing costs.  However, the only thing I'm sending jit.gl.model is a loadbang.  What's up here?


have u tried @automatic 0? it prevents gl objects from outputting their data every time jit.gl.render is banged. perhaps you only need to send the data once in a while... shooting in the dark, but it's kinda a hard to test without your patch and one of your large model files.

Ok disregard that too, I guess this randomly works and doesn't work sometimes either way... I dont know.. sometimes the = appears and sometimes just the i

oops, disregard the bottom, I guess this only works if you make the object from the pallete and not by hitting N...

_________________________________________

that doesn't work for me.. I hit n to make a new object, and click on the left side which is blank and nothing happens, and if I move the mouse at all the i for inspector comes up for the blank object and I click that and it just takes me to the inspector.

seejayjames wrote on Thu, 26 February 2009 19:55Axiom-Crux wrote on Thu, 26 February 2009 20:39

Maybe it worked differently on windows or something, but it always 

works here. In order to see the = sign, you need to have the 

vertical cursor active - if you start typing, the autocomplete

kicks in, and if you have merely the box selected and aren't 

prepared to enter text, you'd get the "i" box. That's all as it 

should be. If that's not so, then the usual things necessary to 

Maybe it worked differently on windows or something, but it always 
works here. In order to see the = sign, you need to have the 
vertical cursor active - if you start typing, the autocomplete
kicks in, and if you have merely the box selected and aren't 
prepared to enter text, you'd get the "i" box. That's all as it 
should be. If that's not so, then the usual things necessary to 
file a bug report would be in order.


Bingo. Funny how I never quite understood @automatic until I end up pushing my graphics card to the limit. The reason I wanted to send the matrix output to mesh was to distort it by crossfading with jit.noise, which I realize now doesn't work without sending both matrices continuously. Oh well, learned something along the way.

Bingo.  Funny how I never quite understood @automatic until I end up pushing my graphics card to the limit.  The reason I wanted to send the matrix output to mesh was to distort it by crossfading with jit.noise, which I realize now doesn't work without sending both matrices continuously.  Oh well, learned something along the way.


switching jit.gl.model