the osc-way to send multiple messages “at the same time” is to send them all in one “bundle”. the OSCDecoder seems to handle bundles correctly already to which several OSCDecoders are connected that listen to different /addresses each
the semantic of bundles is similar to vvvv´s frames. so i do not get the point how one oscdecoder should sensibly deal with bundles, apart from just deleting everything which does not belong to him (actually this is better than just looking at the first message, but also not the best way)
does it make sense to have the same message in one bundle twice? i dont think so.
can the oscglue send bundles? what osc-send code are you using? vvvvs oscencoder cannot yet send bundles.
i´ve picked some of your utility functions from the vvvv-source. i do not send bundles. as the VST plugin wrapper sends me individual ParameterChange callbacks there is no natural way of sending things in bundles, as i dont know (yet) where one frame starts and one frame ends.
as u7angle suggested, it would make sense to collect parameters in the plugin (but then i´d rather send one big message rather than a bundle with multiple messages)
if you are only receiving single oscmessages the first hurdle for the message is the udp (server) node. all messages except one received in the same frame will be discarded as long as you don’t set the “Queue Mode” to “Concatenate”. here all messages received in that frame will be concatenated.
ok.
all OSCDecoders receiving that message will only check for the first /address and discard it if it doesn’t match.
this is the issue. this should and can be changed. even if messages are correctly bundled on the sender, there is now way to ensure that only one bundle gets received per frame.
i propose an OSCTokenizer which waits for bundled messages and makes sure that only one bundle gets delivered per frame (similar as the tokenizer in enqueue mode), it should split out the concatenated OSC messages directly, so they can be received by aforementioned OSCdecoders.
therefore you’ll have to make sure the messages are seperated somehow.
now the udp(servers) delimiter in combination with a tokenizer comes handy. set the delimiter to a symbol you don’t expect in the stream…haha…i know…i tried with a “!”. make the tokenizer receive the udps string and set its seperator also to “!”. now you can either queue the messages and receive them one by one or spread them.
NO. please dont. this is very dangerous practice. as all numbers are encoded binary, all messages containing e.g. integer 33 (=ascii !) will be rendered unreadable by the tokenizer. for 4 byte floating points expect 4/254 = 2% of all messages killed.
when spreaded the OSCDecoder is missing a feature. to directly connect it. but if you know how many messages you receive you could stallone them to several oscdecoders again
…hm this is unsecure…
but how do you know, how many UDP packets will be received per frame?
and anyway bundles are cooler. they even can have a timestamp which could probably replace the extra /Time message sent by oscglue?!
this could be a pin of the OSCTokenizer described above.
but the main point of the time-out is currently getting the timelines position (Ableton Live doesnt sport a MidiTimecode out) and not the parameters sending time. i do want to have timecode out, even if no parameters are changed.
spreading the /address pin of oscdecoder has another drawback: the output of the OSCDecoder would be a spread of the arguments of the received messages…then we’d need an additional binsize to know what slice came from what /address…you see?
i would like to have similar semantics as in e.g. midi controller in. just have one output slice per incoming address.
as most of the messages we´re dealing are running parameters a usable solution would just return the last received value per address.
keep it simple to use. no name-value pairs, no changing spreadcounts, just the running parameters, newer values overwrite older values.
dont invent ad hoc solutions to the greater “one mainloop per patch” topic. these things will fall into place later.
parameters would be an issue. i propose each OSCdecoder would be restricted to one OSC signature. when using the decoder you specify the signature as a string (e.g. I I F) in a config pin, and you will get 3 output pins with the right subtypes, which will spread to the incoming adress vector.
having one oscdecoder deal with many messages should be better performancewise.
advanced uses can be implemented with a special oscrawdecoder which would just decompose concatenated OSC messages into the individual parts as string spreads. (three pins for adresss, parameters and binary data + a node to deal with the latter)
ok, thanks for the input, now your turn agin…