QC OSC Implementations

Ok this seem like my clue to chime in here with a quick summary of my findings with sending and receiving osc messages into QC (brief as i'm on a ipad at the moment).

Stock OSC patch. To borrow rob from hexler words 'the built-in OSC receiver in QC in that it sometimes outputs 0’s instead of the last received numeric value, causing something best described as “stuttering” when used for visual output'. Also receiving a string in a structure will crash QC.

qcOSC. An excellent patch for automatically working out osc paths and data types. I have noticed some discarded messages when receiving extreme amounts of data. This patch does not use vvosc framework. Crash when using inside of an QB application (possibly because it runs on the main thread?)

BBOSC https://github.com/jdelStrother/BBOSC - ok our plugin, the receiver patch seems to be getting flooded with osc messages. You can turn on discard messages to stop this but it may loose key information. There is a bug when it comes to sending a message in an array. Uses vvosc framework.

Wildbunch https://github.com/pizthewiz/WildBunch by @jean_pierre this is a slim down version of BBOSC it removes allot of the unused clutter from vvosc. 10.7 only at the moment. This plugin is where I think we should develop from. I think jean is away/busy at the moment but hopefully we can convince him to do a 10.6 version. And fix the 'null' send bug.

re: BBOSC/"WildBunch". What is the "null send bug"? Is that the same as what you mean by "getting flooded with osc messages", the same as the struct bug, or something different? Does that mean that the composition starts slowing down?

It doesn't appear that "WildBunch" bundled all of the needed files to build the project.

Indeed, (after some extensive testing) WildBunch offers a great OSC sender implementation, except that it does not send unicode strings, but even crashes receiving apps and itself sometimes!!!

The WildBunch receiver works well, too. I particularly like that all messages are received as structures. This makes things very flexible.

However it cannot deal with osc bundles and there are dropouts, or loss of data: If you slip between frames, or need to receive messages that sometimes jitter beyond 60 Hz (if your composition manages to keep up with this frame rate at all ;-) you are lost :-(. Also the receiver cannot handle unicode.

Error on crash is simply:

Failed to get CharCodes from EventRef (-9870)

Probably this can be fixed by looking at the remarkable and unbeaten Best-Before(a proper)OSC receiver, which has none of these problems! Also, it is not just 'flooding' your app with data, but cashes all (possibly important state) messages that arrive in-between-frames. Optionally, if you are only interested in continuous controller data, you may discard them, as said above.

So, "slimming down" is fine, but if there is further development in the wild bunch direction, cashing of messages and automatic utf8 conversion of strings are important and should not be cut away.

Eventually, the wild bunch builds!

See comment on thread: "BBOSC & MnstriOSCTools incompatible? -- do not work in parallel!"

If it is 'ok' to distribute binaries over this forum, i could attach a fresh at-the-end-of-the-day-build (10.7.2, 64bit).

No, I mean, it's literally missing PonyExpress.xcodeproj, OrphanExample, and PonyExpressTests.octest from the dl. This has nothing to do with eventually working, plugin conflicts, though it may be that it's because I'm opening it in 10.6. I don't think so though, since I can see those files are actually missing from the download folder altogether. I appreciate the build offer, but I'm asking about this because I'm interested in opensource/stable codebase.

Heheh, to me, great OSC sender implementation ≠ dropouts or loss of data :-) I think the regular patch is OK for that :-)

With the regular OSC patch, when it gets a 0, which doesn't seem to be if the composition has stalled, or data transfer of the other app stops(?), one can use a sample and hold to get the structure to stick at whatever it was. So, that's not really horrible, though I haven't tested it for leaks or how it performs with a large amount of values. It feels hacky, but it works predictably. I have to actually terminate an app that's sending OSC to the receiving composition to see this happen though, so I may just be lucking out.

So, if I read correctly, the BBOSC will cache data if it hasn't had a chance to evaluate, or you can optionally drop frames? That's pretty nice. What's the deal with multiple versions of the patch not being able to be run - is this correct (it feels like maybe there's an underlying issue if this is the case, but maybe not)?

Regarding the my 'null bug' i have situations where i need to send a empty message. Normally i would just send a tickle to a specific path with no 'osc message parameters', however this does not work anymore. Jean has updated the protocols to osc 1.1 which i believe has replaced this empty message with the 'null' message, but this too doesn't work.

