Best way to create generic audio analysis mapping? (map 3 parameters to 1)

    Apr 29 2012 | 2:33 pm
    So a big part of my main patch is a 'behind the scenes' audio analysis used to generate dynamic presets and parameter changing.
    I've already implemented this for my buffer/sampled based stuff where whenever a new sample is recorded, it analyses what was recorded, crunches a bunch of numbers, and creates relevant parameters for all of my buffer-based processing (granular synthesis, buffer slicing, concat/convolution etc...).
    I'm happy with how this much is working, but it was suuper tedious to put together as I made an algorithm for each individual parameter. It took me probably close to an hour for each. Now I'm not the best programming by a long shot so I'm sure my approach isn't the best way to do it. It also has some cool bits where it always weighs against the previous value, you can morph between the current and previous value, and there's a tiny random variation that's applied once per instantiation.
    Here's one of my mapping subpatchers as an example:
    I'm now moving onto real-time analysis for my input/output DSP/effects. I have waaay more parameters to control than before, so there's no way I can do an individual 'recipe' for each parameter. So I wan't to come up with something generically applicable to many things, with the output varying greatly by what the input is.
    I'm thinking of using 3 analysis parameters weighed together, to spit out a value. I'm using Alex Harker's descriptorsrt~ to do my analysis and have 8 things I'm looking at (ranging from amplitude, to spectral centroid etc..). I think have 3 feeds off each of those parameters ('raw', 'smoothed', and average over last 2min).
    So as far as the actual number crunching, I'm using expr and just cobbled this simple weighting formula:
    expr (($f1 * 10) + ($f2 * 5) + ($f3 * 1)) / 16
    So a 10 to 5 to 1 relationship between the three incoming parameters. So each thing will have a primary, secondary, and tertiary control.
    It's working, but I must imagine there's a more interesting way to handle that. So basically trying to come up with an abstraction for producing a single value from three incoming values, in a relevant, but complex way.
    Here's my patch:

    • Apr 29 2012 | 2:37 pm
      I also have decided that I want 5 possible "modes" for this kind of real-time analysis.
      1 - Only change the parameter once per patch instantiation 2 - Change parameter once for every time the effect is engaged 3 - Change parameter in real-time, but with manual control of effect on/off 4 - Turn effect on/off based on analysis 5 - Turn effect on/off based on analysis AND change parameters in real-time