latest oscbonjour?

    Apr 16 2010 | 2:17 am
    Hi guys, I'm working on trying to send information to a running mrmr app on my iphone. Am using oscbonjour, from here:
    trying to find the source, but the svn site is gone. the article was writting in November 2006.
    i'm wondering if this is the latest news in using bonjour in Max/Msp?
    Any help or advise would be great. Thanks!
    Don Undeen

    • Apr 16 2010 | 5:21 am
      I'm pretty sure this is the source here (just found it today):
      I've been looking into the same thing. The new update of mrmr will work with the oscbonjour object but not as tightly as the MrmrServer software. I believe this is because oscbonjour registers and reads services of type _osc._udp. However, the Mrmr client is looking for services of type _mrmrsrvr._udp. Info can be found here:
      So what we need is a revamped oscbonjour object that is actually a mrmrsrvrbonjour object. I've just started working on this problem myself.
      In the meantime, I've got a working patch that establishes two-way communication between a single Mrmr client (ver 1.12) and Max. I'll attach it to this post.
    • Apr 16 2010 | 12:06 pm
      looks great clavendar, I'll start looking into this right away!
      looking at the source from teh svn above, I see the constant defined: static void oscbonjour_browse(t_oscbonjour *x, t_symbol *s, short ac, t_atom *at) { outlet_anything(x->out2,gensym("clear"),0,NULL);
      const char *type = "_osc._udp"; const char *domain = "local";
      maybe it's just a matter of changing that constant, or making it an argument to the patch?
      what I want to do, is be able to push a new interface to the mrmr client, using max/msp, not the mrmr server.
    • Apr 16 2010 | 12:16 pm
      hey clavender (oh, hey you!)
      got a javascript error in your zip file: js: MrmrLink.js: Javascript SyntaxError: missing ; before statement, line 7 source line:    var a = arguments[0].split(":"); //"a" is the arguments split between the ":" sign.
      though that line looks fine to me; I can't really see the source.
    • Apr 16 2010 | 4:37 pm
      Hey Don,
      Hmm. Weird. I've been writing these short little .js files to do small jobs in Max more as a way to learn Javascript. You could probably do the same job (it's parsing messages) with Max objects. At any rate, I'll attach the non-bundled version to this post. Let me know if that works for you better.
      Essentially, I'm working on the same thing as you are (uploading interfaces). The patch that I've created allows one to upload not only interfaces but also messages to the Mrmr Client. However, right now I've only got it working for one client at a time so if you're hoping to have two way communication between a central server and multiple clients (like I am) it's not the final solution.
      I'm on the same train of thought regarding the oscbonjour code adjustments. "_osc._udp" actually happens in three different places in the code. However, I'm just working on a hunch.
      Essentially, Mrmr transmits OSC over UDP (port 1337) but receives data over TCP (port 31337). This means that you have to have the device IP address to be able to send info to the client. The client presents its IP address when you open a bank which is how I'm making it work.
      However, the MrmrServer software doesn't need this extra step. Which is why I'm thinking it's an issue of registering a bonjour service of _mrmrsrvr._udp rather than _osc._udp. My hunch is that the client is listening for the former and will announces it's IP when it see's it. This is only a hunch though.
      Also, I haven't really had a close look at the MrmrServer code. There could be some clues on how to do a Max implementation of the server there?
      Chris L.
    • Apr 16 2010 | 5:16 pm
      hm, don't see what's wrong with that javascript; I get what you're doing there.
      yeah, I'm trying to do the same thing; upload interfaces to multiple clients.
      I haven't been successful, though, at even the single client connect.
      using the oscbonjour help examples, I can make my iPhone mrmr app see that there's a server available, which is as far as I've gotten. However, using your app, which seems to be put together the same way (passing "register" message to oscbonjour external), it doesn't work.
      though now that I've got yer source, I'll be able to sy something more concrete, once I get in front of my home computer.
      I've never written/compiled a Max/Msp external, in c++ or any other language. Have you? I've got no idea what kind of setup I need to do it; don't think I've ever written any c++. Got any links to good tutorials?
      Your group "In C" performance really got me excited about getting started up with this again. Let's get this working!
      and btw, is this really the latest and greatest tech for communicating btw mrmr and max? oscbonjour seems kind of old to me (last update in 2006?).
    • Apr 16 2010 | 5:23 pm
      To answer my own question, here's what looks like a great tutorial on creating max/msp externals in cpp, for mac or windows:
    • Apr 16 2010 | 5:51 pm
      Don as in "Donny" friend of Koven?
      Thanks for the link. I'm fairly new to coding as well. Lately I've been working in Xcode and getting used to the layout. I'm auditing a class at UCI that is programming w/ the iPhone SDK (Objective C) and I'm barely hanging on. That being said, I'm pretty sure Max externals are written in straight C rather than C++. At any rate, having the code, Xcode, and some tutorials is plenty to start taking it apart and seeing how it works.
      As far as your success with my app... try this:
      1) Delete Mrmr from your phone 2) Redownload it from the App Store 3) Try the app again and let me know what happens
      Some possible reasons it's not working for you:
      1) You've changed the UDP port in the client to something other than 1337 2) You're on a network that is heavily firewalled 3) In the client preferences make sure you've set the Namespace to /mrmr
      Try re-downloading first as that should reinitialized all of the settings like they would be for a random participant.
      Let me know how it goes!
    • Apr 17 2010 | 5:37 pm
      Yep, that's me. Thanks, I'll try that. (reinstalling mrmr), though I've got all those settings as you've described.
      Right now I'm playing with the oscbonjour.cpp source (doesn't cpp mean it's in c++?) from that link you sent me, trying to get it to compile. looks like I need zeroconf, too. wonder where I can find that.
      ah, got yer stuff working. made an interface load on my phone. yay!
      now gotta go celebrate my birthday weekend. yay me!
    • Apr 17 2010 | 5:55 pm
      so what's your hangup in dealing with multiple mrmr clients at this point?
    • Apr 17 2010 | 7:44 pm
      ok, I think I've worked up something that could load multiple phones, automatically when the user hits "play" or "new"
      I'm trying to use poly~, so that multiple phones can be receiving at the same time.
      well, i HAD it working, and now I'm getting "address: bad number" errors when I try to send "address" messages to teh mxj object.
      see attached. Any ideas what I'm doing wrong? autoload_mrmr_network_singleclient is where I'm trying to autoload just one mrmrclient. autoload_mrmr_network attempts to use poly for handling multiple clients
      but I donn't know where these "bad number" messages are coming from...
    • Apr 17 2010 | 8:07 pm
      ok! It seems I've got it working, more or less. see attached.
      open autoload_mrmr_network
      then in your client, connect to the found server, and hit "new" or "play"
      I've been playing with it with two phones, and it works most of the time. when it does fail to load, I generally have to just go back and hit "play" again in the client.
      Those problems seem to happen when multiple phones hit load at exactly the same time.
      So I'd think in a room of people coming in and out of the app, it would be pretty easy to say "if it doesn't work, try again"
      what do you think?
    • Apr 17 2010 | 9:25 pm
      Hey Don,
      I'm not going to have time to look at this in depth this weekend (I'm swamped) but what you've got going is essentially where I'm at right now.
      Yes, the solution is to use poly~ but the current problem is that each device's IP is being sent to ALL the net.tcp.send objects. If you've connected two different devices but when you send the interface only one updates, this is the reason. Of course if you send a "Present" message (via New or Open) with the other device it will update as well right? But not the other. You're essentially only connected to one device at a time.
      What we need is a way to bind each player's IP to a unique ID that references the net.tcp.send object in a specific instance of the poly~ patch.
      OR, on the todo list is to peruse the MrmrServer code to see how it's doing it. A mrmrbonjour object may be the ultimate solution. I'm working on getting my programming up to snuff to be able to do such a thing.
      That being said you're right... .cpp is C++. I guess I wasn't paying attention.
      Happy Birthday!!!
    • Apr 17 2010 | 9:56 pm
      sorry, I guess I don't understand what you're saying. I've got both my phones loading a new interface, and then each is sending info to different instances of the instrument running in max. so it all "works" what i haven't tried, and probably wouldn't work, is sending more information back to specific phones. ie, if I wanted to dynamically set text messages on the clients or something.
      but other than that, it seems to be good.
      give it a try when you get a chance, let me know what's wrong with it.
    • Apr 17 2010 | 11:31 pm
      I just checked it out and it is slick! The automatic upload is very nice. However it's doing exactly what I was talking about. Try opening a new interface simultaneously on multiple devices. OR you can create a button that bangs the interface in all instances of poly~ so that all devices connected should update at close to the same time. In either case you'll see that only one device will receive info. This is because ALL of the net.tcp.send objects are set to the same IP at any one time.
      Every time you choose New or Play in a Mrmr client it resets all of the net.tcp.send objects to that single device's IP address. This setup will work as long as everybody joins one at a time. So the issue is that currently we do not have in place a way to send the IP addresses to a single instance of the ploy~.
      To put it another way, the .js file is generating a target command that is creating duplicate patches but each patch is collecting exactly the same IP information. Does that make sense? ------------ I've attached what you previously posted with a global bang to send the interface to all devices. Check it out and you'll see what I'm talking about.
      Only the last device to log on will receive when you resend via the global bang because it's the only IP that's registered.
    • Apr 17 2010 | 11:33 pm
      Oops. Forgot to include the file.
    • Apr 18 2010 | 3:58 pm
      I think I get what you're saying; that basically that "mxj net.tcp.send" object is "global"; each separate poly patch's version of that object is technically the "same one," internally ?
      for my purposes, since it only takes a few seconds to load an interface, I think this approach can still work practically speaking. After the interface is loaded, my patches are only interested in receiving information. but yeah, I don't have two-way communication.
      will look into this more soon.
    • Apr 19 2010 | 8:56 am
      hi guys,
      The original code for oscbonjour is available from sourceforge here:
      Since then I've refactored it, to be a more general purpose zeroconf toolkit. There is now 3 externals zeroconf.browse, zeroconf.resolve and zeroconf.register. You can browse/register iTunes services, local Ftp, etc... not just _osc._udp. It's also more Max5 friendly with attributes
      sorry only XCode projects will compile at the moment.
    • Apr 20 2010 | 12:06 am
      Wow thanks Remy! I'll definitely check them out asap. If we can register any service than "problem solved" (in theory :-)
      -Chris L.
    • Jun 15 2010 | 8:21 am
      Thank you Remy! You kicked my ass to help figure out how to compile max objects. this is VERY exciting...
    • Oct 22 2010 | 12:04 am
      any change the compiled .mxo files are posted somewhere? hoping to test this out.
    • Nov 12 2010 | 2:47 pm
      Hi tehn, if you go to you'll be able to download a comprehensive zip.
      Thanks for the great work Remy!
      However.. (see next post)
    • Nov 12 2010 | 2:48 pm
      I'm getting a lot of crashes with the zeroconf objects. They all look like this:
      Thread 23 Crashed: 0 libSystem.B.dylib 0x901a2603 DNSServiceRefDeallocate + 241 1 org.osctools.zeroconf.resolve 0x3213c797 ZeroConf::NetServiceThread::~NetServiceThread() + 83 2 org.osctools.zeroconf.resolve 0x3213be11 ZeroConf::NetService::stop() + 59 3 org.osctools.zeroconf.resolve 0x3213c3c6 resolve_reply(_DNSServiceRef_t*, unsigned int, unsigned int, int, char const*, char const*, unsigned short, unsigned short, char const*, void*) + 180 4 libSystem.B.dylib 0x902a880e handle_resolve_response + 401 5 libSystem.B.dylib 0x901a181c DNSServiceProcessResult + 831 6 org.osctools.zeroconf.resolve 0x3213c8ed ZeroConf::NetServiceThread::run() + 295 7 org.osctools.zeroconf.resolve 0x3213c99c ZeroConf::Thread::threadEntryPoint(ZeroConf::Thread*) + 18 8 org.osctools.zeroconf.resolve 0x3213c9bb threadEntryPoint(void*) + 17 9 libSystem.B.dylib 0x9019381d _pthread_start + 345 10 libSystem.B.dylib 0x901936a2 thread_start + 34
      I was wondering whether you have time to look at this
    • Nov 12 2010 | 2:55 pm
      Hm... so when I press 'Upload' the forum automatically posts my message. :P
      Anyway: I was wondering whether you have time to look at this issue. If not, maybe I should try to have a look at your code myself.
      I attached the patch that I am working on ( The crash occurs when I add a new osc device to the system, since I am scripting a bpatcher containing a zeroconf resolver, I assume that's the killer.
      I'm on Mac OS 10.6.4, Max 5.1.6 (43576).
      Best, Mattijs