Forums > MaxMSP

Please explain waveform~'s behavior

December 29, 2006 | 9:05 pm

I just noticed that when selecting all in a waveform~ the end point of the selection is not the total length of the buffer~. I am pretty sure I’ve noticed that with very short files this difference is larger than with very long files (which seems counterintuitive if this were a "feature"). I’ve been searching the docs and archives but don’t see any previous mention of this behavior.

This is throwing off some calculations in a patch when pitch scaling with gizmo~ so that different length buffers~ can playback at the same speeds but at their original pitches without FFT time stretch – however the error is too small for my human ears to notice so it’s not really a huge deal and if it were I could work around it with info~.

That being said, I am curious why this is the case and/or if I should report it as a bug (using the proper guidelines of course). Here is a demonstration:

max v2;
#N vpatcher 14 59 614 459;
#P window setfont Helvetica 9.;
#P window linecount 1;
#P newex 156 54 47 1376265 loadbang;
#P newex 135 78 40 1376265 t b b b;
#P newex 166 245 27 1376265 t b f;
#P flonum 267 336 71 9 0 0 0 21 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 51 31 40 1376265 replace;
#P newex 267 303 27 1376265 – 0.;
#P flonum 397 224 71 9 0 0 0 21 0 0 0 221 221 221 222 222 222 0 0 0;
#P button 319 139 15 0;
#P window setfont "Sans Serif" 9.;
#P message 201 103 51 196617 0 -1 0 -1;
#P window setfont Helvetica 9.;
#P flonum 166 224 71 9 0 0 0 21 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 319 179 105 1376265 info~ goo;
#P message 52 103 40 1376265 set goo;
#P newex 51 54 94 1376265 buffer~ goo anton.aif;
#P window setfont "Sans Serif" 9.;
#P user waveform~ 52 124 200 74 3 9;
#W mode select;
#W mouseoutput continuous;
#W unit ms;
#W grid 1000.;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 1;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 190 137 255;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P window setfont Helvetica 9.;
#P window linecount 3;
#P comment 344 336 100 1376265 < - difference between file length and selection end;
#P connect 10 0 2 0;
#P fasten 13 1 3 0 155 100 57 100;
#P connect 3 0 1 0;
#P fasten 14 0 13 0 161 75 140 75;
#P connect 2 1 13 0;
#P connect 1 3 5 0;
#P connect 5 0 12 0;
#P fasten 13 0 6 0 140 100 206 100;
#P fasten 6 0 1 4 206 121 245 121;
#P fasten 12 0 9 0 171 286 272 286;
#P fasten 8 0 9 0 402 248 272 248;
#P connect 9 0 11 0;
#P fasten 12 1 9 1 188 267 289 267;
#P fasten 13 2 7 0 170 100 324 100;
#P connect 7 0 4 0;
#P connect 4 6 8 0;
#P pop;


December 29, 2006 | 10:34 pm

i can confirm, but i dont think it is a bug.
there is a difference of approximatively 1 sample with 2second long files.
under 1 sample for a three minute long file.
around 2 samples for 170ms long files.

it might have to do with the "pixel to ms" conversion/accuracy ?

Quote: Lewis wrote on Fri, 29 December 2006 13:05
—————————————————-
> I just noticed that when selecting all in a waveform~ the end point of the selection is not the total length of the buffer~. I am pretty sure I’ve noticed that with very short files this difference is larger than with very long files (which seems counterintuitive if this were a "feature"). I’ve been searching the docs and archives but don’t see any previous mention of this behavior.
>
> This is throwing off some calculations in a patch when pitch scaling with gizmo~ so that different length buffers~ can playback at the same speeds but at their original pitches without FFT time stretch – however the error is too small for my human ears to notice so it’s not really a huge deal and if it were I could work around it with info~.
>
> That being said, I am curious why this is the case and/or if I should report it as a bug (using the proper guidelines of course). Here is a demonstration:
>


December 29, 2006 | 11:25 pm

I was thinking about this as well, but shouldn’t different size waveform~s (displayed size on the screen) give different size "errors"? I tried resizing and the error stays the same (I’ve not tried a different screen resolution though).

Quote: (karrrlo) wrote on Fri, 29 December 2006 14:34
—————————————————-
> it might have to do with the "pixel to ms" conversion/accuracy ?
>
—————————————————-


January 2, 2007 | 2:02 am

i know i tried that as well.
one should check if the same problem happens when zooming in or out of the waveform~.
hopefully somebody wil come up with better answers then me ;)
best,

Quote: Lewis wrote on Fri, 29 December 2006 15:25
—————————————————-
> I was thinking about this as well, but shouldn’t different size waveform~s (displayed size on the screen) give different size "errors"? I tried resizing and the error stays the same (I’ve not tried a different screen resolution though).
>
> Quote: (karrrlo) wrote on Fri, 29 December 2006 14:34
> —————————————————-
> > it might have to do with the "pixel to ms" conversion/accuracy ?
> >
> —————————————————-
>
>
—————————————————-


Viewing 4 posts - 1 through 4 (of 4 total)