order of outlet outcome in RNBO
I just started exploring RNBO and found some strange behaviour. Coming from Max I am used to the outlets sending data from right to left. but in RNBO that does not seem to be the case. But it's just my guess. How can I be sure which outlet sent the data first (for example in the picture below)
Max on the left / RNBO on the right. The sum in RNBO is incorrect
if I switch up the cords to the "+" object it works as expected:
Thanks!
It be interesting to look at the C++ generated... as this will reveal order of eval.
other question is... does it work if you add @hot 1 to + ?
Hi there,
Thanks for your reply.
It does work, if I add @hot 1 to the + object. However. Still that doesn't make much sense in my eyes:
I also exported it to C++. But not sure how to read the code. what's the best way to upload the .cpp file?
you don't need to upload the code .. actually just pasting the RNBO patch here would be enough, since then anyone can export the C++ code.
the best way to see whats going on is to use a C++ debugger... you can then look at the call stack for when the + inlets are set.
the thing here, is transport is a bit 'different' from a lot of other generated (rnbo) code.
since, a large chunk of it lives in the engine... and has a kind of callback interface.
so its not so easy to see in rnbo_source.cpp the cause/effect.
but a debugger will make it pretty obvious.
all that said, its pretty irrelevant... you may as well just report it to C74 as a 'bug', as they will be the ones that need to 'fix' it.
they'll also be able to state if this R->L outlets is indeed something we can rely on, or not.
as for now, the hot attribute is pretty important, as its pretty easy to get into a situation where the right inlet also needs to trigger an update.
----
all that said, I just looked at the reference for transport, and it says for outputs.
beats [number]Reports the position of the transport in beats within the current bar.units [number]Reports the current position of the transport as units within a beat (ticks).
so if units are a sub division of beats, then in your code, you would need to either use hot or reverse inlets,
since there are going to be times when units changes and beats does not.
... so perhaps this is just what you are noticing
Yeah, this is quite literally backwards with [transport], but not something like [unpack].
R to L is so fundamental with Max that this is insane to have an object do it the other way around.
@hot is not viable since it'll induce extra downstream messages.
For now I'm using [join @triggers <x>] and [unpack] to get this to work the way I expect.