Viewing Rack Extension Logs from Reason ?

This forum is for developers of Rack Extensions to discuss the RE SDK, share code, and offer tips to other developers.
User avatar
rcbuse
RE Developer
Posts: 949
Joined: 16 Jan 2015
Location: SR388

Post 24 May 2021

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
You do not have the required permissions to view the files attached to this post.
Last edited by rcbuse on 24 May 2021, edited 2 times in total.

User avatar
orthodox
RE Developer
Posts: 1554
Joined: 22 Jan 2015

Post 24 May 2021

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.
Active Reason+ subscriber with (hopefully) early R12 access
Reason 11 Suite gathering dust on the shelf

User avatar
pongasoft
RE Developer
Posts: 308
Joined: 21 Apr 2016
Location: Las Vegas

Post 24 May 2021

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

User avatar
rcbuse
RE Developer
Posts: 949
Joined: 16 Jan 2015
Location: SR388

Post 24 May 2021

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

User avatar
orthodox
RE Developer
Posts: 1554
Joined: 22 Jan 2015

Post 25 May 2021

rcbuse wrote:
24 May 2021
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?
Active Reason+ subscriber with (hopefully) early R12 access
Reason 11 Suite gathering dust on the shelf

User avatar
rcbuse
RE Developer
Posts: 949
Joined: 16 Jan 2015
Location: SR388

Post 25 May 2021

orthodox wrote:
25 May 2021


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.

User avatar
orthodox
RE Developer
Posts: 1554
Joined: 22 Jan 2015

Post 25 May 2021

rcbuse wrote:
25 May 2021
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.
Active Reason+ subscriber with (hopefully) early R12 access
Reason 11 Suite gathering dust on the shelf

  • Information
  • Who is online

    Users browsing this forum: CommonCrawl [Bot] and 1 guest