Arduino project finished…

September 15, 2013 Leave a comment

The missing components turned up so I spent a day building the MIDI interface board. Figuring out where to place the various connectors and components on the prototyping board so that the connectors were not blocked by the sides of the box it would all live in was far harder than writing the code or designing the circuit. Once I had it all hooked up I tried it and…. nothing! Well, the switches worked as did the LEDs but I was not getting a MIDI signal out of the box, or if I was the other end was not detecting it. When I looked at the circuit for the commercial MIDI interface board I had it was a lot simpler than my over engineered effort so after some hesitation I ripped out the output circuit from my board and replaced it with a much simpler version based on the commercial units circuit (basically one wire and a couple of resistors, no transistors). Swapped over the output cables to account for the circuit changes and tried it…. nothing again!

Now  had been very careful about hooking up the output wires to the MIDI connector the right way around. Seems I was not careful enough! On a whim I swapped them and of course it worked. It was probably OK the first time, just the had the wires the wrong way round but at least it works now.

This is what the inside of the project looks like:


As you can see pretty cramped. The board you can see is the MIDI interface board I made. The Arduino is underneath that screwed to a piece of board that is then glues to the case to hold it in place and insulate it from the metal box.

I always think that it is a shame to hide all the electronics as so much effort goes into creating it. In some ways it’s like programming, you can put a lot of effort into making some code as elegant as possible but in the end, all people care about is ‘does it work’.

So with that in mind, this is what the completed project looks like:


The power switch is on the other side of the box but that’s it. The left button controls the bypass on the effects unit and the right button switches between two patches. The LEDs just indicate the current setting that is selected for each switch. All pretty simple.

Time to go play!

Categories: General Stuff Tags: ,

When projects collide…

September 12, 2013 Leave a comment

The iPhone/iPad app I am developing is for live music use (not giving away any details just yet since I am sure any reasonable iPhone developer could knock up the same app in a couple of days and beat me to the finish line!) which means your hands are not so free. My original idea was to use a blue tooth connected foot pedal that I already happen to have (Airturn BT-105) to control the app. However it occurred to me that it would be pretty simple to add a blue tooth shield to an Arduino, hook up a few switches and make my own blue tooth enabled stomp box to control my app, plus I could have more than the two switches my current pedal has.

So, once the current Arduino project is done I’ll be starting on creating a blue tooth enabled stomp pedal to control this app and looking at blue tooth enabling my app to work with my custom pedal.

Categories: Coding, iPhone, xcode Tags: , , ,

Back to the iPhone project

September 11, 2013 Leave a comment

The Arduino project is on hold because I am waiting for parts to arrive which appear to be on a VERY slow boat from Thailand so I decided to get back to my iPhone project.

My iPhone app (which will be mainly an iPad app when it is done) currently has three view controllers. I guess you can think of these as logical screens. Each one has it’s own implementation file (class) and when I originally wrote things, just to get it all going I used a lot of global variables to share data between the view controllers. This got messy really quickly so I’ve been reworking the code over the past couple of weeks to get rid of the global variables and pass data between the view controllers the ‘proper’ way.

I also need to make the app support device rotation as well as both iPhone and iPad devices so for no particular reason I chose to attack the device rotation topic first. So far it is proving to be an interesting challenge to make all my view controllers  work correctly since only the currently displayed VC receives the orientation change messages so any hidden VC has to check the orientation when it is redisplayed and reconfigure the screen to match the current orientation. Let’s just say that this part of the project is still a ‘work in progress’!

I have managed to sketch out what I want the main interface to look like but all the current work is just to get to the point where I can actually implement the main app function and has nothing to do with the actual ‘guts’ of the app.

Oh, and now we have new devices (no doubt with new physical screen sizes) and a new OS to contend with as well.

Still, it keeps me off the streets at night!

Categories: Coding, iPhone Tags: , ,

Maintaining the OMEGAMON XE for CICS on z/OS Globals with PARMGEN

September 10, 2013 Leave a comment

Global settings selection

May aspects of the operation of OMEGAMON XE for CICS on z/OS data collection and operation are controlled by global settings. These settings are held in a PDS member of the library allocated to the RKC2GLBL DD in the ‘classic’ collector address space (also known as the OCCI). Typically the hlq.RKANPARU library is allocated to the RKC2GLBL DD

