Re: [Octal-dev] porting thoughts

[Dave O'Toole]

address@hidden wrote:
> 
> Like I said in my reply to Bullwinkle, I suggest continuing on the path of
> implementing a GTK in-process GUI for the end of the summer, in order to make
> the goal of reaching beta by then possible.  At the same time, it might make
> sense to keep the client-server approach tucked away somewhere as an idea for
> future releases.

This is also in response to several other messages, so sorry it's kind
of out of order. :-)

The first thing I want to say is that none of this is "set in stone."
The underlying stuff that's completed so far is structured as a library,
so it is possible to take several approaches with respect to the GUI and
whether or not the GUI and core are in separate executables. This also
doesn't mean we shouldn't try to pick the best one, or we'll have 30
half-finished GUIs with none of them being really good. There is
something to be said for focus, which means not spending time writing an
Athena interface when we have GTK+. :-)

Everything is unstable right now--there's not much ground to stand on.
While this is in alpha, and while the "first thing" is still being
written and shaped day by day, it becomes hard to write and experiment
with layers the way we've been talking about. If anyone had written a
machine a month ago, it would have broken since then--I needed to change
the API. Similarly, I am about to change the name of one of the library
functions because it collides with one in the C library (boy, you would
never believe the bug this caused.) 

Needless to say, it's difficult to start porting an app that doesn't
fully exist.

I started work on the GUI last night. I am also building the GUI as a
series of small parts (independent windows, like the GIMP) so that it
won't be difficult to re-use those parts later should the architecture
change. 

I've been taking advice and opinions from several developers of other
UNIX audio projects: Quasimodo, SoundTracker, and GSynth. (I didn't want
to jump into this without knowing what some others think.) There seems
to be some consensus in how these applications are built. From
experiences Paul Barton-Davis has related on the linux-audio-dev list,
the "do everything with messages" works best for tiny amounts of data,
like commands. If the core and the GUI do not have shared, direct access
to the song data, then you have to shoehorn *everything* through the
CORBA server or through whatever IPC you're using---the 8k+ patterns,
the wave data, everything. 

Having the core run on one machine while the interface runs on another
(X does this already btw) sounds "wow, cool!" but it isn't clear how
useful this would be unless both machines are in the same room connected
by LAN. Otherwise you're not going to hear anything. 

Thankfully there are other ways of decoupling GUI code from DSP code
than just going client-server. I'm going first for the qualitative goal
of having an efficient and flexible application, rather than the
qualitative goal of "make it client server" which may not have anything
to do with the goal. 

For the moment I am going to use a single-app, multithreaded model, with
some events being governed by message queues (i.e. start, stop) and
changes to the patterns + song data being governed by mutexes. This is
similar to what goes on in SoundTracker. Of course, if we find out that
it doesn't work perfectly, then it will change.

> On the other hand, deciding that this is an worthwhile goal for the future 
> still
> has an impact on certain aspects of design.  Like, I noticed that the (x,y)
> parameters of each machine instance are stored as part of the machine's state 
> as
> designed now, but if the UI is really separate then that info is irrelevant to
> the audio engine and shouldn't be stored there.  (Imagine having to pass
> messages between the UI and server everytime the user dragged a machine around
> -- ick!)

This would be updating just two variables, and it would only need to be
done once (when the user stops dragging the little box.) I don't imagine
this would be a real performance problem (even with something like
CORBA.) 

It is true that the x and y coordinates won't be used in any DSP
calculations. But neither will instance_name or several of the others. A
machine has a location in the network (which must be saved when you save
your song), and this is an attribute of a machine whether or not it is
an "audible" attribute. If we were really to store this in a
GUI-dependent fashion, then we'd better make sure all the GUI's are
doing it the same way or you won't be able to share files across
interfaces. 

This really isn't a big deal unless you want to run the client in Kansas
and the server in Canada. As OCTAL is designed primarily for studio
recording and live performance (basically, tracker tasks) I don't see
where this is going to come in even if we could find a way to make it
usable. 

-- 
@@@ david o'toole
@@@ address@hidden
@@@ www.gnu.org/software/octal