Crumar D9U: Electro 2 Sketch (Part 5)

Finally, after all of the testing, the first Crumar D9U Drawbar Controller application sketch! The sketch below changes the drawbar settings for the Nord Electro 2. The Arduino on board the D9U sends a complete snapshot of all nine drawbar settings to the Electro 2 at start-up and whenever the tactile switch is depressed. Thereafter, it sends a MIDI message to the Electro 2 whenever a slider (drawbar) is changed.

The sketch drives only the Electro 2 upper drawbars. If you need the lower drawbars, too, you can follow Crumar’s example sketch and extend my sketch.

The sketch does not use the Arduino MIDI library because we only need to send simple MIDI continuous control (CC) messages. It’s easy enough to write the necessary code ourselves.

I encountered an Arduino compiler toolchain issue while developing the sketch. I wasn’t able to initialize snapCount in the setup() function. I’ll work around this issue in future sketches and you should back-port the fix. It’s not the first time that I’ve run into an Arduino toolchain bug…

The program logic is quite simple. There are three helper functions: sendNoteOn(), sendNoteOff(), and sendMidiCC(). The sketch uses only the third function which sends a MIDI continuous control message through the Serial1 port, i.e., the Arduino Leonardo TX pin.

The setup() function initializes the digital pins and global variables, and calls sendSnapshot() to scan the analog pins, sending a MIDI CC message for each drawbar. The idea is to sync the Electro 2 with the D9U when the D9U is turned on. You should select an organ voice on the Electro 2 before turning on the D9U in order to take advantage of this feature.

The loop() function goes round and round. If the tactile switch is depressed, the sketch takes a snapshot of the analog pins (sliders) and sends a MIDI CC message for each slider (drawbar). The variable snapCount debounces the tactile switch input, preventing a flood of MIDI CC messages to MIDI OUT and the Electro 2.

After checking the tactile switch, the loop() function delays for a short time and then calls checkSliders(). The function checkSliders() keeps a copy of the most recent slider values. When it detects a change, it saves the new slider value and sends a MIDI CC message with the new value. The Electro 2 accepts drawbar values over the range from 0 to 127.

It’s rather gratifying to attach the Crumar D9U to the Electro 2 and watch the Electro’s drawbar status lights change in sync with the D9U drawbars. Cool. Fun to play, too.

If you have a Nord Electro 2 and a D9U, enjoy the sketch!

Copyright © 2018 Paul J. Drongowski

/*
 * Electro2.ino: Crumar D9U sketch for Nord Electro 2
 */

/*
 * Author:  P.J. Drongowski
 * Address: http://sandsoftwaresound.net/
 * Date:    12 December 2018
 * Version: 1.0
 *
 * A simple sketch to control the Nord Electro 2 with the
 * Crumar D9U Drawbar Controller. This sketch controls
 * the upper drawbars, but could be extended to control
 * the lower drawbars. See the Crumar sketch for
 * inspiration!
 *
 * We assume a direct 5-pin MIDI connection from the
 * D9U to the Electro 2. Since direct MIDI is so simple,
 * the sketch does not use the Arduino MIDI library.
 * MIDI bytes are sent using Serial1.write().
 *
 * Send on MIDI CC messages on MIDI channel 0.
 *
 * Electro 2 MIDI continuous controllers (CC) are:
 *    Parameter       Upper CC#  Lower CC#
 *    --------------  ---------  ---------
 *    16' drawbar         16        70
 *    5 1/3' drawbar      17        71
 *    8' drawbar          18        72
 *    4' drawbar          19        73
 *    2 2/3' drawbar      20        74
 *    2' drawbar          21        75
 *    1 3/5' drawbar      22        76
 *    1 1/3' drawbar      23        77
 *    1' drawbar          24        78

 */

// Pin definitions
#define LED_RED    15
#define LED_GREEN  16
#define BUTTON     5

// Analog pin map
#define NUMBER_OF_SLIDERS 9
int AnalogPinMap[NUMBER_OF_SLIDERS] = {
  A0, A1, A2, A3, A6, A7, A8, A9, A10
} ;

// Drawbar to MIDI CC# map
int MidiCCMap[NUMBER_OF_SLIDERS] = {
  16, 17, 18, 19, 20, 21, 22, 23, 24
} ;

// Global variables
int sliders[NUMBER_OF_SLIDERS] ;
#define SNAP_COUNT  (200)
int snapCount = SNAP_COUNT ;

// MIDI channel
#define CHANNEL 0

// Bias offset for incoming slider values [unused]
#define BIAS 32

void sendNoteOn(byte pitch, byte velocity) {
  Serial1.write(0x90 | CHANNEL) ;
  Serial1.write(pitch) ;
  Serial1.write(velocity) ;
}

void sendNoteOff(byte pitch) {
  Serial1.write(0x80 | CHANNEL) ;
  Serial1.write(pitch) ;
  Serial1.write(0) ;
}

void sendMidiCC(byte cc, byte value) {
  Serial1.write(0xB0 | CHANNEL) ;
  Serial1.write(cc) ;
  Serial1.write(value) ;
}

// Take a snapshot of the current slider state and
// send MIDI CC for all sliders. Electro 2 CC value range
// is 0 to 127.
void sendSnapshot() {
  int newValue = 0 ;
  for (int i = 0 ; i < NUMBER_OF_SLIDERS ; i++) {
    newValue = (analogRead(AnalogPinMap[i]) & 0x3FF) / 8 ;
    sliders[i] = newValue ;
    sendMidiCC(MidiCCMap[i], newValue) ;
  }
}

// Check the sliders for movement (changes). When a change
// is detected, send a MIDI CC message. Nord Electro CC
// values range from 0 to 127.
void checkSliders() {
  int newValue = 0 ;
  for (int i = 0 ; i < NUMBER_OF_SLIDERS ; i++) {
    newValue = (analogRead(AnalogPinMap[i]) & 0x3FF) / 8 ;
    if (sliders[i] != newValue) {
      sliders[i] = newValue ;
      // Send MIDI CC message when the value changes
      sendMidiCC(MidiCCMap[i], newValue) ;
    }
  }
}
 
void setup() {
  // Set up pins
  pinMode(BUTTON, INPUT_PULLUP) ;
  pinMode(LED_RED, OUTPUT) ;
  pinMode(LED_GREEN, OUTPUT) ;

  // Set up Serial1 for MIDI via TX and RX (31,250 baud)
  Serial1.begin(31250) ;

  // Initialize the button debounce count
  // Send an initial snapshot. This operation initializes
  // the current slider values, too.
  sendSnapshot() ;
}

void loop() {
  if ((digitalRead(BUTTON) == LOW) && (snapCount <= 0))
  {
    // Take and send a snapshot of the sliders
    sendSnapshot() ;
    snapCount = SNAP_COUNT ;
  } else {
    snapCount-- ;
  }

  delay(1) ;
  checkSliders() ;
}

Crumar D9U: Testing MIDI (Part 4)

Apologies for the delay between posts. It isn’t for lack of enthusiasm for the Crumar D9U Drawbar Controller. It’s preparation for the approaching holidays.

Today’s post is another aspect of unit testing — MIDI. The D9U has a 3.5mm MIDI OUT jack. The MIDI signals conform to the MIDI “Type B” pin-out for 3.5mm jacks. The Type B pin-out is:

    DIN      3.5mm
    -----    --------------------
    Pin 4    Tip (Current Source)
    Pin 5    Ring (Current Sink)
    Pin 2    Sleeve (Shield) 

Type B is used by Arturia, Novation, and 1010Music.

