Cycling changed some internal data structures that we’re nosing around in, which leads to changed behaviour like yin/psy not working and gbr.ola~ having a latency of ~1h. New version coming soon.
Thanks for the warning!!!
Are you also looking into the issues with the windows version of FTM? (ftm.editor crashes MAX when opening a saved patch)
Thank you very much for the warning, too
Is this still valid in regard to Max 8.1.8?
best, j.
I haven’t tested it, but very probably that change affects all Max versions from 8.1.6 onwards.
Dear Diemo, @schwarz
I’ve installed Max 8.1.8 and I have some troubles with mubu again. see the patcher from extras menu…
Is it the same troubles with FTM ? Even if MuBu is something else ?
Best,
Jerome
mubu.concat~: “audio” is not a valid attribute argument
mubu.concat~: “markers” is not a valid attribute argument
mubu.concat~: “play” is not a valid attribute argument
mubu.concat~: “duplicatechannels” is not a valid attribute argument
trigger: error connecting outlet 1 to mubu.concat~ inlet 1
mubu.concat~: doesn’t understand “advance”
mubu.concat~: doesn’t understand “attack”
mubu.concat~: doesn’t understand “release”
mubu.knn: no buffers included
mubu.knn: no buffers included
mubu.knn: no buffers included
mubu.knn: no buffers included
Suite…
I’ve installed Max 8.1.3… CataRT-FTM idem for MuBu and everything above is ok…
— bach: automated composer’s helper —
© 2010-2020 - Andrea Agostini and Daniele Ghisi
Thank you so much for supporting us on Patreon!
v0.8.1.3 beta
MuBu for Max, version 1.9.14
IRCAM – Centre Pompidou, 14/07/2020
MuBu JavaScript support enabled
process: done 1
process: alldone
catart-mubu: loaded 0.49 minutes of audio in 118 segments in 1 buffers.
Hoping it helps
Jerome
Hi Diemo & others,
Is there a new version coming? I am using some gabor objects that do not work. In my case it is gbr.harms that does not seem to work at all. (it outputs empty fmats)
Best, Hans.
Hi,
besides of I would love to see FTM updates for both platforms I have to say FTM is working very well with MAX 8.1.10 on WIN 10 as far as I can see - at least cataRTs first run was working fine and the help patches for gbr.harms, .ola, .yin and .psy are working, too.
How to test the mentioned ~1h latency of gbr.ola~?
cheers
Hi Johannes, thanks for testing!
That’s great news that these internal data structures did not seem to change on windows! If you have sound with gbr.ola~ (maybe try different vs, sr), then everything is ok.
Cheers!
Hi Hans, gbr.harms works here (at least the help). Also check if gbr.slice~ outputs something sensible. Just in case, here is my gbr.harms.mxo recompiled when I fixed gbr.ola, don’t know if it is affected: gbr.harms.mxo.zip (30.5 KB)
Now the forum is done, and with Johannes Windows confirmation, it is time for a new ftm release, to keep the living legacy alive!
Hi Diemo,
Yes, that fixed the issue. Thanks a lot. I had already checked gbr.slice~ and that worked fine. The same issue is also happening with the gbr.peaks~ object. Would you happen to have that one laying around in a new version as well? Thanks in advance. Great and looking forward to the new ftm release. I figured this was the right timing for sending a message… So playing is now an option as well I suppose ;-).
Oh, and thanks for the nice forum presentation. The forum was nice anyway in this format.
Hans.
Yes please, keep it, please keep the living legacy alive! This sounds so good to my ears.
In fact on my way through the FTM overview I realized how really good it sounds, again.
The only bug I’ve found so far, I can crash MAX with the gabar.psolastic example.
“listen” is working but the “scratch” and “record” options are not working, they are crashing MAX.
Tested a few times with 48/64 and 48/128 KHz/buffer size.
With the sprectrum example I get this:
“gbr.yin: vector too short (at least 963 points expected (1924 recommended) for given minimum frequency of 50 Hz)”
Tested with 64 - 2048 buffer size. It works as far as I can see, but there is the above warning.
This doesn’t happen on Mac here. Anything specific you are doing, Johannes, except twiddling the “scratch” slider?
I’ve just reproduced it with 512 buffer size and 48 and 44 KHz.
Just selecting “record” while the default sample is playing leads to this “not responding” state, sometimes it crashes - no twiddling possible.
Great, thanks, this works as well.
I did a quick test and as you said in the release notes the problem is fixed with release 2.7.5…
Thank you so much for taking care of this foremost beautiful software.