//getvalueTesting//4 buttons wired pins 2-5//pin to tactile button to 330k to ground//uses internal resistence to VCC////goal is an expample that gathers debounced state information//and combines every switch state within a time window//into an int value//ie, buttonstate[4]={1,2,5,1} --> int=1251

more description of purpose is in the codeI tried the bounce library... and I just found that I probably need get more familiar with the core concepts then try to take a shortcut. (and it was working inconsistently but that would be a topic for another thread)

I'm having a hard time finding out why this will give the correct values for presses, but not releases and holds.

Your code dealing with windowCount looks wierd. Why don't you just calculate the difference between now and when the window started? WHy calculate elapsed time per loop and then add them up?

In the context of a system where nothing changes for long intervals (relative to the window size) when is the 'window time' supposed to start?

Exactly what is the code trying to do? It seems to be dealing with press, release,hold, bounce, regular and with flags and times associated with various of those, but it's not obvious how the final output value is supposed to be related to the physical button presses and releases. Ignoring the code itself, and assuming I know nothing about your project, what is this code trying to do?

I only provide help via the forum - please do not contact me for private consultancy.

Your code dealing with windowCount looks wierd. Why don't you just calculate the difference between now and when the window started? WHy calculate elapsed time per loop and then add them up?

it has more to do with the creating a chord then the debounce, sorry its kinda misleading for this question.

Quote

In the context of a system where nothing changes for long intervals (relative to the window size) when is the 'window time' supposed to start?

I see what you are getting at there, I didn't think about it because in my last implementation it worked its self out somehow. The window is supposed to start when values start being detected. For right now this works well enough for me test things out. Just shows whats falling within the window.

Quote

Exactly what is the code trying to do? It seems to be dealing with press, release,hold, bounce, regular and with flags and times associated with various of those, but it's not obvious how the final output value is supposed to be related to the physical button presses and releases. Ignoring the code itself, and assuming I know nothing about your project, what is this code trying to do?

the goal is to debounce over multiple button instances first and foremost then also flag different press types and seed* the press type based on other button statesThe later two objectives I'm working on currently and not in the op

*- if the other buttons are active, the monitored button's reported value is augmented by this to report a unique value. That unique value becomes a key in a chord

the code is basically trying to prove that I can debounce multiple buttons and construct an int "chordValue" from it

Let me try to rephrase that, and see whether I've understood you correctly.

You have a set of inputs - four, in this example. The states of the inputs change over time. The state of all the inputs at a given time constitutes a chord, and the state of the inputs over time represents a sequence of chords.

Because the inputs don't necessarily all change state at the same instant, when the inputs are changing you wait until they have settled into their new state before you determine that a new chord has occurred.

In a sense what you're doing is not debouncing the inputs individually - you are debouncing their combined state.

In that case I'd implement a function to return the instantaneous states of the inputs as a number (each input corresponding to one bit of the number) and use an asynchronous debouncing algorithm along the following lines:

You have a set of inputs - four, in this example. The states of the inputs change over time. The state of all the inputs at a given time constitutes a chord, and the state of the inputs over time represents a sequence of chords.

I might word it differently but that is basically the jist of it

Quote

In a sense what you're doing is not debouncing the inputs individually - you are debouncing their combined state.

I fumbled over the wording of this at first thinking it implied that was done, which is most certainty false. This is Peter's idea to the solution, Its a good approach, Less complex.

//getvalueTesting2//4 buttons wired pins 2-5//pin to tactile button to 330om to ground//uses internal resistence to VCC////goal is an expample that gathers debounced state information//and combines every switch state within a time window//into an int value//ie, buttonstate[4]={1,2,5,1} --> int=1251

Its amusing to do the wave on the serial monitor and see the 2 jump side to sidenow its just a matter of having to figure out how to handleChordChange, I'll work on it a bit and report back whether I run into more complications or not. I've been dug out of a rut twice now and I'm greatful.

out of curiosity I'm still interested in the fail point of the code in the op, for anyone interested in educational pursuits.

//getvalueTesting2//4 buttons wired pins 2-5//pin to tactile button to 330om to ground//uses internal resistence to VCC////goal is an expample that gathers debounced state information//and combines every switch state within a time window//into an int value//ie, buttonstate[4]={1,2,5,1} --> int=1251

int rawInput(){ int incrementor=1; int value=1111;//2 will represent high as zero may prove problematic for low for(int i=0;i<NUMBUTTONS;i++) { if(digitalRead(buttons[i])==LOW) { value+=incrementor; incrementor*=10; } else { incrementor*=10; } } return value;}I'm still having a hard time producing a reliable/consistent values when pressing more then two keys at the same time, but this is kinda primitive and needs some more tweaking.

My idea of creating compiling a unique value, seems a little weak but it works as long as only a few samples are taken before an overflow of "builtChord" happens.

if(regularPress && windowCount > 100) { if(baseChord!=oldChord) { baseChord-=oldChord; builtChord+=baseChord; regularPress=false; } oldChord=baseChord; }main issue now is that, what seems like solid combinational press to me is a really sloppy one to the arduino over the course of 120ms or so. This is like the debounce issue except more dubious... or maybe I'm over-thinking it.

unless maybe I can put debounce on top of the debounce to "settle" the combos? I'll try it.. in the mean time, I would appreciate an pointers though