[Cs-dev] i(kswitch+1)

[Cs-dev] i(kswitch+1)

Date	2014-04-04 10:24
From	Oeyvind Brandtsegg
Subject	[Cs-dev] i(kswitch+1)
	I wonder if this is a bug, I would expect i2 and i3 to be equal in the following example, but they are not. Almost as if i(kswitch+1) reads the previous i-time value of kswitch somehow (??) sr = 44100 kr = 441 ksmps = 100 nchnls = 2 instr 1 kmetro metro 1 kswitch init 0 kswitch = (kswitch+kmetro)%2 printk2 kswitch if kmetro > 0 then reinit testme endif testme: i1 = i(kswitch) i2 = i(kswitch+1) i3 = i1+1 print i1, i2, i3 rireturn endin i1 0 5 e -- Oeyvind Brandtsegg Professor of Music Technology NTNU 7491 Trondheim Norway Cell: +47 92 203 205 http://flyndresang.no/ http://www.partikkelaudio.com/ http://soundcloud.com/brandtsegg http://soundcloud.com/t-emp ------------------------------------------------------------------------------ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2014-04-04 12:17
From	Victor Lazzarini
Subject	Re: [Cs-dev] i(kswitch+1)
	it’s because in i(.) the . has to be a variable (which is actually a memory address). ======================== Dr Victor Lazzarini Senior Lecturer NUI Maynooth, Ireland victor dot lazzarini at nuim dot ie On 4 Apr 2014, at 10:24, Oeyvind Brandtsegg wrote: > I wonder if this is a bug, > I would expect i2 and i3 to be equal in the following example, but they are not. > Almost as if i(kswitch+1) reads the previous i-time value of kswitch > somehow (??) > > > > > > > sr = 44100 > kr = 441 > ksmps = 100 > nchnls = 2 > > instr 1 > > kmetro metro 1 > kswitch init 0 > kswitch = (kswitch+kmetro)%2 > printk2 kswitch > if kmetro > 0 then > reinit testme > endif > > testme: > i1 = i(kswitch) > i2 = i(kswitch+1) > i3 = i1+1 > print i1, i2, i3 > rireturn > > endin > > > i1 0 5 > e > > > > > > > -- > > Oeyvind Brandtsegg > Professor of Music Technology > NTNU > 7491 Trondheim > Norway > Cell: +47 92 203 205 > > http://flyndresang.no/ > http://www.partikkelaudio.com/ > http://soundcloud.com/brandtsegg > http://soundcloud.com/t-emp > > ------------------------------------------------------------------------------ > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2014-04-04 12:24
From	Oeyvind Brandtsegg
Subject	Re: [Cs-dev] i(kswitch+1)
	I see, it is an easy mistake to make though. I see now that it is noted in the manual, but still, if one is not looking in the manual one could expect my original code to work. Could we make k-rate expressions illegal in this case, since it otherwise can lead to unexpected results. If the parser would stop and give an error message that k-rate expressions must be done outside the i(.), I think it would be very helpful. Oeyvind 2014-04-04 13:17 GMT+02:00 Victor Lazzarini : > it's because in i(.) the . has to be a variable (which is actually a memory address). > ======================== > Dr Victor Lazzarini > Senior Lecturer > NUI Maynooth, Ireland > victor dot lazzarini at nuim dot ie > > > > > On 4 Apr 2014, at 10:24, Oeyvind Brandtsegg wrote: > >> I wonder if this is a bug, >> I would expect i2 and i3 to be equal in the following example, but they are not. >> Almost as if i(kswitch+1) reads the previous i-time value of kswitch >> somehow (??) >> >> >> >> >> >> >> sr = 44100 >> kr = 441 >> ksmps = 100 >> nchnls = 2 >> >> instr 1 >> >> kmetro metro 1 >> kswitch init 0 >> kswitch = (kswitch+kmetro)%2 >> printk2 kswitch >> if kmetro > 0 then >> reinit testme >> endif >> >> testme: >> i1 = i(kswitch) >> i2 = i(kswitch+1) >> i3 = i1+1 >> print i1, i2, i3 >> rireturn >> >> endin >> >> >> i1 0 5 >> e >> >> >> >> >> >> >> -- >> >> Oeyvind Brandtsegg >> Professor of Music Technology >> NTNU >> 7491 Trondheim >> Norway >> Cell: +47 92 203 205 >> >> http://flyndresang.no/ >> http://www.partikkelaudio.com/ >> http://soundcloud.com/brandtsegg >> http://soundcloud.com/t-emp >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel -- Oeyvind Brandtsegg Professor of Music Technology NTNU 7491 Trondheim Norway Cell: +47 92 203 205 http://flyndresang.no/ http://www.partikkelaudio.com/ http://soundcloud.com/brandtsegg http://soundcloud.com/t-emp ------------------------------------------------------------------------------ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2014-04-04 13:17
From	Victor Lazzarini
Subject	Re: [Cs-dev] i(kswitch+1)
	Agreed that is an easy mistake and it should be protected somehow, but not sure how to tackle it right now. It would need to be made an exception in the parser. ======================== Dr Victor Lazzarini Senior Lecturer NUI Maynooth, Ireland victor dot lazzarini at nuim dot ie On 4 Apr 2014, at 12:24, Oeyvind Brandtsegg wrote: > I see, > it is an easy mistake to make though. > I see now that it is noted in the manual, > but still, if one is not looking in the manual one could expect my > original code to work. > Could we make k-rate expressions illegal in this case, since it > otherwise can lead to unexpected results. If the parser would stop and > give an error message that k-rate expressions must be done outside the > i(.), I think it would be very helpful. > Oeyvind > > 2014-04-04 13:17 GMT+02:00 Victor Lazzarini : >> it's because in i(.) the . has to be a variable (which is actually a memory address). >> ======================== >> Dr Victor Lazzarini >> Senior Lecturer >> NUI Maynooth, Ireland >> victor dot lazzarini at nuim dot ie >> >> >> >> >> On 4 Apr 2014, at 10:24, Oeyvind Brandtsegg wrote: >> >>> I wonder if this is a bug, >>> I would expect i2 and i3 to be equal in the following example, but they are not. >>> Almost as if i(kswitch+1) reads the previous i-time value of kswitch >>> somehow (??) >>> >>> >>> >>> >>> >>> >>> sr = 44100 >>> kr = 441 >>> ksmps = 100 >>> nchnls = 2 >>> >>> instr 1 >>> >>> kmetro metro 1 >>> kswitch init 0 >>> kswitch = (kswitch+kmetro)%2 >>> printk2 kswitch >>> if kmetro > 0 then >>> reinit testme >>> endif >>> >>> testme: >>> i1 = i(kswitch) >>> i2 = i(kswitch+1) >>> i3 = i1+1 >>> print i1, i2, i3 >>> rireturn >>> >>> endin >>> >>> >>> i1 0 5 >>> e >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Oeyvind Brandtsegg >>> Professor of Music Technology >>> NTNU >>> 7491 Trondheim >>> Norway >>> Cell: +47 92 203 205 >>> >>> http://flyndresang.no/ >>> http://www.partikkelaudio.com/ >>> http://soundcloud.com/brandtsegg >>> http://soundcloud.com/t-emp >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > -- > > Oeyvind Brandtsegg > Professor of Music Technology > NTNU > 7491 Trondheim > Norway > Cell: +47 92 203 205 > > http://flyndresang.no/ > http://www.partikkelaudio.com/ > http://soundcloud.com/brandtsegg > http://soundcloud.com/t-emp > > ------------------------------------------------------------------------------ > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2014-04-04 13:21
