Thijs Koerselman

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?

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 

jit-gl-lua-docs

Sharp eyes! This stuff definitely needs some more docs. I'll put that on the list. The color module has 5 functions:

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}

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}

for k, v in pairs(color) do
if(type(v) == "table") then
print(k, unpack(v))
end
end


Lovely. Thanks for the quick reply and explanation.

jit.lua was amazing back at 07 :)
hope the comback works well !


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?

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. 

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.

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.


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.

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.


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!

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


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 

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

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


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.

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.

Outputting non-strings doesn't work right now. That's a bug. Thanks for finding it.

This works. How were you doing it before?

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?


    -- print the inlet the message came from

function test()
	-- print the inlet the message came from
	print(this.last_inlet)
end


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?

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.

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.


That's great! Will we see the output bug fixed in 6.0.1? Can't wait to script max in lua!

Yes, the outlet bug is fixed for 6.0.1. Also, there is a ton more jit.gl.lua documentation.

Yes, the outlet bug is fixed for 6.0.1.  Also, there is a ton more jit.gl.lua documentation.


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.

    numParticles = length/particlePlanes

    gl.Hint("LINE_SMOOTH_HINT","DONT_CARE")

        gl.Vertex(xcoord,ycoord,zcoord)

        gl.Vertex(to_xcoord,to_ycoord,to_zcoord)

I'm just downloading Max6.01 so maybe the added docs will answer my queries...

Thanks for the reply Wes, I'm sorry I didn't respond earlier but I think I must have turned off email alerts...  

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. 

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)

	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

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.

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.


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

p.s. the added docs in 6.01 are very useful indeed, thanks.

jit.gl.lua docs