When I made some stupid (or less stupid) mistake, GP crashes (which is normal, since it’s my own fault, programming something incorrectly).
To be able to get some diagnostics information, I print lines to the GP Script logger window. However that also closes immediately. Is there a way to store it somewhere? (or should I make my own file I/O solution? Not sure if that will give problems that the file is not properly closed during a hangup, let alone the performance it costs.
Is there some way to keep logging texts after a crash?
That might be very costly (as the log file keeps growing, assuming I don’t know in all cases when it crashes). Besides, I’m using extensions now (I could of course use the Juce file methods to write a file, just wondering if there would be an easy way to ‘freeze’ the GP Script logging window (even when GP crashes), or when there is some way of catching the error, to save the content to a file, or an option to save the GP script logger ALWAYS to a file (or when a checkbox in the window or settings is selected).
Well… i wouldn’t worry too much about the file size.
A text file of (say) a few 100kB can store a lot of information, and this is far below of what i would consider a critical file size. But maybe the output to a file might slow down the whole processes a lot.
If i was in your place i just would give it a try - either it works or not… easy thing.
100 KB shouldn’t be a problem, but since that function does not add to a file but overwrites it I would have to save it for every (added) line again … anyway, I’m not using GP Script, so I will check into what Juce can offer :-).
I just see I reacted to you instead of the generic post (just see your post).
I am using two projects: one is the real GP extension, where the base is the JUCE example from the SDK on github.
And for the test project, I used projucer which creates a VS2022 project which I can use for easy debugging (with some very simply mocked GP API/functions classes).
The Projucer is very convenient as it generates all the project files for the various platforms. It also handles graphics and font resources for you and, although sadly discouraged (I’ve no idea why), it has a GUI builder tool to let you lay out visual components.
Just a bit more context in case you want to know more:
We have a JUCE template based on CMake as well as one based on Projucer
You get some advantages with CMake:
Automatic builds for all platforms in GitHub Actions
You specify the JUCE version to use inside a text file of the repo the same way as one does in the regular template for the GP SDK version. For Projucer, the GP SDK is a git submodule (which has some usability flaws) and the JUCE version is bound to the Projucer version on your computer (which you need to track separately).
You get some advantages with Projucer:
A GUI for adding JUCE modules (as opposed to writing them in a text file) for better discoverability
The GUI designer (which you can use even with the CMake-based build system, but if your project is in Projucer anyway, it’s easier to set up)
Support for integrating with your favorite IDE is supported by both solutions. Both support Visual Studio and Xcode (and Makefiles, I think at least - not sure for Projucer). You will probably get a bit more choice with CMake, since that is one of the most popular build systems for C/C++ projects in general whereas Projucer is obviously only a thing for users of JUCE
Thanks for this useful information … Probably for now, I have a working version, next time I will check how hard it is to ‘copy’ a new (beta) SDK over the old one, but later I should think about what is the best way as I think my project setup can already be improved, especially regarding new updates for Juce.