choosing a data model

After having done some tests with ruby wrappers around midi, bluetooth serial communication and some movement recognition algorithms, it is time to start putting all this together in Rubyk (ruby controller). I am not a big fan of the “lines and boxes” way of writing multimedia programs: it does not scale well. For this reason, I decided to write my own tool called Rubyk.

description

• client-server architecture : the server runs ruby and listens for client connections through TCP/IP. The clients send ruby code to be evaluated inside the server.
• open source.
• easy to write custom objects in C/C++ by wrapping these with ruby
• use standard, fast, cross-platform libraries where possible and wrap these into ruby, creating a large library base.
• use a standard naming scheme for all functions and libraries. This means that we do not use the internal names of the libraries we use so the ruby code and final code in rubyk does not depend on the underlying C implementations.

data model

Single most important thing: “How are the messages between objects implemented ?”.

goals

• share memory for large structures (pass pointers when needed).
• pass direct values when needed.

implementation prototype

struct RKMessage {
 long len;     // can be used as a direct value (integer)
 double value; // direct value (floating point)
 int  ctype;   // type of data RK_DIRECT_LONG, RK_DIRECT_DOUBLE,
RK_LIST_DOUBLE, ...
 void * ptr;  // storage for lists, matrices, etc
};

references

• blitz C++ fast vectors and arrays computations.
• blas very fast matrix library (part of Accelerate.framework on mac os X).