Forum

OSCGlue bugs & features


#1

for all timeline addicts out there… OSCGlue will connect VSTbased sequencers to the world of OSC.
Write a text file to specify which OSC parameters you need, open up in the sequencer, and you will have a VST plugin with all parameters as specified…

download and documentation here

this thread could be a place to discuss this utility further
please write comments and further bug reports here… does this work with Cubase, MAX, PD, Flash etc. ?


#2

i’ve tested ableton live envelopes controlling one quad via OSC messages.

sending the data of one envelope seems to be no problem but more than one results in jaggy output in v4. especially the second message (lamp2) was jaggy. is there anything i could possibly do wrong ?

apart from that…using just this one envelope is lot’s of fun :)


#3

yep. i think this is a limitation of the current OSCdecoder in vvvv.
i suspect it not to handle more than one message per frame correctly.
maybe joreg can comment on that.

or anybody like to test it in event-based graphical languages like PD or MAX?

using two copies of the plugin and sending on different ports works better. in vvvv you will need to create two different udp receivers. while this is an ugly workaround, it is also a workaround vor LIVEs inability to show two different parameter curves at the same time. it also helps to record one parameter while not overwriting other ones (or did i miss something?)

apart from that i´d suggest dampering values in VVVV, as the parameter update rate of Ableton Live will not match VVVVs. So the animation will always have a jitter. e.g. one parameter for the value, and a second one for the damper value. may help.


#4

we had occasional glitches in LIVE when we had a wireless LAN activated. The CPU usage occasionally jumps to something like 63699 percent and live freezes for a short second.

deactivating WLAN made everything run smoothly.


#5

regarding mutliple OSC messages i experienced the same with the dome software…handling lot’s of syncs and control data.

what about merging all messages inside the plugin and send just one package. (although i don’t know if there is a limit to the message lenght. ) sure one need to rip the package on the other end.


#6

bonjour.
this is fancy shit.

i don’t have all the parameters in my head right now and will take a look at it soon. but i’d say it’s true we cannot receive more than one osc-message per frame per port right now.

what you can already prepare though is to make the tokenizer output all received messages as a spread (which could already turn out to be tricky - maybe we have to fix/adapt the udp-servers “delimiter” function for it to work properly). then, the oscdecoder will have to be adapted to deal with spreads.

meanwhile you could probably use several oscdecoders connected to a stallone (connected to the tockenizer) to decode several received messages per frame.


#7

i dont think osc can properly tokenized with the tokenizer. in fact i can not even think of a way osc can get ever properly tokenized. if you need to start at a random stream position there will always be some guesswork involved.

ok. udp + delimiting character + tokenizer in spread mode can do your second trick… hmm


#8

okok. concerning multiple messages i have to correct myself:

a) bundles
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 (besides the rare error thrown: “out of memory” that doesn’t seem to have any effect). this way you can already comfortably have only one udp(server) to which several OSCDecoders are connected that listen to different /addresses each.

can the oscglue send bundles? what osc-send code are you using? vvvvs oscencoder cannot yet send bundles.

b) no bundles
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. all OSCDecoders receiving that message will only check for the first /address and discard it if it doesn’t match. 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. 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…

and anyway bundles are cooler. they even can have a timestamp which could probably replace the extra /Time message sent by oscglue?!

still i see it is not always possible to bundle (it should be possible in oscglue though?!) and one wants to use only one port for convenience…

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? and then if you don’t receive all messages in every frame you have another problem because the spreadcount varies… did anybody follow and has an idea?

huh. i better stop now.
your turn.


#9

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…


#10

one issue left:
i tried to use your conversion function to send integers in OSC messages. can you confirm that your function works? i needed to invent my own to receive the integers i did send.


#11

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
since i would say having the same message twice in one bundle causes an undefined state anyway, it is good practise for each oscdecoder receiving a bundle to look for its /address and discard the rest.

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)
i don’t get that. i understand you get individual parameter change callbacks and it is therefore not harder to send bundles, but as soon as you’d collect the messages, why won’t you send bundles?

right. it shouldn’t be to hard to make all oscdecoders receiving multiple concatenated messages to look through all of them for the _last occurance of their /address.

i propose an OSCTokenizer…
couldn’t you do that with the current tokenizer yet, using “#bundle” as the prefix seperator? okkok it is again unsecure, like with my bad example of using “!” as a seperator…

just as the midireceivers have internal buffers the oscdecoder would need to have one too.

would like to have similar semantics as in
e.g. midi controller in. just have
one output slice per incoming address.
hehe. this way you would kill a very basic feature of osc to send/receive lists/spreads of data. i don’t think this is the way to go.

an alternative to your proposed single-address OSCDecoder could be:
the multi-address OSCDecoder:
where you also have to specify the parameters you expect to receive in as many slices as you have /addresses. just like you have to specify the slices to send on the OSCEncoder you’d specify the slices you expect to receive. this way the spreadcounts would not change unexpectedly.
example:
if you want to feed one OSCDecoder with 3 adresses to receive messages like:
/abra
/kada
/bra

you would also specify in a TypeTag pin:
ff
sss
i
for receiving 2 floats for the first message 3 strings for the second and 1 integer for the last.