All right then, as far as i can tell those sources in the vendor folder are deliberately missing, because they stem from another open source project. You have to grab them from their respective location and symlink it, or put it right in place of the empty placeholder folder. In case of WildBunch they are located at:

https://github.com/pizthewiz/PonyExpress

https://github.com/robbiehanson/CocoaAsyncSocket

Best fun compiling...

Sorry i should have mentioned you have to pull down the other frameworks in order to compile. Jeam(pizthewiz) did put the old build in his download section of his github, maybe you could place your current build in there, folk and update his code with that missing line. This way it might give him a heads up that people are interested in his plugin.

Yeah, only WildBuch on GitHub appears to be read-only.

The stock osc sender patch doesn't seem to send structures(floats) correctly, i've never really understood why, OSCulator displays the message correctly but the python app i sending osc messages to never works, hense the main reason for BBOSC.

The problem is with sample and holding any value above '0' is... sometimes you will need to receive a '0' message

BBOSC does cache data or discard messages each frame(?). The multiple version of vvosc frame is a plugin restriction(?)

Shame, i would say try contacting Jean to change that but I think he is away/busy as he normallym very responsive on the PM's. Could we place a build here, as im also having trouble building and have ended up using the build (with errors) in the dev/debug directory, I would be more happy running your version without a build errors.

BBOSC receiver cashes all messages that were not taken from the internal queue on the currently executing frame. All other osc receivers just drop messages, if there arrive more in the time interval between two frames. Cashing messages is very important, if they are critical to the logical state of your patch.

Below you find, WildBunch (0.1.0-7-g901beea-dirty), the plugin of this day.

I wonder if kineme would be receptive to making some solid OSC send/receive patches. Seems like there is a long standing need. I'd gladly pay for it as a plugin. I'd also love to hear what someone like cwright has to say about the forever-undependable built-in OSC patches.

I did a run of performances using hexler's qcOSC patch for a project receiving data in QC from a jitter patch (a box2D implementation written in java). It worked, and solved the problem of QC's built-in OSC patches sending 0's (which really messed things up initially). Having multiple qcOSC patches caused crashes. Also, we maxed out sending continuous x/y/scale data for about 300 objects before the connection choked and crashed QC (reasons for this limit were not pursued, we just made it work). I think this was using the previous version of qcOSC on OS 10.6.

sorry about that, i added some build instructions to the README that should help clear up your build environment woes. the project uses git submodules to vendor the PonyExpress OSC library and my CocoaAsyncSocket fork. additionally the WildBunch target has a Run Script build phase that uses MacRuby to automatically set the build version info in the plist based the git repository revision information -- you can locally remove the Run Script build phase to avoid installing MacRuby, though you'll then have unchanging build version info.

correct, the typical flow on github is to fork a repository if you want write-access, then you can submit pull requests for upstream changes.

i'm glad it is somewhat working for you, it is still quite immature, especially the receiver patch which is considered unstable until the 0.2.0 release. definitely give the OSC library parent project PonyExpress's TODO a peak as there is quite a lot to do yet (bundles, timetag, OSC-over-TCP, et cetera).

unfortunately as defined in the OSC 1.0 specification, OSC represents strings in ASCII, it is not Unicode savvy (and sadly the 1.1 document does not make any affordances for Unicode either). i suppose internally it could send and receive Unicode, but i haven't really thought through the compatibility concerns when interacting with other clients.

as for the high frequency sending, it wasn't part of the usual workflow for the project i created PonyExpress and WildBunch as a part of, but if it is a blocker for others, i can certainly put it on the TODO list. at present both PonyExpress and WildBunch do a great deal of logging to the console, that certainly doesn't help. if you are a githubber, feel free to file issues as you encounter them in the WildBunch Issue Tracer.

Wonderful to see the designated bearer of hope reacting on the wild bunch of questions and wishes of this thread.

And you name it !!!, a proper implementation of

Quote:
bundles, timetag, OSC-over-TCP

would solve many, if not all the above mentioned issues:

Cashing of inter-frame messages becomes kind of obsolete, if we have bundles that guarantee for a synchronised arrival of data per frame. Even the better so, if the timetag (which actually is a feature of bundles) can be used to schedule messages ahead of time/frames and thus specify, when they become valid or should trigger some arbitrary functionality. All this will be even more save, if we can rely on the TCP protocol to realise state changes of our applications. Then, and only then, inter-frame dropouts of lightweight UDP messages typically sent by continuous controllers are all right (since you cannot respond to them visually any other then frame by frame anyway ;-) and we can discard all plugin-internal cashing, or buffering altogether. As a consequence,

Quote:
high frequency sending

is no more an issue, since a frame rate of 60Hz is close to nothing compared to the speed of our networks (including all C-compiled handling of some pity osc-messages).

As far as unicode is concerned,

Quote:
OSC represents strings in ASCII

but ASCII strings are actually enough (if you only let through all 256 chars) to send utf8 encoded strings, as BBOSC obviously does without any problem or compatibility issues with the various existing OSC clients or implementations of other systems. A QC-plugin would "only" need to recognise that the strings received are utf8 encoded -- and voilà, we have unicode strings sent via the standard ASCII specification.

Thank you for the added build instructions. I'll post my little code-change of the other thread in the Issue Tracer. It is not worth branching the project and, unfortunately, i have not time for any more at the moment.

So, thanks again for reading and commenting to this thread.

Excellent and informative response. Promising!

mc wrote:
Wonderful to see the designated bearer of hope reacting on the wild bunch of questions and wishes of this thread.

And you name it !!!, a proper implementation of

Quote:
bundles, timetag, OSC-over-TCP

would solve many, if not all the above mentioned issues:

Cashing of inter-frame messages becomes kind of obsolete, if we have bundles that guarantee for a synchronised arrival of data per frame.

Can you clarify this?

How can one make this happen? If one has initiated a consumer patch that starts a chain evaluating, and there's a process mid-stream that takes more time to evaluate than the rate at which the sender is sending values, there are exactly two options; have the provider that's upstream cache frames, or drop frames (or values, etc).

I'm not sure that a receiver can ever be in the position to "guarantee for synchronized arrival of data per frame". I can see how one could make a plugin perform generally well and have a minimum amount of latency between the time a signal is sent, and it's able to be accessed in QC, but the issue of dropping values or queuing them is still an issue.

It tends to be standard in QC to drop them; there are some patches that have taken the approach of queueing/buffering the values, but it seems to make QC perform oddly (no rule here, just a loose observation).

mc wrote:
Even the better so, if the timetag (which actually is a feature of bundles) can be used to schedule messages ahead of time/frames and thus specify, when they become valid or should trigger some arbitrary functionality.

What does "schedule messages ahead of time" mean?

It sounds like the only way that would work is if one introduces a delay "on purpose"... I'm unsure if I understand what you mean correctly.

mc wrote:
All this will be even more save, if we can rely on the TCP protocol to realise state changes of our applications. Then, and only then, inter-frame dropouts of lightweight UDP messages typically sent by continuous controllers are all right (since you cannot respond to them visually any other then frame by frame anyway ;-) and we can discard all plugin-internal cashing, or buffering altogether. As a consequence,

Quote:
high frequency sending

is no more an issue, since a frame rate of 60Hz is close to nothing compared to the speed of our networks (including all C-compiled handling of some pity osc-messages).

Can you clarify this? I'm not sure what you mean when you say "all this will be even more save...(etc)", and the conclusion that all cashing and buffering can be discarded.

mc wrote:

As far as unicode is concerned,

Quote:
OSC represents strings in ASCII

but ASCII strings are actually enough (if you only let through all 256 chars) to send utf8 encoded strings, as BBOSC obviously does without any problem or compatibility issues with the various existing OSC clients or implementations of other systems. A QC-plugin would "only" need to recognise that the strings received are utf8 encoded -- and voilà, we have unicode strings sent via the standard ASCII specification.

Hmm, I'm unsure about the ins and outs of that, but afaik, utf-8 encoded strings are backwards compatible with ASCII spec, so it probably doesn't hurt anything if it's "better" inside of QC for some reason. I have no clue whether that's the case or not.

mc wrote:

