LATE PS:
I found a change-detection every 20 ms to be a better compromise, than 40 ms. This means some more CC64 MIDI-events, but on the other hand a better realtime response. A very fast pressed or released pedal should reach 127 or 0 in a reasonable time (with 40 ms for example it can happen, that full sustain 127 is reached after 81 ms,  but this event is sent 39 ms later after 120 ms -- unnecessary lag)

My playing barely needs more than a switched damper pedal anyway, so I have only an interest in this based on my electronics background.

it is not audible, we only don't want to pollute the midi-bus with unnecessary midi-events. In the worst  case two values could "flutter" with the sample-frequency of the ADC.

But If you read the thread thoroughly we already found several working solutions:

a) http://www.forum-pianoteq.com/viewtopic...84#p938384
b) http://www.forum-pianoteq.com/viewtopic...88#p938388
c) http://www.forum-pianoteq.com/viewtopic...75#p938475
d) http://www.forum-pianoteq.com/viewtopic...17#p938617

I prefer the last solution d) (teensy2.0) and I'm using it a few weeks now with my continuous sustain-pedal and with great success. No problems or glitches at all!

Most of your suggestions are already implemented there, if you read the code:

- circular buffer of 10 samples.
- average of the 10 samples ("smoothing")
- sample-interval ~1ms
- change detection every ~40 ms if sustain delta is > 1

The only not implemeted "feature" is aandrmusic's idea of extreme spike-detection and -dropping.

Yes, Pianoteq can use several midi-devices simultaneously. For example I have listed two midi-devices in Pianoteq Standard: My Teensy2.0 continuous sustain-pedal and my USB-keyboard-controller.

... both the Arduino nano and the Teensy2.0 have 10-bit ADC (0-1023). That's why I divide by 8 to get (0-127).

cheers

I see little/no point in mere "Smoothing" of suspect values.

Well, averaging pot ADC input is not uncommon. Since I don't know his exact setup / circuit, it was one thing he could try. But the plastic box + wild wires looked noisy enough ;-)
It helped in a few things I built against small but constantly present fluctuatuations due to external noise when pots remained untouched (front panel).
I have no experience with filtering wild expression pedal action ;-)
Or with the output of hall sensors, for that matter. I imagine it would be less "fractured" than potentiometers'.

Having an adequate analog input filter before the ADC is half the rent, anyway.

You mean like from an old pot, sudden discontinuations in the surface? Is it really the duty of the software to fix pots which should be replaced? ^^ Well I guess making them live a little longer might be worth it.
But last for several ms? How that? I would hardly call that spikes then, given the rate of change we're talking about here.
I haven't seen anything like that so far, maybe because I haven't used anything I built so extensively that the pots could be worn out.

Sounds reasonable, I'll keep that strategy in the back of my head for the time I ever encounter huge jumps and the offending pot is "mostly good" still - *if* it is. And try to balance this against proper reading of quick real changes.

As for the foot not moving so fast, well it can be quite fast. If I kick the pedal, the travel might be well under 10ms for a full scale jump, easily under 20ms. I'd certainly not just discard such a jump.

Sure, the n * LSB error of the ADC alone should not spoil the game here, though, if maybe a not too crappy 10 bit ADC is used when only 7-bit output is needed.
I don't know the Arduino platform and the quality of its ADCs, though.

Now that I know Pianoteq can use this, I'll certainly solder something together and try how well it works ;-)
I wonder what the heck the FATAR guys were thinking when giving my SL990 a on/off pedal input ;-)

Thanks! Now I only need to learn to play the piano properly :-D :-D

Hey there, just registered,
have pianoteq for a while, saw a DIY thread and well, then I just had to register :-D

I have 1) a suggestion and 2) a question

1) value fluttering

I don't know how fast this fluttering is and how much of an *audible* change from e.g. 126 to 127 does.
Does the value e.g. 126 or 127 sometimes stay for a long time and then it flips to the other number, stays for a long time and flips again? Depending on the audible change it wouldn't be too bad perhaps.
But if it indeed changes "reliably" between a few very close values, with no long pauses, maybe some sort of low-pass filtering would help?
Which means no values in the range, and no deltas are excluded from the output categorically, just that time is factored in there.

I'm not quite a DSP guru, only have very fractional knowledge there.
But IIRC, the simplest form of low pass, which might work here, would be just to average a box of values.
Say, you have a circular buffer of size 3 (perhaps sufficient, perhaps needs to be bigger). In this case it would make sense I guess to put one new value in the buffer and discard the oldest *one* (you could also move about other lengths over the input stream, but intuitively I'd say that makes no sense here).
You average all values in the buffer, and pass on the result of that, which should be more stable than the fluttering input. If 3 is not stable enough, try 4..5.. etc).

