Nested If's in UDO

[Steven Yi]

Hi All,

This is a bit of a strange error I'm having.  In the attached CSD
file, there is a UDO entitled yiEnvelope which I've been trying to
convert to using if/then type statements.  So far it almost works,
except on the release note of set of tied notes.

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'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).  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, but somehow on each kpass the value is
initialized to 0, the instrument runs, then the UDO is computed?  The
print statments seem out of order some how too when in the release
stage.

Anyways, it's late; I hope it's a user-error and I'm simply missing
something at this hour, but if not, any suggestions?

Thanks,
steven

[Istvan Varga]

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Istvan Varga]

Now committed, printk prints the correct instrument number:

  i   3 time    15.35604:     1.00000
Value before leaving UDO: 1.000000
  i   3 time    15.35604:     1.00000
  i   3 time    15.45604:     0.90355
Value before leaving UDO: 0.903549
  i   3 time    15.45604:     0.90355
  i   3 time    15.55604:     0.80356
Value before leaving UDO: 0.803556
  i   3 time    15.55604:     0.80356
etc.


-------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Steven Yi]

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 <[hidden email]> 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
> [hidden email]
> 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!
<a href="http://ads.osdn.com/?ad_idt12&alloc_id344&op=click">http://ads.osdn.com/?ad_idt12&alloc_id344&op=click
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Dr. Richard Boulanger-2]

Steven,

I haven't had anything to offer as far as a solution goes, but I do hope you
will share the finished/corrected version with me/us.

Dr. B.

on 5/23/05 3:32 AM, Steven Yi at [hidden email] wrote:

> Hi All,
>
> This is a bit of a strange error I'm having.  In the attached CSD
> file, there is a UDO entitled yiEnvelope which I've been trying to
> convert to using if/then type statements.  So far it almost works,
> except on the release note of set of tied notes.
>
> 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'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).  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, but somehow on each kpass the value is
> initialized to 0, the instrument runs, then the UDO is computed?  The
> print statments seem out of order some how too when in the release
> stage.
>
> Anyways, it's late; I hope it's a user-error and I'm simply missing
> something at this hour, but if not, any suggestions?
>
> Thanks,
> steven
>

_______________________________________________________________________
 +  Dr. Richard Boulanger, Professor
 +  Music Synthesis Department, Berklee College of Music
 +  1140 Boylston Street  - Boston, MA  02215-3693
 +  Office Phone: [phone]   Office Fax: [phone]
 +  eMail: [hidden email] or [hidden email]
 +  WebPage: http://csounds.com/boulanger/
________________________________________________________________________
 +  Almost Everything Csound @ http://csounds.com/
 +  The Csound Instrument Catalog @ http://csounds.com/catalog/
 +  The Csound Book @ http://csounds.com/book/
 +  The Csound Magazine @ http://csounds.com/ezine/
 +  The MacCsound, CsoundAV & CsoundVST Forums @ http://csounds.com/phpBB2/
________________________________________________________________________



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Steven Yi]

Hi Dr. B,

The conclusion to this was resolved a couple of days ago (I think it
was on a different email thread). We found where the problem was and
Istvan put in a fix, so nested if/then's are working out just fine now
in CS5.

steven


On 5/27/05, Richard Boulanger <[hidden email]> wrote:

> Steven,
>
> I haven't had anything to offer as far as a solution goes, but I do hope you
> will share the finished/corrected version with me/us.
>
> Dr. B.
>
> on 5/23/05 3:32 AM, Steven Yi at [hidden email] wrote:
>
> > Hi All,
> >
> > This is a bit of a strange error I'm having.  In the attached CSD
> > file, there is a UDO entitled yiEnvelope which I've been trying to
> > convert to using if/then type statements.  So far it almost works,
> > except on the release note of set of tied notes.
> >
> > 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'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).  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, but somehow on each kpass the value is
> > initialized to 0, the instrument runs, then the UDO is computed?  The
> > print statments seem out of order some how too when in the release
> > stage.
> >
> > Anyways, it's late; I hope it's a user-error and I'm simply missing
> > something at this hour, but if not, any suggestions?
> >
> > Thanks,
> > steven
> >
>
> _______________________________________________________________________
>  +  Dr. Richard Boulanger, Professor
>  +  Music Synthesis Department, Berklee College of Music
>  +  1140 Boylston Street  - Boston, MA  02215-3693
>  +  Office Phone: [phone]   Office Fax: [phone]
>  +  eMail: [hidden email] or [hidden email]
>  +  WebPage: http://csounds.com/boulanger/
> ________________________________________________________________________
>  +  Almost Everything Csound @ http://csounds.com/
>  +  The Csound Instrument Catalog @ http://csounds.com/catalog/
>  +  The Csound Book @ http://csounds.com/book/
>  +  The Csound Magazine @ http://csounds.com/ezine/
>  +  The MacCsound, CsoundAV & CsoundVST Forums @ http://csounds.com/phpBB2/
> ________________________________________________________________________
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Csound-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

