Slicing, analysing and comparing

[jamesbradbury]

@weefuzzy

Of course, if all the cool kids are using node.js now, I’m sure a d3-based animated visualization is just days away…

They possibly are but there isn’t a meeting for a while…

[tedmoore]

Here’s the tool. Feedback very welcome. https://github.com/tedmoore/PlotXYColor

Also, I made a little demo video as that’s all the rage now in our remoteness.

T

[weefuzzy]

Great stuff @tedmoore, that looks really powerful.

[tremblap]

Thanks for this, it is amazing!

@tedmoore

Also, I made a little demo video as that’s all the rage now in our remoteness.

The little corner smile when you say “oh and it resizes too” is worth the whole video

Seriously, great tool. I was pained to see how long it took for the analysis but that is our fault, and soon improving a bit

[tedmoore]

@tremblap

The little corner smile when you say “oh and it resizes too” is worth the whole video

sometimes it’s the little things that can bring joy

[tedmoore]

sorry this is deviating from this thread’s topic, feel free to move if appropriate

@tremblap

I was pained to see how long it took for the analysis but that is our fault, and soon improving a bit

I actually had a question about this. The way I’m doing these analysis is getting the sample indices from FluidBufNoveltySlice and then using those indices to do a separate FluidBufSpectralShape–passing in the startFrame and nframes for each .process. This seems to work well, but I could imagine (and I believe it’s similar to what you were doing in Max last Friday) running FluidBufSpectralShape on the whole buffer and then using the slice information from FluidBufNoveltySlice to extract the data from the appropriate slices of time (probably by doing a FluidBufStats and specifying the startFrame and nFrames on the resulting buffer of the FluidBufSpectralShape).

But of course the startFrame and nFrame that would need to be passed to FluidBufStats in this case (fft frames) is not what would come out of FluidBufNoveltySlice (samplerate frames).

I know I could do some math to pass appropriate slice start and slice length info, but I tend to try to avoid being too in the weeds with frame sizes and hop sizes unless I have to be (as demonstrated by my avoidance of it here).

Is there some shortcut way of thinking about this I’m missing?
Would approaching the analysis that way be faster?

Thanks!

[tremblap]

@tedmoore

Is there some shortcut way of thinking about this I’m missing?

there is: buffers returned after spectral frame analysis have the right SR - for instance if the hop size is 512 (default) at 44.1kHz you get a SR of 86.13 frames per second. Magic!

@tedmoore

Would approaching the analysis that way be faster?

That is a good question. I don’t think so, except if you reanalyse to change time windowing, in which case running the descriptors as time series first, then bundling in time chunks, saves on all the descriptors maths.

[tedmoore]

@tremblap

Magic!

Ah! Yes, I remember that now. That is a nice design implementation.

[buscon]

thanks a lot, excellent work!

[rodrigo.constanzo]

This is really great!

I don’t know if there are any plans for having some kind of scatterplot visualizer for Max, but it would be incredibly useful.

[weefuzzy]

The birthing stages of such a thing can be seen in the current alpha helpfiles for some of the new objects. Not yet a thing of beauty, but definitely on the horizon.

[rodrigo.constanzo]

I need to go through the more recent helpfiles as the first batch didn’t have much meet when I initially went through them all.

[alicee]

@tedmoore - you champion. Thanks so much for sharing this and writing such beautifully clean code.