The library consists of many objects and open source libraries carefully selected and adapted to work together in a seamless way. Objects can be directly used in Lua scripts by requiring ‘lubyk’.
Mimas is the graphical interface to work with Lubyk “nodes” (Lua scripts that wrap some functionality) in a graphical way to compose larger projects (eventually across the network). The editor is built with the library.
A couple of days ago, the Raspberry Pi was announced. Needless to say that this hardware is the perfect complement to the software provided by lubyk.
The goal is to create a debian based OS (eventually installed on sd-cards) to ease the adoption on lubyk (and Lua) as a scripting platform for RPi.
Lubyk is a very good environment to program that removes most of the burden related to some difficult programming tasks, mainly:

Apart from its very low price, this hardware has some very good arguments to serve for educational, low-fi gaming and artistic needs:
Here is a list of the required steps to produce a first OS image:
If anyone wants to join into this effort (or has special needs for what should be installed by default on the OS), please drop a line on the mailing-list.
All required modules to run lubyk on linux now compile and I managed to open the editor:
As you can see, there are many bugs:
But at least, the porting of mdns and other OS specific parts are well advanced and having something to see and play with will surely drive motivation !
This is just a short post to show what Lubyk currently looks like.
This shows the important parts of the editor with a remote process showing a window (the green thing), the log window (right below), the patch view where nodes and processes are connected together and the control view on the right.

For those new to Lubyk, the nodes (the things called “w” or “p”) are boxes with inlets and outlets that simply execute a Lua script inside a remote process connected with ZeroMQ. By double clicking on a node, your favorite editor (vim here) opens the remote script (through WebDAV):

Full script of node “w”
Declaring parameters in a Lua script is as easy as this:
defaults {
sat = 0.5,
temp = 35,
}
These two parameters will then appear when changing connections for a control (see image below). Controls can have multiple “connectors” (like a pad does) or just a single one (like the slider shown here).
Once a control is connected to a node’s parameter, changing the value simply updates the value of the given variable in the Lua script, eventually triggering hooks like “param.changed”.

Connecting node parameters and controls.
Since the scripts run remotely, we cannot read the console for debug information, errors and printed values. We thus use a log window as shown bellow that gets all “print” “warn” and error notifications from remote processes:

Informations, warnings and errors in the log window.
Clicking on a line in the log window will open the culprit at the concerned line in the text editor.
To ease deployment and installation on mac os X, we have decided to create a single object (an application) which you can simply drag or give to friends. The application will install a few files to work from the command line but all the examples/documentation/libraries will be in the resource folder.
To build this application, we need an icon. Nicolas Joos has been working on an icon some time now and after settling for the four rounded shape, we have to build an “Application” icon.
Before diving into the sketches and propositions, here is what I think this icon should convey (most important first) :
Here were some of the propositions for the icon:

first ideas

developments over the ‘animal’ idea
We settled for the four circle shape (cells, ecosystem, proximity, etc):

logo and font choice
Now that we have the logo, it is time to build the actual “app” icon: something that has to live in a dock, a filesystem, etc. We want an icon that stands out a little by it’s strangeness, something appealing but not too candy.
Here are the last contenders for the application icon in different contexts:

in a large filesystem icon view

small version when listed in the Finder

in the dock

in the application tab
Not decided yet…
Now that I can create and remove links between processes, I thought of a little experiment:
What happens if I create a loop ?

Here’s the content of both scripts:
inlet('bang', 'Send next number on [bang].') pass = outlet('pass', 'Increasing numbers [float]') function inlet.bang(i) i = i + 1 print(i) pass(i) end -- initiates the loop on script save pass(0)
inlet('bang', 'Send next number on [bang].') pass = outlet('pass', 'Increasing numbers [float]') function inlet.bang(i) i = i + 1 pass(i) end
I stated the script and I let it run for 30s. The counter reached 241’558 in these 30 seconds which means 8’050 messages per second.
The monitor (open during the test) shows 2.4Mb/s of data being transferred.
The same loop in a single process gives this result 1’298’724 (43’290 messages per second). Note that I had to change the “counter” so that it uses “app:post” to send in order to avoid a stack overflow error (in-process messaging is the same as a function call):