From	Victor Lazzarini
Subject	Re: [Cs-dev] i(kswitch+1)
	Or on the other hand we need to make it use the rule for expressions i1 = i(kw + 1) => ##k1 = kw + 1 i1 = i(##k1) Not sure why it’s not doing that. ======================== Dr Victor Lazzarini Senior Lecturer NUI Maynooth, Ireland victor dot lazzarini at nuim dot ie On 4 Apr 2014, at 13:17, Victor Lazzarini wrote: > Agreed that is an easy mistake and it should be protected somehow, but not sure how to tackle it > right now. It would need to be made an exception in the parser. > ======================== > Dr Victor Lazzarini > Senior Lecturer > NUI Maynooth, Ireland > victor dot lazzarini at nuim dot ie > > > > > On 4 Apr 2014, at 12:24, Oeyvind Brandtsegg wrote: > >> I see, >> it is an easy mistake to make though. >> I see now that it is noted in the manual, >> but still, if one is not looking in the manual one could expect my >> original code to work. >> Could we make k-rate expressions illegal in this case, since it >> otherwise can lead to unexpected results. If the parser would stop and >> give an error message that k-rate expressions must be done outside the >> i(.), I think it would be very helpful. >> Oeyvind >> >> 2014-04-04 13:17 GMT+02:00 Victor Lazzarini : >>> it's because in i(.) the . has to be a variable (which is actually a memory address). >>> ======================== >>> Dr Victor Lazzarini >>> Senior Lecturer >>> NUI Maynooth, Ireland >>> victor dot lazzarini at nuim dot ie >>> >>> >>> >>> >>> On 4 Apr 2014, at 10:24, Oeyvind Brandtsegg wrote: >>> >>>> I wonder if this is a bug, >>>> I would expect i2 and i3 to be equal in the following example, but they are not. >>>> Almost as if i(kswitch+1) reads the previous i-time value of kswitch >>>> somehow (??) >>>> >>>> >>>> >>>> >>>> >>>> >>>> sr = 44100 >>>> kr = 441 >>>> ksmps = 100 >>>> nchnls = 2 >>>> >>>> instr 1 >>>> >>>> kmetro metro 1 >>>> kswitch init 0 >>>> kswitch = (kswitch+kmetro)%2 >>>> printk2 kswitch >>>> if kmetro > 0 then >>>> reinit testme >>>> endif >>>> >>>> testme: >>>> i1 = i(kswitch) >>>> i2 = i(kswitch+1) >>>> i3 = i1+1 >>>> print i1, i2, i3 >>>> rireturn >>>> >>>> endin >>>> >>>> >>>> i1 0 5 >>>> e >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Oeyvind Brandtsegg >>>> Professor of Music Technology >>>> NTNU >>>> 7491 Trondheim >>>> Norway >>>> Cell: +47 92 203 205 >>>> >>>> http://flyndresang.no/ >>>> http://www.partikkelaudio.com/ >>>> http://soundcloud.com/brandtsegg >>>> http://soundcloud.com/t-emp >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> Csound-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> >> >> -- >> >> Oeyvind Brandtsegg >> Professor of Music Technology >> NTNU >> 7491 Trondheim >> Norway >> Cell: +47 92 203 205 >> >> http://flyndresang.no/ >> http://www.partikkelaudio.com/ >> http://soundcloud.com/brandtsegg >> http://soundcloud.com/t-emp >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2014-04-04 13:22
From	Steven Yi
Subject	Re: [Cs-dev] i(kswitch+1)
	I think this might be sort of a hack to detect. What happens is that the line: i2 = i(kswitch+1) becomes something like: #k0 sum.k kswitch, 1 i2 = i(#k0) with the sum happening at perf-time, and #k0 being initialized to 0. The sum would not do anything a init-time, so #k0 just remains 0 when the i() goes to compute. On Fri, Apr 4, 2014 at 8:17 AM, Victor Lazzarini wrote: > Agreed that is an easy mistake and it should be protected somehow, but not sure how to tackle it > right now. It would need to be made an exception in the parser. > ======================== > Dr Victor Lazzarini > Senior Lecturer > NUI Maynooth, Ireland > victor dot lazzarini at nuim dot ie > > > > > On 4 Apr 2014, at 12:24, Oeyvind Brandtsegg wrote: > >> I see, >> it is an easy mistake to make though. >> I see now that it is noted in the manual, >> but still, if one is not looking in the manual one could expect my >> original code to work. >> Could we make k-rate expressions illegal in this case, since it >> otherwise can lead to unexpected results. If the parser would stop and >> give an error message that k-rate expressions must be done outside the >> i(.), I think it would be very helpful. >> Oeyvind >> >> 2014-04-04 13:17 GMT+02:00 Victor Lazzarini : >>> it's because in i(.) the . has to be a variable (which is actually a memory address). >>> ======================== >>> Dr Victor Lazzarini >>> Senior Lecturer >>> NUI Maynooth, Ireland >>> victor dot lazzarini at nuim dot ie >>> >>> >>> >>> >>> On 4 Apr 2014, at 10:24, Oeyvind Brandtsegg wrote: >>> >>>> I wonder if this is a bug, >>>> I would expect i2 and i3 to be equal in the following example, but they are not. >>>> Almost as if i(kswitch+1) reads the previous i-time value of kswitch >>>> somehow (??) >>>> >>>> >>>> >>>> >>>> >>>> >>>> sr = 44100 >>>> kr = 441 >>>> ksmps = 100 >>>> nchnls = 2 >>>> >>>> instr 1 >>>> >>>> kmetro metro 1 >>>> kswitch init 0 >>>> kswitch = (kswitch+kmetro)%2 >>>> printk2 kswitch >>>> if kmetro > 0 then >>>> reinit testme >>>> endif >>>> >>>> testme: >>>> i1 = i(kswitch) >>>> i2 = i(kswitch+1) >>>> i3 = i1+1 >>>> print i1, i2, i3 >>>> rireturn >>>> >>>> endin >>>> >>>> >>>> i1 0 5 >>>> e >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Oeyvind Brandtsegg >>>> Professor of Music Technology >>>> NTNU >>>> 7491 Trondheim >>>> Norway >>>> Cell: +47 92 203 205 >>>> >>>> http://flyndresang.no/ >>>> http://www.partikkelaudio.com/ >>>> http://soundcloud.com/brandtsegg >>>> http://soundcloud.com/t-emp >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> Csound-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> >> >> -- >> >> Oeyvind Brandtsegg >> Professor of Music Technology >> NTNU >> 7491 Trondheim >> Norway >> Cell: +47 92 203 205 >> >> http://flyndresang.no/ >> http://www.partikkelaudio.com/ >> http://soundcloud.com/brandtsegg >> http://soundcloud.com/t-emp >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2014-04-04 13:32
