[Csnd] transegr issue

[Csnd] transegr issue

Date	2011-10-09 16:37
From	menno
Subject	[Csnd] transegr issue
	Hi, i find the transegr opcode very unstable, csound crashes quickly when playing the virtual midi keyboard with this example. Can someone tell me why? thanks Menno ; Select audio/midi flags here according to platform -odac -+rtmidi=virtual -M0 ;;;realtime audio out and realtime midi in ;-iadc ;;;uncomment -iadc if realtime audio input is needed too ; For Non-realtime ouput leave only the line below: ; -o transegr.wav -W ;;; for file output any platform sr = 44100 ksmps = 32 nchnls = 2 0dbfs = 1 instr 1 icps cpsmidi iamp ampmidi .2 ; st,dur1,typ1,val,dur2,typ2,end kenv transegr 0, .2, 2, .5, 1, - 3, 2 asig pluck kenv*iamp, icps, icps, 1, 1 outs asig, asig endin f1 0 4096 10 1 ;sine f0 30 ;runs 30 seconds e -- View this message in context: http://csound.1045644.n5.nabble.com/transegr-issue-tp4885520p4885520.html Sent from the Csound - General mailing list archive at Nabble.com. 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 sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-10-09 20:02
From	Victor Lazzarini
Subject	Re: [Csnd] transegr issue
	it's pretty stable here on OSX... no crashes. Victor On 9 Oct 2011, at 16:37, menno wrote: > Hi, > > i find the transegr opcode very unstable, csound crashes quickly when > playing the virtual midi keyboard with this example. > Can someone tell me why? > > thanks > Menno > > > > ; Select audio/midi flags here according to platform > -odac -+rtmidi=virtual -M0 ;;;realtime audio out and realtime midi > in > ;-iadc ;;;uncomment -iadc if realtime audio input is needed too > ; For Non-realtime ouput leave only the line below: > ; -o transegr.wav -W ;;; for file output any platform > > > > sr = 44100 > ksmps = 32 > nchnls = 2 > 0dbfs = 1 > > instr 1 > > icps cpsmidi > iamp ampmidi .2 > ; st,dur1,typ1,val,dur2,typ2,end > kenv transegr 0, .2, 2, .5, 1, - 3, 2 > asig pluck kenv*iamp, icps, icps, 1, 1 > outs asig, asig > > > endin > > > f1 0 4096 10 1 ;sine > > f0 30 ;runs 30 seconds > e > > > > > -- > View this message in context: http://csound.1045644.n5.nabble.com/transegr-issue-tp4885520p4885520.html > Sent from the Csound - General mailing list archive at Nabble.com. > > > 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 sympa@lists.bath.ac.uk with body > "unsubscribe csound" > Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie 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 sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-10-09 21:21
From	Steven Yi
Subject	Re: [Csnd] transegr issue
	I'm on OSX, but am getting crashes. Running in GDB I get: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x00000001004fac5b in ktrnsegr (csound=0x100800000, p=0x101982c98) at pitch.c:1992 1992 if (!(p->curcnt = segp->cnt)) { /* nonlen = discontin / (gdb) print p $1 = (TRANSEG ) 0x1030f4098 (gdb) print p->curcnt $2 = 21 (gdb) print segp $3 = (NSEG ) 0x0 (gdb) It happens during the release segment here for me. It didn't always happen, some runs I had to hit more notes than other before it would die. Also, the behavior was erratic, sometimes it would suddenly shoot to inf for audio (my ears are ringing a bit!). The crash is happening due to trying to dereference the null NSEG, but the code is a bit tricky to follow since there's a goto in there. I'm full up for tonight with other work, but perhaps John could take a look (I think he wrote transegr?). Thanks, steven On Sun, Oct 9, 2011 at 8:02 PM, Victor Lazzarini wrote: > it's pretty stable here on OSX... no crashes. > > Victor > On 9 Oct 2011, at 16:37, menno wrote: > >> Hi, >> >> i find the transegr opcode very unstable, csound crashes quickly when >> playing the virtual midi keyboard with this example. >> Can someone tell me why? >> >> thanks >> Menno >> >> >> >> ; Select audio/midi flags here according to platform >> -odac -+rtmidi=virtual -M0 ;;;realtime audio out and realtime midi in >> ;-iadc ;;;uncomment -iadc if realtime audio input is needed too >> ; For Non-realtime ouput leave only the line below: >> ; -o transegr.wav -W ;;; for file output any platform >> >> >> >> sr = 44100 >> ksmps = 32 >> nchnls = 2 >> 0dbfs = 1 >> >> instr 1 >> >> icps cpsmidi >> iamp ampmidi .2 >> ; st,dur1,typ1,val,dur2,typ2,end >> kenv transegr 0, .2, 2, .5, 1, - 3, 2 >> asig pluck kenviamp, icps, icps, 1, 1 >> outs asig, asig >> >> >> endin >> >> >> f1 0 4096 10 1 ;sine >> >> f0 30 ;runs 30 seconds >> e >> >> >> >> >> -- >> View this message in context: >> http://csound.1045644.n5.nabble.com/transegr-issue-tp4885520p4885520.html >> Sent from the Csound - General mailing list archive at Nabble.com. >> >> >> 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 sympa@lists.bath.ac.uk with body "unsubscribe >> csound" >> > > Dr Victor Lazzarini > Senior Lecturer > Dept. of Music > NUI Maynooth Ireland > tel.: +353 1 708 3545 > Victor dot Lazzarini AT nuim dot ie > > > > > > 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-10-09 21:41