Global members have member names of the form KC2GLBxx where xx is a two character suffix. The global member to be used by the OCCI when monitoring a given CICS region is selected by including a KOCGLBxx dummy DD in the CICS startup JCL, where the xx in the DD name matches the suffix of a global member in the library allocated to the RK2GLBL DD in the OCCI address space.

If you do not add a KOCGLBxx DD to the CICS region, then xx defaults to ’00’ (zero zero).  If the selected global member is not found by the OCCI address space then it uses a default set of values.

PARMGEN support for the CICS globals

Currently PARMGEN support for the CICS globals is limited to copying global members from a source PDS into the run time environment’s hlq.RKANPARU library.

The source PDS to be used is specified by the KC2_CLASSIC_KC2GLB_SRCLIB parameter in the rte member name in the PARMGEN WCONFIG library and defaults to the ICAT INSTDATA dataset.

If you are not converting from an ICAT install for the RTE you can point this parameter at any library you chose and place your completed global members in there. During the deployment phase of the RTE, the deployment jobs will copy the global members from this library to the run time’s hlq.RKANPARU library.

If you are NOT using the default global member for a CICS region you will still need to manually add a KOCGLBxx dummy DD card to the CICS startup JCL in order to select the corresponding global member.

Finished Code…

August 21, 2013 Leave a comment

This is the finished code for the Arduino project. I switched the code to use exclusive ORs to flip the settings and added a second switch detection block of code for the second switch. All in all, pretty easy.

I’m still waiting for some parts to arrive before I can construct the finished project but I don’t anticipate any problems other than it not physically fitting in the project box I have ordered!

#include <Bounce.h>

Arduino Uno based stomp box Midi controller for T.C. Electronics M300
Copyright David E. Ellis 2013

Switch one toggle patches 2 and 3
Switch 2 toggles dry and mixed signal


#define PATCH_SWITCH 4            // Pin 4 - Controls patch switch
#define BYPASS_SWITCH 5           // Pin 5 - Controls bypass (wet/dry)
#define PATCH_LED 12              // On=initial patch, off=alternate patch
#define BYPASS_LED 11             // on=bypass on (dry), off=bypass off (wet)
#define ALT_PATCH 3
#define WET 0                     // Hear effect (wet signal) when bypass is off
#define DRY 127                     // dry signal when bypass on

// patch control
byte cur_patch = INITIAL_PATCH;
byte old_patch = ALT_PATCH;
byte cur_patch_led = HIGH;                            // high = led on
byte old_patch_led = LOW;

// bypass control
byte cur_bypass = DRY;                                // initial state for bypass signal is on (dry signal)
byte old_bypass = WET; 
byte cur_bypass_led = HIGH;
byte old_bypass_led = LOW;

Bounce bouncer1 = Bounce(PATCH_SWITCH,5);            // setup 5 ms debounce on switch 1
Bounce bouncer2 = Bounce(BYPASS_SWITCH,5);            // ditto on on switch 2

