Upcoming New Version

(18 posts) (5 voices)

Started 1 year ago by admin
Latest reply from nico

Tags:

admin
Key Master

I've alluded to doing a large rewrite of Control in a few postings over the past couple of weeks. As I'm getting closer I'm curious how people think I should handle the update; the problem is it will break most existing user interfaces. Here's some concerns for me"

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

Posted 1 year ago #
admin
Key Master

Also, I'm thinking about taking it one step further... instead of being able to do:

"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?

Posted 1 year ago #

And changing the interface format to something that looks like this:

{
	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.

Posted 1 year ago #

admin
Key Master

Hmmm... stumbling on JSON not allowing functions as data members. If anyone has ideas for workarounds let me know.

Posted 1 year ago #

admin
Key Master

OK, after messing around it looks like using a standard JSON parser isn't going be flexible enough for what I'd like to do. So, I'm sticking with the oft-maligned eval() command for parsing interfaces. I think they'll look like this:

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 : [],
}

Posted 1 year ago #

admin
Key Master

I should point out that use of control.functions will be optional, although encouraged. Go ahead and use globals if you'd like :)

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

Posted 1 year ago #
nico
Member

Charlie,
glad to read that work is in progress!!
i can't help about internal mechanics... sorry, about the name an alternative could be OSControl....
anyway if you want to keep Control name and that break existing layout, for me it doesn't really matter as i'll update D::Light layout to fit to new model.
about loading interface, do you think you can add a button to load .js file that exists on the phone?
best regards, and don't forget to publish an android version ;-)

++

Posted 1 year ago #
admin
Key Master

:) Almost all of the work has been in the JavaScript portion, so it applies to both versions.

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

Posted 1 year ago #
nico
Member

maybe you can publish a beta release we can try...
++

Posted 1 year ago #
bilderbuchi
Member

Can't advise on the technical JSON stuff, sadly.
Regarding breaking features. I would keep the name at all costs! You're correct that you shouldn't lose name and brand recognition. For features breaking existing stuff: That's what major version numbers are for! I'd say bump it to 2.0 and document the breaking changes in the changelog/what's new section.
While you're at it, maybe refresh the logo? I always think about revolution and che guevera when I see it. :-P I could maybe help a bit with this if needed.

Posted 1 year ago #
metaphysician
Member

i agree with bilderbuchi - i think that if building a better (read: faster, more stable, and consistent) mousetrap means that you break existing ones, so be it. if it's possible to alter a few things in the old style interfaces (like terminology and such) to update them to new interfaces, it might be helpful to state that. since the code of the setup is easily edited it shouldn't be tremendously hard to do a search and replace.

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

Posted 1 year ago #
nico
Member

Charlie,
can you please don't forget to add to new version error/success message when loading interface...

++
Nico

Posted 1 year ago #
admin
Key Master

Sure. I was thinking about this the other day... I don't know how much detail I can give about the error but I'll try to at least get it to say either:

"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

Posted 1 year ago #
nico
Member

both would be great...
++

Posted 1 year ago #
admin
Key Master

Yeah, sorry if this wasn't clear but I meant it will give one of those two messages depending on the what the problem is.

Posted 1 year ago #
jetsabel
Member

Wonderful news!
I hah not touched Control/my OSC-based project based for a few months after completing Uni, but now I have time to put some more work into it. To come back to news of a rewrite is exciting! :)

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?

Posted 1 year ago #
admin
Key Master

The ip address will definitely be included in the next Android address and the MultiTouchXY is -much- improved... in addition to outputting the correct values the graphics infinitely smoother now, even when moving 11 balls at once.

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

Posted 1 year ago #
nico
Member

Charlie,
I hope you'll find time to download && test Control on your Andro-Phone running Ice Cream SandOuiche ;-)

Best regards,
++

Posted 1 year ago #

RSS feed for this topic