The starting premise for the Ayyi project is that GPL’d audio software cannot succeed unless the modularity of its architecture is increased. There are good technical and usability reasons for this, but the primary reason is to support a distributed development model. With developers working in small teams and having diverse goals and opinions, the monolithic applications copied from the proprietory world have so far failed to achieve critical mass. This is not meant to belittle projects such as Ardour, Rosegarden or Muse in any way, but is just a recognition of the large challenges faced, and the continued increasing of expectations fueled by proprietory software products.
Many developers are not greatly interested in dealing with the headaches of slotting into a larger framework, but it is in many ways not in the best interest of the developer to spend time on writing code that is only useful to yourself. Because by making it useful to others, and thereby become part of something bigger, in the long term you make the code more useful to yourself. It becomes possible to concentrate on advanced functionality and pushing the boundaries rather than covering old ground writing boring support code.
One of the problems of modularity in this genre is that from the users point of view there needs to be a central focal point which everything revolves around. In existing software, this takes the form of an Arrange/Project window. Ultimately, it would be nice to make screen space here available to devolved services, similar to Microsoft OLE, but this is technically quite difficult to do. Perhaps something to consider later.
So the proposition is for this space to aggregrate the control of separate services. Some of these are nicely separated already - primarily synths, processing plugins, and routing. Jack and Ladpsa/Dssi are excellent examples to build on.
There is a natural split available along Model, View, Controller lines. Many audio programs are already internally architected like this.
It seems logical to preserve a single model, or ‘song’, containing central project information, and its audio and musical playlists etc. This needs to be ‘rendered’ both visually and in audio by record/playback engines for each media type, and one or more gui’s. Input can come from gui’s and other specialised controllers. So the split seems pretty clear cut, and experiments have shown that it actually is workable, so are there any disadvantages?
Too much work. Creating the system is more work initially, but once this done, large possibilities open up. Coding is forced to be considerably more asynchronous, which does make development slightly more time-consuming.
Latency. In practice this doesnt seem to be a problem on a single machine. With the introduction of a network, presumably there will always be a noticable lag, though the effects can be minimised, and it would almost certainly be more pleasant than a remote X session.
Lack of cohesion. This could take the form of missing or incompatible services. Certainly this is an ongoing concern, but is just an organisational problem. For transparent operation of the system, certain relatively simple functions such as auto-startup for services, are needed.
The idea is to add to the collection of run-time services that are available to ease development.
Ayyi uses a variety of independant processes performing specialised functions:
song - handles the main data model
recorder - audio disk i/o and transport control. Similar processes would also exist for other media types such as MIDI.
mixer - transfers audio from the recorder to Jackd and performs any processing needed.
gui - any number of independant user interfaces can display and manipulate the data associated with the other clients.
core - one unreleased implementation uses a central server that handles communication and session management for the other processes. This is useful for complex setups, but is not essential. There are conceptual issues regarding conflicts with other session managers such as LASH.
processor - offline processing for cpu intensive tasks. Fx rendering, peakfile generation, etc.
Most of these correspond to tasks internally seperated at the class or thread level in traditional applications anyway, so enforcing their separation isn’t neccesarily such a big step.
One client may provide more than one of these services.