Standalone continuous sustain pedal? (Page 2 of 2)

I have been RESISTING building something like this for a while now.
Not that my playing NEEDS 3 or 4 pedals (or even ONE) but I have a sense that Arduino is SUCKING me towards a project

Manoreken2's project makes the 3 pedal solution look very attractive, the RPU-3 being quite a reasonable floor unit, so I am noodling around with code while waiting for my next trip that will take me near to the local micro-center on July 2nd.  I may pass a guitar center on that day and pick up an RPU-3.

It SEEMS that "fluttering" could be a problem at any value, so I am SUGGESTING a bit of code that filters out tiny changes, e.g. smaller than 3 or 4 (arbitrary, but reasonable).  There seems no need to transmit something like 34, 35, 34, 36, 34, 35,,, etc. just transmit the 34 and nothing until something greater than 38 or less than 30.

Similarly, great leaps in value in the small fraction of a second that it takes to loop back and take another sample are very unlikely, (the human foot can move only so fast, but wipers on potentiometers can lose/regain contact) so changes greater than 20 since the last transmission could/should be ignored.

I don't see a need for a delay in the loop, I would keep the transmission rate down just by filtering for "worthwhile and real changes" i.e. not noise.

These are just my thoughts/suggestions, I may change my mind completely once I get something built and see what the midi stream actually looks like.

I get that, but since ALL A to D can only ever be precise to +/- 1/2 LSB the value is likely to "flutter" due to rounding (as well as noise).
This is why your  "if (controlValue != lastcontrolValue )" will return true a lot more often than necessary and lead to excess midi messages. Which was probably what led you to the "need" for a delay before the next sample.

My suggestion is that you test for a difference greater than the lest significant bit, I arbitrarily chose a value of 3, a better value could be determined from measured noise.

something along the line of
diff = abs(controlValue - lastcontrolValue)
If (diff > 3)
{
send it, update lastcontrolValue, etc.
}

Well, just a suggestion.

No, it doesn't affect the range of values, it merely filters out tiny changes (due to rounding or electronic noise).
It wouldn't prevent a change from 123 to 127, or from 126 to 122, or from 0 to 4, from 5 to 1, etc.
It allows changes from any value that has already been sent to any other value, as long as it is a DIFFERENCE of greater than 3 (or 4 or whatever you choose).
It does NOT affect the granularity of the pedal, i.e. steps of 5, 6, 7, 13 etc still get through.
It is just a noise and rounding error filter.

As I said, just a suggestion - idea sharing.

I admit to having submitted it as "something along the line of..." when I first saw the != and (based on other experience) the 1/2 LSB rounding issue jumped out at me.
Thinking out loud, etc.
I don't know what the value should be, but 1 is clearly wrong, perhaps => 2 would do it.

With a bit more thought a few more bits of code could handle whatever end/edge conditions are considered important.
64 might be in the middle of a special switching zone, hmmm... 
I don't know,,, does going from 3 to 0 REALLY matter ?  or 125 to 127 ?
Are 3 and 4 FUNCTIONALLY equivalent to zero anyway ?
Is there any real difference between what pianoteq does with 124, 125, 126 and 127 ? 
Personally I doubt that I can reliably produce the same dozen levels on a pedal anyway.

I'll give it some more thought as I shop for parts.

Hi,

yes, there are several ways to map 0-1023 to 0-127 (even a special function map() exists for this purpose) and >=2 could be a good compromise. --  I found another board, that has USB-MIDI-support built-in already! The "Teensy 2.0" is directly supported by the OS as an USB-MIDI device ("class compliant"). No helper-application like 'ttymidi' or 'hairless' is needed on the PC. In Pianoteq it appears as 'Teensy MIDI' in the Devices list. This is my new build:

Teensy is not a member of the Arduino family, but it can be programmed with the Arduino-Software, when Teensyduino is installed. It comes with an nice example called  AnalogControlChange, that I could easily adapt. It originally had a 20 ms loop BTW.

The code is a little different, but it does basically the same as my Arduino nano snippet:

/* 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 50 times per second,
  // to prevent a flood of MIDI messages (PS: with msec >= 20)
  if (msec >= 40) {
    msec = 0;
    int n0 = analogRead(A0) / 8;
    // only transmit MIDI messages if analog input changed
    if (n0 != previousA0) {
      usbMIDI.sendControlChange(controllerA0, n0, channel);
      previousA0 = n0;
    }
  }

  // MIDI Controllers should discard incoming MIDI messages.
  // http://forum.pjrc.com/threads/24179-Tee...midi-crash
  while (usbMIDI.read()) {
    // ignore incoming messages
  }
}

With around 20 EUR the Teensy 2.0 is more expensive than the Arduino nano and not as easy to flash for a beginner.

cheers

:-) 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
  }
}

Calculating "running averages" probably would be the best solution, ack. 

... 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?? ;-)

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?

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.

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...)

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

Much of the point I was trying to make is that we don't know what needs to be filtered out until we know what is actually there.
Consumer grade pedals are unlikely to have high grade components, so it is LIKELY that they will produce spikes.
What I think worth doing is to hook up the pedal(s) that you have and look at the midi stream with no filtering.
Watch it when clamped at about half pedal, when fully pressed and when released.
Press it slowly, release it slowly, capture that midi stream and look for SMOOTH transitions.
Also sudden stomps and releases.
If you see sudden jumps and/or bounces you will need to filter - for THAT pedal.

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