// the setup routine runs once when you press reset:
void setup() {   
  Serial.begin(31250);                              // Set MIDI baud rate:
  selectPatch(INITIAL_PATCH);                       // Set inital patch number
  setBypass(DRY);                                   // Set bypass to on initially (dry signal)
  pinMode(PATCH_SWITCH,INPUT_PULLUP);                // Open switch is normally pulled high
  pinMode(BYPASS_SWITCH,INPUT_PULLUP);                // Open switch is normally pulled high
  pinMode(PATCH_LED, OUTPUT);                         // initialize the led pin as an output.
  digitalWrite(PATCH_LED, cur_patch_led);              // set to current state 
  pinMode(BYPASS_LED, OUTPUT);                         // initialize the led pin as an output.
  digitalWrite(BYPASS_LED, cur_bypass_led);         // set to current state

// the loop routine runs over and over again forever:
void loop() {

  // Switch 1 controls the patch
  if (bouncer1.update()) {                           // returns true if switch state changed (on or off)
    if (! {                          // if switch is pressed (input low)
      cur_patch=cur_patch^old_patch;                 // swap patch
      selectPatch(cur_patch);                        // send it
      cur_patch_led=cur_patch_led^old_patch_led;    // swap led status
      digitalWrite(PATCH_LED,cur_patch_led);        // send it

  // Switch 2 controls bypass (wet/dry mix)
  if (bouncer2.update()) {                           // returns true if switch state changed (on or off)
    if (! {                          // if switch is pressed (input low)
      cur_bypass=cur_bypass^old_bypass;              // swap bypass state
      setBypass(cur_bypass);                           // and set new state
      cur_bypass_led=cur_bypass_led^old_bypass_led;     // swap led status
      digitalWrite(BYPASS_LED, cur_bypass_led);         // and send it

void selectPatch(byte patchNum) {
  Serial.write(0xC0);                    // change patch command
  Serial.write(patchNum-1);              // patch '1' is really zero etc

void setBypass(byte mix) {
  Serial.write(0xB0);                    // CC
  Serial.write(0x51);                    // 81 - Bypass
  Serial.write(mix);                     // by on (127/dry) or off (0/wet)   
Categories: Coding, Development Tools Tags:

As if I don’t have enough projects….

August 14, 2013 Leave a comment

I’ve been playing around with an Arduino micro processor to build a small midi foot controller/stomp box for an effects unit in my synth rack unit. I just need it to be able to make the effects unit flip flop between two patches and also switch from a dry to a mixed signal.

This is the circuit for my prototype (just one switch so far to switch the patches):

ArduinoMidiSwitchCircuitAnd this is the code (oh look, more C!):

#include <Bounce.h>

Midi controller for M300
Switch one toggle patches 2 and 3
Switch 2 toggles dry and mixed signal

#define SWITCH1 4           // header P4, pin 3 - Controls patch switch
#define LED 13              // on board led on pin 13
#define ALT_PATCH 3

  int patch = INITIAL_PATCH;

Bounce bouncer1 = Bounce(SWITCH1,5);    // setup 5 ms debounce on switch 1

// the setup routine runs once when you press reset:
void setup() {   
  Serial.begin(31250);                  //  Set MIDI baud rate:
  selectPatch(INITIAL_PATCH);           // Set inital patch number
  pinMode(SWITCH1,INPUT_PULLUP);        // Open switch is normally pulled high
  pinMode(LED, OUTPUT);                 // initialize the led pin as an output.
  digitalWrite(LED, HIGH);              // led on = initial patch  

// the loop routine runs over and over again forever:
void loop() {

  if (bouncer1.update()) {               // returns true if switch1 state changed (on or off)
    if (! {              // if switch is pressed (input low)
      if (patch == INITIAL_PATCH) {      // if current patch = initial patch
        selectPatch(ALT_PATCH);          // swap to alt patch
        patch=ALT_PATCH;                 // remember it
        digitalWrite(LED, LOW);          // led off = alt patch
      else {                             // current patch = alt patch
        selectPatch(INITIAL_PATCH);      // swap to inital patch
        patch=INITIAL_PATCH;             // remember it
        digitalWrite(LED, HIGH);         // led on = inital patch


void selectPatch(int patchNum) {
  Serial.write(0xC0);                    // change patch command
  Serial.write(patchNum-1);              // patch '1' is really zero etc

I am going to look at using Exclusive ORs to replace the ‘state’ code and LED flip flopping but for now this works very well. Hook up another switch, bit more code and the prototype will be done.

Total turn around time so far to get to this point (including installing the compiler and research), about an hour!

Makes the iPhone programming look ridiculously hard (still trying to figure out how to fix a memory leak. I know where it is, just not how to fix. very frustrating!).

Categories: Coding, Development Tools Tags:

PARMGEN and System Libraries…

August 12, 2013 Leave a comment

The deployment phase (step 11 on the menu) of creating and loading an RTE with PARMGEN copies all the run time data to the run time libraries.  Some of these members need to go into system libraries such as SYS1.PROCLIB and SYS1.VTAMLST or your user versions of same.

Rather than overwrite my current live run time procedures and VTAMLST members I configure PARMGEN to write them to  ‘staging’ libraries. From there I can double check them against the current live members before committing them.

To configure PARMGEN to write to your own system data sets, edit the $GBL$USR member in WCONFIG by selecting option 8 on the main menu and then option 2 and change the highlighted lines shown in this screen shot:


You have to manually create these data sets yourself but that is easy enough using ISPF option 3,2.

After the initial deployment, most of the time you will only need to copy run time JCL from the proclib and possibly vtam list members from the vtamlst staging libraries to your actual live system data sets.