Just out of interest does the patch below not work?

hey, ...actually i think that objects connected to fundamental time management should be rock solid and I think it can be claimed by users who payed for max that they work properly.

and yeah, i also thought it might be a paradox idea to build it based on that api but maybe i'm hoping for someone jumping in saying "it still might work" because i otherwise really would't know where to start

-- beside other things i experienced with transport/timepoint my main problem at the moment is that i can't reset at a certain timepoint. (if you're interested i can tell you about more bugs)

if i create a named transport (having a global transport already), and a timepoint "connected" (@transport named_transport) to the named transport, then setting the timepoint pos in ticks or bbu, then start the named transport, then delete the named transport and after creating a new named tranport and timepoint again max crashes at the moment i want to set the timepoint. that happens everytime!, after the second creation. if i disconnect the message that sets the timepoint, the patch never crashes.

hey grizzle,

your patch seems alright but all problems i experienced were when things get changed or created dynamically. if you change for example the timesig after a position message has been send the clock gets corrupted.

https://cycling74.com/forums/bugs-in-transport-object

Do you mean like this. I tried to do what you said and I didn't get a crash - Max 6.0.5 - I tried to delete and redo (cmd X, cmd Z), and I deleted and created a totally new named transport - all while the main transport was running and when I turned the main transport off. It didn't crash.

Does this work for you or does it crash? Is this what you mean?

EDIT: I read your last post after I posted. I'll leave my patch there anyways but it does not address your problem. I missed the Time Sig change bit I didn't try that.

unfortunately the problem described before is a bit hard to encapsule as a example patch because it's a self written external that creates a bpatcher which contains a patch which contains the timepoint object.

but as it never crashes when i don't send a bbu/ticks message to timepoint i can surely say it's because of that object.

Have you filed a bug report? It sounds pretty reproducible, and it's a lot easier for the Cycling folks than combing the forums.

BTW, if you're having timing issues, have you worked with the scheduler settings, or turned on "Scheduler in Interrupt"?

If you want sample accurate timing, you can do things at audio rate, though that's a bit of a shift.

Hi,

you might also check whether it crashes as well when creating the same bpatcher and patch by hand. It could also be a bug related to the way how your external creates all these objects.

I think that 'Scheduler in Interrupt' may perform even worse with ITM than simply turning 'Overdrive' on, according to this article: https://cycling74.com/articles/event-priority-in-max-scheduler-vs-queue (see section 'Scheduler in Audio Interrupt'). Although you have to test with your actual patch to know it for sure.

Cheers, Ádám

Hi,

thanks for the responses. I saw the bug formular just after my last post. I'll check again if it's really not my fault in the end and then try to create detailed bug reports with little examples. @Peter: no I didn't change anything about those settings @Adam: good idea to create this whole thing another way and see what happens, I'll try, thanks, also for the link @Nicolas: if you are not using any of those objects how do you work with "time" in your system? do you work with time signatures or comparable self defined time units?

Greetings, Alex

ps: my initial problem might be solved. itm offers bbu connected events. so if a transports reaches a certain bbu pos i can send them a bbu set pos message. https://cycling74.com/sdk/MaxSDK-6.0.4/html/chapter_itm.html

Hi,

to answer the question initially addressed to Nicolas, I also never used ITM in any of my compositions. What I usually do is that I have a central [count~] object and then do everything that I can based on the sample count from the start of the piece. Sometimes it's a bit of an overkill, sometimes it's a bit hard to handle everything with a sample-based timer and sometimes it needs much more CPU than a simple [metro]... But it proved to be the most robust solution that I've seen over these years.

HTH, Ádám

Hey,

...and I always thought pretty much everyone is using transport, etc. Good to know, thanks!

Greetings, Alex