Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
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 Graf Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikwissenschaft.uni-mainz.de/~ag
Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
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: 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. And I get the same when trying to use the default 'plughw:0' device. So the solution is: aeolus -A -d hw:0 The bug has been found. New release of libclalsdrv in a few days. -- FA
Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
Alfons Adriaensen wrote: 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 :-) 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 Graf Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikwissenschaft.uni-mainz.de/~ag
Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
Matthias Nagorni wrote: Yes: The MIDI's are up on the alsamodular site: http://sourceforge.net/project/showfiles.php?group_id=69130package_id=121417 That's great, thanks a lot! Albert -- Dr. Albert Graf Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikwissenschaft.uni-mainz.de/~ag
Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
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
Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
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: [EMAIL PROTECTED] 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
Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
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: [EMAIL PROTECTED] Yes: The MIDI's are up on the alsamodular site: http://sourceforge.net/project/showfiles.php?group_id=69130package_id=121417 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
Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
On Thu, Jun 17, 2004 at 07:04:42PM +0200, Dr. Matthias Nagorni wrote: 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. 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
Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
[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
Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
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 Graf Dept. of Music-Informatics, University of Mainz, Germany Email: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW:http://www.musikwissenschaft.uni-mainz.de/~ag
Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
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
Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
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
Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
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. 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 :-) 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
Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
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
Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
Fernando Pablo Lopez-Lezcano 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. 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 :-) Fernando and I wrote the same thing at the same time. It must be a good idea then :) jlc
Re: [linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
On Tue, 2004-06-15 at 13:52, Jesse Chappell wrote: 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. [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? :) 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
[linux-audio-dev] [ANN] New releases of Aeolus and Jaaa
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
