S, R, IO nodes

kalle writes:

  1. rework of that S (Value) and R (Value) string and enum thingi.
    the devvvvs know what i mean.

  2. a possibility to have several S (Value) nodes on the same sendstring, everything added up or multiplied by choice in the R (Value) node

  3. IOboxes subtypes…

  4. please make my harddisk work again

- IOBox (value advanced) / option "radio button"

I think, a radio button like IOBox, that allows to select only one slice of a spread like simulated in the attached patch, would often be very useful to keep patches small and to clean them up.

I know, this is different to all other “pure” IOBox options as it includes dependencies between the slices , but I think it could be very useful and I do not see a way of making a " IOBox-like radio button module"

Markus

radiobutton.v4p (5.0 kB)

io-box (advanced): dynamic control of colums / rows / pages

(e.g. for always having as many buttons as another spread has slices.)

wouldn’t that be nice?

woei writes:

  1. io (string advanced): dropdown menu / list menu to select slices from a spread.

some ideas to the s & r nodes:

  • local sends/receives
    means this they transmit data just in the same subpatch without sending to other subpatches. at the momemnt i never use s & rs in a module because i fear that they could cause trouble when building a bigger patch…

-bind send variables to groups
maybe this could solve also the first problem with local sends/receives but im know sofware architect. the idea is to bind severall sends to group. a group would be something like a channel. the r nodes have to switched to this channel to have access to the variables. this could clear up everything a lot, when doing big projects. the group name could also be generated dynamic…
theres that “Self (vvvv)” node which provides information about the patch like name instance count. out of this information the group name could be created for both the sends and receives. this way local sends/receives could be created…

some featurewishes for speeding up patching/improve overview:

-creating and connecting send-nodes fully automatic by clicking on an outlet of a node with a keyboard combination

-creating and conneting io-boxes fully automated by clicking on inlets or outlets of a node with a keyboad shortcut. the name of the io box is taken from the correspondending inlet/outled. think of the many times you built a module and have to rename the io boxes the same name like the inlets of teh nodes they where connected…

-Automatic descriptive name of s&r after its send receive string. i use normaly a lot of time for labeling this nodes to gain cleraness, this could be done automatcally.

  • the advandtage of s&r are that no wires have to be drawed, wich clears up the patch. but the advatage has also a little disadavantage: if you have various receives distributed over the whol patch its sometimes difficult from where they get there values. a small gui improvement could help:
    Highligting graphically all r modules by clicking on the attached send module, or the other way round. this would improve the overview and debugging when doing large projects…

cheers
ele

just found that post from kalle on the now obsolete UsersWishlist page:


i like the idea of having kind of #0000bb:S (Value) and #0000bb:R (Value Spectral) nodes:
with the possibility to have more than one #0000bb:S (Value) on a channel (means: SendString/ReceiveString) with the
#0000bb:R (Value + Spectral) node summing up everything or an
#0000bb:R (Value * Spectral) node multiplying everything broadcasted.
this may realize patches with dynamically added modules which connect automatically.

and for the same reasons i’d like to have a string input for the ReceiveString replacing the enumerations.

my kindest regards to the vvvv-devs
@kalle

S + R (Value/String/Color/… LastChanged).

several S nodes on one SendString -> R outputs the lastchanged value.

similar to attched patch.


and PLEASE, PLEASE do something with the R nodes:
if they had a stringinput instead of the enuminput the sendstring for both S & R nodes could be autogenerated within the patch. elektromeiers wish for local S/R would be possible. Thanks to Self (VVVV) the nodes could refer to their own instance.

i beg this for 4 years. but this seems to be more complicated than it looks to us user.

ArtNetFake.v4p (9.0 kB)

another reminder:
IMHO my idea with sendstring for BOTH S&Rnodes would really offer lots of new possibilities.
i often tried to patch alternative S&R modules via UDP/Artnet but didn’t get managed by now.

regards from posh wiesbaden

A S&R overview would be very useful! I often avoid using S&R nodes, because they tend to get lost in subpatches.

another thread

hah,

not really beautiful, but at least a workaround.
is limited to values between 0 and 1
and has only 256 steps resolution.

run wishlist.v4p

i would really appreciate to have something comparable as “hardcoded” nodes…

Workaround.zip (5.9 kB)

i would go for a new system here. like a global variable system. there would be a global space for variables and each could have multiple reader and writer nodes. the reader/writer nodes can have kalles string input pin to define the variable to access. as soon as a new string is set to any of the writer nodes the variable will be created in background. misspelling the variable input would then just create another variable.

the feature to show the variable name on the node would be really helpfull to gain overview.

sounds good!
hopefully soon…

elektromeier wrote:

Automatic descriptive name of s&r after its send receive string. i use normaly a lot of time for labeling this nodes to gain cleraness, this could be done automatcally.

here is a workaround for this

setS+Rdescnames.zip (2.8 kB)

@tonfilm - but still, what happens when there are multiple senders (which by default will all write at the same time)? this is where the old enum with the list of commutative functions like sum, average, min, max etc. comes into play.

if we are talking about isChanged semantics (to emulate PD/MAX style S+R nodes) we need an epsilon parameter at a good place.

my suggestion:
behaviour “Last Takes Precedence”
see latest module in kalle.Modules.Spreads

http://www.dthg.de/praxis/infothek/lexikon/lexikon_fenster/LTP.htm

wikipedia knows the term but doesn’t have an explanation.
http://en.wikipedia.org/wiki/LTP

in most cases you don’t want want to influence the same slices from different senders.
e.g.
sender a -> slice 0-99
sender b -> slices 100-199
.