Loop recursively (racks inside racks etc) through a Live set
I made a patch that loops through all Live tracks, racks, and chains to find all devices. This process gives me several properties of each level, such as the names. So, I need not only the device properties but also some of the tracks, racks, and chains.
I encounter a problem with racks.
Take, for example, an audio rack with three racks. The first rack contains another audio rack with two chains. Each chain contains an audio effect device, and the other two chains in the main rack do the same.
When the rack in a rack is found, it correctly lists all two chains and devices in those chains. However, instead of going to the second chain in the main rack next, it outputs the data of the second chain in the sub rack.
it’s as if Max 'knows' it still has to process the second chain in the main rack, but, the id of it is overwritten by the one of the sub rack.
After outputting the wrong second chain, it correctly continues with the third chain in the main rack.
When I add a third chain to the sub rack, it also ignores the third chain in the main rack.
This is only a small example. With multiple racks inside racks, this won’t work at all.
What adjustments must I make to go recursively through the Live set, no matter how many nested racks there are?
I made a small demo project that contains the rack and Max device (made in Live 11.3.25 so most of you can open it).
The patch is also below.
Hello Rivanni
Away from keyboard so I cannot see your patch..
Did you look in the new "Variation" device of L12 how the recursive loop part of the patch is made ?
It seems to work perfectly to list all devices in racks in racks in racks etc...
delay and deferlow are contradictions; delay will always output to the high priority if available.
deferlow moves to the end of the queue, which to my understanding should only help the stuff at the beginning of the queue, i.e. without safely having a certain own "property".
i dont think you can track when something has finished in defer or deferlow, at least not with the usual [t b b]-at-the-beginning approach.
if in amxd you really need to do that because it doesnt execute otherwise, a generous delay would be my preference.
to experiment with this it might be useful to isolate the loop mechanics completely from the actual process which is performed in it. (and maybe you want to have an emergency brake? something which does not allow, say, more than 50 loops.)
why do you use bag ?
coll can work better, not only because you can check it's contents for debugging,
but also can dump instead of running uzi
try this a bit rearanged patch
if that is not reliable, as alternative you could insert delay at id collection to
get end of list.
I am not using Live at all and can't say much about that weird behaviour.
But problem is in first place not knowing when
collecting of all ID's is done.
I have inserted couple of drum racks and have no problems getting all dumps all right,
but maybe live set is not loaded as much to cause problems.
One could pass id's from first coll directly to coll id_path
and insert that delay thing here :
but at the end I don't think that dump or fast output from coll id_path
can work because it is too fast for that last subpatch where you again query
all infos
maybe you need to insert one by one grabbing of previous coll.
something like this :
It must be order of execution,
you used sort 0, what do you want to sort exactly ?
I used next messages to step through ID's only when
previous one produced result.
My version only executes items from coll id_list one by one,
means when 1st item passes through all the "if this than that, add cr cr etc)
subpatches and outputs all it has, next item gets recalled.
Maybe your version puts a strain on the subpatches, so that they
output in different order.
You could try to simplify it and enforce order of execution.
just by triggering something in wanted order does NOT mean
that it will also execute in that order.
possibly this delay plays a role here.
but it can't work without it.