I must note that the MIDI “Type A” pin-out is going to be the standard going forward. Unfortunately, the MIDI Association didn’t get ahead of manufacturers when they began using 3.5mm jacks. For reference, the Type A pin-out is:

    DIN      3.5mm
    -----    --------------------
    Pin 4    Ring (Current Source)
    Pin 5    Tip (Current Sink)
    Pin 2    Sleeve (Shield) 

Type A is used by Akai Pro, IK Multimedia, Korg, Line 6, littleBits, and Make Noise. I found the chart below to be quite helpful in running down an appropriate adapter cable. (Source: MIDI Association 3.5mm stereo TRS to MIDI 5-pin DIN cables)

Thanks to all of the Christmas prep, I didn’t miss a step while waiting for the 1010Music adapter to arrive. (It’s Advent after all.) I detest making cables and the 1010Music adapter is reasonably priced.

I also got down to work on a MIDI test sketch for the D9U. (Code appears at the end of this post.) The sketch does not use the Arduino MIDI library because it simply sends MIDI note ON and note OFF messages through the MIDI port.

If you’re new to Arduino Leonard — the D9U’s Pro Micro is a Leonardo — you may not know that Leonard has two serial ports: Serial and Serial1. The first port, Serial is dedicated to USB communications. The second port, Serial1, is dedicated to the digital RX and TX pins, similar to Arduino UNO, et al. The naming convention sometimes confuses coders who are new to Leonardo. In our case, when we want to send MIDI, we use the Serial1 port, which must be configured for the MIDI baud rate, 31,250Hz.

The sketch repeatedly sends MIDI note ON and OFF messages such that you should hear a steady series of staccato notes when the MIDI message stream is sent to a tone generator. In my case, I connected the D9U to my trusty Yamaha QY70 sequencer and tone module.

Here’s another little twist. Leonardo is equipped with two additional LEDs: TXLED and RXLED. These LEDs flash when there is transmit and receive activity (respectively) on the USB port. The test sketch does not use the USB port (Serial), so the TXLED and RXLED are ours to play with. The four macros:

    TXLED0 ;      RXLED0 ;
    TXLED1 ;      RXLED1 ;

control the LEDs. If you compile the sketch on a regular Arduino (e.g., UNO), these macros will be flagged as undefined symbols.

Extra credit

While wading through the Type A vs. Type B nonsense, I did a few simple experiments with the D9U’s MIDI port. For example, you can check the signal levels using a digital multimeter. DIN pin 2 should read as 0 Volts (ground) while DIN pin 4 should be +5 Volts. DIN pin 5 is the data pin which pulls the MIDI current loop to ground. Please remember that MIDI is a current loop where:

  • Logic 1 → High → no current flow → Opto-isolator LED off → MIDI receiver sees High, logic ‘1’ (data bits, stop bit or idle)
  • Logic 0 → Low → current loop flow rarr; Opto-isolator LED on → MIDI receiver sees Low, logic ‘0’ (data bits, start bit)

Thanks, Wikipedia.

The sender (MIDI OUT) turns an LED on and off in the receiver (MIDI IN). The LED is part of an opto-isolator which provides electrical isolation between the sender and the receiver.

So, if you want to check out MIDI signals at the pins, all you need is an LED and a current limiting resistor (e.g., 330 ohms) in series in the current loop. The LED lights when connected in the direction of positive current flow. Here are my handwritten notes.

David Battino would be proud. David loves to add flashing LED eyes to Japanese movie monster toys and more. One of these days I’ll put all of those Godzillas in our basement toy chest to work. 🙂

Copyright © 2018 Paul J. Drongowski

/*
 * MidiTest.ino: Crumar D9U MIDI and slider test
 */

/*
 * Author:  P.J. Drongowski
 * Address: http://sandsoftwaresound.net/
 * Date:    11 December 2018
 * Version: 1.0
 *
 * This test reads the current slider values. If there is a
 * change, it prints the current slider values to the Arduino
 * serial port. Watch the values change in the IDE's Serial
 * Monitor. The incoming slider values are biased so that
 * values range reliably from 0 to 8. (Leonarkdo's Serial
 * port is dedicated to USB communications.
 *
 * Additionally, send MIDI note ON and note OFF messages to
 * the Serial1 port. On Leonardo, Serial1 communicates via
 * the TX and RX pins.
 */

// Pin definitions
#define LED_RED    15
#define LED_GREEN  16
#define BUTTON     5

// Analog pin map
#define NUMBER_OF_SLIDERS 9
int AnalogPinMap[NUMBER_OF_SLIDERS] = {
  A0, A1, A2, A3, A6, A7, A8, A9, A10
} ;

// Global variables
int colorMode = 0 ;
int ledMode = 0 ;
int noteState = 0 ;
int sliders[NUMBER_OF_SLIDERS] ;

// Bias offset for incoming slider values
#define BIAS 32

void sendNoteOn() {
  Serial1.write(0x90) ;
  Serial1.write(36) ;
  Serial1.write(100) ;
}

void sendNoteOff() {
  Serial1.write(0x90) ;
  Serial1.write(36) ;
  Serial1.write(0) ;
}

void changeColors() {
  if (colorMode) {
    digitalWrite(LED_RED, LOW) ;
    digitalWrite(LED_GREEN, HIGH) ;
  } else {
    digitalWrite(LED_RED, HIGH) ;
    digitalWrite(LED_GREEN, LOW) ;
  }
}

void printSliders() {
  for (int i = 0 ; i < NUMBER_OF_SLIDERS ; i++) {
    Serial.print(sliders[i]) ;
    Serial.print(" ") ;
  }
  Serial.println("") ;
}

void checkSliders() {
  int changeFlag = 0 ;
  int newValue = 0 ;
  for (int i = 0 ; i < NUMBER_OF_SLIDERS ; i++) {
    newValue = (analogRead(AnalogPinMap[i]) + BIAS ) / 128 ;
    if (sliders[i] != newValue) {
      changeFlag = 1 ; 
      sliders[i] = newValue ;
    }
  }
  if (changeFlag != 0) {
    // If a change was made, print current slider values
    printSliders() ;
  }
}
 
void setup() {
  // Set up pins
  pinMode(BUTTON, INPUT_PULLUP) ;
  pinMode(LED_RED, OUTPUT) ;
  pinMode(LED_GREEN, OUTPUT) ;

  // Set up Serial1 for MIDI via TX and RX (31,250 baud)
  Serial1.begin(31250) ;

  colorMode = 0 ;
  noteState = 0 ;

  for (int i = 0 ; i < NUMBER_OF_SLIDERS ; i++) {
    sliders[i] = -1 ;
  }
}

void loop() {
  if (digitalRead(BUTTON) == LOW) {
    colorMode = 0 ;
  } else {
    colorMode = 1 ;
  }

  // Make the TX and RX LEDs flash in sync with the notes.
  // The TX and RX LEDs are Leonardo only. Remove the code
  // below when compiling for Arduino UNO, etc.
  if (ledMode) {
    ledMode = 0 ;
    TXLED1 ;
    RXLED0 ;    
  } else {
    ledMode = 1 ;
    TXLED0 ;
    RXLED1 ;
  }
  
  if (noteState != 0) {
    sendNoteOn() ;
    noteState = 0 ;
  } else {
    sendNoteOff() ;
    noteState = 1 ;
  }

  delay(100) ;
  changeColors() ;
  checkSliders() ;
}

Crumar D9U: What went wrong? (Day 3)

People who build stuff are optimists. Even just a little.

After slaving over a hot soldering iron (or bit of code), there comes the moment of truth. Of course, we all hope and believe that everything will run just fine when power is turned on.

Thus, I was a little bit bummed when I ran my drawbar test sketch (Arduino program) and saw that the second drawbar was unresponsive.

Hey, PJ, how did you debug and fix this thing?

