Hello everybody,

this is my first post and I am a Pure Data Beginner.

I would like to smoothe out an Array in a specific way.
This for example:

This curve is meant to rise until the end. The Values arent supposed to fall at any point. Two same values after each others is also not ideal. In my original patch, I recorded a Pitchbend Automation with 16384 Values. X and Y. During recording, there happened a few midi values, which didn't fit to the rest.

I would like to smooth out the recorded curve, that it is never falling an rises up until the last x value. Like here in the manually corrected example.

I have an Idea, but as I am a beginner I am very frustrated at the moment. tried to get it to work three days.

My Idea was to create a loop, which goes through the array and stops at position "n", if value x on position "n" is smaller or the same value like at position "n-1". Then a counter starts at this position and counts until a x value is bigger than the x value at position "n-1".
If it is bigger, the counter adds the last number. After that the Patch looks what the difference is of Value x on position "n-1" and Value y on position "n-1" plus the Counter Value. After that it divides the difference into the Counter Number as the value "Increment". Then the Patch goes back to Position "n" and adds up the P Value. Then it goes to position "n+1" and adds the Value "n" plus the P Value * 2 and so on, until it reaches the highest Point. After the whole loop beginns again, until it smoothes out the Courve completely.

How can I do that? Maybe there exists already something like that? A patch or so? I appreciate easy beginner tipps!

Thank you very much!!

@Bangflip In the smoothing algorithm you proposed, what would you want to happen if the last value in the raw curve wasn't the largest value?

@jameslo hmm, I would say, the last value should be 1 bigger then the nex-to-last value. If that isn‘t possible, then it can be just the value of the next to last value.

@Bangflip I would start by making a patch that takes a lower and upper index such that curve[lower] < curve[upper]. That patch would perform the interpolation you described to substitute for the negative portions of the raw curve, and if the indexes are adjacent then it would just output the adjacent curve values. You can test that patch until you are convinced it's working. Then your problem is mostly reduced to finding all the lower and upper index pairs, with one special case if the largest curve value isn't at the end of the input table.

The (lower, upper) pairs for your example are (0,1) (1,4) (4,5) (5,6) (6,8) (8,9) and (9,10)

I tried using [lop~] but the problem is that its beginning state is always 0, which may or may not be what you want. Also, lop~ may allow some negative slope to pass through, which I'm gathering you don't want.

@Bangflip Try the vertical fader...... or the mouse if you have the cyclone/mousestate installed.
smoothe.zip
File to open....... smooth_triple-help.pd.
I have set alpha to 0.05 which seems to work well.
It is far too complex probably for what you want to achieve but hey...... it was a good evening....... and if it gets the job done then that will be a result.
David.

Yes, thank you all! I also tried lop yesterday. Wasn‘t exactly, what I was searching for, but it is cool, that I have it now in my arsenal!

I have to go to work now. (Germany; 8 am at the moment) Will try out your help in the evening.

What happens if you move the fader up and down and up and down?

try the median

medianate_1a.pd

You might insert a percentaged threshold.

(Or do the up/down trend-thing with a threshold (lowpass) of step counts ...)
...
@Bangflip said:

I would like to be very exact, as I plan to do something like a mackie controller midi converter in pure data for my controller. To use it with other DAWs. And I found out, that my controller (Steinberg Houston) has a volume curve integrated, which is different from the original Mackie Universal Pro Controller.
[...]

This sounds like a different topic to me.

motorfader

Use the volume-curve as inverse transfer function to make it linear:

a) drive the motor fader with a linear counter, step by step
b ) record the data curve
c) subtract the curve from the linear line
and
d) use this as transfer function by subtracting the incoming data from that

i.e. remapping, subtract the error function

Hmm, still haven‘t got time to check with PD.

But what you wrote last:

I plan to do exactly what you wrote, If I understand it correctly. Everytime I write the Array Values in PD, there are these mistakes. I record the Fadermovement automation of my DAW Cubase and send the Values to PD with a virtual midi port. I record the values extra slow and recorded the 14 bit values in half an hour. But everytime the line isn‘s smoothe. And I notice that than, if I move my motorized Fader with the Array, drawn in Pure Data. So I would like to smoothe out the line first, and than do the Hardware specific curve correction, you mentioned.

Hard to tell without more details. I also have no experience with motorfader-hacks, but am interested.
At a precision of 1600 values it is very likely some subtle hardware bouncing, resonance of motor, dirt, footsteps or similar ?
How slow do you drive them? (now I read 1/2 h, makes about 1 second each step). (EDIT oh! 16000! 8/second!)
I would maybe try to eleminate the discontinuity on the hardware / measurement side, instead of cheating.
Do several measurement runs, instead of one shot only, and compare the data.
Also try to drive it from Pd instead of Cubase. Very slowly. Calibrating. Remember, there is some latency, too.

Later in use, you might use some smoothing filter, too.

Anyway, this is what you where asking for, I think:
new romantics )

