Category Archives: Tinara

Development has proceeded rapidly since the recent design modifications and the changeover to Ruby as the primary language. Currently, multiple instances of Tinara’s components (interface, core, and renderer) can be run across multiple machines via TCP sockets. The core loads a rendering tree from disk upon startup, and keeps the on-disk copy up-to-date with any changes to environments or objects.

The next step will be the introduction of basic numeric data types into the rendering engine. This will allow tests to be performed, simple rendering agents to be developed, and the core of the cache system to be implemented.

After that, work on the audio output and graphical interface features can begin. A simple demo “song”, using oscillators as sound sources, can be created, and a demo release could be made (the graphical interface would, at that point, consist of little more than a window with start/stop/rewind buttons).

For a slightly longer and more detailed roadmap of current development/release plans, see the “doc/brain_dumps” file in the SVN repository:

http://svn.sourceforge.net/viewvc/tinara/trunk/doc/brain_dumps?revision=308&view=markup

The Tinara project has again been reborn with a new design, a new language, and a new philosophy. This time, I truly believe that I will be able to release an alpha version within a couple of months.

Tinara’s design has now made a fundamental departure from other “similar” systems. Tinara’s rendering engine will not be intended to be run in a realtime context (e.g. as a JACK client). This does not mean that it cannot be run in realtime – it simply means that there will be slightly longer controller latencies (probably not enough to notice during typical usage).

The upside of this design change is that the rendering engine, as well as any future rendering “agents”, can be much simpler and more flexible (and less error/crash-prone), since they will be allowed to do normal things like allocating memory, and reading/writing files, if needed. The problem of latency during audio recording will be handled later, by adding a simple headphone mix system with realtime effects to the GUI.

Tinara has also been broken cleanly into several separate components (Renderer, Core, Cache, and GUI), which will communicate via TCP sockets. Eventually, these components will also be able to use named pipes under UNIX, and perhaps DDE under Windows. The GUI has also been broken into two components – one which is binary (for display, audio output, and media capture), and one which is scripted (for controlling and quickly altering/testing/debugging the logic of the interface at runtime).

I’ve also decided that Tinara will initially be implemented in the Ruby language (with the exception of the GUI, which must be written in C/C++ in order to interface with JACK). This will allow much faster development and testing/debugging than C++. As a result, I expect to have a working prototype in a matter of weeks rather than months. Once the program logic is stable, it should be fairly trivial to re-implement the Ruby classes as C++ classes (thanks to the excellent helper classes provided by wxWidgets).

Many of the recent design decisions were either initiated or influenced by Eric S. Raymond’s excellent book “The Art of UNIX Programming”. It is available in hard-copy from several sources, and is also available online. More info can be found here:

http://www.catb.org/~esr/writings/taoup/

Among the many useful design philosophies I found from the book, two of the most strongly influential have been the Rule of Optimization:

http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#rule_of_optimization

and the Rule of Separation:

http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2877777

For more details on the design changes, see the doc/brain_dumps file in the SVN repository.

Although progress may be slow this month, much was accomplished during the month of September.

The most visible (or, rather, audible) change is that Tinara’s Interface component now produces audio output. When the “Play” button in the Interface is pressed, two sawtooth waves are generated, and they are sent to the default stereo audio device. This continues until the Interface is closed, or until “Stop” is pressed.

The Interface’s transport position display was operational for a time (using a temporary/throwaway implementation), but it is currently broken, so the “Rewind” button remains inoperative (pending a more “proper” transport implementation).

Much of last month’s progress was behind-the-scenes restructuring. I made numerous improvements to the build system, added command-line selection of which components should be loaded, and removed the GTK+ dependency for Linux builds of the Server and Engine components, allowing the loading of these components by the new “tinara-daemon” component, on systems without a running X server.

I am currently refactoring Tinara’s core library into a plain C API, with a separate C++ wrapper library. This approach will make the system more portable and extensible, by allowing the creation of bindings for other popular languages such as Python and Java.

I spent over 25 cumulative hours last week coaxing SCons and wxWidgets to cooperate under Windows. Now that this goal has been reached, Tinara should be able (in most cases) to use exactly the same source code and build system without modification on both platforms.

I also revisited the ROADMAP file (in the docs/ directory of the `tinara’ CVS module). I rewrote it from scratch, and I now feel that I have a fairly accurate reference for the amount of work required before an alpha release. As for a timeline, my current guess is roughly one year.

I’m in the process of switching over to dynamically-loaded XRC files for the GUI. The trouble is, XRCed and wxGlade (the only FOSS XRC editors I can find) both segfault when trying to load a previously-saved XRC file. I’ll probably end up writing a minimal XRC editor in C++ – I don’t want to ask other developers to go through the nightmare of trying to get wxPython built and working properly. For now, I’ll generate a starting XRC file with XRCed, and tweak it by hand as-needed.

I’ve continued to work through various details of Tinara’s design. I am currently working on the cache system – one of Tinara’s most significant features. As always, check the doc/ directory of CVS for the most up-to-date design info.

I’ve continued to refine the design. The first three chapters of the Implementation Guide now reflect something which I think is very close to the final design for the asynchronous distributed rendering infrastructure.

I hope to be coding again within a week, but I may not be able to write any actual Tinara code for a little while, since I’m planning to switch over to the SCons build system, and I’m also planning to move from GTK to wxWidgets. Both of these changes will benefit the cross-platform portability of the project, but it will take time for me to learn these new tools.