Midi sync for cdj-800

Hi

I'm a keen user of the site, first time poster.
I have used my Arduino to synchronise my CDJ-800 turntable to an external midi source.

The rig 'presses' the cue button on the CDJ (via optocoupler) in sync with an incoming midi clock to create a synced loop.

The inputs are x4 push-buttons to edit four different timing parameters, and a push-button rotary encoder for adjustment.

The outputs are x4 LEDs to indicate the selected mode, x2 7seg displays, 1 opto to press the cue button, and a trigger output.

Everything works as intended except for 1 bug which has had me scratching my head for the last week.
periodically, variables reset back to their initialised values, and I just can't work out why.

If anyone would be willing to help me with this, I would be very grateful.

Thanks in advance.
Dan

cdj.ino (9.79 KB)

Is the Arduino losing power? Getting hot?

Hi,

There is no excess temp. I have tried a different chip, but still the same.

I confident that it is a software issue. The bug happens when there is no mode selected.
whenever a mode is selected,
eg: alignMode = HIGH;
or stutterMode = HIGH;
or dutyCycleMode = HIGH;
or lengthMode = HIGH;

then variable (length, duty, align or stutter) can be changed using the rotary encoder, then activated using the activate button.

so long as one of these modes is selected, then everything works fine. however when all modes are low, then the variable resets to the value it was initialised at.

I just can't see why (pulling out some hair).

Thanks

Think we'll need to see the code to get further progress/inspiration...

Can you determine if the system is reseting or not?

