OSC Monitor?

  • Does anyone here know of a good OSC monitoring utility for OSX? I'm needing to debug two-way OSC traffic between MonomeSerial and Bidule. It doesn't look like Bidule has an OSC monitor built in.

  • http://poly.share.dj/projects/#%5B%5BOSC%20utilities%5D%5D

  • @chris
    Thanks for the link! That looks like just what I need. I will be curious to see if I can run two of these at once where one is listening in on Port 8000 and one on 8080 (two-way OSC traffic).

    BTW, I'm working on a Bidule-based LFO --> Midi CC app for the Monome and starting to make some head-way. I'll post it up once I have things working solid.

    -cm

  • I'm working on a chunk of code to listen and redistribute messages (so as to send to multiple targets at once), but it will also work as a wiretap like you describe.

    If you want, I can sit down and crank it out tonight :)

  • i'm working on hacking out an OSC monitor for use in Bidule (Therefore this will be platform independent)

    anyone interested?

    regardless, i'll make something up on the wiki page sometime nearer to the targetted 2018 completion date. heh.


    ;)

    -JP
    (i stress the 'hack' part btw)

  • Count me in, pardner!

    I've been a bidule fan for some time, but somehow the OSC send/receive and MIDI patches have never worked for me.

    There didn''t seem to me to be an easy rule to work out which end or point of view is intended when using the terms send or receive .... one man's send is another's receive.

    For example, it's taken me a couple of weeks to figure out exactly what monome serial means when it says "listen port:8080". (I think it means that the monome hardware is listening to port 8080 on localhost). Maybe this is just so obvious to OSC aficionados that it's just not worth explaining to a country idiiot :=)

    Anyhow, keep me posted and if I can help out in any way e.g. testing, docs etc please feel free.

  • + 1 for the bidule osc monitor. i'm always slightly puzzled by the osc nomenclature, although i suppose "listen port" infers a receive port, as you "receive" speech when you listen to people. yeh.

  • +1 i would love something like this. if nothing else, to try and debug to figure out why quadrants won't work in windows!!!!!

  • @ miaouxmiaoux

    totalement vrai, but what is doin' the listenin' and receivin'?

    monome serial interface or monome hardware, the one with the real buttons, or (in my case) polygome software, the one with the on-screen matrix of lights? Each object, real, simulated or soft has its own (definitions of) sends and receives.

    Puzzled this wit's head for a while.

    Also, there are cases when the IP address has to be the host's or server's, others when it has to be the remote clients, others when they all default to unmentioned. If I could only "see" i.e. monitor what an OSC object "sees" in real time, talking or listening, it would save interminable experimentation with perms and combs of settings.

    I'd also welcome a simple get-started intro to OSC messaging e.g. the similarity between message hierarchies and unix-style directories, how it gets packetized in or for udpsend and unpacked in udpreceive.

    As I write this, it's obvious to me that I should be answering these questions for myself. But then, if I've encountered these questions I bet others have too - on osc.org and supercollider forums scarcely a week goes by without a new request for "how it all works". I am new enough to remember my first question unpacking the monome: what on earth is a prefix? and why are some /sys and others not.

    And why, as a musician, I should have to get down to a network and machine addressing level - I'm still not sure what adc and enc checkboxes "really do" in monome serial - and taking the lazy mac way (if you have to consult the manual, it's a dud app) haven't yet strained to search for the answer which must be around somewhere like the wiki.

    I'm reminded about a possibly fictional anecdote about Napoleon who was asked what qualities made for a great general. His reply went something like this:

    "If I were appointing a general, I'd note which of the applicants were intelligent or dumb, lazy or hardworking. Then I'd choose the lazy intelligent one, because this one will look for and invent brilliant new ways to save himself work."

    I think this is a good description of all the great mathematicians.... the absolute worst case is the intelligent hard worker because they won't take advice and won't stop working hard rather than smart, and if it came to the choice, the dim hard worker is to be preferred for exactly the same reasons. Of course the fourth case has no business trying to play a monome (only joking) :-)