< Back to IRCAM Forum

Pipo, onseg example / documentation

MuBu
#1

Hi all,

Congratulations with the 20 year forum anniversary.

Unfortunately I can’t make it to the forum to ask my questions, so I’ll have to do it here.

I am wondering wether there is an example with the syntax of the onseg module of Pipo. Does it work already? Does it make markers automatically when used inside mubu.process?

I tried to find answers through PiPo - IMTR but that site seems down…

Best, Hans.

#2

Hi,
I was looking for the same, and it seems to be working in mubu 1.7.1 at least, with a chain like [pipo~ slice:fft:bands:onseg]. Just looking at the attributes with attrui and watching the output to see how it works, but it would indeed be nice with some documentation.

Best,
Daniel Formo

#3

+1 for more documentation for the pipo family in general. There is a treasure trove there but we have no map! Thanks in anticipation…

#4

Let me resurrect this old thread once again.

It would be great to have a detailed documentation for pipo objects in general (not necessarily for the onseg one) with confidence. At this point, our works with pipo family are basically based on guess works not knowing that we are utilizing all of their potentials. In the worst case personally, I can’t make happen what the pipo objects look promising to be able to do, just because I don’t know how without a documented support.
Please tell us if you are planning to provide such a document in the near future.

Thank you,

Yota

#5

Hi Yota, can you please tell us where and in which of the (now complete) pipo help pages or pipo.catalog you have a specific question?

#6

Hi Diemo,

First, I’d like to appreciate your work for making these wonderful objects available for public.

I have studied the help patches in the mubu distribute, and listed below the things that I couldn’t understand from the described information.

pipo.catalog

  • The linked patches are missing for pipo.moments/dct/bands/mel/mfcc
  • For dct, bands, mel, and mfcc, are we supposed to slice and apply a window before them (e.g., [pipo~ slice:mfcc])?
  • A help patch of polo.moments is very nice to have.

mubu.process

  • What are the synchronous and asynchronous processing using pipo modules in mubu.process: the differences between them, the purpose of using them? mubu.process.maxhelp has undocumented subpatches for descriptions about them.

pipo.fft

  • In pff~ object in Max, we only specify FFT frame size and overlap factor. In pipo.fft, we can specify slice size and fft size. My understanding is that the two sizes should always be the same. Is there any case to use different values for these? Also, in the help patch, slice.hop = 10, so when slice.size = 64 like the online version, the overlap factor results in 6.4. Doesn’t slice.hop need to be a power of 2?
  • pipo.fft has undocumented attributes: FFT mode (what is the complex mode?); FFT weighting (what are these a~d and itur468 modes?).

pipo.onseg

  • In the online version which the help patch shows, scaling (why is the input (1~10) is scaled to the output (0~10),), slice.norm (is it always best to use “power” mode with onseg?); fft.size (not specified in the object and the inspector shows “0” for this attribute, is this somehow automatically synced to the slice.size?; fft.weighting (why set to itur468 mode, what is this?).
  • onseg.odfmode: when set to kullbackleibler mode, only a few makers are detected even with various attributes setting, how can I best use of this?

pipo.const

  • Not listed in pipo.catalog
  • What is this? The help patch shows [pipo~ slice:yin:const]. How is this different from just slice:yin?
  • Also the patch has no explanation about the attributes.

Sorry for asking you many questions. I’d really appreciate if you could help me understand pipo objects better.

Thank you,

Yota

#7

Hi Yota,

Thank you for using MuBu and for your feedback.
We definitely have to document things a little more, however I can already answer a few of your questions.

Concerning dct, mel, bands, and mfcc :

mfcc is in fact a shortcut for slice:fft:bands:dct with predefined settings
mel is also a shortcut for slice:fft:bands
So you should use them as single pipo operators.
I think you can find some use examples in mubu.gmm/gmr/hhmm/xmm help patches

dct and bands are regular pipo operators (they are not combinations)
bands is supposed to be computed on a spectrum
dct can be also used like fft (slice:dct)

Concerning fft :

I assume you are talking about a slice:fft pipo combination
fft has the following behavior :
if its size attribute is <= 0, it will use the incoming stream’s window size,
otherwise if it has a smaller value than this of the incoming stream, this smaller value will be used,
and if it has a greater value, it will clip to the incoming stream’s size
Concretely this means that if we have, say slice.size == 2048 (which is the default value),
if fft.size <= 0, fft will use 2048 as its window size
if fft.size == 1024, fft will perform on windows of size 1024 (and some info will be discarded)
if fft.size > 2048, fft will perform on windows of size 2048 (because it doesn’t have some kind of buffer to store more values than the incoming ones)

slice’s hop attribute is totally independent from the size, it just means how often the last “size” values should be output
(slice has an integrated buffer that allows it to do this)
this is what determines its output samplerate.
it’s different from the way the pfft~ object works, because audio analysis/resynthesis performs best with some power-of-two-sized arrays.
having a smaller hop size allows you to have a better samplerate while still using a big window for analysis.

Concerning onseg :

the way it is used in the examples is one of the best combinations of parameters for onset detection.
it would make sense to create a special pipo for this, just as mfcc was created, but for the moment you have to set all the parameters manually.
you can create your own max abstraction to encapsulate this, though.

Hope this helps.
Best,
Joseph

#8

This is very helpful! thanks Joseph.

#9

You’re welcome :slight_smile:

#10

Hi Joseph,

Sorry for my belated reply.
I appreciate the information. Thank you!

Yota