From	Victor Lazzarini
Subject	Re: [Cs-dev] i(kswitch+1)
	Shouldn’t it be sum.i then? ======================== Dr Victor Lazzarini Senior Lecturer NUI Maynooth, Ireland victor dot lazzarini at nuim dot ie On 4 Apr 2014, at 13:22, Steven Yi wrote: > I think this might be sort of a hack to detect. What happens is that the line: > > i2 = i(kswitch+1) > > becomes something like: > > #k0 sum.k kswitch, 1 > i2 = i(#k0) > > with the sum happening at perf-time, and #k0 being initialized to 0. > The sum would not do anything a init-time, so #k0 just remains 0 when > the i() goes to compute. > > > > On Fri, Apr 4, 2014 at 8:17 AM, Victor Lazzarini > wrote: >> Agreed that is an easy mistake and it should be protected somehow, but not sure how to tackle it >> right now. It would need to be made an exception in the parser. >> ======================== >> Dr Victor Lazzarini >> Senior Lecturer >> NUI Maynooth, Ireland >> victor dot lazzarini at nuim dot ie >> >> >> >> >> On 4 Apr 2014, at 12:24, Oeyvind Brandtsegg wrote: >> >>> I see, >>> it is an easy mistake to make though. >>> I see now that it is noted in the manual, >>> but still, if one is not looking in the manual one could expect my >>> original code to work. >>> Could we make k-rate expressions illegal in this case, since it >>> otherwise can lead to unexpected results. If the parser would stop and >>> give an error message that k-rate expressions must be done outside the >>> i(.), I think it would be very helpful. >>> Oeyvind >>> >>> 2014-04-04 13:17 GMT+02:00 Victor Lazzarini : >>>> it's because in i(.) the . has to be a variable (which is actually a memory address). >>>> ======================== >>>> Dr Victor Lazzarini >>>> Senior Lecturer >>>> NUI Maynooth, Ireland >>>> victor dot lazzarini at nuim dot ie >>>> >>>> >>>> >>>> >>>> On 4 Apr 2014, at 10:24, Oeyvind Brandtsegg wrote: >>>> >>>>> I wonder if this is a bug, >>>>> I would expect i2 and i3 to be equal in the following example, but they are not. >>>>> Almost as if i(kswitch+1) reads the previous i-time value of kswitch >>>>> somehow (??) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> sr = 44100 >>>>> kr = 441 >>>>> ksmps = 100 >>>>> nchnls = 2 >>>>> >>>>> instr 1 >>>>> >>>>> kmetro metro 1 >>>>> kswitch init 0 >>>>> kswitch = (kswitch+kmetro)%2 >>>>> printk2 kswitch >>>>> if kmetro > 0 then >>>>> reinit testme >>>>> endif >>>>> >>>>> testme: >>>>> i1 = i(kswitch) >>>>> i2 = i(kswitch+1) >>>>> i3 = i1+1 >>>>> print i1, i2, i3 >>>>> rireturn >>>>> >>>>> endin >>>>> >>>>> >>>>> i1 0 5 >>>>> e >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Oeyvind Brandtsegg >>>>> Professor of Music Technology >>>>> NTNU >>>>> 7491 Trondheim >>>>> Norway >>>>> Cell: +47 92 203 205 >>>>> >>>>> http://flyndresang.no/ >>>>> http://www.partikkelaudio.com/ >>>>> http://soundcloud.com/brandtsegg >>>>> http://soundcloud.com/t-emp >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Csound-devel mailing list >>>>> Csound-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> Csound-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> >>> >>> -- >>> >>> Oeyvind Brandtsegg >>> Professor of Music Technology >>> NTNU >>> 7491 Trondheim >>> Norway >>> Cell: +47 92 203 205 >>> >>> http://flyndresang.no/ >>> http://www.partikkelaudio.com/ >>> http://soundcloud.com/brandtsegg >>> http://soundcloud.com/t-emp >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > ------------------------------------------------------------------------------ > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2014-04-04 13:37
From	Steven Yi
Subject	Re: [Cs-dev] i(kswitch+1)
	I don't think it should be sum.i, as the compiler detects correctly that the expression being used is a k-rate one. The original code could have been re-written as: i2 = i(kswitch) + 1 which would have worked fine. I think though that the original code could probably be modified to be a bit simpler. It's not clear why there's a re-init being used, and if there isn't a better way to go about it. On Fri, Apr 4, 2014 at 8:32 AM, Victor Lazzarini wrote: > Shouldn't it be sum.i then? > ======================== > Dr Victor Lazzarini > Senior Lecturer > NUI Maynooth, Ireland > victor dot lazzarini at nuim dot ie > > > > > On 4 Apr 2014, at 13:22, Steven Yi wrote: > >> I think this might be sort of a hack to detect. What happens is that the line: >> >> i2 = i(kswitch+1) >> >> becomes something like: >> >> #k0 sum.k kswitch, 1 >> i2 = i(#k0) >> >> with the sum happening at perf-time, and #k0 being initialized to 0. >> The sum would not do anything a init-time, so #k0 just remains 0 when >> the i() goes to compute. >> >> >> >> On Fri, Apr 4, 2014 at 8:17 AM, Victor Lazzarini >> wrote: >>> Agreed that is an easy mistake and it should be protected somehow, but not sure how to tackle it >>> right now. It would need to be made an exception in the parser. >>> ======================== >>> Dr Victor Lazzarini >>> Senior Lecturer >>> NUI Maynooth, Ireland >>> victor dot lazzarini at nuim dot ie >>> >>> >>> >>> >>> On 4 Apr 2014, at 12:24, Oeyvind Brandtsegg wrote: >>> >>>> I see, >>>> it is an easy mistake to make though. >>>> I see now that it is noted in the manual, >>>> but still, if one is not looking in the manual one could expect my >>>> original code to work. >>>> Could we make k-rate expressions illegal in this case, since it >>>> otherwise can lead to unexpected results. If the parser would stop and >>>> give an error message that k-rate expressions must be done outside the >>>> i(.), I think it would be very helpful. >>>> Oeyvind >>>> >>>> 2014-04-04 13:17 GMT+02:00 Victor Lazzarini : >>>>> it's because in i(.) the . has to be a variable (which is actually a memory address). >>>>> ======================== >>>>> Dr Victor Lazzarini >>>>> Senior Lecturer >>>>> NUI Maynooth, Ireland >>>>> victor dot lazzarini at nuim dot ie >>>>> >>>>> >>>>> >>>>> >>>>> On 4 Apr 2014, at 10:24, Oeyvind Brandtsegg wrote: >>>>> >>>>>> I wonder if this is a bug, >>>>>> I would expect i2 and i3 to be equal in the following example, but they are not. >>>>>> Almost as if i(kswitch+1) reads the previous i-time value of kswitch >>>>>> somehow (??) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> sr = 44100 >>>>>> kr = 441 >>>>>> ksmps = 100 >>>>>> nchnls = 2 >>>>>> >>>>>> instr 1 >>>>>> >>>>>> kmetro metro 1 >>>>>> kswitch init 0 >>>>>> kswitch = (kswitch+kmetro)%2 >>>>>> printk2 kswitch >>>>>> if kmetro > 0 then >>>>>> reinit testme >>>>>> endif >>>>>> >>>>>> testme: >>>>>> i1 = i(kswitch) >>>>>> i2 = i(kswitch+1) >>>>>> i3 = i1+1 >>>>>> print i1, i2, i3 >>>>>> rireturn >>>>>> >>>>>> endin >>>>>> >>>>>> >>>>>> i1 0 5 >>>>>> e >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Oeyvind Brandtsegg >>>>>> Professor of Music Technology >>>>>> NTNU >>>>>> 7491 Trondheim >>>>>> Norway >>>>>> Cell: +47 92 203 205 >>>>>> >>>>>> http://flyndresang.no/ >>>>>> http://www.partikkelaudio.com/ >>>>>> http://soundcloud.com/brandtsegg >>>>>> http://soundcloud.com/t-emp >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> _______________________________________________ >>>>>> Csound-devel mailing list >>>>>> Csound-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Csound-devel mailing list >>>>> Csound-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>> >>>> >>>> >>>> -- >>>> >>>> Oeyvind Brandtsegg >>>> Professor of Music Technology >>>> NTNU >>>> 7491 Trondheim >>>> Norway >>>> Cell: +47 92 203 205 >>>> >>>> http://flyndresang.no/ >>>> http://www.partikkelaudio.com/ >>>> http://soundcloud.com/brandtsegg >>>> http://soundcloud.com/t-emp >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> Csound-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2014-04-04 13:39