Thank you for the added build instructions. I'll post my little code-change of the other thread in the Issue Tracer. It is not worth branching the project and, unfortunately, i have not time for any more at the moment.

So, thanks again for reading and commenting to this thread.

Thank you for your thoughts. Thanks, in general, for everyone's thoughts on this thread.

My take, after testing this some today, is that the actual "stock" QC OSC patch is the "best" (gasp), from a standpoint of: 1-Not leaking. 2-Seeming to be "ok" in the amount of processing allocated to it when it's doing some work. 3-Being "ok" with multiple instances on the Editor. 4-Cleaning up correctly. 5-Seemingly running ok in non-QuartzComposer.app contexts (eg., a custom app).

qcOSC seems next most stable, but configuring it via settings, and no published source make it less attractive.

My results with BBOSC and the "WildBunch" OSC patches have been pretty mixed, but it's exciting to have them both be open source, because it provides a good starting point for getting something going. I don't think either one is necessarily better at receiving OSC messages on my system than the stock OSC patch (I've not tested sending at all), and they both seem a little slower (!) and have some issues with multiple instances.

As far as kineme making an OSC patch... idk. OSC is kind of a hacky thing! It's definitely ugly; we (err, I'm speaking of interactive graphics types) use it to enable us to do stuff in an easy way, but I feel like purists may have issues with OSC? I don't know what smokris et. al.'s take on it is though. Maybe some of the logic from the spooky would be a good starting point.

As mentioned, time is rare at the moment. Yet, i'd still like to clarify in short what i tried to say.

a) if you have bundles, you can group many messages together such that synchronous arrival is guaranteed at a certain frame (instead of collecting them sequentially over some frames with possible dropouts).

b) TCP is a handshake protocol, thus secure but slow. If we could choose this protocol for state-critical messages (usually much less frequent than controller data) we are fine and saved.

c) Yes, timetags, in principle, can hold the time of sending and you respond to any introduced delay on the receiver side, or timetags hold a future time, telling the receiver when to do something with the sent data.

d) Wherever encoding and decoding of utf8 takes place, it must be able to slip through the OSC channel. This is currently the case only with BBOSC.

All of these points functioning, would be a solution to all our problems, i guess.

In sum, i think OSC is a very flexible, lightweight protocol to exchange all kinds of data, if we only had flexible and reliable enough sender and receiver plugins. Apple's stock plugin is surely none of both. But an awareness of the discussed shortcomings in this thread is -- as was said -- promising and Mr. WildBunch appears to be on the right way...

With best hopes, mc

At the risk of going OT, any advice on troubleshooting OSC woes? All my tests currently are using localhost only on 10.7.2, QC 4.5, 32-bit. Like, how to trace what happens when the signal leaves the sender and somehow gets lost before it reaches the receiver? Or scrambled (floats structure), or timing gets off, or what appear to be conflicts with multiple instances? Too often in testing I set up something that works, then on reopen does not work anymore and all efforts fail after (using new ports, viewer off/on, trying different order of opening qtz's, new instances of sender/receiver, new comp, paste to new comp, restart QC, restart computer). Also in testing I can get some things to work while others don't, sending same data. qcOSC included, works usually, but (according to hexler) v.6 is supposed to work with multiple instances but usually does not in testing. I'm also using Bidule to send OSC data for testing.

A note about this:

I've been delving into this more, because basically, it would be great to have an OSC receiver (I'm slightly less interested in a broadcaster/sender) that rocks. I think a sender would be great as well. Errrrr, this is probably all clear from my initiation of the subject.

Anyway, I've been looking at samples I have, OSC/UDP related, both QC and otherwise, and I'm starting to wonder "why the fixation on VVOSC"? I want to be very clear; I'm in no way critical of that decision, because I'm still on the front end of this.

However, it seems like VVOSC framework is a little bit of a loosey goosey affair. The source code page makes pains to indicate that stuff may or may not work, and that the source is in a constant state of flux. That can be good and bad. It's great if it means that there's some kind of greater consideration of interfacing with the latest and greatest OSC developments, or whatever. It seems like OSC is pretty much "settled upon" though. I notice that there seems to be some solid examples and info about how to integrate VVOSC framework into projects, and that's a plus.

