Hi!

Is there a way to filter out sudden jumps of values? Let me be more specific; I need to control oscillator's frequency with a ribbon resistor. Everything sound ok until I lift my finger off the resistor, actually, the output suddenly jumps to it's highest value. Ideally, it should stay at the last note I played, something like "hold" function on some keyboards. I know that it can be done in electronic part of my controller, but I wonder is there a way to do it in a patch. I'd like to make it in vanilla since it's much more responsive in my system (winxp).
thank you.

Hi,

every time you receive a value from the controller, you could substract it from the latest control value (stored in a [f ]) and then make it positive using [abs ]. This computed positive difference could be tested with a [< ] triggering a [gate 1] in order to send it to an ouput only if the increments between ctrl values are smaller than a desired threshold value.

This should work.

Nau

Hi Nau
thank you for your suggestion... but, I think I wasn't clear enough, so I will attach the patch. You'll see in a "ribbon_substitute" subpatch, there is an array with stored data from the ribbon resistor. In the second half of it, there are three sudden jumps which happened at the times I lifted my finger off the resistor.

As longer I think about the problem, I am more and more sure that it is not possible to solve that problem in a patch. How to distinguish sudden jumps in actual melody from the ones happened by lifting the finger or stylus off the ribbon? But who knows, this forum is a great place...

http://www.pdpatchrepo.info/hurleur/ribbon_forum1.zip

Ok, now I fully understand. It should be possible to detect 'sudden large rises' anyway in the signal domain, but it is clearly complicated to 'tailor' the control value when such peaks arise, i.e. cut the spikes leaving a smooth signal.
It seems much more interresting to work on the ribbon side, as you mentionned.

What kind of signals do you receive from it ? I've tested a 'dj-style' touch ribbon, it was giving two midi controllers values : one was the position value, and another one acted as a bit (0 or 127) in order to indicate if the finger was touching or lifted.
For sure the ribbon must be the solution...

Nau

What kind of signals do you receive from it ?

It's a membrane linear potentiometer, connected to arduino, so it is giving desired 0-1 range.

I've tested a 'dj-style' touch ribbon, it was giving two midi controllers values : one was the position value, and another one acted as a bit (0 or 127) in order to indicate if the finger was touching or lifted.
For sure the ribbon must be the solution...

Yes, two ribbon setup (pressure and position) could solve the problem, something like this:
http://www.coagula.org/content/pages/coagula-midi-ribbon-controller-20-1

thank you for your time!

Hello everybody:

@sinewave said:

Hi!
[...] I'd like to make it in vanilla since it's much more responsive in my system (winxp).
thank you.

@sinewave: What do you mean by saying that vanilla is more responsive in winxp? Is it faster o consumes less resources than pd-extended? Do you know if vanilla is 'more responsive' than pd-extended in other OS, like GNU/Linux? Interesting matter...
All the best.

Sumidero

Ps: "Na rubu povijesti": nice track. Reminds me of "A warm place" from NIN.

Hi Sumidero!

Yes, pd-vanilla is "faster" than extended, I can tune it to about 6 ms of audio latency which is more than ok for me and my needs. But I have to say I didn't tested it on different OS. I've read somewhere that Linux users don't suffer of high latency problem, so maybe it's just a combination of OS and hardware I'm using. Since I am just an average computer user, I cannot tell why the vanilla package is better for audio on my system. Regarding the CPU performance, I can't tell the difference because the meter showed the same reading on the same patch in both vanilla and extended, though I didn't tested nothing more than my own patches which are very simple. I'll put some coarse comparison here, maybe someone find it useful;

pd-extended pd-vanilla
min latency (ms) 36 6
number of audio channels available 2in 2out 26in 26out (hardw. max)

tested on winxp and RME HDSP 9652.

Hope that helps someone who is struggling with latency...

Ps: thanks for listening the track