Ioboxes inheriting type from boolean nodes on same level

As posted in the matrix chat, here’s what I do:

-new Patch
-new Node with changing float output, eg LFO, but doesn’t matter here
-connect output of LFO to IOBox
-from this IObox connect to two further nodes, 1 boolean, eg OR, and 1 more IObox
-if you now change the parent IObox, to which the boolean node and 2nd IObox are connected, to ColsRowsPages, the child IObox will only show boolean values 0 or 1
…see attached patch…

At this point I’m not even sure if this is a bug- checked this back until beta34.2, it’s the same there…so maybe I’m missing something…
However, this definitely breaks with my understanding of vvvv, where a node on the same hierarchy level, ie both connected to the same upstream node, can not influence each other…? I can also say that every patcher I showed this to has been pretty surprised about this behaviour…
And if it’s not a bug but a “feature”, why would behaviour change between “Input” and “ColsRowsPages” setting?

thankstypeBug2.v4p (3.9 KB)

It works as expected if there are S and R nodes instead of links.

Edit: I was trying to write something making a lot of assumptions, gifs, etc. Previous image is just a superquick, fail-unsafe, dirty workaround.
But I ended here: ColsRowsPages is a way to organize visually data, or to understand what is what or where things are going. At least this is how I understand it.
So either I use it to input a predefined amount of data (with no node upstream), or to understand wtf I’m doing (with no node downstream) by sampling some data.
If I feed it with 24 values and set it to 3 cols and 5 rows, I only get 15 values out of it. I never use it as NITM (node in the middle), primarily because I don’t see why I should use it as that.

So I’m more surprised, from my modest point of view, that ColsRowsPages is used as NITM, rather than it’s sticking to bool.

Oh, I can’t help making an assumption:

  • since in ColsRowsPages mode a node’s spreadCount is fixed,
  • which is somehow exceptional, since this mode excludes spread wrap, making it plausible that this mode could fall under different rules
  • since vvvv makes (sub)type conversion automatically,
  • since there’s a sort of conversion hierarchy (bool > integer > float),

once you, from a float pin, input to a bool pin downstream, and at the same time (at the same level) to pins of subtypes integer and float, the IOBox in ColsRowsPages mode gets converted to bool, and there remains. Being in ColsRowsPages mode, makes the IOBox to stick to the “higher” (sub)type.

That said, do I sense some inconsistency, something that not exactly linear? The answer is yes.

Because from float to int to float, I lose float subtype from source (only in the ColsRowsPages mode IOBox), but the float IOBox returns correct values.
If I put a bool, downstream ColsRowsPages mode, the (sub)type become and propagates down as bool, which somehow is not perfectly aligned, IMHO, with the flawless passage experienced elsewhere.

Again IMHO:

  • can this be changed? Yes.
  • Should it be changed? No.
  • Should it be changed because this float to “everything is now bool” breaks logic? No, because it is more than reasonable to not use ColsRowsPages as NITM.

Based on the amount of effort I put into this, accordingly to my statements and their steadiness, what you pointed out will be fixed approximately within the next week, at most.

Here are some of the thoughts that lead to the current state:

  • We need a poor man’s type inference system to guide the user when entering values.
  • For that “subtypes” propagate upstream. The system helps with entering values, that all downstream nodes can work with.
  • Io boxes in the middle should typically not interfere evaluation. They should be transparent, like a local variable, so that the user can just use them to clarify the patch.
  • Because of this, io boxes in hidden patches do not need to evaluate. It should be sufficient to read from the upstream node that feeds the io box. (We actually do that)
  • However in case of ColsRowsPages mode there is some sort of resampling involved, which actually infers with evaluation and in these cases the io box acts as any other node: It computes new values for the output pin. In this case boolean values.

I can see that the system has rough edges. Maybe we should use the type system only for helping with entering values, but ignore it when displaying values.
However, I would also argue like h99 that ColsRowsPages is not really a good mode for an io box that sits in the middle of a patch.

Any suggestions on how to improve the system are welcome though.

1 Like

@gregsn not in the middle of a patch, but as an outlet\inlet for a module for example, or as a bridge between nodes; how do you manage an unpredictable spreadCount with an IOBox that has a fixed spreadCount?

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.