idea

The idea is to have a separate application for the interface which connects to the rubyk instances through TCP/IP. In the example below, there are three applications (possibly on different computers): an interface and two rubyk instances.

rubyk interface

problems

There are still a number of difficulties to solve:

  • how to avoid sending too much (useless) data through the network ?
  • how to connect a controller (joystick, slider) to a parameter or interface component (“learn” function) ?

data transfer

The first problem could be solved by having the interface “pull” data by sending a query instead of “pushing” everything from the instances. The interface could only query for value changes. Here is an example of a session:

INTERFACE: give me the changes for nodes 334, 345 since 38473998 (timestamp).
INSTANCE : 38473998 -> 384740002: [334: nothing changed], [345: counter:5]
...
INTERFACE: give me the changes for nodes 334, 345 since 384740002.
INSTANCE : 384740002 -> 384741523: [334: nothing changed], [345: counter:15]

The nodes could easily store the last_changed timestamp value and would return “nothing changed” if their last_changed value is smaller then the value since_timestamp.

learn

In order to solve the “learn” problem, we have to decide where the connection goes: to the instance ? to the interface ? An idea would be to have an internal representation of any hardware controller. These internal representations would store a mapping of events (midi events, data changes) and meta events to send to specific nodes (change pitch, etc). The mapping could be done in Lua for greater flexibility.

controller

tools for the job

The interface will be programmed using the excellent Juce C++ framework. The protocol between rubyk instances and interfaces will be implemented using the Ragel state machine compiler.

I found a juce tutorial to start learning Juce.