dhjdhjdhj

Suppose you have an external with an outlet that is connected to three (say) inlets of other objects. Is there any mechanism that can be used to allow the function that is sending the data through that outlet to know along the way that each traversal has completed?

question-about-outlets

The trigger object would be useful for that.

I appreciate your responding but per my question, I need the 

 to be able to know when each traversal has completed. I also don't want to introduce feedback so an external trigger sending bangs back into the external won't help.

I appreciate your responding but per my question, I need the function inside the external to be able to know when each traversal has completed. I also don't want to introduce feedback so an external trigger sending bangs back into the external won't help.


Something like what you want would, arguably, break the notion of encapsulation that is central to object-based programming.

If you're writing the code for the receiving externals, you could set up a non-typed message for communicating this kind of status stuff between your own objects. I can't recommend the approach, though (and, believe me, I did it once for a project and was never really comfortable with the result).

I suppose if the implementation details of patch cords were exposed, it might be possible to hang in some kind of notification scheme. But they're not (exposed) so you can't (notify).

I'm wondering why you want to do this, to see if maybe there's an alternative way of getting the end result. Objects should, at least in theory, handle incoming messages really, 

 fast. If an object needs significant time for processing, it sorta oughta defer the processing (so much the theory, there are enough exceptions). Still, it shouldn't be a question of worrying that some objects are taking too long to do what you're asking them to do.

I suppose if the implementation details of patch cords were exposed, it might be possible to hang in some kind of notification scheme. But they're not (exposed) so you can't (notify). 

I'm wondering why you want to do this, to see if maybe there's an alternative way of getting the end result. Objects should, at least in theory, handle incoming messages really, really fast. If an object needs significant time for processing, it sorta oughta defer the processing (so much the theory, there are enough exceptions). Still, it shouldn't be a question of worrying that some objects are taking too long to do what you're asking them to do.


I was thinking of building a profiling/instrumenting toolkit with some more fine-grained measurement capability but without the need to litter patchers with extra objects. Automatically knowing when each traversal completed (starting at some desired level) would be very convenient. Being able to query an in/outlet to see to what it's connected would also be very useful, if that's not in the SDK already.

I was thinking of building a profiling/instrumenting toolkit with some more fine-grained measurement capability but without the need to litter patchers with extra objects.  Automatically knowing when each traversal completed (starting at some desired level) would be very convenient. Being able to query an in/outlet to see to what it's connected would also be very useful, if that's not in the SDK already.


OK, admirable goals. But I think currently the only chance of getting at what you need would involve some determined reverse engineering to figure out the data structures of outlets and patch cords. Sorry not to have better news.

Or else get a day job as a developer at Cycling '74 :-)

I thought about that and particularly tracing the code from an outlet call but the last time I wanted to debug an external, I wasn't able to get xcode to attach to the Max process, don't know if that's just something on my system or something in place related to Max copy protection scheme.

I'd love a temporary day job at Cycling74, particularly so I could figure out the Max6 VST problem that I've been having for years (sigh)

Didn't thnk of that, and it makes lots of sense if in fact it's the copy protection scheme that's preventing the full system from being loaded.

Other than putting the complete path to your external in the patcher, is there a way to tell the runtime system where to look for an object?

Not sure how drag and drop would be any different than right-clicking on a patcher and opening with the runtime system. The problem is not with finding the patcher. It's finding the external that is referenced from inside a patcher.

Question about outlets