New Open-Source G2 Editor RFC

[blue hell]

ok ok ok .. looking for cables

edit: cable - check :

[blue hell]

Oh, cool ..

1) thye G2 still works and
2) it loads my latest noodle there into the editor and
3) i can switch variations and
4) some knobs work
5) when the G2 hickups - as on cable edits - when i turn it off and on again it is neatly picked up -- great

So. not much luck yet on clicking cables yet.

promising .. had a quick look at the code .. looks more reasonable to me than some other/earlier attempts I had seen .. was this a port of bruno's?

More later

[ChrisPurusha]

I've credited Bruno with some of the protocol reverse engineering, but I think I might have corrected a few bits and pieces. 'C' is easier for me to follow, since I've been working with it for 40+ years! Also being in 'C', it's a short step to C++, which I hope is more easily translated to other languages than from Pascal/Delphi. ...or the underlying mechanisms could stay as C/C++, and GUI could be done in a different language.

Otherwise, it's not a port of the other editor. I pretty-much started from scratch, using my own 'C' framework. It's what you might call vibe-coding, but with a fair bit of 'C' experience behind it. I used Wireshark to look at some of the protocol bits and pieces Bruno didn't seem to cover. I put a fair bit of work into the graphics side of things. Really wanted to have a zoom feature for the modules in there, so that was designed-in early.

Cabling should work - at least on the implemented modules btw.

'C' or C++ programmers welcome to help out! As you can see, as a proof-of-concept, all the fundamentals are there.

Right-click also brings up menus in various scenarios.

[blue hell]

tried a couple of cables .. just clicking on one alters the sound my patch .. so it works in the sense that it does ... something but I did not try to investigate what goes wrong.

I can not test it now .. but there is no support for multiple G2s I guess?

[ChrisPurusha]

Cables are drag from one connector to another. Just clicking on one should do nothing. Click on a connector and drag to another…? I only have 1 G2 to develop with, so haven’t looked at multiple units.

You could always give us a patch you’re working on, for me and the other developer to look at?

[blue hell]

Yeah, and before you drag you need to click .. and that is enough to make the sound change - I will look into this later - not now ..

I had planned to first have a look at the code in the coming week .. so that I do not need to take a synth with me but just a laptop.

Anyway, later more and no worries or guilt feelings or quick help or fixes .. give me some time please .. it has been (a) decade(s) since I looked into the G2 or the nords in general .. and I was just telling what I noticed.

[ChrisPurusha]

No problems this end. I don’t have time for quick fixes at the minute anyhow.

Cables shouldn’t affect the sound if the linkages aren’t changed btw.

[cube666999]

Hi Chris (and ian-s if you're reading this),

I've been following this project with great interest as a Nord G2 owner who's looking to finally retire his old 2009 MacBook from patch editing duties.

While digging through the source of the electro-music.com patch viewer, I came across this file:
https://electro-music.com/patchviewer/nmg2mods.js

It contains complete visual data for all 185 G2 modules — input/output port positions (x/y coordinates), cable colours, labels, module heights and graphical elements. Crucially, each module is indexed by the same type ID used in .pch2 files, so the mapping is already there.

I want to be clear: I'm not asking about copying the JavaScript code — that's not the plan. What I'd like to ask ian-s is whether the data itself could be used as a reference for a native C implementation in G2-Edit. This is an important distinction: a port position is a technical fact describing Clavia's hardware, not creative authorship. That said, ian-s clearly put enormous effort into measuring and documenting all 185 modules, and that work deserves respect.

If ian-s gave his blessing, this could dramatically speed up the GUI implementation — instead of manually defining each of the 200+ modules from scratch, you'd have a complete reference dataset ready to be translated into C structs.

I'd also be happy to help with testing on Apple Silicon (M3 Max) with a G2X connected via USB-A to USB-C.

Keep up the great work — this is exactly what the G2 community has been waiting for!


As a further incentive — and without waiting for ian-s to respond — I went ahead and extracted all the data from nmg2mods.js and prepared ready-to-use files:

- g2_modules.h — a C header with all 168 modules, ready to drop straight into G2-Edit. It includes structs for ports, parameters and visual elements, plus a g2_find_module(id) function that looks up a module by its .pch2 type ID
- g2_modules.json — the same data as clean JSON, useful for other projects too (g2fx, future tooling etc.)

I'm treating this as reference/working material until the licensing situation with ian-s is clarified — but if you'd like to take a look, I'm happy to share the files.

Jakub

[blue hell]

Ian did great work on the patch viewer for sure, and also the data gathering for the module details has been a long process

Some history details that I know of ...

It started with : http://www.dewb.org/g2/pch2format.html#ModuleList iirc

I expanded that a bit : https://bluehell.nl/iaf/html/nm-open/nm-open-g2info.htm

then came g2ools, and ian's work .. also ben verhue made some g2 editors

I think that you can feel free to use any data about modules and protocol that you can find - it has always been an open minded group effort.

there is more of course .. like : https://electro-music.com/forum/topic-6226.html&postorder=asc

or well .. actually of course it started with getting into the NM Classic

[ChrisPurusha]

[cube666999]

Understood, good luck with the election! The files will be waiting for you.

When you're ready — what's the best way to share them? I can put them on a GitHub Gist, open a Pull Request on your repo, or just send them directly — whatever works best for you.

In the meantime I'm happy to start testing right now on an M3 Max with a G2 connected via USB. Is there anything specific I should be testing at this stage? What are the steps to build the project in Xcode for Apple Silicon? And is there a list of modules or features you'd like checked first?

Jakub

[ChrisPurusha]

I don't mind. Dropbox, restricted GitHub anything really.

I need to catch up with where we got up to. Contributor in Sweden has been implementing some of the modules, but need to work out how far he got.

Last thing I was working on was file loading and saving. Loading pch2 files and saving them into a new file, making sure that the OG editor will accept the saved files.

Loading patches from the G2 and pch2 files, checking for crashes. Any anomalies, pass the patches to us to check.

Building should be fairly straight forward if you have home-brew set up as per the instructions on GitHub. I'd like to build the libraries as part of the project, but that's not a high priority.

One thing I need to do is - work out how and when to read and write to the hardware on re-connection or file loading. Any thoughts on that welcome. E.g. what should happen if hardware is disconnected, file is loaded and G2 is reconnected? Related - not sure if there's a mechanism to clear the current slot when loading a file. Will probably need to monitor comms with Wireshark to see how the OG editor does that.

Note that not everything works yet!