Next Previous Table of Contents
Midisend is able to use a special mapfile. These are available as interim solution, as long as aRts isn't able to handle midi processing in a similar, modular way like audio processing.
With this file you can instruct midisend to modify the midimessages, which come in from your midiport. The midimessage is changed before it is put sent to aRts.
With this you can e.g. split your keyboard.
The file is a simple ascii file. It consists of comments (wich starts with a ´#´) and of commands. Blank lines are ignored. Additional spaces and tabs are also ignored.
Glossar:
is the number of the note of the key. To find out, wich pitches maps your keyboard, start midisend with -v
specifies the instrument. In aRts you map a channel to an instrument.
You can use the following commands to configure midisend:
When a pitch on <Channel> comes in, and it is in the given range, the channel of the midi message will be changed to <ToChannel>.
Syntax: PRC <Channel>,<FromPitch>,<ToPitch>,<ToChannel>
When a pitch on <Channel> comes in, and it is in the given range, <PitchDifference> is added to the pitch.
Syntax: PRD <Channel>,<FromPitch>,<ToPitch>,<PitchDifference>
When pitch <Pitch> on <Channel> commes in, the channel will be changed to <ToChannel>.
Syntax: PTC <Channel>,<Pitch>,<ToChannel>
When pitch <Pitch> on <Channel> comes in, the pitch will be changed to <ToPitch>
Syntax: PTP <Channel>,<Pitch>,<ToPitch>
Examples: Assume a keyboard with 49 keys. To split the keyboard in two parts, where each part has an other channel, but is on the same octave, you would use:
PRC 0, 1, 59, 1 PRD 0, 1, 59, 24
If you just want the first part of the keyboard to be one actave down, you would use:
PRD 0, 1, 59, -12
Arts can read AKAI sample CDs through the utilitiy akaiparse. This is currently only known to work with S1000 sample CDs. If you have other AKAI sample CDs and programming skills, you may consider extending the utility to cover these as well.
The CDs generally contain two different kind of files: the samples and the programs. The programs contain keymaps which sample(s) should be played how for a midi pitch with a specific velocity. Currently, aRts is only able to use the samples you extract from the CD, not the programs.
There are two ways of accessing the CDs. You either can start with creating an image of the whole CD (will be about 650 Meg for a complete CD), and then use akaiparse to get samples out of that image. To create the image, run
dd if=/dev/cdrom of=<how_you_want_to_call_your_image>
Then, you can do the following things with akaiparse:
<partition> may be either a partition letter like A or B or the special 'all' to list (extract) all partitions.
When you have extracted, say, a whole piano with perhaps about houndred samples, you probably want that aRts plays the BOE_LD_F#3-L sample on the left channel and the BOE_LD_F#3-R sample on the right channel if you hit an F#3. If you have only a BOE_LD_F#3-* sample and a BOE_LD_G#3-* sample, but no BOE_LD_G-3-* sample, you would probably like to have aRts playing the BOE_LD_F#3-* sample (or BOE_LD_G#3-*) sample instead, but pitched up/down accordingly.
To achieve this (without spending quite some time typing a keymap), there is the utility called akaikggen. It works by defining groups of samples, such as left_channel and right_channel. You would then assign left_channel all the samples with -L, and right channel all the samples with -R.
To do so, open a terminal window, and call something like
akaikggen leftsample = BOE_LD_*-L rightsample = BOE_LD_*-R
If you like the result, you can direct into a file with
akaikggen leftsample = BOE_LD_*-L rightsample = BOE_LD_*-R > boe_ld.arts-map
To have an easy solution, you need to add the line
structure=play_akai_stereo
Artsshell is a utility that accesses the CORBA interface of artsserver directly - so it will only work if artsserver is running.
There are quite a few useful configuration options that you can tune with artsshell.
Calling
artsshell -i
will give you some useful status information about cache usage, number of active modules etc.
artsshell -s
will give you some information about all realtime settings of aRts.
If you are working with samples, you may find it useful that artsserver is caching them automatically. However, for some applications (like loading a whole 100 sample piano from an AKAI sample CD), the preconfigured 8 MB cachesize are simply not enough. To increase that, use
artsshell -C <cachesize in KB>
For some computers/applications, the preconfigured latency may be not optimal. For instance, if you "just" want to run aRts as audio server, and listen to a few mp3s, latency values of 10ms are not really required. It is enough that if you hit on the stop button of your player, the mp3 will stop some time later - but half a second is just fine for that.
There are three parameters for that: number of fragments, size of each fragment and the scheduling cycle size. The sound driver buffer consists of framents * (size of each fragment) bytes, which divided by 2 (16bit) and the number of channels gives the latency. Detailed documentation about how OSS implements that are at http://www.4front-tech.com/pguide/audio2.html
The schduling cycle size is how many samples aRts will calculate when it detects that the soundcard buffer is not full.
To get useful results, the delay of the scheduling cycle should be smaller than the delay of the fragments. Rule: The delay of one or two fragments should probably correspond the delay of the scheduling cycle. Use
artsshell -F <fragments>:<size> -S <scheduling_cycle_samples>
To configure these parameters.
If you are developing aRts, or searching a bug, you can use
artsshell -D 1
to enable the printing of debugging information. To print such information from artsserver (or one of the modules), simply use artsdebug like you would use printf. (You may need to include "debug.h").
Please read the audio server section as well. As in aRts-0.3.4, artscat can record data from aRts (with a full duplex card you can with that record data from outside world - in any case you can of course record what aRts is doing).
On the other hand, you can replay data through arts.
Use
artscat -t <type> -d <description> -p
to play the data through aRts, and supply what you want to play on stdin. It is supposed to be 44100 Hz, raw, 16bit, stereo, signed, le data. Well, just for instance what mpg123 -s or mikmod with its stdout driver produces.
Use
artscat -t <type> -d <description> -r
to record the data from aRts, and you'll get the recorded result on stdout. It will be 44100 Hz, raw, 16bit, stereo, signed, le data.
Watch out for clipping here. Arts interally handles all data as floats, and therefore doesn't care if you transfer for instance data in the range of [-4..4] over a bus. But if you record that data through artscat, it will be clipped (or I guess: it gives real bad overflows). So make sure that you record from busses that have resonable data on it. Synth_SATURATE_ATAN is your friend here.
All those artscat operations get assigned to a bus through user interaction. Simply starting artscat won't do anything - you still need to assign a bus. Do that either with artsshell -c and -d, or using a gui structure that has an audio manager running (such as example_mixer_eqfx and similar).
Next Previous Table of Contents