Monome AutoConfig Protocol - FAQ
What is AutoConfig protocol?
It is a simple way for monome applications to find monome routers and negotiate how they will connect. It greatly simplifies configuration for the user especially when more than one application is involved.
Here is a diagram:
What is oscbonjour?
oscbonjour is a specific implementation of Bonjour designed for OSC (Open Sound Control) devices like the monome. Bonjour is a cross-platform standard available on all major platforms:
Apple - “Bonjour, also known as zero-configuration networking, enables automatic discovery of computers, devices, and services on IP networks. Bonjour uses industry standard IP protocols to allow devices to automatically discover each other without the need to enter IP addresses or configure DNS servers.”
Does AutoConfig protocol need oscbonjour?
No it doesn't. Bonjour is a nice but optional feature that allows discovery of a monome routers (or monome emulator's router's) listening address and port on a network. If Bonjour is not available, the default listening address for an autoconfig enabled router is localhost:8080. The address to start autoconfig can always be manually configured without needing oscbonjour. This still has value as private channels between applications can still be negotiated.
So what does AutoConfig do then?
Autoconfig (Especially combined with oscbonjour) allows a user to easily discover available routers and negotiate a private communication channel with them. Connecting multiple monome applications to a single or multiple monomes has always been a challenge even for seasoned users because communication from application to monome needs to be private between the application and the monome. AutoConfig automatically negotiates this private communication channel.
Does AutoConfig require Max For Live?
No it doesn't. AutoConfig is language agnostic. It works just as well and can work simultaneously with Max For Live apps as well as external MAX apps, C apps, Java apps, Python apps, etc…
Does AutoConfig mean I can't just manually configure my settings?
No. You can always set your settings manually just as you always did and you can choose to use a direct connection to monomeserial or other as normal. AutoConfig is just a way to suggest what those settings should be. Especially useful when using multiple applications. Even if you are an expert, figuring out unique settings for a handful of applications is a chore. Let AutoConfig do it for you.
How hard is it for an application to be AutoConfig enabled?
There are reference implementations for Max For Live and also standalone MAX apps. Generally this is quite simple, involving either simply cutting and pasting the code module or connecting messages that send the prefix, host, ports to the part of the app that needs this information. The protocol itself is documented and there are implementations of oscbonjour and bonjour or zeroconf for most programming languages.
The oscbonjour external for MAX and Max For Live is here:
What about emulators for Launchpad and APC-40?
So far the monomeEMU router has implemented AutoConfig for the launchpad and MonoRoute router for the Monome with more routers and apps on the way shortly. The nice thing here is that the protocol is inclusive not only to all apps and languages but also all devices, so emulators can also connect as easily. This not only grows the community but reduces the level of techical support required when new users are connecting.
What does it look like in an application?
How do AutoConfig and AutoFocus (Introduced by Stretta) relate to each other?
They are both related in the fact that they share the goal of simplifying the use of multiple monome applications for the user.
AutoFocus is a very nice feature and lots of users love it for good reason. AutoFocus however requires very specific system requirements that limit it's scope to applications written in Max For Live and also connecting via shared ports in Max For Live. This means that Max For Live apps must be written in MAX to use autofocus. Applications in Live that are not 100% MAX such as SevenUpLive and Molar cannot use autofocus because their communication layers are written in Java and C.
AutoConfig instead is related to setting up private communication channels with the router so that all apps can always communicate with the router without being interrupted by other apps. This includes apps written in different languages and running across different environments like M4L, MAX, standalone, etc. This will also allow for advanced routers in the future that can maintain perfect state between all apps (rather than just switching the communication stream in midstream). AutoConfig attempts to be all inclusive where all applications can participate not matter where they run and in what language they are written in.
Ok but how do AutoConfig and AutoFocus get along together? Do I have to pick one?
Right now they are not compatible because of the different fundimental approaches to solving the problem and you must choose which to use based on the capabilities of your apps. There are however drop in primitives for apps that allow you to choose one or the other (see myralfur's drop in for M4L linked above). This is where you as a user come in…applications will embed the parts of each that make sense to the user. Tell application developers what you want. We can all bring this together into a situation that is not either/or but the best of both together. It's still early and it depends on router and app developers to implement and work together to make it all work seamlessly.
Why do I have to run two routers to use AutoConfig, for example:
Monomeserial and MonoRoute? This is not an artifact of AutoConfig but instead because Monomeserial does not support AutoConfig and it doesn't necessarily make sense to have multiple routers rewrite what monomeserial does well already. The ideal solution involves creating a new version of monomeserial that runs as a background service on your machine, always willing to serve connections to your monome/s but essentially invisible. This would allow regular connection of legacy applications with no router needing to be launched at all. It would allow for more advanced routers that offered specific capabilities beyond AutoConfig to be launched which would rely on this new core service but could offer nice additional capabilities while still being built on a rock solid and performant core communication layer. Choice is valuable in routers as well as applications.