Recursive math question (chunk buffer analysis)

Feb 5, 2012 at 4:43pm

Recursive math question (chunk buffer analysis)

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)

– Pasted Max Patch, click to expand. –
#61623
Feb 5, 2012 at 6:27pm
– Pasted Max Patch, click to expand. –

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.

#222442
Feb 5, 2012 at 6:35pm

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….

– Pasted Max Patch, click to expand. –
#222443
Feb 5, 2012 at 7:13pm

@Wetterberg

That seems perfect. Doesn’t even need to be reset, which is ideal.

#222444
Feb 5, 2012 at 7:30pm

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…

– Pasted Max Patch, click to expand. –
#222445
Feb 5, 2012 at 7:49pm

not sure I understand correctly, but if this fixes it, look into using the trigger object more often (right to left order etc)

– Pasted Max Patch, click to expand. –
#222446
Feb 5, 2012 at 7:53pm

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?

– Pasted Max Patch, click to expand. –
#222447
Feb 6, 2012 at 12:59am

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.]

– Pasted Max Patch, click to expand. –
#222448
Feb 6, 2012 at 1:04am

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.

#222449
Feb 6, 2012 at 1:38am

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.

#222450
Feb 6, 2012 at 2:47am

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.

#222451
Feb 6, 2012 at 4:27am

What then? A fast metro or qmetro?

#222452

You must be logged in to reply to this topic.