Viewing Rack Extension Logs from Reason ?

[rcbuse]

I'm testing a new RE.
Running Windows 10.
A custom display is busted in Reason 11.3.9d22. I click on the display and BAM:
"An error has occurered in device '<redacted>'. It has been disabled. You can still save your document."

There are multiple custom displays, and only this one throws this error.
The display works fine while running under Recon 11.2.1.d10, which makes this frustrating...

I'm on my 12th server build trying to narrow it down.

When I upload my universal build to the servers, I select 'Testing' for the testing build. Build is Successful. I download the Testing build to Reason and run it, error happens. I can't seem to find any of the RE logging from display.lua. Does anyone know what the point of the 'Testing' vs 'Deployment' versions are if testing doesn't produce logging in Reason ? I can't find any feedback on the problem.

"C:\Users\rcb\Documents\Propellerhead Logs\Rack Extension Logs" only has logs generated from Recon.

Anyone dealt with this before?

panda.jpeg (29.19 KiB) Viewed 1641 times

[orthodox]

Debugging LUA in an RE seems nearly impossible to me.
I use old techniques, like visually checking the code line by line, or disabling/commenting out some parts in a dichotomy which eventually converges to the bug.

[pongasoft]

I am curious if you tried on a Mac as well. The reason why I am saying that is because on the Mac I would simply launch Reason on the command line and then the output would be there as well. That being said I do not know if that works with custom display print statements...

If you don't have access to a Mac I can give it a try if you want me to test it out.

Yan

[rcbuse]

BAM!
Found it. I have a huge global constant table in display.lua, and then I was passing part of that into custom_data. There must be something going in internally, like copying it and hitting a limit. Recon was cool with it, Reason was not.

Bad:

Code: Select all

display.lua:

MY_BIG_ASS_TABLE = {
....  600 or so lines of nested tables
}

later in a gesture handler:
....
    return { 
      custom_data = { info=MY_BIG_ASS_TABLE[id] }, 
      handlers = { on_tap=thing_on_tap }
      }
 .... 

[orthodox]

BAM!
Found it. I have a huge global constant table in display.lua, and then I was passing part of that into custom_data. There must be something going in internally, like copying it and hitting a limit. Recon was cool with it, Reason was not.

Bad:

Code: Select all

display.lua:

MY_BIG_ASS_TABLE = {
....  600 or so lines of nested tables
}

later in a gesture handler:
....
    return { 
      custom_data = { info=MY_BIG_ASS_TABLE[id] }, 
      handlers = { on_tap=thing_on_tap }
      }
 .... 

You mean, it's hitting limit only as a return value? If you return just "id" (the table index, since "TABLE" is accessible globally), the problem disappears?

[rcbuse]

You mean, it's hitting limit only as a return value? If you return just "id" (the table index, since "TABLE" is accessible globally), the problem disappears?

Thats right. I converted everything over to use id instead of the table reference and it works. I would have suspected an id and a table reference to be basically the same, but I guess not.

[orthodox]

I would have suspected an id and a table reference to be basically the same, but I guess not.

It should be in theory, at least until you change a single item, in that case it creates a copy.
EDIT: there is another possible story, that the global table chunk reference goes out of dynamic scope if used as a return value. If the global context is re-created or if there are multiple interpreter engines.

Thanks for sharing, a useful observation.