It has to be in samples in the source buffer, not the file. Your source buffer can be made of many things.
In your case, let’s say you have a live buffer. You know the sampling rate of Max, so you know the SR of the buffer. Then your ‘specific chunk’ to analyse will be (time in MS) * SR / 1000.0. Your duration of analysis will be (duration in MS) * SR / 1000.
So for a 44.1kHz running process of RT buffers, wanting to analyse the 3rd second (between second 2 and 3) you would get numframes to 44100 (one second) and startframe to 88200 (after 2 seconds)
So it’s in samples then - that makes sense. I was confused by the documentation.
Just noticed that there are two versions of bufloudness~ in my search path - Max found a version in your Cloud v2.1 M4L patch. Not sure if that explains the documentation though…
(a few moments later)
I’ve made sure I’m on the latest version as linked by @rodrigo.constanzo and made sure there are only one set of objects in the search path but the documentation for remains the same. I’m using the PC version so maybe this version of the fluid.bufloudness~ reference is not yet updated?
My wise explanation is that John is correct that this is what the reference currently says, presumably because I missed it (along with much else) whilst spring cleaning the reference files. I can see how the combination of (a) referring to an attribute that is now called something else, and (b) missing the plural of samples wouldn’t aid understanding.
It’s probably broken in the same way for a lot of the buf* objects that ‘wrap’ real-time ones. Sorry everyone.
thanks @weefuzzy - Just got this slightly ambiguous error message in the max window:
fluid.bufloudness~: Not enough channels in buffer
If I open the help file it goes away so I’m guessing I didn’t copy something over - It’d be cool if the error was a bit more specific about which buffer - ie the source or the destination buffer didn’t have enough channels.
Agreed. I just had to search the code for it So, it will definitely be improved.
It happens when @blocking is set to 2 in a buf object, meaning that it runs all the processing directly in the scheduler thread, but won’t attempt to resize any buffers~. So, getting that could mean either:
the features buffer from the help patch wasn’t copied over with the object, and will have ceased to exist when the help patch was closed (ergo, there are no channels available to write to)
there is a features buffer, but it doesn’t have as many channels as requested.
@blocking 2 is tricky when you’re still developing, because all the buffers need to be exactly the right size (and the error messages are pretty lousy, it turns out).
Ahhh! That explains a thing or two. I didn’t realise that @blocking 2 didn’t manage the buffer sizes. That helps me understand why @blocking 1 is causing a little hiccup in the constant graphic drawing i’m doing in my patch. Ironically @blocking 0 gives me the worst hiccuping.
In this circumstance I think I can get away with @blocking 1 as it only seems to pause the graphic drawing on the first call for processing.
Yeah, if it’s a small frequent job, then @blocking 0 will probably cause more overhead creating and launching a new thread than the original job cost. Given that all that happens on the main thread, it will be particularly bad for interrupting drawing things.
The burp on the first run probably is due to buffer resizing. If that size isn’t going to change, could be worth hard coding it and using @blocking 2, once you’re happy everything is working.