[linux-audio-dev] [ANN] New releases of Aeolus and Jaaa

[Alfons Adriaensen]

[Fernando] 

> I see... you may consider for a future version to write a ~/.aeolusrc
> alternative file (ie: if $AEOLUS_DIR/aeolusrc is not writable just write
> to ~/.aeolusrc), and read from it if available. I'm installing the
> presets in a shared lib directory so that there is only one copy for all
> users and obviously that directory is not world writable :-)

[Jesse Chappell]
 
> You might consider using ~/.aeolus/rc or something of the sort
> for the writing of user configuration instead of AEOLUS_DIR.
> You also might consider not relying only upon the envvar, but
> building in some system-wide paths (at configure/build time) to
> search for stops if AEOLUS_DIR is not specified.
> Both of these things could help long-term usability, IMO.

Since your comment are very similar, I'll try to answer all points
together.

One of the objectives for Aeolus is not only to permit a user to 
play a predefined instrument, but also to enable him/her to modify
it and create new stops. ATM, this feature is not very strongly
advertised for the simple reason that there is no manual for the
stop editor (which *is* built in an can be used), and that this part
is likely to change a lot in the (not so distant) future.

For this to work, the whole stops-x.y.z directory should belong to
the user, and not be a system-wide shared resource, and the aeolusrc
is local to that directory since it must be consistent with the
contents of it. 

A user could very well have a number of stop dirs, each with its
own aeolusrc, and defining different instruments. I have three ATM,
of which only one is distributed, corresponding to an organ that is
based on the German Baroque tradition (that's the influence of 
Matthias :-). But other instruments are possible, and future versions
could come with more than one stops directory.

So in my view, a ~/.aeolusrc would make sense, but it would be
at a higher level than the current one: it would contain global
options such as soundcard and related parameters, and also a
default stops directory. The existing aeolusrc is not really an
application config file - it defines an instrument, and also
contains things such as the stored presets.


> Also, what are your thoughts about disk caching the generated waveforms
> that is done at startup?  These could be written into the ~/.aeolus/
> dir based on whatever settings (samplerate, etc) and loaded instead
> of always re-generating them.  I haven't looked at the internals,
> so if there is some fundamental thing preventing that, ok.  I
> just want to instantly *play* it, you know?  :)

Yes, this is certainly possible, and I already considered doing this,
as it would indeed lead to 'instant satisfaction'. IMHO, this is an
optimisation, and anayway, on a real organ you have to wait for the
air pressure to build up :-)

OTOH, the wavetables depend on three paramters: sample rate, tuning and
temperament, so this requires some extra checks (no big problem really).
But considering the points above, the wavetables also depend on the user,
so they would have also have to be private to each user.

Probably the best solution would be to have an ~/.aeolusrc that points
to a system-wide shared stops directory (and wavetables), and still
permitting the user to create his own. In fact, the current solution
of using $AEOLUS_DIR does exectly that.


-- 
Fons