You can now add widgets by dragging paths from the browser.

When you drag a path (“tempo” here) on a device view, the widget steals the color and shape of the closest widget (the new dragged element is the lime full rectangle) and snaps to to ease alignment.

The source code for mimas, liboscit API and rubyk are now separated in their own git repositories with their own bug tracker.

This will make it easier to track releases, bug fixes and the like. The repositories now live at the following urls:

• liboscit: github.com/rubyk/oscit
• rubyk: github.com/rubyk/rubyk
• mimas: github.com/rubyk/mimas

You can look at the project pages for the bug trackers.

PS: as you may have noticed, there is now a twitter feed for rubyk: @rubyk_.

The development of mimas is advancing quite well and proving that the oscit library is actually built on a strong usability ground.

The interface now handles asynchronous updates: when you enter “edit” mode and move a widget to some other location, a couple of interesting things happen:

1. you move a “ghost”, not the real widget
2. when the “ghost” is dropped, an interface update message is sent (with the minimal information needed) to the server
3. the server notifies all interfaces (including the one you are working on)
4. you see the widget move

You can see an example of a ghost being moved in the example below.

As you can see on the screenshot below, “minimas” (oscit controller for iPhone) now also has little sliders magically appearing when an oscit enabled device is connected to the network.

And yes, this works on my iPhone through wifi and it’s super cool !

Now I just have to implement the same ”.views” parser as in Mimas (view is provided by the remote application as xml).

Ok, these screenshots of mimas are not very impressive but they are a proof of concept.

two interfaces, one value

Let me get into the details: the two windows are two instances of mimas, each of which has a zeroconf browser opened listening for “oscit” devices on the network. Each application has found the same two devices “beatbox” and “receive”. Through automated url discovery using oscit protocol, the browsers have discovered that there is a "beatbox"/tempo url that can be represented with a slider (range). The slider’s minimum and maximum values represent the advertised type of “tempo” and moving the value of one slider updates the other one (since both are registered as observers).

This is just the beginning, but it works damn well for a first shot and its the basis upon which all the rest will be built.

Once the patterns of what does what are clear, the rest is much easier…

Let’s code this into iOscit (iPhone app) !

Here is an interesting introduction to the problems and math involved in machine learning.

watch video

Managing locations is not an easy task. Now I realize that I need the ’/.reply’ receiver to know from which “remote place” the answer comes from so that it can update the corresponding RootProxy.

what we have

Actually, the only reference to a remote location used in oscit is the IpEndpointName from oscpack. This is fine as long as:

1. you only talk one language (osc)
2. you want your users to set IP addresses or hostnames and ports by hand

In rubyk, an Url can be used to reach any kind of connected device, not only network (and osc) based targets. This means that point (1) is not satisfied. The other problem is that most users don’t have any dns setup running on their local network and thus can’t use hostnames. They will end up having to find each and every IP address and write in stone in their patch. Bad, bad, bad. Point (2): no good.

what we want

I’d like to write urls like this in a patch:

oscit://example.com:5424/foo/bar  <--- far remote, using dns
example.com:5424/foo/bar          <--- defaults to oscit protocol
foo/bar                           <--- relative url
oscit://"stage camera"/contrast   <--- find host/port by service name, nice !
"stage camera"/contrast           <--- same as above
http://"web server"/status        <--- using http, resolving with zeroconf

The rules to parse such urls become quite obvious:

1. Protocol can be omitted or must be separated from host by ://
2. If host is enclosed in quotes ("..."), it’s a service name to be resolved by zeroconf
3. If the host part is not enclosed in quotes, it’s a fully qualified domain name and it must provide port numbers, except when using well known ports (http, ftp, etc).
4. And sometimes we receive a message from an IP with a port number and we just need to reply so we use SOME.IP.ADDR.ESS:port but we should not store this value in a patch.

design

From all the ideas shown above we see that an Url class should provide the following elements:

• protocol
• hostname or service name
• ip & port (can be empty until resolved)
• path

In C++, this gives:

class Url
{
...
private:
  Location location_;
  std::string path_;
};

class Location
{
...
private:
  std::string protocol_;

  // hostname or service name
  std::string name_;

  // true if using hostname instead of service type
  bool reference_by_hostname_;

  unsigned long ip_;
  uint port_;
};

location

The ‘location’ part of the Url contains the target location (when the url is going out) or the source location (when the url is coming in).

Storing locations on every url can be a waste if we need to do so very often so it could be better to just keep a pointer to a list of “known hosts” instead. This is left as an exercise ;-).

To start building the GUI for rubyk, I decided to first implement an iPhone remote because:

1. I know objective C and iPhone development is very well documented (not like juce).
2. It will raise all the problems of a remote gui without involving the full complexity of a desktop application
3. It’s network based and fun

add device

The first problem I fell upon was how to build the proxy tree and manage the asynchronous calls (update and change value). It took me some time but I finally wrapped my head around the idea of a ProxyFactory that you sub-class in your specific gui environment, providing the necessary hooks to build the gui widgets.

sync

Here is the list of commands (part of oscit protocol) that are used to build the proxy tree.

change value

And finally, this is what happens when values are changed:

coding time

I started writing the tests for this setup. The code will be part of the liboscit library.