Spreadable OSCDecoder

A spreadable OSCDecoder would be very helpful.

A spread as input on pin “Address:” should result in spreaded outputs on “Arguments:” and “TypeTags:”.

Markus

ah, that old story…

*A spread as input on pin “Address:” should result in spreaded outputs on “Arguments:” and “TypeTags:”.
nkay, but arguments and typetags are already spreaded. so we’d need an additional “bin-size” output, that tells you how many slices belong to the input addresses…hm

then there is the other issue we had with the tuio-protocoll: multiple equal addresses in a bundle should also be decoded as spreads…

so those are two different additional different versions of how to spread the outputs…

how about so:
the address input is a spreadable configuration-input. for each address-slice the decoder gets a pair of Address/TypeTag outputs. like this both cases would be possible to decode easily.

disadvantage: addresses are no longer dynamic. problem?

i´d favour the seconds idea. the big advantage would be that these pins could already have their correct type no user needs to mess around with type tags and type conversion nodes.

perhaps this could just be a separate node to completely avoid backward compatibility issues? (which may have an quite similar OSCEncoder?)

a…which one is the second?

*the big advantage would be that these pins could already have their correct type no user needs to mess around with type tags and type conversion nodes.
i don’t see a way to code around that. typetags can be mixed. a single oscmessage can send a list of: iiiffsss
since typetags are dynamic on the senders side it is not possible to create individually typed outputs.

OSCEncoder is already quite spreadable.

i’d prefer this solution:

  • so we’d need an additional “bin-size” output, that tells you how many slices belong to the input addresses…hm

a very similiar aproach has already been used for the Dir node. especially with the new GetSlice Bin Size - possibilities one can easily segment the spreaded arguments, as i’ve tried out in the attached patch.
or did i foget something?

OSCDecoderSpreadedProofOfConcept.v4p (19.8 kB)

spreadable OSCDecoder as outlined by rrrr above ships with beta>18

i can’t see the spreadable oscdecoder on my node list in vvvv18.
If i send a spread of addresses to an oscdecoder’s address pin it ignores everything except the first address (i.e. the input doesn’t accept a spread of addresses). Am I doing something wrong?

Personally i’d like the implementation of a ‘spreadable’ OSCDecoder to work like a the KeyMatch node, which presents different outputs for each key (as presented by joreg in the second post). Generally if I want a spread of values in VVVV then i’d send them down one OSC channel, but if i wanted seperate values i’d send them down seperate OSC channels.

i was hoping to make myself very clear, that when writing “ships with beta>18” i mean it will ship with all vvvv-betas where the version number is greater than 18. that is, why you don’t find it in your current beta18, but you will find it in any beta released thereafter.

yeah sorry, my stupidity. got > and >= mixed up in my dazed state.
found a bug with oscdecoder (only in vvvv18) last night, will post in bugs section

found the bit about having to set a deliminator, so not a bug after all

no wait, double correction. will post my findings