< Back to IRCAM Forum

Mubu.process with several long audio files

MuBu
#1

Dear all,

I’m experiencing problems with mubu.process while importing long (several minutes) audio files. Basicall, with @process 0:
. importing the audio files one after the other with drag&drop, then sending a bang, works
. but importing the audio files at once (select several audio files and then dragging them), the sending a bang, fails: only the first one is processed

With @process 1, even importing audio files one after the other fails: the latest file is not processed.

I could also notice that, as long as the processing of a given starts, it finishes. The problem seems to be that in certain conditions, processing of some buffers does not start at all.

See the patch below for a practical example.

The problem occurs with different pipo chains, so it’s not related to the slice:fft:bands I’m using in the example (I tried for instance to replace it with descr:chop, same issue).

I tried also to queue the file list and force sending them slowly one after the other with a qmetro, no luck.

Any ideas?

Best

Alexis

Macbook pro 10.11.6
Max 8.1.1
Mubu 1.9.11


----------begin_max5_patcher----------
1908.3ocuYssaaiCD84juBB+vhT.GWc0VN.6hreC69VaQ.kDsMaoDEnnhiaQ
+22gWjhjMch7krAHx1zjb3bNGNyP5ec6MSR4uPpmfd.8EzM27qau4FcSpFtw
94alTfeIigq0caRFunfTJmL07cRxKRc6QeFskJ2fDDL6dIsffpD7LRcMsbM5
tGse.4+ooHpDkyI0nRtDskK9ABKQXFCQdlTZlDZQEWHUibEkA8jWRP3URh.I
2PPb3g3A8aelH1gXXIoVp6JhZlVq4H4yP+KGshKxHJyJ4nztE1T8L70I1O90
Iv5PPooMRBZCt114ZhDkhy9g5i+jH3SQ3xb0HKQX3KTNGLBIur+L8oASPo1v
EMoMyr8nE8XzRRFuoTCgysMV1TPKYDoFu8sMRy0nLO8626ubxq8j2Ha6pms0
JrLaCfcOIHYRC0NOJbl2TTPPj9kkKTuj.OQeSMlee6spGSuPIP3mQ4B7Zze.
uvq.GGXGLCcG.+HZYsDWBrP3mPLNfZ3lbJ2Ru2Ef.WFvcfoEnBtf7IklfC8e
pApyXTfBFBxn+7uf9BDOeERI3zBKdIaWG6aDNoMqVQDSgWkZsgRpoFxFRA5N
KYhDz0ajlYSinupPkaD7spVAaCCMGlRffmg9GdAQYVPGktCj8UDrVw1S12h.
5tgtCTB4plM5FyFgUzRXR2o2GbgxhEmqrvOH4iTVDbMkENhD7NRjiirgiEYm
etH67k8.1nqMv5ODXUPydXn6cVfj+zAqfwBVQmKXEFzCrBCOSvpjrEVFGfU3
pJX2G5wRLjYRCPSFoCE61eZ6ooI4tJhwYlLA8s2vUWpi.Gsz2rwagIr700Wq
TAi.mEREma76w5qQe.9Zb3biu5cQ9pRhqjzi0U7c6JAG0UlNN2Ibt+rXvcla
XP+3qK2w337BUgR0zeRP9i0aCa63JdoTMTc+TandK9bCMOmTNRFVMypcOZa9
2BJlM43f0xvYKhhm6Esz9WBfb95ngKuLMuBbvqIG.bYLBFRqvbhXANPrfyBx
tV.jejAfh8r+4q1oXCNbQ.zJHGPSwnENKdcQJfEOjY8IRINkQ5Gz9HPDjAu.
ueQJicylpFnyE7zHTj27d4XCtxIWg0bUirVUN2ZQuR1SaRsfi+Hg3f3SRo4c
NHRRxrf82uE4EaBQY1vEcl.jBQLmvwQhlAml4c0ZQmrVK4HfT3aFFG9mppZ4
amV.J+Dccv9w5xQhht1Ykg0DTv6pQW4QxGutIJQmFKLVKUhurPyT0QbaMFuB
mQAhwt8g97.RtolTwvYjMbVNQL..xZD0bwSYTADReCQctLMi241RNmkhEOkt
Niy3BaHAMy0+QG6myKvv4LxDbldbcHY6Dhaj7lpbrzBvdclxLTQCizaXw1ur
thQkO8LsltW.AAYMkW9TJT5bt8tUz093cvhxLyi0QLgjdlR11xudCwr5MXyF
AH3pXxvuyw5bkfP94f4YKsLGXK5vVM18Gjc0Nrogm1RykaFRScZvMDV08Jow
8p3EcGt.uCl29SXKuVwqoR..6uT2mCc3Mli4msgyqALcUeLsE8sO5ioRbZ8.
K5h5aJoCVoXFccohGdkh8Fx8CLdhxtKrO5abmA.pKwUhVsHTXfSw3Xcu9Qei
GSzWAjUlXrwZgYzdNAXGLPqJzJeBGHefPU0tzr6K8c6GPPThnDyzWLPea1JZ
5Lp6UqKMkl5aGWfKTtmO1OVwqrdvPV2Al3tJxgKtSKPlaxwDLZbfoByzxBRN
sqvmdDeGVFeHwt+VgSK1k9hvHLH8yd61rUa45qrFeErymu8.UjMMitoYyMkR
GDlD4mDmrmDoG6D3jG5hvOuuBwAoteznwAAJoif.Acq2zt+t0KHEoj7ggQpw
EULRmd268O+Qe4gqHZFIRmf+Pd2gbmKnPwwX2AGOLCWTPHTJ0rkKVDFDELOz
yOwaY2BbOz90jU5pKqO0SKMWW9Ovyyh8RVjjXKjawRaIb6m2DyZHtxf0GqtG
Hry4PoMLIslQgZYZ8hZXKub2PcCzFDvGFYOHquBY+Hmu6cbDNlP5tOSVsZii
5DX8hJMx8xFGcPBnXefril57c6EF3st1kiH2N5Q.s0sFBUyuLvKJxqsX9P0E
0bcqeu+ueCZXMM1abEvkLxCqVIe.NaadM5w1heMBPn1e0yGgNLqfmSPE30Pz
zF3cOpGfsUBSMRJfExcn.36zaafJyHuf7Pc+RZdi+Nscb8Gc+FRCowo8dzm2
FbBjnibBjnwbnrom+UlXNn+BykoaN3R74d8aXoTzPG8kIlb1WLpxPtNr7wcv
nElSg599R0Srly26msUOgp1G50f3Sj0trrLOJ70jFjZIsraG2W5N4I5X35oX
Gu2wNpaepWm3BU.T0F+ObKqBc5xx9WjkiGgkitBXazXv13qfgBGikV9Q.kix
xCIQGWm80QPotq3+mv6SW51yquHS6mLdp9xLzHrygXoItGtp5Yhn11YsIf35
e2jASWv+DHRt4iZQ.TIspr1dm7aBFJAkJgntMBShmWlatXxIp7uhRHsfALAm
CLoNmgJIkphIaAqPpka+8s+WNHDMl
-----------end_max5_patcher-----------
#2

Yes, this is a known new bug introduced in 1.9.11. Temporary workaround: iterate through the buffers (uzi), setting bufferindex, then bang (should still run in background with @priority default, foreground with @priority async).

#3

hi Diemo,

thanks for the trick, it seems to work with @process 1 and @priority 2, as you say.

Since I am at it: what is actually the advantage of having @process 0 in general? As far as I understand, it means having the processing put in the event thread, correct? Why would one like to overload the event thread with mubu.process?

Alexis

#4

no, @process 1 is to continuously analyse added data (for live recording, ring buffer, etc.), but it never sends “alldone”.
With @process 0, it runs on bang in separate threads per buffer, or main thread (@priority sync).

#5

OK, got it, I was confused since your trick works only in @process 0 with @priority sync.

So for pre-recorded data, the best is indeed to work with @process 0 and @priority 2 (of course as soon as the bug is corrected), since it’s easier to trace when the processing is done.

Is there anyway a drawback by working with @process 1 and check oneself when processing is done (for instance by summing the multislider output and comparing it to the number of buffers)?

Alexis