NMG2 Open Source Editor

brunov · Posted: Wed Oct 12, 2011 3:18 am Post subject:

Hmm, it seems a big part of the problem can be expained by the delay of 10ms I put in the send thread of the server. Embarassed

Forgot about that.

I put it there to give the other threads some cpu time. Otherwise the receive thread might miss a message from the G2, and then contact is lost. So I have to do something there. I already gave the receive thread a higher priority put that's not enough.

I'll try some different settings.

brunov · Posted: Wed Oct 12, 2011 2:06 pm Post subject:

I put a delay in the send queue of 1ms if there are messages to process otherwise when the send queue is empty a delay of 10ms, seems to work ok for up to 5 automated parameters with visual editor and vst, or when not visible I can automate more. With some more optimization this can be improved.

But I as a matter of interest : How many parameters of the G2 do you usually automate in a ableton/cubase/or other project?

Moody33 · Posted: Wed Oct 12, 2011 9:32 pm Post subject:

Hi.

In my case, I often use:

aftertouch+mod wheel+sustain pedal+control pedal+ CC#7+ 2 or 3 other #CC

So 8 parameters in my case is a maximum.

brunov · Posted: Thu Oct 13, 2011 12:50 pm Post subject:

Ok, thanks. Is that for one slot or do you use this automation for multiple slots? In other words, do you sometimes have 8x4(slots) = 32 parameters automated?

And another question: in a ableton/cubase project do you generally use the G2 as 4 seperate patches or do you use it in performance mode?

ZeeByeZon · Posted: Fri Oct 14, 2011 12:25 am Post subject:

I think you should not make such assumptions about the use of most users: this is very variable from one user to another, and this will change in time...

For your second question for example, I think both are interesting and depending on the project, I would choose either performance or multi-patch... especially if a VST editor allows the saving of my program with the song!

brunov · Posted: Fri Oct 14, 2011 3:21 am Post subject:

Yes, I'm asking because it makes a big difference for the application if your automating 8 or 32 parameters.

At some point it can't process the input fast enough so you get a backlog of messages. So then the application could start sampling the input or something to keep up. But I don't think I'm going to do that now, because it'll make it all even more complex.

I was hoping to get some idea of how people use the g2 in ableton, so i could get an idea of how important the above problem is.

jksuperstar · Posted: Fri Oct 14, 2011 2:13 pm Post subject:

Because there are 8 knobs on the front of a G2 with keys, plus aftertouch, modulation, pitch wheel, and volume, I would assume that would be a pretty strong place to start. It allows a typical performance to be played in real time without the feeling of missing something. I would suspect it'd be a lofty (but in the long run worthy!) goal of supporting any number of parameter changes...MIDI supports 128 CC, plus pitch wheel, etc... You get the unfortunate point Wink

brunov · Posted: Sun Oct 16, 2011 3:20 am Post subject:

Ok, think I have a solution now.

I've made a table in the server for the parameter changes.

When the server receives a parameter update from a client, it's value is put in the table with indicator "changed".

Every cycle of the send thread the changed values are send to the G2 and the changed indicator is reset.

When the changes are comming faster from the clients then the send thread can handle, the values in the table are simply overwritten with the latest value.

I've also improves the graphics performance in the vst a bit.

Here's a screenshot where i've automated 8 params.

CPU in the task manager show's about 50%, but when I look in the Processes tab, it shows 50/60% System Idle. So I guess that's ok.

Ableton show's Cpu load of 5%

Result_12.jpg

Description:

Filesize:

416.38 KB

Viewed:

513 Time(s)

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

Derek Cook · Posted: Mon Oct 17, 2011 2:26 am Post subject:

This is a very interesting project.

If ever you wanted any help in implementing this in Java so that it is cross platform on anything that runs a Java environment, then let me know!

ZeeByeZon · Posted: Mon Oct 17, 2011 2:57 am Post subject:

I could for this help too Smile

brunov · Posted: Mon Oct 17, 2011 9:57 am Post subject:

Thank you very much Derek and ZeeByeZon! Very Happy

Yes, if this is ever to progress from a private project to something everybody can use, I will need some serious help!

I've not uploaded any software because I didn't want to bother you with an endless stream of updates and bug fixes. I think I've rewritten the thing 3 or 4 times already but now I'm happy with the structure. It's a matter of adding functionality from now on, optimizing performance and finding and solving bugs.

Of course when your porting it to Java, I don't now what kind of problems you will find...

What I'll do this week is add comments to the source code where I can, and explain a bit of the structure on the website. And then at the end of the week I'll upload what I have so far. Maybe you can have a look then and decide what you want to do.

Derek Cook · Posted: Mon Oct 17, 2011 11:58 pm Post subject:

No worries. It's just a suggestion, and I don't want to disturb any other plans that you have. But I have found in my own work that Java does live up to the write once run anywhere paradigm.

The only thing I'd need to look at first is how to talk via Java over USB. You'd probably need a Java Native Interface (JNI) for that.

Derek Cook · Posted: Tue Oct 18, 2011 1:43 am Post subject:

Update: I had a quick browse for Java and how it can interface to USB, and that's something that I'd need to look at first, as it does not appear to be straight forward.

If you have a test program that is simply interrogating the G2, that would be the best place to start.

Something I'm happy to look at anyway, as I love my G2 and would like to see it continue to be supported.

brunov · Posted: Tue Oct 18, 2011 10:00 am Post subject:

Derek,

I use the libusb-win32, that's a generic usb driver that you can put on top of the original clavia driver (filter driver). So you can still use the original clavia software, that's essential i think.

There exists a Java wrapper http://libusbjava.sourceforge.net/wp/

Don't know if you use a windows/linux/max platform? All should be supported according to the info.

I've included a test application that I started with. The units that are important for the connection are the following:
- LibUSB.pas : this is the interface to the libusb-win32 dll
- UnitG2USB.pas
in this there are a couple functions:
Init : to set up the connection to the G2
Done : to close it
bwrite : bulk write data
bread : bulk read data
iread : interrupt read

So basically you send a message with bwrite then you get a message back with interrupt read and when the returning message is bigger than 16 bytes you can read the rest with a bulk read.

I hope this will get you started Smile

Result_13.jpg

Description:

Filesize:

135.59 KB

Viewed:

326 Time(s)

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

G2 Tool.rar

Description:

Download (listen)

Filename:

G2 Tool.rar

Filesize:

235.28 KB

Downloaded:

342 Time(s)

Derek Cook · Posted: Tue Oct 18, 2011 1:14 pm Post subject:

OK, thanks

I'll take a look when I get five minutes. I'm currently updating my music computer to Windows 7 and having a few issues. On the plus side, the Nord G2 Editor works with the latest Clavia USB drivers on Windows 7 Smile

Derek Cook · Posted: Sat Oct 22, 2011 3:46 am Post subject:

This is just a quick post to let you know that I have downloaded your example, and am working on converting it to Java. I'm not very familiar with Pascal/Delphi, so am on a bit of a learning curve!

blue hell · Posted: Sat Oct 22, 2011 4:10 am Post subject:

Some file info then Wink

pas are the pascal files, dpr is the 'main program file' it will have have a uses clause that lists all other files in the project (but not all source files used need actually be in the project).

Some pas files have an associated dfm (same base name), or form file, usually that one is readable too, or could be made readable at least.

The dfm has the form design which can have some non visual components too (in general, everything descending from TComponent can be in a TForm). The actions associated with the form will be in the pas file, some of the couplings to buttons for instance can be read in the dfm).

dproj is not too interesting for you I think, it's an XML project file that can be regenerated by delphi when it got lost.

dsk files are desktop files, not interesting for porting.

dcu files are compiled units, or pas files (object files), not interesting.

cfg holds compiler options, not interesting.

res is a regular microsoft compiled resource file.

ddp - no idea, but not interesting

identcache - just delete it.

Derek Cook · Posted: Sun Oct 23, 2011 1:29 am Post subject:

Thanks for that, but it was more the syntax of the code that I am learning. Smile

It's funny I've programmed in all sorts over the years: machine code (yes, hand assembling op codes), assembly, BASIC, FORTRAN, PL/M, OCCAM, C, C++, Java and even some Prolog, but never Pascal for some reason.

Still, the port is going fairly well, I have most of it converted now according to what I think should be happening, so in the next few days I should be ready to try it out for real.

Derek Cook · Posted: Sun Oct 23, 2011 10:27 am Post subject:

Well, I can report some success. Smile

I did the initial port, remapping the LibUsb functions to the LibUsbJava wrapper.

The installation of the filter driver went pretty smoothly.

I had a lot of aggravation getting the software to recognise LibUsbJava. Essentially the native DLL needs to be in the C:\Windows directory, which was not obvious.

I then went into debugging mode Wink

, focusing on getting the List function working. No GUI at present, everything is being dumped on the command line.

After sorting out basic problems, like the CRC calculation (my errors in the porting Smile

), it all appears to be working pretty well.

So the next step is to try and build the complete test app that Brunov did in Delphi, but in Java, tidy the code up and get it commented and I'll then post the results for others to have a look at.

Antimon · Posted: Sun Oct 23, 2011 10:50 am Post subject:

Wow cool! It would be interesting to get a look at the Java code at some point, if you feel like sharing.

brunov · Posted: Sun Oct 23, 2011 1:26 pm Post subject:

Since I won't have much time to work on the project the next couple of weeks, I've made an effort to make a first beta release and update the documentation.

You can find it all here : http://www.bverhue.nl/G2dev/

That includes the executables and the source code.

Here is a screenshot of how the editor looks now.

For the visible changes:
- I've added the module colors
- Added the module names, but you can't change them yet
- Added a little sequencer grid for the note sequencer, to make it a bit more easy to edit a sequence

For the none visible changes
- Ive solved a vast number of bugs, but not all I'm afraid Smile

- Made some improvements to the cable rendering
- Lots of other small things of course

So I hope someone will be able to try it out. I would recommend this only to someone who's experienced in software developement though. I've only been able to test this on an xp machine. And I hope of course that it will help Derek with his java development.

Regards
Bruno

Result_14.jpg

Description:

Filesize:

421.68 KB

Viewed:

379 Time(s)

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

Antimon · Posted: Sun Oct 23, 2011 11:23 pm Post subject:

The UI looks pretty enough anyway! Going to try to run this today or tomorrow.

Derek Cook · Posted: Sun Oct 23, 2011 11:59 pm Post subject:

Derek Cook · Posted: Mon Oct 24, 2011 12:17 am Post subject:

dorremifasol · Posted: Tue Oct 25, 2011 12:39 am Post subject:

This is an amazing work. Editing the G2 from a cheap android tablet may not be a dream after all. Smile