[Dr. Richard Boulanger-2]

Please share the new working instrument with us!

Dr. B.

on 5/27/05 11:39 PM, Steven Yi at [hidden email] wrote:

> Hi Dr. B,
>
> The conclusion to this was resolved a couple of days ago (I think it
> was on a different email thread). We found where the problem was and
> Istvan put in a fix, so nested if/then's are working out just fine now
> in CS5.
>
> steven
>
>
> On 5/27/05, Richard Boulanger <[hidden email]> wrote:
>> Steven,
>>
>> I haven't had anything to offer as far as a solution goes, but I do hope you
>> will share the finished/corrected version with me/us.
>>
>> Dr. B.
>>
>> on 5/23/05 3:32 AM, Steven Yi at [hidden email] wrote:
>>
>>> Hi All,
>>>
>>> This is a bit of a strange error I'm having.  In the attached CSD
>>> file, there is a UDO entitled yiEnvelope which I've been trying to
>>> convert to using if/then type statements.  So far it almost works,
>>> except on the release note of set of tied notes.
>>>
>>> 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'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).  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, but somehow on each kpass the value is
>>> initialized to 0, the instrument runs, then the UDO is computed?  The
>>> print statments seem out of order some how too when in the release
>>> stage.
>>>
>>> Anyways, it's late; I hope it's a user-error and I'm simply missing
>>> something at this hour, but if not, any suggestions?
>>>
>>> Thanks,
>>> steven
>>>
>>
>> _______________________________________________________________________
>>  +  Dr. Richard Boulanger, Professor
>>  +  Music Synthesis Department, Berklee College of Music
>>  +  1140 Boylston Street  - Boston, MA  02215-3693
>>  +  Office Phone: [phone]   Office Fax: [phone]
>>  +  eMail: [hidden email] or [hidden email]
>>  +  WebPage: http://csounds.com/boulanger/
>> ________________________________________________________________________
>>  +  Almost Everything Csound @ http://csounds.com/
>>  +  The Csound Instrument Catalog @ http://csounds.com/catalog/
>>  +  The Csound Book @ http://csounds.com/book/
>>  +  The Csound Magazine @ http://csounds.com/ezine/
>>  +  The MacCsound, CsoundAV & CsoundVST Forums @ http://csounds.com/phpBB2/
>> ________________________________________________________________________
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by Yahoo.
>> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
>> Search APIs Find out how you can build Yahoo! directly into your own
>> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
>> _______________________________________________
>> Csound-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Csound-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel

_______________________________________________________________________
 +  Dr. Richard Boulanger, Professor
 +  Music Synthesis Department, Berklee College of Music
 +  1140 Boylston Street  - Boston, MA  02215-3693
 +  Office Phone: [phone]   Office Fax: [phone]
 +  eMail: [hidden email] or [hidden email]
 +  WebPage: http://csounds.com/boulanger/
________________________________________________________________________
 +  Almost Everything Csound @ http://csounds.com/
 +  The Csound Instrument Catalog @ http://csounds.com/catalog/
 +  The Csound Book @ http://csounds.com/book/
 +  The Csound Magazine @ http://csounds.com/ezine/
 +  The MacCsound, CsoundAV & CsoundVST Forums @ http://csounds.com/phpBB2/
________________________________________________________________________



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel