i() behavior on PC / Mac
Locked
12
12
i() behavior on PC / Mac
 
|
Dear list and developers,
I’ve encountered a csd file made by a friend, that uses a massive amount of i() casting with expression arguments, like this: gitable ftgen 1, 0, 16, -2, i(gka + gkb), i(gkc * .5 + gkd), etc... The file is somehow force-compiled and runs ok on Mac version of csound 5.15f, only with this message: “WARNING: i() should not be used with expression argument” However, it fails to compile on Windows 7 & csound 5.15d with the same warning sign but as an “error.” I guess these behaviors depend on the platform, but it could be the difference between the float and double. (I cannot test both right now...) Anyway, is there by any chance these behaviors will be addressed and changed in the future versions? Or should I just tell my friend to fix all the i()’s not to include math expressions? Takahiko ; example code <CsoundSynthesizer> <CsOptions> </CsOptions> <CsInstruments> sr = 44100 ksmps = 2 instr 1 gka init 1 gkb init 1 gkc init 1 gkd init 1 gke init 1 gkf init 1 endin instr 2 gitable ftgen 1, 0, 4, -2, i(gka), i(gkb + gkc), i(gkd * .5 + gke), i(gkf) endin </CsInstruments> <CsScore> f0 1000 </CsScore> </CsoundSynthesizer> Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email [hidden email] with body "unsubscribe csound" |
|
hi takahiko -
just to cite the manual (http://www.csounds.com/manual/html/opi.html): "Using i() with a k-rate expression argument is not recommended, and can produce unexpected results." seems to be true ... joachim Am 27.01.2012 18:42, schrieb Takahiko Tsuchiya: > Dear list and developers, > > I’ve encountered a csd file made by a friend, that uses a massive amount of i() casting with expression arguments, like this: > > gitable ftgen 1, 0, 16, -2, i(gka + gkb), i(gkc * .5 + gkd), etc... > > The file is somehow force-compiled and runs ok on Mac version of csound 5.15f, only with this message: > > “WARNING: i() should not be used with expression argument” > > However, it fails to compile on Windows 7 & csound 5.15d with the same warning sign but as an “error.” > > I guess these behaviors depend on the platform, but it could be the difference between the float and double. (I cannot test both right now...) Anyway, is there by any chance these behaviors will be addressed and changed in the future versions? Or should I just tell my friend to fix all the i()’s not to include math expressions? > > Takahiko > > > ; example code > <CsoundSynthesizer> > <CsOptions> > </CsOptions> > <CsInstruments> > sr = 44100 > ksmps = 2 > instr 1 > gka init 1 > gkb init 1 > gkc init 1 > gkd init 1 > gke init 1 > gkf init 1 > endin > instr 2 > gitable ftgen 1, 0, 4, -2, i(gka), i(gkb + gkc), i(gkd * .5 + gke), i(gkf) > endin > </CsInstruments> > <CsScore> > f0 1000 > </CsScore> > </CsoundSynthesizer> > > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email [hidden email] with body "unsubscribe csound" > > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email [hidden email] with body "unsubscribe csound" |
Re: i() behavior on PC / Mac
|
Is there a way to make this work/possible without more complex reinit designs?
___________________________________ Dr. Richard Boulanger, Ph.D. Professor of Electronic Production and Design Professional Writing and Music Technology Division Berklee College of Music 1140 Boylston Street Boston, MA 02215-3693 617-747-2485 (office) 774-488-9166 (cell) ____________________________________ ____________________________________ ____________________________________ On Jan 27, 2012, at 3:11 PM, joachim heintz wrote:
|
Re: i() behavior on PC / Mac
|
It works (5.15 single and double float, gnu/linux)
gitable ftgen 1, 0, 4, -2, i(gka), i(gkb) + i(gkc), i(gkd) * .5 + i(gke), i(gkf) Tomorrow I can try to see if there is an alternative tito Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email [hidden email] with body "unsubscribe csound" |
Re: i() behavior on PC / Mac
|
|
Hi Joachim and Tito,
Thanks for the comments and the solution idea. Also good to know the behavior on GNU/Linux too. Seems I may have to tell the coder to fix them manually... it's just that there are dozens of them. Takahiko On Jan 27, 2012, at 4:38 PM, Tito Latini wrote: > It works (5.15 single and double float, gnu/linux) > > gitable ftgen 1, 0, 4, -2, i(gka), i(gkb) + i(gkc), i(gkd) * .5 + i(gke), i(gkf) > > Tomorrow I can try to see if there is an alternative > > tito > > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email [hidden email] with body "unsubscribe csound" > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email [hidden email] with body "unsubscribe csound" |
Re: i() behavior on PC / Mac
|
The CSD is being "force"-compiled with the --no-expression-opt option.
This option makes it possible to write i(ka+kb) expressions although I personally don't use these. On 1/27/12, Takahiko Tsuchiya <[hidden email]> wrote: > Hi Joachim and Tito, > > Thanks for the comments and the solution idea. Also good to know the > behavior on GNU/Linux too. > Seems I may have to tell the coder to fix them manually... it's just that > there are dozens of them. > > Takahiko > > > On Jan 27, 2012, at 4:38 PM, Tito Latini wrote: > >> It works (5.15 single and double float, gnu/linux) >> >> gitable ftgen 1, 0, 4, -2, i(gka), i(gkb) + i(gkc), i(gkd) * .5 + i(gke), >> i(gkf) >> >> Tomorrow I can try to see if there is an alternative >> >> tito >> >> >> Send bugs reports to the Sourceforge bug tracker >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> Discussions of bugs and features can be posted here >> To unsubscribe, send email [hidden email] with body "unsubscribe >> csound" >> > > > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email [hidden email] with body "unsubscribe > csound" > > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email [hidden email] with body "unsubscribe csound" |
Re: i() behavior on PC / Mac
|
|
Hi Adam,
I checked and it did force-compile the csd on Windows. I agree it's not recommended, but saved us a huge amount of time in this case. Thanks a lot. Takahiko On Jan 28, 2012, at 1:29 PM, Adam Puckett wrote: > The CSD is being "force"-compiled with the --no-expression-opt option. > This option makes it possible to write i(ka+kb) expressions although I > personally don't use these. > > On 1/27/12, Takahiko Tsuchiya <[hidden email]> wrote: >> Hi Joachim and Tito, >> >> Thanks for the comments and the solution idea. Also good to know the >> behavior on GNU/Linux too. >> Seems I may have to tell the coder to fix them manually... it's just that >> there are dozens of them. >> >> Takahiko >> >> >> On Jan 27, 2012, at 4:38 PM, Tito Latini wrote: >> >>> It works (5.15 single and double float, gnu/linux) >>> >>> gitable ftgen 1, 0, 4, -2, i(gka), i(gkb) + i(gkc), i(gkd) * .5 + i(gke), >>> i(gkf) >>> >>> Tomorrow I can try to see if there is an alternative >>> >>> tito >>> >>> >>> Send bugs reports to the Sourceforge bug tracker >>> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >>> Discussions of bugs and features can be posted here >>> To unsubscribe, send email [hidden email] with body "unsubscribe >>> csound" >>> >> >> >> >> Send bugs reports to the Sourceforge bug tracker >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> Discussions of bugs and features can be posted here >> To unsubscribe, send email [hidden email] with body "unsubscribe >> csound" >> >> > > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email [hidden email] with body "unsubscribe csound" > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email [hidden email] with body "unsubscribe csound" |
Re: i() behavior on PC / Mac
|
|
I think maybe something you didn't realize is the fact that Csound can
take a .csoundrc file, which your friend may have modified or put one in the current tirectory, and since you didn't say anything about a .csoundrc file, chances are the original wwas modified or replaced unless Csound defaults to --no-expression-opt, which I don't think is the case. On 1/28/12, Takahiko Tsuchiya <[hidden email]> wrote: > Hi Adam, > > I checked and it did force-compile the csd on Windows. I agree it's not > recommended, but saved us a huge amount of time in this case. Thanks a lot. > > Takahiko > > > On Jan 28, 2012, at 1:29 PM, Adam Puckett wrote: > >> The CSD is being "force"-compiled with the --no-expression-opt option. >> This option makes it possible to write i(ka+kb) expressions although I >> personally don't use these. >> >> On 1/27/12, Takahiko Tsuchiya <[hidden email]> wrote: >>> Hi Joachim and Tito, >>> >>> Thanks for the comments and the solution idea. Also good to know the >>> behavior on GNU/Linux too. >>> Seems I may have to tell the coder to fix them manually... it's just that >>> there are dozens of them. >>> >>> Takahiko >>> >>> >>> On Jan 27, 2012, at 4:38 PM, Tito Latini wrote: >>> >>>> It works (5.15 single and double float, gnu/linux) >>>> >>>> gitable ftgen 1, 0, 4, -2, i(gka), i(gkb) + i(gkc), i(gkd) * .5 + >>>> i(gke), >>>> i(gkf) >>>> >>>> Tomorrow I can try to see if there is an alternative >>>> >>>> tito >>>> >>>> >>>> Send bugs reports to the Sourceforge bug tracker >>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >>>> Discussions of bugs and features can be posted here >>>> To unsubscribe, send email [hidden email] with body "unsubscribe >>>> csound" >>>> >>> >>> >>> >>> Send bugs reports to the Sourceforge bug tracker >>> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >>> Discussions of bugs and features can be posted here >>> To unsubscribe, send email [hidden email] with body "unsubscribe >>> csound" >>> >>> >> >> >> Send bugs reports to the Sourceforge bug tracker >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> Discussions of bugs and features can be posted here >> To unsubscribe, send email [hidden email] with body "unsubscribe >> csound" >> > > > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email [hidden email] with body "unsubscribe > csound" > > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email [hidden email] with body "unsubscribe csound" |
Re: i() behavior on PC / Mac
|
|
There was no .csoundrc file included in the current directory. And I have not modified them on my PC / Mac. It might actually be the that the default option of "expression optimiztion" in Windows version of Csound differs from the others?
Takahiko On Jan 28, 2012, at 3:14 PM, Adam Puckett wrote: > I think maybe something you didn't realize is the fact that Csound can > take a .csoundrc file, which your friend may have modified or put one > in the current tirectory, and since you didn't say anything about a > .csoundrc file, chances are the original wwas modified or replaced > unless Csound defaults to --no-expression-opt, which I don't think is > the case. > > On 1/28/12, Takahiko Tsuchiya <[hidden email]> wrote: >> Hi Adam, >> >> I checked and it did force-compile the csd on Windows. I agree it's not >> recommended, but saved us a huge amount of time in this case. Thanks a lot. >> >> Takahiko >> >> >> On Jan 28, 2012, at 1:29 PM, Adam Puckett wrote: >> >>> The CSD is being "force"-compiled with the --no-expression-opt option. >>> This option makes it possible to write i(ka+kb) expressions although I >>> personally don't use these. >>> >>> On 1/27/12, Takahiko Tsuchiya <[hidden email]> wrote: >>>> Hi Joachim and Tito, >>>> >>>> Thanks for the comments and the solution idea. Also good to know the >>>> behavior on GNU/Linux too. >>>> Seems I may have to tell the coder to fix them manually... it's just that >>>> there are dozens of them. >>>> >>>> Takahiko >>>> >>>> >>>> On Jan 27, 2012, at 4:38 PM, Tito Latini wrote: >>>> >>>>> It works (5.15 single and double float, gnu/linux) >>>>> >>>>> gitable ftgen 1, 0, 4, -2, i(gka), i(gkb) + i(gkc), i(gkd) * .5 + >>>>> i(gke), >>>>> i(gkf) >>>>> >>>>> Tomorrow I can try to see if there is an alternative >>>>> >>>>> tito >>>>> >>>>> >>>>> Send bugs reports to the Sourceforge bug tracker >>>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >>>>> Discussions of bugs and features can be posted here >>>>> To unsubscribe, send email [hidden email] with body "unsubscribe >>>>> csound" >>>>> >>>> >>>> >>>> >>>> Send bugs reports to the Sourceforge bug tracker >>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >>>> Discussions of bugs and features can be posted here >>>> To unsubscribe, send email [hidden email] with body "unsubscribe >>>> csound" >>>> >>>> >>> >>> >>> Send bugs reports to the Sourceforge bug tracker >>> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >>> Discussions of bugs and features can be posted here >>> To unsubscribe, send email [hidden email] with body "unsubscribe >>> csound" >>> >> >> >> >> Send bugs reports to the Sourceforge bug tracker >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> Discussions of bugs and features can be posted here >> To unsubscribe, send email [hidden email] with body "unsubscribe >> csound" >> >> > > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email [hidden email] with body "unsubscribe csound" > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email [hidden email] with body "unsubscribe csound" |
Re: i() behavior on PC / Mac
|
|
In reply to this post by Takahiko TSUCHIYA
fixed in git; Takahiko, here is your example + some extravagance
<CsoundSynthesizer> <CsOptions> </CsOptions> <CsInstruments> sr = 44100 ksmps = 2 instr 1 gka init 1 gkb init 1 gkc init 1 gkd init 1 gke init 1 gkf init 1 gkg init 10 gkh init 100 gki init -123 endin instr 2 gitable ftgen 1, 0, 4, -2, i(gka), i(gkb + gkc), i(gkd * .5 + gke), i(gkf) print i(gkb + gkc) print i(gkd * .5 + gke) print i(gkd * .5 + gke + abs(gki * 2 / 3) + sin(gkg / 3.33 + p3) * gkh) endin </CsInstruments> <CsScore> i1 0 .1 i2 0 .1 </CsScore> </CsoundSynthesizer> csound -g test.csd ... ftable 1: 4 points, scalemax 2.000 _ - _ _ instr 2: #i11 = 2.000 instr 2: #i15 = 1.500 instr 2: #i31 = 87.358 ... tito Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email [hidden email] with body "unsubscribe csound" |
Re: i() behavior on PC / Mac
|
Hi,
I think this is an interesting issue which begs the question, should opcodes that modify k-rate vairables always make the first value available during the init-pass? If they do, and it's considered a bug not to, it would be very convenient and it would avoid a lot of unexpected behavior with if-thens and reinits, however, It can also be problematic performance wise to have to run a control pass as part of initialization. I recently spent a long while trying to debug a problem due to this, so specifying a default behavior, and an easy way to know whether a control-rate opcode updates the k-variables during the init pass would be great! What do you all think? Cheers, Andrés On Sun, Jan 29, 2012 at 11:02 AM, Tito Latini <[hidden email]> wrote: > fixed in git; Takahiko, here is your example + some extravagance > > <CsoundSynthesizer> > <CsOptions> > </CsOptions> > <CsInstruments> > sr = 44100 > ksmps = 2 > instr 1 > gka init 1 > gkb init 1 > gkc init 1 > gkd init 1 > gke init 1 > gkf init 1 > gkg init 10 > gkh init 100 > gki init -123 > endin > instr 2 > gitable ftgen 1, 0, 4, -2, i(gka), i(gkb + gkc), i(gkd * .5 + gke), i(gkf) > > print i(gkb + gkc) > print i(gkd * .5 + gke) > print i(gkd * .5 + gke + abs(gki * 2 / 3) + sin(gkg / 3.33 + p3) * gkh) > endin > </CsInstruments> > <CsScore> > i1 0 .1 > i2 0 .1 > </CsScore> > </CsoundSynthesizer> > > csound -g test.csd > ... > ftable 1: 4 points, scalemax 2.000 > _ > > > - > > _ _ > instr 2: #i11 = 2.000 > instr 2: #i15 = 1.500 > instr 2: #i31 = 87.358 > ... > > tito > > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email [hidden email] with body "unsubscribe csound" > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email [hidden email] with body "unsubscribe csound" |
|
I think thta the i operator should take constants, i-rate objects and
global k-rate variables. Actually would prefer it not to take expressions, just variables but I doubt that would be popular. I seem to remember I did not like the i() form when it was introduced because of these oddities ==John ff > Hi, > > I think this is an interesting issue which begs the question, should > opcodes that modify k-rate vairables always make the first value > available during the init-pass? > > If they do, and it's considered a bug not to, it would be very > convenient and it would avoid a lot of unexpected behavior with > if-thens and reinits, however, It can also be problematic performance > wise to have to run a control pass as part of initialization. > > I recently spent a long while trying to debug a problem due to this, > so specifying a default behavior, and an easy > way to know whether a control-rate opcode updates the k-variables > during the init pass would be great! > > What do you all think? > > Cheers, > Andrés > > On Sun, Jan 29, 2012 at 11:02 AM, Tito Latini <[hidden email]> > wrote: >> fixed in git; Takahiko, here is your example + some extravagance >> >> <CsoundSynthesizer> >> <CsOptions> >> </CsOptions> >> <CsInstruments> >> sr = 44100 >> ksmps = 2 >> instr 1 >> gka init 1 >> gkb init 1 >> gkc init 1 >> gkd init 1 >> gke init 1 >> gkf init 1 >> gkg init 10 >> gkh init 100 >> gki init -123 >> endin >> instr 2 >> gitable ftgen 1, 0, 4, -2, i(gka), i(gkb + gkc), i(gkd * .5 + gke), >> i(gkf) >> >> print i(gkb + gkc) >> print i(gkd * .5 + gke) >> print i(gkd * .5 + gke + abs(gki * 2 / 3) + sin(gkg / 3.33 + p3) * gkh) >> endin >> </CsInstruments> >> <CsScore> >> i1 0 .1 >> i2 0 .1 >> </CsScore> >> </CsoundSynthesizer> >> >> csound -g test.csd >> ... >> ftable 1:    4 points, scalemax 2.000 >>  _ >> >> >>  - >> >> _  _ >> instr 2:  #i11 = 2.000 >> instr 2:  #i15 = 1.500 >> instr 2:  #i31 = 87.358 >> ... >> >> tito >> >> >> Send bugs reports to the Sourceforge bug tracker >>      >>  https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> Discussions of bugs and features can be posted here >> To unsubscribe, send email [hidden email] with body "unsubscribe >> csound" >> > > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email [hidden email] with body "unsubscribe > csound" > > > > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email [hidden email] with body "unsubscribe csound" |
Re: i() behavior on PC / Mac
|
|
Now, i() with krate operations is syntactic sugar. Internally
i(num) -> num i(ivar) -> ivar i(pN) -> pN i(kvar) -> i(kvar) i(fn(x)) -> fn(i(x)) the example i(gkd * .5 + gke + abs(gki * 2 / 3) + sin(gkg / 3.33 + p3) * gkh) internally becomes i(gkd) * .5 + i(gke) + abs(i(gki)*2/3) + sin(i(gkg)/3.33 + p3) * i(gkh) The user uses expressions and csound see const, ivar and kvar. The limit is gone On Sun, Jan 29, 2012 at 01:44:37PM -0000, [hidden email] wrote: > I think thta the i operator should take constants, i-rate objects and > global k-rate variables. Actually would prefer it not to take > expressions, just variables but I doubt that would be popular. I seem to > remember I did not like the i() form when it was introduced because of > these oddities > ==John ff > > > Hi, > > > > I think this is an interesting issue which begs the question, should > > opcodes that modify k-rate vairables always make the first value > > available during the init-pass? > > > > If they do, and it's considered a bug not to, it would be very > > convenient and it would avoid a lot of unexpected behavior with > > if-thens and reinits, however, It can also be problematic performance > > wise to have to run a control pass as part of initialization. > > > > I recently spent a long while trying to debug a problem due to this, > > so specifying a default behavior, and an easy > > way to know whether a control-rate opcode updates the k-variables > > during the init pass would be great! > > > > What do you all think? > > > > Cheers, > > Andrés > > > > On Sun, Jan 29, 2012 at 11:02 AM, Tito Latini <[hidden email]> > > wrote: > >> fixed in git; Takahiko, here is your example + some extravagance > >> > >> <CsoundSynthesizer> > >> <CsOptions> > >> </CsOptions> > >> <CsInstruments> > >> sr = 44100 > >> ksmps = 2 > >> instr 1 > >> gka init 1 > >> gkb init 1 > >> gkc init 1 > >> gkd init 1 > >> gke init 1 > >> gkf init 1 > >> gkg init 10 > >> gkh init 100 > >> gki init -123 > >> endin > >> instr 2 > >> gitable ftgen 1, 0, 4, -2, i(gka), i(gkb + gkc), i(gkd * .5 + gke), > >> i(gkf) > >> > >> print i(gkb + gkc) > >> print i(gkd * .5 + gke) > >> print i(gkd * .5 + gke + abs(gki * 2 / 3) + sin(gkg / 3.33 + p3) * gkh) > >> endin > >> </CsInstruments> > >> <CsScore> > >> i1 0 .1 > >> i2 0 .1 > >> </CsScore> > >> </CsoundSynthesizer> > >> > >> csound -g test.csd > >> ... > >> ftable 1:    4 points, scalemax 2.000 > >>  _ > >> > >> > >>  - > >> > >> _  _ > >> instr 2:  #i11 = 2.000 > >> instr 2:  #i15 = 1.500 > >> instr 2:  #i31 = 87.358 > >> ... > >> > >> tito > >> > >> > >> Send bugs reports to the Sourceforge bug tracker > >>      > >>  https://sourceforge.net/tracker/?group_id=81968&atid=564599 > >> Discussions of bugs and features can be posted here > >> To unsubscribe, send email [hidden email] with body "unsubscribe > >> csound" > >> > > > > > > Send bugs reports to the Sourceforge bug tracker > > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > > Discussions of bugs and features can be posted here > > To unsubscribe, send email [hidden email] with body "unsubscribe > > csound" > > > > > > > > > > > > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email [hidden email] with body "unsubscribe csound" Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email [hidden email] with body "unsubscribe csound" |
|
I think we would have to be very careful to document this in detail.
It's a bit of syntax magic (like, i(f(n)) becomes f(i(n)) is sort of mindbending :P). On Sun, Jan 29, 2012 at 9:51 AM, Tito Latini <[hidden email]> wrote: > Now, i() with krate operations is syntactic sugar. Internally > > i(num) -> num > i(ivar) -> ivar > i(pN) -> pN > i(kvar) -> i(kvar) > i(fn(x)) -> fn(i(x)) > > the example > > i(gkd * .5 + gke + abs(gki * 2 / 3) + sin(gkg / 3.33 + p3) * gkh) > > internally becomes > > i(gkd) * .5 + i(gke) + abs(i(gki)*2/3) + sin(i(gkg)/3.33 + p3) * i(gkh) > > The user uses expressions and csound see const, ivar and kvar. The limit is gone > > On Sun, Jan 29, 2012 at 01:44:37PM -0000, [hidden email] wrote: >> I think thta the i operator should take constants, i-rate objects and >> global k-rate variables. Actually would prefer it not to take >> expressions, just variables but I doubt that would be popular. I seem to >> remember I did not like the i() form when it was introduced because of >> these oddities >> ==John ff >> >> > Hi, >> > >> > I think this is an interesting issue which begs the question, should >> > opcodes that modify k-rate vairables always make the first value >> > available during the init-pass? >> > >> > If they do, and it's considered a bug not to, it would be very >> > convenient and it would avoid a lot of unexpected behavior with >> > if-thens and reinits, however, It can also be problematic performance >> > wise to have to run a control pass as part of initialization. >> > >> > I recently spent a long while trying to debug a problem due to this, >> > so specifying a default behavior, and an easy >> > way to know whether a control-rate opcode updates the k-variables >> > during the init pass would be great! >> > >> > What do you all think? >> > >> > Cheers, >> > Andrés >> > >> > On Sun, Jan 29, 2012 at 11:02 AM, Tito Latini <[hidden email]> >> > wrote: >> >> fixed in git; Takahiko, here is your example + some extravagance >> >> >> >> <CsoundSynthesizer> >> >> <CsOptions> >> >> </CsOptions> >> >> <CsInstruments> >> >> sr = 44100 >> >> ksmps = 2 >> >> instr 1 >> >> gka init 1 >> >> gkb init 1 >> >> gkc init 1 >> >> gkd init 1 >> >> gke init 1 >> >> gkf init 1 >> >> gkg init 10 >> >> gkh init 100 >> >> gki init -123 >> >> endin >> >> instr 2 >> >> gitable ftgen 1, 0, 4, -2, i(gka), i(gkb + gkc), i(gkd * .5 + gke), >> >> i(gkf) >> >> >> >> print i(gkb + gkc) >> >> print i(gkd * .5 + gke) >> >> print i(gkd * .5 + gke + abs(gki * 2 / 3) + sin(gkg / 3.33 + p3) * gkh) >> >> endin >> >> </CsInstruments> >> >> <CsScore> >> >> i1 0 .1 >> >> i2 0 .1 >> >> </CsScore> >> >> </CsoundSynthesizer> >> >> >> >> csound -g test.csd >> >> ... >> >> ftable 1: 4 points, scalemax 2.000 >> >> _ >> >> >> >> >> >> - >> >> >> >> _ _ >> >> instr 2: #i11 = 2.000 >> >> instr 2: #i15 = 1.500 >> >> instr 2: #i31 = 87.358 >> >> ... >> >> >> >> tito >> >> >> >> >> >> Send bugs reports to the Sourceforge bug tracker >> >> >> >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> >> Discussions of bugs and features can be posted here >> >> To unsubscribe, send email [hidden email] with body "unsubscribe >> >> csound" >> >> >> > >> > >> > Send bugs reports to the Sourceforge bug tracker >> > https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> > Discussions of bugs and features can be posted here >> > To unsubscribe, send email [hidden email] with body "unsubscribe >> > csound" >> > >> > >> > >> > >> >> >> >> >> Send bugs reports to the Sourceforge bug tracker >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> Discussions of bugs and features can be posted here >> To unsubscribe, send email [hidden email] with body "unsubscribe csound" > > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email [hidden email] with body "unsubscribe csound" > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email [hidden email] with body "unsubscribe csound" |
Re: i() behavior on PC / Mac
|
|
On the same idea, would it be worth having:
ifi and ifk so the user can make sure the expressions are being evaluated as he expects? Cheers, Andrés On Sun, Jan 29, 2012 at 3:44 PM, Steven Yi <[hidden email]> wrote: I think we would have to be very careful to document this in detail. |
|
|
There already is if-ithen and if-kthen, or at least, there used to be.
On Mon, Jan 30, 2012 at 10:37 AM, Andres Cabrera <[hidden email]> wrote: > On the same idea, would it be worth having: > > ifi and ifk so the user can make sure the expressions are being evaluated as > he expects? > > Cheers, > Andrés > > > On Sun, Jan 29, 2012 at 3:44 PM, Steven Yi <[hidden email]> wrote: >> >> I think we would have to be very careful to document this in detail. >> It's a bit of syntax magic (like, i(f(n)) becomes f(i(n)) is sort of >> mindbending :P). >> >> On Sun, Jan 29, 2012 at 9:51 AM, Tito Latini <[hidden email]> >> wrote: >> > Now, i() with krate operations is syntactic sugar. Internally >> > >> > i(num) -> num >> > i(ivar) -> ivar >> > i(pN) -> pN >> > i(kvar) -> i(kvar) >> > i(fn(x)) -> fn(i(x)) >> > >> > the example >> > >> > i(gkd * .5 + gke + abs(gki * 2 / 3) + sin(gkg / 3.33 + p3) * gkh) >> > >> > internally becomes >> > >> > i(gkd) * .5 + i(gke) + abs(i(gki)*2/3) + sin(i(gkg)/3.33 + p3) * i(gkh) >> > >> > The user uses expressions and csound see const, ivar and kvar. The limit >> > is gone >> > >> > On Sun, Jan 29, 2012 at 01:44:37PM -0000, [hidden email] wrote: >> >> I think thta the i operator should take constants, i-rate objects and >> >> global k-rate variables. Actually would prefer it not to take >> >> expressions, just variables but I doubt that would be popular. I seem >> >> to >> >> remember I did not like the i() form when it was introduced because of >> >> these oddities >> >> ==John ff >> >> >> >> > Hi, >> >> > >> >> > I think this is an interesting issue which begs the question, should >> >> > opcodes that modify k-rate vairables always make the first value >> >> > available during the init-pass? >> >> > >> >> > If they do, and it's considered a bug not to, it would be very >> >> > convenient and it would avoid a lot of unexpected behavior with >> >> > if-thens and reinits, however, It can also be problematic performance >> >> > wise to have to run a control pass as part of initialization. >> >> > >> >> > I recently spent a long while trying to debug a problem due to this, >> >> > so specifying a default behavior, and an easy >> >> > way to know whether a control-rate opcode updates the k-variables >> >> > during the init pass would be great! >> >> > >> >> > What do you all think? >> >> > >> >> > Cheers, >> >> > Andrés >> >> > >> >> > On Sun, Jan 29, 2012 at 11:02 AM, Tito Latini <[hidden email]> >> >> > wrote: >> >> >> fixed in git; Takahiko, here is your example + some extravagance >> >> >> >> >> >> <CsoundSynthesizer> >> >> >> <CsOptions> >> >> >> </CsOptions> >> >> >> <CsInstruments> >> >> >> sr = 44100 >> >> >> ksmps = 2 >> >> >> instr 1 >> >> >> gka init 1 >> >> >> gkb init 1 >> >> >> gkc init 1 >> >> >> gkd init 1 >> >> >> gke init 1 >> >> >> gkf init 1 >> >> >> gkg init 10 >> >> >> gkh init 100 >> >> >> gki init -123 >> >> >> endin >> >> >> instr 2 >> >> >> gitable ftgen 1, 0, 4, -2, i(gka), i(gkb + gkc), i(gkd * .5 + gke), >> >> >> i(gkf) >> >> >> >> >> >> print i(gkb + gkc) >> >> >> print i(gkd * .5 + gke) >> >> >> print i(gkd * .5 + gke + abs(gki * 2 / 3) + sin(gkg / 3.33 + p3) * >> >> >> gkh) >> >> >> endin >> >> >> </CsInstruments> >> >> >> <CsScore> >> >> >> i1 0 .1 >> >> >> i2 0 .1 >> >> >> </CsScore> >> >> >> </CsoundSynthesizer> >> >> >> >> >> >> csound -g test.csd >> >> >> ... >> >> >> ftable 1: 4 points, scalemax 2.000 >> >> >> _ >> >> >> >> >> >> >> >> >> - >> >> >> >> >> >> _ _ >> >> >> instr 2: #i11 = 2.000 >> >> >> instr 2: #i15 = 1.500 >> >> >> instr 2: #i31 = 87.358 >> >> >> ... >> >> >> >> >> >> tito >> >> >> >> >> >> >> >> >> Send bugs reports to the Sourceforge bug tracker >> >> >> >> >> >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> >> >> Discussions of bugs and features can be posted here >> >> >> To unsubscribe, send email [hidden email] with body >> >> >> "unsubscribe >> >> >> csound" >> >> >> >> >> > >> >> > >> >> > Send bugs reports to the Sourceforge bug tracker >> >> > >> >> > https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> >> > Discussions of bugs and features can be posted here >> >> > To unsubscribe, send email [hidden email] with body >> >> > "unsubscribe >> >> > csound" >> >> > >> >> > >> >> > >> >> > >> >> >> >> >> >> >> >> >> >> Send bugs reports to the Sourceforge bug tracker >> >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> >> Discussions of bugs and features can be posted here >> >> To unsubscribe, send email [hidden email] with body >> >> "unsubscribe csound" >> > >> > >> > Send bugs reports to the Sourceforge bug tracker >> > https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> > Discussions of bugs and features can be posted here >> > To unsubscribe, send email [hidden email] with body "unsubscribe >> > csound" >> > >> >> >> Send bugs reports to the Sourceforge bug tracker >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> Discussions of bugs and features can be posted here >> To unsubscribe, send email [hidden email] with body "unsubscribe >> csound" >> > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email [hidden email] with body "unsubscribe csound" |
Re: i() behavior on PC / Mac
|
|
Hi Steven,
But that applies to the branching, not to the evaluation of expressions, doesn't it? Cheers, Andrés On Mon, Jan 30, 2012 at 3:40 PM, Steven Yi <[hidden email]> wrote: There already is if-ithen and if-kthen, or at least, there used to be. |
|
|
The evaluation of the expression is dependent on what's being
compared. If I remember correctly, there's a b and a B type internally, and the latter is at k-rate. So if you do "kval == ival", that see that there's at least one krate arg, and that == returns a B type, while "ival == ival2" would return a b type. So the if-kthen can be used to force krate branching, even if the boolean expression evaluates out to a b type. On Mon, Jan 30, 2012 at 10:44 AM, Andres Cabrera <[hidden email]> wrote: > Hi Steven, > > But that applies to the branching, not to the evaluation of expressions, > doesn't it? > > Cheers, > Andrés > > > On Mon, Jan 30, 2012 at 3:40 PM, Steven Yi <[hidden email]> wrote: >> >> There already is if-ithen and if-kthen, or at least, there used to be. >> >> On Mon, Jan 30, 2012 at 10:37 AM, Andres Cabrera <[hidden email]> >> wrote: >> > On the same idea, would it be worth having: >> > >> > ifi and ifk so the user can make sure the expressions are being >> > evaluated as >> > he expects? >> > >> > Cheers, >> > Andrés >> > >> > >> > On Sun, Jan 29, 2012 at 3:44 PM, Steven Yi <[hidden email]> wrote: >> >> >> >> I think we would have to be very careful to document this in detail. >> >> It's a bit of syntax magic (like, i(f(n)) becomes f(i(n)) is sort of >> >> mindbending :P). >> >> >> >> On Sun, Jan 29, 2012 at 9:51 AM, Tito Latini <[hidden email]> >> >> wrote: >> >> > Now, i() with krate operations is syntactic sugar. Internally >> >> > >> >> > i(num) -> num >> >> > i(ivar) -> ivar >> >> > i(pN) -> pN >> >> > i(kvar) -> i(kvar) >> >> > i(fn(x)) -> fn(i(x)) >> >> > >> >> > the example >> >> > >> >> > i(gkd * .5 + gke + abs(gki * 2 / 3) + sin(gkg / 3.33 + p3) * gkh) >> >> > >> >> > internally becomes >> >> > >> >> > i(gkd) * .5 + i(gke) + abs(i(gki)*2/3) + sin(i(gkg)/3.33 + p3) * >> >> > i(gkh) >> >> > >> >> > The user uses expressions and csound see const, ivar and kvar. The >> >> > limit >> >> > is gone >> >> > >> >> > On Sun, Jan 29, 2012 at 01:44:37PM -0000, [hidden email] wrote: >> >> >> I think thta the i operator should take constants, i-rate objects >> >> >> and >> >> >> global k-rate variables. Actually would prefer it not to take >> >> >> expressions, just variables but I doubt that would be popular. I >> >> >> seem >> >> >> to >> >> >> remember I did not like the i() form when it was introduced because >> >> >> of >> >> >> these oddities >> >> >> ==John ff >> >> >> >> >> >> > Hi, >> >> >> > >> >> >> > I think this is an interesting issue which begs the question, >> >> >> > should >> >> >> > opcodes that modify k-rate vairables always make the first value >> >> >> > available during the init-pass? >> >> >> > >> >> >> > If they do, and it's considered a bug not to, it would be very >> >> >> > convenient and it would avoid a lot of unexpected behavior with >> >> >> > if-thens and reinits, however, It can also be problematic >> >> >> > performance >> >> >> > wise to have to run a control pass as part of initialization. >> >> >> > >> >> >> > I recently spent a long while trying to debug a problem due to >> >> >> > this, >> >> >> > so specifying a default behavior, and an easy >> >> >> > way to know whether a control-rate opcode updates the k-variables >> >> >> > during the init pass would be great! >> >> >> > >> >> >> > What do you all think? >> >> >> > >> >> >> > Cheers, >> >> >> > Andrés >> >> >> > >> >> >> > On Sun, Jan 29, 2012 at 11:02 AM, Tito Latini >> >> >> > <[hidden email]> >> >> >> > wrote: >> >> >> >> fixed in git; Takahiko, here is your example + some extravagance >> >> >> >> >> >> >> >> <CsoundSynthesizer> >> >> >> >> <CsOptions> >> >> >> >> </CsOptions> >> >> >> >> <CsInstruments> >> >> >> >> sr = 44100 >> >> >> >> ksmps = 2 >> >> >> >> instr 1 >> >> >> >> gka init 1 >> >> >> >> gkb init 1 >> >> >> >> gkc init 1 >> >> >> >> gkd init 1 >> >> >> >> gke init 1 >> >> >> >> gkf init 1 >> >> >> >> gkg init 10 >> >> >> >> gkh init 100 >> >> >> >> gki init -123 >> >> >> >> endin >> >> >> >> instr 2 >> >> >> >> gitable ftgen 1, 0, 4, -2, i(gka), i(gkb + gkc), i(gkd * .5 + >> >> >> >> gke), >> >> >> >> i(gkf) >> >> >> >> >> >> >> >> print i(gkb + gkc) >> >> >> >> print i(gkd * .5 + gke) >> >> >> >> print i(gkd * .5 + gke + abs(gki * 2 / 3) + sin(gkg / 3.33 + p3) >> >> >> >> * >> >> >> >> gkh) >> >> >> >> endin >> >> >> >> </CsInstruments> >> >> >> >> <CsScore> >> >> >> >> i1 0 .1 >> >> >> >> i2 0 .1 >> >> >> >> </CsScore> >> >> >> >> </CsoundSynthesizer> >> >> >> >> >> >> >> >> csound -g test.csd >> >> >> >> ... >> >> >> >> ftable 1: 4 points, scalemax 2.000 >> >> >> >> _ >> >> >> >> >> >> >> >> >> >> >> >> - >> >> >> >> >> >> >> >> _ _ >> >> >> >> instr 2: #i11 = 2.000 >> >> >> >> instr 2: #i15 = 1.500 >> >> >> >> instr 2: #i31 = 87.358 >> >> >> >> ... >> >> >> >> >> >> >> >> tito >> >> >> >> >> >> >> >> >> >> >> >> Send bugs reports to the Sourceforge bug tracker >> >> >> >> >> >> >> >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> >> >> >> Discussions of bugs and features can be posted here >> >> >> >> To unsubscribe, send email [hidden email] with body >> >> >> >> "unsubscribe >> >> >> >> csound" >> >> >> >> >> >> >> > >> >> >> > >> >> >> > Send bugs reports to the Sourceforge bug tracker >> >> >> > >> >> >> > https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> >> >> > Discussions of bugs and features can be posted here >> >> >> > To unsubscribe, send email [hidden email] with body >> >> >> > "unsubscribe >> >> >> > csound" >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Send bugs reports to the Sourceforge bug tracker >> >> >> >> >> >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> >> >> Discussions of bugs and features can be posted here >> >> >> To unsubscribe, send email [hidden email] with body >> >> >> "unsubscribe csound" >> >> > >> >> > >> >> > Send bugs reports to the Sourceforge bug tracker >> >> > >> >> > https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> >> > Discussions of bugs and features can be posted here >> >> > To unsubscribe, send email [hidden email] with body >> >> > "unsubscribe >> >> > csound" >> >> > >> >> >> >> >> >> Send bugs reports to the Sourceforge bug tracker >> >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> >> Discussions of bugs and features can be posted here >> >> To unsubscribe, send email [hidden email] with body >> >> "unsubscribe >> >> csound" >> >> >> > >> >> >> Send bugs reports to the Sourceforge bug tracker >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> Discussions of bugs and features can be posted here >> To unsubscribe, send email [hidden email] with body "unsubscribe >> csound" >> > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email [hidden email] with body "unsubscribe csound" |
Re: i() behavior on PC / Mac
|
|
Thanks Steven. I was thinking of asking whether it was worth allowing an i-rate only comparison of ival == kval, but i guess you could do i(kval), which then brings me to my previous question of whether k-rate variables should have a value at init time...
John has made a good point in saying they shouldn't, and I agree that code looks much cleaner if they didin't. Maybe it should be considered a bug if they do, and just write i-rate versions of the opcode for when they are needed. I think this should be considered and discussed, as it was for me a source of great frustration when developing a non trivial process in Csound! And I think the issue would have been avoided if there was consistency in this respect. Cheers, Andrés On Mon, Jan 30, 2012 at 4:02 PM, Steven Yi <[hidden email]> wrote: The evaluation of the expression is dependent on what's being |
Re: i() behavior on PC / Mac
|
|
What about the init opcode?
On 2/3/12, Andres Cabrera <[hidden email]> wrote: > Thanks Steven. I was thinking of asking whether it was worth allowing an > i-rate only comparison of ival == kval, but i guess you could do i(kval), > which then brings me to my previous question of whether k-rate variables > should have a value at init time... > > John has made a good point in saying they shouldn't, and I agree that code > looks much cleaner if they didin't. Maybe it should be considered a bug if > they do, and just write i-rate versions of the opcode for when they are > needed. > > I think this should be considered and discussed, as it was for me a source > of great frustration when developing a non trivial process in Csound! And I > think the issue would have been avoided if there was consistency in this > respect. > > Cheers, > Andrés > > On Mon, Jan 30, 2012 at 4:02 PM, Steven Yi <[hidden email]> wrote: > >> The evaluation of the expression is dependent on what's being >> compared. If I remember correctly, there's a b and a B type >> internally, and the latter is at k-rate. So if you do "kval == ival", >> that see that there's at least one krate arg, and that == returns a B >> type, while "ival == ival2" would return a b type. So the if-kthen >> can be used to force krate branching, even if the boolean expression >> evaluates out to a b type. >> >> On Mon, Jan 30, 2012 at 10:44 AM, Andres Cabrera <[hidden email]> >> wrote: >> > Hi Steven, >> > >> > But that applies to the branching, not to the evaluation of expressions, >> > doesn't it? >> > >> > Cheers, >> > Andrés >> > >> > >> > On Mon, Jan 30, 2012 at 3:40 PM, Steven Yi <[hidden email]> wrote: >> >> >> >> There already is if-ithen and if-kthen, or at least, there used to be. >> >> >> >> On Mon, Jan 30, 2012 at 10:37 AM, Andres Cabrera <[hidden email] >> > >> >> wrote: >> >> > On the same idea, would it be worth having: >> >> > >> >> > ifi and ifk so the user can make sure the expressions are being >> >> > evaluated as >> >> > he expects? >> >> > >> >> > Cheers, >> >> > Andrés >> >> > >> >> > >> >> > On Sun, Jan 29, 2012 at 3:44 PM, Steven Yi <[hidden email]> >> wrote: >> >> >> >> >> >> I think we would have to be very careful to document this in detail. >> >> >> It's a bit of syntax magic (like, i(f(n)) becomes f(i(n)) is sort of >> >> >> mindbending :P). >> >> >> >> >> >> On Sun, Jan 29, 2012 at 9:51 AM, Tito Latini <[hidden email]> >> >> >> wrote: >> >> >> > Now, i() with krate operations is syntactic sugar. Internally >> >> >> > >> >> >> > i(num) -> num >> >> >> > i(ivar) -> ivar >> >> >> > i(pN) -> pN >> >> >> > i(kvar) -> i(kvar) >> >> >> > i(fn(x)) -> fn(i(x)) >> >> >> > >> >> >> > the example >> >> >> > >> >> >> > i(gkd * .5 + gke + abs(gki * 2 / 3) + sin(gkg / 3.33 + p3) * gkh) >> >> >> > >> >> >> > internally becomes >> >> >> > >> >> >> > i(gkd) * .5 + i(gke) + abs(i(gki)*2/3) + sin(i(gkg)/3.33 + p3) * >> >> >> > i(gkh) >> >> >> > >> >> >> > The user uses expressions and csound see const, ivar and kvar. The >> >> >> > limit >> >> >> > is gone >> >> >> > >> >> >> > On Sun, Jan 29, 2012 at 01:44:37PM -0000, [hidden email]: >> >> >> >> I think thta the i operator should take constants, i-rate objects >> >> >> >> and >> >> >> >> global k-rate variables. Actually would prefer it not to take >> >> >> >> expressions, just variables but I doubt that would be popular. I >> >> >> >> seem >> >> >> >> to >> >> >> >> remember I did not like the i() form when it was introduced >> because >> >> >> >> of >> >> >> >> these oddities >> >> >> >> ==John ff >> >> >> >> >> >> >> >> > Hi, >> >> >> >> > >> >> >> >> > I think this is an interesting issue which begs the question, >> >> >> >> > should >> >> >> >> > opcodes that modify k-rate vairables always make the first >> >> >> >> > value >> >> >> >> > available during the init-pass? >> >> >> >> > >> >> >> >> > If they do, and it's considered a bug not to, it would be very >> >> >> >> > convenient and it would avoid a lot of unexpected behavior with >> >> >> >> > if-thens and reinits, however, It can also be problematic >> >> >> >> > performance >> >> >> >> > wise to have to run a control pass as part of initialization. >> >> >> >> > >> >> >> >> > I recently spent a long while trying to debug a problem due to >> >> >> >> > this, >> >> >> >> > so specifying a default behavior, and an easy >> >> >> >> > way to know whether a control-rate opcode updates the >> k-variables >> >> >> >> > during the init pass would be great! >> >> >> >> > >> >> >> >> > What do you all think? >> >> >> >> > >> >> >> >> > Cheers, >> >> >> >> > Andrés >> >> >> >> > >> >> >> >> > On Sun, Jan 29, 2012 at 11:02 AM, Tito Latini >> >> >> >> > <[hidden email]> >> >> >> >> > wrote: >> >> >> >> >> fixed in git; Takahiko, here is your example + some >> extravagance >> >> >> >> >> >> >> >> >> >> <CsoundSynthesizer> >> >> >> >> >> <CsOptions> >> >> >> >> >> </CsOptions> >> >> >> >> >> <CsInstruments> >> >> >> >> >> sr = 44100 >> >> >> >> >> ksmps = 2 >> >> >> >> >> instr 1 >> >> >> >> >> gka init 1 >> >> >> >> >> gkb init 1 >> >> >> >> >> gkc init 1 >> >> >> >> >> gkd init 1 >> >> >> >> >> gke init 1 >> >> >> >> >> gkf init 1 >> >> >> >> >> gkg init 10 >> >> >> >> >> gkh init 100 >> >> >> >> >> gki init -123 >> >> >> >> >> endin >> >> >> >> >> instr 2 >> >> >> >> >> gitable ftgen 1, 0, 4, -2, i(gka), i(gkb + gkc), i(gkd * .5 + >> >> >> >> >> gke), >> >> >> >> >> i(gkf) >> >> >> >> >> >> >> >> >> >> print i(gkb + gkc) >> >> >> >> >> print i(gkd * .5 + gke) >> >> >> >> >> print i(gkd * .5 + gke + abs(gki * 2 / 3) + sin(gkg / 3.33 + >> p3) >> >> >> >> >> * >> >> >> >> >> gkh) >> >> >> >> >> endin >> >> >> >> >> </CsInstruments> >> >> >> >> >> <CsScore> >> >> >> >> >> i1 0 .1 >> >> >> >> >> i2 0 .1 >> >> >> >> >> </CsScore> >> >> >> >> >> </CsoundSynthesizer> >> >> >> >> >> >> >> >> >> >> csound -g test.csd >> >> >> >> >> ... >> >> >> >> >> ftable 1: 4 points, scalemax 2.000 >> >> >> >> >> _ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> - >> >> >> >> >> >> >> >> >> >> _ _ >> >> >> >> >> instr 2: #i11 = 2.000 >> >> >> >> >> instr 2: #i15 = 1.500 >> >> >> >> >> instr 2: #i31 = 87.358 >> >> >> >> >> ... >> >> >> >> >> >> >> >> >> >> tito >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Send bugs reports to the Sourceforge bug tracker >> >> >> >> >> >> >> >> >> >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> >> >> >> >> Discussions of bugs and features can be posted here >> >> >> >> >> To unsubscribe, send email [hidden email] with body >> >> >> >> >> "unsubscribe >> >> >> >> >> csound" >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> > Send bugs reports to the Sourceforge bug tracker >> >> >> >> > >> >> >> >> > https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> >> >> >> > Discussions of bugs and features can be posted here >> >> >> >> > To unsubscribe, send email [hidden email] with body >> >> >> >> > "unsubscribe >> >> >> >> > csound" >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Send bugs reports to the Sourceforge bug tracker >> >> >> >> >> >> >> >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> >> >> >> Discussions of bugs and features can be posted here >> >> >> >> To unsubscribe, send email [hidden email] with body >> >> >> >> "unsubscribe csound" >> >> >> > >> >> >> > >> >> >> > Send bugs reports to the Sourceforge bug tracker >> >> >> > >> >> >> > https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> >> >> > Discussions of bugs and features can be posted here >> >> >> > To unsubscribe, send email [hidden email] with body >> >> >> > "unsubscribe >> >> >> > csound" >> >> >> > >> >> >> >> >> >> >> >> >> Send bugs reports to the Sourceforge bug tracker >> >> >> >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> >> >> Discussions of bugs and features can be posted here >> >> >> To unsubscribe, send email [hidden email] with body >> >> >> "unsubscribe >> >> >> csound" >> >> >> >> >> > >> >> >> >> >> >> Send bugs reports to the Sourceforge bug tracker >> >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> >> Discussions of bugs and features can be posted here >> >> To unsubscribe, send email [hidden email] with body >> "unsubscribe >> >> csound" >> >> >> > >> >> >> Send bugs reports to the Sourceforge bug tracker >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> Discussions of bugs and features can be posted here >> To unsubscribe, send email [hidden email] with body "unsubscribe >> csound" >> >> > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email [hidden email] with body "unsubscribe > csound" > > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email [hidden email] with body "unsubscribe csound" |
«
Return to Csound - General
|
1 view|%1 views
Loading...
| Powered by Nabble | See how NAML generates this page |
