I’ve recently been experimenting with vibe coding for plugins, and came up with this physical modelling synth. There’s a VST release. The whole thing was written, documented and published by Codex/ChatGPT. I’m new to this stuff so would be interested in any comments/feedback if anyone gets round to trying it.
3 Likes
ohhh no macosx ;-( …
Looks really interesting!
It apparently uses Juce. Asking the Coding Agent to also make a macOS version should be in the cards! 
Edit: Asked the agent to evaluate the feasibility of a port, might be easier to do this on a Mac where it can also be tested. Can provide a pull request and some test binaries when it works (and it is desired by BJG145).
Here a macOS build of the synth: Edit: Please use the notarized build below.
This contains a VST3 and an AU plugin. Tested in GigPerformer - works!
And here the changes (it also contains a small fix for an editor construction crash that happened while running the tests): GitHub - NothanUmber/blazar: Procedural physical modelling synthesizer combining MATTER, FIELD, PARTICLES and PLASMA. Windows x64 VST3. · GitHub
@BJG145 please tell me whether I should start a pull request.
Thanks, very cool project!
3 Likes
…wow! Thanks NothanUmber!
Sure thing, not sure what that means but I’ll look it up. 
Added a few more things:
- a GitHub workflow to build the windows and macOS versions and run the unit tests. This ensures that all versions still build (so you see whether you e.g. accidentally break the macOS versions).
- ran a short manual and a more extensive agent based code review (so I can sign this with good conscience)
- let the coding agent fix some bugs (check saved state before applying, recalling factory presets updates the UI, protection from overwriting a stale user-patch selection, MIDI note-off respects channels, sample counters don’t wrap after some hours of running)
- added scripts for signing and notarizing the macOS build (this is needed so macOS considers the plugins trustworthy). I didn’t add this to the CI build because then you’d need an Apple account and put your credentials into GitHub to make it work on your repository. The scripts can be run locally. I can create macOS build of new versions if you want.
- signed and notarized the current version, so it doesn’t require the user extra steps to trust the plugins
The sources are again in the repo linked above. If you want I can provide you two pull requests for the macOS port and bug fixing separately. I could also split the big bug fix commit into separate commits. (unless you don’t review these anyways then feel free to take it over as is, the bug fixing is the second last commit )
Here the signed and notarized version (with the bug fixes above applied): https://drive.google.com/file/d/1Sb_t25d8eicrhpr_rPRRJy4T_R2Q6FWT/view?usp=sharing (use File->Download to download the full zip file)
A pull request is an offer to merge my changes into your repository. You would get a mail and can then decide whether to do the merge or not. If you want to see the changes up front you can look here (you can also click on the commits to see the separate steps, like only the bugfixes etc.): Comparing bjglover:main...NothanUmber:main · bjglover/blazar · GitHub
1 Like
Brilliant, thanks for all the work on this. Happy to action any pull requests you send. 
Will refactor this into several focussed pull requests. A good practice, it shouldn’t have to make a difference for the maintainer whether something came from a human or a LLM - no code dump blobs
OK! And do I download the Mac zip and add a new release for that…?
Feel free to add my zip to the release section of your GitHub page, yes. Probably better after you merged my changes, because the binary already contains all the changes from these pull requests. (You might also want to build a new Windows version based on those, so the bug fixes are also in the Windows version).
1 Like
OK! (Happy to add you as a collaborator to the project if that makes things easier.)
(Sorry to say this here, but I feel a moral obligation that I can’t shake.
I’m really worried about the vibe coding, myself. In some ways it seems no worse than embracing AI generated music, but technically we know that these models have incompetent and malicious code in their training data, socially we might trust some of the companies providing these models but I doubt we can trust all of them, and overall there’s no known auditing method for LLMs. To trust the machine generated code you need to understand it better than if you’d written it yourself, because at least you know your own motivations and abilities.
Not to say that I’m against good ideas seeing the light of day with the least possible friction. I’ve never quite believed the mandatory suffering theory of art. But this technology is by its nature not ecologically sound, however useful it may be.)
That’s fair enough. It’s a divisive subject. I’ve chosen to trust it so far. There’s a lot of it about, and I think it’s going to become difficult to avoid systems with elements of AI generated code.
The environmental concerns are also valid. We each have our own approach to that. I choose to use AI, but try not to do so wastefully. It’s not completely unlike the choice of whether to fly, or own a car, or adopt a certain diet, etc.
Here you can review the separated steps up front, so you can better understand what each change does: Pull requests · NothanUmber/blazar · GitHub
Then I can either create a pulll request for each one. You’d have to merge the first, then I could open the second etc. Or I just create a pull request from my main branch to yours, that would contain all changes at once, if you prefer that.
1 Like
OK! Happy with the second option…
@sps I personally see a difference between vibe coding own ideas - which leads to unique programs based on human ideas that would otherwise probably not have existed. Essentially using the coding agent to “compile” down a high level specification into binary code.
And vibe coding “make an app that I can sell”, which would be at the same level as “compose me a hit that I can sell”.
E.g. for my music app that is in development I have spent months of research and iteration (on and off). But without coding agents I wouldn’t even have started the endeavor, it is too big for me and my spare time.
I am pretty confident that this particular synth contains no malicious code. But for larger code bases controlling that gets more and more difficult. The further away we get from the actual machine code the more trust in tools is needed (Even when using a C-compiler you have to trust that the binary it creates does what the C-file you gave it to compile defines). And that the libraries you link to don’t do things they are not supposed to. I guess there is no easy answer. Time will tell where this leads us - very difficult to predict atm, imho.
Mega pull request created (It still links to the individual mini requests in case you want to trace the purpose of an individual change).
…awesome, I think that’s all done. 
1 Like
When you click on “Actions” you can see the build pipeline doing it’s thing, building the Windows app and the macOS Apple Silicon and Intel apps: Merge pull request #1 from NothanUmber/main · bjglover/blazar@67de3ec · GitHub
For now these binaries are dropped after the test build. Later we could automatically build release versions on push/merge or on tag.
For macOS the automatically built version is currently signed with an ad-hoc key, so the user would have to do some manual steps to trust the plugin when we would directly use the current CI build. To sign and notarize it you’d need a payed Apple developer account and set the related signature key as secret in your GitHub account so the GitHub CI runner could use it. Probably it is the same for Windows nowadays. But still good to have the CI build as a compile and unit test check.
Signed binaries can be built manually and then uploaded for now, this is probably the simpler approach.
2 Likes