First and foremost, I want to emphasize the importance of diagnostic tests. My test sketch told me conclusively that the second drawbar was busted. The test not only said, “Houston, we have a problem,” but the test also told me where to look for the problem — the second drawbar. Explicit testing is much better than trying to test and debug hardware with the application sketch itself, i.e., the sample sketch provided by Crumar.

Knowing that the second drawbar was bunged, I whipped out my digital multimeter and did a few simple electrical tests. I usually assume good components, but it was easy to check the second slide pot. Yep, the meter read out the expected resistance. Then I did quick continuity and resistance checks back to the appropriate Arduino analog pin. Thank heavens for the sample sketch because I quickly worked out the pin map (Arduino Pro Micro):

          TX o    o RAW
          RX o    o GND
         GND o    o RST
         GND o    o VCC
         SDA o    o A3    Draw4
         SCL o    o A2    Draw3
  Draw5   A6 o    o A1    Draw2  <---
             o    o A0    Draw1
  Draw6   A7 o    o SCLK
             o    o MISO
  Draw7   A8 o    o MOSI
  Draw8   A9 o    o A10   Draw9

I numbered the drawbars (left to right) starting with one. The Crumar schematics numbers the drawbars from zero. [Oh, well.]

This was a good time to check the batteries in the multimeter. Whoops, 2017. Good, fair or poor, I replaced the batteries with fresh ones.

I didn't find anything out of the ordinary, so I began the usual prayer, "Dear Lord, I hope I didn't blowed up the chip." I did not relish the thought of replacing the Arduino Pro Micro -- all 24 pins of it.

My soldering skills are good, but not perfect. Plus, the large holes and the excessive amount of solder consumed by the slide pot leads immediately made me suspect a bad soldering joint.

In order to test this theory, I tried jumpering the voltage from the first drawbar slider to the Arduino A1 pin while watching the sketch's output in the IDE Serial Monitor. Perhaps an internal pull-up (or something) didn't change the A1 signal or the output from the sketch.

Then it was time to play "which of these isn't like the others" with the multimeter and with the power on. Ah-ha. The voltage at the SIGN #2 pad did not change when sliding the pot to a new position. The rest of the SIGN pads responded correctly. Not conclusive evidence for a bad solder joint, but more hope than a blown up Arduino.

The next step was to fire up the iron and retouch the pot leads for the second drawbar. It takes longer for the iron to heat up than to do the touch up. Damn, these leads suck down solder.

After letting things cool, I plugged the Arduino back in and voila, the second drawbar now responds correctly. Thank you, test sketch.

When testing pot resistance, I noted some variability in resistance across the 9 pots. I hope the variability doesn't affect behavior when I get down to transmitting MIDI values. Maybe everything will act like a well-worn B3? Sometimes higher resistance is due to a marginal solder joint, but I'm not anxious to touch up every pot connection lest I introduce a worse problem. More testing ahead.

If you landed here, check out Day One in this series of blog posts about the Crumar D9U Drawbar Controller kit.

Copyright © 2018 Paul J. Drongowski

Crumar D9U: Slip slidin’ (day 2)

Today I completed most of the remaining assembly of the Crumar D9U Drawbar Controller. The work entailed:

  1. Combining the Arduino control board and the main PCB.
  2. Installing the drawbar slide pots on the bottom of the chassis.
  3. Soldering the main PCB to the slide pots and soldering the DIL connections to the Arduino control board.
  4. Installing colored plastic caps on the drawbars.

Overall, the work went well. Here’s a few observations and tips.

  • When the instructions say make the DIL flat and straight on the control board, they really mean it! The receiving holes on the main PCB are quite small and if that DIL isn’t straight, good luck. Even with a straight DIL, it took some finagling to pass the pins through the holes.
  • The control board and main PCB are joined by two long-ish bolts with spacers between the boards. The nuts are really tight. You will not be able to hold the nuts in place with fingers alone. I used needle nose pliers to hold the nuts while turning the bolts. Be careful not to damage the Arduino when using the pliers. I did bend a pin.
  • Experience with the main PCB and the slider pins was similar although these holes are larger and more accommodating. Gently straighten any bent pins.
  • Speaking of large holes, crimp the pot leads against the main PCB pads to make good electrical contact. These holes eat solder like crazy. You should rely on the solder to maintain electrical contact, not to be the electrical bridge itself.
  • The colored caps fit OK, but you will need to use a far bit of force to drive the screws into the caps for a firm result. The white knobs still have a tiny amount of play, but I was afraid to over-tighten the screws and strip the plastic.

The D9U is built like a warship although the tight fit of nuts and screws makes for a slightly stressful assembly job.

I forget to suggest one tip in yesterday’s blog post. If you have a breadboard available, it makes a nice jig for installing DILs and other components that you need to keep straight. Push the DIL into the breadboard, lay the board on top, and then solder away. I usually try to tack one or two corners first and then check for straightness, etc. If the DIL ain’t straight, it’s a lot easier to remove the tack from two pins (using a solder sucker or braided copper tape) than to remove solder from all 16 pins!

See my first blog post about the D9U for pictures of the pieces and parts in the kit.

Slider test sketch

Here is the code for a quick slider test. It prints the slider values to the Arduino IDE’s Serial Monitor. This sketch is already earning its keep — the second drawbar slider is not changing. The other eight sliders are changing just fine. I have some hardware debugging to do!

/*
 * SliderTest.ino: Crumar D9U initial test
 */

/*
 * Author:  P.J. Drongowski
 * Address: http://sandsoftwaresound.net/
 * Date:    7 December 2018
 * Version: 1.0
 *
 * This test reads the current slider values. If there is a
 * change, it prints the current slider values to the Arduino
 * serial port. Watch the values change in the IDE's Serial
 * Monitor.
 */

// Pin definitions
#define LED_RED    15
#define LED_GREEN  16
#define BUTTON     5

// Analog pin map
#define NUMBER_OF_SLIDERS 9
int AnalogPinMap[NUMBER_OF_SLIDERS] = {
  A0, A1, A2, A3, A6, A7, A8, A9, A10
} ;

// Global variables
int colorMode = 0 ;
int sliders[NUMBER_OF_SLIDERS] ;

void changeColors() {
  if (colorMode) {
    digitalWrite(LED_RED, LOW) ;
    digitalWrite(LED_GREEN, HIGH) ;
  } else {
    digitalWrite(LED_RED, HIGH) ;
    digitalWrite(LED_GREEN, LOW) ;
  }
}

void printSliders() {
  for (int i = 0 ; i < NUMBER_OF_SLIDERS ; i++) {
    Serial.print(sliders[i]) ;
    Serial.print(" ") ;
  }
  Serial.println("") ;
}

void checkSliders() {
  int changeFlag = 0 ;
  int newValue = 0 ;
  for (int i = 0 ; i < NUMBER_OF_SLIDERS ; i++) {
    newValue = analogRead(AnalogPinMap[i]) / 128 ;
    if (sliders[i] != newValue) {
      changeFlag = 1 ; 
      sliders[i] = newValue ;
    }
  }
  if (changeFlag != 0) {
    // If a change was made, print current slider values
    printSliders() ;
  }
}
 
void setup() {
  // Set up pins
  pinMode(BUTTON, INPUT_PULLUP) ;
  pinMode(LED_RED, OUTPUT) ;
  pinMode(LED_GREEN, OUTPUT) ;

  colorMode = 0 ;

  for (int i = 0 ; i < NUMBER_OF_SLIDERS ; i++) {
    sliders[i] = -1 ;
  }
}

void loop() {
  if (digitalRead(BUTTON) == LOW)
  {
    colorMode = 0 ;
  } else {
    colorMode = 1 ;
  }

  delay(100) ;
  changeColors() ;
  checkSliders() ;
}

