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: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW: http://www.musikwissenschaft.uni-mainz.de/~ag
