Onseg durations column

[ep0]

Hello all,

I’m looking at the max pipo.onseg helpfile and there is something I don’t understand regarding the @onseg.duration attribute.

In the offline example using mubu.process, the value in the duration column (matrix view) refers to the segment that starts with the marker on the same line (as you would expect).
But in the real-time pipo~ example, the values in the duration column appear to be shifted down a line so that the duration value refers to the audio segment before the marker on the same line.
Why is that?

I’m probably missing something really basic here, so please bear with me.
Thanks!
All the best,
Erik

[ep0]

Attached is a screenshot from the “ring” example in the mubu.concat~ helpfile (pipo~ real-time).
The duration value in the imubu segments appears to refer to the previous segment. This is not the case in the first “basic” example (mubu.process offline), where the duration appears to refer to the correct segment.
This shift is also reflected in the matrix view of the marker track as mentioned earlier.
Does anyone know why there is a difference?

[ep0]

I guess this is by design, since there is no way of knowing how long a segment is before the next marker has been created. It’s just a bit confusing at first that offline and real-time are treated differently with regard to the duration value.
In the case of real-time, it is more like: ‘The duration since the previous marker was created’ rather than ‘the duration of the segment’.

[schwarz]

Hi Erik,
that’s exactly it. When any of the duration/mean/min/max/stddev flags are on, pipo~ can output the current segment statistics only at the END of the segment! If you want to detect just the onset, switch them all off and a bang will be output for each onset.

Here’s an updated helpfile that clarifies this, and also adapts the imubu columns for recording. Please tell us if this would have made things clearer for you.

pipo.onseg.maxhelp (156.6 KB)

best

[ep0]

Hi,
Thanks for your reply, the addition in the help file is clarifying to some extent.
But it doesn’t really address the fact that the information gathered at the end of the segment is not attached to the segment’s index/timetag, but rather to the next index. (See duration discrepancy in the screenshot in previous post: the long segment in the middle is listed as 133 ms, which clearly refers to the previous, shorter segment).
In my case for example, I want to access both the timestamp of the segment start and the segment duration to make my own concat using the regular max buffer. If processing is done in real time using pipo~, that means I have to access the timestamp at one index and retrieve the segment duration from the next index, which is a bit unintuitive.
I am still not completely clear why this is.
It would be more intuitive if the info gathered at the end of the segment could be inserted at the index/timestamp created at the start of the segment, not the following index. At the “same line” if you will in matrix view.
I’ll attach two new screenshots to clarify what confused me initially.
Thanks!
All the best,
Erik

[schwarz]

You’re right, in the real-time help, it actually doesn’t make sense to record the RT output of pipo.onseg as-is. One could correct the time tag by duration and insert events in the past, in order to get a nicely aligned recording.
A better way would be to use mubu.process with @process 1, which puts the segments at the right position.