Hello Csound mailing list members,

So far, I have written two letters to the mailing list, but posted no
solutions.  Now, it's time for me to give back a little.  My first letter
had to do with Csound examples using the MIDI features.  Without examples,
the manual is pretty opaque.  Someone suggested the big Csound distribution
at Keyboard Magazine.  I didn't find any examples of MIDI rendering based
on .WAV or .AIFF files in the files Keyboard added, but wandering around
later, I came across examples in a file entitled "csound_tar.gz".  The
files are titled things like "pastoral", "123" and "strings" with ".mf",
".orc" and ".sco".  I think it is a version 2.x distribution.  Oddly, I
don't see these files in the csound95.exe distribution, or the
"csound_src.zip" file, but the samples these examples use are still up on
the MIT FTP server.  The problem with these examples is that they won't
run, as is.  They are missing a parameter in the ".sco" files which is not
documented in the HTML Manual Version 2, but IS documented in the
"csound.hlp" windows help file, which is less complete.

The next letter I wrote concerned a big problem I was having determining
the sign of a function at a-rate.  Somebody on the mailing list emailed me
directly with the solution.  That's great, because I don't want the full
mailing list feed, so I haven't subscribed.  I believe my benefactor's name
is Mike Pocino.  The statements which I finally wound up with, and which
work, are:

inum		=1/1e10					;ie9 too small, 1e15 too big
asignl	table al* inum +.5, 3,1,0.5
asignr	table ar* inum +.5, 3,1,0.5

in the .orc file, and:

f3 0 2 -2 -1 1

in the .sco file.  I work with some really big numbers in power
calculations for doing two pans of stereo instruments.

I have more information about the Csound95 3.44 division bug, and a new one
as well.  Apparently, this bug affects any divisions made at a-rate.  The
results are often right, but periodically wrong.  Notice that I multiply by
the ivar set to 1/1e10, instead of dividing by 1e10.  If I try to do this,
I get erratic results.

I believe I have found another "bug", but if it works as designed, it was
designed poorly.  It is sometimes necessary to assign a constant to a
variable of a suitable type in order to utilize it.  The "table" definition
with an a-rate result is:

ar	table		andx, ifn[, ixmode][, ixoff][, iwrap]

and I had one problem in a test case where it did not work using a constant
for andx, but did when using a variable.  Uncharacteristically, I have not
tested this bug extensively before reporting it, but have seen examples of
code assigning constants to variables before use.  There is no need for
this sort of behavior by the interpreter, since the constant could be
assigned to a suitable temporary variable hidden by Csound, and executed. 
As it is, if this is indeed the case, then the interpreter provides no
warning that this is illegal syntax, and thus new programmers are
constantly spend hours debugging a construct that looks like it should
work.

A few more ways Csound needs to be extended in order to make it a decent
language:  exp() raises to an exponent of the natural constant e, but log
finds the exponent for the mantissa of 10.  These two functions are
incompatible, and must be interconverted to use both.  If an interpreter
supplies exp(), it should supply ln().  If it supplies log(), it should
also provide for exponents such as 10**x, or supply a exp10() function
perhaps.

Csound needs block IF's, ELSE's, and ELSE IF statements.  This helps make
programming more readable.  I also think that if you have an IF ... {} or
IF ... THEN type construct, then the interpreter could choose goto, igoto
or kgoto depending on the type of the resulting expression.  I have spent
some time finding such a bug where I had the wrong type of goto myself,
because I had cut and pasted some code, and missed one.  Also, functions
with replacable parameters and a typed result would be useful.

Csound is a beautiful concept: a sound processing language that is fast
enough that it can even work in some realtime applications, and is platform
independent.  Working with it, however, doesn't give one the impression of
the type of language design we were taught about in computer science
classes, where the language is constructed in a way to minimize coding
errors and maximize flexibility.  Rather, it is somewhat like my experience
working with dBase III+, where all types of constructs which look like they
logically should work, don't, due to quirks in the implementation of the
language.  You just have to spend unnecessary hours upon hours debugging,
until you can create a construct in the language which does work.  Or you
have to spend hours developing complicated workarounds, because a simple
flag or function wasn't implemented in an obvious omission.  With better
language design, all this could be avoided.

By the way, another bug I have in the Csound95 implementation: the kdump
statement seems broken.  If I use that statement, it creates the file, but
keeps on generating an error like, Can't open file "kdump.txt".  Also, how
about an adump statement?  Wouldn't that be a logical addition?

Guess I may have to gain access to Visual C++ 4.2 and build the thing
myself eventually, but I really don't want to.  My job is making music now,
not software.  Sigh.

Jackee Criswell
TheSilverSurfer@themall.net