Example:
The input stream of Sustain events: {126,125,127,125,126,127,126}
Output stream of averages (with fractional part | rounded by 0.5)
(After program start, when the first CC event arrives, I guess you need to fill the buffer initially completely with the first ever received value before generating the first output event. After that, each new incoming event just does the regular step: "put newest into buffer, discard oldest from buffer, average all, generate output event")
{126,126,126} -> 126    | 126
{126,126,125} -> 125.6 | 126
{126,125,127} -> 126    | 126
{125,127,125} -> 125.6 | 126
{127,125,126} -> 126    | 126
{125,126,127} -> 126    | 126
{126,127,126} -> 126.3 | 126

As you see, the rounded output remains stable. This depends of course on how widely and with what kind of distribution the input fluctuates and how many values the averaging buffer has.
But differences of (on average) 1 are still possible, which it would not with a solution like "only pass deltas >= 4" or so.
E.g., if it fluctuates, say, around 125 +/-1, and you kick the pedal fully, and it fluctuates around 126 +/-1.

2) Pianoteq and extra MIDI Sustain pedal as own MIDI device

Seeing this thread here, tells me, it must be possible in Pianoteq to have more than one MIDI input device, each for a different purpose?
E.g. use my MIDI keyboard which does not have a continuous sustain pedal input for notes, and a Pedal as own MIDI device as pedal input?
Can someone tell me how to set this up in Pianoteq 5? (I think I have the cheapest version...)

I see little/no point in mere "Smoothing" of suspect values.
Noise from potentiometer wipers is likely to be in the form of spikes (both negative and positive) and could last for milliseconds.
I regard suspect values as anything wildly different from a recent average, those should be discarded immediately, not put with recent valid values to pollute the valid average.  At first guess any change greater than 10% of the current average is too large and has happened too fast to be valid - feet can't move that fast.
In view of the times scales involved, e.g. feet move on a time scale of fractions of a second, but code runs around loops in microseconds - any averaging buffers could be quite LARGE.  The arduino might as well be doing this filtering instead of sitting on a wait for tens of milliseconds.

Clearly differences of 1 need to be filtered out since they can occur from rounding no matter how good the sensor is, this is the plus or minus half the least significant bit problem that ALL analogue to digital conversion has.
Beyond that, sad to say it depends on the particular sensor in each particular pedal, i.e. if you use a 3 pedal unit such as the RPU-3 it would be wise to gather data for each pedal and set your filters to each one.  If you PLAN to do this the code should be simple enough.
My guess is that a cyclic list 64 or 128 locations long might be a good starting place.
From there experimentation is needed, again with the particular pedals that you are using as well as the processing speed of the arduino and its libraries.

Yes, pianoteq can be set to listen on all midi inputs, for example mine is set to listen to midi cable and to loopBE internal midi.
Also many/most midi devices have "midi in" and "midi through", so you can "daisy chain" midi devices.

I have 1) a suggestion and 2) a question

1) value fluttering

I don't know how fast this fluttering is and how much of an *audible* change from e.g. 126 to 127 does.
Does the value e.g. 126 or 127 sometimes stay for a long time and then it flips to the other number, stays for a long time and flips again? Depending on the audible change it wouldn't be too bad perhaps.
But if it indeed changes "reliably" between a few very close values, with no long pauses, maybe some sort of low-pass filtering would help?
Which means no values in the range, and no deltas are excluded from the output categorically, just that time is factored in there.

I'm not quite a DSP guru, only have very fractional knowledge there.
But IIRC, the simplest form of low pass, which might work here, would be just to average a box of values.
Say, you have a circular buffer of size 3 (perhaps sufficient, perhaps needs to be bigger). In this case it would make sense I guess to put one new value in the buffer and discard the oldest *one* (you could also move about other lengths over the input stream, but intuitively I'd say that makes no sense here).
You average all values in the buffer, and pass on the result of that, which should be more stable than the fluttering input. If 3 is not stable enough, try 4..5.. etc).

Example:
The input stream of Sustain events: {126,125,127,125,126,127,126}
Output stream of averages (with fractional part | rounded by 0.5)
(After program start, when the first CC event arrives, I guess you need to fill the buffer initially completely with the first ever received value before generating the first output event. After that, each new incoming event just does the regular step: "put newest into buffer, discard oldest from buffer, average all, generate output event")
{126,126,126} -> 126    | 126
{126,126,125} -> 125.6 | 126
{126,125,127} -> 126    | 126
{125,127,125} -> 125.6 | 126
{127,125,126} -> 126    | 126
{125,126,127} -> 126    | 126
{126,127,126} -> 126.3 | 126

