Apr 16, 2010 at 2:17am
trying to find the source, but the svn site is gone.
i’m wondering if this is the latest news in using bonjour in Max/Msp?
Any help or advise would be great. Thanks!
Apr 16, 2010 at 5:21am
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 at 12:06pm
looks great clavendar, I’ll start looking into this right away!
looking at the source from teh svn above, I see the constant defined:
const char *type = “_osc._udp”;
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 at 12:16pm
hey clavender (oh, hey you!)
though that line looks fine to me; I can’t really see the source.
Apr 16, 2010 at 4:37pm
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?
Apr 16, 2010 at 5:16pm
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.
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++.
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 at 5:23pm
To answer my own question,
Apr 16, 2010 at 5:51pm
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
Some possible reasons it’s not working for you:
1) You’ve changed the UDP port in the client to something other than 1337
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 at 5:37pm
Yep, that’s me.
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.
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 at 5:55pm
so what’s your hangup in dealing with multiple mrmr clients at this point?
Apr 17, 2010 at 7:44pm
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.
but I donn’t know where these “bad number” messages are coming from…
Apr 17, 2010 at 8:07pm
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.
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 at 9:25pm
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.
Apr 17, 2010 at 9:56pm
sorry, I guess I don’t understand what you’re saying.
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 at 11:31pm
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?
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 at 11:33pm
Oops. Forgot to include the file.
Apr 18, 2010 at 3:58pm
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 at 8:56am
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
the code is available there:
sorry only XCode projects will compile at the moment.
Apr 20, 2010 at 12:06am
Wow thanks Remy! I’ll definitely check them out asap. If we can register any service than “problem solved” (in theory :-)
Jun 15, 2010 at 8:21am
Thank you Remy! You kicked my ass to help figure out how to compile max objects. this is VERY exciting…
Oct 22, 2010 at 12:04am
any change the compiled .mxo files are posted somewhere? hoping to test this out.
Nov 12, 2010 at 2:47pm
Hi tehn, if you go to http://sourceforge.net/projects/osctools/ you’ll be able to download a comprehensive zip.
Thanks for the great work Remy!
However.. (see next post)
Nov 12, 2010 at 2:48pm
I’m getting a lot of crashes with the zeroconf objects. They all look like this:
Thread 23 Crashed:
I was wondering whether you have time to look at this
Nov 12, 2010 at 2:55pm
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 (devicelist.zip). 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).
You must be logged in to reply to this topic.