| Here are three broken UDOs that worked in Csound4.
Note that these may have MacCsound info in the .csd that you
might want to coment out to test.
-dr. B.
On Jun 17, 2006, at 5:56 PM, Istvan Varga wrote:
> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel
|