i() behavior on PC / Mac
Locked
12
12
Re: i() behavior on PC / Mac
 
|
I do want and need (always have) to be able to simply cast in Csound. i(k) should work. I am happy that it might/will.
-dB
___________________________________ 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 Feb 3, 2012, at 6:58 AM, Andres Cabrera 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... |
Re: i() behavior on PC / Mac
|
I agree with Dr. B.
On 2/3/12, Dr. Richard Boulanger <[hidden email]> wrote: > I do want and need (always have) to be able to simply cast in Csound. i(k) > should work. I am happy that it might/will. > > -dB > ___________________________________ > > 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) > > [hidden email] > http://csounds.com/boulanger > ____________________________________ > > http://csounds.com > http://csoundforlive.com > ____________________________________ > > http://csounds.com/mathews > ____________________________________ > > On Feb 3, 2012, at 6:58 AM, Andres Cabrera 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] >> >> >> > 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" >> >> > > > 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 Adam Puckett-2
Hi Adam,
The init opcode is not enough, as some krate variables when in the output of a k-rate opcode will not have the "correct" value at init time. So in a way it's a question of convenience ("i() should work everywhere"), which would mean adding an i-pass to all those k-rate opcodes that don't have one, or cleanness, and make all k-rate versions of opcodes not produce values at init time, but rather have independent i-rate versions for them. The second one would probably render i() obsolete. Cheers, Andrés On Fri, Feb 3, 2012 at 1:53 PM, Adam Puckett <[hidden email]> wrote: What about the init opcode? |
Re: i() behavior on PC / Mac
|
|
Thanks for the explanation.
On 2/3/12, Andres Cabrera <[hidden email]> wrote: > Hi Adam, > > The init opcode is not enough, as some krate variables when in the output > of a k-rate opcode will not have the "correct" value at init time. > > So in a way it's a question of convenience ("i() should work everywhere"), > which would mean adding an i-pass to all those k-rate opcodes that don't > have one, or cleanness, and make all k-rate versions of opcodes not produce > values at init time, but rather have independent i-rate versions for them. > > The second one would probably render i() obsolete. > > Cheers, > Andrés > > On Fri, Feb 3, 2012 at 1:53 PM, Adam Puckett > <[hidden email]>wrote: > >> 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" >> >> > > 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 |