From	Victor Lazzarini
Subject	Re: [Cs-dev] i(kswitch+1)
	We might need to flag to users that any expression involving ksigs and constants will not be evaluated at i-time. ======================== Dr Victor Lazzarini Senior Lecturer NUI Maynooth, Ireland victor dot lazzarini at nuim dot ie On 4 Apr 2014, at 13:37, Steven Yi wrote: > I don't think it should be sum.i, as the compiler detects correctly > that the expression being used is a k-rate one. The original code > could have been re-written as: > > i2 = i(kswitch) + 1 > > which would have worked fine. > > I think though that the original code could probably be modified to be > a bit simpler. It's not clear why there's a re-init being used, and > if there isn't a better way to go about it. > > On Fri, Apr 4, 2014 at 8:32 AM, Victor Lazzarini > wrote: >> Shouldn't it be sum.i then? >> ======================== >> Dr Victor Lazzarini >> Senior Lecturer >> NUI Maynooth, Ireland >> victor dot lazzarini at nuim dot ie >> >> >> >> >> On 4 Apr 2014, at 13:22, Steven Yi wrote: >> >>> I think this might be sort of a hack to detect. What happens is that the line: >>> >>> i2 = i(kswitch+1) >>> >>> becomes something like: >>> >>> #k0 sum.k kswitch, 1 >>> i2 = i(#k0) >>> >>> with the sum happening at perf-time, and #k0 being initialized to 0. >>> The sum would not do anything a init-time, so #k0 just remains 0 when >>> the i() goes to compute. >>> >>> >>> >>> On Fri, Apr 4, 2014 at 8:17 AM, Victor Lazzarini >>> wrote: >>>> Agreed that is an easy mistake and it should be protected somehow, but not sure how to tackle it >>>> right now. It would need to be made an exception in the parser. >>>> ======================== >>>> Dr Victor Lazzarini >>>> Senior Lecturer >>>> NUI Maynooth, Ireland >>>> victor dot lazzarini at nuim dot ie >>>> >>>> >>>> >>>> >>>> On 4 Apr 2014, at 12:24, Oeyvind Brandtsegg wrote: >>>> >>>>> I see, >>>>> it is an easy mistake to make though. >>>>> I see now that it is noted in the manual, >>>>> but still, if one is not looking in the manual one could expect my >>>>> original code to work. >>>>> Could we make k-rate expressions illegal in this case, since it >>>>> otherwise can lead to unexpected results. If the parser would stop and >>>>> give an error message that k-rate expressions must be done outside the >>>>> i(.), I think it would be very helpful. >>>>> Oeyvind >>>>> >>>>> 2014-04-04 13:17 GMT+02:00 Victor Lazzarini : >>>>>> it's because in i(.) the . has to be a variable (which is actually a memory address). >>>>>> ======================== >>>>>> Dr Victor Lazzarini >>>>>> Senior Lecturer >>>>>> NUI Maynooth, Ireland >>>>>> victor dot lazzarini at nuim dot ie >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 4 Apr 2014, at 10:24, Oeyvind Brandtsegg wrote: >>>>>> >>>>>>> I wonder if this is a bug, >>>>>>> I would expect i2 and i3 to be equal in the following example, but they are not. >>>>>>> Almost as if i(kswitch+1) reads the previous i-time value of kswitch >>>>>>> somehow (??) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> sr = 44100 >>>>>>> kr = 441 >>>>>>> ksmps = 100 >>>>>>> nchnls = 2 >>>>>>> >>>>>>> instr 1 >>>>>>> >>>>>>> kmetro metro 1 >>>>>>> kswitch init 0 >>>>>>> kswitch = (kswitch+kmetro)%2 >>>>>>> printk2 kswitch >>>>>>> if kmetro > 0 then >>>>>>> reinit testme >>>>>>> endif >>>>>>> >>>>>>> testme: >>>>>>> i1 = i(kswitch) >>>>>>> i2 = i(kswitch+1) >>>>>>> i3 = i1+1 >>>>>>> print i1, i2, i3 >>>>>>> rireturn >>>>>>> >>>>>>> endin >>>>>>> >>>>>>> >>>>>>> i1 0 5 >>>>>>> e >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Oeyvind Brandtsegg >>>>>>> Professor of Music Technology >>>>>>> NTNU >>>>>>> 7491 Trondheim >>>>>>> Norway >>>>>>> Cell: +47 92 203 205 >>>>>>> >>>>>>> http://flyndresang.no/ >>>>>>> http://www.partikkelaudio.com/ >>>>>>> http://soundcloud.com/brandtsegg >>>>>>> http://soundcloud.com/t-emp >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> _______________________________________________ >>>>>>> Csound-devel mailing list >>>>>>> Csound-devel@lists.sourceforge.net >>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> _______________________________________________ >>>>>> Csound-devel mailing list >>>>>> Csound-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Oeyvind Brandtsegg >>>>> Professor of Music Technology >>>>> NTNU >>>>> 7491 Trondheim >>>>> Norway >>>>> Cell: +47 92 203 205 >>>>> >>>>> http://flyndresang.no/ >>>>> http://www.partikkelaudio.com/ >>>>> http://soundcloud.com/brandtsegg >>>>> http://soundcloud.com/t-emp >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Csound-devel mailing list >>>>> Csound-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> Csound-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > ------------------------------------------------------------------------------ > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2014-04-04 13:45
From	Oeyvind Brandtsegg
Subject	Re: [Cs-dev] i(kswitch+1)
	Just to note, if by the original code you mean the example I sent, it was a simplified test just to show the problem. The reinit was needed in the actual code where I discovered the problem. Wouldn't it be ok to catch the k-rate expression inside i() at the preprocessing stage? Oeyvind 2014-04-04 14:37 GMT+02:00 Steven Yi : > I don't think it should be sum.i, as the compiler detects correctly > that the expression being used is a k-rate one. The original code > could have been re-written as: > > i2 = i(kswitch) + 1 > > which would have worked fine. > > I think though that the original code could probably be modified to be > a bit simpler. It's not clear why there's a re-init being used, and > if there isn't a better way to go about it. > > On Fri, Apr 4, 2014 at 8:32 AM, Victor Lazzarini > wrote: >> Shouldn't it be sum.i then? >> ======================== >> Dr Victor Lazzarini >> Senior Lecturer >> NUI Maynooth, Ireland >> victor dot lazzarini at nuim dot ie >> >> >> >> >> On 4 Apr 2014, at 13:22, Steven Yi wrote: >> >>> I think this might be sort of a hack to detect. What happens is that the line: >>> >>> i2 = i(kswitch+1) >>> >>> becomes something like: >>> >>> #k0 sum.k kswitch, 1 >>> i2 = i(#k0) >>> >>> with the sum happening at perf-time, and #k0 being initialized to 0. >>> The sum would not do anything a init-time, so #k0 just remains 0 when >>> the i() goes to compute. >>> >>> >>> >>> On Fri, Apr 4, 2014 at 8:17 AM, Victor Lazzarini >>> wrote: >>>> Agreed that is an easy mistake and it should be protected somehow, but not sure how to tackle it >>>> right now. It would need to be made an exception in the parser. >>>> ======================== >>>> Dr Victor Lazzarini >>>> Senior Lecturer >>>> NUI Maynooth, Ireland >>>> victor dot lazzarini at nuim dot ie >>>> >>>> >>>> >>>> >>>> On 4 Apr 2014, at 12:24, Oeyvind Brandtsegg wrote: >>>> >>>>> I see, >>>>> it is an easy mistake to make though. >>>>> I see now that it is noted in the manual, >>>>> but still, if one is not looking in the manual one could expect my >>>>> original code to work. >>>>> Could we make k-rate expressions illegal in this case, since it >>>>> otherwise can lead to unexpected results. If the parser would stop and >>>>> give an error message that k-rate expressions must be done outside the >>>>> i(.), I think it would be very helpful. >>>>> Oeyvind >>>>> >>>>> 2014-04-04 13:17 GMT+02:00 Victor Lazzarini : >>>>>> it's because in i(.) the . has to be a variable (which is actually a memory address). >>>>>> ======================== >>>>>> Dr Victor Lazzarini >>>>>> Senior Lecturer >>>>>> NUI Maynooth, Ireland >>>>>> victor dot lazzarini at nuim dot ie >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 4 Apr 2014, at 10:24, Oeyvind Brandtsegg wrote: >>>>>> >>>>>>> I wonder if this is a bug, >>>>>>> I would expect i2 and i3 to be equal in the following example, but they are not. >>>>>>> Almost as if i(kswitch+1) reads the previous i-time value of kswitch >>>>>>> somehow (??) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> sr = 44100 >>>>>>> kr = 441 >>>>>>> ksmps = 100 >>>>>>> nchnls = 2 >>>>>>> >>>>>>> instr 1 >>>>>>> >>>>>>> kmetro metro 1 >>>>>>> kswitch init 0 >>>>>>> kswitch = (kswitch+kmetro)%2 >>>>>>> printk2 kswitch >>>>>>> if kmetro > 0 then >>>>>>> reinit testme >>>>>>> endif >>>>>>> >>>>>>> testme: >>>>>>> i1 = i(kswitch) >>>>>>> i2 = i(kswitch+1) >>>>>>> i3 = i1+1 >>>>>>> print i1, i2, i3 >>>>>>> rireturn >>>>>>> >>>>>>> endin >>>>>>> >>>>>>> >>>>>>> i1 0 5 >>>>>>> e >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Oeyvind Brandtsegg >>>>>>> Professor of Music Technology >>>>>>> NTNU >>>>>>> 7491 Trondheim >>>>>>> Norway >>>>>>> Cell: +47 92 203 205 >>>>>>> >>>>>>> http://flyndresang.no/ >>>>>>> http://www.partikkelaudio.com/ >>>>>>> http://soundcloud.com/brandtsegg >>>>>>> http://soundcloud.com/t-emp >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> _______________________________________________ >>>>>>> Csound-devel mailing list >>>>>>> Csound-devel@lists.sourceforge.net >>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> _______________________________________________ >>>>>> Csound-devel mailing list >>>>>> Csound-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Oeyvind Brandtsegg >>>>> Professor of Music Technology >>>>> NTNU >>>>> 7491 Trondheim >>>>> Norway >>>>> Cell: +47 92 203 205 >>>>> >>>>> http://flyndresang.no/ >>>>> http://www.partikkelaudio.com/ >>>>> http://soundcloud.com/brandtsegg >>>>> http://soundcloud.com/t-emp >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Csound-devel mailing list >>>>> Csound-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> Csound-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > ------------------------------------------------------------------------------ > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel -- Oeyvind Brandtsegg Professor of Music Technology NTNU 7491 Trondheim Norway Cell: +47 92 203 205 http://flyndresang.no/ http://www.partikkelaudio.com/ http://soundcloud.com/brandtsegg http://soundcloud.com/t-emp ------------------------------------------------------------------------------ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2014-04-04 13:54
