How could i mesure the peak frequency of a moving nonresonant analog filter without a feedbackloop between its audio output back into its audio input?
I do have a calibration patch for resonating filters and oscillators.

What would be a good way to do
this? White noise into the filter > FFT > Findung the peak? And slowing the whole calibration procedure by the overall latency. Or better with a sine sweep instead of noise for being independend of randomness.

How can i find such a peak?

@ddw_music said:

[fexpr~] appears to be basically undocumented -- opening help on an [fexpr~] object goes to [expr] help, which neglects to explain the difference between [expr~] and [fexpr~].

http://yadegari.org/expr/expr.html

but there's no [>~] object, so how would one check that at an audio rate?

yes, I do it with [expr~] or [fexpr~]

@ddw_music you can get rid of the floating point when multiplying by 10s and dividing at the end.
for example:

[* 10000] 
[mod 20000]
[/ 10000]

fmod() you can use in [expr], [expr~] and [fexpr~]

And notice in the helpfile of [expr] >> [pd [expr] examples] the use of floats and integers

@nico or [sel] [select] instead of [==]

Now I found A-weighting is not the same as equal loudness:
http://www.sengpielaudio.com/calculator-dba-spl.htm

There is no formula for calculating "equal loudness"

equal loudness is a measured curve, tested idealized with sine tones, with no reverberation:
http://www.sengpielaudio.com/Acoustics226-2003.pdf

What is best to adapt such a curve without degrading the sound? With a FIR filter?

Has anyone already applied A-weighting in PD?
How would you start?

https://en.wikipedia.org/wiki/A-weighting

merci beaucoup!
I just edited my first post and added clk lib.

This lecture at Linux Audio Conference 18 explains it in detail:

https://media.ccc.de/v/lac2018-42-ableton_link_a_technology_to_synchronize_music_software

It is just the same as
https://forum.pdpatchrepo.info/topic/12387/quantising-in-real-time-for-step-sequencer/4
just smarter and shorter.

There is also shown how to read the array in steps with [tabread].
You can implement midi stuff with objects like [notein] [mtof] [ftom] ect.
Store a higher range of values, instead of 0 and 1 only, as it is done here.

Understand [trigger] [t] and [float] [f].

I would highly recommend you to go through the tutorials and example-patches of PD!

@Nicolas-Danet said:

control messages and compute audio vectors of the DSP graph are interleaved operations. The internal audio vector size is 64.

[64][control][64][control][64][control][64][control]

Ok, i see.
But I read control messages are first, then audio. f.e. [loadbang] is proceeded before an upcoming audio-block.
And [vline~] is calculated and "drawn" before and "modulating" the *following * audio blocks.

[control][64][control][64][control][64][control][64]

What's happen in a 1 sample reblocked subpatch? In short, instead of compute 1 vector of 64 samples, it computes 64 times following a vector of 1 sample.

And there is no way to change this interval rate of 64?
Is upsampling in a subpatch increasing the computation time-interval of control-messages?

The tricky stuff with real time audio is not to do the things fast, but do things fast at the right time. Wait the sound in, deliver the sound out, compute the next sound and wait. When i benchmark my fork for instance, most of the time is spent in sleeping!

I see. In the analog world it is very different. This is why we have the buffer-latency in digital everywhere:

...incoming audio-samples in blocks, computation, audio out, and again...

And the control-domain every 64 samples.
For me as "user" of PD this is confusing.
So every object with a [v ...] will be sampleaccurate on point in upcoming audio-blocks, as long as it is not needed more often then 64 samples later!??? i.e. as long it is not starting several times in a smaller interval then 64 samples?