That code layout is hideous - the only way I can see which braces pair up using using an editor that matches them for me. And I'd much rather you used boolean values true and false for your boolean variables, instead of using the values defined by Arduino for digital I/O states. Having said that, I don't think either of these issues are causing your problem and look at length mode as an example the only place that length is updated is an assignment from encoder0Pos, and encoder0Pos is set from length at the start of length mode. The code looks pretty complex (and I can't help thinking some of that complexity is not required) so I can't be sure that encoder0Pos is updated correctly, but nothing jumps out at me as likely to cause the length variable to be set to 4.

I think MarkT's thought about the board resetting is the most likely explanation and is what I'd check for first. You could explicitly check for a reset by making the board do something obviously recognisable during setup(). Another way to check is to change the initialisation of length to some other arbitrary value. If the symptoms change and it now jumps back to that new value, it's pretty strong evidence that the board is resetting.

boolean looseBeat = LOW;

...

void ClockPulse() {
  if (looseBeat == HIGH){
    looseBeat = LOW;
  }
  else{
    clockPulse++;                                                                    //

Booleans can be true or false. Not anything else.

As for ClockPulse and clockPulse -- how would you like it if Dog and dog referred to different things? Choose better data names that don't only differ by case.

Please amend your description to something better than "Can anyone help me find this bug?". Everyone wants their bugs solved.

Read this before posting a programming question

Hi,

point taken about the messy code. it's my first stab at something other than basic lights and motors.

I'll do some housekeeping, change the booleans to true/false, and confirm if a reset is ocurring.

thanks guys.

Dan

Hello,

I have confirmed that a re-start is happening.

I'm not sure why though.
The power supply is regulated.

I can press any of the 4 mode toggle buttons, in any and all combinations, at any speed, and all is well.

as soon as all four buttons are released - reboot.

after reboot, it will run fine with all buttons released until the next transition from 'any button pressed' to 'no buttons pressed'

I've scoped the inputs to the button channels. There is a clean 0 to 5v transition, with no obvious voltage spike.

The chip does not feel in any way hot, and I have tried a substitute chip

any thoughts?

I've attached the code after a little tidy up.

Thanks again

cdj1_1.ino (10.5 KB)

To save me wading through all this (and you might want to use the auto-formatter on it) which 4 buttons? Name them.

Also, as a style thing:

      if (stutterMode == true)

Booleans can only be true or false, so testing "if it is true" is a bit redundant. It looks neater like this:

      if (stutterMode)

It's like saying:

if (((2 + 2) == 4) == true)

The condition 2+2==4 is already going to be true or false, you don't need to add "== true" to it.

Hi.

Yes, I've used the auto format now, and found it good. Thanks

It is much neater to use if(stuttermode), I shall do so from now on.

the four buttons are align, length, stutter, and dutycycle. Their states are read from pins 14 to 17 into the variables alignMode, stutterMode, lengthMode, dutyCycleMode.

The buttons mechanically latch on and off, and have an integral LED, attached to lengthLEDPin... etc

There is also a button on my rotary encoder used to activate values.

The idea is to choose a mode, eg length. the current value for length is then shown on the display. the length LED lights for user feedback.
an new value can be dialled in using the encoder, lengthLED flashes to show the parameter has changed.
the new parameter becomes active when the encoder button gets pressed.

  pinMode(lengthLEDPin, OUTPUT);     // mode Iidicator
  pinMode(dutyCycleLEDPin, OUTPUT);  // mode indicator
  pinMode(stutterLEDPin, OUTPUT);    // mode indicator
  pinMode(alignLEDPin, OUTPUT);      // mode indicator
  pinMode(12, OUTPUT);               // Cue button presser
  pinMode(13, INPUT);                // activate button
  pinMode(14, INPUT);
  pinMode(15, INPUT);
  pinMode(16, INPUT);
  pinMode(17, INPUT);

Oh I see. Why did you stop using symbolic names from pins 12 onwards? Get bored?

How about:

  pinMode(alignSwitch, INPUT);
  pinMode(lengthSwitch, INPUT);
  pinMode(stutterSwitch, INPUT);
  pinMode(dutycycleSwitch, INPUT);

And so on for the rest of the sketch. Although judging by this bit, I guessed the names wrongly:

  alignMode = digitalRead(17);
  stutterMode = digitalRead(16);
  dutyCycleMode = digitalRead(15);
  lengthMode = digitalRead(14);
  activate = digitalRead(13);

Good use of symbolic names makes it easy to read. Easy to read is easy to debug.

How are the switches wired up exactly? Are there pull-up or pull-down resistors?

hi.

Each button uses a pulldown resistor, as per the arduino button tutorial.

The lack of symbolic names comes from coded added 'just to check it works' which then became perminant.
poor programming practice i guess.

thanks

If it resets, it sounds electrical. I can't see offhand what would do it in your code. I'm not trying to attack your programming practice, but am suggesting that if you write in a way that is easy to follow, you will help yourself. The use of symbolic names, good layout, comments, etc. help in this regard.

Hi,

I'll investigate the electrical side, just identifying that a reset is occuring has been a big help.

Your suggestions have been helpfull and informative, since I'm just starting out with the arduino language, I want to get into the habit of doing things the right way, so I don't have to break bad habits later on.

Thanks

Hello helpful forum peeps,

Still not got to the bottom of this one. :frowning:

I have thoroughly scrutinised all connections, track gaps, and solder joints, and found them sound.
I have also tidied and refined the code as per suggestions.

I'm now convinced that the problem is somewhere in the midi input section, as I have discovered that the re-start does not occur when the midi cable is unplugged.

I based the midi input circuit on this
http://www.thebox.myzen.co.uk/Hardware/MIDI_Shield.html

however I found that this circuit periodically lost bits of information.
Through a little breadboard experimentation, I found that this was remedied by adding a 10k resistor between pins 7 and 5.
I figured that this was acting as a pull-down to logical 0 voltage level.

In any case, with or without the additional 10K, the reset occurs whenever all buttons are released, but only if a midi input is present.

Has anyone using this circuit experienced similar problems?
Any and all suggestions are gratefully recived.

Dan

SOLVED!!!!!!!!!!!!!!!

I found a different diagram for midi input here: http://pzwart3.wdka.hro.nl/wiki/ArduinoMidiInterface

made the changes, and WOOF! Immediate flawless operation.

I am very pleased. Thanks a lot for the assistance.