I know that PNS is not built with any debugging support. I am trying to find a better way to debug stuff, especially midi processing.
Do you think it should be possible to download the Angelscript SDK and build one of the examples there which would maybe be a command line program that can basically load an angel script and run it...such that I could then attach to that command line program with a debugger?
In addition to that, I realize that in order to debug actual PNS scripts I would have to write a number of support functions to mimic what PNS normally is doing, calling callbacks, simulating midi, simulating parameters and default GUI, etc. But in theory I could then create test cases that can be ran from the command line, for one thing, checking for erroneous results..but also potentially attach to it with a visual debugger and step through the code. In this situation I don't need it to run in real time, need to be able to step through the code to see WTF is going on.
Just thinking out loud here. Or any other more advanced ideas for debugging PNS scripts beyond DEBUG tracing to log files?
PNS Debugging
-
Blue Cat Audio Blue Cat Audio https://www.kvraudio.com/forum/memberlist.php?mode=viewprofile&u=39981
- KVRAF
- 6349 posts since 8 Sep, 2004 from Paris (France)
So far tracing is the only way to go, as far as I know. For the DSP side anyway, it is usually quite difficult to actually debug real time processing, so it is usually easier to print debug information instead.
We may add direct angelscript debugging capabilities in the future though.
We may add direct angelscript debugging capabilities in the future though.
-
- KVRist
- 316 posts since 28 May, 2011
I was trying to debug AngelScript perfomance using system calls and external .exe returning time in microseconds.
So a few hundred iterations and a couple system calls, and I could get and average time the algo takes - minus the time system calls take.
Not very precise, but not bad overall (better than nothing
In general I would just jump to C++ directly with all it's debugging possibilities and speed.
So a few hundred iterations and a couple system calls, and I could get and average time the algo takes - minus the time system calls take.
Not very precise, but not bad overall (better than nothing
In general I would just jump to C++ directly with all it's debugging possibilities and speed.
-
- KVRAF
- Topic Starter
- 1985 posts since 14 Mar, 2006
What I can say is that when I actually *DO* need to step through code, I don't care about the real time performance. I just want to step through it and inspect various variables as I go...sometimes to make sure the program is behaving the way I expected it to in terms of program flow. It doesn't matter whether I hear the audio or midi while doing that. It matters that I can stop real time processing and step through the program to make sure I haven't overlooked something in my code.
With LogicPro Scripter, I have worked around the lack of a debugger, by setting up a separate framework outside of LogicPro entirely. Scripter is very similar as PNS. It has an API of functions, and a callback mechanism where it calls back to script functions that we provide.
So my little external debugging system basically has a number of Javascript functions to replace whatever Logic normally provides...with stubbed out functions that return the same data I would expect if it were inside LogicPro.
And I have a little test engine that basically can read an input file with midi event data, emulate a running sequencer over time, with calls to the processBlock callback repeatedly, representing a length of time, then spit out the resulting midi data.
It actually doesn't run in realtime, it goes as fast as it can, like a non-real-time bounce. But the whole thing runs using the generic nodejs command line javascript interpreter. And the main advantage is I can attach to it with a debugger and step through the code, inspect the variables, etc.. and I can inspect the output file to see if it did what I thought it should do in terms of the data. It also allows me to setup little unit tests that I can run...and I can diff the output against expected results. If the output changes later on after I change something in the script, the diff will catch it and let me know.
I haven't done it yet, but I can also add to the input data file, some stuff about GUI interactions happening at flagged timestamps, to emulate the LogicPro Scripter GUI being manipulated by the user, so that those kinds of things can be tested as well. And stepped through.
So anyway, I will probably try to set something like this up for PNS also, but will be a lot of work to do, but still I don't see any other way, some of the PNS scripts I want to do are complex enough that I will need to be able to do this.
What would be really fantastic would be if BCA provided "something" similar.. Perhaps built into the standalone version in some way... such that we could attach to it from an angel script debugger and step through the script code. Albeit without actually hearing any midi or audio. Just at least be able to "break" into the Script and then step through and inspect variables or just follow along with the code to make sure its flowing through the code the way we expected it to, etc.
With LogicPro Scripter, I have worked around the lack of a debugger, by setting up a separate framework outside of LogicPro entirely. Scripter is very similar as PNS. It has an API of functions, and a callback mechanism where it calls back to script functions that we provide.
So my little external debugging system basically has a number of Javascript functions to replace whatever Logic normally provides...with stubbed out functions that return the same data I would expect if it were inside LogicPro.
And I have a little test engine that basically can read an input file with midi event data, emulate a running sequencer over time, with calls to the processBlock callback repeatedly, representing a length of time, then spit out the resulting midi data.
It actually doesn't run in realtime, it goes as fast as it can, like a non-real-time bounce. But the whole thing runs using the generic nodejs command line javascript interpreter. And the main advantage is I can attach to it with a debugger and step through the code, inspect the variables, etc.. and I can inspect the output file to see if it did what I thought it should do in terms of the data. It also allows me to setup little unit tests that I can run...and I can diff the output against expected results. If the output changes later on after I change something in the script, the diff will catch it and let me know.
I haven't done it yet, but I can also add to the input data file, some stuff about GUI interactions happening at flagged timestamps, to emulate the LogicPro Scripter GUI being manipulated by the user, so that those kinds of things can be tested as well. And stepped through.
So anyway, I will probably try to set something like this up for PNS also, but will be a lot of work to do, but still I don't see any other way, some of the PNS scripts I want to do are complex enough that I will need to be able to do this.
What would be really fantastic would be if BCA provided "something" similar.. Perhaps built into the standalone version in some way... such that we could attach to it from an angel script debugger and step through the script code. Albeit without actually hearing any midi or audio. Just at least be able to "break" into the Script and then step through and inspect variables or just follow along with the code to make sure its flowing through the code the way we expected it to, etc.
MacPro 5,1 12core x 3.46ghz-96gb MacOS 12.2 (opencore), X32+AES16e-50