Copyright © 2018 Paul J. Drongowski

Crumar D9U: Day one

This time of year, the Sun is low in the sky and its morning rays shine bright in the dining room, AKA my downstairs work area. The morning sunlight is perfect for close-in soldering.

I started to assemble the Crumar D9U Drawbar Controller today. Wow, the pads are small, so if you’re following my lead and building the D9U kit, be sure to use a small soldering tip and low wattage iron.

Assembly instructions and schematic are available on the Crumar D9U Web page.

Here’s a few quick observations.

  • One needs to bend the resistor leads quite close to the resistor body in order to fit them to the PCB holes. Be prepared for close work. Snip the leads as you go; don’t try to snip everything at the end. The pad spacing is that small.
  • The assembly instructions note the correct placement (polarity) of the LEDs. Please also note that the short lead is also denoted by a flat edge along the side of the LED plastic. Be double sure of polarity.
  • The DIL strip as shipped is actually two 1×8 strips. I prefer DIL when possible, so I substituted a 2×8 DIL from my component larder. It is much easier to mount a DIL than two 1x8s. I use a small bit of masking tape (painter’s tape) to hold the DIL in place until I can tack one or two pins.
  • Fortunately, the SIL terminals were pre-installed on the Arduino Pro Micro. Sometimes ya lose and sometimes ya win!
  • Crimp component leads to hold components against the PCB before soldering. This helps electrical contact between the leads and the PCB as well as holding the components in place while soldering.

Check the solder joints using a magnifying glass. Each joint should be nice and shiny. The morning sun helps — a lot.

DIY coders: Read this!

If you intend to write your own code, be sure to read the description of the sample Arduino script. You’ll find this info at the end of the assembly instructions. Be sure to read the fine print!

The sample script uses the USBMidi library and turns the D9U into a MIDI class-compliant USB controller.If you compile and download the script to the Arduino, Windows (or MacOS) will henceforth recognize the D9U as a MIDI device, not an Arduino.

Further complicating things, that tactile switch is not a reset switch. In order to reset the Arduino, you must short the reset pin to ground as shown in the instructions. Reset gives you a short window in which to download a new Arduino script.

Man, I’m glad that I read this now. I do not intend to use the D9U as a MIDI class-compliant device. I want to use it as a 5-pin MIDI controller. Plus, I know that I need to construct custom scripts for the Yamaha Genos/PSR and MODX. Development always involves trial and error (AKA “implementation and testing”). I don’t want to constantly reset the Arduino just to download a new script.

The lights are on

Once I assembled the Arduino control board, I downloaded the latest Arduino Integrated Development Environment (IDE v1.8.8) and wrote a quick test script. (See code below.) The script toggles the LEDs on and off using the tactile switch. Yep, the Arduino is an “Arduino Leonardo” board.

Next stop: Mounting the control board and the drawbars.

BTW, I’m not sure about the description of the MIDI 3.5mm jack cable wiring (“Type B”) as described in the instructions. Clearly, I’ll have to come to grips with the pin-out RSN.

Copyright © 2018 Paul J. Drongowski

/*
 * InitialTest.ino: Crumar D9U initial test
 */

/*
 * Author:  P.J. Drongowski
 * Address: http://sandsoftwaresound.net/
 * Date:    6 December 2018
 * Version: 1.0
 */

// Pin definitions
#define LED_RED    15
#define LED_GREEN  16
#define BUTTON     5

// Global variables
int colorMode = 0 ;

void changeColors()
{
  if (colorMode) {
    digitalWrite(LED_RED, LOW) ;
    digitalWrite(LED_GREEN, HIGH) ;
  } else {
    digitalWrite(LED_RED, HIGH) ;
    digitalWrite(LED_GREEN, LOW) ;
  }
}
 
 void setup() {
  // Set up pins
  pinMode(BUTTON, INPUT_PULLUP) ;
  pinMode(LED_RED, OUTPUT) ;
  pinMode(LED_GREEN, OUTPUT) ;

  colorMode = 0 ;
}

void loop() {
  if (digitalRead(BUTTON) == LOW)
  {
    colorMode = 0 ;
  } else {
    colorMode = 1 ;
  }

  delay(1000) ;
  changeColors() ;
}

Crumar D9U in the house!

When I saw the Crumar D9U Drawbar Controller, I knew “Man, I have got to get one of these.” Und, I did.

In short, the D9U is an Arduino-based drawbar controller done right. It has nine real drawbars, a MIDI OUT mini-jack and is USB powered through the Arduino Pro Micro which provides the brains. Because it’s Arduino, it’s programmable. Yes, you can, will and should write your own sketches.

If you’re interested, I recommend downloading the ZIP file on the Crumar D9U page. The ZIP file contains assembly instructions, a sketch to get your coding started, and a schematic. The assembly instructions are top-notch.

I haven’t assembled the D9U yet, but here is a mock-up to show you what it will eventually look like. [Click on images to enlarge.]

Best yet, the entire unit is housed in a very sturdy metal case.

One of the biggest challenges in DIY is building or finding a suitable case for the finished project. The D9U case is hefty and gig-worthy. Honest to goodness, the case, the drawbars and the knobs are enough to justify an order (and the price).

I placed my order through My Rig Shop, which is located in Italy. Not to worry, fulfillment was excellent and took only a few days — quite good for an international order.

The pictures below show you just what you’ll get if you order the D9U kit.

If you don’t feel up to assembling the D9U, My Rig Shop also sells a fully assembled unit (at a higher price, of course).

Please stay tuned! I’ve been itching to build and the D9U arrived at just the right moment. Yamaha Genos™/PSR and Yamaha MODX will require custom sketches, but that is still far down the road. First, I need an up-and-running D9U.

The other big questions is “Where am I going to put the D9U when I play?” First things first.

Copyright © 2018 Paul J. Drongowski

MODX: Quick thoughts

The Yamaha synth folks recently posted an IdeaScale appeal for people willing to participate in a phone interview concerning Montage and synths. Fortunately, I was able to snag an interview slot.

Here’s just a few thoughts that are on my mind. I’m quite happy with both the MODX sound and user interface (UI) although I think there are a few ideas that they could take from the Yamaha Genos™ workstation.

First biggie. Both the Montage/MODX and Genos/PSR instruments would benefit from tighter integration and better direct support from Cubase, and especially, Cubasis. Quite a few users were upset when Yamaha dropped the relatively full featured Motif/MODX sequencer in favor of the Performance Recorder. The likely presumption is that most musicians will use a DAW instead of a built-in sequencer. Well, maybe Yamaha went to far for some users.

I’m not quite so bummed out about the Performance Recorder. But, I often get the impression that Steinberg and Cubase are marching in their own direction. When I spoke with Nithin Cherian at Music Expo Boston, he explained how Yamaha product groups need to come to Steinberg with requests in order to create the overall customer experience with a product. Perhaps it’s a matter of making requests to Steinberg? Yamaha have quite a good asset in Cubase and I’m surprised that it isn’t exploited more strategically across product lines.

Seems like Cubasis (yes, Cubasis) could be an important part of the solution for both synths and arrangers. [The arranger sequencer is showing its age and is sometimes difficult to work with.] Tight coupling with Montage/MODX could eliminate the need for a full-featured built-in sequencer. At the very least, users should be able to select Performances easily and to configure effects from Cubasis. It should be special to use a Yamaha synth or arranger via Cubasis (or Cubase, for that matter). The existing Montage/MODX UI covers much of the same territory as the old Motif/MOX iPad apps and that functionality doesn’t need to be duplicated.

