Editor Environment Question

Renoise Tool Development
1

Okay I’m working on a script to do some sysex stuff, but when I change the function in the editor I can’t seem to get it to change in the terminal (running functions via the terminal to see what happens)… Is this a thing to avoid? Should I get to the gui stuff ASAP? Because it seems I can’t overwrite functions (or only a couple of times before they freeze in memory). Here’s the code I’m working on, maybe someone can spot a mistake?

[luabox]
MIDICHANNEL = 0x7F – ALL

MIDIIN = 4 – nio 2|4
MIDIOUT = 5 – nio 2|4

sysxDeviceInquiry = {0xF0,0x7E,MIDICHANNEL,0x06,0x01,0xF7}
sysxEvoSig = {0xF0,0x7E,MIDICHANNEL,0x06,0x02,0x01,0x20,0x00,0x00,0x00,0x00,0x03,0x04,0x03,0xF7}
sysxReqPrgDump = {0xF0,0x01,0x20,0x01,0x05,0x00,0x00,0xF7}

ClockDivide = { }

function testEvo()

local inputs = renoise.Midi.available_input_devices()
local outputs = renoise.Midi.available_output_devices()

local midi_input = nil
local midi_output = nil

if not table.is_empty(inputs) then
local device_name = inputs[MIDIIN]
local function midi_callback(message)
local n = 1
while (message[n]) do
if(message[n] == sysxEvoSig[n]) then print(“DSI Evolver sig”, n, message[n]) end
n = n + 1
end
end
midi_input = renoise.Midi.create_input_device(device_name, midi_callback, midi_callback)
end

if not table.is_empty(outputs) then
local device_name = outputs[MIDIOUT]
midi_output = renoise.Midi.create_output_device(device_name)
end

print(“sysx Device Inquiry”)
midi_output:send(sysxDeviceInquiry)

– print(“sysxReqPrgDump”)
– midi_output:send(sysxReqPrgDump)

print(“Close”)
midi_output:close()

print(“All Done”)

end
[/luabox]

the code works, but if I try and change it (by pressing execute, or reload tools), nothing changes. I have to close the editor and restart it.

2

this! maybe there is something else wrong, to be honest I didn’t even look at your code much (because I never touched MIDI), but I still would simply package everything you have into a tool, just so what you have above gets called when you hit the menu entry = no need for a GUI, you can still use print() for now, I just don’t think you will get far by executing stuff in the terminal.

I might be wrong, but until you get better advice I’d see if that helps.

3

frl - I agree; I reckon you should stick it in the non-GUI Example tool (which demonstrates menu entries and alert dialogues). That’s how I did all my sysex testing and simply saving in the editor will clean the tool and reload.

4

alright, will do this then… So I can assume that every tool is a fresh spawn of a lua environment? Or is it loaded localy on top of the environment that the terminal is running on? Just wondering whats going on.

5

Also I have noticed that I can make renoise and my hardware choke pretty fast on sysex data.

If I change the midi callback to ‘rprint(message)’ it just stops reporting pretty soon when I’m turning some knobs.

Also, when I send two sysex calls to the hardware in quick succession, stuff gets intertwined and messed up. How can I make it come out right? Is it a good idea to use a callback at all in this sort of situations? Can I set up some sort of pipe?

6

Re environment:

The scripting console has its own environment (Lua interpreter), just like each XRNX tool. This also means you can not access any globals from a XRNX to any other running XRNX, and can also not access any XRNX globals from within the console. The only thing that’s shared is the “print” output, which is dumped no matter where it comes from into the console.

The consoles environment gets recreated every time you start the console. You can do so to flush, reset it explicitly.

When doing stuff with callbacks, notifiers and so on, its highly recommended to write a simply XRNX tool for this. You can not really rely on when an object in Lua dies, gets garbage collected. Or lets say, you should not…

7

I don’t understand that last paragraph, you mean write something as simple as possible in the space of the callback and then put the more programming in other functions? If I want something like bi-directional sysex is that even practical/possible? Any clues?

8

Taktik probably means that notifiers should not be attached to functions that may disappear as soon as you close your tool (garbage collection). But it indeed looks like Taktik forgot an important word in the last paragraph.

9

Ah ok, so I shouldn’t make the callback functions local then, right? Thanks.

10

Well, not necessailry, but not if you want to approach these functions on a more global level.
It’s best to embed the habit to remove deeper nested level notifiers as soon as you leave a specific function level that is not the nearest nest-level, this way you also find out quicker if you need a notifier on a more global level and thus forces you to set the notifier elsewhere without having to bump into it through trial and error.

11

I’ll give it a try, didn’t put much thought into it yet - just trying some stuff out.