Updated “counter” inlet function:
function inlet.bang(i) i = i + 1 print(i) app:post(function() -- post to avoid stack overflow count(i) end) end count(0)
A local loop takes 23μ s with the post overhead. It takes 124μ s when going through the network. This is roughly 0.1 ms latency overhead. This is not too bad.
Another thing to take into account is that sending is a blind process unless feedback is setup. This means that the receiver should work faster or the incoming mailbox will grow. We could overcome this issue by providing other types of links if needed.
An important milestone has been reached today: messaging between processes works and displays in Mimas as in the example below:

‘a’ and ‘b’ are different processes, possibly on different boxes
The connection between process “a” and “b” does not depend on the order in which the processes are started and does not require complicated IP configuration. The link is simply defined in the source (sender) with a fully qualified url. For example, this is the yaml definition for the counter in process “a” :
counter: x: 30 y: 45 hue: 0 links: count: /b/play/in/trigger: true params: tempo: 580
The links are defined as a dictionary so that link removal can be managed by setting the url to false.
If “a” or “b” goes offline, the link goes into “disconnected” state. When the missing process comes back, the link automatically reconnects and the messages are transmitted on the line.
As highlighted in the image above, links properly display in the editor, even if we cannot create them there yet and there are some display bugs.
The receiver has a single zmq “PULL” socket announced by ZeroConf and the sender pushes the data through this socket along with the target url. When an object is taken offline, ZeroConf informs the other party and the sender stops sending.
We are working on a storage system for patch information that makes it easy to work with versioning tools such as git/mercurial/bazaar and such.
Here is an overview of a project’s file organization (on local filesystem or remote on Mnémosyne server):
... <== base project directory. This is the current dir for the process .../A <== Everything for process with role "A" .../A/_patch.yml <== Patch for process with role "A" .../B <== Everything for process with role "B" .../B/_patch.yml <== Patch for process with role "B" .../B/foo.lua or ...[node:url()].lua <== Code for node 'foo' in process 'B' .../lib <== searched for required code
The idea with this structure is that all the information for the different processes (potentially on different machines) is stored in a single folder. With the “Mnémosyne” server, the process will simply query the server with the required node url (which contains the process name) and the server will serve the code (by reading the filesystem).
The “Mnémosyne” server will save every code changes by registering for notifications and using git on the project’s folder.
This is the first tangible result concerning the graphical interface after the switch to Lua and Qt. The development in the new environment is a joy and things advance at a fast pace.
In this new context, writing tests by mocking parts of the system is really easy with Lua and greatly simplifies test driven development (especially for graphical elements). Difficult conceptual issues such as the relation between model and views remain but testing/fixing is just “command+R” away.
We have managed to make sync between lk.Process
and editor.Process
work. This implies many tools working together such as mdns (Zeroconf network discovery), zmq (zmq networking library), msgpack (binary serialization), mimas (Qt bindings), yaml (text serialization) and editor (Mimas application objects).
In the example below, the process has been automatically discovered on the network, patch information fetched and the process is drawn in the editor.ProcessView
.

Another big advance highlighted by this example is that patch definition works (with automatic loading of required lua code). Here is the “simple.yml” file with external “add” and “store” classes. We could have serialized these in the patch by using “script” instead of “class”.
add: class: add hue: 0.9 x: 70 y: 95 links: sum: store/in/value params: val1: 0 val2: 5 store: class: store hue: 0.2 bug: 0.7 x: 90 y: 155
The “add.lua” file contains this:
inlet('val1', 'First value [number].') inlet('val2', 'Second value [number].') sum = outlet('sum', 'Sends sum of first and second values [number].') val1 = val1 or 0 val2 = val2 or 0 function inlet.val1(v) val1 = v sum(val1 + val2) end function inlet.val2(v) val2 = v sum(val1 + val2) end
The “store.lua” file is like this:
inlet('value', 'Stores the value') function inlet.value(v) value = v end
Loading latest twitter data...
Funding from the Swiss Federal Office of Culture to write the graphical frontend to rubyk !
Moving from a global mutex to a global select/poll loop.