Thanks for posting the example. I found a place where it hangs:

B 41.296 .. 41.564 T 41.564 TT 41.564 M:   2263.9   3548.6

this happens in instr 13, line 522:

asignal1    wgpluck2    .1, 1.0, ifrequency, .15, .2

in Opcodes/repluck.c, wgpsetin(), lines 58 to 61:

    while (npts < 512) {        /* Minimum rail length is 256 */
      npts += (int)(csound->esr / *p->icps);
      scale++;
    }

This can be an infinite loop if 'icps' is too high (exceeds the
sample rate). Indeed, according to gdb, *p->icps is 4286473.
The bogus frequency value comes from the 'NoteOn' UDO, which
uses the (recently changed) MIDI interoperability opcodes:

            midinoteonoct p4, p5
inormal     =           ampdb(80)
ifrequency  =           cpsoct(p4)

The note that hangs has the following p-fields:

p1 = 13, p2 = 41.5642509, p3 = 4, p4 = 54, p5 = 45, ...

The p4=54 is obviously out of range for cpsoct(). The problems
are apparently caused by the fact that midinoteonoct no longer
converts the frequency for score notes, and is fixed by adding
the line

p4          =           (p4 / 12) + 3

before the midinoteonoct.

So, it seems the relevant change between 5.01 and 5.02.1 is not
bug introduction in UDOs, but rather the different behavior of
MIDI interoperability opcodes.

On Saturday 17 June 2006 21:24, Michael Gogins wrote:

> Here's the piece for which the orc using UDOs was not working.


_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net