From	Steven Yi
Subject	Re: [Cs-dev] i(kswitch+1)
	We could do it as part of the parser, perhaps when we're walking the parse tree. I guess compilers in general do issue warnings for coding patterns, so it might make sense. It just feels odd as it's a very specific scenario for a single opcode. Anyways, if we do this, we should probably create a generic checkForWarnings() kind of function that would then do the check. We could then extend what checks we do. We could then add flags, similarly to how gcc has -Wall, -Wno-some-option, -Wno-deprecated, etc. That'd give some control then to users to turn off certain warning types. What I wouldn't like is just some code to be hacked in, and would prefer a framework for warnings to be done. On Fri, Apr 4, 2014 at 8:45 AM, Oeyvind Brandtsegg wrote: > Just to note, if by the original code you mean the example I sent, it > was a simplified test just to show the problem. > The reinit was needed in the actual code where I discovered the problem. > > Wouldn't it be ok to catch the k-rate expression inside i() at the > preprocessing stage? > > Oeyvind > > 2014-04-04 14:37 GMT+02:00 Steven Yi : >> I don't think it should be sum.i, as the compiler detects correctly >> that the expression being used is a k-rate one. The original code >> could have been re-written as: >> >> i2 = i(kswitch) + 1 >> >> which would have worked fine. >> >> I think though that the original code could probably be modified to be >> a bit simpler. It's not clear why there's a re-init being used, and >> if there isn't a better way to go about it. >> >> On Fri, Apr 4, 2014 at 8:32 AM, Victor Lazzarini >> wrote: >>> Shouldn't it be sum.i then? >>> ======================== >>> Dr Victor Lazzarini >>> Senior Lecturer >>> NUI Maynooth, Ireland >>> victor dot lazzarini at nuim dot ie >>> >>> >>> >>> >>> On 4 Apr 2014, at 13:22, Steven Yi wrote: >>> >>>> I think this might be sort of a hack to detect. What happens is that the line: >>>> >>>> i2 = i(kswitch+1) >>>> >>>> becomes something like: >>>> >>>> #k0 sum.k kswitch, 1 >>>> i2 = i(#k0) >>>> >>>> with the sum happening at perf-time, and #k0 being initialized to 0. >>>> The sum would not do anything a init-time, so #k0 just remains 0 when >>>> the i() goes to compute. >>>> >>>> >>>> >>>> On Fri, Apr 4, 2014 at 8:17 AM, Victor Lazzarini >>>> wrote: >>>>> Agreed that is an easy mistake and it should be protected somehow, but not sure how to tackle it >>>>> right now. It would need to be made an exception in the parser. >>>>> ======================== >>>>> Dr Victor Lazzarini >>>>> Senior Lecturer >>>>> NUI Maynooth, Ireland >>>>> victor dot lazzarini at nuim dot ie >>>>> >>>>> >>>>> >>>>> >>>>> On 4 Apr 2014, at 12:24, Oeyvind Brandtsegg wrote: >>>>> >>>>>> I see, >>>>>> it is an easy mistake to make though. >>>>>> I see now that it is noted in the manual, >>>>>> but still, if one is not looking in the manual one could expect my >>>>>> original code to work. >>>>>> Could we make k-rate expressions illegal in this case, since it >>>>>> otherwise can lead to unexpected results. If the parser would stop and >>>>>> give an error message that k-rate expressions must be done outside the >>>>>> i(.), I think it would be very helpful. >>>>>> Oeyvind >>>>>> >>>>>> 2014-04-04 13:17 GMT+02:00 Victor Lazzarini : >>>>>>> it's because in i(.) the . has to be a variable (which is actually a memory address). >>>>>>> ======================== >>>>>>> Dr Victor Lazzarini >>>>>>> Senior Lecturer >>>>>>> NUI Maynooth, Ireland >>>>>>> victor dot lazzarini at nuim dot ie >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 4 Apr 2014, at 10:24, Oeyvind Brandtsegg wrote: >>>>>>> >>>>>>>> I wonder if this is a bug, >>>>>>>> I would expect i2 and i3 to be equal in the following example, but they are not. >>>>>>>> Almost as if i(kswitch+1) reads the previous i-time value of kswitch >>>>>>>> somehow (??) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> sr = 44100 >>>>>>>> kr = 441 >>>>>>>> ksmps = 100 >>>>>>>> nchnls = 2 >>>>>>>> >>>>>>>> instr 1 >>>>>>>> >>>>>>>> kmetro metro 1 >>>>>>>> kswitch init 0 >>>>>>>> kswitch = (kswitch+kmetro)%2 >>>>>>>> printk2 kswitch >>>>>>>> if kmetro > 0 then >>>>>>>> reinit testme >>>>>>>> endif >>>>>>>> >>>>>>>> testme: >>>>>>>> i1 = i(kswitch) >>>>>>>> i2 = i(kswitch+1) >>>>>>>> i3 = i1+1 >>>>>>>> print i1, i2, i3 >>>>>>>> rireturn >>>>>>>> >>>>>>>> endin >>>>>>>> >>>>>>>> >>>>>>>> i1 0 5 >>>>>>>> e >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Oeyvind Brandtsegg >>>>>>>> Professor of Music Technology >>>>>>>> NTNU >>>>>>>> 7491 Trondheim >>>>>>>> Norway >>>>>>>> Cell: +47 92 203 205 >>>>>>>> >>>>>>>> http://flyndresang.no/ >>>>>>>> http://www.partikkelaudio.com/ >>>>>>>> http://soundcloud.com/brandtsegg >>>>>>>> http://soundcloud.com/t-emp >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> _______________________________________________ >>>>>>>> Csound-devel mailing list >>>>>>>> Csound-devel@lists.sourceforge.net >>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> _______________________________________________ >>>>>>> Csound-devel mailing list >>>>>>> Csound-devel@lists.sourceforge.net >>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Oeyvind Brandtsegg >>>>>> Professor of Music Technology >>>>>> NTNU >>>>>> 7491 Trondheim >>>>>> Norway >>>>>> Cell: +47 92 203 205 >>>>>> >>>>>> http://flyndresang.no/ >>>>>> http://www.partikkelaudio.com/ >>>>>> http://soundcloud.com/brandtsegg >>>>>> http://soundcloud.com/t-emp >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> _______________________________________________ >>>>>> Csound-devel mailing list >>>>>> Csound-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Csound-devel mailing list >>>>> Csound-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> Csound-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > -- > > Oeyvind Brandtsegg > Professor of Music Technology > NTNU > 7491 Trondheim > Norway > Cell: +47 92 203 205 > > http://flyndresang.no/ > http://www.partikkelaudio.com/ > http://soundcloud.com/brandtsegg > http://soundcloud.com/t-emp > > ------------------------------------------------------------------------------ > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2014-04-04 14:42
