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:
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)
source line: var a = arguments.split(":"); //"a" is the arguments split between the ":" sign.
though that line looks fine to me; I can't really see the source.
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?
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?).
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.
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!
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.
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...
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.
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.
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.
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.
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
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.