Inconsistent live.observer / live.object behaviour
Hey folks, I've been at it 4 hours and it's time to ask for help.
The patch below is behaving (to me) strangely. The intent is to find a Looper device on the same track as this patch. I was using class_display_name but for debugging purposes just switched it to "name" and that has shown me that my "loop" isn't working as intended.
Here's a quick visual of the patch and here's the debug output:
So as you can see:
when the patch loads (when I hit "save"), it queries the canonical parent and gets a list of devices
It then groups / loops through those devices and we can see that we are indeed getting 3 individual device ids
It then feeds those device ids to the live.object and queries the object's name
(the rest of the patch is non-functional while I debug this issue).
even though I'm printing out 3 different device ids, I'm only printing out the name of the last device in the chain (id 9).
The weird part is that I actually had this working, and then I faffed about and now it's no longer working.
What I'm seeing is that it's listing all 3 device IDs and then listing 3 (of the same) device names. In the past it would list: device ID THEN device name and then the next device ID and so on.
I'm missing something about program flow or it's late and I'm missing something obvious.
Can you help me find the flaw in my logic?
this should get you parameter ID's of
device named "Looper" in same track.
but don't place multiple same named instances in the track
P.S.
I don't know where one has to defer querries,
you must check that yourself
Hey thanks for the response... and the patch!
Yeah, that's the clue - the [deferlow] here was the issue. I'm still not clear on when / where you have to defer messages going into live.* nodes.
Thanks for the patch, it's essentially the same approach as mine with a few notable differences, namely zl.iter instead of zl.group, as well as iterating through all of the parameters of the live.object instead of just directly getting the name.
And finally, I'm a bit stumped by the last join @ triggers 1 - I've seen that used before but haven't dived into its purpose. Could you elaborate on that?
@triggers attribute is what it says - which inlet triggers output.
Haha, okay! That sentence means nothing to me, but I'll RTFM and I'm sure it will make sense eventually.
Thanks for everyone's help.
ok, so more detailed :
join object has several inlets.
As default only 1st one triggers output.
To override that and set other inlets as "hot"
(means that if someting arrives at THAT inlet output of all
so far collected inlets gets out)
one can set @triggers attribute.
even several ones like @triggers 2 3
or ALL @triggers -1
which would then make join react same as pak object.
You will find that attribute in other objects, for example combine.
If you looked at help file of join,
I would not need to type all this...