NMG2 Open Source Editor

v-un-v · Posted: Sun Dec 11, 2011 12:54 pm Post subject:

Sorry, please pardon my bad manners! Excellent work! Very Happy

(even though I still only have a mk1 Nord Modular).

Antimon · Posted: Sun Dec 11, 2011 1:03 pm Post subject:

fairplay · Posted: Sat Dec 17, 2011 4:58 am Post subject:

...just to let you know that i am following your efforts with admiration - thank you for tackling this project...

...Thank You!...

dasz · Posted: Sat Dec 17, 2011 11:22 am Post subject:

I too want to applaud you on your efforts, cheers!

Looking forward to trying it when the time is right ...
Dasz

buzzr · Posted: Sat Dec 17, 2011 8:55 pm Post subject:

Most excellent..I sold my nord G2 only to buy it back again as it's the best instrument I've ever owned. This solidifies this 3 fold. Thanks again for your work!

brunov · Posted: Mon Dec 19, 2011 3:00 am Post subject:

Thanks, I enjoy working on this, I find it very satisfying to find out bits and pieces and putting it in the software and then to see it actually work.

This weekend I did the performance dialog and the global knob assignments. My plan now is to try to put in as much as possible of the missing functionality the coming months. It's surprising to see how much functionality there is, things I've always taken for granted. So this is what's missing at the moment:

Select, cut, copy past part of patches
Undo, redo
Auto assign midi
Sysex functions
Bank/patch manager
Choose module color
Show/hide cables
Edit name of modules/parameters
Module text functions
Module graphic screens
Multiple g2 support
Memory used indicator
Virtual keyboard
Patch adjuster
Patch mutator

I'll do the cut/copy/past stuff first, because that may involve another round of software restructuring.

I'm not going to try the patch mutator. I think that would be very difficult and take too much time. Memory used is also difficult, don't know if I can make that 100% accurate. Multiple g2 support, don't know yet. Undo/redo might be difficult too, don't know yet how this is done with the usb messaging.

Then there is extra functionality that isn't in the original editor:
a Vst
OSC support

With the vst you can automatically load patches with an ableton project for example. This is done using FXB files, but maybe there are alternative solutions. And with the vst you can automate the parameters. The parameter change messages are send over tcpid to the editor and then over usb to the g2 in stead of using midi.
So I could try to make a translation layer for sending the parameter change messages between vst and editor in osc format. Then you could also communicate with other osc devices with the editor.

I'm new to osc and I don't have a lemur or an ipad or max for live, so I'm looking for a simple windows osc tool that sends out and receives osc that I can manipulate with the mouse. If the editor can communicate with that tool, it will be able to communicate with other osc devices too. So if you know of such a tool, please let me know.

The biggest problem with linux version of the software at the moment is the buggy scrollbox control of the Lazarus/fp compiler. So in the worst case we'll have to write our own scrollbox control.

Then some day I'll try to compile the project for OSX, both Lazarus/fpc and the latest Delphi compiler should be able to able to build applications for OSX.

If there are people able and willing to help with the delphi developement, we could put the code somewhere on sourceforge or somewhere like that. Don't have any experience with that so any advice would be welcome. Maybe Derek's Java code could be there also.

Or if you have suggestions about the functionality, that's always interesting too.

So, all in all, there's really no excuse for getting bored this winter...

jksuperstar · Posted: Mon Dec 19, 2011 6:46 pm Post subject:

In the words of someone sampled on The Dark Side of the Moon:

"Brilliant. Absolutely fucking Brilliant!"

Many thanks and congrats on such a superb job!

Derek Cook · Posted: Tue Dec 20, 2011 1:04 am Post subject:

jksuperstar · Posted: Tue Dec 20, 2011 3:09 pm Post subject:

brunov · Posted: Thu Dec 29, 2011 2:16 pm Post subject:

Hey Derek, great that you are so busy with your music, the java implementation can wait of course.

Jk, thanks for the osc tool, i'll try that.

I've done the cut/copy/paste/delete parts of patches and basic undo functionality: I just put the opposite of a message on an undo stack, so if you add say a cable, i put the corresponding delete cable message on to the stack.

Also did the parameter and module name change functionality.

And now I've also been able to get my hands on the latest Delphi compiler: Delphi XE. That opens up a few new possibilities. You can for example compile for different target platforms: win32, win64, macos (but no linux yet unfortunately).

There is also a different ui farmwork "firemonkey" that enables for example zooming in and there's also support for touch and gestures. I'm going to take some time to look what I can use of this in the editor. Can't promise anything of course, but all quite interesting. I'll keep you posted.

brunov · Posted: Tue Jan 03, 2012 2:51 pm Post subject:

Ok, made a bit of progress with the Osc. I didn't get the tool you suggested to work jk, but found another one "Mouse to Osc" by www.niallmoody.com. And joreg http://opensoundcontrol.org/implementation/delphi-osc already made a port of the osc implementation to Delphi, so that's great.

