OSCDecoder bug

Is anybody else having trouble with the new OSCDecoder?

I’m sending values from mrmr (iPhone OSC client) using tactilezones (which always send 2 values simultanaously).

Data is smooth on channel 0, i.e. /mrmr/tactilezoneX/0/iPod and /mrmr/tactilezoneY/0/iPod (as long as UDP is set to concatenate)
but data is erratic/non-existent when being sent on all other channels, e.g. /mrmr/tactilezoneX/1/iPod and /mrmr/tactilezoneY/1/iPod

There doesn’t seem to be any difference in the format of the OSC messages. The problem seems to be with having multiple OSCDecoders, as the first two OSCDecoders can happily pick up any of the 8 channels of data, whilst another set will complain.

In my patch, there are 4 osc decoders per subpatch and there are 4 copies of that subpatch. the first 2 oscdecoders in the first subpatch work correctly.

Also, if i put my cursor over the output of the OSCDecoder node then i get a working output. Doing this it is possible to have each value working one by one by hovering my cursor over each output.

current workaround is to use an earlier version of vvvv, possibly using netsend to send values across the current version.

ai sugoku,

are those messages coming in bundles? if not, can you make them come in bundles? if not, please test with the upcomming oscdecoder in beta>18 which is completely rewritten to be spreadable and even decode tuio-style protocols (with several identical addresses in one bundle). while it may introduce new bogus, it should in theory cope better with un-bundled messages.