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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
From: Albert Graef (Dr.Graef_AT_t-online.de)
Date: Sun Jun 20 2004 - 18:49:57 EEST


Fons Adriaensen wrote:
> Adding MTS probably will not be too hard. There is a problem however
> since Aeolus expects a frequency for the A above middle C and a
> temperament defined over one octave, while MTS could specify any
> frequency for any note. So what I'll probably do is to take from
> the MTS data the octave starting at midi note 60, and compute the
> relative frequencies and tuning from that. Would that be OK for you ?

Hi Fons,

yes, I think that this is a reasonable solution. Of course one could
also design an aeolus-specific sysex format for octave-based tuning
tables, that could make things easier. (There are so many tuning
"standards" out there already, every tuneable hardware synth seems to
have its own, so why not just invent another one. ;-) The only essential
requirement that I see is that the resolution of the tuning protocol
must be (at least) 0.01 Cents, otherwise some of the just intervals
still have annoying beats. MTS satisfies this, of course. Also, it is an
established standard, although I don't know of many implementations.
OTOH, it would be nice to have a light-weight protocol for octave-based
tunings, to reduce communication overhead. MTS doesn't offer this. Other
common formats (like XG and GS) suffer from their 1 Cent resolution limit.

> Also, even with the programmatic control, there would still be the
> delay of 20..30 seconds needed to recompute the waveforms.

Yes, MTS specifies that changing the tuning table is a realtime message.
In the case of aeolus this is certainly impossible. I don't know how
much memory the precomputed wavetables need, but I strongly suspect it
would also be infeasible to cache different tunings in advance and then
switch between them on the fly? Of course this severely limits the
usefulness of programmatic control. So no adaptive tunings for now. :(
For all other applications it's probably enough if one could easily
configure the tuning (e.g., by loading a scala file) in aeolus itself,
although the MTS interface would still be useful if you want to use an
external software tool to retune different instruments simultaneously.

> Do you have a program that outputs MTS on an ALSA sequencer port ?
> That would be very useful for testing the MTS code. In fact I have
> no other means to do that ATM.

I do have a little Q script with Tk GUI that does the job for
octave-based tunings in Scala format. It uses MidiShare, but the new
msAlsaSeq driver for MidiShare makes it possible to interface to ALSA
sequencer ports. I haven't released it yet, but if you want to have it
just let me know. (You'll need Q, Q-Midi and MidiShare to make this
work, though. All readily available as SuSE 9.0 RPMs from
http://q-lang.sourceforge.net/.)

> To work around the bug you reported I suggested -d hw:0.0
> This should be -d hw:0 (tested, this works). I also found the
> cause of the problem, it's not in Aeolus but in one of the shared
> libraries.

Yes, the -d hw:0 option does the trick. Thanks a lot for looking into this!

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef_AT_t-online.de, ag_AT_muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Jun 20 2004 - 18:39:56 EEST