Here is a screenshot. Maybe someone has a suggestion how to format addresses in the G2? In the example I address the parameter pages as "/<parameter>/<page>/<button>".

The Osc uses the UDP protocol, what I've read about it is that it doesn't guaranty the delivery of the message, so in the editor it can only be used for messages that aren't critical, that's the responseless messages:
- select module parameter
- set module parameter value
- set module parameter morph range

Result_18.jpg

Description:

Filesize:

274.21 KB

Viewed:

307 Time(s)

This image has been reduced to fit the page. Click on it to enlarge.

Derek Cook · Posted: Tue Jan 03, 2012 4:10 pm Post subject:

Hi,

Still no time to look at the Java stuff.

But I can confirm what you are saying: UDP is a connectionless protocol, compared to TCP/IP which is connection oriented. So UDP does not guarantee that data will get through, but TCP/IP will.

UDP is good for continuous streams of data, where you do not want retransmits in the case of errors. For example, I deal with sensor communication systems over networks in my day job. The sensors send data at 20Hz. If a packet is corrupt, we don't want a retransmit, because we know the next (up to date) sample is coming along in another 50ms.

But as you say, UDP is not good for when you want to guarantee that a message gets through correctly. So, back to my example, whilst sensor updates can be lost (as long as you don't lose too many), the configuration data to control the nodes are TCP/IP.

Hope that makes sense and is of some help! Smile

brunov · Posted: Wed Jan 04, 2012 12:19 am Post subject:

Ok Derek, I will keep the TCP-IP connection for the Vst then. That holds a copy of the patch that must be in sync with the editor.

Thought some more about the Osc addressing structure, it should of course be structured so you have access to all functions in the g2 or multiple g2's. You should then be able to create the knobs panel of a g2 on a touch device. Maybe something like

/1/patch/2/var/3/par/A/1/3/set 70

-> set the value of parameter on parameter page A, column 1, knob 3 of variation 3 in patch 2 of g2 synth 1 to value 70 Cool

or

/1/patch/2/var/3/par/A/1/3/morph -20

-> set morph value of the same parameter to -20

and maybe

/2/bank/2/patch/4/load 1

-> load patch 4 of bank 2 in slot 1 of g2 synth 2.

Don't have much experience with Osc, so any suggestions are welcome.

ZeeByeZon · Posted: Wed Jan 04, 2012 1:33 am Post subject:

In your example, I do not understand why and how you want to modify a parameter in a given patch in memory. I thought you can only access the parameters of the patch (or performance) in the edition buffer.

brunov · Posted: Wed Jan 04, 2012 5:42 am Post subject:

I'm not sure if I fully understand your question, but I made a little picture with the configuration. So on the right is the G2 that holds a performance and in the performance are max 4 patches that hold the parameters.

On the PC is the editor and possibly ableton with one or more Vst's.

The editor and the vst also both keep a copy of the performance and all the patches.

All the copies have to be sychronised, so if you would for example have mapped a Midi CC to a particular parameter, and you turn the knob than the following things happen:
- The G2 receives the Midi message and changes the parameter value
- Then it sends a USB message to the editor
- The editor receives the USB message and also changes the parameter in the appropriate patch (that doesn't have to be the patch that is currently visible in the editor, could be another one)
- The editor then sends on (broadcasts) the parameter change to all the clients (VST's) that are connected to the editor via TCP-IP
- The Vst receives the message and also changes the parameter value in the appropriate patch.

So with the OSC interface you could for example connect a tablet with Touchosc for example. There you make a slider and you want to map the slider to a parameter of a patch in slot B. That doesn't have to be the patch that's currently visible in the editor. The only thing necessary is to provide the editor with enough info so it can find the parameter, for example:

- The slider is mapped to address /1/patch/2/var/3/par/A/1/3/set
- So when you move the slider it sends a OSC message to the editor /1/patch/2/var/3/par/A/1/3/set 70
- The editor receives the message and finds out which parameter is mapped to the knob 3 on parameter page A 1 of Patch in Slot 2
- It sets the value of the parameter to 70 in variation 3
- than it constructs an USB message that looks like [Slot][Location][Module][Param][Variation][Value] and sends it to the G2
- it also broadcasts the same message to alle the Vst clients

Looking at the USB message, it might even be possible to change a parameter of another variation than is currently selected in a patch, although that might not be very usefull.

In any case, for the editor understand the osc messaging, some kind of syntax/structure has to be decided.

What i would like to know for example is how to address a particular slot, should that be /Slot/2/... or /Slot2/... Maybe these OSC devices have some means of constructing adsresses dynamically, for example a slider is mapped to adress /a/b/.. but if you push a button then the slider is mapped to a/c/.. and so on.

If you take for example the knob panel of the G2 Keys, there are 8 knobs that address different parameters depending on wich parameter page you have selected. If you want to recreate that on a touch device, you have to be able to dynamically construct the address.

I hope this makes some things clear?

Config.jpg

Description:

Filesize:

68.15 KB

Viewed:

247 Time(s)

This image has been reduced to fit the page. Click on it to enlarge.

ZeeByeZon · Posted: Wed Jan 04, 2012 6:32 am Post subject:

Thank you. What I did not understand was the "Patch" in your OSC address path: it may be better to call it "Slot".

If the USB protocol allows edition of parameters in other variations independanlty, then it is useful to reflect this in OSC. But it will be completely useless if you can only edit the current variation...
A typical use of this feature would be to change a parameter value for all variations and not only for the selected one. I really miss this feature on the current editor (or may be I am missing something).

brunov · Posted: Wed Jan 04, 2012 6:59 am Post subject:

Ok, yes I undestand your question now. I choose Patch in stead of Slot because a parameter only makes sence in relation to a patch. And a slot can hold a patch or be empty.

I will look tonight if I can change a parameter value in all variations at once with usb messages.

brunov · Posted: Wed Jan 04, 2012 2:38 pm Post subject:

Tested it: when I send 9 messages, one for each variation, the parameter gets updated in all variations.

I also don't know if this is already available somewhere on the g2 or the original editor. If not then it will only be a feature thats available through this editor. The drawback off that is of course that you have to connect a pc/laptop to the g2 to be able to use it.

I guess you would like to have this feature to have more control over transitions between variations?

brunov · Posted: Wed Jan 04, 2012 3:21 pm Post subject:

I've been playing a bit with this, and I can see now what would be the benefit : you can prevent some of the parameters that you have been tweaking from jumping to the original value when you switch to another variation.

ZeeByeZon · Posted: Thu Jan 05, 2012 1:28 am Post subject:

Yes, this is useful when you are building or modifying your patch. When you add a new module, the setting you make on this module are only done in the current variation, which is often not what you want.
A good idea would be to add a button near the variation selector to enable/disable an "edit all variations" mode.

brunov · Posted: Wed Jan 11, 2012 12:21 pm Post subject:

Here's an update of what I've been up to with the software development. In the editor I've put in that knob to edit all variations at once (Edit all, it just sends 8 parameter changes in stead of one)

Furthermore, the functions to change module color, show/hide cables, a couple of sysex functions: load/save patch/performance as sysex (thanks to Jan's code), command to the g2 to dump a sysex of the current patch or all assigned controllers.

As you can see I've made an overview of all the screens and menu's that are in the editor at the moment.

Now I'm working on the Vst. Initially I had a Vst that represented a slot. You could load a patch into the Vst with an FXP (Vst program) file or a Performance with an FXB (Vst bank) file.

So if you would use 2 slots, you would load two Vst's into the host. But what if you loaded a performance in one and another performance in the other? The last one loaded would just overwrite the first one. What if you would have automated a couple of parameters, and than would mistankenly change the slot the vst was pointing to. So all would lead to error and confusion.

Therefore I thought it would be better that the Vst would represent the whole G2. So for one G2 you only would need one VST. To automate parameters, you have to assign them to the global parameter pages. You can automate 120 parameters that way. In ableton, there seems to be a limit on the number of parameters, when I try to define 4*120 parameters it doesn't accept the vst anymore.
You also load FXB in stead of FxP, so performances in stead of individual patches.

I think this will be better, also the load on the host will be less.

The last couple of days I've put a lot of time in making the code thread save for the vst or multiple vst's, so no global data, but everything tucked away in objects that are created en destroyed within the thread itself and so on.

So testing and debugging aside, the following things remain from the list I mentioned earlyer:

Auto assign midi
Bank/patch manager
Virtual keyboard
Module text functions
Module graphic screens
Multiple g2 support
Patch adjuster
maybe:
Memory used indicator
Patch mutator

I already found some more functionality that I overlooked, but that's for another day.

I'm always interested in suggestions about functionality, so don't hold back Wink

Regards
Bruno

Result_20.jpg

Description:

Filesize:

407.38 KB

Viewed:

210 Time(s)

This image has been reduced to fit the page. Click on it to enlarge.

Result_19.jpg

Description:

Filesize:

395.19 KB

Viewed:

223 Time(s)

This image has been reduced to fit the page. Click on it to enlarge.

Roland Kuit · Posted: Wed Jan 11, 2012 12:37 pm Post subject:

Bruno, awsome!

Antimon · Posted: Wed Jan 11, 2012 12:55 pm Post subject:

I haven't commented that much in this thread, because it would just have been 10 "wow" posts, but Nord Modular VST? wow!

It's a big thread now - Is this available somewhere if I feel like helping out with betatesting?

/Stefan

brunov · Posted: Wed Jan 11, 2012 1:28 pm Post subject:

Thanks!

And any help with testing would be very much appreciated, but I want to take out the most obvious bugs first. I think that from the list, the Bank/patch manager would be something that I would like to add, maybe after that I have something that I could release as a beta version.

It would be windows only, because I ran into some trouble with lazarus and firmonkey (needed for osx developement with delphi) and the vst is also windows only at the moment.

dasz · Posted: Wed Jan 11, 2012 4:47 pm Post subject:

Count me in.

Looking forward to it.

Bravo, brunov!
/Dasz