hi there, quick question,
say I got a [send] object and many pairing [receive]... how do you predict the ordering of messages, or can't you do it at all? Meaning, which receive will actually receive the data first? The one that was first connected?
My hint is that you have no way to control this
cheers Alex
Meaning, which receive will actually receive the data first? The one that was first connected?
Althougth that is true for local connections, weirdly enough, in non-local connections the last created receive object receives data first. In local connections the problem can be solved using trigger. A solution for non-local ones doesn't occur to me.
If there is really no workaround on this: What if a second argument would define the order? (e.g.: [r bala 1], [r bala 2] ... )
alabala
On 2010-05-10 07:34, Alexandre Porres wrote:
hi there, quick question,
say I got a [send] object and many pairing [receive]... how do you predict the ordering of messages, or can't you do it at all? Meaning, which receive will actually receive the data first? The one that was first connected?
My hint is that you have no way to control this
as soon as you use send/receive or connect multiple inlets to a single outlet, you are deliberately giving up control on order of execution. even if you think you might have found some logic behind the order of execution, be aware that this is purely by chance. don't rely on it.
if you need to make sure of a certain order take explicit measures! it's easy.
mnasdr IOhannes
PS: rumours are that there are at least two different receive objects living out there that have a way to define explicit ordering. don't try to hunt them down
On Mon, 10 May 2010, IOhannes m zmoelnig wrote:
PS: rumours are that there are at least two different receive objects living out there that have a way to define explicit ordering. don't try to hunt them down
one is [iemguts/oreceive]. what's the other one ?
and why "don't try to hunt them down" ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On 2010-05-10 17:18, Mathieu Bouchard wrote:
one is [iemguts/oreceive]. what's the other one ?
[gemreceive], which is a clone of the above.
and why "don't try to hunt them down" ?
because most likely there are better/more portable ways to fix the original problem.
this reminds me of a lot of students that believed that dynamic patching would magically solve all their problems they ever had, as soon as they first heard about it.
gmasdr IOhannes
-
Alexandre Porres -
IOhannes m zmoelnig -
Mathieu Bouchard -
ypatios