Integrating Lua into a patcher

bump

I'm interested in this too. I've done some testing, which seems to indicate:

• jit.gl.lua seems to run in high priority when receiving high priority events

• Outlets seems to be sent immediately and then subsequent Lua code is run

I'd love confirmation of this. Here's the patch I used for testing:

Because the Lua and JS code aren't copied to the clipboard, here are those files:

luatesting.lua
this.inlets = 1
this.outlets = 1
function dotest()
    outlet(0,123)
    print("Sent output")
end

jstesting.js
this.inlets = 1;
this.outlets = 1;
function bang() {
    outlet(0,123);
    post("Sent output\n");
}

Oh, and I meant to reply to OP to say:

• To output something from [jit.gl.lua] use the "outlet" function like the above code.

• To receive input, define a function named the message you want like "dotest" above. You can also define "int" or "float" functions to handle those types of inputs.

• For some reason, "bang" as a function name didn't handle bangs input to the Lua object. I had to send "call bang" as a message. You don't need to use "call dotest" BTW, sending a message of just "dotest" works. Not sure why it doesn't work for bang.

• This is all analogous to the [js] object.

Oh man, thank you so much!

I'll do a little testing and get back soon, but the main reason I wanted to try Lua out was to see if it performs better than the JS object as Lua is integrated more closely with C and I often run into performance issues when I pass a lot of messages over the JS-MAX barrier.

But anyway, confirmed - patch works perfectly, and thanks for the explanatory comments in there - finally a working Lua patch on the forums!

EDIT: I actually get different outputs from the Lua object based on which defer setting is used - on my machine the outputs from the JS and Lua objects are identical in nature based on which [defer] is used. What does this mean exactly?

EDIT: since it still comes out the [print R] first after going through [defer], does this mean it comes out in the low priority?

Oh yes - I wanted to ask about the [delay 0] object in there- I've heard about that before. Could you please explain why this promotes it to the high priority, and I guess UI triggered events are defaulted to low priority? This seems counter-intuitive to me, but maybe its to prevent disruption of the audio processing?

You're welcome. Regarding [delay 0], I saw this in the excellent event priority article:

There may also be instances when you want to move a low priority event to a high priority event, or make use of the scheduler for setting a specific time at which an event should execute. This can be accomplished by using the delay or pipe objects. Note that only the high priority scheduler maintains timing information, so if you wish to schedule a low priority event to execute at a specific time in the future, you will need to use the delay or pipe objects connected to the defer or deferlow objects.

I actually get different outputs from the Lua object based on which defer setting is used - on my machine the outputs from the JS and Lua objects are identical in nature based on which [defer] is used. What does this mean exactly?

So, this is pretty tricky to explain. My thinking is that a high-priority event going into [defer] and [deferlow] should be treated identically. But a low-priority event going into [defer] executes immediately while a low-priority event going into [deferlow] will be placed at the end of the low-priority queue.

On my machine (Mac), I see the same result for [js] with [defer] and [js] with [deferlow] BUT [jit.gl.lua] does something different depending on whether I use [defer] or [deferlow]. To me this indicates that Lua can output high-priority events. It may be that having "Overdrive" on is required. I believe you need that to have separate high- and low-priority queues.

You're right, overdrive was off. I now see the difference in behavior between the two objects. Thank you!

I'm still curious about performance though, so I'll post a testing patch soon