January 7th, 2011

Interface files posted

I’ve posted some of the interface JSON files that come included with Control; they’re a good resource to get an idea how to create interfaces or to modify for your own purposes. They’re located at http://www.charlie-roberts.com/Control/interfaces. As time goes by I’ll be adding more interfaces to this destination for people to download, accordingly, I’ve created the following link shortener to make it easier to type on mobile devices: http://goo.gl/5K4W7. At least, I think that’s easier…
I guess the shortener doesn’t work if you add the interface filenames to it… use the full address.

At some point maybe I can figure out a way to browse folder directories from within Control…

January 5th, 2011

App Store Submission

After a lot of bug fixing, interface building, documentation and screenshot taking I submitted Control to the App Store today. I wasn’t able to cram everything into the first release that I wanted to, but a lot of it made it in there.

Here’s a couple of screenshots from the App Store submission:

Screenshot of the Game of Life interface

December 27th, 2010

Some thoughts on Canvas rendering

When I first began creating Control, interfaces were defined as HTML Canvas objects that filled the entire screen. Each widget had its own draw method (this is still true) that drew straight into the canvas. Although this made the most sense from an organizational view in practice the rendering was very slow.

It took a while for me to realize the Canvas object was the bottleneck in rendering; I assumed that Canvas performance was hardware optimized for the gpu on iOS devices and that the problem was related to getting the widget values in the Objective-C runtime so that they could be sent out over OSC. Eventually I found some blog posts that described the performance issues with using large Canvas objects and realized the Canvas approach would not work for my needs.

The way it works now is that every widget has its own div tag. The div tags are manipulated via JavaScript and CSS. This seems to be hardware accelerated and yields usable latency. The only exception to this is the knob widget; there really was no practical way to draw a knob using divs alone (-webkit-border-radius gives a huge performance decrease) so Canvas is still used. In general it seems like the performance of canvas isn’t that bad as long as the canvas object is small. Thus, drawing multiple small canvas objects is much more efficient than redrawing the entire interface whenever a widget value should change.

In the future I’ll be doing some tests to see if it makes sense to have other widgets (like sliders) draw via canvas instead of using div tags. It would definitely provide more flexibility in terms of the toes of widgets that could be drawn. WebGL will also be a great option once it’s available on mobile devices.

December 26th, 2010

Control blog is up!

For this first post I’m attaching a screenshot of a DJ interface that will come with the software. There’s not too much special about it, but I’ll note that the scripting capabilities of Control allow for the crossfader position to be controlled by the left, right and center buttons. This behavior is all setup in the interface file via JavaScript. Even a behavior relatively simple like this would be impossible to program in an interface without adding code to the app itself in other iOS interface programs.

Here is the code for the left button that sets the crossfader value to zero, as found in the JSON interface file:

"ontouchstart": "crossfader.value = 0; crossfader.draw();"

Normally when setting the value of a widget you would use the setValue(x) method; setValue changes the value of the widget, outputs the new value via OSC or MIDI and then redraws the widget. However, in this case, the button already sends out a value and we want to avoid sending a repeat.

This work is licensed under GPL - 2009 | Powered by Wordpress using a heavily modified version of the theme aav1