Speaking of iPad (tablet-based) apps, Yamaha app development seems to be stalled. This is just a personal, subjective impression, of course. Mobile Music Sequencer has not been updated for Montage/MODX or Genos, for example. I understand that development resources (e.g., engineers) are limited, so maybe Cubasis is the right platform to invest in going forward?

BTW, when it comes to apps, I feel like there are too many islands and not enough bridges between islands. For example, I should be able to transfer a MIDI file developed in Cubasis to some other app without making a trip through iTunes or Dropbox.

Second biggie. The Montage/MODX Live Set concept, Scenes and Motion Control are wonderful tools for live performance. In a few cases, however, the flow on Genos is smoother than the synths. Here’s an example. Many musicians play in a single or duo with backing tracks. Currently, it takes several steps to select a Performance, load a WAV file, set the audio volume level, and start play back. This is a very streamlined flow on an arranger thanks to the arranger registration concept. I’d love to see Live Set buttons be extended in a similar way. [Arranger registrations get to be a dumping ground for parameters that rightfully belong in a Performance, so a careful separation of concerns/features is appropriate here.] Perhaps Live Set buttons can be extended to remember the path to an audio file on a USB flash drive and the initial volume setting? Then, a user can select a Performance and load an audio file in one button touch.

I prefer WAV audio for backing tracks. For the past 3 to 4 years, I produce the backing track on an arranger and then record (freeze) the track to WAV. It simply is soooooo much easier to massage commercial tracks on an XG-based arranger. Yamaha Musicsoft is my favorite source for commercial tracks.

Here are several smaller suggestions.

  1. The MODX doesn’t have the big bank of front panel selection buttons like Montage. The Live Set buttons are too small and sometimes the touch screen isn’t responsive enough during live performance. I’ve got to switch Performances in a hurry when I play. (Please don’t suggest a foot switch. 🙂 )
  2. The front panel buttons have a nice positive feel. I may experient with Live Set button layout such that I can use cursor buttons to change Performance on the fly.
  3. I compensate for the loss of selection buttons (somewhat) by using Scenes. The sound cuts out when switching scenes. [Maybe this is something I need to fix in my Scene programming.] I would love to have Scene titles (i.e., a text name in a 24-point font) that is displayed on the screen — positive visual feedback that I’ve selected the correct Scene.
  4. The placement of some fields on control assignment pages is confusing. Usually I think of source first sending to a destination. Plus, I always mistake the control filter fields for actual parameter fields.
  5. Control Assign makes it very easy to set up new control relationships. However, it takes a lot of effort to deconstruct (reverse engineer) existing control relationships and edit them.
  6. In Live Set, SHIFT+INC and SHIFT+DEC change the Live Set page. This is a little awkward when making fast changes. Perhaps a way to change the page which doesn’t require SHIFT?

Third biggie. Sound.

Montage/MODX sound quality is excellent. What can be done to make it better?

It would be great if the Montage/MODX adopted Articulation Element Modeling (AKA Super Articulation 2). I realize that it may be difficult to fully edit AEM through the synth UI. Maybe a computer-based application? I love AEM/SArt2 on Genos.

With respect to articulations (and control), here’s two wild ideas:

  1. In addition to assignable buttons for articulation control, add key switching similar to what’s found in VST-land.
  2. Allow user scripting. What else is a synth, but a MIDI controller and a tone generator. Why not make MIDI control programmable through user scripts?

To my ears, Yamaha have clearly invested effort in B-3 organ and rotary speaker emulation. However, musicians on both synth and arranger forums still regard the Neo Instruments Vent II as the “gold standard” for rotary speaker emulation. If the next Montage is to be a clone-killer, it needs to beat the Vent II. [Will Yamaha exploit U.S. Patent 9,899,016?]

I would love to take a MODX Performance and automatically turn it into a Genos voice. Yeah, probably isn’t a problem for the synth people to solve. However, the voice editing in Yamaha Expansion Manager (YEM) really, really lags.

Fourth biggie. Sequencing multi-part Performances via MIDI.

I’m sure you’ve heard this one before. 🙂 I haven’t deep dived MODX sequencing (yet), but I understand there is an issue with sequencing multi-part Performances from a DAW. Perhaps the solution is a map from MIDI channel to one-or-more Parts? This solution breaks the hard binding between MIDI channel and Part.

Final Biggie. People love getting updates! Updates are truly a hit with the user base — including me. 🙂 Social media forums always chatter about the next update and updates are a great way to create continuing interest in Montage/MODX. Please keep the updates coming!

Whew! A longer and discussion than I thought! None-the-less, I really enjoy the MODX. It’s light weight and sound make it a terrific gig machine.

P.S. The last time I participated in an interview, I wrote an MOX retrospective. It describes some of my use cases, flow and general concerns.

MODX: Sampling Genos pipe organ

Sample Robot for Montage (SRM) is a very useful addition to the Yamaha MODX (Montage) product ecosystem. After my initial start-up experience:

I went on to produce two sampled pipe organ voices: Organ Prinzipal and Organ Pleno.

Prinzipal and Pleno

Anyone who sees a pipe organ — especially a cathedral-sized instrument — is immediately impressed by its large array of pipes. The open metal pipes are the principal pipes which give a pipe organ its distinctive sound. Pipes are arranged in ranks, kind of like the individual drawbars on a Hammond B3 organ (vice versa, really!) Hammond-ites know that the length of a pipe determines its pitch and that each rank has a reference pitch (measured in feet) that specifies the rank’s harmonic character when blended with other ranks.

I generally use pipe organ to lead congregational singing. Conventional wisdom for hymn accompaniment is simple: Use principal pipes with simple, foundational pitch: 8′, 4′ and 2′. Although this sounds plain vanilla, the sound is not cluttered by harmonics that may confuse the congregational ear. This kind of organ registration is often called a “principal chorus.” Due to the deep history of pipe organ in Western Europe, a French, German or Italian name may be used instead, e.g., “Prinzipal.”

Old school players understood the need to built energy and drama during a tune, too. Thus, an organist might add non-fundamental harmonics during the final verse and chorus. Think, Hammand organ “whistle”, 1 3/5′, 1 2/3′, etc. Often, a group of such ranks is brought in, a “mixture.” If the mixture consist of principal pipes, then the resulting registration is called a “full principal chorus.” This registration has many names, too, such as “Organo Pleno” or “Plein Jeu.”

In case you’re wondering, reed stops are rarely used for hymn accompaniment, if ever. Flute pipes are occasionally added for quiet meditative hymns. Principals are the real work horses.

Yamaha Musicsoft offers a terrific PSR expansion pack: Church Organ. Someone put a lot of love and care into this pack! I bought a PSR-S950 based upon the strength of the Church Organ pack. Fortunately, the PSR-S970 version of the pack also loads on Yamaha Genos™ and I’ve been able to take advantage of its sounds for practice and live play.

My goal here is to sample the Organ Prinzipal and Organ Pleno voices on Genos and to use those voices on MODX.

Sample, test, repeat

Sampling with SRM is reasonably straightforward. If you read my previous blog posts, then you already have the general drift. I recommend reading the SRM manual, too.

I liked the sampling strategy and key layout used in the Apple Symphony Orchestra pipe organs and arrived at a planned layout of keybanks:

KB#  Low  High  Center
---  ---  ----  ------
 1    C-2  C#0      C0
 2    D0    E0     D#0
 3    F0    G0     F#0
 4   G#0   A#0      A0
 5    B0   C#1      C1
 6    D1    E1     D#1
 7    F1    G1     F#1
 8   G#1   A#1      A1
 9    B1   C#2      C2