From	jpff@cs.bath.ac.uk
Subject	Re: [Cs-dev] i(kswitch+1)
Attachments	None

Date	2014-04-04 15:20
From	Steven Yi
Subject	Re: [Cs-dev] i(kswitch+1)
	I think we could get a way with a simpler method, but looking at the parse tree for opcode or function nodes. If it's "i", then check if the argument is a single node or an expression, then issue a warning. We could probably add that check during one of the other tree walk phases and not use another phase. At least, in my head that'd work, but I'm not positive. On Fri, Apr 4, 2014 at 9:42 AM, wrote: > Would need to remove i from functions etc and lex it specially; think > it is doable. But behind in e-mail > > Quoting Victor Lazzarini : > >> Agreed that is an easy mistake and it should be protected somehow, >> but not sure how to tackle it >> right now. It would need to be made an exception in the parser. >> ======================== >> Dr Victor Lazzarini >> Senior Lecturer >> NUI Maynooth, Ireland >> victor dot lazzarini at nuim dot ie >> >> >> >> >> On 4 Apr 2014, at 12:24, Oeyvind Brandtsegg >> wrote: >> >>> I see, >>> it is an easy mistake to make though. >>> I see now that it is noted in the manual, >>> but still, if one is not looking in the manual one could expect my >>> original code to work. >>> Could we make k-rate expressions illegal in this case, since it >>> otherwise can lead to unexpected results. If the parser would stop and >>> give an error message that k-rate expressions must be done outside the >>> i(.), I think it would be very helpful. >>> Oeyvind >>> >>> 2014-04-04 13:17 GMT+02:00 Victor Lazzarini : >>>> it's because in i(.) the . has to be a variable (which is actually >>>> a memory address). >>>> ======================== >>>> Dr Victor Lazzarini >>>> Senior Lecturer >>>> NUI Maynooth, Ireland >>>> victor dot lazzarini at nuim dot ie >>>> >>>> >>>> >>>> >>>> On 4 Apr 2014, at 10:24, Oeyvind Brandtsegg >>>> wrote: >>>> >>>>> I wonder if this is a bug, >>>>> I would expect i2 and i3 to be equal in the following example, >>>>> but they are not. >>>>> Almost as if i(kswitch+1) reads the previous i-time value of kswitch >>>>> somehow (??) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> sr = 44100 >>>>> kr = 441 >>>>> ksmps = 100 >>>>> nchnls = 2 >>>>> >>>>> instr 1 >>>>> >>>>> kmetro metro 1 >>>>> kswitch init 0 >>>>> kswitch = (kswitch+kmetro)%2 >>>>> printk2 kswitch >>>>> if kmetro > 0 then >>>>> reinit testme >>>>> endif >>>>> >>>>> testme: >>>>> i1 = i(kswitch) >>>>> i2 = i(kswitch+1) >>>>> i3 = i1+1 >>>>> print i1, i2, i3 >>>>> rireturn >>>>> >>>>> endin >>>>> >>>>> >>>>> i1 0 5 >>>>> e >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Oeyvind Brandtsegg >>>>> Professor of Music Technology >>>>> NTNU >>>>> 7491 Trondheim >>>>> Norway >>>>> Cell: +47 92 203 205 >>>>> >>>>> http://flyndresang.no/ >>>>> http://www.partikkelaudio.com/ >>>>> http://soundcloud.com/brandtsegg >>>>> http://soundcloud.com/t-emp >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Csound-devel mailing list >>>>> Csound-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> Csound-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> >>> >>> -- >>> >>> Oeyvind Brandtsegg >>> Professor of Music Technology >>> NTNU >>> 7491 Trondheim >>> Norway >>> Cell: +47 92 203 205 >>> >>> http://flyndresang.no/ >>> http://www.partikkelaudio.com/ >>> http://soundcloud.com/brandtsegg >>> http://soundcloud.com/t-emp >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2014-04-04 18:07
From	jpff@cs.bath.ac.uk
Subject	Re: [Cs-dev] i(kswitch+1)
Attachments	None

Date	2014-04-04 18:13
From	Steven Yi
Subject	Re: [Cs-dev] i(kswitch+1)
	Hi John, I think I'll have my hands a bit full with trying to get the installer for csound~ put together, so you're welcome to take this one over. It seems like having a csound_orc_warnings.c/.h would be good, where we could eventually add other warning detection functions. I figured we could call the code from there in csound_orc_expressions.c for now for the i(k-expr) check. Just some stray thoughts though, perhaps there's a better way. One thing: Oeyvind, could you file an issue for this on the tracker? It'd be good to keep tabs of this item. You can set the asignee to John (jpff) on github. Thanks! steven On Fri, Apr 4, 2014 at 1:07 PM, wrote: > That move it from a syntax issue to a semantics one and will work > better with array access > You doing it or should I try? > > ==John > > Quoting Steven Yi : > >> I think we could get a way with a simpler method, but looking at the >> parse tree for opcode or function nodes. If it's "i", then check if >> the argument is a single node or an expression, then issue a warning. >> We could probably add that check during one of the other tree walk >> phases and not use another phase. At least, in my head that'd work, >> but I'm not positive. >> >> On Fri, Apr 4, 2014 at 9:42 AM, wrote: >>> Would need to remove i from functions etc and lex it specially; think >>> it is doable. But behind in e-mail >>> >>> Quoting Victor Lazzarini : >>> >>>> Agreed that is an easy mistake and it should be protected somehow, >>>> but not sure how to tackle it >>>> right now. It would need to be made an exception in the parser. >>>> ======================== >>>> Dr Victor Lazzarini >>>> Senior Lecturer >>>> NUI Maynooth, Ireland >>>> victor dot lazzarini at nuim dot ie >>>> >>>> >>>> >>>> >>>> On 4 Apr 2014, at 12:24, Oeyvind Brandtsegg >>>> wrote: >>>> >>>>> I see, >>>>> it is an easy mistake to make though. >>>>> I see now that it is noted in the manual, >>>>> but still, if one is not looking in the manual one could expect my >>>>> original code to work. >>>>> Could we make k-rate expressions illegal in this case, since it >>>>> otherwise can lead to unexpected results. If the parser would stop and >>>>> give an error message that k-rate expressions must be done outside the >>>>> i(.), I think it would be very helpful. >>>>> Oeyvind >>>>> >>>>> 2014-04-04 13:17 GMT+02:00 Victor Lazzarini : >>>>>> it's because in i(.) the . has to be a variable (which is actually >>>>>> a memory address). >>>>>> ======================== >>>>>> Dr Victor Lazzarini >>>>>> Senior Lecturer >>>>>> NUI Maynooth, Ireland >>>>>> victor dot lazzarini at nuim dot ie >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 4 Apr 2014, at 10:24, Oeyvind Brandtsegg >>>>>> wrote: >>>>>> >>>>>>> I wonder if this is a bug, >>>>>>> I would expect i2 and i3 to be equal in the following example, >>>>>>> but they are not. >>>>>>> Almost as if i(kswitch+1) reads the previous i-time value of kswitch >>>>>>> somehow (??) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> sr = 44100 >>>>>>> kr = 441 >>>>>>> ksmps = 100 >>>>>>> nchnls = 2 >>>>>>> >>>>>>> instr 1 >>>>>>> >>>>>>> kmetro metro 1 >>>>>>> kswitch init 0 >>>>>>> kswitch = (kswitch+kmetro)%2 >>>>>>> printk2 kswitch >>>>>>> if kmetro > 0 then >>>>>>> reinit testme >>>>>>> endif >>>>>>> >>>>>>> testme: >>>>>>> i1 = i(kswitch) >>>>>>> i2 = i(kswitch+1) >>>>>>> i3 = i1+1 >>>>>>> print i1, i2, i3 >>>>>>> rireturn >>>>>>> >>>>>>> endin >>>>>>> >>>>>>> >>>>>>> i1 0 5 >>>>>>> e >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Oeyvind Brandtsegg >>>>>>> Professor of Music Technology >>>>>>> NTNU >>>>>>> 7491 Trondheim >>>>>>> Norway >>>>>>> Cell: +47 92 203 205 >>>>>>> >>>>>>> http://flyndresang.no/ >>>>>>> http://www.partikkelaudio.com/ >>>>>>> http://soundcloud.com/brandtsegg >>>>>>> http://soundcloud.com/t-emp >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> _______________________________________________ >>>>>>> Csound-devel mailing list >>>>>>> Csound-devel@lists.sourceforge.net >>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> _______________________________________________ >>>>>> Csound-devel mailing list >>>>>> Csound-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Oeyvind Brandtsegg >>>>> Professor of Music Technology >>>>> NTNU >>>>> 7491 Trondheim >>>>> Norway >>>>> Cell: +47 92 203 205 >>>>> >>>>> http://flyndresang.no/ >>>>> http://www.partikkelaudio.com/ >>>>> http://soundcloud.com/brandtsegg >>>>> http://soundcloud.com/t-emp >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Csound-devel mailing list >>>>> Csound-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> Csound-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2014-04-06 20:29
