Cycling 74 » Topic: getpath of a clip only with deferlow? http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/feed Wed, 19 Jun 2013 00:28:38 +0000 http://bbpress.org/?v=2.2.4 http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-59913 <![CDATA[getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-59913 Wed, 09 Nov 2011 11:11:50 +0000 pure Clicking on a MIDI Clip [live.path] sends out an id which goes to [live.object] to get the path of the Clip. I don’t understand why it works only with [deferlow] right after [live.path]. Can anyone explain this?
I attached the device…

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215688 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215688 Wed, 09 Nov 2011 11:17:45 +0000 pure here’s the device…

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215689 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215689 Wed, 09 Nov 2011 12:53:49 +0000 broc Quote from the docs (Live API Overview):

Note: changes to a Live Set and its contents are not possible from a notification. The error message in the Max Window is ‘Changes cannot be triggered by notifications’. In many cases putting a deferlow between the notification outlet and the actual change helps to resolve the issue.

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215690 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215690 Wed, 09 Nov 2011 12:58:01 +0000 pure Thanks, I know this quote. I should probably reframe my question: why is implemented this way?

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215691 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215691 Wed, 09 Nov 2011 13:37:50 +0000 broc I’d guess it’s for prevention of feedback loops.
(not sure if the developers want to discuss implementation details)

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215692 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215692 Wed, 09 Nov 2011 13:48:22 +0000 pure yeah maybe. But then I wonder why it’s not set to low priority in the first place? Oh, it seems to behave differently depending on where the live.object points at. It works with getting the path of a track f.e.

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215693 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215693 Thu, 10 Nov 2011 02:33:11 +0000 basvlk I think the whole deferlow thing is unclear – for me it’s a bit like if it doesn’t work, stick a couple of deferlows in.. If we understood why they are required, the mechanics behind it, it would be easier to program efficiently. Apologies if it actually is explained somewhere, I searched but couldn’t find it.

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215694 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215694 Thu, 10 Nov 2011 10:25:01 +0000 broc Here is an article that explains some relevant aspects of the Max execution model.

http://cycling74.com/2004/09/09/event-priority-in-max-scheduler-vs-queue/

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215695 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215695 Thu, 10 Nov 2011 10:36:03 +0000 pure Thanks, I know this article as well. =)
I think I just considered getting the path of a MIDI Clip by clicking on it so basic that I didn’t expect it to be necessary to use any tricks. M4L ain’t easy to tame…

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215696 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215696 Thu, 10 Nov 2011 11:09:35 +0000 basvlk Here’s my understanding of deferlow – can you tell me if this is correct?
Everything below (and connected to) the deferlow object is executed with the lowest priority – effectively allowing other events to finish first, before the events below deferlow object.

in the case of M4L objects, what is that ‘thing’ or those events that need to finish first? what is that M4L object dependent on that requires it to be below a deferlow?

apologies if I completely misunderstood something!

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215697 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215697 Thu, 10 Nov 2011 11:28:01 +0000 pure [deferlow] puts the message it receives at the end of the low priority thread (there is high priority and low priority) unlike [defer] which puts it at the front of the low priority thing (This of course also affects the objects downstream of [deferlow] but they are not “deferlowed” per se). So [deferlow] is the strongest slow-down you can do.

In this case it’s the sending out the id of the MIDI Clip I clicked on that is put to the very end of the queue. Why it has to do this to give back the path of a Clip but f.e. not of the track this Clip is on I don’t understand.

I’d think that if I can deferlow it than it could also be built into the object so it “just works”.

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215698 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215698 Thu, 10 Nov 2011 11:57:43 +0000 pid the thing about max is, whilst most of it is easy to learn and use, it wants to give you so much flexibility, individuality and level of control like no other app, that sometimes you run into these sort of issues (the perennial “scheduler” issue) that you wish “it just took care of it for me”, but it cannot be that way, as then you would not have all that amazing control and uniqueness.