10    D2    E2     D#2
11    F2    G2     F#2
12   G#2   A#2      A2
13    B2   C#3      C3
14    D3    E3     D#3
15    F3    G3     F#3
16   G#3   A#3      A3
17    B3   C#4      C4
18    D4    E4     D#4
19    F4    G4     F#4
20   G#4   A#4      A4
21    B4   C#5      C5
22    D5    E5     D#5
23    F5    G8     F#5

In Sample Robot concepts, this means starting at C0 (MIDI note number 24) and sampling every three semi-tone steps up to C5 (MIDI note number 84). With the exception of the lowest and highest note, a sample is never transposed (pitch shifted) more than a single semi-tone. I also liked the long sample time in the Apple approach and settled on a 12 second capture time plus 0.5 seconds release (12.5 seconds total of capture). I didn’t use the release samples, but I wanted to see and hear them as a learning experience.

If you change the MIDI note range or step number in SRM, be sure to click the Step button! I got hung up and couldn’t figure out why SRM didn’t “see” new note range limits. This really should be mentioned prominently in the SRM manual. I assumed that SRM would simply take what it was given…

These basic sampling parameters can be set using the SRM project wizard. Or, you can set them individually on the various property tabs. I went through the wizard first, then fine tuned individual parameters later.

The virtual keyboard at the bottom of the screen shows the notes to be sampled (black and white) and the notes for which samples have been taken (notes with a blue square). The dark grey notes are not sampled. [Click on images to enlarge.]

Before going further, I must state that I made several attempts at sampling each voice. I decided to retain the volume differences (level nuances) across the multisample. I turned Auto-gain OFF and set the audio input level manually. Thanks to the waveform display, I could find any obviously clipped sample. I also did a spot check of questionable samples in Sound Forge Studio. I eventually arrived at a set of samples for each voice in which one (or a few samples) were max’ed and the rest of the samples in the set fell in line as synthesized by Genos. I believe this strategy preserved the natural levels across the pipe organ key range.

Loop quality

I let SRM do the looping. I know from experience that looping pipe organ samples is not easy and is very time consuming. Plus, I wanted to see how well SRM would do.

The Display buttons below the waveform pane control waveform annotations. Enable the Loop button and SRM shows the loop in (start) and loop out (end) points for a sample. I used the default cross-fade loop settings as shown in the screenshot.

SRM’s loops sound decent. There are a few samples where a bit of a surge could be heard, but no obvious bumps or clicks. SRM’s loops are shorter than the Apple loops and that is a little disappointing. However, there aren’t any short cycle loops that lose the dynamic timbral quality of a pipe organ. I think they are all useable as they are without any manual tweaking. My opinion is based upon what I auditioned in SRM and what I heard at the MODX keyboard itself.

Normalization and gain change

Really good thinking went into this part of SRM. SRM gives you several options for normalizing or applying a gain factor across one or all of the samples in a project. (Please see the manual for details.)

Normalization works as expected. It applies a gain factor that brings up the an entire sample such that the peak is 0dB or a custom peak level which you set.

Gain change is just what I needed for this project. I wanted to maintain the relative difference in level between samples — just make everything uniformly louder without introducing clipping distortion. In order to do this, I needed to know the highest dB level for a group of samples then apply a gain factor everywhere to pull all samples up. SRM provides a few different options for finding the overall peak level, e.g., “Find highest dB Level in selected Project”. Suggested improvement to SRM: After analyzing the samples, SRM should display the peak level for each sample in the property pane along with the sample’s other properties.

I like the option “Warn if clipping will occur.” Features like normalization and gain change would make SRM quite useful and necessary even when starting out with old samples borrowed from a VST software instrument. 🙂

Export and import

I exported each voice as a Montage LIBRARY file (X7L) and loaded each LIBRARY file into MODX. One nice MODX feature is the ability to audition Performances in a Library. This is a quick way to sanity check new waveforms (and underlying samples) on MODX.

There were several iterations at this stage, too. It took a few iterations to get the desired key range for sampling. The initial key range was one octave too high. I like to have three octaves in the left hand and two octaves in the right hand for hymn accompaniment as I’m faking organ pedals in the left hand. I used MIDI OX to check the high and low MIDI note numbers, then I reset the lower and upper note sampling limits in SRM.

Thankfully, any and all iterations are fast. SRM can sample the entire key range in about 5 to 6 minutes with the chosen capture time for each sample (12.5 seconds). This is welcome and needed time to get a cup and give my ears a rest!

Finishing and sanding

The new waveform needs to be incorporated into a finished MODX Performance because the SRM-generated Performance in the Library file is very, very basic. (Actually basic is a good thing for quality assurance and auditioning.)

In one of my earlier experiments, I had fashioned a pipe organ Performance (Plein Jeu). I repurposed the Performance even though I had long since blown away the Plein Jeu waveform.

My process has (roughly) the following steps:

  1. Load the LIBRARY file generated by SRM.
  2. Audition the generated Performance in the Library.
  3. Import the generated Performance and its waveform into USER memory.
  4. Select and edit an existing Performance, hopefully one which is close to the desired result.
  5. Save the new Performance under a new name.
  6. Edit the effects or any other Performance Common parameters.
  7. Edit the Part information within the Performance.
  8. Edit the elements in the new Performance to use the new waveform.
  9. Edit the new waveform to change its name (category and subcategory), to extend the lower note limit of the lowest key bank, and to extend the upper note limit of the highest key bank.
  10. Make any other necessary tweaks to the new waveform.
  11. Make tweaks to the Element programming or effects.
  12. Save the new Performance.

Clearly, prior experience with Performance and Part editing is a real plus at this stage. Ramp up slowly! Gain experience. Rome wasn’t built in a day.

OK, get ready for TMI. When you load a library, MODX seems to load incoming waveforms into wave memory on a contingency basis. This is why you can audition new Performance waveforms in a library. You can even make a contingent waveform part of a USER Performance. If you haven’t explicitly imported the Library Performance and its (contingent) waveform from the Library and you delete the Library, kiss the waveform good-bye; it’s deleted, too.

When you’re ready to commit to a new waveform, you must explicitly import the parent Performance and the new waveform within to USER Memory via the Data Utility.

A few comments for the developers

Nice work! Here are a few refinements.

Please add the ability to directly monitor the incoming sample stream. It would greatly aid set up and we can listen for audible clipping distortion when setting levels.

Display the peak level in sample properties. This will make it easy to find samples which are (potentially) clipped.

The Project Datapath in the Preferences dialog does not seem to apply everywhere and it isn’t persistent i.e., it is reset to the path “C\Users\xxx\Documents\SKYLIFE\SampleRobot6\Data.” This file path should be used consistently.

A native English speaker should take a quick pass through the manual, which is already pretty darned good. There are occasional spelling and simple grammatical errors (e.g., possessive versus plural). The same reviewer should check the application for spelling errors; there are misspelled words.

The manual should inform the user to press the Step button after changing the MIDI note limits for sampling.

What’s next?

When I A/B’ed the expansion pack organs against the Apple Symphony Orchestra pipe organ, I had to give the quality edge to Apple. I’ve already snagged another voice from the Symphony Orchestra Jam Pack. At the very least, I’ll use Sample Robot for Montage to change gain, to layout the key banks and to generate a Montage LIBRARY file. It shines at these operations and really speeds up the work.

Copyright © 2018 Paul J. Drongowski

MODX: Going to the library

After resolving yesterday’s Sample Robot teething issues, I pulled together two new sampled pipe organ voices. Each voice is stored into its own MODX Library file as exported by Sample Robot for Montage (SRM).

At this point, I realized that libraries and voices are going to stack up quickly. So, I dipped into a few on-line resources:

Essentially, a MODX (or Montage) Library is a way to bundle up related Performances, waveforms, arpeggios and other data into a single package. Bundling makes it easy to save, distribute, and load Performance-related data.

