Hello,

I want to decelerate values that I get from the pix_blob object size output? I have tried to use pipe / debounce / line. Is there sort of damper object?

@RihardsV You could do this.........
sampled.zip
David.

If you need ALL of the data...... slowly..... then write to an array and read slowly from the array....

thank you.

Array is the way that I needed.

@RihardsV check the mapping abstraction (in pd-extended (RIP)). [resample] I think...
Cheers~

Hi, thanks for that I will check it out.
this is how the patch is looking like. basically size of blob is changing speed of a video. It still should be very responsive. but the values are to fast so its looks more like jumping around. Array is working at this speed but if I slow it down it start to look like its lagging.

@RihardsV Hello again...... could you upload your patch? It's a lot of work to build it again for testing! Could you put the comments in English as well please.... that might help as well..
I cannot help you myself.... [pix_video] crashes Pd on my crumby MacBook Pro....
David.

here is the patch.

Loreta.pd

@RihardsV I wonder if you have a different problem? Try this......
loretta2.pd
It does not matter how fast I move the test fader, the video looks good. Obviously the jumps between frames are visible at low frame rates, but that is normal.
I am testing with a large de-interlaced avi file. Maybe yours is variable frame-rate?
David.

At the moment it is working. But if you try to change metro, from 100 to 500+, for recording and for playing back the {tabwrite], then you start to notice difference between interaction and the video playback. It's not anymore so smooth. So my question is is there some other ways to slow down the blob size parameter data flow?

in general this is working and its fine for me. Its more my curiosity to know is there other way. Your firs solution before the array was interesting for me, but didn't do job so wall.

Thank you for your time array tip was good.

I tried [resample] as well that didn't work out that good as array. Thanks for the tip EEight it will work for something else in next projects.

@RihardsV Yes, if you slow down the array then there will be a lag between the blob changes and the frame-rate changes..... because the data to change the metro is arriving later (slowed down). That is why I thought maybe the resample that I posted in sampled.zip might help. With the [inlet rate] set to 2 it will output current blob data every 2ms, set to 4 every 4ms etc. ....... so the data rate will be slower, but it will arrive at the right time.... so no lag between blob changes and frame-rate changes.
My example was not so good...... 500 or 1000 as [inlet rate] would give too slow a resample rate (every half or whole second). Try it with 1, 2, 3, 4 etc. ?
I don't think that you need ALL of the blob data for your purpose..........

But maybe your blob data is "jumping about" and not smooth. You could smooth it maybe like this.........
filter data.zip (extended and vanilla)
It will only output data that has changed by less than a set deviation. So if your deviation is set to 10 and the data is 5, 11, 15, 150, 110, 300, 20, 22, 28 it will output 5, 11, 15, 22, 28.........
It might help?
If you look at the blob data (in the array, or using [print] you will have a better idea, and could build a better tool maybe?
David.

thank you I will look at it.