As you see, the rounded output remains stable. This depends of course on how widely and with what kind of distribution the input fluctuates and how many values the averaging buffer has.
But differences of (on average) 1 are still possible, which it would not with a solution like "only pass deltas >= 4" or so.
E.g., if it fluctuates, say, around 125 +/-1, and you kick the pedal fully, and it fluctuates around 126 +/-1.

2) Pianoteq and extra MIDI Sustain pedal as own MIDI device

Seeing this thread here, tells me, it must be possible in Pianoteq to have more than one MIDI input device, each for a different purpose?
E.g. use my MIDI keyboard which does not have a continuous sustain pedal input for notes, and a Pedal as own MIDI device as pedal input?
Can someone tell me how to set this up in Pianoteq 5? (I think I have the cheapest version...)

Yes, it is likely to be LARGE and PERSISTENT, i.e. bounce around for milliseconds.

... one more reason for contactless Hall-Sensors ...

Thank you! ;-)

Do we have any indication, that the deviation by bouncing/settling is not masked by the hysteresis of +/-2 MIDI-values?

And if that noise couldn't be masked all the time - would it have practical consequences?

aandrmusic wrote:

I will stream in raw values once I get hardware set up.

Yes, statistics and simulation could give an answer.

Yes, it is likely to be LARGE and PERSISTENT, i.e. bounce around for milliseconds.
The very existence of the code that you pointed to here;  https://www.arduino.cc/en/Tutorial/Smoothing
supports the need for what I described earlier as maintaining a cyclic list of values and discarding values
that deviate a lot from the running average - different terms, but essentially the same basis and principles.
Spurious signals need to be filtered out, not just accepted at larger time intervals.
 
Again, micro processors are fast, pots bounce slowly, feet move even slower.

There is no hysteresis, use of that term will likely lead to other readers becoming confused.

In words it does the following: It checks every 40 ms, if an average of the last ten CC64-values has changed for more than >= 2. In that case a MIDI-Event is sent to Pianoteq via USB (else not).

The analog input is read continuously every ~1 ms (because the loop has the delay(1)). So the ten readings in the cyclic list represent the last ~10 ms before the change-check.

/* USB MIDI AnalogControlChange Example

   You must select MIDI from the "Tools > USB Type" menu
   http://www.pjrc.com/teensy/td_midi.html

   This example code is in the public domain.
*/

#include <Bounce.h>

// the MIDI channel number to send messages
const int channel = 1;

// the MIDI continuous controller for each analog input
const int controllerA0 = 64; // 64 = sustain

const int numReadings = 10;

int readings[numReadings];      // the readings from the analog input
int index = 0;                  // the index of the current reading
int total = 0;                  // the running total
int average = 0;                // the average

int inputPin = A0;

void setup() {
        // initialize all the readings to 0:
        for (int thisReading = 0; thisReading < numReadings; thisReading++)
          readings[thisReading] = 0;
}

// store previously sent values, to detect changes
int previousA0 = -1;

elapsedMillis msec = 0;

void loop() {
  // subtract the last reading:
  total= total - readings[index];        
  // read from the sensor:  
  readings[index] = analogRead(inputPin);
  // add the reading to the total:
  total= total + readings[index];      
  // advance to the next position in the array:  
  index = index + 1;                    

  // if we're at the end of the array...
  if (index >= numReadings)              
    // ...wrap around to the beginning:
    index = 0;                          

  // calculate the average:
  average = total / numReadings;        
  
  // only check for changes all 40 ms
  // to prevent a flood of MIDI messages
  if (msec >= 40) {
    msec = 0;
    int n0 = average / 8;
    // only transmit MIDI messages if analog input changed
    // if (n0 != previousA0) {
    // only transmit MIDI if change is 2 or more
    int diff = abs (n0 - previousA0);
    if (diff > 1) {
      usbMIDI.sendControlChange(controllerA0, n0, channel);
      previousA0 = n0;
    }
      delay(1);        // delay in between reads for stability
  }

  // MIDI Controllers should discard incoming MIDI messages.
  // http://forum.pjrc.com/threads/24179-Teensy-3-Ableton-Analog-CC-causes-midi-crash
  while (usbMIDI.read()) {
    // ignore incoming messages
  }
}

At first glance it seems not to behave differently to the simplistic approach, but it should smoothen potential noise.

And if that noise couldn't be masked all the time - would it have practical consequences?

Yes, statistics and simulation could give an answer.

