Yet another OSC question

I used work with max to send OSC to vvvv, there I used to send full packages useing the pak object. So I would list related values and send them all in one happy group to OSCDecoder, so my spread count always stayed the same.
Now I work with score and it sends only changed values, thus my spread count changes all the time and screws my spread order… what to do?
?help?

You build spread of adresses connect that to osdecoder, then asvalue, avoid nil, s+h with set pin set to onrecive of oscdecoder.

thats exactly what I am doing, but the spread size coming for OSC decoder changes

ho wait, my order is different I do OSCDecoder to avoidNIL to S+H to AsValue, would that be the problem?
edit: nope checked it, same thing.

if that is the case then it somehow also has to tell you which values those are, out of the spread. see? there must be more to it…

Im not sure I see…
Score have addresses and values attached to them (not lists just floats and ints), if a value is automated in score it will be set out. I organized it so that every module has is own sub address and decoder so for example
/Wave would have /Wave/x /Wave/y /Wave/Pos etc thats my spread in vvvv /Wave would have a decoder with all its values. but if for example I dont animate /Wave/Pos my spread in vvvv coming out from decoder will be shorter…
image

a nicer solution would be to use
A: a dictionary in VL where Keys are the addresses and values are the data
B: or if you don’t want to dig around in VL, there’s a dictionary node in mp.essentials which makes it super fast to hold hashed data (such as data arriving with osc). https://vvvvpm.github.io/#mp.essentials/github
C: or velcrome’s messages can also deserialize from any osc but that won’t solve the spreading problem vvvvpm.github.io/#message/node17

ok i missunderstood, so you have individual messages for each change. then it should actually work exaclty as you did, see simple demo attached. i cannot really tell how tihs is different to what you did though,…

OSCDemo.v4p (10.5 KB)

@microdee
A. I would love to get my head around VL but until now every project in last year contains a folder of monstrous vl patchs that will never see the light of day (may their tormented souls find peace one day)
B. yes! I was reading about it and tired many times to get essentials to work but with vpn I always get an error (the type or namespace…) and (the name Jarray…)
C. also cool but if it wont solve me problems I wont go there…

@joreg so a funny thing happened (funny in the sense of “whats the point?” or “why do we even try, life is just a random series of events”…)
I was looking at your demo and as you said it was no different from what I did, but it did work… so just for fun I put a udp in and entered the addresses Im using in score and still works! so why? I know now why, I dont know why the why, but I know one why. I entered the addresses in a different order then in my original patch… the order matters? I thought the order of the addresses I enter determinants the order of the output spread, am I wrong?

hm…there shouldn’t be any matter of order here. the order of addresses you specify as input to the OSCDecoder only defines the order of values coming out of it.

image

so if you turn them around, only the outputs also will adapt accordingly.

@joreg Exactly! I have a second theory- the value that in not animated used to be first in the list, now its last so it doesn’t disturb the order anymore.

@microdee so I got essentials going
when you said use dictionary you meant in parallel to OSCDecoder or instead of? would you mind giving me a little demo?

@ofersmi so you still have troubles with plain vvvv? if so, i couldn’t follow…

@joreg ho yes…
the solution was not really a solution… it stopped being a problem just because the problematic value (the one which is not being animated) was at the end of the spread, so it didnt disturb the order no more. but thats not really a solution because sometimes other values will not be animated…
Like you said changing the order doesnt really do anything…(well except changing the order)

There are girlpowers demonstrating exactly that. You will need a safekeep and default to ensure initialisation on the vvvv side.

yes you still need to use the OSCDecoder, the Dictionary is just that, dictionary of arbitrary objects. Check out the help patch of Dictionary (string string). Then for your purposes use the OSC addresses as the keys.

@velcrome Im checking the grilpower (the reaktor one…) but its always only one level deep so /Height for example, what should I do for deeper levels? like /Wave/Height? is that what “topic” is for? will I get rid of the confused spread size problem using Message?

@microdee so I was trying that but since OSCDecoder spits out only values without address attached I cant really dict it right? so I was trying going from OSC to string and trying to parse (berk…) the output. am I completely off base here?

Yes, that is what Topic is for.
Check TouchOsc girlpower too for a more advanced example.

probably ;-)

@ofersmi i’m afraid still cannot follow… so you open the patch and before any data was received obviously all /Wave/… will be 0.00, right? now the sender starts sending and all it sends will be arriving in the correct slice, right? so is it that you only have a problem with uninitialized values which don’t get sent by the sender? if so you can of course also set better defaults for those, eg. via the Default input of the AsValue (String). but even better you’d force your sender to send those value once to initialze…

or am i missing something?