Hi Istvan, Thanks for checking it all out. The second elseif that was redundant was incorrect and should have been: elseif (p3 > 0 && itie == 0) then and that's what I get for working later than I should have! I have been using older if/kgoto's for a while and yesterday had the thought to convert to if/then. The syntax for if/then is so much cleaner to work with and I prefer it very much, but have largely avoided it due to strange bugs. On the other hand, working with if/kgoto was always strange to me as well as it seemed I had to always work with the negated version of what I wanted(if not true, go to this label). I haven't been spending much time inside Csound code lately, but if/then seems like something worth investigating and debugging. Thanks for all the information and help! Very much appreciated (as always!) steven On 5/23/05, Istvan Varga wrote: > Steven Yi wrote: > > > In the example CSD file I have enabled three places where there are > > printk statements, one within the UDO just before the xout output, one > > after the release envelope section of the UDO, and one within the > > calling instrument. When the last note of a set of tied notes is > > reached, the value within the release envelope section of the UDO is > > generating correctly, but the calling instrument does not receive the > > value generated by the UDO, instead receiving 0 value. > > I have been able to fix the error by commenting out the (apparently > redundant) last elseif case; I also added a newline to printks to make > the output more readable: > > elseif (p3 > 0 && itie == 1) then > ; this is an end note out of a group of tied notes > kenv linseg 1, p3 - 1, 1, 1, 0 > > printk .1, kenv > > /* elseif (p3 > 0 && itie == 1) then > ; this is a single note > > ; TODO - Should Remove, use articulation from other places > ;kenv adsr .2, 0, 1, 1 > kenv adsr iattack, idecay, isus, irel > */ > > endif > > endif > > printks "Value before leaving UDO: %f\n", .1, kenv > > I do not know why the last elseif corrupts kenv; it is probably best to > stick with old (and reliable) if...goto style conditionals, as if...endif > seems to have many obscure bugs and Matt Ingalls (author of if/then/else) > does not seem to be interested in Csound5 development. > > > I'm not sure what to make of this. It's strange to me that the printk > > statement within the UDO gives an instrument 203 for it's statement (I > > haven't checked how UDO's are implemented underneath the hood). > > UDO's are really instruments with instrument numbers that cannot be used > directly from the score. I will fix printk to print the real instrument > number (in this case, instr 3) instead of the instrument number of the UDO. > > > It makes me think that's there some kind of strange issue with instrument > > number and processing order. Could it be possible that the UDO is > > processed after the instrument, > > No, UDO's are performed from within the calling instrument, and not independently > from kperf(). > > > print statments seem out of order some how too when in the release > > stage. > > Perhaps printk and printks round time values slightly differently and the > printing from the two different opcodes does not occur in exactly the same > k-period. > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net