GP crash, how to save window?

GP Extensions Developing GP Extensions
1

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?

2

Maybe use this function?
https://development.gigperformer.com/downloads/gp/beta/SystemFunctionList.html#SaveStringToTextFilefilename%20:%20String%20text%20:%20String

1 Like
3

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

4

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. :wink:

1 Like
5

JUCE has its own logger tools

1 Like
6

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 :-).

7

Good idea, I will look at if I can write DBG info to a file.

8

You don’t use DBG - you use Logger methods

https://docs.juce.com/master/classLogger.html

and in particular the file logger.
https://docs.juce.com/master/classFileLogger.html

You should really review the juce class libaries before you go any further – there is a LOT of functionality available

1 Like
9

Yes, I just found out about those classes :slight_smile: … you just were ahead of me :slight_smile:

10

To use Juce, do I need projucer or is there a sdk that I ‘only’ need?

11

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

1 Like
12

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.

13

Although I think the GP widgets are so beautiful, I’m not sure I would want to (re)create them in JUCE.

14

I don’t use projucer. The way @simon has set up the GP Juce template means that the GitHub Actions automatically do the cross-platform builds.

15

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 :slight_smile:
4 Likes
16

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.

17

Just to facilitate my juce-baby-steps:

The documentation of the api’s I’ll find on Juce’s site, I assume. I.e. when I want to know more about juce::Label("new label", TRANS("Hello Gig Performer From an Extension - JUCE + CMake"))

1 Like