On the flip side; I used to have some pretty bad experience with TUIO and QC, but I realized recently that this was from a really old plugin (that may not even have been from who maintains it now, it seems). The newer TUIO plugin for QC (a google search away), has seemed to have some solid performance for me. The TUIO spec is basically OSC with some extra functions built in, to help setup the data for TUIO related activities. That plugin uses the oscpack framework. I find that interesting, and it seems like oscpack is pretty stable, and is being used in demanding scenarios.

gtoledo3 wrote:

mc wrote:
As far as unicode is concerned,

jean_pierre wrote:
OSC represents strings in ASCII

but ASCII strings are actually enough (if you only let through all 256 chars) to send utf8 encoded strings, as BBOSC obviously does without any problem or compatibility issues with the various existing OSC clients or implementations of other systems. A QC-plugin would "only" need to recognise that the strings received are utf8 encoded -- and voilà, we have unicode strings sent via the standard ASCII specification.

Hmm, I'm unsure about the ins and outs of that, but afaik, utf-8 encoded strings are backwards compatible with ASCII spec, so it probably doesn't hurt anything if it's "better" inside of QC for some reason. I have no clue whether that's the case or not.

not exactly guys, working off the spec, strictly speaking, OSC uses ASCII as its character encoding scheme, which only has 128 values in its vocabulary. while it is true that UTF-8 is backward compatible with ASCII, that only means for the 128 characters that ASCII represents, the actual data octets (8-bits = 1 octet) are the same in both ASCII and UTF-8; so ASCII is valid UTF-8, but UTF-8 is not necessarily valid ASCII. UTF-8 itself represents over a million different code points and has a variable length encoding of 1-4 octets, ASCII of course has a fixed length of a single octet.

this is all to say that while UTF-8 has a huge vocabulary of characters that can be represented, if ASCII is the encoding scheme only 128 of those million plus can be used. one could make an argument that the OSC library could just pass along data that it receives ignoring the encoding, and as long as both sides were aware and able, it would be fine -- this is what VVOSC does, see the in-line info in VVOSC.h for more details. however this is not spec compliant, and the behavior when both sides were not aware / able to handle non-ASCII encodings could be messy and difficult to debug. in Apple's case it just drops the message entirely if the encoding is not ASCII, other libraries might be left in an error state.

Apple's OSC Sender and Receiver patches disallow UTF-8, send ASCII input:

and UTF-8 input:

perhaps this would be solved by an explicit UTF-8 support mode the patch could be put into, but defaulting to UTF-8 support may set a strange precedent with garbled expectations for a messaging format.

Joel Spolsky has an interesting article that might shed some more light on character encodings: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!).

---

gtoledo3 wrote:
My take, after testing this some today, is that the actual "stock" QC OSC patch is the "best" (gasp), from a standpoint of: 1. Not leaking. 2. Seeming to be "ok" in the amount of processing allocated to it when it's doing some work. 3. Being "ok" with multiple instances on the Editor. 4. Cleaning up correctly. 5. Seemingly running ok in non-QuartzComposer.app contexts (eg., a custom app).

qcOSC seems next most stable, but configuring it via settings, and no published source make it less attractive.

