trying to use the OSC ArgsToValue node(s) seems akward to me.
the node is defined with a CastAs of type T:
on using the node, the type stays open until you connect a certain datatype (e.g. a IOBox of type Float32).
from a patchers view this is pretty weird imho as this explicit type annotation happens downstream. is this node meant to be used like that?
ArgsToValues cannot be used with the above mentioned hack. i really feel that something is missing here…
hei motzi,
welcome to the beauty of type inference. a patch is not complete unless a type can be infered. this is a feature. a rather powerful one. in your case you made an explicit type annotation, but often you’d just have a node downstream, that implicitly propagates a specific type upstream and you don’t have to manually annotate anything. also instead of using an extra iobox you could have simply annotated the splicer loop output.
but then also let me point you at this wip:
those nodes should simplify using osc tremendously for many cases. would be great to hear your thoughts on those.
i’m aware how type inference in VL works, that’s not the issue.
in my case i originally had the problem that the type was not propagated through a matroska of another process node, making it impossible to set the type by inference. that made me think that i totally did not get something when it is so complicated to make a type explicit.
i repatched the whole thing flat and inference worked as expected.
i guess this is a bug then for the type propagation. i’ll see if i can reproduce it in a new, clean patch and will see if i just had bad luck.
regarding the UX: the OSC simple nodes are nice. still - if i have to explicitly set the Count on the input pins (with the ArgsToValues node) i find it a little strange to infere the types implicitly. (i know, it make sense codewise but setting parameters explicitly upstream AND implicitly downstream for the same message feels strange to me. i’ll get used to it)
ok, so we’d have to see what @gregsn says about the type inference issue.
and regarding the ArgsToValues with count input…would your case be solved with a kinda ArgsToAllValues node? ie. if you know you simply want all slices?
is the original patch generic? if so, then it should be possible. generic means you don’t know all types now, but someone from the outside will tell. you can see that in the patch by grayed out style vs. empty outline style.
we disabled that checkbox by default in the last betas because it is not needed so often. but in your case it should fix it.
Bingo @tonfilm !
making the process node generic fixes the type inference issue.
wouldn’t some kind of warning make sense here (that a generic output exists in a non generic process)?
edit: ah, so many shades of gray :)
yes good point, the error message should give a hint that making the patch generic could solve it.
working with types and their inference is one of the biggest hurdles for vvvv users in VL because this concept did not exist in vvvv in this way. there should be more documentation and tutorials for that.
i see many vvvv users getting nervous when elements are grayed out or stay generic and there seems to be the need to resolve the types as early as possible but in many cases it is much better to resolve the types as late as possible which is counter intuitive but more powerful and leads to more modularity.
@joreg regarding ArgsToAllValues : not sure if i understand
my intuition was like this:
i know that i will always receive a message with 6 floats ‘ffffff’ from my OSC source under this adress.
UX-wise an explicit configuration (e.g. input pin with string ‘ffffff’) would be nice to have as it could implicitly give you the count and make the output of the node non-generic. i see though that designing a node like this brings lots of other hurdles like dealing with different intermingeled datatypes. maybe an adaptive version of the node with multiple values from the same datatype (‘fff’, ‘iiii’, …) could cover most of the cases from the real world (i don’t remember ever mixing different types in a message).
@tonfilm: maybe it would help if the warning was more explicit (i.e. not grayed out but some color). in VS similar C# code would probably get a red wavy underline…
re “ArgsToAllValues” (bad name) but the idea: the current node is flexible in a way that it has a GetSpread practically built in, right? so say there is a message ffffssfii you could still reach the ii with just this one node. but true, in cases where you have ffff and you need exactly ffff the node still requires you to set a count of 4 which can be considered cumbersome. so a node that simply tries to convert all arguments of a message at once would probably be also very useful. see?
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.