• community
• software
• contact
• download

• lubyk
• old rubyk
• mimas
• download
• oscit
• liboscit
• dub

software

• Choosing an icon

  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) :

  1. stability (we can rely on lubyk: it works)
  2. organic (“ecosystem”, sharing, alive)
  3. strangeness (arty)

  Logo

  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

  Application icon

  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

  Final choice

  Not decided yet…

  Gaspard Bucher
  2011-09-03 - comments (2)

• Network loop to test latency

  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:

  counter

  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)
  

  loop

  inlet('bang', 'Send next number on [bang].')
  pass = outlet('pass', 'Increasing numbers [float]')
  
  function inlet.bang(i)
    i = i + 1
    pass(i)
  end
  

  results

  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)
  

  network overhead

  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.

  Gaspard Bucher
  2011-06-29 - comments (0)

• Messaging between processes

  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

  plug & play

  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.

  resiliency

  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.

  links in the editor

  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.

  technical details

  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.

  Gaspard Bucher
  2011-06-26 - comments (0)

• Managing code for distributed processes

  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.

  Gaspard Bucher
  2011-04-09 - comments (0)

• Sync between editor and process

  Mimas editor

  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.

  lk.Process sync

  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 .

  

  Patch creation

  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
  

  Gaspard Bucher
  2011-03-31 - comments (0)

• Record/playback data streams

  I have just finished creating a stream recorder/playback engine.

  For several months, I have been investigating various storage solutions ranging from SDIF to Matroska. These are really great tools with lots of optimization to improve seek and storage. These enhancements come at a price: library usage complexity.

  Since I do not have enough time right now to wrap my head around these huge and not easy to use libraries (Matroska is not a library: I am talking about the libraries implementing ebml) I decided to work with what I really know well: SQL databases. In this case, since I want to store the data in files with a single client the choice is evident: SQLite.

  So it took me half an hour to write the tests so I could see clearly what kind of interface I wanted to use, an hour to to integrate Lua bindings (LuaSQLite) and compile everything with sqlite3. Once all this was in place (“sqlite3” is now a module in Lubyk), I could just write my recorder/player in Lua and things went on really easily, especially because I could use “worker:now()” to get the current time and “rk.Timer” to handle timing issues during playback.

  I have adapted the “wii_cube” example to record wiimote movements and it’s very smooth (taking less the 2% CPU with OpenGL and all).

  As a teaser, here’s an example with the db.Stream recorder/playback engine:

  set (create/update)

  streamer = db.Stream() -- in memory db
  
  streamer:set({t=10, x=4, y=8})
  streamer:set({t=10, z=9})
  -- these two lines create a single event at time '10' with
  -- three tracks "x", "y" and "z"
  streamer:at(10) ---> {t=10, x=4, y=8, z=9}
  

  record

  Record is like “set” but it uses the current time from worker to set “t”. You must first call “rec_start()” or the “rec” method is a noop (this is needed so that the “rec” method can be dropped in a signal flow and only record when needed.

  streamer = db.Stream() -- in memory db
  streamer:rec_start()
  
  streamer:rec{x=4, y=8, z=9}
  ...
  streamer:rec{x=5, y=12, z=7}
  ...
  streamer:rec{btn='hop'} -- set strings is ok
  

  read

  Get next timestamp (useful to advance one event at a time):

  -- if t holds the current playback position, calling next will
  return the next timestamp or nil
  next_t = streamer:next(previous_t)
  

  Get event content:

  row = streamer:at(t)
  
  print(row.t, row.x, row.y, row.z, row.btn)
  

  Get track data in range [a, b[:

  track = streamer:track('x')
  
  for row in track:range(a, b) do
    -- draw point in OpenGL for dataset "x"
  end
  

  The last method (range) will be used to plot signal with OpenGL and avoids loading all data in memory through the use of an iterator.

  Gaspard Bucher
  2011-01-27 - comments (0)

• Wiimote fun

  

  Everything is still very much alpha but since I want to create some OpenGL games with my son, I have to move forward !

  I am happy to say that I have integrated the code from darwiinremote to be able to use the wiimote to get some live data and funny buttons.

  The immediate goal is to use the wii.Remote to create simple games. Then (when I have the record/playback engine ready) the wiimote could be used as a cheap wireless captor device to experiment with movement recognition.

  The example below is in the ”.../examples/wii” directory from the sources.

  For the adventurous ones you need to know that:

  1. You will probably need to talk on the mailing list if the example is not in sync with the codebase.
  2. The wii.Browser needs an NSRunLoop to work. If you use a mimas.Application, you are fine but if you don’t, you need to use worker:run().

  

  control openGL with the wii

  what’s up ?

  Before I continue implementing new features, I want to reenable live coding (network access) because the game will probably run on my mini media center with a beamer but no keyboard.

  This means that I have to solve my subscription/discovery/zmq code… Instead of going for a full property based system with access to everything and notifications everywhere (which scares me), I will focus on the in-process connections, gui (blocks with links) and script editing.

  The goal with the remote GUI is to enable remote scripting and encapsulation through an easy to grok visual feedback.

  Gaspard Bucher
  2011-01-25 - comments (0)

• Basic slider sync

  My goal before the end of this year was to have a basic service based slider / processor sync in the new mimas / rubyk.

  

  This very crude example shows a slider that updates as the “Saturn” service runs.

  This first test worked by the means of the magical wand because:

  1. It was using zmq sockets from foreign threads (bad, sadly)
  2. Garbage collection with callbacks would segfault (lua calls during gc)
  3. Both Lua and the GUI want to garbage collect widget elements (really bad).

  zmq

  In order to solve these issues, I have tried to improve my zmq bindings to avoid sharing them between threads. It works better but the pattern is no very nice to use so I started the implementation of raw BSD sockets in order to try some damn simple UDP posting like I was doing in the first prototype (will come back to zmq or tcp when the rest is working).

  GC with callbacks in Lua

  This was very tricky: I want Lua to manage memory but I need to store some a pointer to the callback plus some thread state and I do not want that to go away before the callback is destroyed or the thread using it is killed.

  Thanks to the help from Peter Odding and Robert G. Jakabosky on the Lua mailing list, I could come up with the following solution:

  1. The thread is stored in the userdata’s environment table (so that it lives at least as long as the userdata which is the rk.Socket or rk.Thread).
  2. The function (and self) are stored on the thread’s stack.

  The dependency chain is thus ([] = stack):

  <userdata>---<env table>---<thread[<func>, <userdata>]>

  Check the source for this particular part of the callback..

  Gaspard Bucher
  2010-12-31 - comments (0)