From	Victor Lazzarini
Subject	Re: [Csnd] transegr issue
	maybe it's a 64 bit OS issue? On 9 Oct 2011, at 21:21, Steven Yi wrote: > I'm on OSX, but am getting crashes. Running in GDB I get: > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 > 0x00000001004fac5b in ktrnsegr (csound=0x100800000, p=0x101982c98) at > pitch.c:1992 > 1992 if (!(p->curcnt = segp->cnt)) { /* nonlen = discontin > / > (gdb) print p > $1 = (TRANSEG ) 0x1030f4098 > (gdb) print p->curcnt > $2 = 21 > (gdb) print segp > $3 = (NSEG ) 0x0 > (gdb) > > It happens during the release segment here for me. It didn't always > happen, some runs I had to hit more notes than other before it would > die. Also, the behavior was erratic, sometimes it would suddenly > shoot to inf for audio (my ears are ringing a bit!). The crash is > happening due to trying to dereference the null NSEG, but > the code is a bit tricky to follow since there's a goto in there. I'm > full up for tonight with other work, but perhaps John could take a > look (I think he wrote transegr?). > > Thanks, > steven > > On Sun, Oct 9, 2011 at 8:02 PM, Victor Lazzarini > wrote: >> it's pretty stable here on OSX... no crashes. >> >> Victor >> On 9 Oct 2011, at 16:37, menno wrote: >> >>> Hi, >>> >>> i find the transegr opcode very unstable, csound crashes quickly >>> when >>> playing the virtual midi keyboard with this example. >>> Can someone tell me why? >>> >>> thanks >>> Menno >>> >>> >>> >>> ; Select audio/midi flags here according to platform >>> -odac -+rtmidi=virtual -M0 ;;;realtime audio out and realtime >>> midi in >>> ;-iadc ;;;uncomment -iadc if realtime audio input is needed too >>> ; For Non-realtime ouput leave only the line below: >>> ; -o transegr.wav -W ;;; for file output any platform >>> >>> >>> >>> sr = 44100 >>> ksmps = 32 >>> nchnls = 2 >>> 0dbfs = 1 >>> >>> instr 1 >>> >>> icps cpsmidi >>> iamp ampmidi .2 >>> ; st,dur1,typ1,val,dur2,typ2,end >>> kenv transegr 0, .2, 2, .5, 1, - 3, 2 >>> asig pluck kenviamp, icps, icps, 1, 1 >>> outs asig, asig >>> >>> >>> endin >>> >>> >>> f1 0 4096 10 1 ;sine >>> >>> f0 30 ;runs 30 seconds >>> e >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://csound.1045644.n5.nabble.com/transegr-issue-tp4885520p4885520.html >>> Sent from the Csound - General mailing list archive at Nabble.com. >>> >>> >>> 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 sympa@lists.bath.ac.uk with body >>> "unsubscribe >>> csound" >>> >> >> Dr Victor Lazzarini >> Senior Lecturer >> Dept. of Music >> NUI Maynooth Ireland >> tel.: +353 1 708 3545 >> Victor dot Lazzarini AT nuim dot ie >> >> >> >> >> >> 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk with body > "unsubscribe csound" > Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie 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 sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-10-09 21:43
From	Steven Yi
Subject	Re: [Csnd] transegr issue
	I'm not sure, Menno, what OS are you using and is it 32-bit or 64-bit? On Sun, Oct 9, 2011 at 9:41 PM, Victor Lazzarini wrote: > maybe it's a 64 bit OS issue? > On 9 Oct 2011, at 21:21, Steven Yi wrote: > >> I'm on OSX, but am getting crashes. Running in GDB I get: >> >> Program received signal EXC_BAD_ACCESS, Could not access memory. >> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 >> 0x00000001004fac5b in ktrnsegr (csound=0x100800000, p=0x101982c98) at >> pitch.c:1992 >> 1992 if (!(p->curcnt = segp->cnt)) { /* nonlen = discontin / >> (gdb) print p >> $1 = (TRANSEG ) 0x1030f4098 >> (gdb) print p->curcnt >> $2 = 21 >> (gdb) print segp >> $3 = (NSEG ) 0x0 >> (gdb) >> >> It happens during the release segment here for me. It didn't always >> happen, some runs I had to hit more notes than other before it would >> die. Also, the behavior was erratic, sometimes it would suddenly >> shoot to inf for audio (my ears are ringing a bit!). The crash is >> happening due to trying to dereference the null NSEG, but >> the code is a bit tricky to follow since there's a goto in there. I'm >> full up for tonight with other work, but perhaps John could take a >> look (I think he wrote transegr?). >> >> Thanks, >> steven >> >> On Sun, Oct 9, 2011 at 8:02 PM, Victor Lazzarini >> wrote: >>> >>> it's pretty stable here on OSX... no crashes. >>> >>> Victor >>> On 9 Oct 2011, at 16:37, menno wrote: >>> >>>> Hi, >>>> >>>> i find the transegr opcode very unstable, csound crashes quickly when >>>> playing the virtual midi keyboard with this example. >>>> Can someone tell me why? >>>> >>>> thanks >>>> Menno >>>> >>>> >>>> >>>> ; Select audio/midi flags here according to platform >>>> -odac -+rtmidi=virtual -M0 ;;;realtime audio out and realtime midi in >>>> ;-iadc ;;;uncomment -iadc if realtime audio input is needed too >>>> ; For Non-realtime ouput leave only the line below: >>>> ; -o transegr.wav -W ;;; for file output any platform >>>> >>>> >>>> >>>> sr = 44100 >>>> ksmps = 32 >>>> nchnls = 2 >>>> 0dbfs = 1 >>>> >>>> instr 1 >>>> >>>> icps cpsmidi >>>> iamp ampmidi .2 >>>> ; st,dur1,typ1,val,dur2,typ2,end >>>> kenv transegr 0, .2, 2, .5, 1, - 3, 2 >>>> asig pluck kenviamp, icps, icps, 1, 1 >>>> outs asig, asig >>>> >>>> >>>> endin >>>> >>>> >>>> f1 0 4096 10 1 ;sine >>>> >>>> f0 30 ;runs 30 seconds >>>> e >>>> >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> >>>> http://csound.1045644.n5.nabble.com/transegr-issue-tp4885520p4885520.html >>>> Sent from the Csound - General mailing list archive at Nabble.com. >>>> >>>> >>>> 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 sympa@lists.bath.ac.uk with body "unsubscribe >>>> csound" >>>> >>> >>> Dr Victor Lazzarini >>> Senior Lecturer >>> Dept. of Music >>> NUI Maynooth Ireland >>> tel.: +353 1 708 3545 >>> Victor dot Lazzarini AT nuim dot ie >>> >>> >>> >>> >>> >>> 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk with body "unsubscribe >> csound" >> > > Dr Victor Lazzarini > Senior Lecturer > Dept. of Music > NUI Maynooth Ireland > tel.: +353 1 708 3545 > Victor dot Lazzarini AT nuim dot ie > > > > > > 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-10-09 21:51
From	Victor Lazzarini
Subject	Re: [Csnd] transegr issue
	it does not crash here at all, in floats or doubles, OSX10.5 i386 On 9 Oct 2011, at 21:43, Steven Yi wrote: > I'm not sure, Menno, what OS are you using and is it 32-bit or 64-bit? > > On Sun, Oct 9, 2011 at 9:41 PM, Victor Lazzarini > wrote: >> maybe it's a 64 bit OS issue? >> On 9 Oct 2011, at 21:21, Steven Yi wrote: >> >>> I'm on OSX, but am getting crashes. Running in GDB I get: >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 >>> 0x00000001004fac5b in ktrnsegr (csound=0x100800000, p=0x101982c98) >>> at >>> pitch.c:1992 >>> 1992 if (!(p->curcnt = segp->cnt)) { /* nonlen = >>> discontin / >>> (gdb) print p >>> $1 = (TRANSEG ) 0x1030f4098 >>> (gdb) print p->curcnt >>> $2 = 21 >>> (gdb) print segp >>> $3 = (NSEG ) 0x0 >>> (gdb) >>> >>> It happens during the release segment here for me. It didn't always >>> happen, some runs I had to hit more notes than other before it would >>> die. Also, the behavior was erratic, sometimes it would suddenly >>> shoot to inf for audio (my ears are ringing a bit!). The crash is >>> happening due to trying to dereference the null NSEG, but >>> the code is a bit tricky to follow since there's a goto in there. >>> I'm >>> full up for tonight with other work, but perhaps John could take a >>> look (I think he wrote transegr?). >>> >>> Thanks, >>> steven >>> >>> On Sun, Oct 9, 2011 at 8:02 PM, Victor Lazzarini >>> wrote: >>>> >>>> it's pretty stable here on OSX... no crashes. >>>> >>>> Victor >>>> On 9 Oct 2011, at 16:37, menno wrote: >>>> >>>>> Hi, >>>>> >>>>> i find the transegr opcode very unstable, csound crashes quickly >>>>> when >>>>> playing the virtual midi keyboard with this example. >>>>> Can someone tell me why? >>>>> >>>>> thanks >>>>> Menno >>>>> >>>>> >>>>> >>>>> ; Select audio/midi flags here according to platform >>>>> -odac -+rtmidi=virtual -M0 ;;;realtime audio out and realtime >>>>> midi in >>>>> ;-iadc ;;;uncomment -iadc if realtime audio input is needed too >>>>> ; For Non-realtime ouput leave only the line below: >>>>> ; -o transegr.wav -W ;;; for file output any platform >>>>> >>>>> >>>>> >>>>> sr = 44100 >>>>> ksmps = 32 >>>>> nchnls = 2 >>>>> 0dbfs = 1 >>>>> >>>>> instr 1 >>>>> >>>>> icps cpsmidi >>>>> iamp ampmidi .2 >>>>> ; st,dur1,typ1,val,dur2,typ2,end >>>>> kenv transegr 0, .2, 2, .5, 1, - 3, 2 >>>>> asig pluck kenviamp, icps, icps, 1, 1 >>>>> outs asig, asig >>>>> >>>>> >>>>> endin >>>>> >>>>> >>>>> f1 0 4096 10 1 ;sine >>>>> >>>>> f0 30 ;runs 30 seconds >>>>> e >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> >>>>> http://csound.1045644.n5.nabble.com/transegr-issue-tp4885520p4885520.html >>>>> Sent from the Csound - General mailing list archive at Nabble.com. >>>>> >>>>> >>>>> 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 sympa@lists.bath.ac.uk with body >>>>> "unsubscribe >>>>> csound" >>>>> >>>> >>>> Dr Victor Lazzarini >>>> Senior Lecturer >>>> Dept. of Music >>>> NUI Maynooth Ireland >>>> tel.: +353 1 708 3545 >>>> Victor dot Lazzarini AT nuim dot ie >>>> >>>> >>>> >>>> >>>> >>>> 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk with body >>> "unsubscribe >>> csound" >>> >> >> Dr Victor Lazzarini >> Senior Lecturer >> Dept. of Music >> NUI Maynooth Ireland >> tel.: +353 1 708 3545 >> Victor dot Lazzarini AT nuim dot ie >> >> >> >> >> >> 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk with body > "unsubscribe csound" > Dr Victor Lazzarini Senior Lecturer Dept. of Music NUI Maynooth Ireland tel.: +353 1 708 3545 Victor dot Lazzarini AT nuim dot ie 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 sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-10-10 09:10
From	jpff@cs.bath.ac.uk
Subject	Re: [Csnd] transegr issue
	I did indeed write transeg(r) Will take a look, but the inconsistent reports are worrying ==JOhn ff > I'm not sure, Menno, what OS are you using and is it 32-bit or 64-bit? > > On Sun, Oct 9, 2011 at 9:41 PM, Victor Lazzarini > wrote: >> maybe it's a 64 bit OS issue? >> On 9 Oct 2011, at 21:21, Steven Yi wrote: >> >>> I'm on OSX, but am getting crashes. Running in GDB I get: >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 >>> 0x00000001004fac5b in ktrnsegr (csound=0x100800000, p=0x101982c98) at >>> pitch.c:1992 >>> 1992 if (!(p->curcnt = segp->cnt)) { /* nonlen = discontin >>> / >>> (gdb) print p >>> $1 = (TRANSEG ) 0x1030f4098 >>> (gdb) print p->curcnt >>> $2 = 21 >>> (gdb) print segp >>> $3 = (NSEG ) 0x0 >>> (gdb) >>> >>> It happens during the release segment here for me. It didn't always >>> happen, some runs I had to hit more notes than other before it would >>> die. Also, the behavior was erratic, sometimes it would suddenly >>> shoot to inf for audio (my ears are ringing a bit!). The crash is >>> happening due to trying to dereference the null NSEG, but >>> the code is a bit tricky to follow since there's a goto in there. I'm >>> full up for tonight with other work, but perhaps John could take a >>> look (I think he wrote transegr?). >>> >>> Thanks, >>> steven >>> >>> On Sun, Oct 9, 2011 at 8:02 PM, Victor Lazzarini >>> wrote: >>>> >>>> it's pretty stable here on OSX... no crashes. >>>> >>>> Victor >>>> On 9 Oct 2011, at 16:37, menno wrote: >>>> >>>>> Hi, >>>>> >>>>> i find the transegr opcode very unstable, csound crashes quickly when >>>>> playing the virtual midi keyboard with this example. >>>>> Can someone tell me why? >>>>> >>>>> thanks >>>>> Menno >>>>> >>>>> >>>>> >>>>> ; Select audio/midi flags here according to platform >>>>> -odac -+rtmidi=virtual -M0 ;;;realtime audio out and realtime midi >>>>> in >>>>> ;-iadc ;;;uncomment -iadc if realtime audio input is needed too >>>>> ; For Non-realtime ouput leave only the line below: >>>>> ; -o transegr.wav -W ;;; for file output any platform >>>>> >>>>> >>>>> >>>>> sr = 44100 >>>>> ksmps = 32 >>>>> nchnls = 2 >>>>> 0dbfs = 1 >>>>> >>>>> instr 1 >>>>> >>>>> icps cpsmidi >>>>> iamp ampmidi .2 >>>>> ; st,dur1,typ1,val,dur2,typ2,end >>>>> kenv transegr 0, .2, 2, .5, 1, - 3, 2 >>>>> asig pluck kenviamp, icps, icps, 1, 1 >>>>> outs asig, asig >>>>> >>>>> >>>>> endin >>>>> >>>>> >>>>> f1 0 4096 10 1 ;sine >>>>> >>>>> f0 30 ;runs 30 seconds >>>>> e >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> >>>>> http://csound.1045644.n5.nabble.com/transegr-issue-tp4885520p4885520.html >>>>> Sent from the Csound - General mailing list archive at Nabble.com. >>>>> >>>>> >>>>> 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 sympa@lists.bath.ac.uk with body >>>>> "unsubscribe >>>>> csound" >>>>> >>>> >>>> Dr Victor Lazzarini >>>> Senior Lecturer >>>> Dept. of Music >>>> NUI Maynooth Ireland >>>> tel.: +353 1 708 3545 >>>> Victor dot Lazzarini AT nuim dot ie >>>> >>>> >>>> >>>> >>>> >>>> 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk with body >>> "unsubscribe >>> csound" >>> >> >> Dr Victor Lazzarini >> Senior Lecturer >> Dept. of Music >> NUI Maynooth Ireland >> tel.: +353 1 708 3545 >> Victor dot Lazzarini AT nuim dot ie >> >> >> >> >> >> 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-10-10 10:27
From	menno
Subject	[Csnd] Re: transegr issue
	it crashes on Kubuntu 64 bit doubles, but tonight i can test it on my Kubuntu 32 bit laptop. I'll get back to you with the results bye, Menno -- View this message in context: http://csound.1045644.n5.nabble.com/transegr-issue-tp4885520p4887548.html Sent from the Csound - General mailing list archive at Nabble.com. 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 sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-10-10 12:27
From	menno
Subject	[Csnd] Re: transegr issue
	I get the same unstable result in Kubuntu10.04 32bit double samples. The transegr example crashes while the linsegr example does not. ? Here is the linsegr example that works fine over here. ; Select audio/midi flags here according to platform -odac -+rtmidi=virtual -M0 ;;;realtime audio out and realtime midi in ;-iadc ;;;uncomment -iadc if realtime audio input is needed too ; For Non-realtime ouput leave only the line below: ; -o linsegr.wav -W ;;; for file output any platform sr = 44100 ksmps = 32 nchnls = 2 0dbfs = 1 instr 1 icps cpsmidi iamp ampmidi .3 kenv linsegr 1, .05, 0.5, 1, 0 asig pluck kenv, icps, 200, 1, 1 outs asig, asig endin f 1 0 4096 10 1 ;sine wave f0 30 ;runs 30 seconds e greetings Menno -- View this message in context: http://csound.1045644.n5.nabble.com/transegr-issue-tp4885520p4887870.html Sent from the Csound - General mailing list archive at Nabble.com. 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 sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-10-10 16:47
From	jpff@cs.bath.ac.uk
Subject	Re: [Csnd] Re: transegr issue
	I really have no idea how to debug this; I do not get any problems on my computer (64bit Linux, doubles), and I have read the code withpout seeong anything odd. Indeed I cannot see any way segp can be null unless the arguments to the opcode are wrong ==John ff > I get the same unstable result in Kubuntu10.04 32bit double samples. The > transegr example crashes while the linsegr example does not. > ? > > Here is the linsegr example that works fine over here. > > > > ; Select audio/midi flags here according to platform > -odac -+rtmidi=virtual -M0 ;;;realtime audio out and realtime midi in > ;-iadc ;;;uncomment -iadc if realtime audio input is needed too > ; For Non-realtime ouput leave only the line below: > ; -o linsegr.wav -W ;;; for file output any platform > > > > sr = 44100 > ksmps = 32 > nchnls = 2 > 0dbfs = 1 > > instr 1 > > > icps cpsmidi > iamp ampmidi .3 > > kenv linsegr 1, .05, 0.5, 1, 0 > asig pluck kenv, icps, 200, 1, 1 > outs asig, asig > > endin > > > f 1 0 4096 10 1 ;sine wave > > f0 30 ;runs 30 seconds > e > > > > greetings > Menno > > -- > View this message in context: > http://csound.1045644.n5.nabble.com/transegr-issue-tp4885520p4887870.html > Sent from the Csound - General mailing list archive at Nabble.com. > > > 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-10-10 19:12
From	Steven Yi
Subject	Re: [Csnd] Re: transegr issue
Attachments	test3.csd
	Hi John, I took a look again, I think the logic is incorrect for advancing to the last segment. If one releases before the first segment is complete, it goes off. I've attached a CSD with a score that can be run without midi that shows the issue. GDB log is at end of thi method. I think this code: while (p->segsrem > 1) { /* reles flag new: / segp = ++p->cursegp; / go to last segment / p->segsrem--; } / get univ relestim / should look for segsrem > 0, if it's trying to get to the last segment. Also, since the last segment has a value cached for its increment, I think that is the reason the release stage is something generating inf signal as I think the code (if read correctly) assumes that the release is going to be starting at the value of the previous segment. In the case where a user releases before the other segments complete, the value should probably be calculated at that time so that the value doesn't generate wild values. Could you take another look and confirm if my diagnosis is correct? Thanks! steven Breakpoint 1, ktrnsegr (csound=0x100800000, p=0x10205b098) at pitch.c:1976 1976 while (p->segsrem > 1) { / reles flag new: / (gdb) print p->segsrem $1 = 2 (gdb) n 1977 segp = ++p->cursegp; / go to last segment / (gdb) n 1978 p->segsrem--; (gdb) n Breakpoint 1, ktrnsegr (csound=0x100800000, p=0x10205b098) at pitch.c:1976 1976 while (p->segsrem > 1) { / reles flag new: / (gdb) print p->segsrem $2 = 1 (gdb) print p->cursegp $3 = (NSEG ) 0x10140d168 (gdb) n 1980 segp->cnt = p->xtra>=0 ? p->xtra : p->h.insdshead->xtratim; (gdb) n 1992 if (!(p->curcnt = segp->cnt)) { /* nonlen = discontin / (gdb) n Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x00000001004fac5b in ktrnsegr (csound=0x100800000, p=0x10205b098) at pitch.c:1992 1992 if (!(p->curcnt = segp->cnt)) { / nonlen = discontin */ (gdb) Quit On Mon, Oct 10, 2011 at 4:47 PM, wrote: > I really have no idea how to debug this; I do not get any problems on my > computer (64bit Linux, doubles), and I have read the code withpout seeong > anything odd. Indeed I cannot see any way segp can be null unless the > arguments to the opcode are wrong > ==John ff > >> I get the same unstable result in Kubuntu10.04 32bit double samples. The >> transegr example crashes while the linsegr example does not. >> ? >> >> Here is the linsegr example that works fine over here. >> >> >> >> ; Select audio/midi flags here according to platform >> -odac -+rtmidi=virtual -M0 ;;;realtime audio out and realtime midi in >> ;-iadc ;;;uncomment -iadc if realtime audio input is needed too >> ; For Non-realtime ouput leave only the line below: >> ; -o linsegr.wav -W ;;; for file output any platform >> >> >> >> sr = 44100 >> ksmps = 32 >> nchnls = 2 >> 0dbfs = 1 >> >> instr 1 >> >> >> icps cpsmidi >> iamp ampmidi .3 >> >> kenv linsegr 1, .05, 0.5, 1, 0 >> asig pluck kenv, icps, 200, 1, 1 >> outs asig, asig >> >> endin >> >> >> f 1 0 4096 10 1 ;sine wave >> >> f0 30 ;runs 30 seconds >> e >> >> >> >> greetings >> Menno >> >> -- >> View this message in context: >> http://csound.1045644.n5.nabble.com/transegr-issue-tp4885520p4887870.html >> Sent from the Csound - General mailing list archive at Nabble.com. >> >> >> 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-10-10 19:57
From	jpff@cs.bath.ac.uk
Subject	Re: [Cs-dev] [Csnd] Re: transegr issue
	usy at present, but i thought tis logic was a direct copy of linsegr/expsegr. If you are correct then they may be wrong also ==John ff > Hi John, > > I took a look again, I think the logic is incorrect for advancing to > the last segment. If one releases before the first segment is > complete, it goes off. > > I've attached a CSD with a score that can be run without midi that > shows the issue. GDB log is at end of thi method. > > I think this code: > > while (p->segsrem > 1) { /* reles flag new: / > segp = ++p->cursegp; / go to last segment / > p->segsrem--; > } / get univ relestim / > > > should look for segsrem > 0, if it's trying to get to the last > segment. Also, since the last segment has a value cached for its > increment, I think that is the reason the release stage is something > generating inf signal as I think the code (if read correctly) assumes > that the release is going to be starting at the value of the previous > segment. In the case where a user releases before the other segments > complete, the value should probably be calculated at that time so that > the value doesn't generate wild values. > > Could you take another look and confirm if my diagnosis is correct? > > Thanks! > steven > > > Breakpoint 1, ktrnsegr (csound=0x100800000, p=0x10205b098) at pitch.c:1976 > 1976 while (p->segsrem > 1) { / reles flag new: / > (gdb) print p->segsrem > $1 = 2 > (gdb) n > 1977 segp = ++p->cursegp; / go to last segment / > (gdb) n > 1978 p->segsrem--; > (gdb) n > > Breakpoint 1, ktrnsegr (csound=0x100800000, p=0x10205b098) at pitch.c:1976 > 1976 while (p->segsrem > 1) { / reles flag new: / > (gdb) print p->segsrem > $2 = 1 > (gdb) print p->cursegp > $3 = (NSEG ) 0x10140d168 > (gdb) n > 1980 segp->cnt = p->xtra>=0 ? p->xtra : p->h.insdshead->xtratim; > (gdb) n > 1992 if (!(p->curcnt = segp->cnt)) { /* nonlen = discontin / > (gdb) n > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 > 0x00000001004fac5b in ktrnsegr (csound=0x100800000, p=0x10205b098) at > pitch.c:1992 > 1992 if (!(p->curcnt = segp->cnt)) { / nonlen = discontin */ > (gdb) Quit > > > > On Mon, Oct 10, 2011 at 4:47 PM, wrote: >> I really have no idea how to debug this; I do not get any problems on my >> computer (64bit Linux, doubles), and I have read the code withpout >> seeong >> anything odd. Indeed I cannot see any way segp can be null unless the >> arguments to the opcode are wrong >> ==John ff >> >>> I get the same unstable result in Kubuntu10.04 32bit double samples. >>> The >>> transegr example crashes while the linsegr example does not. >>> ? >>> >>> Here is the linsegr example that works fine over here. >>> >>> >>> >>> ; Select audio/midi flags here according to platform >>> -odac -+rtmidi=virtual -M0 ;;;realtime audio out and realtime midi >>> in >>> ;-iadc ;;;uncomment -iadc if realtime audio input is needed too >>> ; For Non-realtime ouput leave only the line below: >>> ; -o linsegr.wav -W ;;; for file output any platform >>> >>> >>> >>> sr = 44100 >>> ksmps = 32 >>> nchnls = 2 >>> 0dbfs = 1 >>> >>> instr 1 >>> >>> >>> icps cpsmidi >>> iamp ampmidi .3 >>> >>> kenv linsegr 1, .05, 0.5, 1, 0 >>> asig pluck kenv, icps, 200, 1, 1 >>> outs asig, asig >>> >>> endin >>> >>> >>> f 1 0 4096 10 1 ;sine wave >>> >>> f0 30 ;runs 30 seconds >>> e >>> >>> >>> >>> greetings >>> Menno >>> >>> -- >>> View this message in context: >>> http://csound.1045644.n5.nabble.com/transegr-issue-tp4885520p4887870.html >>> Sent from the Csound - General mailing list archive at Nabble.com. >>> >>> >>> 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk with body "unsubscribe > csound" > > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2011-10-10 21:29
From	Steven Yi
Subject	Re: [Cs-dev] [Csnd] Re: transegr issue
	I checked linsegr and it looks like the segsrem is set as count + 1 in the init function, which is the same in transegr, so that code to get to the last segment looks alright. I do notice something odd but haven't figured it out quite yet, in comparing linsegr's k-time function and transegr. Still looking. On Mon, Oct 10, 2011 at 7:57 PM, wrote: > usy at present, but i thought tis logic was a direct copy of > linsegr/expsegr. If you are correct then they may be wrong also > ==John ff > >> Hi John, >> >> I took a look again, I think the logic is incorrect for advancing to >> the last segment. If one releases before the first segment is >> complete, it goes off. >> >> I've attached a CSD with a score that can be run without midi that >> shows the issue. GDB log is at end of thi method. >> >> I think this code: >> >> while (p->segsrem > 1) { /* reles flag new: / >> segp = ++p->cursegp; / go to last segment / >> p->segsrem--; >> } / get univ relestim / >> >> >> should look for segsrem > 0, if it's trying to get to the last >> segment. Also, since the last segment has a value cached for its >> increment, I think that is the reason the release stage is something >> generating inf signal as I think the code (if read correctly) assumes >> that the release is going to be starting at the value of the previous >> segment. In the case where a user releases before the other segments >> complete, the value should probably be calculated at that time so that >> the value doesn't generate wild values. >> >> Could you take another look and confirm if my diagnosis is correct? >> >> Thanks! >> steven >> >> >> Breakpoint 1, ktrnsegr (csound=0x100800000, p=0x10205b098) at pitch.c:1976 >> 1976 while (p->segsrem > 1) { / reles flag new: / >> (gdb) print p->segsrem >> $1 = 2 >> (gdb) n >> 1977 segp = ++p->cursegp; / go to last segment / >> (gdb) n >> 1978 p->segsrem--; >> (gdb) n >> >> Breakpoint 1, ktrnsegr (csound=0x100800000, p=0x10205b098) at pitch.c:1976 >> 1976 while (p->segsrem > 1) { / reles flag new: / >> (gdb) print p->segsrem >> $2 = 1 >> (gdb) print p->cursegp >> $3 = (NSEG ) 0x10140d168 >> (gdb) n >> 1980 segp->cnt = p->xtra>=0 ? p->xtra : p->h.insdshead->xtratim; >> (gdb) n >> 1992 if (!(p->curcnt = segp->cnt)) { /* nonlen = discontin / >> (gdb) n >> >> Program received signal EXC_BAD_ACCESS, Could not access memory. >> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 >> 0x00000001004fac5b in ktrnsegr (csound=0x100800000, p=0x10205b098) at >> pitch.c:1992 >> 1992 if (!(p->curcnt = segp->cnt)) { / nonlen = discontin */ >> (gdb) Quit >> >> >> >> On Mon, Oct 10, 2011 at 4:47 PM, wrote: >>> I really have no idea how to debug this; I do not get any problems on my >>> computer (64bit Linux, doubles), and I have read the code withpout >>> seeong >>> anything odd. Indeed I cannot see any way segp can be null unless the >>> arguments to the opcode are wrong >>> ==John ff >>> >>>> I get the same unstable result in Kubuntu10.04 32bit double samples. >>>> The >>>> transegr example crashes while the linsegr example does not. >>>> ? >>>> >>>> Here is the linsegr example that works fine over here. >>>> >>>> >>>> >>>> ; Select audio/midi flags here according to platform >>>> -odac -+rtmidi=virtual -M0 ;;;realtime audio out and realtime midi >>>> in >>>> ;-iadc ;;;uncomment -iadc if realtime audio input is needed too >>>> ; For Non-realtime ouput leave only the line below: >>>> ; -o linsegr.wav -W ;;; for file output any platform >>>> >>>> >>>> >>>> sr = 44100 >>>> ksmps = 32 >>>> nchnls = 2 >>>> 0dbfs = 1 >>>> >>>> instr 1 >>>> >>>> >>>> icps cpsmidi >>>> iamp ampmidi .3 >>>> >>>> kenv linsegr 1, .05, 0.5, 1, 0 >>>> asig pluck kenv, icps, 200, 1, 1 >>>> outs asig, asig >>>> >>>> endin >>>> >>>> >>>> f 1 0 4096 10 1 ;sine wave >>>> >>>> f0 30 ;runs 30 seconds >>>> e >>>> >>>> >>>> >>>> greetings >>>> Menno >>>> >>>> -- >>>> View this message in context: >>>> http://csound.1045644.n5.nabble.com/transegr-issue-tp4885520p4887870.html >>>> Sent from the Csound - General mailing list archive at Nabble.com. >>>> >>>> >>>> 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk with body "unsubscribe >> csound" >> >> > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net

Date	2011-10-10 21:58
From	Steven Yi
Subject	Re: [Cs-dev] [Csnd] Re: transegr issue
Attachments	test4.csd None None
	Following up, there were some subtle differences between how transegr was grabbing the current segment. It also was missing some code to sustain on the 2nd to last segment before releasing. I've modified the code and committed it. I found too that the original test csd that menno sent isn't so good to illustrate the problems, and it was much better to use a vco2 example (attached). All is working well here now. On Mon, Oct 10, 2011 at 9:29 PM, Steven Yi wrote: > I checked linsegr and it looks like the segsrem is set as count + 1 in > the init function, which is the same in transegr, so that code to get > to the last segment looks alright. > > I do notice something odd but haven't figured it out quite yet, in > comparing linsegr's k-time function and transegr. Still looking. > > On Mon, Oct 10, 2011 at 7:57 PM, wrote: >> usy at present, but i thought tis logic was a direct copy of >> linsegr/expsegr. If you are correct then they may be wrong also >> ==John ff >> >>> Hi John, >>> >>> I took a look again, I think the logic is incorrect for advancing to >>> the last segment. If one releases before the first segment is >>> complete, it goes off. >>> >>> I've attached a CSD with a score that can be run without midi that >>> shows the issue. GDB log is at end of thi method. >>> >>> I think this code: >>> >>> while (p->segsrem > 1) { /* reles flag new: / >>> segp = ++p->cursegp; / go to last segment / >>> p->segsrem--; >>> } / get univ relestim / >>> >>> >>> should look for segsrem > 0, if it's trying to get to the last >>> segment. Also, since the last segment has a value cached for its >>> increment, I think that is the reason the release stage is something >>> generating inf signal as I think the code (if read correctly) assumes >>> that the release is going to be starting at the value of the previous >>> segment. In the case where a user releases before the other segments >>> complete, the value should probably be calculated at that time so that >>> the value doesn't generate wild values. >>> >>> Could you take another look and confirm if my diagnosis is correct? >>> >>> Thanks! >>> steven >>> >>> >>> Breakpoint 1, ktrnsegr (csound=0x100800000, p=0x10205b098) at pitch.c:1976 >>> 1976 while (p->segsrem > 1) { / reles flag new: / >>> (gdb) print p->segsrem >>> $1 = 2 >>> (gdb) n >>> 1977 segp = ++p->cursegp; / go to last segment / >>> (gdb) n >>> 1978 p->segsrem--; >>> (gdb) n >>> >>> Breakpoint 1, ktrnsegr (csound=0x100800000, p=0x10205b098) at pitch.c:1976 >>> 1976 while (p->segsrem > 1) { / reles flag new: / >>> (gdb) print p->segsrem >>> $2 = 1 >>> (gdb) print p->cursegp >>> $3 = (NSEG ) 0x10140d168 >>> (gdb) n >>> 1980 segp->cnt = p->xtra>=0 ? p->xtra : p->h.insdshead->xtratim; >>> (gdb) n >>> 1992 if (!(p->curcnt = segp->cnt)) { /* nonlen = discontin / >>> (gdb) n >>> >>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 >>> 0x00000001004fac5b in ktrnsegr (csound=0x100800000, p=0x10205b098) at >>> pitch.c:1992 >>> 1992 if (!(p->curcnt = segp->cnt)) { / nonlen = discontin */ >>> (gdb) Quit >>> >>> >>> >>> On Mon, Oct 10, 2011 at 4:47 PM, wrote: >>>> I really have no idea how to debug this; I do not get any problems on my >>>> computer (64bit Linux, doubles), and I have read the code withpout >>>> seeong >>>> anything odd. Indeed I cannot see any way segp can be null unless the >>>> arguments to the opcode are wrong >>>> ==John ff >>>> >>>>> I get the same unstable result in Kubuntu10.04 32bit double samples. >>>>> The >>>>> transegr example crashes while the linsegr example does not. >>>>> ? >>>>> >>>>> Here is the linsegr example that works fine over here. >>>>> >>>>> >>>>> >>>>> ; Select audio/midi flags here according to platform >>>>> -odac -+rtmidi=virtual -M0 ;;;realtime audio out and realtime midi >>>>> in >>>>> ;-iadc ;;;uncomment -iadc if realtime audio input is needed too >>>>> ; For Non-realtime ouput leave only the line below: >>>>> ; -o linsegr.wav -W ;;; for file output any platform >>>>> >>>>> >>>>> >>>>> sr = 44100 >>>>> ksmps = 32 >>>>> nchnls = 2 >>>>> 0dbfs = 1 >>>>> >>>>> instr 1 >>>>> >>>>> >>>>> icps cpsmidi >>>>> iamp ampmidi .3 >>>>> >>>>> kenv linsegr 1, .05, 0.5, 1, 0 >>>>> asig pluck kenv, icps, 200, 1, 1 >>>>> outs asig, asig >>>>> >>>>> endin >>>>> >>>>> >>>>> f 1 0 4096 10 1 ;sine wave >>>>> >>>>> f0 30 ;runs 30 seconds >>>>> e >>>>> >>>>> >>>>> >>>>> greetings >>>>> Menno >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://csound.1045644.n5.nabble.com/transegr-issue-tp4885520p4887870.html >>>>> Sent from the Csound - General mailing list archive at Nabble.com. >>>>> >>>>> >>>>> 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk with body "unsubscribe >>> csound" >>> >>> >> >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2dcopy1 >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel >> >

Date	2011-10-11 10:56
From	Steven Yi
Subject	Re: [Cs-dev] [Csnd] Re: transegr issue
	Note: I realized I did not push the code last night, and have pushed that just now. On Mon, Oct 10, 2011 at 9:58 PM, Steven Yi wrote: > Following up, there were some subtle differences between how transegr > was grabbing the current segment. It also was missing some code to > sustain on the 2nd to last segment before releasing. I've modified > the code and committed it. I found too that the original test csd that > menno sent isn't so good to illustrate the problems, and it was much > better to use a vco2 example (attached). All is working well here now. > > On Mon, Oct 10, 2011 at 9:29 PM, Steven Yi wrote: >> I checked linsegr and it looks like the segsrem is set as count + 1 in >> the init function, which is the same in transegr, so that code to get >> to the last segment looks alright. >> >> I do notice something odd but haven't figured it out quite yet, in >> comparing linsegr's k-time function and transegr. Still looking. >> >> On Mon, Oct 10, 2011 at 7:57 PM, wrote: >>> usy at present, but i thought tis logic was a direct copy of >>> linsegr/expsegr. If you are correct then they may be wrong also >>> ==John ff >>> >>>> Hi John, >>>> >>>> I took a look again, I think the logic is incorrect for advancing to >>>> the last segment. If one releases before the first segment is >>>> complete, it goes off. >>>> >>>> I've attached a CSD with a score that can be run without midi that >>>> shows the issue. GDB log is at end of thi method. >>>> >>>> I think this code: >>>> >>>> while (p->segsrem > 1) { /* reles flag new: / >>>> segp = ++p->cursegp; / go to last segment / >>>> p->segsrem--; >>>> } / get univ relestim / >>>> >>>> >>>> should look for segsrem > 0, if it's trying to get to the last >>>> segment. Also, since the last segment has a value cached for its >>>> increment, I think that is the reason the release stage is something >>>> generating inf signal as I think the code (if read correctly) assumes >>>> that the release is going to be starting at the value of the previous >>>> segment. In the case where a user releases before the other segments >>>> complete, the value should probably be calculated at that time so that >>>> the value doesn't generate wild values. >>>> >>>> Could you take another look and confirm if my diagnosis is correct? >>>> >>>> Thanks! >>>> steven >>>> >>>> >>>> Breakpoint 1, ktrnsegr (csound=0x100800000, p=0x10205b098) at pitch.c:1976 >>>> 1976 while (p->segsrem > 1) { / reles flag new: / >>>> (gdb) print p->segsrem >>>> $1 = 2 >>>> (gdb) n >>>> 1977 segp = ++p->cursegp; / go to last segment / >>>> (gdb) n >>>> 1978 p->segsrem--; >>>> (gdb) n >>>> >>>> Breakpoint 1, ktrnsegr (csound=0x100800000, p=0x10205b098) at pitch.c:1976 >>>> 1976 while (p->segsrem > 1) { / reles flag new: / >>>> (gdb) print p->segsrem >>>> $2 = 1 >>>> (gdb) print p->cursegp >>>> $3 = (NSEG ) 0x10140d168 >>>> (gdb) n >>>> 1980 segp->cnt = p->xtra>=0 ? p->xtra : p->h.insdshead->xtratim; >>>> (gdb) n >>>> 1992 if (!(p->curcnt = segp->cnt)) { /* nonlen = discontin / >>>> (gdb) n >>>> >>>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>>> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 >>>> 0x00000001004fac5b in ktrnsegr (csound=0x100800000, p=0x10205b098) at >>>> pitch.c:1992 >>>> 1992 if (!(p->curcnt = segp->cnt)) { / nonlen = discontin */ >>>> (gdb) Quit >>>> >>>> >>>> >>>> On Mon, Oct 10, 2011 at 4:47 PM, wrote: >>>>> I really have no idea how to debug this; I do not get any problems on my >>>>> computer (64bit Linux, doubles), and I have read the code withpout >>>>> seeong >>>>> anything odd. Indeed I cannot see any way segp can be null unless the >>>>> arguments to the opcode are wrong >>>>> ==John ff >>>>> >>>>>> I get the same unstable result in Kubuntu10.04 32bit double samples. >>>>>> The >>>>>> transegr example crashes while the linsegr example does not. >>>>>> ? >>>>>> >>>>>> Here is the linsegr example that works fine over here. >>>>>> >>>>>> >>>>>> >>>>>> ; Select audio/midi flags here according to platform >>>>>> -odac -+rtmidi=virtual -M0 ;;;realtime audio out and realtime midi >>>>>> in >>>>>> ;-iadc ;;;uncomment -iadc if realtime audio input is needed too >>>>>> ; For Non-realtime ouput leave only the line below: >>>>>> ; -o linsegr.wav -W ;;; for file output any platform >>>>>> >>>>>> >>>>>> >>>>>> sr = 44100 >>>>>> ksmps = 32 >>>>>> nchnls = 2 >>>>>> 0dbfs = 1 >>>>>> >>>>>> instr 1 >>>>>> >>>>>> >>>>>> icps cpsmidi >>>>>> iamp ampmidi .3 >>>>>> >>>>>> kenv linsegr 1, .05, 0.5, 1, 0 >>>>>> asig pluck kenv, icps, 200, 1, 1 >>>>>> outs asig, asig >>>>>> >>>>>> endin >>>>>> >>>>>> >>>>>> f 1 0 4096 10 1 ;sine wave >>>>>> >>>>>> f0 30 ;runs 30 seconds >>>>>> e >>>>>> >>>>>> >>>>>> >>>>>> greetings >>>>>> Menno >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://csound.1045644.n5.nabble.com/transegr-issue-tp4885520p4887870.html >>>>>> Sent from the Csound - General mailing list archive at Nabble.com. >>>>>> >>>>>> >>>>>> 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk 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 sympa@lists.bath.ac.uk with body "unsubscribe >>>> csound" >>>> >>>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> All the data continuously generated in your IT infrastructure contains a >>> definitive record of customers, application performance, security >>> threats, fraudulent activity and more. Splunk takes this data and makes >>> sense of it. Business sense. IT sense. Common sense. >>> http://p.sf.net/sfu/splunk-d2dcopy1 >>> _______________________________________________ >>> Csound-devel mailing list >>> Csound-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/csound-devel >>> >> > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net