A point about your last reply; Sure there is little/no noise when the pedal is stationary, as depicted with a clamp on it - but your code senses a change and assumes the value to be valid IMMEDIATELY.  The point being that these initial change values are probably the MOST invalid.

Potentiometer wipers tend to BOUNCE and their settling time is typically in milliseconds.
Arduino's time to ReadAnalogue() is about 100 microseconds according to the reference page.
That seems awfully SLOW to me, but the exact time doesn't matter, it is an order of magnitude faster than the settling time of a potentiometer, so you could get around a read loop several times while a pot finds its steady value.
This is my main point, the arduino can be WATCHING the settling of the pot instead of WAITING some arbitrary amount of time to gather a next value that is no more credible, it is merely "different" and some number of milliseconds later.

I will stream in raw values once I get hardware set up.
It shouldn't take long to establish settling times and noise floors/ceilings, then I can decide if any of this matters more than my lack of pianistic skills - - Oh, I know that already.  I need to PLAY more and PRACTICE more diligently.
   
BTW, a 10 bit A to D should take little more than 10 clock cycles, that is why I think 100 microseconds is SLOW.

... but that is an important point IMHO. Maybe the noise of the analog input is negligible. For example all MIDI-events are stable, when I use fixed positions :-)
-->

Remains "dynamic noise" - is there any generated, when the pedal is moving dynamically up and down? I don't know, all I can say is, that I don't find any spikes in the opposite direction of the pedal movement  (the deeper the pedal is pressed, the greater are the CC64-values in the event-list and vice versa).

But that doesn't mean, that it is not "good enough". Ok, "qualified" would be better approach, yes. It would be interesting to see, how averaging handles fast 0 <-> 127 movements or erratic changes in between.

I'm an absolut beginner with Teensy or Arduino, probably "smoothing" of the analog input would be the next step:

https://www.arduino.cc/en/Tutorial/Smoothing

(... where overengineering begins?? ;-)

I would prefer an approach that samples as often as possible and actively FILTERS OUT noise.

Propose;
Sample as often as possible.
Store values in a cyclic list (length TBD experimentally)
Discard values that differ from previous table average by more than some percentage.
If table average has changed more than some TBD value Send table average, update previous table average, etc.

This would provide some smoothing as well as spike and valley noise removal.

I can't DO this until I have parts assembled, but I will run with NO filtering initially to determine the amount of noise on my pedals and the maximum speed at which my foot can perform full strokes - down is almost certainly faster than release.
Then I can determine table size and thresholds for discarding spikes and valleys.

Almost worth getting one so I can tell people what it is when they ask

Teensyduino

Seriously, I like it and might build with it.
The picture shows that it isn't much bigger than the end of the USB cable.

:-) As you suggested, I modified the code a bit now, so that not each controller change is detected, but only if it is greater than 1 MIDI-value (i.e. 2, 3, 4, ...). This "hysteresis" is enough to make each pedal-position of my Roland DP-10 stable. As we discussed, it can happen now, that with a let-off pedal the cc64 remains at value 1 (and not 0).

But this is no problem, because Pianoteq drops all values <=10 to value 0, and all values >=117 to value 127 when calibrating the pedalcurve with the calibrator. 

FYI:

/* USB MIDI AnalogControlChange Example

   You must select MIDI from the "Tools > USB Type" menu
   http://www.pjrc.com/teensy/td_midi.html

   This example code is in the public domain.
*/

#include <Bounce.h>

// the MIDI channel number to send messages
const int channel = 1;

// the MIDI continuous controller for each analog input
const int controllerA0 = 64; // 64 = sustain

void setup() {
}

// store previously sent values, to detect changes
int previousA0 = -1;

elapsedMillis msec = 0;

void loop() {
  // only check the analog inputs all 40 ms
  // to prevent a flood of MIDI messages
  if (msec >= 40) {
    msec = 0;
    int n0 = analogRead(A0) / 8;
    // only transmit MIDI messages if analog input changed
    // if (n0 != previousA0) {
    // only transmit MIDI if change is 2 or more
    int diff = abs (n0 - previousA0);
    if (diff > 1) {
      usbMIDI.sendControlChange(controllerA0, n0, channel);
      previousA0 = n0;
    }
  }

  // MIDI Controllers should discard incoming MIDI messages.
  // http://forum.pjrc.com/threads/24179-Teensy-3-Ableton-Analog-CC-causes-midi-crash
  while (usbMIDI.read()) {
    // ignore incoming messages
  }
}

Teensyduino

Seriously, I like it and might build with it.
The picture shows that it isn't much bigger than the end of the USB cable.