Loop recursively (racks inside racks etc) through a Live set

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...

Thanks for the suggestion.

Unfortunately, the device suffers from similar issues. Values a returned randomly, if at all. And that's only with my simple demo rack. So this means another bug report...

Despite the bug, the Variation device was a useful example. I could use some of its ideas to adjust my patch.

All (sub) racks chains and devices are now listed correctly.

I want to improve only the order because now all sub racks are listed at the end. I will figure this out later.

Below is the patch for anyone who wants to use or improve it.

Follow-up question:

I’m grappling with the execution order due to defer low and I need some guidance. 

The left part of the patch below traverses all devices in a Live set and stores the id numbers in a bag.

There are two recursive loops: one for devices in rack chains and one for devices in drum rack return chains.

Next, it starts dumping the bag’s contents into a collection (orange cord) and doing other things during this process (yellow cords).

Here is the problem. The dumping process occurs before the two recursive loops (with a deferlow) are finished. Because of this, the data from the recursive part is not added bag and hence not to the the collection.

When I manually start the dump process (orange bang), all data is added to the collection since fetching all ids has finished.

So I tried to automatically delay the dumping using [delay], [pipe], [deferlow] etc in all kinds of places, and changed trigger orders etc. Nothing worked, and sometimes, the fetching process was even terminated at an earlier stage. But most of the time it just executed as described above.

In essence, how do I send a bang when the whole id fetching process is finished, so I can continue with other processes?

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.)

Adding a delay (in the orange cord) has the weird effect of processing only 1 item from the bag, even though it's executed after all id's, including the recursive ones, were added to the bag (according to a watchpoint going to the bag).

The recursive loop was isolated in earlier stages. I moved the 'yellow' part inside to see if it would change things. Even when it was outside, I still needed a bang to know the loop had been completed to continue with the further steps in the process.

The start of the loop is a button press, by the way.

An emergency break is not an option, as I want to traverse the whole Live set. The purpose of the Max device is to list all plugins, Max, and Live devices in a set, and it does this part well. The loop is not the problem, but not knowing when it's finished is. It surprises me there is no simple way to do this.

In a version of the patch where I remove the first bang to clear the bag, I get the result I want by clicking the button twice in a row. The loop executes again, but the bag does not accept duplicates. The loop is going very fast when executed inside Live. For some reason, the loop takes longer to execute in Max. But even though it can be very quick, a user might click too fast in case of very large Live sets.

When asking users to click twice, I can expect question why I don't program it this way.

I tried to replicate this double-click in Max, but it didn't solve the issue.

I attach the full device so you and others can see what it is supposed to do.

If you use it in a large Live set, you'll see that the generated list is larger after the second click on the button.

Changing the three toggles on the left results in the [bag] being emptied. This can't be done upon a button-click because otherwise a second-click would start all over and delete the deferred id's.

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.

Thanks for your adjustments. The collection instead of the bag is indeed a cleaner solution, and I added it to my device.

However, it does not fix the problem.

The deferred dump message is sent before the loop has been completed. This is the same result I got with my device.

Delaying the dump acts in the same strange way I saw when I delayed sending the bag's contents.

A watchpoint tells me that all ids from the collection are sent to [p StoreIdNumber+Path].

But the collection inside this sub-patch only contains the last id that was dumped.

Also when I manually bang before the delay to start the dump, only the last id is stored.

When I click on the dump message after the delay, everything is stored.

I'm puzzled.

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 :