From	Oeyvind Brandtsegg
Subject	Re: [Cs-dev] i(kswitch+1)
	Ok. Done. I couldn't figure out how to assign it to someone specific(?) It is my opinion that k-rate expressions in i() should not be allowed (not just generate a warning). Even though I'm usually in favor of features that can be exploited creatively, in cases where it "can generate unexpected results" why would we want to allow that in our language? In this case, manipulating the pointer to a value with something that looks as if we manipulate the value itself. It seems .. hmm. .. quirky? Just an opinion, and I'm open to arguments why it should be allowed of course. Oeyvind 2014-04-04 19:13 GMT+02:00 Steven Yi : > Hi John, > > I think I'll have my hands a bit full with trying to get the installer > for csound~ put together, so you're welcome to take this one over. It > seems like having a csound_orc_warnings.c/.h would be good, where we > could eventually add other warning detection functions. I figured we > could call the code from there in csound_orc_expressions.c for now for > the i(k-expr) check. Just some stray thoughts though, perhaps there's > a better way. > > One thing: Oeyvind, could you file an issue for this on the tracker? > It'd be good to keep tabs of this item. You can set the asignee to > John (jpff) on github. > > Thanks! > steven > > On Fri, Apr 4, 2014 at 1:07 PM, wrote: >> That move it from a syntax issue to a semantics one and will work >> better with array access >> You doing it or should I try? >> >> ==John >> >> Quoting Steven Yi : >> >>> I think we could get a way with a simpler method, but looking at the >>> parse tree for opcode or function nodes. If it's "i", then check if >>> the argument is a single node or an expression, then issue a warning. >>> We could probably add that check during one of the other tree walk >>> phases and not use another phase. At least, in my head that'd work, >>> but I'm not positive. >>> >>> On Fri, Apr 4, 2014 at 9:42 AM, wrote: >>>> Would need to remove i from functions etc and lex it specially; think >>>> it is doable. But behind in e-mail >>>> >>>> Quoting Victor Lazzarini : >>>> >>>>> Agreed that is an easy mistake and it should be protected somehow, >>>>> but not sure how to tackle it >>>>> right now. It would need to be made an exception in the parser. >>>>> ======================== >>>>> Dr Victor Lazzarini >>>>> Senior Lecturer >>>>> NUI Maynooth, Ireland >>>>> victor dot lazzarini at nuim dot ie >>>>> >>>>> >>>>> >>>>> >>>>> On 4 Apr 2014, at 12:24, Oeyvind Brandtsegg >>>>> wrote: >>>>> >>>>>> I see, >>>>>> it is an easy mistake to make though. >>>>>> I see now that it is noted in the manual, >>>>>> but still, if one is not looking in the manual one could expect my >>>>>> original code to work. >>>>>> Could we make k-rate expressions illegal in this case, since it >>>>>> otherwise can lead to unexpected results. If the parser would stop and >>>>>> give an error message that k-rate expressions must be done outside the >>>>>> i(.), I think it would be very helpful. >>>>>> Oeyvind >>>>>> >>>>>> 2014-04-04 13:17 GMT+02:00 Victor Lazzarini : >>>>>>> it's because in i(.) the . has to be a variable (which is actually >>>>>>> a memory address). >>>>>>> ======================== >>>>>>> Dr Victor Lazzarini >>>>>>> Senior Lecturer >>>>>>> NUI Maynooth, Ireland >>>>>>> victor dot lazzarini at nuim dot ie >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 4 Apr 2014, at 10:24, Oeyvind Brandtsegg >>>>>>> wrote: >>>>>>> >>>>>>>> I wonder if this is a bug, >>>>>>>> I would expect i2 and i3 to be equal in the following example, >>>>>>>> but they are not. >>>>>>>> Almost as if i(kswitch+1) reads the previous i-time value of kswitch >>>>>>>> somehow (??) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> sr = 44100 >>>>>>>> kr = 441 >>>>>>>> ksmps = 100 >>>>>>>> nchnls = 2 >>>>>>>> >>>>>>>> instr 1 >>>>>>>> >>>>>>>> kmetro metro 1 >>>>>>>> kswitch init 0 >>>>>>>> kswitch = (kswitch+kmetro)%2 >>>>>>>> printk2 kswitch >>>>>>>> if kmetro > 0 then >>>>>>>> reinit testme >>>>>>>> endif >>>>>>>> >>>>>>>> testme: >>>>>>>> i1 = i(kswitch) >>>>>>>> i2 = i(kswitch+1) >>>>>>>> i3 = i1+1 >>>>>>>> print i1, i2, i3 >>>>>>>> rireturn >>>>>>>> >>>>>>>> endin >>>>>>>> >>>>>>>> >>>>>>>> i1 0 5 >>>>>>>> e >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Oeyvind Brandtsegg >>>>>>>> Professor of Music Technology >>>>>>>> NTNU >>>>>>>> 7491 Trondheim >>>>>>>> Norway >>>>>>>> Cell: +47 92 203 205 >>>>>>>> >>>>>>>> http://flyndresang.no/ >>>>>>>> http://www.partikkelaudio.com/ >>>>>>>> http://soundcloud.com/brandtsegg >>>>>>>> http://soundcloud.com/t-emp >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> _______________________________________________ >>>>>>>> Csound-devel mailing list >>>>>>>> Csound-devel@lists.sourceforge.net >>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> _______________________________________________ >>>>>>> Csound-devel mailing list >>>>>>> Csound-devel@lists.sourceforge.net >>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Oeyvind Brandtsegg >>>>>> Professor of Music Technology >>>>>> NTNU >>>>>> 7491 Trondheim >>>>>> Norway >>>>>> Cell: +47 92 203 205 >>>>>> >>>>>> http://flyndresang.no/ >>>>>> http://www.partikkelaudio.com/ >>>>>> http://soundcloud.com/brandtsegg >>>>>> http://soundcloud.com/t-emp >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> _______________________________________________ >>>>>> Csound-devel mailing list >>>>>> Csound-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Csound-devel mailing list >>>>> Csound-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> Csound-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > ------------------------------------------------------------------------------ > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel -- Oeyvind Brandtsegg Professor of Music Technology NTNU 7491 Trondheim Norway Cell: +47 92 203 205 http://flyndresang.no/ http://www.partikkelaudio.com/ http://soundcloud.com/brandtsegg http://soundcloud.com/t-emp ------------------------------------------------------------------------------ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2014-04-06 20:33