however, i do not think that this issue is particularly complex at all, and once you have been patching with max a while it starts to make more and more sense and becomes natural to take into account. even though the helpfiles explain it very well, here is my potentially nightmare explanation, i hope it helps a bit:

– Pasted Max Patch, click to expand. –
]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215699 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215699 Thu, 10 Nov 2011 12:02:18 +0000 pid by the way

“I’d think that if I can deferlow it than it could also be built into the object so it “just works”.”

… usually, the reason one thing has to be deferlow-ed when another does not and you are not expecting it, is simply to do with bad patching practices and not following your execution orders exactly correctly. the problem with deferlow is that it ‘makes stuff work’ so it gets way overused, whereas ones use of it should not be frivilous but very exacting. if you need 10 in a simple patch then something is usually very wrong with the patch, not the execution / thread calling of Live/Max.

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215700 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215700 Thu, 10 Nov 2011 12:11:53 +0000 pure Wow nice patch – you must have a lot of time!

Did you have a look at my attached .amxd? Why does it need deferlow in this specific case? I can’t see any bad patching practice in it.

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215701 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215701 Thu, 10 Nov 2011 12:29:40 +0000 basvlk Pid – I completely agree, I’d want my patches to be defer low-free if possible. I build all my abstractions to Max object conventions like get triggered by the left-most input, and try to build my patches so that they execute in the right order just by design (left-to-right arrangement of objects etc), and use a lot of triggers to add control of execution order.

Which makes it so much more interesting to understand why m4l needs deferlows to operate! And not knowing why/when to use them and when not means you end up using many more than required, because at the end of the day you want it to work….

I’ll look at your patch when I get home, I hope it will clear things up for me!

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215702 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215702 Thu, 10 Nov 2011 12:40:51 +0000 broc @ pure

regarding your track example: Do you get the same error/warning message as with the clip?

(right-click on the device title bar and select ‘Open Max window’).

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215703 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215703 Thu, 10 Nov 2011 12:56:12 +0000 pure @broc: nope

I attached an updated version with a [live.path live_set this_device canonical_parent] in it that shows that getpath works without [deferlow] in this case.

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215704 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215704 Thu, 10 Nov 2011 13:57:46 +0000 broc @pure

I think your second example shows normal behavior because the path calculation is simple and thus can easily be performed in real time (high priority). In contrast, the path calculation of ‘detail_clip’ is much more complicated since the clip may reside anywhere in the set depending on user interaction (selection).

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215705 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215705 Thu, 10 Nov 2011 14:11:05 +0000 pid ok, broc is the expert, listen to her/him. however, i’ll add…

no, sorry, i did not look at your .amxd originally – i was just answering to the ‘deferlow’ issues. however, i have looked at your example device now and the answer is very simple and is a tricky part of the API that has always been there (and documented), namely: you cannot trigger processes based on observed notifications from the API.

this is one of the API ‘rules’. it is for this very reason that use of the [deferlow] object was envisioned, and its use here is perfect and correct and exactly as you had it. there was possibly confusion because [live.path] is not strictly an ‘observer’ object but, give it the argument you gave it to track straight to “detail_clip” and it becomes one.

therefore we ascertain that SOME parts of the API are slow, in terms of callbacks. as broc said, “the path calculation of ‘detailed_clip’ is much more complicated as the clip may reside anywhere in the set depending on user interaction”.

i attach a .amxd device based on yours demonstrating this, although i am sure you get it… disclaimer: i am no API expert – i delve into it now and then.

hth .

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215706 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215706 Thu, 10 Nov 2011 15:18:39 +0000 broc Pid, thanks for the valuable comment. Apparently I’m not the only expert here if at all…

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215707 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215707 Thu, 10 Nov 2011 15:42:18 +0000 pure @broc
easy vs. complicated path calculation: OK, if this is what it is I can live with that. Is anywhere documented which calls are what?

@pid
so sending an id is an “observed notification from the API” and doesn’t work, but deferring the same to the end of the low priority thread works. uh…

