Problem with modified sel b object - SOLVED


#1

Hi
I'm trying to modify a sel b object so that is sends out sequenced midi note-on's and note-off's (both internally to control a poly synth patch and also externally (but I haven't tried that yet). The idea is that a counter advances through the horizontal grid; if a cell is highlighted then a midi-note-on is output for a specific note allocated to that row. A non-highlighted cells sends a midi-note-off. If two highlighted (or non-highlighted) cells are next to each other then repeat messages are suppressed.... meaning a midi-off must always follow a midi-on. I put 8 of these rows together with note selector fields to produce a simple polyphonic step sequencer. So here's the code for one such row:

bool m1; (in "local data")
m1=0; (in "Init Code")

if ( bool((param_1>>inlet_step)&1) != m1 ){
PatchMidiInHandler(MIDI_DEVICE_INTERNAL,0,MIDI_NOTE_ON,param_note1,m1*127);
m1=!m1;
}

((param_1>>inlet_step)&1) is to read each step and returns a TRUE when the step cell is highlighted. I had to add a bool cast as it wouldn't work otherwise. m1 is a flag to remember whether the last command was a midi-on or midi-off...detecting when a cell state changes. If consecutive cells are the same then repeat midi messages are prevented. I'm using a midi-note-on with velocity zero (m1==0) to achieve a midi-note-off.
So here's the problem: it works, but the non-highlighted cells produce the midi-on!! This doesn't make sense to me. Bizarrely changing the != to == produces the correct effect, but not on the first cycle. Nothing happens on the first run through the row then all starts working correctly.
Can anyone help explain what I'm doing wrong?
Cheers!
Paul
PS. Absolutely love Axoloti


#2

Got it. Two probs...
1. m1=!m1 should be before midi statement and this explains "inverted" behaviour
2. I was using square wave LFO as clock source and this commences with a leading +ve edge effectively skipping zero in the counter I was using to drive the sequencer. Applied a logic invert and I now have a leading logic low and behaviour is as expected (though that first low seems shorter than subsequent pulses)
Cheers
Paul