| >Last easter i started looking at wgbrass and it seems to be
>sample-rate dependent. At 22050 (the rate for which the original Cook
>code ran) it seems to generate an audio signnal, but at 44100 I get no
>output. Simple experiments failed to get any sound at any other sr.
>
>Has anyone else had this problem? Or eevn better, has anyone any idea
>how thi shappens and how to fix it?
as a coincidence, i happen to be working on the exact same problem. no
answers yet, although i will note that the docs for this opcode are
wrong. the "iatt" argument has no effect on attack time at all, and it
actually named as a decay argument in the opcode structure. the way it
is used has little effect at all. In addition, some fairly important
stuff in brassset() seems to be commented out.
This reminds me of a general observation about the physmod
opcodes. The way they are coded, they cannot be used under MIDI
control, because they assume that the note duration is known. A very
simple change to them all changes this: in the opcode's a-rate
function, instead of :
if (p->kloop > 0 && p->PROCESS->releasing())
p->kloop = 1;
if ((--p->kloop) == 0) {
.... release phase stuff ....
}
you need:
if (p->kloop >= 0 && p->PROCESS->releasing())
p->kloop = 1;
if (p->kloop && (--p->kloop) == 0) {
.... release phase stuff ....
}
Actually, I don't recall if Csound has the convention that I adopted
that a zero duration means "unknown duration - play till told to
turnoff", and this change assumes that this is true.
|