align_up_down_6c.pd
EDIT: updated again and again

@lacuna said:

Hard to tell without more details. I also have no experience with motorfader-hacks, but am interested.
At a precision of 1600 values it is very likely some subtle hardware bouncing, resonance of motor, dirt or similar ?
How slow do you drive them?
I would maybe try to eleminate the discontinuity on the hardware / measurement side, instead of cheating.
Do several measurements, instead of one shot only.
Also try to drive it from Pd instead of Cubase. Very slowly. Calibrating. Remember, there is some latency, too.

Anyway, this is what you where asking for, I think:
new romantics )

align_up_down_3c.pd

@lacuna Hey, thank you very much, for your help and the patch!

I will now describe more precisely, what I would like to do. I thought, it would be a little bit off topic, because it is a bigger project.

Also, I think, I described it not correctly with the motorfader recording. That isn't true. My english is not the best, so my formulations arent always on point, but I will try my best.

So, to describe my Project, I am working on:

I have an old 20 years old "Steinberg Houston" Midi-Controller, which works via the Mackie Protocoll. It was specifically designed as a Cubase / Nuendo Controller back in the days. Cubase / Nuendo are also, as far as I know, the only DAWs with which the controller is working nowadays.

Almost all DAWs are supporting the specifications of a "Mackie Universal Pro" Controller. So I would like to program a Midi-Data Converter, so I can use my controller with other DAWs as a "Mackie Universal Pro" Controller.

At the moment I already found out, which midi Data the faders send and which midi data the DAW Cubase sends to the Controller. I also converted the Midi Data, so that I can use the controller faders, while Cubase thinks, it is a Mackie Universal Pro.

So, but the problem, why I started this thread is, that I noticed, that the Mackie Controller needs to get different values from the DAW to get the right fadermovement done, than my Steinberg Houston. For example: When I set my Fader in the DAW to 6 dBFS, my Conroller Fader moves correctly to 6 dBFS, as that is the highest fader value in Cubase. Also the other way around. If I set the Fader in Cubase to -00 dBFS, also my Fader of the controller is at the right position. So the lowest and highest values are correct. But if I set -20 dBFS in Cubase via Mackie UP Mode, my controller sets the fader to -10 dBFS. In the original Cubase "Steinberg Houston" mode, the fader movements are very precise and always are reflecting the number, which I set in the mixer in Cubase.

So my Idea was, to first send all Pitchbend values from Pure Data via Midi to Cubase in Houston Mode. I tricked Cubase in thinking, I would use the Houston Controller, but used Pure Data instead, to be very precise. Then in the preferences of cubase, I deleted all automation smoothing and set up a tempo in Cubase and with Metro in Pure Data, so that each 8th note, one pitch bend value is send to Cubase. and I synchronised both my DAW Cubase and Pure Data with a C3, sent from Cubase, when I start the Playback in Cubase. This C3 is then sent to Pure Data and than acts as a bang in PD to start the metro and sends the Midi Values. This midi Values are written then in Cubase as a Automation.

Then after that, I did the same process again, and recorded the Automation Values in Pure Data. But these values arent as smoothe as I would like to have them, even I recorded them that slow, that I set a metro of 8 per second which is for the 14 Bit values something like half an hour. The faders are the most important feature of my Controller for me, so I take the right amount of time to get them very precisely.

Between: I also found out the SysEx values to display what I want on my two rows houston display with Pure Data which was fun.

uww

I updated my last post and think it is still valid.

But really, at a resolution of 16000 values on a fader length of maybe 10cm? This is almost a microphone! 20 years old ...
I wouldn't care too much about precision of the numbers. Take care to soothe any bigger jumps with the median-filter in realtime and you're done!?

@Bangflip said:

When I set my Fader in the DAW to 6 dBFS, my Conroller Fader moves correctly to 6 dBFS, as that is the highest fader value in Cubase. Also the other way around. If I set the Fader in Cubase to -00 dBFS, also my Fader of the controller is at the right position. So the lowest and highest values are correct. But if I set -20 dBFS in Cubase via Mackie UP Mode, my controller sets the fader to -10 dBFS. In the original Cubase "Steinberg Houston" mode, the fader movements are very precise and always are reflecting the number, which I set in the mixer in Cubase.

This is probably easy. I know consoles have some arbitrary? mapping.
You might easily match them with [pow]

nonlinearmap.pd

@lacuna said:

This is probably easy. I know consoles have some arbitrary? mapping.
You might easily match them with [pow]

nonlinearmap.pd

Hey, thank you very much. Yes that could be also a possibility. Smoother than a math function it can't be, haha.

Anyways. Thank you for your nice horizon patch. Did exact what I wanted to do!!! Now there arent any drops that arent made any sense. Will do also try out the smoothing suggestion to get the smoothest experience, possible, with this old device! But it is still really cool nowadays, even if it is 20 years old. Lot's of midi Buttons one can assign and it's build Quality in terms of materials is very good, compared to todays standards:

These are the two curves, I came up with now. Looks very nice so far with your horizon patch.

... And Pd's Midi i/o and schedueling happens between the audioblocks of 64 samples only. You might have jitter at fast movements and low samplerates?

I think the fastest response you could get with standard Vanilla, is starting PD from the console with -noaudio -nosleep flags and maybe -nogui ... if you care about this.

@whale-av said:

@Bangflip Try the vertical fader...... or the mouse if you have the cyclone/mousestate installed.
smoothe.zip
File to open....... smooth_triple-help.pd.
I have set alpha to 0.05 which seems to work well.
It is far too complex probably for what you want to achieve but hey...... it was a good evening....... and if it gets the job done then that will be a result.
David.

Very interesting patch. Thank you also very much for your helpfile. Didn't ended up using your patch for my curve, but I will defenitely safe it for future needs and learning purpose. You did some interesting things with pure data, which I didn't know. Maybe I will also do a combination of your patch for my controller converter and the patch of lacuna.

@lacuna said:

I think the fastest response you could get with standard Vanilla, is starting PD from the console with -noaudio -nosleep flags and maybe -nogui ... if you care about this.

Yes, I care. Thank you for the suggestion.

@Bangflip Maybe you have seen this discussion...... https://discuss.cakewalk.com/index.php?/topic/19846-mackie-control-questions/

The Mackie control is supposed to spit out a direct linear midi slope...... Mackie Control Midi Table.pdf and only clockwise/counterclockwise and count for rotary encoders (like the BCF2000).

In the discussion above "skavan" has given an approximate formula for a linearization of the Cakewalk curve. Maybe there is other information out there or a question on a Cubase forum would shed some light.
Or maybe the curve is the same in Cubase as a lot of the software developers were moving around as Cakewalk folded.

If you have jitter in the slope then make absolutely sure that you have no midi feedback anywhere in your setup....... I am a bit embarrassed to mention that as it seems you know what you are doing......
David.

@whale-av said:

@Bangflip Maybe you have seen this discussion...... https://discuss.cakewalk.com/index.php?/topic/19846-mackie-control-questions/

The Mackie control is supposed to spit out a direct linear midi slope...... Mackie Control Midi Table.pdf and only clockwise/counterclockwise and count for rotary encoders (like the BCF2000).

In the discussion above "skavan" has given an approximate formula for a linearization of the Cakewalk curve. Maybe there is other information out there or a question on a Cubase forum would shed some light.
Or maybe the curve is the same in Cubase as a lot of the software developers were moving around as Cakewalk folded.

Hey, thank you for the discussion link!

Also for the Mackie Control Midi Table. This link, I already knew, and is very helpful.

If you have jitter in the slope then make absolutely sure that you have no midi feedback anywhere in your setup....... I am a bit embarrassed to mention that as it seems you know what you are doing......
David.

I already made sure, that there isn’t any feedback. I also think it has maybe something to do with my configuration or the values, Cubase sends out, because the little midi drops are always the same with continuus raising of the Cubase Fader.

I am experienced with sound design, yes, but I am more a creative, not a technican or programmer. It‘s a project, to invest some time and learn pure data for me.

I am thankful for every tip.

Hey, thank you all, for your help! With the help of you, I have now made a curve correction with my Smoothed out Arrays. The Motorfaders move really smoothe now, without wiggle, as it was before.

The curve isn‘t perfect, so I need to do some finetuning, but the fadermovement is!

@Bangflip Can you please post your noisy data so I can try a different smoothing algorithm on it? I'm porting something from the Arduino world for fun.

@jameslo said:

@Bangflip Can you please post your noisy data so I can try a different smoothing algorithm on it? I'm porting something from the Arduino world for fun.

Yes, I deleted already my old data, but recorded this curve today, that you can use it. It's an strange curve.

I got this curve by send the pitchbend Data from Pure Data to Cubase and record as automation. All values linear via Mackie Mode. Then I switched Cubase to "Houston" Mode and recorded the the output of cubase with pd into the array. The result is always the same. I thought it has maybe to do with the 20 years old algorithm for my houston hardware. Because if I send the midi data via mackie mode to pd, it's much smoother, without these artefacts.

The curve you can see here is also a little bit different in what I described after starting this thread, because the artefacts are in the opposite direction. But it's clear to see with the eyes, how the curve should be. Would be cool, if you could also post, what you came up with. I am interested in the result.

For Forum Request.pd

@Bangflip I don't really understand this thread with respect to the hardware, but I was just curious if this thing I ported from the Arduino library "ResponsiveAnalogRead" (https://github.com/dxinteractive/ResponsiveAnalogRead) could remove all the negative first differences without making any assumptions about which way the signal should be heading (it can). I think it's just a self-adjusting version of the exponential moving average stuff that @whale-av posted. Put both files in the same directory and open "houstonData.pd" to run it.
houstonData.pd
responsiveExpMovgAvg.pd