I just tried one more thing which really baffles me: even when I [zl reg] the id for a second before passing it on to [live.object] it won’t work. So it’s somehow not about the time but the thread it is attached to. or so…

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215708 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215708 Thu, 10 Nov 2011 17:12:28 +0000 broc

easy vs. complicated path calculation: OK, if this is what it is I can live with that. Is anywhere documented which calls are what?

No, unfortunately. But I’m not sure if a strict classification would be possible.

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215709 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215709 Thu, 10 Nov 2011 18:10:08 +0000 pid “So it’s somehow not about the time but the thread it is attached to. or so…”

- well done, you got it! as i demonstrated in my initial crazy patch-description of [defer] and [deferlow], with [defer] (or [delay], or [pipe], or [s]/[r] etc) it is not possible to pinpoint the exact execution order, but with [deferlow] it is. this is why it works to [deferlow] on an ‘observer notification’ from the live api because it is saying ‘do everything you need to do, when you have done that, let me know and i will execute’. it is nothing to do with ‘id’s in general – you can happily trigger as many as you want so long as not directly from a notification. with the tricky business of ‘you cannot start another process based on a live api observer,’ think of it like a digital audio feedback loop – it cannot be done like in the analog domain – you need a sample of delay (in gen~!) or a vector of delay (in msp).

re: “easy vs. complicated path calculation” – sort of; it is more about ‘possible to predict time scale of callback’ and ‘NOT possible to predict…’; but in general, yes. “No, unfortunately. But I’m not sure if a strict classification would be possible” – exactly. it is not about a ‘list’ of objects or api calls that always need [deferlow], it is more about realising general situations in which these things are needed. so no list. however, i do agree that the documentation on this could be better. e.g. there should be a discussion-chapter somewhere in the docs about ‘strategies for programming with the live api and fitting everything else in and around it’. or a snappier title of course. preferably not written by such a hacky douchebag as myself that does not really know what the hell he is talking about.

api calls in both live and max (and most other media software on the planet) happen in a slower, deferred, not as high priority and to some degree unpredictable thread, because the important stuff – audio (and video, but that is different again) – must never get interrupted or glitch. in fact live and max are two of the most amazing and robust softwares in this regard and it is one of the things that makes them special. letting ‘us’ in there, right in the guts of the software, to mess around and hack and create our own things, is very tricky and sometimes difficult. but that is what max is. i am constantly amazed that max even works at all with me abusing it all the time.

and yes, obviously, i had a pretty slow day today (!!), but i just got an email with some c++ stuff in it so i’ll be locked away this weekend doing that as i really suck at it.

p.s. broc is still the man! i learn loads from him!

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215710 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215710 Fri, 11 Nov 2011 02:37:02 +0000 basvlk Seriously helpful thread! I finally understand the language they’re using in the manuals.
the below may be obvious? let me know…

I think you can interpret the message “live.object: Setting the Id cannot be triggered by notifications” as follows:
1) because you clicked a different clip in Live, the live.path object had to send out a new path ID. this is a notification
2) the notification (the new path ID) was going to set the ID for the live.object BUT.. “Setting the Id cannot be triggered by notifications”

But not everything you do (even some possibly complicated stuff) is triggered by a ‘notification’ from live: eg if you trigger the path directly by clicking a message box with the path name. Maybe the attached device illustrates it. I changed from ‘getpath’ to ‘get name’ because it illustrates my point a bit better. It definitely means I can get rid of a lot of deferlows in my patches.

I think I learned more in 3 months on this forum than I have in the year before :-)

]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215711 <![CDATA[Re: getpath of a clip only with deferlow?]]> http://cycling74.com/forums/topic/getpath-of-a-clip-only-with-deferlow/#post-215711 Fri, 11 Nov 2011 02:57:59 +0000 basvlk Awesome. I just was able to cut out 32 deferlows (see clipping) : not understanding when they were required, I had a deferlow after every live.path that was feeding an id into a live.object. Now I know when I need them and when I don’t!

– Pasted Max Patch, click to expand. –
]]>