| Here is information on a number of undocumented opcodes in the
current and recent versions of Csound.
This is an edited version of what I just wrote to Jean Piche.
Information follows on the following opcodes:
tablekt
tableikt
icgoto
kcgoto
gcgoto
ktone
katone
kreson
kareson
oscilx
limit
ilimit
seed
peakk
peaka
The other two undocumented opcodes I know of are:
ktableseg
ktablexseg
I haven't looked at these - they are Richard Karpen's pvoc.c.
All the details follow
- Robin
After nearly two years, I am getting back into Csound!
I hadn't realised that my rewrite of the table read code had been
incorporated, in ugens1.c. I am glad it has!
This includes the ugens "tablekt" and "tableikt" which enable
changing the table number at k rate. However these two ugens are
not mentioned in the manual.
I propose that I write some new text to describe:
table, tablei, tablekt and tableikt
on one page, with a proper, more detailed description of wrap mode,
offsets, interpolation and the guard point. The "guard point"
concept is one that puzzles people, and this is an excellent place
to describe it fully. (Actually, on the bottom of the "table,
tablei, oscil1, oscil1i" page, it talks about the guard point, but
confusingly does not use the term "guard point".
Then I propose that the following ugens have their own page:
oscil1, oscil1i, osciln
[Jean said this is fine - I will send him some text or HTML.]
The syntax is:
kr tablekt kndx, kfn[, ixmode][, ixoff][, iwrap]
kr tableikt kndx, kfn[, ixmode][, ixoff][, iwrap]
Which is identical to table and tablei, except that the second
input parameter is a k rate (can still be an i rate) variable,
instead of being i rate.
> kcgoto
========
There are functions icgoto() and kcgoto() in insert.c and they have
been there since February 1995 at least. They are used with the
opcodes:
icgoto, kcgoto and gcgoto
which have been in entry.c since then as well.
None of these are mentioned in the current manual.
It is clear that they are conditional gotos, where the
first parameter must be a boolean. A boolean is an integer inside
csound, not a float like a k rate value. The only things that
return a boolean are:
> >= < <= == != && ||
So, although I haven't tested them, I guess they would be used as
kgoto p3 > 5 , label
So I think that these three are functionally equivalent to the
already documented "if . . . xgoto " constructs.
icgoto ia R ib , label } i time only.
== if ia R ib igoto label }
kcgoto ia R ib , label } k time only.
== if ka R kb kgoto label }
gcgoto ia R ib , label } i or k time.
== if ka R kb igoto label }
I suggest that they should be tested (its not convenient for me
right now) and documented on the same page as igoto etc.
> kareson
> kreson
> ktone
> katone
> kport
=========
These are all mine - they are in ugrw2.c.
kport is documented in the manual in "port.html" however it is not
mentioned in "CONTENTS.html"
The other four should be included on the same page.
port Deals with k rate signals, with an i rate time.
kport Deals with k rate signals, with a *k* rate time.
tone } All have k rate control of frequency and bandwidth
atone } but deal only in *a* rate input and output signals.
areson }
areson }
ktone } Are just like those above, but they deal with
katone } *k* rate input and output signals.
kreson }
kareson }
So just mention this and include syntax lines such as:
kr ktone ksig, khp[, istor]
kr katone ksig, khp[, istor]
kr kreson ksig, kcf, kbw[, iscl, istor]
kr kareson ksig, kcf, kbw[, iscl, istor]
> oscilx
========
This is a 1994 creation of Paris Smaragdis. See aoscilx.c/h.
Like far too much software, there aren't any comments. I find it
so exasperating!!!!!!!!
It looks like it puts out a rate audio and has four input
parameters:
k "amp" Amplitude.
i "freq" Frequency in Hertz.
i "ift" Table number.
i "periods" How many cycles through the table should be played.
After they have been played, put out 0.
Considering there's not k rate frequency, its not very exciting.
> limit
=======
This is one of mine. Pretty much all that can be said of them is
in ugrw2.c. Slightly reworked, this is:
limit, ilimit - syntax
ir ilimit isig, ilow, ihigh
kr limit ksig, klow, khigh
ar limit asig, klow, khigh
These set lower and upper limits on the xsig value they process.
If xhigh is lower than xlow, then the output will not be affected
by xsig, and will be the average of xhigh and xlow.
> seed
======
This is part of the main random number / noise system - in
cmath.c. It calls the C library's srand() function with the single
i rate input parameter. It has no output. Looking at the source
for seedrand() in cmath.c, if the parameter is 0, it uses the
current time for the seed. Otherwise it casts the floating point
input parameter into an integer and uses that as a seed. I think
that means that fractional parts of the input parameter are
irrelevant.
The trouble with this entire random / noise system is that it
relies on the C library's rand() function - which is very often
pathetically limited to a 16 bit pseudo-random number generator
(PRNG). There's no way this is good enough for audio! Also, the
ability of other programs to muck around with this system is
unacceptable too.
In September 1995 I fixed this up for my own system - with a 31
bit PRNG, and I am about to do it again and will post details to
the list.
There are two other random / noise systems in Csound:
1 - In ugens4.c, there is the rand, randh and randi code.
These are self-contained 16 bit PRNGs which can have their
seed set as an option. Each instance maintains its own state.
2 - Barry's recently added irnd, ibrnd, krnd and kbirnd code in
aops.c. These are part of a single, self-contained, 32 bit
PRNG. The seed is always set at the start of Csound
running, (so they always produce the same set of numbers!)
All instances of these ugens share the one PRNG, with the one
state. It is a simple PRNG and I don't know anything about
the quality of noise it produces.
> peak
======
peakk and peaka are mine too. The doco is in ugrw1.c:
Two ugens for tracking peak signal levels
-----------------------------------------
peakk takes k rate inputs and peak takes a rate inputs.
They maintain the output k rate variable as the peak
absolute level so far received.
kpeakout peakk ksigin
kpeakout peaka asigin
kpeakout Output equal to the highest absolute value
received so far.
This is effectively an input to the ugen as well,
since it reads kpeakout in order to decide whether
to write something higher into it.
ksigin k rate input signal.
asigin a rate input signal.
- - - - - - - - - - -
===============================================================
Robin Whittle rw@firstpr.com.au http://www.firstpr.com.au
Heidelberg Heights, Melbourne, Australia
First Principles Research and expression: music, Internet
music marketing, telecommunications, human
factors in technology adoption. Consumer
advocacy in telecommunications, especially
privacy. Consulting and technical writing.
Real World Electronics and software for music: eg.
Interfaces the Devil Fish mods for the TB-303.
=============================================================== |