bang order of signal-to-bang objects
I have the situation that I need to control the bang order of 2 edge~ objects. You ever noticed that right to left rule is not valid in this case?
I know there's no order for signal objects but when I go back to events I would need a predictable order. Any insight?
my obervation is that order of signal execution remains unchanged till patch gets resaved - reread.
after reading file :
changed order on right side, saved patch ... result is same:
reopened the patch ... new order works:
order is defined in patchline, and it does not get reflected on the fly, only after reloading the patch
----------
in any case inserting del 0 will enforce order right to left
>> I know there's no order for signal objects
but you are right, the rtl order should still be true because of the relative positions of the objects.
for loadbang this works perfectly, why it does not for signal-to-data, no idea.
let me think about it 10 more seconds....
... i mean... it most likely that the signal (cables) also have an order (as nothing in a computer runs parallel), but as we can see, it is not left to right.
maybe it is creation date, like in pure data?
(arent signal connections numbered through similar to jitter connections or #0 arguments?)
okay, i should have read a.s. answer and look into your patch first.
but however, it is getting more funny now:
i am not sure that means that the connections are always irrelevant, and it is rather the object itself (which of course also is part of a signal chain, in this case one which has no connections on patcher layer)
but this here can only be releated to the object. and the order is not reversed or difficult to predict, it simply does not exist.
sure, there might be jitter (i.e. different ones in each of the objects) due to the conversion of signal vectors to scheduler rate. but i´ve looked at the data stream, and it is definitely not a jitter pattern, it is random.
well, one reason more to clock those "metro to audio" objects from outside(!)
or will that also create funny results?
let´s see...
nope. that behaves well.
I suspected snapshot~ object was troublemaker in your first example.
but bang or metro driven, we are ignoring signal order and only grab current state of snapshot~ objects, which produces expected right to left order of output.
In Olsen's patch it is edge~ object that decides when to output
bang to non signal world, and there it seems that connection order counts
and temporary reordering of objects on screen plays no role.
here comparison of both worlds, on half ramp way snapshots get
triggered by edge together
on ramp top, 2 edge objects do
maybe i have a wrong picture, but i dont think that example #2 works because the order was already present in the symbol(s) coming into the inlet.
as far as i understand it, the bang can´t be directly connected to the value which is output, because that would mean that internally every first sample of each audio vector is always read and written into a register. which i doubt; i think it is only read and written when a bang comes in. (?)
but as you say, of course it is a different construct as the original problem, where he is coming from audio signals.
we also have to take into account that it is probably possible to write 2 different egde objects, one which produces this and one which produces that. so it might simply be a feature, and not unavoidable.
Last time I checked snapshot~ it captured all the time but did only output on demand, when banged or at (unreliable) set interval.
I tested again - still the same.
first starting count~ and then banging snapshot~ shoud not output
last seen vector chunk, but zero, If bang would make it start to capture.
That's why one needs to add vector size of samples if using snapshot~
to set count~ based looper recording length.
i only use it for GUI elements.
Thanks guys for the reactions. @sourceaudio thanks for clarification. I successfully fixed the order in my poly patcher. So in this case it's left2right. Interessting..