From	Victor Lazzarini
Subject	Re: [Cs-dev] i(kswitch+1)
	I think my analysis may have been wrong and this is actually a plain bug, but I’ll stop giving my opinion on this and let John or Steven fix it. ======================== Dr Victor Lazzarini Senior Lecturer NUI Maynooth, Ireland victor dot lazzarini at nuim dot ie On 6 Apr 2014, at 20:29, Oeyvind Brandtsegg wrote: > Ok. Done. > I couldn't figure out how to assign it to someone specific(?) > > It is my opinion that k-rate expressions in i() should not be allowed > (not just generate a warning). > Even though I'm usually in favor of features that can be exploited > creatively, in cases where it "can generate unexpected results" why > would we want to allow that in our language? > In this case, manipulating the pointer to a value with something that > looks as if we manipulate the value itself. It seems .. hmm. .. > quirky? > Just an opinion, and I'm open to arguments why it should be allowed of course. > > Oeyvind > > > > 2014-04-04 19:13 GMT+02:00 Steven Yi : >> Hi John, >> >> I think I'll have my hands a bit full with trying to get the installer >> for csound~ put together, so you're welcome to take this one over. It >> seems like having a csound_orc_warnings.c/.h would be good, where we >> could eventually add other warning detection functions. I figured we >> could call the code from there in csound_orc_expressions.c for now for >> the i(k-expr) check. Just some stray thoughts though, perhaps there's >> a better way. >> >> One thing: Oeyvind, could you file an issue for this on the tracker? >> It'd be good to keep tabs of this item. You can set the asignee to >> John (jpff) on github. >> >> Thanks! >> steven >> >> On Fri, Apr 4, 2014 at 1:07 PM, wrote: >>> That move it from a syntax issue to a semantics one and will work >>> better with array access >>> You doing it or should I try? >>> >>> ==John >>> >>> Quoting Steven Yi : >>> >>>> I think we could get a way with a simpler method, but looking at the >>>> parse tree for opcode or function nodes. If it's "i", then check if >>>> the argument is a single node or an expression, then issue a warning. >>>> We could probably add that check during one of the other tree walk >>>> phases and not use another phase. At least, in my head that'd work, >>>> but I'm not positive. >>>> >>>> On Fri, Apr 4, 2014 at 9:42 AM, wrote: >>>>> Would need to remove i from functions etc and lex it specially; think >>>>> it is doable. But behind in e-mail >>>>> >>>>> Quoting Victor Lazzarini : >>>>> >>>>>> Agreed that is an easy mistake and it should be protected somehow, >>>>>> but not sure how to tackle it >>>>>> right now. It would need to be made an exception in the parser. >>>>>> ======================== >>>>>> Dr Victor Lazzarini >>>>>> Senior Lecturer >>>>>> NUI Maynooth, Ireland >>>>>> victor dot lazzarini at nuim dot ie >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 4 Apr 2014, at 12:24, Oeyvind Brandtsegg >>>>>> wrote: >>>>>> >>>>>>> I see, >>>>>>> it is an easy mistake to make though. >>>>>>> I see now that it is noted in the manual, >>>>>>> but still, if one is not looking in the manual one could expect my >>>>>>> original code to work. >>>>>>> Could we make k-rate expressions illegal in this case, since it >>>>>>> otherwise can lead to unexpected results. If the parser would stop and >>>>>>> give an error message that k-rate expressions must be done outside the >>>>>>> i(.), I think it would be very helpful. >>>>>>> Oeyvind >>>>>>> >>>>>>> 2014-04-04 13:17 GMT+02:00 Victor Lazzarini : >>>>>>>> it's because in i(.) the . has to be a variable (which is actually >>>>>>>> a memory address). >>>>>>>> ======================== >>>>>>>> Dr Victor Lazzarini >>>>>>>> Senior Lecturer >>>>>>>> NUI Maynooth, Ireland >>>>>>>> victor dot lazzarini at nuim dot ie >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 4 Apr 2014, at 10:24, Oeyvind Brandtsegg >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I wonder if this is a bug, >>>>>>>>> I would expect i2 and i3 to be equal in the following example, >>>>>>>>> but they are not. >>>>>>>>> Almost as if i(kswitch+1) reads the previous i-time value of kswitch >>>>>>>>> somehow (??) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> sr = 44100 >>>>>>>>> kr = 441 >>>>>>>>> ksmps = 100 >>>>>>>>> nchnls = 2 >>>>>>>>> >>>>>>>>> instr 1 >>>>>>>>> >>>>>>>>> kmetro metro 1 >>>>>>>>> kswitch init 0 >>>>>>>>> kswitch = (kswitch+kmetro)%2 >>>>>>>>> printk2 kswitch >>>>>>>>> if kmetro > 0 then >>>>>>>>> reinit testme >>>>>>>>> endif >>>>>>>>> >>>>>>>>> testme: >>>>>>>>> i1 = i(kswitch) >>>>>>>>> i2 = i(kswitch+1) >>>>>>>>> i3 = i1+1 >>>>>>>>> print i1, i2, i3 >>>>>>>>> rireturn >>>>>>>>> >>>>>>>>> endin >>>>>>>>> >>>>>>>>> >>>>>>>>> i1 0 5 >>>>>>>>> e >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Oeyvind Brandtsegg >>>>>>>>> Professor of Music Technology >>>>>>>>> NTNU >>>>>>>>> 7491 Trondheim >>>>>>>>> Norway >>>>>>>>> Cell: +47 92 203 205 >>>>>>>>> >>>>>>>>> http://flyndresang.no/ >>>>>>>>> http://www.partikkelaudio.com/ >>>>>>>>> http://soundcloud.com/brandtsegg >>>>>>>>> http://soundcloud.com/t-emp >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>> _______________________________________________ >>>>>>>>> Csound-devel mailing list >>>>>>>>> Csound-devel@lists.sourceforge.net >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> _______________________________________________ >>>>>>>> Csound-devel mailing list >>>>>>>> Csound-devel@lists.sourceforge.net >>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Oeyvind Brandtsegg >>>>>>> Professor of Music Technology >>>>>>> NTNU >>>>>>> 7491 Trondheim >>>>>>> Norway >>>>>>> Cell: +47 92 203 205 >>>>>>> >>>>>>> http://flyndresang.no/ >>>>>>> http://www.partikkelaudio.com/ >>>>>>> http://soundcloud.com/brandtsegg >>>>>>> http://soundcloud.com/t-emp >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> _______________________________________________ >>>>>>> Csound-devel mailing list >>>>>>> Csound-devel@lists.sourceforge.net >>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> _______________________________________________ >>>>>> Csound-devel mailing list >>>>>> Csound-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> Csound-devel mailing list >>>>> Csound-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Csound-devel mailing list >>>> Csound-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > -- > > Oeyvind Brandtsegg > Professor of Music Technology > NTNU > 7491 Trondheim > Norway > Cell: +47 92 203 205 > > http://flyndresang.no/ > http://www.partikkelaudio.com/ > http://soundcloud.com/brandtsegg > http://soundcloud.com/t-emp > > ------------------------------------------------------------------------------ > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel ------------------------------------------------------------------------------ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2014-04-08 11:44
From	ebmtranceboy
Subject	Re: [Cs-dev] i(kswitch+1)
	What does the # of #k0 mean in Steven's reply ? -- View this message in context: http://csound.1045644.n5.nabble.com/i-kswitch-1-tp5733873p5733999.html Sent from the Csound - Dev mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2014-04-08 15:39
From	jpff@cs.bath.ac.uk
Subject	Re: [Cs-dev] i(kswitch+1)
Attachments	None