now all comes in a single spread and not in seperate pins… or even seperate pins…but i’m not sure…both makes sense. anyway i don’t like the idea of having to specify what types of parameters you expect to receive (which both yours and my proposals would need)

maybe sending spreaded osc messages is more interesting anyway. and it seems to me more straight forward to implement

concerning sending integers see attached patch. did i get this right? i don’t see a problem there.

OSCintegertest.v4p (3.4 kB)


#12

it is good practise for each oscdecoder receiving a bundle to look
for its /address and discard the rest.
exactly

as u7angle suggested, it would make sense to collect parameters in
the plugin
i don’t get that. i understand you get individual parameter change
callbacks and it is therefore not harder to send bundles, but as soon as
you’d collect the messages, why won’t you send bundles?

its more efficient to send one big message rather than a bundle with multiple messages. at least on the udp level. and in the current vvvv implementation. of course you will loose the names, so a bundle would be preferred. but i could make this an option.

right. it shouldn’t be to hard to make all oscdecoders receiving multiple
concatenated messages to look through all of them for the _last
occurance of their /address.

perfect

i propose an OSCTokenizer…
couldn’t you do that with the current tokenizer yet, using “#bundle
as the prefix seperator? okkok it is again unsecure, like with my bad
example of using “!” as a seperator…

the messages within a bundle are separated by some header, so it is not just concatenated messages between the string “#bundle”. the OSCtokenizer needs to strip these.

the tokenizer handles only one character separators, but this need to be fixed anyway.

just as the midireceivers have internal buffers the oscdecoder
would need to have one too.
no, thats what the enqueue mode of the OSCTokenizer is for

would like to have similar semantics as in
e.g. midi controller in. just have one output slice per
incoming address.
hehe. this way you would kill a very basic feature of osc to
send/receive lists/spreads of data. i don’t think this is the way to go.

ok, this depends on the things you want to do.
i dont think that eg a VST plugin will have a reason to send spreads in this way. it is much clearer to have one adress per parameter. apart from that you could easily spread the addresses and get the values returned as a spread. i think using multiple adresses is the more powerful and general approach, and closer to the spirit of the OSC spec.

when communicating with other software or under performance constraints it might be helpful to send a spread as one variable long parameter list - but perhaps we need different OSCdecoders for different applications - i dont think it is necessary to mix them in one node

an alternative to your proposed single-address OSCDecoder could be:
the multi-address OSCDecoder:
where you also have to specify the parameters you expect to receive in
as many slices as you have /addresses. just like you have to specify the
slices to send on the OSCEncoder you’d specify the slices you expect to
receive. this way the spreadcounts would not change unexpectedly.

ok, but you could do this more clear and with muss less nodes (including all the necessary AsString, AsValues, Stallones, Vectors etc. when you have one node per command/signature

anyway i don’t like the idea of having to specify what types of
parameters you expect to receive (which both yours and my
proposals would need)

i like the beauty of dynamically generated pins and hate the explicit AsValue thingies you need when dont doing the thing in a way. and i am still a fan of strongly typed languages, even if its just for usability.

perhaps its just a separate node.


#13

okok. so…

  • i fix the current OSCDecoder to deal better with nonbundled messages.
  • one could implement a second decoder that creates typed outputs

what about the integertest?

still i don’t see a reason for OSCTokenizer for i think what it is supposed to do should just be included into the oscdecoder. the OSCDecoder already detects #bundles and if it detects two consecutive bundles it should buffer them the same way the midireceiver nodes do. setting bufferlength to 0 means: take only the most recent and discard the rest.


#14

okay, the osctokenizer is supposed to take care that osc bundles which are received in multiple successive udp packets will be delivered in one vvvv frame - but you could include all that code into the decoder.

currently people need many decoders (as the adress is not spreaded) so buffering all bundles in each decoder is likely to become a performance issue, but with future spreaded decoders it might be much less of a problem.
do you expect the current decoder dealing with spreaded adresses sometime soon?


#15

i expect the mentioned fix soon. the spreaded address in the decoder rather later.

still what about the integertest?


#16

still what about the integertest?
sorry for making pferde scheu. your patch works as expected.

did you rework the conversion routines at one point in time? i used some old code which happened to be on my laptop without checking the vcs and found the routines somewhat unnecessary complicated. sorry.


#17

so what do we have:

  • the oscEncoder is now spreadable. the spread can go out as #bundle or as single encoded slices (for what its worth…). the code for sending bundles is in the source (and really easy to understand/adapt)

  • the oscDecoder should now deal with concatenated messages as discussed above. always only the last received message per frame per /address is decoded. concatenated #bundles are not yet adressed.

alpha10.1 + src is up for internal testing in the repository. oschatz pls report your findings.

i can’t remember having changed the code for integer conversion. pls check the current sources.


#18

The timereceive example says to put the instrument on an audio track for sending time code.

I tried to put Oscglue on a Audio track but ableton Live says: “Instrument not supported in audio track”.

What’s am I doing wrong?


#19

drop it on a midi track.


#20

on a midi track it works, but I can only receive the notes. The time code I can’t receive.
I need to get the bpm and the audio level of a track. Is this possible?