data for pattern stop is ignored

[gentleclockdivider]

Sequencer ignores changes ( -1 for stop )

As you can see the sequencer takes data -1,0,1,2 for pattern changes .
Just for fun I made the first data module -1 also trigger a data named 'hello' that goes into a numeric readout
I am totally aware that this does nothing except giving an error in the readout , but at the same time the pattern is also ignoring the -1 for stopping
The way I reproduced the bug is by copy/pasting the original -1 data module and renamed it ( in this case 'luck')
Changing the original -1 data to any other value for pattern changing does nothing , it has become totally unresponsive .
Is it because the error message that the originla -1 is ignored ?

Here's the file

[gentleclockdivider]

Maybe this is more obvious

[gentleclockdivider]

the bug is verry easy to reproduce
-create step sequencer set to play / module
-create three data modules , -1,0,1 , route to [play pattern index
-create numeric readout
-duplicate the -1 data and name the new instance 'whatever comes to mind' and route this into the numeric value

[colin@loomer]

It is as you said: errors stop events. And this is by design, because otherwise an error from a single module could end up generate tens or hundreds of downstream errors.

In your case, -1 goes to the 'luck' module, then to [numeric value], which raises the error, and stops the event before it ever goes to the [poly step seq].

[gentleclockdivider]

I don't really get the flow , sure the event stops at the error ,numeric value module ', but it was the last halt for that event anyway
Isn't there another event also going from -1 to pattern in , independent from the event that causes the error ?

[colin@loomer]

No, same event is sent from -1, first to print; then to "luck", where it fails. And if that hadn't errored, it would then be sent to [poly step seq].

In your example, not failing the event is benign, but in other cases, if the event isn't stopped at the first point of failure, you can get loads of cascading events as modules downstream are expecting values they never received. Which is why the rule is: events from a single source stop on failure.