Beginner project: MIDI, analog pot turned into MIDI CC, MIDI merge with incoming MIDI

Status
Not open for further replies.
Ok, It's bedtime here and this code compiles so am looking forward to good news.

Code:
///************LIBRARIES USED**************
#include <MIDI.h>
MIDI_CREATE_INSTANCE(HardwareSerial, Serial1, MIDI);
#include <ResponsiveAnalogRead.h>

// ******CONSTANT VALUES******** 
const int channel = 1; // MIDI Out channel
const int A_PINS = 1; // number of Analog PINS

// define the pins you want to use and the CC ID numbers on which to send them..
const int ANALOG_PINS[A_PINS] = {A0}; //            Need to change this 
const int CCID[A_PINS] = {16};  //CC for Modulation. Need to change this

//******VARIABLES***********
// a data array and a lagged copy to tell when MIDI changes are required
byte data[A_PINS];
byte dataLag[A_PINS]; // when lag and new are not the same then update MIDI CC value

//************INITIALIZE LIBRARY OBJECTS**************
ResponsiveAnalogRead analog[]{{ANALOG_PINS[0],true}}; 

int previousTimer;

//************SETUP**************
void setup() {
  MIDI.begin(MIDI_CHANNEL_OMNI); 
}

//************LOOP**************
void loop() {
    MIDI.read();
    mergeIncoming();
    getAnalogData();
    doActiveSensing();
}
//*************Merge
void mergeIncoming()
        {
   if (MIDI.read())
            {
        MIDI.send(MIDI.getType(),MIDI.getData1(),MIDI.getData2(),MIDI.getChannel());
            }
        }
//************ANALOG SECTION**************
void getAnalogData(){  
  for (int i=0;i<A_PINS;i++){
    // update the ResponsiveAnalogRead object every loop
    analog[i].update(); 
    // if the repsonsive value has change, print out 'changed'
    if(analog[i].hasChanged()) {
      data[i] = analog[i].getValue()>>3;
      if (data[i] != dataLag[i]){
        dataLag[i] = data[i];
        MIDI.sendControlChange(CCID[i], data[i], channel);
      }
    }
  } 
}  
//******** Send Active sensing
void doActiveSensing()
     {
   int currentTimer = millis();
      if(currentTimer - previousTimer > 300)// If 300Ms has passed
        {
          // Reset the counter
          previousTimer = currentTimer;
          // And send ActiveSensing
          MIDI.sendRealTime(0xFE);
          // and you need to find and put the number for activeSensing inside the brackets.
        }
      }
 
Hi MatrixRat,
the code works with my DIN to USB MIDI interface in a lab environment! Thank you very much for helping a beginner! Codewise the job is done thanks to you!

The 1987 Roland GP-8, however, does not recognize the MIDI data. Maybe the old optocoupler PC910 of the MIDI in needs more current ...
The teensy should actually provide enough current, maybe I experiment with a 74ls05 or even transistors.
The original Roland FC-100 footcontroller uses transistors to "drive" the MIDI out:
IMG_2954.jpg
 
Basically, Q8 and Q6 in the above schematic and the 74LS05 in the earlier one are doing the same job as a buffer between the MCU TX pin and the outside world. Good engineering practice.

The current through the optocoupler Led is determined by the value of series resistance. I can't see any potential benefit (yet) by adding a 74LS05.

Ok. something is "proprietary" here so ya gotta ask "what's different".
Would be interesting to see what circuitry is associated with the opto in the receiving device.

Another thought, does "proprietary" mean that 300 Ms between ActiveSensing messages might be something else? after all "Proprietary" usually means that rules have been bent so why not bend a few more...

I'm not a skilled programmer and cannot guarantee that my code is spitting out ActiveSensing messages exactly 300 Ms apart. You might fiddle with the 300 in void doActiveSensing(). It wont go up in smoke.

Midiox gives us a timestamp on incoming messages so maybe this can be used to get a fix on ActiveSensing messages coming out of the "proprietary" device, then compare with what my code puts out. I have two devices that emit ActiveSensing but none that do anything with it.

More headcratching....
 
I see your point, it doesn't make sense to add just another 74LS05 or transistors.
The proprietary Roland RRC jack just has a few more pins for Vcc and the signal for the guitar tuner.
Here's the receiving MIDI in:
IMG_2956.jpg
 
I compared the original footcontroller and my modded one. I reduced the active sensing to 200ms in your code.
Judging by the flashing LEDs of the USB MIDI interface and the speed of the Active sensing coming up in the MIDI-Ox input monitor I would say that the two timings are close ...
but I try to figure out the timestamps of the MIDI-Ox ...
 
