Command Line Hints

There are two ways to start realtime audio output sessions: using DirectSound or old MME Wave OUT. Don't use both the flags at the same time!  To use DirectSound you have to set the -+X flag together with -b flag. The buffer length determines how quick the response to your realtime actions is. With my Pentium 133 a value of -b100 is the minimum possible value: below that sample-flow interruptions will occurr (i.e. pop and clics will be heard). However, with other computers it should be possible to reduce this value to allow a faster note response (curiosly, sometimes faster computers need a bigger value as in the case of my new Pentium II 400 MHz, which needs at least a -b200 value).  DirectSound is very sensitive to everything is happening in your computer, so during realtime performances you MUST SUPPRESS all console messages by means of -+O and -m0 flags otherwise sound flow interruption will occurr. You can type the -+X flag with a number identifying the DirectSound device to be activated. If you type it without a number, a list of installed DirectSound devices will be shown in the console window asking the user to type a number.

When DirectSound is not used, finding the optimum values for "-b" and "-+p" flags (which enable the old MME WAVE OUT driver) requires some experimentation: more buffer length means more latency delay but also more safety from dropouts and sound interruptions (flag "-B" is now obsolete, don't use it).  Now it is possible  to reduce buffer length and delay by using '-+e' flag and 'rounded' sr and kr.  Notice that sometimes a smaller buffer length can handle sound flow better than a larger. Only experimentation can lead you toward optimal '-b' values.  However the minimum latency delay can be allowed only when using DirectX (-+X flag) instead of old MME driver.

When DirectSound is not used (i.e. when using old MME drivers), optimum "-b" and "-+p" flag values need to be changed with different audio and k rates. These changes are not linear and not intuitive. So experiment!

It is suggested to try to set "-b" value to integer multiples or sub-multiples of kr. This tip sometime can help to reduce latency, sometime not. Again, experiment to find optimum values.

When old MME WAVE OUT driver is used (for example, when using audio IN and audio OUT at the same time), "-b" and "-+p" flag values can be reduced considerably by using "rounded" ar and kr values (for example ar=32000 and kr=320; ar=40000 and kr=400 and so on) together with "-+e" flag (until now this feature is tested only with a SB16 ASP and with an AWE32 card. I don't know if other cards support it). Reducing "-b" and "-+p" flag values means reducing latency delay and so a more interactive realtime playing.

"-+Q" flag allows parallel MIDI OUT and DAC performance. Unfortunately the realtime timing implemented in Csound is completely managed by DAC buffer sample flow. So MIDI OUT operations can present some time irregularities, because the fullness of audio buffer cannot be predicted at each moment. These irregularities are reduced when audio buffer length is very short. At last, irregularities can be fully eliminated when suppressing DAC operations themselves ('-+Y' flag).

"-+Y" flag suppresses DAC operations. This enhances timing of midi out operations when used in conjunction with "-+Q" flag. It is recommended to use "-+Y" with low krates (max. kr=1000). As in Win95 maximum timer resolution is 1/1000 of second, unpredictable results can occurr when using it at krates greater than 1000.  Also it is very important to set only kr values in which the following division: 1000/kr  produces integer results (some example: kr = 10; 20; 50; 100; 125; 200; 250 etc.) because Win95 timer only handles integer periods in milliseconds. If you use a kr value that produces a non integer result in the above formula Csound seems to run normally but times will be not reliable. With my computer I work very well with a value of kr=200. Maybe with slower computers a lower value works better. Experiment! I recommend to use kr=200 or less because with values greater than 200 increases the overhead affecting the entire system and do not give a noticiable precision improvement. A time resoultion of 1/200 of sec is enough precise for almost all MIDI application. You must respect sr/kr/ksmps ratio even if sr value is meaningless when using "-+Y" flag, or an error message will stop the performance.

'-+*' flag compells Csound to yield control to system until audio output buffer content passes a certain threshold. Below this threshold Csound continues processing, while over this threshold Csound yields control to Windows. This gives a big enhanchement in multitasking processes. Enabling this option could reduce polyphony a bit when using short buffer space.  In this case, the user should increase the number ('-+p' flag) and the length ('-b' flag) of buffers when setting '-+*' flag. Experiment to find best values.

For best realtime performance, it is (obviously) better:  reduce the number of concurrent applications running  not moving neither resizing or closing windows during all realtime session.

'-+O' flag suppresses all text output during the performance time. Using only '-m0' flag, some text messages are still sent to the console. I recommend to use '-m0' and '-+O' flag together for maximum performance speed.

'xtratim' and 'release' opcodes (as well as 'linenr') don't operate correctly when using -t flag.

When using ctrlXX and midicXX opcodes you must be sure the MIDI IN flag (-K and/or -Msbmidi) is activated, otherwise Csound will crash!

When using realtime AUDIO input you must set the -i flag without argument, or followed by a number which represent the wave-in port number recognized by Win95. (ex. -i0). Notice that DirectX realtime input is not implemented yet, so you must use the old MME driver.

When using WAVE out and FILE out in parallel, you must set -o flag followed by the output file name (which must have a name different than "devaudio" or "dac" obviously), toghether with the -+q flag (when using MME) or -+X flag (when using DirectX).

Unified file directive syntax (DirectCsound, as well as the canonical csound version, now partially implements Micael Gogins' AXCsound structured data files): The following example is a "csd" text file template. The format of .csd files follows the same principles as SGML, XML, or HTML. Each section of data is prefaced by a start (<>) tag and finished with an end (</>) tag, and sections can be nested hierarchically. The Csound tags (boldface) are as follows, with explanatory comments (italics) and sample data: <CsoundCsynthesizer> ; Csound structured data file. <CsOptions> ; Command-line options -W </CsOptions> <CsInstruments> ; Orchestra statements. sr 44100 kr 441 ksmps 100 nchnls 2 ; Instrument definitions. ; The first comment following on the same line as an instrument number is the name of the instrument. instr 1 ;Toot1 endin instr 2 ;Toot2 endin </CsInstruments <CsScore> ; Standard Csound function ("f") statements, note ("i") statements, or comments (";"). f 1 2 3 i 1 2 3 4 </CsScore> </CsoundSynthesizer>a