Best regards,
++

The new version features a lot of dynamic interface improvements... here's a video with Max (there are similar implementations for SuperCollider and LuaAV):

http://charlie-roberts.com/misc/control_max.mov

In terms of downloading larger interfaces, I think the best way to do it is to send the following command via OSC:

/control/runScript "control.interfaceManager.downloadInterface('http://yourwebsite.com/yourInterface.js');"

You know, as a temporary fix... I assume you're using the Zeroconf object to find instances of Control in Max? If so, you already know the IP address so you could send it to the Android device and assign it... again, using /control/runScript/.

Hope this info is helpful... - Charlie

Re the name, I think changing to a more unique name may be beneficial, and a rewrite would be a good opportunity to do so. I always had to get people to search App store/Market for "Control OSC", as just plain "Control" gets too many different results.
I tend to think would be reasonable to call it Control2, OSControl, ControlOSC, whatever as long as all the places people can get the original Control have the link to the newer version prominently displayed.

A related idea might be to have the rewrite check interface files and be capable of returning an error saying "This interface was written for an older version of Control" - only if that's trivial to implement.

With the actual software, there are a few old bugs that I hope may sort themselves out in the rewrite:
Discrepancy between Android & iOS behavior - http://charlie-roberts.com/Control/forum/topic.php?id=300
Strange MultitouchXY output - http://charlie-roberts.com/Control/forum/topic.php?id=357

Another thing that I am very interested in (and may already be possible??) is having people download Control from the Market/App store, join a dedicated WiFi network and have Control automatically load my interface without users manually having to enter the URL.

I am about to explore this with MaxMSP sending out messages to the broadcast IP:Port 8080 but I have a vague recollection that while we can create new interfaces and simple widgets with this method, it is far more difficult/impossible to have control load/create a more complex interface with numerous functions and variables (would be a version of this interface, http://bit.ly/multiosc)

Has anyone had success broadcasting complex interfaces?

"Network error - the file could not be downloaded from the provided address"

- or -

"Parse error - the file contains errors and could not be run"

- Charlie

++
Nico

looking forward - thanks for all your hard work - it's vastly appreciated!

I don't know much about the file system on Android and if it's easy to get permission to load files like that. It's certainly -not- easy in iOS...

I already have the new interface format working correctly; I think it's a big improvement. Very excited to be finally taking time to polish things and fix a bunch of bugs. - Charlie

++

There will also be a recommended control.data to hold any extra variables you might need. Again, optional but recommended.

If you use control.functions and control.data at some point hopefully you will be able to do basic edits to your interface on the device itself. - Charlie

control.functions = {
	sliderTouch : function() {
		console.log("slider value = " + this.value);
	}
}

control.interface = {
	name : "test",
	orientation : "portrait",

	pages : [[
	{
		name: "slider1",
		type: "Slider",
		bounds: [0,0,.5,.5],
		ontouchstart: function() { control.oscManager.sendOSC("/test", "i", 1) },
	},
	{
		name: "slider2",
		type: "Slider",
		bounds: [.5,.5,.5,.5],
		ontouchstart: control.functions.sliderTouch,
	},
	]],

	constants : [],
}

{
	name : "test",
	orientation : "portrait",

	sliderTouch : function() {
		console.log("slider value = " + this.value);
	},

	pages : [[
	{
		"name": "slider1",
		"type": "Slider",
		"bounds": [0,0,.5,.5],
		"ontouchstart": function() { control.oscManager.sendOSC("/test", "i", 1),
	},
	{
		"name": "slider2",
		"type": "Slider",
		"bounds": [.5,.5,.5,.5],
		"ontouchstart": control.interface.sliderTouch,
	},
	]],

	constants : []
}

This JSON object would be decoded in control.interface. Using this format means will mean that dynamically generated interfaces could be saved onto the device. Or, eventually, that interfaces could be constructed on the device itself. And it will save me a bunch of headaches that aren't worth going into here. And it looks cleaner.

"ontouchend" : function() { mySlider.value = 2;}

you'd have to do:

"ontouchend" : function() { control.mySlider.value = 2; }

even better would be:

"ontouchend" : function() { control.widgets.mySlider.value = 2;} "

But that's really starting to be kind of verbose... any thoughts?

1. No more global objects. Everything is stored inside of control. For example, if you name a slider slider1 to refer to it in your code you will now have to use control.slider1. oscManager will be control.oscManager. I think this will make it more stable to add external javascript libraries (like Box2D etc) so there's not "namespace" collisions.

2. I've changed the storage model for interfaces in iOS to be the same as Android. This should get rid of problems with interfaces and destinations not appearing correctly. But it will require all (non-stock) interfaces to be reloaded.

I don't want people to download the new version and then suddenly have all their custom interfaces stop working. Should I publish the app with a new name? Control2? CNTRL? These would also be easier to search for in the app store potentially...

There's obviously going to be some new features in there as well. My favorite is that event handlers will no longer be strings, so :

"ontouchend" : "mySlider.value = 2;"

is replaced by:

"ontouchend" : function() { mySlider.value = 2; }

Or you can directly call a function that has been previously defined. This will be much more efficient than the previous method. There is also a new AutoGUI feature for creating interfaces via OSC that is pretty neat and allows really fast integration with apps like Max/MSP and SuperCollider.

Anyways, curious what people think about releasing a separate app vs. updating the existing one. I'm not excited about losing all the "press" associated with the current version of Control if I change the name...

- Charlie