as i realized neither transport nor the timepoint object are stable or fully functional
i thought it might be an idea to build a modified transport.

the initial idea now was to look at the itm api.
the simple goal is to build a transport that in principle does everything the standard transport does
+ the ability to reset the beat-/barcount everytime after a certain (beat.bar.unit, ticks) position is reached +it doesn’t crash.
is it in general possible with itm to get notified if a certain position (bbu or ticks) is reached?

any opinions about this or experiences with the itm api?

If the built-in transport system is not stable i’m not sure you can do better with the API provided as i suppose the built-in system is based on this API ;-)

What do you mean by not stable ? Lagging, crash ?

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.

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.

http://cycling74.com/forums/topic.php?id=42364

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

----------begin_max5_patcher----------
755.3oc6XtrbaBCEFdM9oPiV65AIt2UtOGc5jQ1VwQofDijhaZyj28JI.GRh
MPRrURmzMFKg3ne93bCtaV.bk3VpBB9J36fff6lED3lxNQP63.XE410kDkaY
P9MUqnR37lSYFw3kTs6bn1IuTv0J1ent4vKBeXshazcKF2NasjpnbMQyD7Kj
z05FwjVrHEmLGDkGYL.Hr8GvOZurFKo+cMsY8PFWCmCfqH7sv8qplnWeEius
mgyxrlp0rIN6h6aX1F2soX00eIIC16NhSpb6E7aRFoDteGjl40T4ETNYUoaE
g1Sc+rY1el+Ng0WMePIIKLbGiym.fR+LBnvW.fR7GfpnJEYKsyrZ5sNACyRy
CWbPtgeIbCcLtMHrhc1CfJRsGhQtA4GAV3Af0qwig9KiYeFOzrJZsv7zFT.P
fv2tG0QIyntRczIM1dHuXPWonSLc9vDOgebp9QhnP9Kh5xRg4d8LhHyFPlFj
voIKhxd.REIML6XXJN2eXRK1tsjNHllX.i0kY3TuMEuw6cQFf.wm7JPGNehw
zRAXoQ6T4NRIPyV+SEHArjrVy1QAnyXt2wCthi6QLTwvHySIfkDtpVH0fk18
.nJYUfkZZUsvffv2NtJFIkT6g8QeO+OGZUSxyrK40vbFcZ47Go7TQo8ZNBgF
rjVT5m7tihRya7Zvi2cDJzycGkY6NxDWtOZ0Fm9d1sTGsZyk07hbGy2BkcZw
kGKxE2zTXR7DJx8+ZblbNgo85hdjZbdtD2+lEyZ8.KbsZhvCGnMMf5tTXIi+
zu1ja+sy+XJqD2HW2cq1UzD7fB1PUZF28Ui5sH6Wro2hthsYC0c9N1tgorgG
aNd7wT0iUNnwjSpWkynzIwaxw91piqGr2zi8sAFUOOwE6rpG7GL8X2prwzSt
e0yngW9iO1tul1yKjehulh+i+jCJaJxIzqYCGyaNxeImim3CK+nF7YTMMk4I
006nRUqIcBwz1z0BocX5b2PFuYnyhPIcGqa8IyrV69Y+Ev.rwzA
-----------end_max5_patcher-----------

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.

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.

http://cycling74.com/max6-bug-form/

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.

Sorry, i never used seriously the ITM part of the SDK nor the [transport] object so i really can not help you. Send a bug report seems a more reasonable approach than redo the built-in object but i can understand your frustration (specially if you use max 5 and so will never get updates).

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: http://cycling74.com/2004/09/09/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

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

http://www.cycling74.com/sdk/MaxSDK-6.0.4/html/chapter_itm.html

To deal with “time” I implemented my own sheduler in my own thread with functions like mach_absolute_time( ) and nanosleep( ) ; i doubt that it was the most brillant choice, but a good one to learn C deepest ;-)

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

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

Greetings,
Alex

Or : pretty much everyone is using transport except the guys of the dev forum ;-)