My results with BBOSC and the "WildBunch" OSC patches have been pretty mixed, but it's exciting to have them both be open source, because it provides a good starting point for getting something going. I don't think either one is necessarily better at receiving OSC messages on my system than the stock OSC patch (I've not tested sending at all), and they both seem a little slower (!) and have some issues with multiple instances.

the WildBunch QC plug-in and the OSC library parent project PonyExpress are definitely of alpha quality. at present i am not aware of any memory leaks in either project, so if you encounter one/many please give me a holler. as for the performance, the default build scheme uses the Debug configuration for both projects log a great deal of DEBUG info to the console, you might want to try the Release configuration for non-debug needs. and aside from that, if you have multiple instance / stop / quit or resource load issues, please do report them (ideally via the GitHub Issue Trackers, especially with a composition that reduces the problem in a reproducible manner) and i will be sure to give them some attention.

OSC can be a little tricky to debug, several receiver implementations seem to operate on exclusive access to the receiving port (and some then share it across instances within the same binary where appropriate), so snooping OSC traffic can prove to be a challenge. i just replied to an earlier branch in this tread about string encoding schemes, it might be worth a quick read incase it provides a clue to missing messages.

if you are programming savvy, you could write a simple mirror tool, one which listens for OSC on a given port, logs it then resends the same messages to another port on top of an existing library (VVOSC, CoreOSC, PonyExpress, i'd recommend omgosc if you are good with javascript/node.js as it is very quick to get up and running and great for functional or integration testing. something like Osculator i think supports this kind of flow right out of the box, be sure to give that a look too.

stop/start and document opening order sounds like a race condition which to me would indicate port sharing problems of some sort, can you provide some concrete examples where you hit problems and maybe we can better guidance or suggestions for investigation.

VVOSC is a good, featureful library created by Ray Cutler (co-developer of VDMX) with a friendly license and to the best of my knowledge, was also the first Objective-C framework to wrap OSC (it has a MIDI sibling too).

the receiving end seems a lot more tricky to do well than the sending end, because it involves routing, exposure of message arguments and signaling. what features do you feel would make a great OSC receiver?

Thanks for the Unicode article. I read this one recently which was okay for an introduction. As a typophile I've sadly found QC's lack of Unicode support seems to extend beyond OSC. Try using the Command-key glyph in the Apple Symbol font to in a standard Image with String patch (in 10.5 at least it's a fail).

probably of little consolation, but the command-key '⌘' displays just fine through an Image With String > Sprite on 10.7, 10.5 is ancient history now! (0:

Here are my test comps that currently do not work for me. It did work at first, then at some point on reopen, no go. I would not be surprised if they worked for others, but i have no idea how to troubleshoot.

the first sender in your composition, an apple sender with a single argument of a struct of floats, is in an error state. and unfortunately a render failure will cause all downstream patches to not execute. the console indicates such too:

12/12/11 7:21:45.596 PM Quartz Composer: *** Message from <QCOSCBroadcaster = 0x7fbf21cf7a90 "OSCBroadcaster_1">:
Execution failed at time 0.000
12/12/11 7:21:45.596 PM Quartz Composer: *** Message from <QCPatch = 0x7fbf21cf76c0 "(null)">:
Execution failed at time 0.000
12/12/11 7:21:45.596 PM Quartz Composer: *** <RenderView: 0x7fbf2765bc00>: Render failed at time 0.000000s

if you disable it, the second patch an apple sender with 8 float args transmits just fine - so that explains why the second sender wasn't working, lets investigate why the original struct of floats isn't working. cracking open the Javascript struct-maker, it looks like you have an array that you are packing with strings, not floats. this probably isn't a big deal when you have an OSC sender with individual float arguments as it likely can coerce the types from string to float directly, but with a struct, it doesn't seem to be afforded the same level of flexibility. try the following instead:

_floats=[]
function (__structure struct) main (__string input[8])
{
  var result = new Object();
  _floats[0] = parseFloat(input[0]);
  _floats[1] = parseFloat(input[1]);
  _floats[2] = parseFloat(input[2]);
  _floats[3] = parseFloat(input[3]);
  _floats[4] = parseFloat(input[4]);
  _floats[5] = parseFloat(input[5]);
  _floats[6] = parseFloat(input[6]);
  _floats[7] = parseFloat(input[7]);
  result.struct = _floats;
  return result;
}

the qcOSC receiver now appears to work though the items in the float array argument out of order.

Ok, damn, got it, thanks for your patience. Yes, working again. Really was trying to avoid mixing types (except post receiver, which renders float -> string just fine). While I was troubleshooting/experimenting i slipped up and plugged in that js -- was using kineme structure maker when it stopped working the first time.

i also read that qcOSC makes no claims to handle anything else but float messages, so i don't expect structure of floats to behave 100%.

Okay, I have the four tests working in sync from qtz to qtz, two with built in send/receive, two sending to qcOSC. Though not sure how slow it would be with lots of data, used iterator+queue to sort qcOSC structure of floats. Thanks, Jean Pierre.

Have you tried sorting with the stock structure sort patch, jersmi? (You might need to change your keys to get it happening though). How does it compare with iterator and queue for speed and ease?

Good question about Structure Sort. I'll check it out.