• lacuna

    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?

    posted in technical issues read more
  • lacuna

    @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~]

    posted in technical issues read more
  • lacuna

    @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

    posted in technical issues read more
  • lacuna

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

    posted in technical issues read more
  • lacuna

    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?

    posted in technical issues read more
  • lacuna

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

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

    posted in technical issues read more
  • lacuna

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

    posted in technical issues read more
  • lacuna

    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!

    posted in technical issues read more
  • lacuna

    @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?

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!