yoyoyoo reasoneers
Maybe someone who writes Remotes Scripts as well knows a solution to debug .lua-scripts while used inside the reason runtime. As you might now, the function remote.trace() that only logs something to the log window of the codec test tool, is really not useful if you're writing rack device specific scripts.
What i did so far is just raising errors of variables where i needed to know whats going on. this way it is possible to 'watch' variables while the script runs within reason, but its a really hacky and annoying solution.
Yesterday i tried to implement a custom log function that prints something to an external console, but the reason remote environment seems to be allergic to any 'import' or 'require' call, which i needed to import some packages that could call some other processes than reason.
now i'm sad and i run out of ideas. has someone some tipps or ideas or even a solution to this?
cheers
Debugging Remote Scripts
- Nocturn789
- Posts: 67
- Joined: 01 Jun 2015
v10.4
Windows 10 Pro x64, Intel i7-7700K, 32GB RAM, Scarlett 4i4 3rd Gen
Behringer X-Touch, Nektar Impakt LX61, Livid DS1, Novation LaunchPad Mini
Pioneer DJM-900NXS2, 2x Pioneer CDJ-2000NXS2, Korg Kaoss Pad 3
Windows 10 Pro x64, Intel i7-7700K, 32GB RAM, Scarlett 4i4 3rd Gen
Behringer X-Touch, Nektar Impakt LX61, Livid DS1, Novation LaunchPad Mini
Pioneer DJM-900NXS2, 2x Pioneer CDJ-2000NXS2, Korg Kaoss Pad 3
I have a couple of tips and a starter script that has some debugging routines. I'll post it in a bit if I can find it.
If you ain't hip to the rare Housequake, shut up already.
Damn.
Damn.
I do have a couple of versions of my starter/example script. But here's the main debugging functions from it. If this is useful to you, say thanks.
First, if you are using the remote SDK debugger (forget what it's called) then you have access to remote.trace(), so use this:
If you are doing straight up debugging in Reason, you should use this function and call it whenever you need it.
I might as well throw this function in as well. I'm not sure if it's been fixed (by Reason using a later version of Lua) but here's a function for Modulo.
First, if you are using the remote SDK debugger (forget what it's called) then you have access to remote.trace(), so use this:
Code: Select all
--+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-- For showing tables!
-- remote.trace contents of `tbl`, with indentation.
-- `indent` sets the initial level of indentation.
-- https://gist.github.com/ripter/4270799
function tprint (tbl, indent)
if not indent then indent = 0 end
for k, v in pairs(tbl) do
formatting = string.rep(" ", indent) .. k .. ": "
if type(v) == "table" then
remote.trace(formatting)
tprint(v, indent+1)
elseif type(v) == 'boolean' then
remote.trace(formatting .. tostring(v))
else
remote.trace(formatting .. tostring(v) ..'\n')
end
end
end
--+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Code: Select all
--+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-- Usage: error(tableprint(tbl)) returns contents of `tbl`, with indentation.
-- You can then copy the error that reason throws into the clipboard
-- and then restart the codec in Reason's preferences.
-- Also you can create tables on the fly to send it, like:
-- error({var1,var2,table1,table2})
function tableprint (tbl, indent)
local output = ''
if not indent then indent = 0 end
if type(tbl) == "table" then
for k, v in pairs(tbl) do
formatting = string.rep(" ", indent) .. k .. ": "
if type(v) == "table" then
output = output..'\n'..formatting ..'\n'..
tableprint(v, indent+1)
elseif type(v) == 'boolean' then
output=output..formatting .. tostring(v)
else
output=output..formatting .. tostring(v) ..'\n'
end
end
end
return output
end
-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Code: Select all
-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-- Thanks to pete@lividinstruments.com
--for some Reason (pun intended) we need to define a modulo function. just using the % operator was throwing errors :(
function modulo(a,b)
local mo = a-math.floor(a/b)*b
return mo
end
-- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
If you ain't hip to the rare Housequake, shut up already.
Damn.
Damn.
- Nocturn789
- Posts: 67
- Joined: 01 Jun 2015
Hey, thank you. Didn't expect a response that quickly.
So the thing is, i debug straight up in reason because the debugger tool of the sdk is not really useful for testing stuff going on if for example the rack device focus changes.
I mean, that is just one example of a shitload of stuff which are not possible to test with it, so direct debugging in Reason it is.
But yeah anyway, is see you 'debug' as well by raising errors. So it is probably the only 'logging' possibility, but thanks for tableprint(), this is really handy.
And no, the modulo operator is still not fixed xP i use a custom function as well
Again, thank you very much, I will check out your table formatter when i'm back home
Cheers
v10.4
Windows 10 Pro x64, Intel i7-7700K, 32GB RAM, Scarlett 4i4 3rd Gen
Behringer X-Touch, Nektar Impakt LX61, Livid DS1, Novation LaunchPad Mini
Pioneer DJM-900NXS2, 2x Pioneer CDJ-2000NXS2, Korg Kaoss Pad 3
Windows 10 Pro x64, Intel i7-7700K, 32GB RAM, Scarlett 4i4 3rd Gen
Behringer X-Touch, Nektar Impakt LX61, Livid DS1, Novation LaunchPad Mini
Pioneer DJM-900NXS2, 2x Pioneer CDJ-2000NXS2, Korg Kaoss Pad 3
- Raveshaper
- Posts: 1089
- Joined: 16 Jan 2015
Raising errors is the only way to log. The modulo operator throws an exception in reason so it can only be emulated with a custom function instead.
Enhanced by DataBridge v5
-
- Information
-
Who is online
Users browsing this forum: No registered users and 6 guests