Page 23 of the MODX Reference Manual contains a diagram depicting the contents of USER Memory and the relationship of USER Memory to USB flash drive file types like USER files and LIBRARY files. This diagram and its accompanying text is meaningful to engineers, but is somewhat confusing to a regular user who wants to get a job done! Diagram aside, it’s worth noting that there are two main file types that are important to our data management: USER files and LIBRARY files. Each file type has its own file name extension:

                  Montage  MODX
                  -------  ----
    USER file        .X7U  .X8U
    LIBRARY file     .X7L  .X8L

Yamaha have continued their practice of bumping the file format version number with each new generation of synth. Thus, the MODX USER file extension is “.X8U” versus Montage’s “.X7U”. I won’t distract you with compatibility details except to note that MODX can load Montage USER and LIBRARY files. Good thing since Sample Robot exports Montage USER and LIBRARY files (.X7U and .X7L).

There are two primary file operations:

    LOAD: [UTILITY] → [Contents] → [Load]
    STORE/SAVE: Press [STORE] button, or 
                [UTILITY] → [Contents] → [Store/Save]

I think of USER Memory as working storage that holds my most frequently used Performances (and other stuff). It’s important to stay backed up, especially when working with a new keyboard. I back up daily, writing USER memory to a USER file. It’s not that the data is so important — I can’t afford lost time. Lost data is lost time.

A USER file contains:

    User Performance (640 max)
    User Arpeggio (256 max)
    User Motion Sequence
    User Curve
    User Live Set
    User Micro Tuning
    User Waveform
    Utility Settings
    Quick Setup
    User Audition Phrase

That’s pretty much the whole ball of wax from USER Memory — a complete snapshot.

A LIBRARY file is similar to a USER file. A LIBRARY file contains:

    Performance (640 max)
    Arpeggio (256 max)
    Motion Sequence
    Curve
    Live Set
    Micro Tuning
    Waveform
    Audition Phrase

A Library doesn’t contain Utility Settings or Quick Setup data. You wouldn’t want a Library to disturb these settings when it’s loaded.

What’s a little confusing about the USER Memory diagram is that it shows (eight) Libraries as part of USER Memory. Maybe it’s better to think of USER Memory as “Internal Memory”. By the way, some writers refer to this memory as “read only,” kind of, sort of. The correct term is “non-volatile,” i.e., memory contents aren’t lost when power is turned off. This terminology gets around writer-ly semantic problems. Internal memory can be read and written. It just doesn’t lose its mind when power is removed.

A LIBRARY file, since it’s a file, can be loaded and saved. During a load operation, the contents of a library is written (stored) into one of the eight available library slots in USER Memory. The contents of the USER Performances, etc. in USER Memory are not over-written. From my point of view, this is great because I don’t want anything messing with my work! We can, however, save User data to a LIBRARY file.

The final piece of the puzzle is how to bring selected pieces of a memory-resident Library into USER Memory. That’s where Library import comes into play:

    [UTILITY] → [Contents] → [Library Import]

The Import to User Bank operation:

Copies the selected Performance in the User Bank. User Waveforms and User Arpeggio which are used in the selected Performance are copied to the User Bank as well. This button is displayed only when any of the Performances is selected.

Reading this last sentence from the MODX Reference Manual rang a bell in my head.

When I auditioned my first attempt at a pipe organ voice, I loaded the library generated by Sample Robot, but did not import the Performance. I even created a User Performance that referred to the new waveform and it played perfectly. However, was the new waveform really in USER Memory? No. I deleted the Library from USER Memory and the waveform disappeared, too. The User Performance which once referred to the waveform did not sound anymore. Edit revealed an empty space in the voice Element which once referred to the new waveform.

Actually, this is quite good behavior. In order to quickly audition new waveforms produced by Sample Robot, I just need to load the Library file with the new waveform. If I don’t like the sound, I can easily destroy the evidence by deleting the library from its slot in USER Memory. If I like the sound, then I can import the performance from the library to the USER Bank and build on top of the new waveform.

I’m glad that I undertook this experiment before going further. I want to keep the Principal 8′, 4′, 2′ waveform and Performance, and I want to audition any new waveforms without disturbing my earlier work. With load, save and import in mind, I think I see the way forward.

Copyright © 2018 Paul J. Drongowski

Here are a few helpful notes from the YamahaSynth.com site. Special thanks for to Phil Clendeninn and Jason!

A Library file can be loaded without overwriting your USER AREA. A Library file can install data into one of eight LIBRARY locations in your Montage/MODX.

When you place something in a Library location it’s there with everything it needs to be played (just like your Preset data always has everything it needs). But, you can rewrite this, later, if you change your mind or wish to add to it!

To create a LIBRARY you must assemble what you wish to place in that Library into your USER area. From the USER area you can SAVE as a “Library File” — this creates a .X7L file on your USB stick. Once you have that file, you can then install it to one of 8 Library locations.

You can then audition the sounds, decide which ones you think are “keepers”. The ones you want to keep you can IMPORT to USER. Why would you want to import them into USER? Because you assemble the data that you want to keep and then create your own custom library.

You can delete unwanted Libraries by entering the Library folder, select an item, tap “Delete”.

You can assemble data from a Library by using the “Import Library” function (Montage version 1.10 and later): UTILITY → Contents → Library Import

Each library can only be changed in its entirety. You cannot delete individual performances within a library – you can only delete the
entire library. You cannot add one Performance to an existing library. Libraries can only be installed, deleted, or created. Libraries cannot be edited on MODX.

The Library Banks contain the Performances you have added as Libraries. The Library Banks are initially empty. (A Library can be added by importing a library file.)

  1. Install library to a library slot (the one you want to add to)
  2. Backup then clear the user area so it is empty
  3. Create the one user Performance you want to add to the library (eventually) in the user area. The user area now has one Performance you want to add to the installed library.
  4. Import the entire Library you installed in step 1 to the user area. The act of “import” does not overwrite the user area. It will make sure all necessary content in the library, including custom waveforms, are copied (imported) into the user area.
  5. Create a new library from the user area. This new library will be the original one plus the one (in this example) user Performance you wanted to add.
  6. Delete the previous library
  7. Install the new library

MODX: Get started with Sample Robot

In my last post, I created a new Yamaha MODX Performance from a handful of WAV files. The new Performance had shortcomings, mainly due to short loops in the samples themselves. I tossed the first one away. What the heck — it’s only bits. 🙂

Last time, I did all of the work on the MODX itself through its user interface (UI). My experience was generally good, but I had to enter a lot of detail directly into the UI. Today, I’m moving on to Sample Robot for Montage with hopes of making the job easier.

Sample Robot by SKYLIFE is a spiffy tool for copping sounds from old keyboards or any other sound source. Yamaha formed a parnership with SKYLIFE resulting in Sample Robot for Montage, a version of Sample Robot that is tailor-made for Montage (and MODX).

Even though Sample Robot for Montage — which I will refer to as “SRM” — has the ability to capture multisamples automatically from MIDI keyboards, it has two other capabilities of immediate interest and purpose:

  1. SRM can import WAV/AIFF files into a multisample.
  2. SRM exports the finished result as a Montage User file (X7U) or a Montage Library file (X7L). MODX loads both of these file types.

Thus, SRM looks to be and is a promising path for creating new MODX Performances from existing WAV/AIFF files.

At this point, I must admit that I’m still getting my head around the Montage/MODX library concept. [This subject receives scant space in the documentation, unfortunately.] Thanks to Phil’s tutorials on YamahaSynth.com, I grok their basic purpose — to bundle related Performances, waveforms, arpeggios, etc. into an easily distributed and imported package. I have much to learn about this subject especially how to exploit Montage/MODX libraries for data management during sound development. More about this some day.

