We have just finished cleaning up the code for Mutex and Threads in oscit and now we have to decide what kind of locking policy we want to implement.

Do we want:

1. Global locking of a processing tree ? (could be managed by Root class)
2. Object locking ? (must be implemented by hand for each object class)

The current (buggy) implementation of oscit library uses the first paradigm, but it’s bad because we forbid parallelisme all together by locking too much. Moreover, most objects can perfectly handle concurrent requests. For example, an object that is bound to some hardware sensor could return the current temperature to many callers at the same time without problem.

If we lock less, we have to lock better and analyse where concurrency could blow up. Here is a short list of such places:

• Find object, [object destroyed] trigger method (boom).
• Start parsing script [method call: boom].
• Start computing new PCA model [matrix input: boom].
• Start command call [kill command]: some object could be left in an undefined state.

From these examples, we see that it shouldn’t be too difficult to write proper locking inside the objects themselves.

After some hard work to port the build process to CMake and fix the necessary changes, rubyk and oscit now work on linux !

In order to do some testing with touchosc (an osc controller for the iPhone), I realized that we need some kind of transcoder in rubyk since touchosc does not let you define the mappings and this might be the case with many simple hardware devices. The transcoder would be a special type of command with the following properties:

1. input port
2. output port (for replies)
3. mappings

The mappings could be written in a script with a syntax like this:

/1/fader3  [0..1] --> /m/tempo [60..240]
/1/toggle1 [0, 1] --> /m/start_stop [0, 1]

To send replies, we would use the same mappings. If we receive more complicated data types then real numbers we just send the values through to the url (checking types) and we use a lua object to filter, route, etc.

Let’s code !

oscit library is reaching maturity and we can now start working on mimas.

This is a screenshot of the first communication test between mimas and rubyk. For the sake of rubyk’s biography, let’s keep the commit id of this important step in rubyk’s history: b34beac.

What these two applications do together right now is quite trivial: mimas simply shows a message about newly connected oscit devices on the local network. That’s just the beginning of lots of coding fun !

I can’t wait to create objects and links… (but I have to learn a little more about juce right now).

Lines starting with > are commands, the other lines are messages from rubyk.

# Welcome to rubyk !
#
> v => p
# /v ? /p
> v = Value(4)
# <Value:/v value:4>
> p = Print(prefix:'yoba')
# <Print:/p prefix:"yoba">
# /v/out/value => /p/in/print
> v/value(7)
yoba: 7
# 7
> v/value
yoba: 7
# 7
> v || p
# /v/out/value || /p/in/print
> v/value
# 7
> q
#
# Bye...

What this does is:

1. try to create a link between url ”/v” and ”/p” using relative url syntax
2. create a Value node at url ”/v”
3. create a Print node at url ”/p”. This operation creates the pending link v => p.
4. set “value” of “v” to 7
5. get “value” of node “v”
6. unlink “v” and “p”
7. get “value” method again
8. quit

Dealing with our own mail server was too much work…

The mailing list now lives with google groups: rubyk mailing list.

We are currently busy defining the basic protocol a planet should implement in order to be easy to configure and use through an ethernet network.

The protocol’s goal is to ease the automatic discovery of new planets on the network (zeroconf) and to have a set of minimal common naming conventions so that we can discover the content of unknown planets.

For the glory details: oscit.

When the transition to “osc-everything” will be over and we have a basic GUI, we will jump deep into computer vision because I need it for my next show called “emergence”.

This is what prevents me from sleeping enough. I am really excited about what we will be able to achieve with rubyk + lua + opencv or libcvd.

See you in a few months…

Putting an object (hardware, software) on the network should be done properly these days.

Zero Configuration Networking

Bought a new book to make sure no one ever needs to configure the network of a rubyk enabled software.

The book seems to be very well written. Its a joy to read, both for the text and for the great features that this will bring to rubyk… Keep in touch.