Last edited:
I take it that the timestamp in MIDI-OX is in HEX and DEC is in ms.
Here are some readings:

Roland FC-100: min. 236ms, max. 263ms
Teensy: min. 189ms, max. 201ms

The teensy is more consistent putting out "Active Sensing" every 201ms on average. That's amazing because I typed into the code:
Code:
//******** Send Active sensing
void doActiveSensing()
     {
   int currentTimer = millis();
      if(currentTimer - previousTimer > 200)// If 300Ms has passed
        {
 
Last edited:
I changed the timing of the active sensing to 250ms to no avail.
Right now I haven't got time to do it, but tomorrow:
I am going to connect the modded Ibanez footcontroller with the teensy to the MIDI IN of my USB2MIDI interface,
then I am going to connect the MIDI out of the USB2MIDI interface to the MIDI in of the Roland GP-8. See what is going on there with the MIDI-OX as middle man.

I have to say the proprietary RRC input of the Roland GP-8 is still working with original Roland footcontroller, so the opto-coupler is not damaged.
I can also confirm that the Roland FC-100 footcontroller puts out conventional MIDI signals, no Sys-Ex, just program changes and CCs.
 
Ok thanks. As I expected there some small differences in the opto input from what you usually see but nothing leaps out as something to play with. Will investigate more deeply in daylight as have both Midi in and out circuitry mocked up on a breadboard as have been looking at output buffer and Midi In circuits for 3.3v operation. ThePC 910 looks functionally similar to the 6N 137 and I have some handy.
I've find no fault in your thinking or your English and if matter transporters existed I'd gladly upload my CRO. Darn sure the solution turns out to be dead simple.
 
...ideas.

Let's forget about Midi for the moment and think diagnostics like an ElCheapo logic probe.

ElCheapoLogicProbe.jpg
The two Leds are wired back to back so regardless of which way it's connected, one of them lights up when it sees +5v.

Then open the blink sketch in File>Examples>01.Basics then change int led = 13; to int led = 8; and make it flash faster like delay(100);

Ok, pin 8 is TX so when the sketch is uploaded we've got the the TX pin turning ond and off. Use the probe and verify TX pin is pulsing.

Then probe from +5v to pin 6 of receiving PC 910 to see if there is activity.
 
Good idea! That‘s a 47R resistor: yellow - violet - black - gold ? That will take a few days since I am quite busy jobwise ...
 
Oops, sorry, it is a 470R which happened to be on the bench when I assembled it.

I think it wise to use a bigger R like 1k5 to minimise current draw. The Leds will still be bright enough to see.

It's important to think about where you use it because of the current draw.
 
More confusion!
If I patch the USB2MIDI interface + MIDI-OX between footcontroller and Roland GP-8 switched to MIDI IN position (instead of RRC in see schematics above), the GP-8 receives program changes and responds correctly.
Program changes, MIDI CC and active sensing are sent correctly by the teensy.

The MIDI In and the RRC in have the same infrastructure, opto-coupler etc. ...
 
Not sure if the 6 - pin connector in the schematic Post #38 and the 6-pin of the schematic in Post # 52 are on the same page.

Would you zoom out and repeat post #52?
 
I have modded the section to provide MIDI THRU for both RRC and MIDI IN. Bear in mind that RRC is MIDI, just a proprietary DIN jack!
Roland GP-8 RRC and MIDI IN.jpg
 
It looks like the lower SW1 wiring mod routes either incoming Midi In or RRC to Thru.

Upper SW1 pulls P16 of the CPU low for whatever reasons which are unclear. We are dealing with that magic word - "proprietary".

Perhaps the CPU is enabling power to the RRC port and who knows what else may be switched like baudrate or whatever.

Could you post schematic details of how the IFC60 connects to the GP-8.
 
Thanks for your answer, MatrixRat!
X marks the spot where I have inserted the teensy.
I am going to open the Roland GP-8 at the end of the month, I suspect that's the culprit. Right now I haven't got time to work at the project.
ifc60.jpg
 

Attachments

  • IFC60_schematics.pdf
    782.6 KB · Views: 105
Hi everybody, hi MatrixRat,

I connected the footcontroller including the teensy with a second Roland GP-8 that I could get hold of. It worked and I can confirm that MatrixRat‘s code is verified now.
The RRC optocoupler on the original GP-8 is non-functional or damaged. I am going to swap it for a new one.
Thank you very much for your help, MatrixRat!
 
Status
Not open for further replies.
Back
Top