Sample Robot for Montage: Set-up

I downloaded SRM from the Yamaha Musicsoft site. SRM is free to Montage (and, apparently, MODX owners) until March 2019. I can’t argue with the price!

The download is a ZIP file containing both the Windows and Macintosh versions of SRM. The Musicsoft site provides a Yamaha code number and a serial number, both of which are required for activation. Rikki don’t lose that number. 🙂

Install is easy — just click through the installation wizard. The Windows installer is about 200MBytes, the bulk of which are example projects.

You will be asked to activate after launching SRM for the first time. Enter all of the magic numbers. SRM starts up with a preloaded example. I peeked and poked at the example for a little while and quickly discovered that an audio device wasn’t assigned. I eventually settled on “Microsoft Sound Mapper – Output”. Unfortunately, Windows 7 ran that damnable audiodg (Audio Device Graph Isolation) process, taking a long time to complete. Further, I had to restart SRM before getting audio through the monitors. I can’t fault SRM for this. Microsoft? Hello, it’s 2018?

Upon start-up, SRM displays a wizard leading you through the task of setting essential project characteristics like sample rate and such. In a moment of hubris, I cancelled the wizard the first time through and found the app to be somewhat inert. Me-thinks SRM needs to initialize its environment and clicking through the start-up wizard at least once does the trick.

SRM: The warm-up

I strongly recommend a quick read through the SRM manual for no other reason than to become familiar with its concepts and terminology. The terminology is fairly standard, but it differs a bit from Montage/MODX terminology. For example, it appears that your SRM “multisamples” will become Yamaha waveforms and inherit multisample names. This is where familiarity will breed expertise, I expect.

I also suggest taking a tour around the SRM user interface. The “Info and Settings” pane is a property inspector that shows important properties for the selected project, multisample or sample. Then, check out the virtual keyboard. With a two button mouse, left clicking/holding a key plays the sample associated with the note. (Notes with a blue box marker have a sample assigned.) Right clicking a key selects the sample associated with the key.

The Osc, Wav, MIDI and Panic radio buttons seem to choose what the virtual keyboard sends and does. Try Osc and you’ll hear a pure reference tone at the selected pitch — a good feature when working with pitched multisamples. I don’t know about you, but my sense of pitch goes all whack after 30 minutes or so of intense work.

Today’s protein on the plate

I dug another old chestnut out of my hoard of pipe organ samples. Apple’s Symphony Orchestra Jam Pack (a blast from the past, eh?) has several mighty fine church organ patches. Even though it’s Garageband, the church organ is an EXS24 virtual instrument. If you know where to look, you can find the samples and you can play/inspect the virtual instrument in Logic via EXS24.

Apple licensed pretty decent samples. I once tried to determine their original source and vaguely remember Sonic Reality. Others thought VSL lite (circa 2003). Association with Garageband unfairly cheapened their reputation.

The samples are taken from three principal ranks (8′, 4′ and 2′) in unison. Without deep diving organ registration, a voice consisting of principals is good for hymn accompaniment. [Principals, BTW, are the metal pipes that give a pipe organ its distinctive timbre.] Thanks to the even footages, there aren’t a lot of weird harmonics to clutter up the sound.

A Dave Stewart moment. Many synthesizer pipe organ patches are reedy. They want to impress the buyer with bombast (i.e., “Phantom of the Opera” AKA Bach’s Toccata and Fugue in D minor). Reeds and strings are inappropriate for hymn accompaniment. Flutes, sometimes. Pure tones, pure tones.

Here is a table summarizing the sample files:

KB#  Low  High  Center  File
---  ---  ----  ------  -----------------------
 1   C-2   C#1      C1  Prin_842_kb1_c1.aif
 2    D1    E1     D#1  Prin_842_kb2_d#1.aif
 3    F1    G1     F#1  Prin_842_kb3_f#1.aif
 4   G#1   A#1      A1  Prin_842_kb4_a1.aif
 5    B1   C#2      C2  Prin_842_kb5_c2.aif
 6    D2    E2     D#2  Prin_842_kb6_d#2.aif
 7    F2    G2     F#2  Prin_842_kb7_f#2.aif
 8   G#2   A#2      A2  Prin_842_kb8_a2.aif
 9    B2   C#3      C3  Prin_842_kb9_c3.aif
10    D3    E3     D#3  Prin_842_kb10_d#3.aif
11    F3    G3     F#3  Prin_842_kb11_f#3.aif
12   G#3   A#3      A3  Prin_842_kb12_a3.aif
13    B3   C#4      C4  Prin_842_kb13_c4.aif
14    D4    E4     D#4  Prin_842_kb14_d#4.aif
15    F4    G4     F#4  Prin_842_kb15_f#4.aif
16   G#4   A#4      A4  Prin_842_kb16_a4.aif
17    B4   C#5      C5  Prin_842_kb17_c5.aif
18    D5    E5     D#5  Prin_842_kb18_d#5.aif
19    F5    G8     F#5  Prin_842_kb19_f#5.aif

The note names (numbers) follow the Yamaha convention. This information was taken from Logic EXS24.

I did a little bit of prep work. I renamed the AIF files, putting the center note into standard form. I checked the samples in Yamaha Tiny Wave Editor (TWE) to see if they were looped. (They were.) I normalized the samples using TWE. Turns out, SRM can normalize and I could have accomplished this task in SRM instead.

The Apple samples are decent:

  • Stereo, 44100Hz, 16-bit
  • Nice long samples (12 to 19 seconds each)
  • Long loops, no audible bumps

This one has the potential to be a keeper.

SRM: Doing the business

Time to get down to business. I created a new project named “Principal842”. Please see the screenshot below. [Click images to enlarge.] I like SRM’s “Battle Zone” visual theme; it’s one of the few games that I still relate to.

Drop into the “Import/Export” menu, select the AIF files, click the Import button, and what the?

Admittedly, what came next were my most frustrating moments. I either imported one individual sample file or just the last sample file in the selected list. Arg! Long story short, it came down to finding the right combination of import settings.

The default Copy setting is “Copy to filenames’s Root Key (if available), else to filename’s Root Key”. Grammar issue aside (“filenames'” is grammatically correct), I tried “Copy to filenames’s Root Key” with success.

The first screenshot shows the state of the project after a successful import. The samples are laid out correctly across the keyboard as derived from the sample file names. Further, SRM did a smashing job with the keybank ranges.

With everything in order, dive into import/export and select Montage Library (X7L) format for export. I went with X7L instead of X7U (User format) because I didn’t want to overwrite my User area. Yes, I’m thoroughly backed up, but why take a chance. I also wanted to get my feet wet with libraries.

I copied the X7L file to a USB flash drive, inserted the flash drive into MODX and loaded the library file. The X7L Library file is sizeable due to the waveform inside. The library file has the name “Principal842”, same as the SRM project. The Library appears in Category Search under that name. SRM generated a basic Performance, too.

I tried the basic Performance and was satisfied with the raw material. I then dove into the left-over husk of yesterday’s abandoned experiment. The husk (Performance) began life as the “Church Organ” preset voice. I changed its waveform to the new one and made a few tweaks here and there. Voila! A decent pipe organ voice suitable for hymn accompaniment.

Sometimes a new waveform requires polish. The sample levels may be uneven across the keyboard or a sample may be out of tune. The MODX UI is well up to the job allowing tweaks for level and fine pitch.

I wanted to post the finished project. However, given the commercial origin of the samples (Apple), I don’t want to violate intellectual property (IP) rights. Instead, here’s a quick MPEG-4 demo (m4a).

Copyright © 2018 Paul J. Drongowski