jit.gl.lua docs

    Oct 28 2011 | 8:48 pm
    Big thanks to Wes for jit.gl.lua and making it part of standard Max! From now it will be less obscure and more people will start loving Lua for Jitter stuff :D
    The new editor for Lua and JS with syntax highlighting is wonderful.
    I was looking at the examples and noticed the use of the color global. I coudn't find any documentation on this or other globals. Is it on the way or did I miss it?

    • Oct 28 2011 | 9:07 pm
      Sharp eyes! This stuff definitely needs some more docs. I'll put that on the list. The color module has 5 functions:
      hue(hslcolor, amt) - shift the hue saturation(hslcolor, scale) - scale the saturation lighten(hslcolor, scale) - scale the luminance rgb2hsl - convert between, alpha is preserved if present hsl2rgb - convert between, alpha is preserved if present
      The rest of the values in the color table are predefined color values from the web specs. For example:
      color.olive = {0.501961, 0.501961, 0.000000} color.orchid = {0.854902, 0.439216, 0.839216}
      To see them all, do:
      for k, v in pairs(color) do if(type(v) == "table") then print(k, unpack(v)) end end
    • Oct 28 2011 | 9:19 pm
      Lovely. Thanks for the quick reply and explanation.
    • Oct 28 2011 | 11:04 pm
      jit.lua was amazing back at 07 :) hope the comback works well !
    • Oct 29 2011 | 8:32 pm
      A vaguely related question about jit.gl.lua.
      In the past I've tried to abuse jit.gl.lua for scheduler calculations and not necessarily drawing anything. This always got me into trouble leading to vague crashes when the patches / cpu load grew bigger.
      Would you think that jit.gl.lua could now be used for these kinds of things, or am I better off using javascript?
      For anything not jit.gl I think it would be really cool to have a plain [lua] object in Max, including the vector math bindings (and other useful libraries) of jit.gl.lua. I've recently worked on a project which involved vector math for sound calculations. I was forced to do this in a C external where otherwise Lua would've been perfect.
      It's just a thought, but if [lua] would essentially be a trimmed down version of what you already developed for [jit.gl.lua] it might not even be that much work maybe? I think such an object would also help to spread the love:)
      When the source of jit.gl.lua was public I once planned to make this object myself, but I fear I don't have enough knowledge en time to do this anymore. I'm already struggling to get back into serious Max patching in general.
      BTW I read the Max javascript engine/version was improved with version 6. That's great. What's the current version and JS implementation?
      Cheers, Thijs
    • Oct 29 2011 | 9:00 pm
      if you set jit.gl.lua @enable 0, it should be equivalent to a [lua] object. If you have problems using it this way, let me know.
    • Oct 29 2011 | 9:22 pm
      Ok if there's no reason jit.gl.lua shouldn't be able to handle the scheduler I'll try it again next time.
      Still I think a non gl version of the object would help make people aware that it could be an alternative to JS and don't get them confused with the gl attributes and such.
    • Oct 29 2011 | 9:23 pm
      agreed. I'll put in a feature request.
    • Oct 29 2011 | 9:59 pm
      Great thanks!
    • Oct 30 2011 | 3:27 pm
      about the jit.gl.lua documentation, I can't find any in the Max6 distribution, besides the object's help file... for now, I am referring to the beta7 docs, but something like the awesome java-doc folder would be more than welcome! aa
    • Oct 30 2011 | 9:21 pm
      I also want to use jit.gl.lua as a [js]-like object. How can I send values other than strings to outlets? Something like outlet(0, 0.7) seems to just send empty strings out. Also how can I tell which inlet gets the input? There is no inlet variable like in [js].
    • Nov 03 2011 | 12:19 pm
      Could somebody tell me if the way that jit.gl.lua handles incoming Jitter Matrices has changed? I'm struggling to get old patches containing jit.gl.lua scripts in them to run in Max6, and I can't find any relevant documentation.
      Many thanks
    • Nov 03 2011 | 4:39 pm
      One of the bug difference between previous iterations of jit.gl.lua and the Max6 one is that function call messages no longer need to be prefaced by "call". If they are, it will be stripped away, so there is no change in functionality, but it's no longer necessary.
      @larme Outputting non-strings doesn't work right now. That's a bug. Thanks for finding it.
      @tom function jit_matrix(name) print("jit_matrix", name) end
      This works. How were you doing it before?
    • Nov 03 2011 | 4:56 pm
      For getting the last inlet used:
      -- set the # of inlets this.inlets = 2
      function test() -- print the inlet the message came from print(this.last_inlet) end
    • Nov 03 2011 | 9:21 pm
      My macbook was sent to repaired so I can't test it on Max6 myself. But what if I send two different float numbers to two different inlets of a jit.gl.lua object at the same time? I know that one inlet will get the message earlier depending on the position of the inlets. When this message evokes the function float_msg(), is it guaranteed that this.last_inlet will not be overwritten by the fact that the other float number reaches the other inlet?
    • Nov 03 2011 | 9:53 pm
      this.inlets = 2
      function float(v) print(this.last_inlet, v) end
      1 3.4000000953674 // set to the second inlet 0 1.2000000476837 // sent to the first inlet
      using an unpack with the two outlets connected to both the inlets. Whenever a messages is received, it is immediately used to call into the Lua script so the last_inlet value will be correct.
    • Nov 04 2011 | 6:06 pm
      That's great! Will we see the output bug fixed in 6.0.1? Can't wait to script max in lua!
    • Nov 08 2011 | 8:31 pm
      Yes, the outlet bug is fixed for 6.0.1. Also, there is a ton more jit.gl.lua documentation.
    • Nov 12 2011 | 11:19 am
      Thanks for the reply Wes, I'm sorry I didn't respond earlier but I think I must have turned off email alerts...
      Anyway, this is the problem I'm having with Jitter Matrices:
      I have a lua script that I'm using to draw lines between points coming out of cv.jit.centroids and a predefined point in 3d space. This matrix is 3 planes float32, with planes representing x,y and z coordinated of each point.
      To draw the lines between each point, I was using the following code (which seemed to be much faster than using multiple getcell commands). Actually, this code is abbreviated from the real thing for clarity. I'm getting errors with the lines 'currentPos = mat[0]', which previously gave me all the data in the incoming matrix in a long one-dimensional table with very quick performance.
      local mat = jit.matrix() local particlePlanes = 3 local toxcoord = 0. local toycoord = 0. local tozcoord = 0.
      function jit_matrix(name) mat:frommatrix(name) end
      function draw() currentPos = mat[0] length = table.getn(currentPos) numParticles = length/particlePlanes
      gl.Enable("BLEND") gl.Enable("LINE_SMOOTH") gl.Hint("LINE_SMOOTH_HINT","DONT_CARE") gl.Color({1.,.4,0.,0.5}); gl.BlendFunc("SRC_ALPHA","ONE") gl.LineWidth(1.5)
      i=1 f = 1 row = 1
      while f < numParticles do xcoord = currentPos[i] ycoord = currentPos[i+1] zcoord = currentPos[i+2] gl.Begin("LINES") gl.Vertex(xcoord,ycoord,zcoord) gl.Vertex(to_xcoord,to_ycoord,to_zcoord) gl.End() i = i + particlePlanes end end
      I'm just downloading Max6.01 so maybe the added docs will answer my queries...
      Thanks again
    • Nov 12 2011 | 6:20 pm
      Hi Tom, This is something I've been debating with myself for a while now. In the jit.gl.lua betas, matrix[0] would return a list of all the cells in a column. If used unwisely on a large matrix, performance would be terrible. Indexing a matrix like matrix[0][0] would incur huge calculations for a 320x240 matrix, so I decided in Max6 to remove that feature, which is why you're getting errors. For small matrices, you're right that it is more efficient, particularly in the case of a 1D matrix where you can then access all of the data from the resulting Lua table. I'll add this back in for 6.0.2 with documentation describing proper use cases.
    • Nov 12 2011 | 7:38 pm
      Thanks Wesley, that would be very useful!
      In the meantime, I've written a little patcher with a jit.iter and few zls which spits the matrix out into the same format of list that matrix[0] was returning in the beta versions, and then using a list input into jit.gl.lua in place of the matrix input. It seems to work pretty well for my applications, although I don't know what the performance implications would be for larger matrices.
      Thanks for the super quick response,
    • Nov 12 2011 | 7:39 pm
      p.s. the added docs in 6.01 are very useful indeed, thanks.