Nord User Forum

[Hobster]

I'm sure a few people here will be interested, me included.
Funily enough, back in the eighties, I modified an old set of Maplin bass pedals and a Moog Prodigy (had to make the 2 oscillators produce '32 ft' waves; i.e. an octave lower than normal) and ended up with the equivalent of a Moog Taurus!! All analog electronics of course and it sounded pretty cool!
And yes, I think I will put my project into the Stage 3 itself!
I've simplified it by removing the hex inverters as the ATmega output thru the Nord's 47R resistor (it's what Nord uses for some reason rather than the more usual 220R) seems to easily supply enough voltage & current to drive a MIDI input.
In fact the project now simply consists of the ATmega328P, a 16MHz crystal with 2 x 22pF caps and a 100nF cap!
And I've managed to reduce the code size hugely and, more importantly, sped processing (and hence, response) up by quite a bit too, simply(!) by writing my own UART handler instead of using the Serial class.
Ironic really; the first real pro coding I ever did was back in the early eighties and it involved serial communications (that's all MIDI is) which heavily involved writing (in 6502 assembler) UART handlers!!

[Mr_-G-]

For velocity you could use the standard method of having 2 contacts per key, which close at different times during the key down. The difference in timing sets the velocity, I am not sure if an Arduino is quick enough for this kind of processing (maybe it is, I just do not know). Really interesting projects, keep them posted.

[Mr_-G-]

Here's the modified code (Filter.txt) for my project (with home-brewed UART handler - if you can call it that; there's only three lines of code that do the actual transmitting and receiving!! ) that I mentioned a couple of posts back. Just change the extension from .txt to .ino to be able to use it with the Arduino IDE.

As I hinted at in the previous post, there are several ways to do this sort of MIDI programming using an Arduino...
1. Use an Arduino MIDI library - simple and effective, no chip datasheets needed (see below)! But you end up with quite a bit of code (source & compiled) and a relatively slow(ish) program.
2. Use the Serial class - my original code (see previous post). Produces fairly lean code and is still pretty easy to understand.
3. Get 'close to the metal' - which is what this version does. Trickier to grok, but produces very tight compiled code and runs like a rat up a drainpipe which is why I ended up using this method

To understand (the different bits from before of) my code (all the lines with CAPITAL letter variables), you'll need to pore over an 'ATmega328 Complete Datasheet'; there are several variants out there (just google it) and any of them will do the job.
I used the Atmel original (https://atmega32-avr.com/atmega328-datasheet/); page 176 onwards contains all the necessary info.
I'm afraid this is all about bit manipulating - bit-shifting (using << and >>) and bit-masking (using ~, & and |) - microprocessor registers and hardware control so be prepared for a bit (haha) of a headache if you've not done any low-level programming using chip datasheets before...!

It's worth it in the end though if you intend to get into this sort of microcontroller-based port-manipulating MIDI/comms programming and it has one other advantage that I REALLY like...
Unlike if you use 1 or 2 above, using 3 means that you don't have to rely on anyone else's code!
Aside from understanding (and using the register & bit names from) the datasheet, It's totally self-contained
OK, all those capital variable names (UCSR0A etc.) have been defined (by someone else) in a .h header file somewhere, but that's all they are; definitions. They're not someone else's code!
And if there's one thing I've learnt, thru bitter experience over the years, it's NOT to rely on anyone else's code no matter who they are (yeah, Microsoft, especially you!)

I've not included a circuit design as there are plenty about on the web that show the absolute minimum you need to use to get the 328P working (see previous post for component list).
But if you understand 'Assembly language' intermediate files, I've also included (FilterAsm.txt) the one for this C program which shows just how 'lean & mean' the C code gets compiled to!
Just ignore all the 'timer' stuff - this is automatically added by the Arduino compile process (to make it easier for novice Arduino programmers who just want to dip their toes in the water ) and isn't part of my program. As it only runs once at the very start, it doesn't actually affect the main code at all which is why I haven't bothered modifying the Arduino 'makefile' stuff to remove it - that would just be TOO nerdy!!
Health Warning: Assembler is not for the faint-hearted

[Hobster]

Managed to get rid of all the redundant timer initialisation stuff (inserted by the Arduino IDE) and it turns out I didn't need to modify anything to do with the Arduino environment or anything techy!!!
I just needed to have my code run in a routine called.... main() - which as any C/C++ programmer will tell you is one of the first things you learn about in C..!!!

Having said that, It's not quite as obvious as it seems cos the Arduino documentation doesn't mention anywhere that you can...
actually override the Arduino main() function - which calls init() then setup() and then loops around loop() - with your own main() function! - who knew!!

The compiled code is now pretty much halved and everything (except the interrupt vector table and the first dozen or so 'variable clearing' instructions) that's in the compiled file is purely 'hand-rolled' code; no 'hand-holding' stuff from Arduino
Yaayyy!!

Needless to say, if you plan on using a MIDI library, the Serial class or even just anything to do with timers (delay(), millis() etc.), then you can't use this approach!

[anotherscott]

I'm currently building a project...that will allow me use the Stage 3 to control my GSi Gemini over MIDI the way I want to.my own solution

The original solution you came up with (using channel 4 via EXT for notes and channel 6 via Global for controls, as described at the other thread) looked clever and effective to me! So why do you need a device to do more? Is it to get the Rhodes/Wurli real-time control that your other approach doesn't give you?

I also contacted Guido at GSi and although he didn't feel that changing the way the Gemini worked was appropriate

Too bad. Maybe the issue is just too specific to the Nord Stage. If there were a variety of instances where one might want the MIDI notes to come in on one channel while the controls came in on another, it would probably be easier to justify building that feature into the Gemini software.

[Hobster]

Is it to get the Rhodes/Wurli real-time control that your other approach doesn't give you?

Yes, that's one of the reasons. With my ATmega project, I now have CC panel data going out on channel 4 for the organ patches on the Gemini DSP 1 and on channel 7 for the electric piano sounds et al that I use on the Gemini DSP 2. Exactly what I need!

But even more importantly, I now disable the Nord control pedal from sending out Expression (CC11) on the Global channel which I couldn't do before - unless I turned off the Global channel completely, but of course, that's not programmable per patch!
Instead I can now send CC11 out on either or both Extern channels on a per patch basis using the Extern switches.

When I used that bodged solution, because Expression was still being sent out on Global channel 6, it meant that the volume level of the organ on the GSI was modified by the Nord Control pedal as well as my usual method of controlling it with the Nord Swell pedal! This was extremely annoying!

Anyway, I couldn't be happier with how this ATmega project has turned out. My final step is to (gently) modify the Nord so that my circuit runs internally...!
I need to do the mod on the Mod Wheel (remove the connector and hard-wire it to the board) because, as many others have discovered, mine springs into life occasionally of its own accord!
So I'll hopefully do both mods sometime next week. Fingers crossed...

[anotherscott]

When I used that bodged solution, because Expression was still being sent out on Global channel 6, it meant that the volume level of the organ on the GSI was modified by the Nord Control pedal as well as my usual method of controlling it with the Nord Swell pedal! This was extremely annoying!

But the Nord sends Swell as CC 4, and Control Pedal as CC 11. Couldn't you just program the Gemini to recognize 4 for volume, and then it would ignore 11? Or does it see 11 no matter what? If that's the case, a MIDI Solutions box could just filter out CC 11.

[Hobster]

I know the Nord sends Swell as CC4 & Control as CC11. I used MIDI Monitor on my Mac to figure out exactly what the Nord does when it comes to MIDI transmitting...

Unfortunately, the Gemini always responds to CC4 as Swell (when using the VB3 engine) & CC11 as Expression (which affects volume on the GSi) and that can't be changed or disabled.
That was why I asked Guido if he would be prepared to implement some way of being able to selectively disable CC11 reception.
But he felt it wasn't a viable solution and I can see his point.
IMO it's Nord's rather shoddy MIDI NS3 implementation (just look at the number of topics raised on this forum about NS3 MIDI; admittedly mostly about incoming MIDI, but still...) that's to blame.

And why would I want to spend money on an external MIDI box when I'm perfectly capable of creating my own solution (without the need for an external box to put it in either)...?
Besides, I want to selectively (on a per patch basis) filter out CC11 messages not stop them altogether.

I'm really pleased with the ATmega solution I've come up with and I expect that I'll fully write it up and post it (like KeyFrog2 has done with his) at some point in the future; assuming my Nord mod'ing goes to plan...!
And I REALLY enjoy doing this sort of embedded software thang anyway (alongside playing music of course!)

I may include a description of how to do it as an external box too in case anyone else feels (sensibly...?) that it's a bit risky tinkering around inside the Nord...!

[anotherscott]

why would I want to spend money on an external MIDI box when I'm perfectly capable of creating my own solution

That's the difference... I'm not.

Besides, I want to selectively (on a per patch basis) filter out CC11 messages not stop them altogether.

Uh-huh. Though in general, for overall volume, I think I'd put the Gemini's outputs through something like a Boss FV500L pedal, because using the morph-flexible control pedal just for volume seems a shame when there's usually something much more interesting it can do.

[Hobster]

That's the difference... I'm not.

Fair enough, but your comments seem to me to be wondering why I haven't embraced a solution that you yourself may well have chosen and why I've chosen this route to go down...
Which is why I'm responding with why I chose my solution. I perfectly accept that you may well have chosen differently

Anyway, I don't just use the Control pedal to send CC11. I can (and do) use it to send other (sometimes multiple) CC mesages to the GSi.
Besides, I've never really liked audio volume pedals and they're yet another box + wires to have to set up at gigs plus I've only got two feet (Control pedal & Sustain pedal or Rotor pedal & Swell pedal) and there's only so much floor space!