This script base is excellent for demonstrating and testing Large Language Models (LLMs), particularly how they navigate the limitations of GP-Script. It allows you to efficiently achieve your goals through VIBE-coding alongside GP.
The example on GitHub was created entirely by Gemini and subsequently refined by Claude Code. The project is still under development but is architecturally stable.
Holy cow, this is DEEP!!! Will have to check this out when I have time. I uploaded the GPScript guide to Gemini and have used it to generate some pretty cool scripts. Took it a few tries to learn what didn’t work. ChatGPT 4.x did a miserable job compared to Gemini. I’m sure Claude is going to excel at this!
You are absolutely right: Claude Code is significantly more powerful than Gemini and almost always compiles error-free on the first try. But the real game-changer is the workflow: Claude edits all involved files and scriptlets at once. There’s no more need to hunt for specific functions in the GP compiler—you can just copy and paste the entire script.
I’d also like to correct my phrasing regarding the “limitations of GP-Script” from my original post. The fact that GP-Script is restrictive in certain areas is actually its biggest advantage! This strictness ensures that Gig Performer remains extremely performant and guarantees rock-solid reliability with absolutely no audio dropouts on stage.
Thanks to AI, the learning curve of GP-Script essentially doesn’t matter anymore today. It is completely irrelevant how restrictive the syntax is, because we basically don’t even have to look at the code ourselves.
The practical payoff is highly customized rackspaces for our personal keyboard setups. Everyone uses different controllers and plugins live. The AI handles the heavy lifting with the strict compiler, and we just get our finished setup ready for the stage.
GP and AI are a brilliant match. It would only take a few minor tweaks in GP to make the coding workflow even more efficient—for example, through naming conventions and automatically loading the “latest” script version.
Sorry, but the AI is still just making things up, all while asserting its familiarity.
There is absolutely no substitute for self-learning. Otherwise, when the AI gets things wrong (and it will get things wrong, guaranteed), you won’t know what is wrong or how to go about fixing it. Then you’ll have to ask a real person who does actually know the language. They’ll get irked that you’re attempting difficult coding solutions without having a clue what you’re doing, and simply looking for someone to do it for you-- -to which the answer is likely to be, ‘Hire me, or learn it for yourself’—which is what should have happened in the first place, leaving AI out of it entirely.
You make a very good point. It completely makes sense that this specific request failed because AI models aren’t really trained on GP-Script by default.
To work smoothly, they need the right foundation. Once you provide the AI with that context, it can actually write excellent GP-Script. I’m not a programmer myself, yet I’ve generated 15,000 lines of mostly flawless, executable code simply through prompting. What did I do differently?
I just showed the AI where to look. I always provide these references:
This is also exactly why I uploaded my code to GitHub (https://github.com/Abstraktikus/GigPerformer). The more correct code and examples the AI sees, the better and faster it programs.
Regarding my setup: My Genos2 might not be a true stage keyboard. I initially thought it was a bad purchase. But thanks to GP and AI, I can now control all VSTs directly via the keyboard knobs, get automatic controller reassignments mid-song. I now have an arranger and a powerful stage keyboard combined, and I couldn’t be happier.
I totally agree with you that you still have to think carefully about what you want. Sometimes you have to be persistent in your dialogue with the AI until you find the solution—but honestly, that’s usually a lot of fun!
Hello dhj
As a non-programmer, it’s probably dangerous to talk about things you’ve only learned from an AI. But right around line 10,000 of my script, I got curious about what kind of code this actually is. I asked Gemini if it was Pascal, because whenever the compiler failed, Gemini would often point out that it’s ‘similar but different’ to Pascal.
That got me wondering why a musician would even come up with the idea of building a custom compiler in the first place. Gemini explained that strict typing, an event-based framework, the protection of the audio thread, and specific commands are the key factors for success - and that the lack of a garbage collector is exactly what brings that rock-solid stability. It must have been incredibly necessary to get this ‘right’; after all, the developer is a musician too and could have just spent that time making music instead!
In practice, it’s usually the little things that make the AI fail during compilation: var declarations can’t just be dropped in the middle of a function, early returns from loops don’t work, Double variables have to be explicitly declared, parsing failed due to unusual line break handling, and so on.
All of this combined created the impression in my head that I mistakenly called ‘limited’ at first, and then corrected to ‘restrictive.’ I am constantly amazed by what can be achieved just with GP’s scripting capabilities alone. It makes the foundation incredibly brilliant. The AI also repeatedly highlighted the excellent CPU load distribution.
All of this leads me to say that GP and AI are simply a perfect match. It would be impossible to build such a solid foundation just through ‘vibe coding’. Trying to recreate something like GP with vibe coding is completely out of the question for that exact reason. GP is sensationally structured and provides a strict framework that keeps you safely within the guardrails.
Well, assuming you actually stick to the principles (I have to admit, in one or two places, I just couldn’t resist taking a bite of the forbidden apple :-))
The musician who did this spent much of his career developing programming languages for various purposes
Correct - syntactically and philosophically, it was influenced by Pascal, a language originally developed for teaching programming, consequently much easier to learn than languages like C.
However, one critical difference is the notion of an explicit callback to make it clear what functions the programmer is called vs. what functions (callbacks) are invoked by the system (Gig Performer). Most well-known languages (C, C++, Java, Javascript, etc) do not make that differentiation, thereby requiring the program to setup such things.
You’re probably talking about the use of strong types, preventing you from certain kinds of bugs such as passing a string when an integer is required, or only allowing calls that manipulate widgets to be invoked on handles that are defined as widget types.
