diaseis

So I have this odd looking patch which essentially doesn't do anything meaningful (it's extracted from a much bigger and complex patch that I'm debugging). For now, on "dump" message, it basically removes all the elements of coll only to put them back in there right after.

However, this goes on an infinite loop : the dump message never terminates (just like if coll was streaming what it receives and dumping it instantly).

- Adding a short delay (1 ms) will prevent the looping

- Having only one item stored in the coll object (e.g. remove the message 2 2) also prevents the looping.

- Removing the "remove" message prevents the looping

So I wonder if I came across a bug or if I didn't get some subtlety about how coll is supposed to behave.

Also, a quick fix tip would be welcome :) (I tried to use the bang that coll sends when it has finished reading the data but that bang is never sent)

comment

pack

message

button

prepend

coll

However, this goes on an infinite loop : the dump message never terminates (just like if coll was streaming what it receives and dumping it instantly).

Things I noticed :
- Adding a short delay (1 ms) will prevent the looping
- Having only one item stored in the coll object (e.g. remove the message 2 2) also prevents the looping.
- Removing the "remove" message prevents the looping

So I wonder if I came across a bug or if I didn't get some subtlety about how coll is supposed to behave. 

Hi !
So I have this odd looking patch which essentially doesn't do anything meaningful (it's extracted from a much bigger and complex patch ... 

strange-behaviour-of-coll-object-with-dump-never-stops-reading-the-data

Hi. This is not a bug. You have, perhaps unwittingly, created an infinate loop because of the way Max works.

The easiest way for you to understand what is happening is to use the debugging tool. Insert a Break watchpoint in the cord running from the first 

 will be loaded with the two data items and then the debugger will be triggered. Now use the dubugger to step through the process (by clicking the small down-arrow with the dot underneath it) and see what happens:

image.png

The dump message puts the coll command onto the processing stack and the first item in the coll is output. This immediately triggers your command that removes that item from the coll. However, this also resets the index counter that dump is using to sequentially output the data. You then re-insert the data again at the end of the coll so there are still two more items for the dump command to read. Those processes are then taken off the processing stack and the scheduler returns to processing the dump command. However, instead of there being only one more data item in the coll to process, it thinks that there are still two again, so the loop goes around a second time.... and again and again forever. The "finished dumping" bang never happens because it never finishes.

This does not create a "stack overflow" error as the number of processes in the stack never changes but the endless loop of rapidly repeating commands will eventually crash the scheduler counters.

The various measures you mention will "fix" the problem in different ways:

1) Adding a delay will cause the scheduler to move the relevant step from the active stack to the deferred stack allowing the dump to complete but you are likely to only get one data point re-inserted.

2) Only having one data item means that the dump process completes in one cycle before it is removed from the stack.

3) Taking the remove command out stops the loop because the coll index counter is no longer reset back to the first index line every time the cycle goes around.

I'm not sure what you are wanting this rountine to do but I hope that helps you understand why it crashes!

The easiest way for you to understand what is happening is to use the debugging tool. Insert a Break watchpoint in the cord running from the first [trigger] to the (dump) message. Hit the {bang} button to start the process. Your[coll] will be loaded with the two data items and then the debugger will be triggered. Now use the dubugger to step through the process (by clicking the small down-arrow with the dot underneath it) and see what happens:

The dump message puts the coll command onto the processing stack and the first item in the coll is output. This immediately triggers your command that removes that item from the coll. However, this also resets the index counter that dump is using to sequentially output the data. You then re-insert the data again at the end of the coll so there are still two more items for the dump command to read. Those processes are then taken off the processing stack and the scheduler returns to processing the dump command. However, instead of there being only one more data item in the coll to process, it thinks that there are still two again, so the loop goes around a second time....  and again and again forever. The "finished dumping" bang never happens because it never finishes.

if you want to restore coll like that - which makes no sense at all,

there is no reason to remove anything, but restore using same indexes and data.

again, no use for that that I can recognise.

routing symbols allows this to use also symbols as indexes or data.

max prepends "symbol" in case it has to output single non numeric item.

if you want to restore coll like that  - which makes no sense at all,

there is no reason to remove anything, but restore using same indexes and data.
again, no use for that that I can recognise.
routing symbols allows this to use also symbols as indexes or data.
max prepends "symbol" in case it has to output single non numeric  item.


 for your very detailed explanation, that's exactly what I needed. I've been able to find a proper fix thanks to this (basically I transfer all the data to a second coll object before updating the content of the first coll object, seems overpowered but it's actually quite flexible and opened new possibilities !)

 The minimal example I gave doesn't make sense indeed. I use it in a much bigger patch in which I actually replace values with other values :) (I won't get into detail as it would be too long to write and to read)

Thanks a lot @Andy Maskell for your very detailed explanation, that's exactly what I needed. I've been able to find a proper fix thanks to this (basically I transfer all the data to a second coll object before updating the content of the first coll object, seems overpowered but it's actually quite flexible and opened new possibilities !)

@ Source Audio The minimal example I gave doesn't make sense indeed. I use it in a much bigger patch in which I actually replace values with other values :) (I won't get into detail as it would be too long to write and to read)


Strange behaviour of coll object with dump (never stops reading the data)