Recursive math question (chunk buffer analysis)

    Feb 05 2012 | 4:43 pm
    Some I'm setting up some simple concat stuff using Alex Harker's descriptors/entrymatcher and I'm trying to analyze a buffer in chunks. So I need to spit out a series of numbers that are recursive.
    I have this solution but since it's based on bucket, I have to bang it twice to clear (which is spitting out analysis messages too).
    I basically want to have a list of numbers that go:
    0 100, 100 200, 200 300, etc... or 0 50, 50 100, 100 150, etc...
    here's my code where I can do 50ms or 100ms chunks at a time. (no externals used in the example)

    • Feb 05 2012 | 6:27 pm
      I'm certain it can be done even simpler, but this will reset every time you bang it.
      From what I understand, what you've got here is the equivalent of a for( loop, where we use the right outlet of uzi to iterate through it.
    • Feb 05 2012 | 6:35 pm
      there are probably lots of solutions to this... You can simply store the previous value in a [i] object. (see patch).
      But it would be easier to simply multiply the counter value with the chunk size for $1 and add the chunk size for $2. This way, you don't have to remember the previous value....
    • Feb 05 2012 | 7:13 pm
      That seems perfect. Doesn't even need to be reset, which is ideal.
    • Feb 05 2012 | 7:30 pm
      Hmm, order of operation seems super critical with uzi.
      So I'm sending these two numbers to [descriptors~], which is spitting out to analysis values (within the designated time) and I want to take the output from descriptors and pack that into [entrymatchers~] with the time index being first.
      In this mockup the [$1 $2] can function as descriptors to make it easy to see.
      I want the printed output to be:
      starttime (the first number of uzi output), value1, value2
      Using prepend has them out of line (the first value prints the last time of the last run. I tried [pack 0. 0. 0.] but that missed out on the first entry too...
    • Feb 05 2012 | 7:49 pm
      not sure I understand correctly, but if this fixes it, look into using the trigger object more often (right to left order etc)
    • Feb 05 2012 | 7:53 pm
      It's not completely clear what you'd expect the first entry to be here?
      In either case I'd use some pretty strict ordering at the end, [t l l l ] and such.
      So you want "uzi output" "some value analyzed after the function getting that uzi output" "some other value ditto"?
      If so, then yeah, I'd do [t l l l], send the values out, bring them back into the second and third inlets of pack 0 0. 0.] and close the deal with the uzi output on the leftmost, sending out the value.
      Does this exhibit the same problems?
    • Feb 06 2012 | 12:59 am
      I tried using a [t l], but I used [t l 0] which I think didn't like the single digit list coming in or something. It didn't seem to work right either way.
      I was going to do something similar to what you did, but I have a 2item list to feed into the [pack 0. 0. 0.], so I had to unpack it then repack it into a 3 item list (which seemed wrong to me), which is why I was trying prepend to avoid unpack/pack.
      So I'm using the recursive math to pick chunks to analyze (0 100, 100 200, 200 300), then each chunk of time has two values for it (loudness and pitch), so I want to pack into entrymatcher (basically like a smart [coll]) the first value of chunk analysis (the start time) and then the loudness/pitch of that chunk.
      This does the trick it seems (your code @wetterberg) just using [unpack 0. 0.] into [pack 0. 0. 0.]
    • Feb 06 2012 | 1:04 am
      Cool, glad to see it working :)
      Quick coolness note, btw: "pack" will unpack the list itself - you can just feed it into the middle inlet and it'll distribute the members itself.
    • Feb 06 2012 | 1:38 am
      That's good to know!
      It looks like doing uzi-based chunk analysis makes the computer lag a bit while it's happening (particularly for longer files), so I might need to do this another way. I tried defer after the uzi but it still lagged.
    • Feb 06 2012 | 2:47 am
      Uzi is not what you should be using for longish calculations. It hogs execution, to the exclusion of all else.
      It's the fastest way to get things done, but at the expense of being a good citizen.
    • Feb 06 2012 | 4:27 am
      What then? A fast metro or qmetro?