13 Jun
2004
13 Jun
'04
7:44 p.m.
New releases of Aeolus and Jaaa are now available at
<http://users.skynet.be/solaris/linuxaudio>
Aeolus-0.2.0
------------
- bugfixes,
- some new stops,
- added tuning and temperament controls,
- added controls for tremulant speed and intensity.
Still no manual :-( but it's coming...
This will be a stable release for some time. The next major step
is to add the 'chiff' generators, and this will require a lot a
research and work. First step is to make recordings of real pipes
and analyse them to find the noise spectra. I'll probably be
making recordings of the Metzler organ in the Antwerp cathedral
during the coming months. Then it's back to the drawing board.
The target is to make this work for LADconf 3...
Jaaa-0.1.0
----------
Some bugfixes, no new features. Adapted to the new shared libs,
see below. There's a minimal manual in the README.
Shared libraries
----------------
libalsadrv.so used by earlier releases is replaced by clalsadrv-0.0.1,
libclthreads and libclxclient have been are upgraded to 0.0.2.
Please delete all earlier versions of these libs, they are now useless.
The so-names are now correct, and Aeolus and Jaaa will link with the
*.so.0 files. I had this completely wrong in the first release
(thanks to Fernando for complaining about this :-).
--
Fons
15 Jun
15 Jun
5:06 p.m.
On Sun, 2004-06-13 at 14:58, Fons Adriaensen wrote:
New releases of Aeolus and Jaaa are now available at
<http://users.skynet.be/solaris/linuxaudio>
Aeolus-0.2.0
------------
Hi Fons... I noticed something different. I used to be able to start
Aeolus and click on [Next] and then I would get a preset (you know,
instant satisfaction - who wants to spend time turning on stops? :-). It
does not seem to happen anymore. Is this something in the packaging I
did, or is it something different in Aeolus?
-- Fernando
6:41 p.m.
Hi Fernando,
First of all, if you package Aeolus and Jaaa please use the most recent
versions that I released only yesterday evening (libclthreads-0.0.3
and jaaa-0.1.1).
I noticed something different. I used to be able to
start
Aeolus and click on [Next] and then I would get a preset (you know,
instant satisfaction - who wants to spend time turning on stops? :-). It
does not seem to happen anymore. Is this something in the packaging I
did, or is it something different in Aeolus?
The current version comes with no defined presets, but you can easily
create your own. There are 10 banks of 100 presets. Click on [Memory]
and you'll see something like
[<][>] a:b c [<][>] and some other buttons.
a = memory bank # 0..9
b = preset #, 0..99
c = U, *, L, S
U = undefined (empty)
* = defined
L = loaded
S = stored
[Store] will save the current registration into to the selected preset,
and [Recall] loads the selected preset. [Insert] moves up the selected
preset and all the following ones one place up, and stores the current
registration. Finally [Delete] deletes the selected preset, and all the
following ones move one place down.
[Next] is the same ++b [Recall] and [Prev] is the same as --b [Recall].
You can also use the normal Midi control messages (if the channel is
enabled in the bottom row of the Midi matrix) to load presets.
If you have a full piano keyboard, then the C and D in the octave
below the lowest one used by Aeolus (i.e. note # 24 and 26) will do
the same as [Prev] and [Next].
To save your presets for later use, click [Save]. This will also
save the Midi routing and any changes to the disposition.
The file $AEOLUS_DIR/aeolusrc' must be writeable for [Save] to work.
This is one reason to put the stops directory in the user's home
dir, and not in one of the standard lib directories.
The [Preset] button works as follows: while it is 'on', changing
the registration has no effect until [Preset] is switched off again.
This allows your registration assistant to prepare a new registration
and then switch to it :-)
(So I've finally started to write a manual...)
Enjoy !
--
Fons
6:50 p.m.
First of all, if you package Aeolus and Jaaa please
use the most recent
versions that I released only yesterday evening (libclthreads-0.0.3
and jaaa-0.1.1).
Yes, that's what I currently have packaged...
I noticed
something different. I used to be able to start
Aeolus and click on [Next] and then I would get a preset (you know,
instant satisfaction - who wants to spend time turning on stops? :-). It
does not seem to happen anymore. Is this something in the packaging I
did, or is it something different in Aeolus?
The current version comes with no defined presets, but you can easily
create your own. There are 10 banks of 100 presets. Click on [Memory]
and you'll see something like
[<][>] a:b c [<][>] and some other buttons.
a = memory bank # 0..9
b = preset #, 0..99
c = U, *, L, S
U = undefined (empty)
* = defined
L = loaded
S = stored
[MUNCH]
The file $AEOLUS_DIR/aeolusrc' must be writeable for [Save] to work.
This is one reason to put the stops directory in the user's home
dir, and not in one of the standard lib directories. The [Preset] button works as follows: while it is
'on', changing
the registration has no effect until [Preset] is switched off again.
This allows your registration assistant to prepare a new registration
and then switch to it :-)
(So I've finally started to write a manual...)
Yes, indeed, and thanks a lot for the explanations!
Enjoy !
I surely will!
-- Fernando
7:07 p.m.
Fernando Pablo Lopez-Lezcano wrote on Tue, 15-Jun-2004:
Fernando and I wrote the same thing at the same time. It must
be a good idea then :)
jlc
The file
$AEOLUS_DIR/aeolusrc' must be writeable for [Save] to work.
This is one reason to put the stops directory in the user's home
dir, and not in one of the standard lib directories.
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 :-)
7:01 p.m.
Fons Adriaensen wrote on Tue, 15-Jun-2004:
The file $AEOLUS_DIR/aeolusrc' must be writeable
for [Save] to work.
This is one reason to put the stops directory in the user's home
dir, and not in one of the standard lib directories.
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.
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? :)
jlc
10:59 p.m.
On Tue, 2004-06-15 at 13:52, Jesse Chappell wrote:
Fons Adriaensen wrote on Tue, 15-Jun-2004:
He he he, no instant satisfaction :-) I don't know, how big would be the
whole thing? (As a sysadmin) I would not want something replicated all
over the user home directories that is not really necessary.
-- Fernando
The file $AEOLUS_DIR/aeolusrc' must be
writeable for [Save] to work.
This is one reason to put the stops directory in the user's home
dir, and not in one of the standard lib directories.
[MUNCH]
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? :) 
16 Jun
16 Jun
8:51 a.m.
[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
10:46 p.m.
Hi, Fons,
thanks so much for this truly wonderful instrument, I'm sure we are
going to have very much fun with it. :)
I have a couple of questions, though:
1. I can't seem to get the ALSA output working. (ALSA MIDI input and
Jack output works ok.) When I try to start aeolus with -A, I get:
ALSA lib pcm_mmap.c:362:(snd_pcm_mmap) shmget failed: No space left on
device
Alsa_driver: can't set hardware parameters.
Alsa_driver: can't set playback hardware parameters.
Can't connect to ALSA
Does anyone have an idea what I'm doing wrong there? Do I have to enable
some kind of shared mem extension in ALSA? I am using Aeolus 0.2.0 on
SuSE 9.0 with the included Alsa 0.9.6, the soundcard is an sblive.
2. I noticed that you have put up some recordings on the aeolus website.
Are the original midi files by Matthias Nagorni also available somewhere?
3. Besides Werckmeister III there's another "well temperament" in the
tuning config. Which one is that?
4. Are the temperaments configurable somewhere? Do you have any plans to
support the MIDI tuning standard?
TIA,
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikwissenschaft.uni-mainz.de/~ag
17 Jun
17 Jun
8:05 a.m.
Hello Albert,
1. I can't seem to get the ALSA output working.
(ALSA MIDI input and
Jack output works ok.) When I try to start aeolus with -A, I get:
ALSA lib pcm_mmap.c:362:(snd_pcm_mmap) shmget failed: No space left on
device
Alsa_driver: can't set hardware parameters.
Alsa_driver: can't set playback hardware parameters.
Can't connect to ALSA
Does anyone have an idea what I'm doing wrong there? Do I have to enable
some kind of shared mem extension in ALSA? I am using Aeolus 0.2.0 on
SuSE 9.0 with the included Alsa 0.9.6, the soundcard is an sblive.
This is very strange:
- I have the same SL 9.0 and ALSA version (but other soundcards)
- The ALSA code is a near copy of the ALSA code in JACK, in
both cases memory mapped access is used.
I can only hope one of the ALSA wizards on the list can find out
what's wrong. The first error line should explain all, the others
are just the consequences.
You could try a shorter period size (512 or 256).
2. I noticed that you have put up some recordings on
the aeolus website.
Are the original midi files by Matthias Nagorni also available somewhere?
I'm sure Matthias will be prepared to make them available: mana(a)suse.de
3. Besides Werckmeister III there's another
"well temperament" in the
tuning config. Which one is that?
IIRC, it's by Jacob Breetvelt. I took it from the Scala database.
You can find the definition in scales.cc.
4. Are the temperaments configurable somewhere?
No, ATM the four that are built-in are all you have. It's a quick
solution but it should cover most periods. I plan to add direct support
for the Scala database at some time. If changing the temparament is
important to you, just let me know, and I'll change some priorities...
(and if it's very urgent, you could edit scales.cc :-)
Do you have any plans to support the MIDI tuning
standard?
If there's a demand for it, probably yes.
--
Fons
3:13 p.m.
On Thu, 17 Jun 2004, Alfons Adriaensen wrote:
- I have the same SL 9.0 and ALSA version (but other
soundcards)
- The ALSA code is a near copy of the ALSA code in JACK, in
both cases memory mapped access is used.
But I have the problem on SL 9.1 as well.
I'm sure Matthias will be prepared to make them
available: mana(a)suse.de
Yes: The MIDI's are up on the alsamodular site:
http://sourceforge.net/project/showfiles.php?group_id=69130&package_id=…
Not all mirrors might have them yet, though...
Matthias
--
Dr. Matthias Nagorni
SuSE Linux AG
Maxfeldstr. 5 phone: +49 911 74053375
D - 90409 Nuernberg fax : +49 911 74053483
4:04 p.m.
On Thu, Jun 17, 2004 at 07:04:42PM +0200, Dr. Matthias Nagorni wrote:
On Thu, 17 Jun 2004, Alfons Adriaensen wrote:
And I get the same when trying to use the default 'plughw:0' device.
So the solution is: aeolus -A -d hw:0
I'll try to find out what exactly is happening.
--
Fons
- I have the same SL 9.0 and ALSA version (but
other soundcards)
- The ALSA code is a near copy of the ALSA code in JACK, in
both cases memory mapped access is used.
But I have the problem on SL 9.1 as well.
18 Jun
18 Jun
5:25 a.m.
On Thu, Jun 17, 2004 at 08:07:04PM +0200, Fons Adriaensen wrote:
On Thu, Jun 17, 2004 at 07:04:42PM +0200, Dr. Matthias
Nagorni wrote:
The bug has been found. New release of libclalsdrv in a few days.
--
FA
On Thu, 17 Jun 2004, Alfons Adriaensen wrote:
And I get the same when trying to use the default 'plughw:0' device.
So the solution is: aeolus -A -d hw:0 - I have the same SL 9.0 and ALSA version (but
other soundcards)
- The ALSA code is a near copy of the ALSA code in JACK, in
both cases memory mapped access is used.
But I have the problem on SL 9.1 as well.
3:36 p.m.
Matthias Nagorni wrote:
Yes: The MIDI's are up on the alsamodular site:
http://sourceforge.net/project/showfiles.php?group_id=69130&package_id=…
That's great, thanks a lot!
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikwissenschaft.uni-mainz.de/~ag
3:35 p.m.
Alfons Adriaensen wrote:
Well, I'm experimenting with different temperaments, adaptive tunings,
psychoacoustic stuff, so this would be very useful for me. (I'm
currently using SuperCollider for that purpose, but my home-grown synths
don't sound all that good yet. ;-) But I'd vote for MIDI tuning standard
support, because that would allow programmatic control. (I already have
my own little tuning program which reads scala format files and dumps
tunings in either MTS or XG format.)
But by all means please go ahead with whatever your plans are to make
the instrument even more real (chiff and all that). ;-) If I grok the
sources, I might look into the MTS support myself, if I have the time...
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikwissenschaft.uni-mainz.de/~ag
4. Are the
temperaments configurable somewhere?
No, ATM the four that are built-in are all you have. It's a quick
solution but it should cover most periods. I plan to add direct support
for the Scala database at some time. If changing the temparament is
important to you, just let me know, and I'll change some priorities...
(and if it's very urgent, you could edit scales.cc :-)
7:25 p.m.
Hello Dr. Graef,
Well, I'm experimenting with different
temperaments, adaptive tunings,
psychoacoustic stuff, so this would be very useful for me. (I'm
currently using SuperCollider for that purpose, but my home-grown synths
don't sound all that good yet. ;-) But I'd vote for MIDI tuning standard
support, because that would allow programmatic control. (I already have
my own little tuning program which reads scala format files and dumps
tunings in either MTS or XG format.)
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 ?
Also, even with the programmatic control, there would still be the
delay of 20..30 seconds needed to recompute the waveforms.
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.
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.
Kind regards,
--
Fons Adriaensen
20 Jun
20 Jun
1:56 p.m.
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(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikwissenschaft.uni-mainz.de/~ag
7259
days inactive
7266
days old
linux-audio-dev@lists.linuxaudio.org
16 comments
6 participants
participants (6)
-
Alfons Adriaensen -
Dr.Graef＠t-online.de -
Fernando Pablo Lopez-Lezcano -
Fons Adriaensen -
Jesse Chappell -
Matthias Nagorni