[Csnd] 'linsegr' is not going back to zero

[Csnd] 'linsegr' is not going back to zero

Date	2022-12-09 21:12
From	Philipp Neumann
Subject	[Csnd] 'linsegr' is not going back to zero
	Hello Everybody! I have some problems with the linsegr opcode, which i don’t understand. I use it as a global gate for a mic-input. It gets triggered by a specific midi note and the instrument in which it is, is only used for this. My problem is, when the note-off signal is coming to trigger the last segment of the opcode it does not gets down to 0.000. It stops always like on 0.0132 or something and the gate stays always a little bit open. Maybe someone can help. All the best, Philipp This is the Instrument. instr 100 ; Mic-Gate ;;; Über massign wird MIDI-Kanal 1 auf Instrument 1 geroutet ;;; Instrument 1 startet bei Eingang eines MIDI-Signals ;;; Wenn MIDI-Note 1 eingeht wird linsegr gestartet ;;; Wenn nicht, dann ist MicGate = 0 iMidinote notnum if iMidinote == 1 then gkMicGate linsegr 0, 0.01, 1, 0.1, 0 else gkMicGate = 0 printk2 gkMicGate endif endin This is the whole Csound-Code: -d -odac3 -iadc2 -W -3 -+rtmidi=coremidi -M4 sr = 44100 ksmps = 64 nchnls = 2 0dbfs = 1.0 nchnls_i = 12 ;----------------------------------------------------------- #include "/Users/philippneumann/Documents/Csound/PHN-UDOs.txt" ;----------------------------------------------------------- giMicIn = 11 gkMasterVol init 0 massign 1, 100 giDelBufSize1 = 5 gkMicGate init 0 ;----------------------------------------------------------- instr 100 ; Mic-Gate ;;; Über massign wird MIDI-Kanal 1 auf Instrument 1 geroutet ;;; Instrument 1 startet bei Eingang eines MIDI-Signals ;;; Wenn MIDI-Note 1 eingeht wird linsegr gestartet ;;; Wenn nicht, dann ist MicGate = 0 iMidinote notnum if iMidinote == 1 then gkMicGate linsegr 0, 0.01, 1, 0.1, 0 else gkMicGate = 0 printk2 gkMicGate endif endin instr 1 ; ----- ; Tap-Delay ; MIDI-Kanal 1 ; CC-1: Mikrofon und Delay Volume ; CC-2: Feedback Ratio ; CC-3: Delay Time ; CC-4: Delay Time Shift ; ----- ;;; Mikrofon Input aIn inch giMicIn initc7 1, 1, 0 kInVol ctrl7 1, 1, 0., 1. kInVol port kInVol, 0.01 aMicGated = aIngkMicGate aMic = aMicGatedkInVol printks2 "Mic-Volume: %f \n", kInVol ; Wenn auf MIDI-Kanal 1 die MIDI-Note geschickt wird ist das Gate ; für das Mikrofon offen und das Signal geht in das Delay ;aMic = aIngkMicGate ;;; Delay ; Delay-Time initc7 1, 3, 0. aDelTime1 ctrl7 1, 3, 0.003, 2 ; Delay-Time Offset für Links und Rechts initc7 1, 4, 0. aDelOffset ctrl7 1, 4, 0., 2. aDelOffsetL = aDelOffset1 aDelOffsetR = aDelOffset1.1 ; Feedback-Ratio initc7 1, 2, 0 kFdb ctrl7 1, 2, 0., 1. ; Delay-Buffer aDumpC delayr giDelBufSize1 aDel1C deltap3 aDelTime1 delayw aMic+(aDel1CkFdb) aDumpL delayr giDelBufSize1 aDel1L deltap3 aDelTime1aDelOffsetL delayw aMic+(aDel1CkFdb) aDumpR delayr giDelBufSize1 aDel1R deltap3 aDelTime1aDelOffsetR delayw aMic+(aDel1CkFdb) ;aDelL sum aDel1CkInVol, aDel1LkInVol ;aDelR sum aDel1CkInVol, aDel1RkInVol aDelL sum aDel1C, aDel1L aDelR sum aDel1C, aDel1R outs (aMic+aDelL)gkMasterVol, (aMic+aDelR)gkMasterVol endin instr 8 ; ----- ; Master-Kanal ; MIDI-Kanal 8 ; CC-1: Master Volume ; CC-2: G ; ----- ;;; Master Volume initc7 8, 1, 0. kMasterVol ctrl7 8, 1, 0., 1. gkMasterVol portk kMasterVol, 0.01 printks2 "Master-Volume: %f \n", gkMasterVol endin ;----------------------------------------------------------- i100 0 z i1 0 z i8 0 z Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-10 23:53
From	Richard Knight
Subject	Re: [Csnd] 'linsegr' is not going back to zero
	Hi I tested the instrument and got the same result as you. There may even be a bug with linsegr as it seems that the value at the very last k-cycle is not being set. As a work around you could use the xtratim opcode to add some additional release time to the instrument. linsegr already extends the instrument time by the release time given (0.1) so xtratim needs to be above that. 1/kr gives the time of one k-cycle (which with ksmps=64 is 0.0013 seconds), and I had success with the following: instr 100 ; Mic-Gate iMidinote notnum if iMidinote == 1 then iReleasetime = 0.1 ; release time to be used by linsegr xtratim iReleasetime + (1/kr) ; add very short additional time to the existing release time gkMicGate linsegr 0, 0.01, 1, iReleasetime, 0 else gkMicGate = 0 endif printk2 gkMicGate endin Hope that helps Richard On 2022-12-09 21:12, Philipp Neumann wrote: > Hello Everybody! > > I have some problems with the linsegr opcode, which i don’t understand. > > I use it as a global gate for a mic-input. It gets triggered by a > specific midi note and the instrument in which it is, is only used for > this. > My problem is, when the note-off signal is coming to trigger the last > segment of the opcode it does not gets down to 0.000. It stops always > like on 0.0132 or something and the gate stays always a little bit > open. > Maybe someone can help. > > All the best, > Philipp > > This is the Instrument. > > instr 100 ; Mic-Gate > ;;; Über massign wird MIDI-Kanal 1 auf Instrument 1 geroutet > ;;; Instrument 1 startet bei Eingang eines MIDI-Signals > ;;; Wenn MIDI-Note 1 eingeht wird linsegr gestartet > ;;; Wenn nicht, dann ist MicGate = 0 > > iMidinote notnum > if iMidinote == 1 then > gkMicGate linsegr 0, 0.01, 1, 0.1, 0 > else > gkMicGate = 0 > printk2 gkMicGate > endif > endin > > > This is the whole Csound-Code: > > > > > -d -odac3 -iadc2 -W -3 -+rtmidi=coremidi -M4 > > > sr = 44100 > ksmps = 64 > nchnls = 2 > 0dbfs = 1.0 > nchnls_i = 12 > > > ;----------------------------------------------------------- > #include "/Users/philippneumann/Documents/Csound/PHN-UDOs.txt" > ;----------------------------------------------------------- > giMicIn = 11 > gkMasterVol init 0 > massign 1, 100 > giDelBufSize1 = 5 > gkMicGate init 0 > ;----------------------------------------------------------- > instr 100 ; Mic-Gate > ;;; Über massign wird MIDI-Kanal 1 auf Instrument 1 geroutet > ;;; Instrument 1 startet bei Eingang eines MIDI-Signals > ;;; Wenn MIDI-Note 1 eingeht wird linsegr gestartet > ;;; Wenn nicht, dann ist MicGate = 0 > > iMidinote notnum > if iMidinote == 1 then > gkMicGate linsegr 0, 0.01, 1, 0.1, 0 > else > gkMicGate = 0 > printk2 gkMicGate > endif > endin > > instr 1 > ; ----- > ; Tap-Delay > ; MIDI-Kanal 1 > ; CC-1: Mikrofon und Delay Volume > ; CC-2: Feedback Ratio > ; CC-3: Delay Time > ; CC-4: Delay Time Shift > ; ----- > ;;; Mikrofon Input > aIn inch giMicIn > initc7 1, 1, 0 > kInVol ctrl7 1, 1, 0., 1. > kInVol port kInVol, 0.01 > aMicGated = aIngkMicGate > > > aMic = aMicGatedkInVol > printks2 "Mic-Volume: %f \n", kInVol > ; Wenn auf MIDI-Kanal 1 die MIDI-Note geschickt wird ist das Gate > ; für das Mikrofon offen und das Signal geht in das Delay > ;aMic = aIngkMicGate > ;;; Delay > ; Delay-Time > initc7 1, 3, 0. > aDelTime1 ctrl7 1, 3, 0.003, 2 > ; Delay-Time Offset für Links und Rechts > initc7 1, 4, 0. > aDelOffset ctrl7 1, 4, 0., 2. > aDelOffsetL = aDelOffset1 > aDelOffsetR = aDelOffset1.1 > ; Feedback-Ratio > initc7 1, 2, 0 > kFdb ctrl7 1, 2, 0., 1. > ; Delay-Buffer > aDumpC delayr giDelBufSize1 > aDel1C deltap3 aDelTime1 > delayw aMic+(aDel1CkFdb) > > aDumpL delayr giDelBufSize1 > aDel1L deltap3 aDelTime1aDelOffsetL > delayw aMic+(aDel1CkFdb) > > aDumpR delayr giDelBufSize1 > aDel1R deltap3 aDelTime1aDelOffsetR > delayw aMic+(aDel1CkFdb) > > > ;aDelL sum aDel1CkInVol, aDel1LkInVol > ;aDelR sum aDel1CkInVol, aDel1RkInVol > > aDelL sum aDel1C, aDel1L > aDelR sum aDel1C, aDel1R > > outs (aMic+aDelL)gkMasterVol, (aMic+aDelR)gkMasterVol > endin > > instr 8 > ; ----- > ; Master-Kanal > ; MIDI-Kanal 8 > ; CC-1: Master Volume > ; CC-2: G > ; ----- > ;;; Master Volume > initc7 8, 1, 0. > kMasterVol ctrl7 8, 1, 0., 1. > gkMasterVol portk kMasterVol, 0.01 > printks2 "Master-Volume: %f \n", gkMasterVol > endin > ;----------------------------------------------------------- > > > i100 0 z > i1 0 z > i8 0 z > > > Csound mailing list > Csound@listserv.heanet.ie > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > Send bugs reports to > https://github.com/csound/csound/issues > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-11 10:02
From	joachim heintz
Subject	Re: [Csnd] 'linsegr' is not going back to zero
	hi - i think it is more a problem with the program flow. as i read the code, the if-condition is only activated as long as a certain midi key is pressed. as the linsegr statement is in this if-clause, it will not be finished, if the midi key is pressed too short. an alternative would be to trigger another instrument which then puts the gkMicGate to zero. like: if iMidiNote == 1 then schedule("PulDown",0,.1) endif in the instrument, and as instrument: instr PullDown gkMicGate linseg 1,p3,0 endin best - joachim On 11/12/2022 00:53, Richard Knight wrote: > Hi > I tested the instrument and got the same result as you. There may even > be a bug with linsegr as it seems that the value at the very last > k-cycle is not being set. As a work around you could use the xtratim > opcode to add some additional release time to the instrument. > linsegr already extends the instrument time by the release time given > (0.1) so xtratim needs to be above that. 1/kr gives the time of one > k-cycle (which with ksmps=64 is 0.0013 seconds), and I had success with > the following: > > instr 100 ; Mic-Gate > iMidinote notnum > if iMidinote == 1 then > iReleasetime = 0.1 ; release time to be used by linsegr > xtratim iReleasetime + (1/kr) ; add very short additional time > to the existing release time > gkMicGate linsegr 0, 0.01, 1, iReleasetime, 0 > else > gkMicGate = 0 > endif > printk2 gkMicGate > endin > > Hope that helps > Richard > > > On 2022-12-09 21:12, Philipp Neumann wrote: >> Hello Everybody! >> >> I have some problems with the linsegr opcode, which i don’t understand. >> >> I use it as a global gate for a mic-input. It gets triggered by a >> specific midi note and the instrument in which it is, is only used for >> this. >> My problem is, when the note-off signal is coming to trigger the last >> segment of the opcode it does not gets down to 0.000. It stops always >> like on 0.0132 or something and the gate stays always a little bit >> open. >> Maybe someone can help. >> >> All the best, >> Philipp >> >> This is the Instrument. >> >> instr 100 ; Mic-Gate >> ;;; Über massign wird MIDI-Kanal 1 auf Instrument 1 geroutet >> ;;; Instrument 1 startet bei Eingang eines MIDI-Signals >> ;;; Wenn MIDI-Note 1 eingeht wird linsegr gestartet >> ;;; Wenn nicht, dann ist MicGate = 0 >> >> iMidinote notnum >> if iMidinote == 1 then >> gkMicGate linsegr 0, 0.01, 1, 0.1, 0 >> else >> gkMicGate = 0 >> printk2 gkMicGate >> endif >> endin >> >> >> This is the whole Csound-Code: >> >> >> >> >> -d -odac3 -iadc2 -W -3 -+rtmidi=coremidi -M4 >> >> >> sr = 44100 >> ksmps = 64 >> nchnls = 2 >> 0dbfs = 1.0 >> nchnls_i = 12 >> >> >> ;----------------------------------------------------------- >> #include "/Users/philippneumann/Documents/Csound/PHN-UDOs.txt" >> ;----------------------------------------------------------- >> giMicIn = 11 >> gkMasterVol init 0 >> massign 1, 100 >> giDelBufSize1 = 5 >> gkMicGate init 0 >> ;----------------------------------------------------------- >> instr 100 ; Mic-Gate >> ;;; Über massign wird MIDI-Kanal 1 auf Instrument 1 geroutet >> ;;; Instrument 1 startet bei Eingang eines MIDI-Signals >> ;;; Wenn MIDI-Note 1 eingeht wird linsegr gestartet >> ;;; Wenn nicht, dann ist MicGate = 0 >> >> iMidinote notnum >> if iMidinote == 1 then >> gkMicGate linsegr 0, 0.01, 1, 0.1, 0 >> else >> gkMicGate = 0 >> printk2 gkMicGate >> endif >> endin >> >> instr 1 >> ; ----- >> ; Tap-Delay >> ; MIDI-Kanal 1 >> ; CC-1: Mikrofon und Delay Volume >> ; CC-2: Feedback Ratio >> ; CC-3: Delay Time >> ; CC-4: Delay Time Shift >> ; ----- >> ;;; Mikrofon Input >> aIn inch giMicIn >> initc7 1, 1, 0 >> kInVol ctrl7 1, 1, 0., 1. >> kInVol port kInVol, 0.01 >> aMicGated = aIngkMicGate >> >> >> aMic = aMicGatedkInVol >> printks2 "Mic-Volume: %f \n", kInVol >> ; Wenn auf MIDI-Kanal 1 die MIDI-Note geschickt wird ist das Gate >> ; für das Mikrofon offen und das Signal geht in das Delay >> ;aMic = aIngkMicGate >> ;;; Delay >> ; Delay-Time >> initc7 1, 3, 0. >> aDelTime1 ctrl7 1, 3, 0.003, 2 >> ; Delay-Time Offset für Links und Rechts >> initc7 1, 4, 0. >> aDelOffset ctrl7 1, 4, 0., 2. >> aDelOffsetL = aDelOffset1 >> aDelOffsetR = aDelOffset1.1 >> ; Feedback-Ratio >> initc7 1, 2, 0 >> kFdb ctrl7 1, 2, 0., 1. >> ; Delay-Buffer >> aDumpC delayr giDelBufSize1 >> aDel1C deltap3 aDelTime1 >> delayw aMic+(aDel1CkFdb) >> >> aDumpL delayr giDelBufSize1 >> aDel1L deltap3 aDelTime1aDelOffsetL >> delayw aMic+(aDel1CkFdb) >> >> aDumpR delayr giDelBufSize1 >> aDel1R deltap3 aDelTime1aDelOffsetR >> delayw aMic+(aDel1CkFdb) >> >> >> ;aDelL sum aDel1CkInVol, aDel1LkInVol >> ;aDelR sum aDel1CkInVol, aDel1RkInVol >> >> aDelL sum aDel1C, aDel1L >> aDelR sum aDel1C, aDel1R >> >> outs (aMic+aDelL)gkMasterVol, (aMic+aDelR)gkMasterVol >> endin >> >> instr 8 >> ; ----- >> ; Master-Kanal >> ; MIDI-Kanal 8 >> ; CC-1: Master Volume >> ; CC-2: G >> ; ----- >> ;;; Master Volume >> initc7 8, 1, 0. >> kMasterVol ctrl7 8, 1, 0., 1. >> gkMasterVol portk kMasterVol, 0.01 >> printks2 "Master-Volume: %f \n", gkMasterVol >> endin >> ;----------------------------------------------------------- >> >> >> i100 0 z >> i1 0 z >> i8 0 z >> >> >> Csound mailing list >> Csound@listserv.heanet.ie >> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND >> Send bugs reports to >> https://github.com/csound/csound/issues >> Discussions of bugs and features can be posted here > > Csound mailing list > Csound@listserv.heanet.ie > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > Send bugs reports to > https://github.com/csound/csound/issues > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-11 15:16
From	Richard Knight
Subject	Re: [Csnd] 'linsegr' is not going back to zero
	Hi I didn't test with midi or the if condition - really just an instrument with linsegr & printk - and still found an inconsistency with linsegr.. I may try and have a look at the source at some point. I don't use midi much and think yours is a good suggestion - however with the if running at init-time (ie iMidiNote == 1) and given linsegr is running at k-rate I would think the linsegr would run for the duration of the instrument regardless of what iMidiNote is after init? I know (but don't understand) there are some special/particular way that instruments are handled when used with midi though. RK On 2022-12-11 10:02, joachim heintz wrote: > hi - > > i think it is more a problem with the program flow. as i read the > code, the if-condition is only activated as long as a certain midi key > is pressed. as the linsegr statement is in this if-clause, it will > not be finished, if the midi key is pressed too short. > > an alternative would be to trigger another instrument which then puts > the gkMicGate to zero. like: > > if iMidiNote == 1 then > schedule("PulDown",0,.1) > endif > > in the instrument, and as instrument: > > instr PullDown > gkMicGate linseg 1,p3,0 > endin > > best - > joachim > > > On 11/12/2022 00:53, Richard Knight wrote: >> Hi >> I tested the instrument and got the same result as you. There may even >> be a bug with linsegr as it seems that the value at the very last >> k-cycle is not being set. As a work around you could use the xtratim >> opcode to add some additional release time to the instrument. >> linsegr already extends the instrument time by the release time given >> (0.1) so xtratim needs to be above that. 1/kr gives the time of one >> k-cycle (which with ksmps=64 is 0.0013 seconds), and I had success >> with the following: >> >> instr 100 ; Mic-Gate >> iMidinote notnum >> if iMidinote == 1 then >> iReleasetime = 0.1 ; release time to be used by linsegr >> xtratim iReleasetime + (1/kr) ; add very short additional >> time to the existing release time >> gkMicGate linsegr 0, 0.01, 1, iReleasetime, 0 >> else >> gkMicGate = 0 >> endif >> printk2 gkMicGate >> endin >> >> Hope that helps >> Richard >> >> >> On 2022-12-09 21:12, Philipp Neumann wrote: >>> Hello Everybody! >>> >>> I have some problems with the linsegr opcode, which i don’t >>> understand. >>> >>> I use it as a global gate for a mic-input. It gets triggered by a >>> specific midi note and the instrument in which it is, is only used >>> for >>> this. >>> My problem is, when the note-off signal is coming to trigger the last >>> segment of the opcode it does not gets down to 0.000. It stops always >>> like on 0.0132 or something and the gate stays always a little bit >>> open. >>> Maybe someone can help. >>> >>> All the best, >>> Philipp >>> >>> This is the Instrument. >>> >>> instr 100 ; Mic-Gate >>> ;;; Über massign wird MIDI-Kanal 1 auf Instrument 1 geroutet >>> ;;; Instrument 1 startet bei Eingang eines MIDI-Signals >>> ;;; Wenn MIDI-Note 1 eingeht wird linsegr gestartet >>> ;;; Wenn nicht, dann ist MicGate = 0 >>> >>> iMidinote notnum >>> if iMidinote == 1 then >>> gkMicGate linsegr 0, 0.01, 1, 0.1, 0 >>> else >>> gkMicGate = 0 >>> printk2 gkMicGate >>> endif >>> endin >>> >>> >>> This is the whole Csound-Code: >>> >>> >>> >>> >>> -d -odac3 -iadc2 -W -3 -+rtmidi=coremidi -M4 >>> >>> >>> sr = 44100 >>> ksmps = 64 >>> nchnls = 2 >>> 0dbfs = 1.0 >>> nchnls_i = 12 >>> >>> >>> ;----------------------------------------------------------- >>> #include "/Users/philippneumann/Documents/Csound/PHN-UDOs.txt" >>> ;----------------------------------------------------------- >>> giMicIn = 11 >>> gkMasterVol init 0 >>> massign 1, 100 >>> giDelBufSize1 = 5 >>> gkMicGate init 0 >>> ;----------------------------------------------------------- >>> instr 100 ; Mic-Gate >>> ;;; Über massign wird MIDI-Kanal 1 auf Instrument 1 geroutet >>> ;;; Instrument 1 startet bei Eingang eines MIDI-Signals >>> ;;; Wenn MIDI-Note 1 eingeht wird linsegr gestartet >>> ;;; Wenn nicht, dann ist MicGate = 0 >>> >>> iMidinote notnum >>> if iMidinote == 1 then >>> gkMicGate linsegr 0, 0.01, 1, 0.1, 0 >>> else >>> gkMicGate = 0 >>> printk2 gkMicGate >>> endif >>> endin >>> >>> instr 1 >>> ; ----- >>> ; Tap-Delay >>> ; MIDI-Kanal 1 >>> ; CC-1: Mikrofon und Delay Volume >>> ; CC-2: Feedback Ratio >>> ; CC-3: Delay Time >>> ; CC-4: Delay Time Shift >>> ; ----- >>> ;;; Mikrofon Input >>> aIn inch giMicIn >>> initc7 1, 1, 0 >>> kInVol ctrl7 1, 1, 0., 1. >>> kInVol port kInVol, 0.01 >>> aMicGated = aIngkMicGate >>> >>> >>> aMic = aMicGatedkInVol >>> printks2 "Mic-Volume: %f \n", kInVol >>> ; Wenn auf MIDI-Kanal 1 die MIDI-Note geschickt wird ist das Gate >>> ; für das Mikrofon offen und das Signal geht in das Delay >>> ;aMic = aIngkMicGate >>> ;;; Delay >>> ; Delay-Time >>> initc7 1, 3, 0. >>> aDelTime1 ctrl7 1, 3, 0.003, 2 >>> ; Delay-Time Offset für Links und Rechts >>> initc7 1, 4, 0. >>> aDelOffset ctrl7 1, 4, 0., 2. >>> aDelOffsetL = aDelOffset1 >>> aDelOffsetR = aDelOffset1.1 >>> ; Feedback-Ratio >>> initc7 1, 2, 0 >>> kFdb ctrl7 1, 2, 0., 1. >>> ; Delay-Buffer >>> aDumpC delayr giDelBufSize1 >>> aDel1C deltap3 aDelTime1 >>> delayw aMic+(aDel1CkFdb) >>> >>> aDumpL delayr giDelBufSize1 >>> aDel1L deltap3 aDelTime1aDelOffsetL >>> delayw aMic+(aDel1CkFdb) >>> >>> aDumpR delayr giDelBufSize1 >>> aDel1R deltap3 aDelTime1aDelOffsetR >>> delayw aMic+(aDel1CkFdb) >>> >>> >>> ;aDelL sum aDel1CkInVol, aDel1LkInVol >>> ;aDelR sum aDel1CkInVol, aDel1RkInVol >>> >>> aDelL sum aDel1C, aDel1L >>> aDelR sum aDel1C, aDel1R >>> >>> outs (aMic+aDelL)gkMasterVol, (aMic+aDelR)gkMasterVol >>> endin >>> >>> instr 8 >>> ; ----- >>> ; Master-Kanal >>> ; MIDI-Kanal 8 >>> ; CC-1: Master Volume >>> ; CC-2: G >>> ; ----- >>> ;;; Master Volume >>> initc7 8, 1, 0. >>> kMasterVol ctrl7 8, 1, 0., 1. >>> gkMasterVol portk kMasterVol, 0.01 >>> printks2 "Master-Volume: %f \n", gkMasterVol >>> endin >>> ;----------------------------------------------------------- >>> >>> >>> i100 0 z >>> i1 0 z >>> i8 0 z >>> >>> >>> Csound mailing list >>> Csound@listserv.heanet.ie >>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND >>> Send bugs reports to >>> https://github.com/csound/csound/issues >>> Discussions of bugs and features can be posted here >> >> Csound mailing list >> Csound@listserv.heanet.ie >> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND >> Send bugs reports to >> https://github.com/csound/csound/issues >> Discussions of bugs and features can be posted here > > Csound mailing list > Csound@listserv.heanet.ie > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > Send bugs reports to > https://github.com/csound/csound/issues > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-11 16:59
From	joachim heintz
Subject	Re: [Csnd] 'linsegr' is not going back to zero
	hi richard - what you would do with my suggestion: to give the job of guiding the gkMicGate to zero (fade out) to the instrument "PullDown". what happens there, is normal linseg. so no linsegr any more (also not in the other instrument). can you share your test code for linsegr, showing that it does not really reach zero? if so, we should file a bug. cheers - joachim On 11/12/2022 16:16, Richard Knight wrote: > Hi > I didn't test with midi or the if condition - really just an instrument > with linsegr & printk - and still found an inconsistency with linsegr.. > I may try and have a look at the source at some point. > > I don't use midi much and think yours is a good suggestion - however > with the if running at init-time (ie iMidiNote == 1) and given linsegr > is running at k-rate I would think the linsegr would run for the > duration of the instrument regardless of what iMidiNote is after init? I > know (but don't understand) there are some special/particular way that > instruments are handled when used with midi though. > > RK > > > On 2022-12-11 10:02, joachim heintz wrote: >> hi - >> >> i think it is more a problem with the program flow. as i read the >> code, the if-condition is only activated as long as a certain midi key >> is pressed. as the linsegr statement is in this if-clause, it will >> not be finished, if the midi key is pressed too short. >> >> an alternative would be to trigger another instrument which then puts >> the gkMicGate to zero. like: >> >> if iMidiNote == 1 then >> schedule("PulDown",0,.1) >> endif >> >> in the instrument, and as instrument: >> >> instr PullDown >> gkMicGate linseg 1,p3,0 >> endin >> >> best - >> joachim >> >> >> On 11/12/2022 00:53, Richard Knight wrote: >>> Hi >>> I tested the instrument and got the same result as you. There may >>> even be a bug with linsegr as it seems that the value at the very >>> last k-cycle is not being set. As a work around you could use the >>> xtratim opcode to add some additional release time to the instrument. >>> linsegr already extends the instrument time by the release time given >>> (0.1) so xtratim needs to be above that. 1/kr gives the time of one >>> k-cycle (which with ksmps=64 is 0.0013 seconds), and I had success >>> with the following: >>> >>> instr 100 ; Mic-Gate >>> iMidinote notnum >>> if iMidinote == 1 then >>> iReleasetime = 0.1 ; release time to be used by linsegr >>> xtratim iReleasetime + (1/kr) ; add very short additional >>> time to the existing release time >>> gkMicGate linsegr 0, 0.01, 1, iReleasetime, 0 >>> else >>> gkMicGate = 0 >>> endif >>> printk2 gkMicGate >>> endin >>> >>> Hope that helps >>> Richard >>> >>> >>> On 2022-12-09 21:12, Philipp Neumann wrote: >>>> Hello Everybody! >>>> >>>> I have some problems with the linsegr opcode, which i don’t understand. >>>> >>>> I use it as a global gate for a mic-input. It gets triggered by a >>>> specific midi note and the instrument in which it is, is only used for >>>> this. >>>> My problem is, when the note-off signal is coming to trigger the last >>>> segment of the opcode it does not gets down to 0.000. It stops always >>>> like on 0.0132 or something and the gate stays always a little bit >>>> open. >>>> Maybe someone can help. >>>> >>>> All the best, >>>> Philipp >>>> >>>> This is the Instrument. >>>> >>>> instr 100 ; Mic-Gate >>>> ;;; Über massign wird MIDI-Kanal 1 auf Instrument 1 geroutet >>>> ;;; Instrument 1 startet bei Eingang eines MIDI-Signals >>>> ;;; Wenn MIDI-Note 1 eingeht wird linsegr gestartet >>>> ;;; Wenn nicht, dann ist MicGate = 0 >>>> >>>> iMidinote notnum >>>> if iMidinote == 1 then >>>> gkMicGate linsegr 0, 0.01, 1, 0.1, 0 >>>> else >>>> gkMicGate = 0 >>>> printk2 gkMicGate >>>> endif >>>> endin >>>> >>>> >>>> This is the whole Csound-Code: >>>> >>>> >>>> >>>> >>>> -d -odac3 -iadc2 -W -3 -+rtmidi=coremidi -M4 >>>> >>>> >>>> sr = 44100 >>>> ksmps = 64 >>>> nchnls = 2 >>>> 0dbfs = 1.0 >>>> nchnls_i = 12 >>>> >>>> >>>> ;----------------------------------------------------------- >>>> #include "/Users/philippneumann/Documents/Csound/PHN-UDOs.txt" >>>> ;----------------------------------------------------------- >>>> giMicIn = 11 >>>> gkMasterVol init 0 >>>> massign 1, 100 >>>> giDelBufSize1 = 5 >>>> gkMicGate init 0 >>>> ;----------------------------------------------------------- >>>> instr 100 ; Mic-Gate >>>> ;;; Über massign wird MIDI-Kanal 1 auf Instrument 1 geroutet >>>> ;;; Instrument 1 startet bei Eingang eines MIDI-Signals >>>> ;;; Wenn MIDI-Note 1 eingeht wird linsegr gestartet >>>> ;;; Wenn nicht, dann ist MicGate = 0 >>>> >>>> iMidinote notnum >>>> if iMidinote == 1 then >>>> gkMicGate linsegr 0, 0.01, 1, 0.1, 0 >>>> else >>>> gkMicGate = 0 >>>> printk2 gkMicGate >>>> endif >>>> endin >>>> >>>> instr 1 >>>> ; ----- >>>> ; Tap-Delay >>>> ; MIDI-Kanal 1 >>>> ; CC-1: Mikrofon und Delay Volume >>>> ; CC-2: Feedback Ratio >>>> ; CC-3: Delay Time >>>> ; CC-4: Delay Time Shift >>>> ; ----- >>>> ;;; Mikrofon Input >>>> aIn inch giMicIn >>>> initc7 1, 1, 0 >>>> kInVol ctrl7 1, 1, 0., 1. >>>> kInVol port kInVol, 0.01 >>>> aMicGated = aIngkMicGate >>>> >>>> >>>> aMic = aMicGatedkInVol >>>> printks2 "Mic-Volume: %f \n", kInVol >>>> ; Wenn auf MIDI-Kanal 1 die MIDI-Note geschickt wird ist das Gate >>>> ; für das Mikrofon offen und das Signal geht in das Delay >>>> ;aMic = aIngkMicGate >>>> ;;; Delay >>>> ; Delay-Time >>>> initc7 1, 3, 0. >>>> aDelTime1 ctrl7 1, 3, 0.003, 2 >>>> ; Delay-Time Offset für Links und Rechts >>>> initc7 1, 4, 0. >>>> aDelOffset ctrl7 1, 4, 0., 2. >>>> aDelOffsetL = aDelOffset1 >>>> aDelOffsetR = aDelOffset1.1 >>>> ; Feedback-Ratio >>>> initc7 1, 2, 0 >>>> kFdb ctrl7 1, 2, 0., 1. >>>> ; Delay-Buffer >>>> aDumpC delayr giDelBufSize1 >>>> aDel1C deltap3 aDelTime1 >>>> delayw aMic+(aDel1CkFdb) >>>> >>>> aDumpL delayr giDelBufSize1 >>>> aDel1L deltap3 aDelTime1aDelOffsetL >>>> delayw aMic+(aDel1CkFdb) >>>> >>>> aDumpR delayr giDelBufSize1 >>>> aDel1R deltap3 aDelTime1aDelOffsetR >>>> delayw aMic+(aDel1CkFdb) >>>> >>>> >>>> ;aDelL sum aDel1CkInVol, aDel1LkInVol >>>> ;aDelR sum aDel1CkInVol, aDel1RkInVol >>>> >>>> aDelL sum aDel1C, aDel1L >>>> aDelR sum aDel1C, aDel1R >>>> >>>> outs (aMic+aDelL)gkMasterVol, (aMic+aDelR)gkMasterVol >>>> endin >>>> >>>> instr 8 >>>> ; ----- >>>> ; Master-Kanal >>>> ; MIDI-Kanal 8 >>>> ; CC-1: Master Volume >>>> ; CC-2: G >>>> ; ----- >>>> ;;; Master Volume >>>> initc7 8, 1, 0. >>>> kMasterVol ctrl7 8, 1, 0., 1. >>>> gkMasterVol portk kMasterVol, 0.01 >>>> printks2 "Master-Volume: %f \n", gkMasterVol >>>> endin >>>> ;----------------------------------------------------------- >>>> >>>> >>>> i100 0 z >>>> i1 0 z >>>> i8 0 z >>>> >>>> >>>> Csound mailing list >>>> Csound@listserv.heanet.ie >>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND >>>> Send bugs reports to >>>> https://github.com/csound/csound/issues >>>> Discussions of bugs and features can be posted here >>> >>> Csound mailing list >>> Csound@listserv.heanet.ie >>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND >>> Send bugs reports to >>> https://github.com/csound/csound/issues >>> Discussions of bugs and features can be posted here >> >> Csound mailing list >> Csound@listserv.heanet.ie >> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND >> Send bugs reports to >> https://github.com/csound/csound/issues >> Discussions of bugs and features can be posted here > > Csound mailing list > Csound@listserv.heanet.ie > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > Send bugs reports to > https://github.com/csound/csound/issues > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-11 18:12
From	Richard Knight
Subject	Re: [Csnd] 'linsegr' is not going back to zero
	Here's the minimal reproducible example: instr 1 kval linsegr 0, 0.1, 1, 0.1, 0 printk2 kval endin schedule(1, 0, 1) the last value I see is 0.01449 ..and a bit more examination of what's going on: instr 1 ktrig init 1 kval linsegr 0, 0.1, 1, 0.1, 0 if (kval == 0) then printf "it's 0 at %d\n", ktrig, timeinstk() ktrig += 1 endif if (lastcycle() == 1) then printf "last value is %.20f", 1, kval endif endin schedule(1, 0, 1) for this I get it's 0 at 1 last value is 0.01449275362318966538 if the release time in linsegr is 10, the last value is closer to 0: last value is 0.00014511681916878143 if xtratim is used like in my previous email, it's closer but doesn't absolutely return to the desired value. Even with 10s added using xtratim: last value is 0.00000000000000128023 Substituting linsegr with linseg ie kval linseg 1, p3, 0 works OK, kval == 0 condition is met in multiple k-cycles and the end result is last value is 0.00000000000000000000 all the best rk On 2022-12-11 16:59, joachim heintz wrote: > hi richard - > > what you would do with my suggestion: to give the job of guiding the > gkMicGate to zero (fade out) to the instrument "PullDown". what > happens there, is normal linseg. so no linsegr any more (also not in > the other instrument). > > can you share your test code for linsegr, showing that it does not > really reach zero? if so, we should file a bug. > > cheers - > joachim > > Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-11 18:17
From	Richard Knight
Subject	Re: [Csnd] 'linsegr' is not going back to zero
	NB the results shown from the print statements here are when run at sr=44100 , ksmps=64 . At other rates the results are different, but still don't end with kval as the desired value of 0 at the last cycle. On 2022-12-11 18:12, Richard Knight wrote: > Here's the minimal reproducible example: > > instr 1 > kval linsegr 0, 0.1, 1, 0.1, 0 > printk2 kval > endin > schedule(1, 0, 1) > > > the last value I see is 0.01449 > ..and a bit more examination of what's going on: > > instr 1 > ktrig init 1 > kval linsegr 0, 0.1, 1, 0.1, 0 > if (kval == 0) then > printf "it's 0 at %d\n", ktrig, timeinstk() > ktrig += 1 > endif > if (lastcycle() == 1) then > printf "last value is %.20f", 1, kval > endif > endin > schedule(1, 0, 1) > > > for this I get > it's 0 at 1 > last value is 0.01449275362318966538 > > > if the release time in linsegr is 10, the last value is closer to 0: > last value is 0.00014511681916878143 > > if xtratim is used like in my previous email, it's closer but doesn't > absolutely return to the desired value. Even with 10s added using > xtratim: > last value is 0.00000000000000128023 > > > Substituting linsegr with linseg ie > kval linseg 1, p3, 0 > works OK, kval == 0 condition is met in multiple k-cycles and the end > result is > last value is 0.00000000000000000000 > > > > all the best > rk > Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-11 18:40
From	joachim heintz
Subject	Re: [Csnd] 'linsegr' is not going back to zero
	ah yes, i can confirm it. you said you can have a look in the code? On 11/12/2022 19:17, Richard Knight wrote: > NB the results shown from the print statements here are when run at > sr=44100 , ksmps=64 . > At other rates the results are different, but still don't end with kval > as the desired value of 0 at the last cycle. > > On 2022-12-11 18:12, Richard Knight wrote: >> Here's the minimal reproducible example: >> >> instr 1 >> kval linsegr 0, 0.1, 1, 0.1, 0 >> printk2 kval >> endin >> schedule(1, 0, 1) >> >> >> the last value I see is 0.01449 >> ..and a bit more examination of what's going on: >> >> instr 1 >> ktrig init 1 >> kval linsegr 0, 0.1, 1, 0.1, 0 >> if (kval == 0) then >> printf "it's 0 at %d\n", ktrig, timeinstk() >> ktrig += 1 >> endif >> if (lastcycle() == 1) then >> printf "last value is %.20f", 1, kval >> endif >> endin >> schedule(1, 0, 1) >> >> >> for this I get >> it's 0 at 1 >> last value is 0.01449275362318966538 >> >> >> if the release time in linsegr is 10, the last value is closer to 0: >> last value is 0.00014511681916878143 >> >> if xtratim is used like in my previous email, it's closer but doesn't >> absolutely return to the desired value. Even with 10s added using >> xtratim: >> last value is 0.00000000000000128023 >> >> >> Substituting linsegr with linseg ie >> kval linseg 1, p3, 0 >> works OK, kval == 0 condition is met in multiple k-cycles and the end >> result is >> last value is 0.00000000000000000000 >> >> >> >> all the best >> rk >> > > Csound mailing list > Csound@listserv.heanet.ie > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > Send bugs reports to > https://github.com/csound/csound/issues > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-12 23:54
From	Richard Knight
Subject	Re: [Csnd] 'linsegr' is not going back to zero
	Yes, I've had a look and have an alteration that works to ensure the last value is always the iz value, will test further. On 2022-12-11 18:40, joachim heintz wrote: > ah yes, i can confirm it. > you said you can have a look in the code? > Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-13 05:19
From	Philipp Neumann
Subject	Re: [Csnd] 'linsegr' is not going back to zero
	Thank you both a lot! I’m working, for this project at least, with the ‚xtratim‘ solution. Also it’s ksmps depending. Greetings, Philipp > Am 13.12.2022 um 00:54 schrieb Richard Knight : > > Yes, I've had a look and have an alteration that works to ensure the last value is always the iz value, will test further. > > On 2022-12-11 18:40, joachim heintz wrote: >> ah yes, i can confirm it. >> you said you can have a look in the code? > > Csound mailing list > Csound@listserv.heanet.ie > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > Send bugs reports to > https://github.com/csound/csound/issues > Discussions of bugs and features can be posted here > Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-14 09:18
From	Victor Lazzarini
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	There was what we could consider a bug in linsegr (if compared to linseg), in that it never settled exactly on the final value, but one right before it and so the xtratim solution was not a complete workaround. How close would depend on ksmps and on the values of the last segment (start, dur, end). I have committed a fix to make linsegr behave like linseg, which is what some would expect. It is possible that someone would have exploited the bug since it has always been there as far as I can see (thirty years or more). There’s an associated issue I discovered, where it appears that any added extra time runs to 1 kcycle fewer than the equivalent p3 time (with no extra time added). My fix includes extending extra time by 1 kcycle if linsegr is used but this is is likely to affect other opcodes that depend on extra time. I am not sure where this discrepancy comes from, but I hope to find out. Once that is resolved, I can remove the extra kcycle added to linsegr. This fix has been applied to both csound6 branch (6.19 beta) and develop (7.0 beta) ======================== Prof. Victor Lazzarini Maynooth University Ireland > On 13 Dec 2022, at 05:19, Philipp Neumann wrote: > > Warning > > This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe. > > Thank you both a lot! > > I’m working, for this project at least, with the ‚xtratim‘ solution. Also it’s ksmps depending. > > Greetings, > Philipp > >> Am 13.12.2022 um 00:54 schrieb Richard Knight : >> >> Yes, I've had a look and have an alteration that works to ensure the last value is always the iz value, will test further. >> >> On 2022-12-11 18:40, joachim heintz wrote: >>> ah yes, i can confirm it. >>> you said you can have a look in the code? >> >> Csound mailing list >> Csound@listserv.heanet.ie >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc3748b72734c453af4c608dadcc9a03a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638065056553136061%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2kCAFxyHzLhbHecWICbffMFa9uy%2BbkRaf9KGb24%2FM9Q%3D&reserved=0 >> Send bugs reports to >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc3748b72734c453af4c608dadcc9a03a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638065056553136061%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Mbs9TuyRLpXNLcAU%2F%2Fx4LF6jToqDsTZQ6Jz%2FWJOO0%2BI%3D&reserved=0 >> Discussions of bugs and features can be posted here >> > > Csound mailing list > Csound@listserv.heanet.ie > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc3748b72734c453af4c608dadcc9a03a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638065056553136061%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2kCAFxyHzLhbHecWICbffMFa9uy%2BbkRaf9KGb24%2FM9Q%3D&reserved=0 > Send bugs reports to > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc3748b72734c453af4c608dadcc9a03a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638065056553136061%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Mbs9TuyRLpXNLcAU%2F%2Fx4LF6jToqDsTZQ6Jz%2FWJOO0%2BI%3D&reserved=0 > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-14 15:12
From	Richard Knight
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	This is great, thank you. I did wonder, as it's evidently worked like that for a long time, if it should be a new opcode, even if it could objectively be considered a bug.. Good/interesting spot with the additional extra time, sounds quite curious. On 2022-12-14 09:18, Victor Lazzarini wrote: > There was what we could consider a bug in linsegr (if compared to > linseg), in that it never settled exactly on the final value, but > one right before it and so the xtratim solution was not a complete > workaround. How close would depend on ksmps and on the > values of the last segment (start, dur, end). > > I have committed a fix to make linsegr behave like linseg, which is > what some would expect. It is possible that someone > would have exploited the bug since it has always been there as far as > I can see (thirty years or more). > > There’s an associated issue I discovered, where it appears that any > added extra time runs to 1 kcycle fewer than the equivalent > p3 time (with no extra time added). My fix includes extending extra > time by 1 kcycle if linsegr is used but this is is likely to affect > other opcodes that depend on extra time. I am not sure where this > discrepancy comes from, but I hope to find out. Once that is > resolved, I can remove the extra kcycle added to linsegr. > > This fix has been applied to both csound6 branch (6.19 beta) and > develop (7.0 beta) > ======================== > Prof. Victor Lazzarini > Maynooth University > Ireland > Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-14 15:27
From	joachim heintz
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	i think it is good to have this as a fix. we all used linsegr so much and the small difference simply did not show up in an audible way. good to have it really clean now. On 14/12/2022 16:12, Richard Knight wrote: > This is great, thank you. > I did wonder, as it's evidently worked like that for a long time, if it > should be a new opcode, even if it could objectively be considered a bug.. > Good/interesting spot with the additional extra time, sounds quite curious. > > > > On 2022-12-14 09:18, Victor Lazzarini wrote: >> There was what we could consider a bug in linsegr (if compared to >> linseg), in that it never settled exactly on the final value, but >> one right before it and so the xtratim solution was not a complete >> workaround. How close would depend on ksmps and on the >> values of the last segment (start, dur, end). >> >> I have committed a fix to make linsegr behave like linseg, which is >> what some would expect. It is possible that someone >> would have exploited the bug since it has always been there as far as >> I can see (thirty years or more). >> >> There’s an associated issue I discovered, where it appears that any >> added extra time runs to 1 kcycle fewer than the equivalent >> p3 time (with no extra time added). My fix includes extending extra >> time by 1 kcycle if linsegr is used but this is is likely to affect >> other opcodes that depend on extra time. I am not sure where this >> discrepancy comes from, but I hope to find out. Once that is >> resolved, I can remove the extra kcycle added to linsegr. >> >> This fix has been applied to both csound6 branch (6.19 beta) and >> develop (7.0 beta) >> ======================== >> Prof. Victor Lazzarini >> Maynooth University >> Ireland >> > > Csound mailing list > Csound@listserv.heanet.ie > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > Send bugs reports to > https://github.com/csound/csound/issues > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-14 15:54
From	Michael Gogins
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	Thanks, Victor, for fixing this. I think that this issue probably was a real bug that could cause clicks in releases at times. ----------------------------------------------------- Michael Gogins Irreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com On Wed, Dec 14, 2022 at 10:27 AM joachim heintz <jh@joachimheintz.de> wrote: i think it is good to have this as a fix. we all used linsegr so much and the small difference simply did not show up in an audible way. good to have it really clean now. On 14/12/2022 16:12, Richard Knight wrote: > This is great, thank you. > I did wonder, as it's evidently worked like that for a long time, if it > should be a new opcode, even if it could objectively be considered a bug.. > Good/interesting spot with the additional extra time, sounds quite curious. > > > > On 2022-12-14 09:18, Victor Lazzarini wrote: >> There was what we could consider a bug in linsegr (if compared to >> linseg), in that it never settled exactly on the final value, but >> one right before it and so the xtratim solution was not a complete >> workaround. How close would depend on ksmps and on the >> values of the last segment (start, dur, end). >> >> I have committed a fix to make linsegr behave like linseg, which is >> what some would expect. It is possible that someone >> would have exploited the bug since it has always been there as far as >> I can see (thirty years or more). >> >> There’s an associated issue I discovered, where it appears that any >> added extra time runs to 1 kcycle fewer than the equivalent >> p3 time (with no extra time added). My fix includes extending extra >> time by 1 kcycle if linsegr is used but this is is likely to affect >> other opcodes that depend on extra time. I am not sure where this >> discrepancy comes from, but I hope to find out. Once that is >> resolved, I can remove the extra kcycle added to linsegr. >> >> This fix has been applied to both csound6 branch (6.19 beta) and >> develop (7.0 beta) >> ======================== >> Prof. Victor Lazzarini >> Maynooth University >> Ireland >> > > Csound mailing list > Csound@listserv.heanet.ie > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > Send bugs reports to > https://github.com/csound/csound/issues > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-14 18:25
From	Victor Lazzarini
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	Thanks. Yes, I think on balance we should just accept the change and move on. I'm surprised it has not been detected before. Prof. Victor Lazzarini Maynooth University Ireland On 14 Dec 2022, at 15:56, Michael Gogins <michael.gogins@gmail.com> wrote: Thanks, Victor, for fixing this. I think that this issue probably was a real bug that could cause clicks in releases at times. ----------------------------------------------------- Michael Gogins Irreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com On Wed, Dec 14, 2022 at 10:27 AM joachim heintz <jh@joachimheintz.de> wrote: i think it is good to have this as a fix. we all used linsegr so much and the small difference simply did not show up in an audible way. good to have it really clean now. On 14/12/2022 16:12, Richard Knight wrote: > This is great, thank you. > I did wonder, as it's evidently worked like that for a long time, if it > should be a new opcode, even if it could objectively be considered a bug.. > Good/interesting spot with the additional extra time, sounds quite curious. > > > > On 2022-12-14 09:18, Victor Lazzarini wrote: >> There was what we could consider a bug in linsegr (if compared to >> linseg), in that it never settled exactly on the final value, but >> one right before it and so the xtratim solution was not a complete >> workaround. How close would depend on ksmps and on the >> values of the last segment (start, dur, end). >> >> I have committed a fix to make linsegr behave like linseg, which is >> what some would expect. It is possible that someone >> would have exploited the bug since it has always been there as far as >> I can see (thirty years or more). >> >> There’s an associated issue I discovered, where it appears that any >> added extra time runs to 1 kcycle fewer than the equivalent >> p3 time (with no extra time added). My fix includes extending extra >> time by 1 kcycle if linsegr is used but this is is likely to affect >> other opcodes that depend on extra time. I am not sure where this >> discrepancy comes from, but I hope to find out. Once that is >> resolved, I can remove the extra kcycle added to linsegr. >> >> This fix has been applied to both csound6 branch (6.19 beta) and >> develop (7.0 beta) >> ======================== >> Prof. Victor Lazzarini >> Maynooth University >> Ireland >> > > Csound mailing list > Csound@listserv.heanet.ie > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > Send bugs reports to > https://github.com/csound/csound/issues > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-14 21:36
From	Victor Lazzarini
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	So I got to the bottom of this. What is happening is that the lastcycle opcode is adding one extra kcycle but only in the case of no xtratim, that is where the discrepancy comes from. I can now adjust the code accordingly. ======================== Prof. Victor Lazzarini Maynooth University Ireland > On 14 Dec 2022, at 15:12, Richard Knight wrote: > > This is great, thank you. > I did wonder, as it's evidently worked like that for a long time, if it should be a new opcode, even if it could objectively be considered a bug.. > Good/interesting spot with the additional extra time, sounds quite curious. > > > > On 2022-12-14 09:18, Victor Lazzarini wrote: >> There was what we could consider a bug in linsegr (if compared to >> linseg), in that it never settled exactly on the final value, but >> one right before it and so the xtratim solution was not a complete >> workaround. How close would depend on ksmps and on the >> values of the last segment (start, dur, end). >> I have committed a fix to make linsegr behave like linseg, which is >> what some would expect. It is possible that someone >> would have exploited the bug since it has always been there as far as >> I can see (thirty years or more). >> There’s an associated issue I discovered, where it appears that any >> added extra time runs to 1 kcycle fewer than the equivalent >> p3 time (with no extra time added). My fix includes extending extra >> time by 1 kcycle if linsegr is used but this is is likely to affect >> other opcodes that depend on extra time. I am not sure where this >> discrepancy comes from, but I hope to find out. Once that is >> resolved, I can remove the extra kcycle added to linsegr. >> This fix has been applied to both csound6 branch (6.19 beta) and >> develop (7.0 beta) >> ======================== >> Prof. Victor Lazzarini >> Maynooth University >> Ireland > > Csound mailing list > Csound@listserv.heanet.ie > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C5c20711242664ac74d6008dadde5ac6b%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066275768089966%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xJul7d7DqakPPReX1VTGzPLxsjf8%2B9KxBlXOwGhVFsA%3D&reserved=0 > Send bugs reports to > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C5c20711242664ac74d6008dadde5ac6b%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066275768089966%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=q%2BZcPbTHdknurC7FdZRrc3EP%2Bk6rm3GjaBJeuVx%2Fxyw%3D&reserved=0 > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-14 21:53
From	Victor Lazzarini
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	which turns out to be complicated. Without lastcycle, linseg also finishes at the last kcycle without reaching the target, just as linsegr did (after my bug fix). So now the situation is slightly more complex because clearly this is the behaviour of these opcodes, and I am not quite sure what we need to do now. linseg will reach the final value and hold it there if the instrument duration is longer than the sum of its segments (by at least 1 kcycle), but will not reach it if the duration is equal to it. linsegr will never reach its final value unless we have an xtratim that is longer than its release duration by at least 1 kcycle. So I would like to see what people think it’s best doing. I can modify both opcodes to reach the destination with 1 kcycle short at the end or I can just modify linsegr. ======================== Prof. Victor Lazzarini Maynooth University Ireland > On 14 Dec 2022, at 21:36, Victor Lazzarini wrote: > > So I got to the bottom of this. What is happening is that the lastcycle opcode is adding one extra kcycle but only in the case of no xtratim, > that is where the discrepancy comes from. I can now adjust the code accordingly. > ======================== > Prof. Victor Lazzarini > Maynooth University > Ireland > >> On 14 Dec 2022, at 15:12, Richard Knight wrote: >> >> This is great, thank you. >> I did wonder, as it's evidently worked like that for a long time, if it should be a new opcode, even if it could objectively be considered a bug.. >> Good/interesting spot with the additional extra time, sounds quite curious. >> >> >> >> On 2022-12-14 09:18, Victor Lazzarini wrote: >>> There was what we could consider a bug in linsegr (if compared to >>> linseg), in that it never settled exactly on the final value, but >>> one right before it and so the xtratim solution was not a complete >>> workaround. How close would depend on ksmps and on the >>> values of the last segment (start, dur, end). >>> I have committed a fix to make linsegr behave like linseg, which is >>> what some would expect. It is possible that someone >>> would have exploited the bug since it has always been there as far as >>> I can see (thirty years or more). >>> There’s an associated issue I discovered, where it appears that any >>> added extra time runs to 1 kcycle fewer than the equivalent >>> p3 time (with no extra time added). My fix includes extending extra >>> time by 1 kcycle if linsegr is used but this is is likely to affect >>> other opcodes that depend on extra time. I am not sure where this >>> discrepancy comes from, but I hope to find out. Once that is >>> resolved, I can remove the extra kcycle added to linsegr. >>> This fix has been applied to both csound6 branch (6.19 beta) and >>> develop (7.0 beta) >>> ======================== >>> Prof. Victor Lazzarini >>> Maynooth University >>> Ireland >> >> Csound mailing list >> Csound@listserv.heanet.ie >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0 >> Send bugs reports to >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0 >> Discussions of bugs and features can be posted here > > > Csound mailing list > Csound@listserv.heanet.ie > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0 > Send bugs reports to > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0 > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-14 22:01
From	Victor Lazzarini
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	NB: same thing applies to linen, I just checked and it does not go all the way to 0. ======================== Prof. Victor Lazzarini Maynooth University Ireland > On 14 Dec 2022, at 21:53, Victor Lazzarini wrote: > > which turns out to be complicated. > > Without lastcycle, linseg also finishes at the last kcycle without reaching the target, just as linsegr did (after my bug fix). > So now the situation is slightly more complex because clearly this is the behaviour of these opcodes, and I am not quite sure what we need to do > now. > > linseg will reach the final value and hold it there if the instrument duration is longer than the sum of its segments (by at least 1 kcycle), but will not reach it if the > duration is equal to it. linsegr will never reach its final value unless we have an xtratim that is longer than its release duration by at least 1 kcycle. > > So I would like to see what people think it’s best doing. I can modify both opcodes to reach the destination with 1 kcycle short at the end or I can > just modify linsegr. > > > ======================== > Prof. Victor Lazzarini > Maynooth University > Ireland > >> On 14 Dec 2022, at 21:36, Victor Lazzarini wrote: >> >> So I got to the bottom of this. What is happening is that the lastcycle opcode is adding one extra kcycle but only in the case of no xtratim, >> that is where the discrepancy comes from. I can now adjust the code accordingly. >> ======================== >> Prof. Victor Lazzarini >> Maynooth University >> Ireland >> >>> On 14 Dec 2022, at 15:12, Richard Knight wrote: >>> >>> This is great, thank you. >>> I did wonder, as it's evidently worked like that for a long time, if it should be a new opcode, even if it could objectively be considered a bug.. >>> Good/interesting spot with the additional extra time, sounds quite curious. >>> >>> >>> >>> On 2022-12-14 09:18, Victor Lazzarini wrote: >>>> There was what we could consider a bug in linsegr (if compared to >>>> linseg), in that it never settled exactly on the final value, but >>>> one right before it and so the xtratim solution was not a complete >>>> workaround. How close would depend on ksmps and on the >>>> values of the last segment (start, dur, end). >>>> I have committed a fix to make linsegr behave like linseg, which is >>>> what some would expect. It is possible that someone >>>> would have exploited the bug since it has always been there as far as >>>> I can see (thirty years or more). >>>> There’s an associated issue I discovered, where it appears that any >>>> added extra time runs to 1 kcycle fewer than the equivalent >>>> p3 time (with no extra time added). My fix includes extending extra >>>> time by 1 kcycle if linsegr is used but this is is likely to affect >>>> other opcodes that depend on extra time. I am not sure where this >>>> discrepancy comes from, but I hope to find out. Once that is >>>> resolved, I can remove the extra kcycle added to linsegr. >>>> This fix has been applied to both csound6 branch (6.19 beta) and >>>> develop (7.0 beta) >>>> ======================== >>>> Prof. Victor Lazzarini >>>> Maynooth University >>>> Ireland >>> >>> Csound mailing list >>> Csound@listserv.heanet.ie >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cde3edc6a204f42532b7408dade1dc003%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066516600179599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HzPHSTZu%2FDwoCO8iosZzPz9hbUZnz%2FPFAXqDShB%2BmA8%3D&reserved=0 >>> Send bugs reports to >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cde3edc6a204f42532b7408dade1dc003%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066516600179599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=w0FiIOsYVAUOpQLUsn5qLDpVHXzU%2FKXjLuSW2jRChA4%3D&reserved=0 >>> Discussions of bugs and features can be posted here >> >> >> Csound mailing list >> Csound@listserv.heanet.ie >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cde3edc6a204f42532b7408dade1dc003%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066516600179599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HzPHSTZu%2FDwoCO8iosZzPz9hbUZnz%2FPFAXqDShB%2BmA8%3D&reserved=0 >> Send bugs reports to >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cde3edc6a204f42532b7408dade1dc003%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066516600179599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=w0FiIOsYVAUOpQLUsn5qLDpVHXzU%2FKXjLuSW2jRChA4%3D&reserved=0 >> Discussions of bugs and features can be posted here > > > Csound mailing list > Csound@listserv.heanet.ie > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cde3edc6a204f42532b7408dade1dc003%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066516600179599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HzPHSTZu%2FDwoCO8iosZzPz9hbUZnz%2FPFAXqDShB%2BmA8%3D&reserved=0 > Send bugs reports to > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cde3edc6a204f42532b7408dade1dc003%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066516600179599%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=w0FiIOsYVAUOpQLUsn5qLDpVHXzU%2FKXjLuSW2jRChA4%3D&reserved=0 > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-15 09:43
From	joachim heintz
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	in my understanding, all the -r opcodes (linenr, linsegr) add an extra time segment which is as long as the requires release time. so there is no need for any xtratim statement, and it seems to be wrong to do both. why is xtratim part of the discussion? On 14/12/2022 22:53, Victor Lazzarini wrote: > which turns out to be complicated. > > Without lastcycle, linseg also finishes at the last kcycle without reaching the target, just as linsegr did (after my bug fix). > So now the situation is slightly more complex because clearly this is the behaviour of these opcodes, and I am not quite sure what we need to do > now. > > linseg will reach the final value and hold it there if the instrument duration is longer than the sum of its segments (by at least 1 kcycle), but will not reach it if the > duration is equal to it. linsegr will never reach its final value unless we have an xtratim that is longer than its release duration by at least 1 kcycle. > > So I would like to see what people think it’s best doing. I can modify both opcodes to reach the destination with 1 kcycle short at the end or I can > just modify linsegr. > > > ======================== > Prof. Victor Lazzarini > Maynooth University > Ireland > >> On 14 Dec 2022, at 21:36, Victor Lazzarini wrote: >> >> So I got to the bottom of this. What is happening is that the lastcycle opcode is adding one extra kcycle but only in the case of no xtratim, >> that is where the discrepancy comes from. I can now adjust the code accordingly. >> ======================== >> Prof. Victor Lazzarini >> Maynooth University >> Ireland >> >>> On 14 Dec 2022, at 15:12, Richard Knight wrote: >>> >>> This is great, thank you. >>> I did wonder, as it's evidently worked like that for a long time, if it should be a new opcode, even if it could objectively be considered a bug.. >>> Good/interesting spot with the additional extra time, sounds quite curious. >>> >>> >>> >>> On 2022-12-14 09:18, Victor Lazzarini wrote: >>>> There was what we could consider a bug in linsegr (if compared to >>>> linseg), in that it never settled exactly on the final value, but >>>> one right before it and so the xtratim solution was not a complete >>>> workaround. How close would depend on ksmps and on the >>>> values of the last segment (start, dur, end). >>>> I have committed a fix to make linsegr behave like linseg, which is >>>> what some would expect. It is possible that someone >>>> would have exploited the bug since it has always been there as far as >>>> I can see (thirty years or more). >>>> There’s an associated issue I discovered, where it appears that any >>>> added extra time runs to 1 kcycle fewer than the equivalent >>>> p3 time (with no extra time added). My fix includes extending extra >>>> time by 1 kcycle if linsegr is used but this is is likely to affect >>>> other opcodes that depend on extra time. I am not sure where this >>>> discrepancy comes from, but I hope to find out. Once that is >>>> resolved, I can remove the extra kcycle added to linsegr. >>>> This fix has been applied to both csound6 branch (6.19 beta) and >>>> develop (7.0 beta) >>>> ======================== >>>> Prof. Victor Lazzarini >>>> Maynooth University >>>> Ireland >>> >>> Csound mailing list >>> Csound@listserv.heanet.ie >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0 >>> Send bugs reports to >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0 >>> Discussions of bugs and features can be posted here >> >> >> Csound mailing list >> Csound@listserv.heanet.ie >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0 >> Send bugs reports to >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0 >> Discussions of bugs and features can be posted here > > > Csound mailing list > Csound@listserv.heanet.ie > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > Send bugs reports to > https://github.com/csound/csound/issues > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-15 10:14
From	Victor Lazzarini
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	Because linsegr does not get to 0, as is the case of linseg and linen. They only get to 0 if the duration of performance is longer than the sum of segments. For linsegr that can only be achieved by using xtratim alongside it. ======================== Prof. Victor Lazzarini Maynooth University Ireland > On 15 Dec 2022, at 09:43, joachim heintz wrote: > > in my understanding, all the -r opcodes (linenr, linsegr) add an extra time segment which is as long as the requires release time. so there is no need for any xtratim statement, and it seems to be wrong to do both. > > why is xtratim part of the discussion? > > > On 14/12/2022 22:53, Victor Lazzarini wrote: >> which turns out to be complicated. >> Without lastcycle, linseg also finishes at the last kcycle without reaching the target, just as linsegr did (after my bug fix). >> So now the situation is slightly more complex because clearly this is the behaviour of these opcodes, and I am not quite sure what we need to do >> now. >> linseg will reach the final value and hold it there if the instrument duration is longer than the sum of its segments (by at least 1 kcycle), but will not reach it if the >> duration is equal to it. linsegr will never reach its final value unless we have an xtratim that is longer than its release duration by at least 1 kcycle. >> So I would like to see what people think it’s best doing. I can modify both opcodes to reach the destination with 1 kcycle short at the end or I can >> just modify linsegr. >> ======================== >> Prof. Victor Lazzarini >> Maynooth University >> Ireland >>> On 14 Dec 2022, at 21:36, Victor Lazzarini wrote: >>> >>> So I got to the bottom of this. What is happening is that the lastcycle opcode is adding one extra kcycle but only in the case of no xtratim, >>> that is where the discrepancy comes from. I can now adjust the code accordingly. >>> ======================== >>> Prof. Victor Lazzarini >>> Maynooth University >>> Ireland >>> >>>> On 14 Dec 2022, at 15:12, Richard Knight wrote: >>>> >>>> This is great, thank you. >>>> I did wonder, as it's evidently worked like that for a long time, if it should be a new opcode, even if it could objectively be considered a bug.. >>>> Good/interesting spot with the additional extra time, sounds quite curious. >>>> >>>> >>>> >>>> On 2022-12-14 09:18, Victor Lazzarini wrote: >>>>> There was what we could consider a bug in linsegr (if compared to >>>>> linseg), in that it never settled exactly on the final value, but >>>>> one right before it and so the xtratim solution was not a complete >>>>> workaround. How close would depend on ksmps and on the >>>>> values of the last segment (start, dur, end). >>>>> I have committed a fix to make linsegr behave like linseg, which is >>>>> what some would expect. It is possible that someone >>>>> would have exploited the bug since it has always been there as far as >>>>> I can see (thirty years or more). >>>>> There’s an associated issue I discovered, where it appears that any >>>>> added extra time runs to 1 kcycle fewer than the equivalent >>>>> p3 time (with no extra time added). My fix includes extending extra >>>>> time by 1 kcycle if linsegr is used but this is is likely to affect >>>>> other opcodes that depend on extra time. I am not sure where this >>>>> discrepancy comes from, but I hope to find out. Once that is >>>>> resolved, I can remove the extra kcycle added to linsegr. >>>>> This fix has been applied to both csound6 branch (6.19 beta) and >>>>> develop (7.0 beta) >>>>> ======================== >>>>> Prof. Victor Lazzarini >>>>> Maynooth University >>>>> Ireland >>>> >>>> Csound mailing list >>>> Csound@listserv.heanet.ie >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9186b42352b453cec0908dade80cef8%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066942062877647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fUWtHrw8GnorSmyXnPmtb%2BoDdcvNTy%2FP1URObDPOQpY%3D&reserved=0 >>>> Send bugs reports to >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9186b42352b453cec0908dade80cef8%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066942062877647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5oglMKqOCBreAlLul2EtwofZ6HhqlRRWHMlmlyWLHEY%3D&reserved=0 >>>> Discussions of bugs and features can be posted here >>> >>> >>> Csound mailing list >>> Csound@listserv.heanet.ie >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9186b42352b453cec0908dade80cef8%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066942062877647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fUWtHrw8GnorSmyXnPmtb%2BoDdcvNTy%2FP1URObDPOQpY%3D&reserved=0 >>> Send bugs reports to >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9186b42352b453cec0908dade80cef8%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066942062877647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5oglMKqOCBreAlLul2EtwofZ6HhqlRRWHMlmlyWLHEY%3D&reserved=0 >>> Discussions of bugs and features can be posted here >> Csound mailing list >> Csound@listserv.heanet.ie >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9186b42352b453cec0908dade80cef8%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066942062877647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fUWtHrw8GnorSmyXnPmtb%2BoDdcvNTy%2FP1URObDPOQpY%3D&reserved=0 >> Send bugs reports to >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9186b42352b453cec0908dade80cef8%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066942063033873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m9qiADQ8BaHoCzD9t2DMPoOzsfS0DuIqkkgufb62XC4%3D&reserved=0 >> Discussions of bugs and features can be posted here > > Csound mailing list > Csound@listserv.heanet.ie > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9186b42352b453cec0908dade80cef8%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066942063033873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0YIG1Q4pzGCFAlDlWhKyvbIoLZcrYxA%2FXIIikoPAi9A%3D&reserved=0 > Send bugs reports to > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9186b42352b453cec0908dade80cef8%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066942063033873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m9qiADQ8BaHoCzD9t2DMPoOzsfS0DuIqkkgufb62XC4%3D&reserved=0 > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-15 11:26
From	joachim heintz
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	the manual states: "Note that you do not need to use xtratim if you are using linsegr, since the time is extended automatically." and this runs for two seconds, although it is only called for one: instr 1 kLine linsegr 0,1,1,1,0 printk .1,kLine endin schedule(1, 0, 1) or do you mean the internal code, not the "xtratim" opcode? On 15/12/2022 11:14, Victor Lazzarini wrote: > Because linsegr does not get to 0, as is the case of linseg and linen. They only get to 0 if the duration of performance is longer than the sum of segments. For > linsegr that can only be achieved by using xtratim alongside it. > > > ======================== > Prof. Victor Lazzarini > Maynooth University > Ireland > >> On 15 Dec 2022, at 09:43, joachim heintz wrote: >> >> in my understanding, all the -r opcodes (linenr, linsegr) add an extra time segment which is as long as the requires release time. so there is no need for any xtratim statement, and it seems to be wrong to do both. >> >> why is xtratim part of the discussion? >> >> >> On 14/12/2022 22:53, Victor Lazzarini wrote: >>> which turns out to be complicated. >>> Without lastcycle, linseg also finishes at the last kcycle without reaching the target, just as linsegr did (after my bug fix). >>> So now the situation is slightly more complex because clearly this is the behaviour of these opcodes, and I am not quite sure what we need to do >>> now. >>> linseg will reach the final value and hold it there if the instrument duration is longer than the sum of its segments (by at least 1 kcycle), but will not reach it if the >>> duration is equal to it. linsegr will never reach its final value unless we have an xtratim that is longer than its release duration by at least 1 kcycle. >>> So I would like to see what people think it’s best doing. I can modify both opcodes to reach the destination with 1 kcycle short at the end or I can >>> just modify linsegr. >>> ======================== >>> Prof. Victor Lazzarini >>> Maynooth University >>> Ireland >>>> On 14 Dec 2022, at 21:36, Victor Lazzarini wrote: >>>> >>>> So I got to the bottom of this. What is happening is that the lastcycle opcode is adding one extra kcycle but only in the case of no xtratim, >>>> that is where the discrepancy comes from. I can now adjust the code accordingly. >>>> ======================== >>>> Prof. Victor Lazzarini >>>> Maynooth University >>>> Ireland >>>> >>>>> On 14 Dec 2022, at 15:12, Richard Knight wrote: >>>>> >>>>> This is great, thank you. >>>>> I did wonder, as it's evidently worked like that for a long time, if it should be a new opcode, even if it could objectively be considered a bug.. >>>>> Good/interesting spot with the additional extra time, sounds quite curious. >>>>> >>>>> >>>>> >>>>> On 2022-12-14 09:18, Victor Lazzarini wrote: >>>>>> There was what we could consider a bug in linsegr (if compared to >>>>>> linseg), in that it never settled exactly on the final value, but >>>>>> one right before it and so the xtratim solution was not a complete >>>>>> workaround. How close would depend on ksmps and on the >>>>>> values of the last segment (start, dur, end). >>>>>> I have committed a fix to make linsegr behave like linseg, which is >>>>>> what some would expect. It is possible that someone >>>>>> would have exploited the bug since it has always been there as far as >>>>>> I can see (thirty years or more). >>>>>> There’s an associated issue I discovered, where it appears that any >>>>>> added extra time runs to 1 kcycle fewer than the equivalent >>>>>> p3 time (with no extra time added). My fix includes extending extra >>>>>> time by 1 kcycle if linsegr is used but this is is likely to affect >>>>>> other opcodes that depend on extra time. I am not sure where this >>>>>> discrepancy comes from, but I hope to find out. Once that is >>>>>> resolved, I can remove the extra kcycle added to linsegr. >>>>>> This fix has been applied to both csound6 branch (6.19 beta) and >>>>>> develop (7.0 beta) >>>>>> ======================== >>>>>> Prof. Victor Lazzarini >>>>>> Maynooth University >>>>>> Ireland >>>>> >>>>> Csound mailing list >>>>> Csound@listserv.heanet.ie >>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9186b42352b453cec0908dade80cef8%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066942062877647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fUWtHrw8GnorSmyXnPmtb%2BoDdcvNTy%2FP1URObDPOQpY%3D&reserved=0 >>>>> Send bugs reports to >>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9186b42352b453cec0908dade80cef8%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066942062877647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5oglMKqOCBreAlLul2EtwofZ6HhqlRRWHMlmlyWLHEY%3D&reserved=0 >>>>> Discussions of bugs and features can be posted here >>>> >>>> >>>> Csound mailing list >>>> Csound@listserv.heanet.ie >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9186b42352b453cec0908dade80cef8%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066942062877647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fUWtHrw8GnorSmyXnPmtb%2BoDdcvNTy%2FP1URObDPOQpY%3D&reserved=0 >>>> Send bugs reports to >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9186b42352b453cec0908dade80cef8%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066942062877647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5oglMKqOCBreAlLul2EtwofZ6HhqlRRWHMlmlyWLHEY%3D&reserved=0 >>>> Discussions of bugs and features can be posted here >>> Csound mailing list >>> Csound@listserv.heanet.ie >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9186b42352b453cec0908dade80cef8%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066942062877647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fUWtHrw8GnorSmyXnPmtb%2BoDdcvNTy%2FP1URObDPOQpY%3D&reserved=0 >>> Send bugs reports to >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9186b42352b453cec0908dade80cef8%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066942063033873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m9qiADQ8BaHoCzD9t2DMPoOzsfS0DuIqkkgufb62XC4%3D&reserved=0 >>> Discussions of bugs and features can be posted here >> >> Csound mailing list >> Csound@listserv.heanet.ie >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9186b42352b453cec0908dade80cef8%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066942063033873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0YIG1Q4pzGCFAlDlWhKyvbIoLZcrYxA%2FXIIikoPAi9A%3D&reserved=0 >> Send bugs reports to >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cc9186b42352b453cec0908dade80cef8%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066942063033873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m9qiADQ8BaHoCzD9t2DMPoOzsfS0DuIqkkgufb62XC4%3D&reserved=0 >> Discussions of bugs and features can be posted here > > > Csound mailing list > Csound@listserv.heanet.ie > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > Send bugs reports to > https://github.com/csound/csound/issues > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-15 12:24
From	Victor Lazzarini
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	This is not what I mean. The situation is - you don’t need xtratim to add the release period - linsegr does not reach the final value in its release period, you can check this with your code by replacing printk with printk2 - if you want that to happen, you need to add xtratime irel + 1/kr That is the same with linseg and linen: to reach zero 1/kr needs to be added to p3 (if their total duration is set to the original value of p3). ======================== Prof. Victor Lazzarini Maynooth University Ireland > On 15 Dec 2022, at 11:26, joachim heintz wrote: > > the manual states: "Note that you do not need to use xtratim if you are using linsegr, since the time is extended automatically." > > and this runs for two seconds, although it is only called for one: > instr 1 > kLine linsegr 0,1,1,1,0 > printk .1,kLine > endin > schedule(1, 0, 1) > > or do you mean the internal code, not the "xtratim" opcode? > > > On 15/12/2022 11:14, Victor Lazzarini wrote: >> Because linsegr does not get to 0, as is the case of linseg and linen. They only get to 0 if the duration of performance is longer than the sum of segments. For >> linsegr that can only be achieved by using xtratim alongside it. >> ======================== >> Prof. Victor Lazzarini >> Maynooth University >> Ireland >>> On 15 Dec 2022, at 09:43, joachim heintz wrote: >>> >>> in my understanding, all the -r opcodes (linenr, linsegr) add an extra time segment which is as long as the requires release time. so there is no need for any xtratim statement, and it seems to be wrong to do both. >>> >>> why is xtratim part of the discussion? >>> >>> >>> On 14/12/2022 22:53, Victor Lazzarini wrote: >>>> which turns out to be complicated. >>>> Without lastcycle, linseg also finishes at the last kcycle without reaching the target, just as linsegr did (after my bug fix). >>>> So now the situation is slightly more complex because clearly this is the behaviour of these opcodes, and I am not quite sure what we need to do >>>> now. >>>> linseg will reach the final value and hold it there if the instrument duration is longer than the sum of its segments (by at least 1 kcycle), but will not reach it if the >>>> duration is equal to it. linsegr will never reach its final value unless we have an xtratim that is longer than its release duration by at least 1 kcycle. >>>> So I would like to see what people think it’s best doing. I can modify both opcodes to reach the destination with 1 kcycle short at the end or I can >>>> just modify linsegr. >>>> ======================== >>>> Prof. Victor Lazzarini >>>> Maynooth University >>>> Ireland >>>>> On 14 Dec 2022, at 21:36, Victor Lazzarini wrote: >>>>> >>>>> So I got to the bottom of this. What is happening is that the lastcycle opcode is adding one extra kcycle but only in the case of no xtratim, >>>>> that is where the discrepancy comes from. I can now adjust the code accordingly. >>>>> ======================== >>>>> Prof. Victor Lazzarini >>>>> Maynooth University >>>>> Ireland >>>>> >>>>>> On 14 Dec 2022, at 15:12, Richard Knight wrote: >>>>>> >>>>>> This is great, thank you. >>>>>> I did wonder, as it's evidently worked like that for a long time, if it should be a new opcode, even if it could objectively be considered a bug.. >>>>>> Good/interesting spot with the additional extra time, sounds quite curious. >>>>>> >>>>>> >>>>>> >>>>>> On 2022-12-14 09:18, Victor Lazzarini wrote: >>>>>>> There was what we could consider a bug in linsegr (if compared to >>>>>>> linseg), in that it never settled exactly on the final value, but >>>>>>> one right before it and so the xtratim solution was not a complete >>>>>>> workaround. How close would depend on ksmps and on the >>>>>>> values of the last segment (start, dur, end). >>>>>>> I have committed a fix to make linsegr behave like linseg, which is >>>>>>> what some would expect. It is possible that someone >>>>>>> would have exploited the bug since it has always been there as far as >>>>>>> I can see (thirty years or more). >>>>>>> There’s an associated issue I discovered, where it appears that any >>>>>>> added extra time runs to 1 kcycle fewer than the equivalent >>>>>>> p3 time (with no extra time added). My fix includes extending extra >>>>>>> time by 1 kcycle if linsegr is used but this is is likely to affect >>>>>>> other opcodes that depend on extra time. I am not sure where this >>>>>>> discrepancy comes from, but I hope to find out. Once that is >>>>>>> resolved, I can remove the extra kcycle added to linsegr. >>>>>>> This fix has been applied to both csound6 branch (6.19 beta) and >>>>>>> develop (7.0 beta) >>>>>>> ======================== >>>>>>> Prof. Victor Lazzarini >>>>>>> Maynooth University >>>>>>> Ireland >>>>>> >>>>>> Csound mailing list >>>>>> Csound@listserv.heanet.ie >>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y9iRfovopTLQlnxq2moy6hq35U3lobC48EMDpHvQYeg%3D&reserved=0 >>>>>> Send bugs reports to >>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T%2F7RDctkY91mLrA2uclZ89Vy4ii9jUQZjwmgpIbp5XQ%3D&reserved=0 >>>>>> Discussions of bugs and features can be posted here >>>>> >>>>> >>>>> Csound mailing list >>>>> Csound@listserv.heanet.ie >>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y9iRfovopTLQlnxq2moy6hq35U3lobC48EMDpHvQYeg%3D&reserved=0 >>>>> Send bugs reports to >>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T%2F7RDctkY91mLrA2uclZ89Vy4ii9jUQZjwmgpIbp5XQ%3D&reserved=0 >>>>> Discussions of bugs and features can be posted here >>>> Csound mailing list >>>> Csound@listserv.heanet.ie >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y9iRfovopTLQlnxq2moy6hq35U3lobC48EMDpHvQYeg%3D&reserved=0 >>>> Send bugs reports to >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T%2F7RDctkY91mLrA2uclZ89Vy4ii9jUQZjwmgpIbp5XQ%3D&reserved=0 >>>> Discussions of bugs and features can be posted here >>> >>> Csound mailing list >>> Csound@listserv.heanet.ie >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y9iRfovopTLQlnxq2moy6hq35U3lobC48EMDpHvQYeg%3D&reserved=0 >>> Send bugs reports to >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T%2F7RDctkY91mLrA2uclZ89Vy4ii9jUQZjwmgpIbp5XQ%3D&reserved=0 >>> Discussions of bugs and features can be posted here >> Csound mailing list >> Csound@listserv.heanet.ie >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y9iRfovopTLQlnxq2moy6hq35U3lobC48EMDpHvQYeg%3D&reserved=0 >> Send bugs reports to >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T%2F7RDctkY91mLrA2uclZ89Vy4ii9jUQZjwmgpIbp5XQ%3D&reserved=0 >> Discussions of bugs and features can be posted here > > Csound mailing list > Csound@listserv.heanet.ie > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y9iRfovopTLQlnxq2moy6hq35U3lobC48EMDpHvQYeg%3D&reserved=0 > Send bugs reports to > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T%2F7RDctkY91mLrA2uclZ89Vy4ii9jUQZjwmgpIbp5XQ%3D&reserved=0 > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-15 16:03
From	joachim heintz
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	ok thanks. now i get this connection. On 15/12/2022 13:24, Victor Lazzarini wrote: > This is not what I mean. The situation is > > - you don’t need xtratim to add the release period > > - linsegr does not reach the final value in its release period, you can check this with your code by replacing printk with printk2 > > - if you want that to happen, you need to add xtratime irel + 1/kr > > That is the same with linseg and linen: to reach zero 1/kr needs to be added to p3 (if their total duration is set to the original value of p3). > ======================== > Prof. Victor Lazzarini > Maynooth University > Ireland > >> On 15 Dec 2022, at 11:26, joachim heintz wrote: >> >> the manual states: "Note that you do not need to use xtratim if you are using linsegr, since the time is extended automatically." >> >> and this runs for two seconds, although it is only called for one: >> instr 1 >> kLine linsegr 0,1,1,1,0 >> printk .1,kLine >> endin >> schedule(1, 0, 1) >> >> or do you mean the internal code, not the "xtratim" opcode? >> >> >> On 15/12/2022 11:14, Victor Lazzarini wrote: >>> Because linsegr does not get to 0, as is the case of linseg and linen. They only get to 0 if the duration of performance is longer than the sum of segments. For >>> linsegr that can only be achieved by using xtratim alongside it. >>> ======================== >>> Prof. Victor Lazzarini >>> Maynooth University >>> Ireland >>>> On 15 Dec 2022, at 09:43, joachim heintz wrote: >>>> >>>> in my understanding, all the -r opcodes (linenr, linsegr) add an extra time segment which is as long as the requires release time. so there is no need for any xtratim statement, and it seems to be wrong to do both. >>>> >>>> why is xtratim part of the discussion? >>>> >>>> >>>> On 14/12/2022 22:53, Victor Lazzarini wrote: >>>>> which turns out to be complicated. >>>>> Without lastcycle, linseg also finishes at the last kcycle without reaching the target, just as linsegr did (after my bug fix). >>>>> So now the situation is slightly more complex because clearly this is the behaviour of these opcodes, and I am not quite sure what we need to do >>>>> now. >>>>> linseg will reach the final value and hold it there if the instrument duration is longer than the sum of its segments (by at least 1 kcycle), but will not reach it if the >>>>> duration is equal to it. linsegr will never reach its final value unless we have an xtratim that is longer than its release duration by at least 1 kcycle. >>>>> So I would like to see what people think it’s best doing. I can modify both opcodes to reach the destination with 1 kcycle short at the end or I can >>>>> just modify linsegr. >>>>> ======================== >>>>> Prof. Victor Lazzarini >>>>> Maynooth University >>>>> Ireland >>>>>> On 14 Dec 2022, at 21:36, Victor Lazzarini wrote: >>>>>> >>>>>> So I got to the bottom of this. What is happening is that the lastcycle opcode is adding one extra kcycle but only in the case of no xtratim, >>>>>> that is where the discrepancy comes from. I can now adjust the code accordingly. >>>>>> ======================== >>>>>> Prof. Victor Lazzarini >>>>>> Maynooth University >>>>>> Ireland >>>>>> >>>>>>> On 14 Dec 2022, at 15:12, Richard Knight wrote: >>>>>>> >>>>>>> This is great, thank you. >>>>>>> I did wonder, as it's evidently worked like that for a long time, if it should be a new opcode, even if it could objectively be considered a bug.. >>>>>>> Good/interesting spot with the additional extra time, sounds quite curious. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2022-12-14 09:18, Victor Lazzarini wrote: >>>>>>>> There was what we could consider a bug in linsegr (if compared to >>>>>>>> linseg), in that it never settled exactly on the final value, but >>>>>>>> one right before it and so the xtratim solution was not a complete >>>>>>>> workaround. How close would depend on ksmps and on the >>>>>>>> values of the last segment (start, dur, end). >>>>>>>> I have committed a fix to make linsegr behave like linseg, which is >>>>>>>> what some would expect. It is possible that someone >>>>>>>> would have exploited the bug since it has always been there as far as >>>>>>>> I can see (thirty years or more). >>>>>>>> There’s an associated issue I discovered, where it appears that any >>>>>>>> added extra time runs to 1 kcycle fewer than the equivalent >>>>>>>> p3 time (with no extra time added). My fix includes extending extra >>>>>>>> time by 1 kcycle if linsegr is used but this is is likely to affect >>>>>>>> other opcodes that depend on extra time. I am not sure where this >>>>>>>> discrepancy comes from, but I hope to find out. Once that is >>>>>>>> resolved, I can remove the extra kcycle added to linsegr. >>>>>>>> This fix has been applied to both csound6 branch (6.19 beta) and >>>>>>>> develop (7.0 beta) >>>>>>>> ======================== >>>>>>>> Prof. Victor Lazzarini >>>>>>>> Maynooth University >>>>>>>> Ireland >>>>>>> >>>>>>> Csound mailing list >>>>>>> Csound@listserv.heanet.ie >>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y9iRfovopTLQlnxq2moy6hq35U3lobC48EMDpHvQYeg%3D&reserved=0 >>>>>>> Send bugs reports to >>>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T%2F7RDctkY91mLrA2uclZ89Vy4ii9jUQZjwmgpIbp5XQ%3D&reserved=0 >>>>>>> Discussions of bugs and features can be posted here >>>>>> >>>>>> >>>>>> Csound mailing list >>>>>> Csound@listserv.heanet.ie >>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y9iRfovopTLQlnxq2moy6hq35U3lobC48EMDpHvQYeg%3D&reserved=0 >>>>>> Send bugs reports to >>>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T%2F7RDctkY91mLrA2uclZ89Vy4ii9jUQZjwmgpIbp5XQ%3D&reserved=0 >>>>>> Discussions of bugs and features can be posted here >>>>> Csound mailing list >>>>> Csound@listserv.heanet.ie >>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y9iRfovopTLQlnxq2moy6hq35U3lobC48EMDpHvQYeg%3D&reserved=0 >>>>> Send bugs reports to >>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T%2F7RDctkY91mLrA2uclZ89Vy4ii9jUQZjwmgpIbp5XQ%3D&reserved=0 >>>>> Discussions of bugs and features can be posted here >>>> >>>> Csound mailing list >>>> Csound@listserv.heanet.ie >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y9iRfovopTLQlnxq2moy6hq35U3lobC48EMDpHvQYeg%3D&reserved=0 >>>> Send bugs reports to >>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T%2F7RDctkY91mLrA2uclZ89Vy4ii9jUQZjwmgpIbp5XQ%3D&reserved=0 >>>> Discussions of bugs and features can be posted here >>> Csound mailing list >>> Csound@listserv.heanet.ie >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y9iRfovopTLQlnxq2moy6hq35U3lobC48EMDpHvQYeg%3D&reserved=0 >>> Send bugs reports to >>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T%2F7RDctkY91mLrA2uclZ89Vy4ii9jUQZjwmgpIbp5XQ%3D&reserved=0 >>> Discussions of bugs and features can be posted here >> >> Csound mailing list >> Csound@listserv.heanet.ie >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Y9iRfovopTLQlnxq2moy6hq35U3lobC48EMDpHvQYeg%3D&reserved=0 >> Send bugs reports to >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7C6a1d022a22f84eeb1fed08dade8f4bb3%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638067004298618736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T%2F7RDctkY91mLrA2uclZ89Vy4ii9jUQZjwmgpIbp5XQ%3D&reserved=0 >> Discussions of bugs and features can be posted here > > > Csound mailing list > Csound@listserv.heanet.ie > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > Send bugs reports to > https://github.com/csound/csound/issues > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-15 17:09
From	"Dr. Richard Boulanger"
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	I agree! fix. - Dr.B Dr. Richard Boulanger Professor Electronic Production and Design Berklee College of Music Professional Writing & Technology Division On Wed, Dec 14, 2022 at 10:28 AM joachim heintz <jh@joachimheintz.de> wrote: i think it is good to have this as a fix. we all used linsegr so much and the small difference simply did not show up in an audible way. good to have it really clean now. On 14/12/2022 16:12, Richard Knight wrote: > This is great, thank you. > I did wonder, as it's evidently worked like that for a long time, if it > should be a new opcode, even if it could objectively be considered a bug.. > Good/interesting spot with the additional extra time, sounds quite curious. > > > > On 2022-12-14 09:18, Victor Lazzarini wrote: >> There was what we could consider a bug in linsegr (if compared to >> linseg), in that it never settled exactly on the final value, but >> one right before it and so the xtratim solution was not a complete >> workaround. How close would depend on ksmps and on the >> values of the last segment (start, dur, end). >> >> I have committed a fix to make linsegr behave like linseg, which is >> what some would expect. It is possible that someone >> would have exploited the bug since it has always been there as far as >> I can see (thirty years or more). >> >> There’s an associated issue I discovered, where it appears that any >> added extra time runs to 1 kcycle fewer than the equivalent >> p3 time (with no extra time added). My fix includes extending extra >> time by 1 kcycle if linsegr is used but this is is likely to affect >> other opcodes that depend on extra time. I am not sure where this >> discrepancy comes from, but I hope to find out. Once that is >> resolved, I can remove the extra kcycle added to linsegr. >> >> This fix has been applied to both csound6 branch (6.19 beta) and >> develop (7.0 beta) >> ======================== >> Prof. Victor Lazzarini >> Maynooth University >> Ireland >> > > Csound mailing list > Csound@listserv.heanet.ie > https://us-west-2.protection.sophos.com?d=heanet.ie&u=aHR0cHM6Ly9saXN0c2Vydi5oZWFuZXQuaWUvY2dpLWJpbi93YT9BMD1DU09VTkQ=&i=NWYxNzBkMDNiNTVmZGEwZmIyNjczYmRm&t=WVZMRlI4dlFUVUZ6V2NTOUU5eE9lZnFIemtoc2hxYlBDMFFCWmtKZzhzRT0=&h=568a006ebd3f4e41ad1705e94acbd30e&s=AVNPUEhUT0NFTkNSWVBUSVYpmKWVU1jKuTPLD5gnaWwAaG5wwcHTpfjKIfFGmt9h9A > Send bugs reports to > https://us-west-2.protection.sophos.com?d=github.com&u=aHR0cHM6Ly9naXRodWIuY29tL2Nzb3VuZC9jc291bmQvaXNzdWVz&i=NWYxNzBkMDNiNTVmZGEwZmIyNjczYmRm&t=YlNrQ2lLclRLZUpGUE1iR0FyY2M1eW1NTUU5SUozWlJwMTNZU2NXT1BLOD0=&h=568a006ebd3f4e41ad1705e94acbd30e&s=AVNPUEhUT0NFTkNSWVBUSVYpmKWVU1jKuTPLD5gnaWwAaG5wwcHTpfjKIfFGmt9h9A > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://us-west-2.protection.sophos.com?d=heanet.ie&u=aHR0cHM6Ly9saXN0c2Vydi5oZWFuZXQuaWUvY2dpLWJpbi93YT9BMD1DU09VTkQ=&i=NWYxNzBkMDNiNTVmZGEwZmIyNjczYmRm&t=WVZMRlI4dlFUVUZ6V2NTOUU5eE9lZnFIemtoc2hxYlBDMFFCWmtKZzhzRT0=&h=568a006ebd3f4e41ad1705e94acbd30e&s=AVNPUEhUT0NFTkNSWVBUSVYpmKWVU1jKuTPLD5gnaWwAaG5wwcHTpfjKIfFGmt9h9A Send bugs reports to https://us-west-2.protection.sophos.com?d=github.com&u=aHR0cHM6Ly9naXRodWIuY29tL2Nzb3VuZC9jc291bmQvaXNzdWVz&i=NWYxNzBkMDNiNTVmZGEwZmIyNjczYmRm&t=YlNrQ2lLclRLZUpGUE1iR0FyY2M1eW1NTUU5SUozWlJwMTNZU2NXT1BLOD0=&h=568a006ebd3f4e41ad1705e94acbd30e&s=AVNPUEhUT0NFTkNSWVBUSVYpmKWVU1jKuTPLD5gnaWwAaG5wwcHTpfjKIfFGmt9h9A Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-16 02:24
From	Richard Knight
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	I forgot that lastcycle adds a k-cycle. I think I'd be inclined towards having both linseg and linsegr reach the final value without having to use xtratim (if I'm following correctly and that's the option). On 2022-12-14 21:53, Victor Lazzarini wrote: > which turns out to be complicated. > > Without lastcycle, linseg also finishes at the last kcycle without > reaching the target, just as linsegr did (after my bug fix). > So now the situation is slightly more complex because clearly this is > the behaviour of these opcodes, and I am not quite sure what we need > to do > now. > > linseg will reach the final value and hold it there if the instrument > duration is longer than the sum of its segments (by at least 1 > kcycle), but will not reach it if the > duration is equal to it. linsegr will never reach its final value > unless we have an xtratim that is longer than its release duration by > at least 1 kcycle. > > So I would like to see what people think it’s best doing. I can modify > both opcodes to reach the destination with 1 kcycle short at the end > or I can > just modify linsegr. > > > ======================== > Prof. Victor Lazzarini > Maynooth University > Ireland > Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-16 12:38
From	Oeyvind Brandtsegg
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	Hi, If you are still asking for input on this, I have a suggestion: linseg, as you describe it works now will reach the end value on time. We only see it complete the segment if the instr duration is extended with at least one k cycle. It still makes sense to have it this way, since all the line segments are joined this way: the end value is also the start value of the next segment. So it also have to be this way to ensure that the next segment starts with the correct value at the described time. Then the *r (linsegr) family will always be special, since the release segment does not have anything coming after it. So it makes sense to let it finish the release line segment one k-cycle earlier, so that it can reach the described final value within its life span. It is also ok to just extend the release time with one k-cycle if you prefer that. The only possible problem with that is if someone expect the instrument to be inactive at that exact time (say, if you have an algorithmic generating process with a polyphony limitation, then the voice will not be available until the next k-cycle... and if the next event from the generator algorithm is then skipped, the algorithm in question might not work as the author expected because of the one-cycle extra release time... and it would be very hard for them to find the cause of the problem in that case). all best Øyvind ons. 14. des. 2022 kl. 22:54 skrev Victor Lazzarini <Victor.Lazzarini@mu.ie>: which turns out to be complicated. Without lastcycle, linseg also finishes at the last kcycle without reaching the target, just as linsegr did (after my bug fix). So now the situation is slightly more complex because clearly this is the behaviour of these opcodes, and I am not quite sure what we need to do now. linseg will reach the final value and hold it there if the instrument duration is longer than the sum of its segments (by at least 1 kcycle), but will not reach it if the duration is equal to it. linsegr will never reach its final value unless we have an xtratim that is longer than its release duration by at least 1 kcycle. So I would like to see what people think it’s best doing. I can modify both opcodes to reach the destination with 1 kcycle short at the end or I can just modify linsegr. ======================== Prof. Victor Lazzarini Maynooth University Ireland > On 14 Dec 2022, at 21:36, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote: > > So I got to the bottom of this. What is happening is that the lastcycle opcode is adding one extra kcycle but only in the case of no xtratim, > that is where the discrepancy comes from. I can now adjust the code accordingly. > ======================== > Prof. Victor Lazzarini > Maynooth University > Ireland > >> On 14 Dec 2022, at 15:12, Richard Knight <richard@1BPM.NET> wrote: >> >> This is great, thank you. >> I did wonder, as it's evidently worked like that for a long time, if it should be a new opcode, even if it could objectively be considered a bug.. >> Good/interesting spot with the additional extra time, sounds quite curious. >> >> >> >> On 2022-12-14 09:18, Victor Lazzarini wrote: >>> There was what we could consider a bug in linsegr (if compared to >>> linseg), in that it never settled exactly on the final value, but >>> one right before it and so the xtratim solution was not a complete >>> workaround. How close would depend on ksmps and on the >>> values of the last segment (start, dur, end). >>> I have committed a fix to make linsegr behave like linseg, which is >>> what some would expect. It is possible that someone >>> would have exploited the bug since it has always been there as far as >>> I can see (thirty years or more). >>> There’s an associated issue I discovered, where it appears that any >>> added extra time runs to 1 kcycle fewer than the equivalent >>> p3 time (with no extra time added). My fix includes extending extra >>> time by 1 kcycle if linsegr is used but this is is likely to affect >>> other opcodes that depend on extra time. I am not sure where this >>> discrepancy comes from, but I hope to find out. Once that is >>> resolved, I can remove the extra kcycle added to linsegr. >>> This fix has been applied to both csound6 branch (6.19 beta) and >>> develop (7.0 beta) >>> ======================== >>> Prof. Victor Lazzarini >>> Maynooth University >>> Ireland >> >> Csound mailing list >> Csound@listserv.heanet.ie >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0 >> Send bugs reports to >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0 >> Discussions of bugs and features can be posted here > > > Csound mailing list > Csound@listserv.heanet.ie > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0 > Send bugs reports to > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0 > Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-16 15:49
From	joachim heintz
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	yes i think to treat the -r opcodes differently (compared to linseg etc) and let them reach the target in time, that would be the best solution. On 16/12/2022 13:38, Oeyvind Brandtsegg wrote: > Hi, > If you are still asking for input on this, I have a suggestion: > > linseg, as you describe it works now will reach the end value on time. > We only see it complete the segment if the instr duration is extended > with at least one k cycle. It still makes sense to have it this way, > since all the line segments are joined this way: the end value is also > the start value of the next segment. So it also have to be this way to > ensure that the next segment starts with the correct value at the > described time. > > Then the *r (linsegr) family will always be special, since the release > segment does not have anything coming after it. So it makes sense to let > it finish the release line segment one k-cycle earlier, so that it can > reach the described final value within its life span. It is also ok to > just extend the release time with one k-cycle if you prefer that. The > only possible problem with that is if someone expect the instrument to > be inactive at that exact time (say, if you have an algorithmic > generating process with a polyphony limitation, then the voice will not > be available until the next k-cycle... and if the next event from the > generator algorithm is then skipped, the algorithm in question might not > work as the author expected because of the one-cycle extra release > time... and it would be very hard for them to find the cause of the > problem in that case). > > all best > Øyvind > > > ons. 14. des. 2022 kl. 22:54 skrev Victor Lazzarini > >: > > which turns out to be complicated. > > Without lastcycle, linseg also finishes at the last kcycle without > reaching the target, just as linsegr did (after my bug fix). > So now the situation is slightly more complex because clearly this > is the behaviour of these opcodes, and I am not quite sure what we > need to do > now. > > linseg will reach the final value and hold it there if the > instrument duration is longer than the sum of its segments (by at > least 1 kcycle), but will not reach it if the > duration is equal to it. linsegr will never reach its final value > unless we have an xtratim that is longer than its release duration > by at least 1 kcycle. > > So I would like to see what people think it’s best doing. I can > modify both opcodes to reach the destination with 1 kcycle short at > the end or I can > just modify linsegr. > > > ======================== > Prof. Victor Lazzarini > Maynooth University > Ireland > > > On 14 Dec 2022, at 21:36, Victor Lazzarini > > wrote: > > > > So I got to the bottom of this. What is happening is that the > lastcycle opcode is adding one extra kcycle but only in the case of > no xtratim, > > that is where the discrepancy comes from. I can now adjust the > code accordingly. > > ======================== > > Prof. Victor Lazzarini > > Maynooth University > > Ireland > > > >> On 14 Dec 2022, at 15:12, Richard Knight > wrote: > >> > >> This is great, thank you. > >> I did wonder, as it's evidently worked like that for a long > time, if it should be a new opcode, even if it could objectively be > considered a bug.. > >> Good/interesting spot with the additional extra time, sounds > quite curious. > >> > >> > >> > >> On 2022-12-14 09:18, Victor Lazzarini wrote: > >>> There was what we could consider a bug in linsegr (if compared to > >>> linseg), in that it never settled exactly on the final value, but > >>> one right before it and so the xtratim solution was not a complete > >>> workaround. How close would depend on ksmps and on the > >>> values of the last segment (start, dur, end). > >>> I have committed a fix to make linsegr behave like linseg, which is > >>> what some would expect. It is possible that someone > >>> would have exploited the bug since it has always been there as > far as > >>> I can see (thirty years or more). > >>> There’s an associated issue I discovered, where it appears that any > >>> added extra time runs to 1 kcycle fewer than the equivalent > >>> p3 time (with no extra time added). My fix includes extending extra > >>> time by 1 kcycle if linsegr is used but this is is likely to affect > >>> other opcodes that depend on extra time. I am not sure where this > >>> discrepancy comes from, but I hope to find out. Once that is > >>> resolved, I can remove the extra kcycle added to linsegr. > >>> This fix has been applied to both csound6 branch (6.19 beta) and > >>> develop (7.0 beta) > >>> ======================== > >>> Prof. Victor Lazzarini > >>> Maynooth University > >>> Ireland > >> > >> Csound mailing list > >> Csound@listserv.heanet.ie > >> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0 > >> Send bugs reports to > >> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0 > >> Discussions of bugs and features can be posted here > > > > > > Csound mailing list > > Csound@listserv.heanet.ie > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0 > > Send bugs reports to > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0 > > Discussions of bugs and features can be posted here > > > Csound mailing list > Csound@listserv.heanet.ie > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > > Send bugs reports to > https://github.com/csound/csound/issues > > Discussions of bugs and features can be posted here > > Csound mailing list Csound@listserv.heanet.ie > > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > Send bugs reports to > https://github.com/csound/csound/issues > Discussions of bugs and > features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-16 18:15
From	Arthur Hunkins <000001e1d761dea2-dmarc-request@LISTSERV.HEANET.IE>
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	I agree. Art Hunkins http://www.arthunkins.com On Fri, Dec 16, 2022 at 10:49 AM joachim heintz <jh@joachimheintz.de> wrote: yes i think to treat the -r opcodes differently (compared to linseg etc) and let them reach the target in time, that would be the best solution. On 16/12/2022 13:38, Oeyvind Brandtsegg wrote: > Hi, > If you are still asking for input on this, I have a suggestion: > > linseg, as you describe it works now will reach the end value on time. > We only see it complete the segment if the instr duration is extended > with at least one k cycle. It still makes sense to have it this way, > since all the line segments are joined this way: the end value is also > the start value of the next segment. So it also have to be this way to > ensure that the next segment starts with the correct value at the > described time. > > Then the *r (linsegr) family will always be special, since the release > segment does not have anything coming after it. So it makes sense to let > it finish the release line segment one k-cycle earlier, so that it can > reach the described final value within its life span. It is also ok to > just extend the release time with one k-cycle if you prefer that. The > only possible problem with that is if someone expect the instrument to > be inactive at that exact time (say, if you have an algorithmic > generating process with a polyphony limitation, then the voice will not > be available until the next k-cycle... and if the next event from the > generator algorithm is then skipped, the algorithm in question might not > work as the author expected because of the one-cycle extra release > time... and it would be very hard for them to find the cause of the > problem in that case). > > all best > Øyvind > > > ons. 14. des. 2022 kl. 22:54 skrev Victor Lazzarini > <Victor.Lazzarini@mu.ie <mailto:Victor.Lazzarini@mu.ie>>: > > which turns out to be complicated. > > Without lastcycle, linseg also finishes at the last kcycle without > reaching the target, just as linsegr did (after my bug fix). > So now the situation is slightly more complex because clearly this > is the behaviour of these opcodes, and I am not quite sure what we > need to do > now. > > linseg will reach the final value and hold it there if the > instrument duration is longer than the sum of its segments (by at > least 1 kcycle), but will not reach it if the > duration is equal to it. linsegr will never reach its final value > unless we have an xtratim that is longer than its release duration > by at least 1 kcycle. > > So I would like to see what people think it’s best doing. I can > modify both opcodes to reach the destination with 1 kcycle short at > the end or I can > just modify linsegr. > > > ======================== > Prof. Victor Lazzarini > Maynooth University > Ireland > > > On 14 Dec 2022, at 21:36, Victor Lazzarini > <Victor.Lazzarini@mu.ie <mailto:Victor.Lazzarini@mu.ie>> wrote: > > > > So I got to the bottom of this. What is happening is that the > lastcycle opcode is adding one extra kcycle but only in the case of > no xtratim, > > that is where the discrepancy comes from. I can now adjust the > code accordingly. > > ======================== > > Prof. Victor Lazzarini > > Maynooth University > > Ireland > > > >> On 14 Dec 2022, at 15:12, Richard Knight <richard@1BPM.NET > <mailto:richard@1BPM.NET>> wrote: > >> > >> This is great, thank you. > >> I did wonder, as it's evidently worked like that for a long > time, if it should be a new opcode, even if it could objectively be > considered a bug.. > >> Good/interesting spot with the additional extra time, sounds > quite curious. > >> > >> > >> > >> On 2022-12-14 09:18, Victor Lazzarini wrote: > >>> There was what we could consider a bug in linsegr (if compared to > >>> linseg), in that it never settled exactly on the final value, but > >>> one right before it and so the xtratim solution was not a complete > >>> workaround. How close would depend on ksmps and on the > >>> values of the last segment (start, dur, end). > >>> I have committed a fix to make linsegr behave like linseg, which is > >>> what some would expect. It is possible that someone > >>> would have exploited the bug since it has always been there as > far as > >>> I can see (thirty years or more). > >>> There’s an associated issue I discovered, where it appears that any > >>> added extra time runs to 1 kcycle fewer than the equivalent > >>> p3 time (with no extra time added). My fix includes extending extra > >>> time by 1 kcycle if linsegr is used but this is is likely to affect > >>> other opcodes that depend on extra time. I am not sure where this > >>> discrepancy comes from, but I hope to find out. Once that is > >>> resolved, I can remove the extra kcycle added to linsegr. > >>> This fix has been applied to both csound6 branch (6.19 beta) and > >>> develop (7.0 beta) > >>> ======================== > >>> Prof. Victor Lazzarini > >>> Maynooth University > >>> Ireland > >> > >> Csound mailing list > >> Csound@listserv.heanet.ie <mailto:Csound@listserv.heanet.ie> > >> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0> > >> Send bugs reports to > >> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0> > >> Discussions of bugs and features can be posted here > > > > > > Csound mailing list > > Csound@listserv.heanet.ie <mailto:Csound@listserv.heanet.ie> > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0> > > Send bugs reports to > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0> > > Discussions of bugs and features can be posted here > > > Csound mailing list > Csound@listserv.heanet.ie <mailto:Csound@listserv.heanet.ie> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > <https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND> > Send bugs reports to > https://github.com/csound/csound/issues > <https://github.com/csound/csound/issues> > Discussions of bugs and features can be posted here > > Csound mailing list Csound@listserv.heanet.ie > <mailto:Csound@listserv.heanet.ie> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > <https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND> Send bugs reports to > https://github.com/csound/csound/issues > <https://github.com/csound/csound/issues> Discussions of bugs and > features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-17 09:42
From	Victor Lazzarini
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	ok, so I think the fix I have already applied is sufficient. Rather than mess with the rate of the final segment, I think to extend the release by 1/kr is a lesser evil. Prof. Victor Lazzarini Maynooth University Ireland On 16 Dec 2022, at 18:17, Arthur Hunkins <000001e1d761dea2-dmarc-request@listserv.heanet.ie> wrote: I agree. Art Hunkins http://www.arthunkins.com On Fri, Dec 16, 2022 at 10:49 AM joachim heintz <jh@joachimheintz.de> wrote: yes i think to treat the -r opcodes differently (compared to linseg etc) and let them reach the target in time, that would be the best solution. On 16/12/2022 13:38, Oeyvind Brandtsegg wrote: > Hi, > If you are still asking for input on this, I have a suggestion: > > linseg, as you describe it works now will reach the end value on time. > We only see it complete the segment if the instr duration is extended > with at least one k cycle. It still makes sense to have it this way, > since all the line segments are joined this way: the end value is also > the start value of the next segment. So it also have to be this way to > ensure that the next segment starts with the correct value at the > described time. > > Then the *r (linsegr) family will always be special, since the release > segment does not have anything coming after it. So it makes sense to let > it finish the release line segment one k-cycle earlier, so that it can > reach the described final value within its life span. It is also ok to > just extend the release time with one k-cycle if you prefer that. The > only possible problem with that is if someone expect the instrument to > be inactive at that exact time (say, if you have an algorithmic > generating process with a polyphony limitation, then the voice will not > be available until the next k-cycle... and if the next event from the > generator algorithm is then skipped, the algorithm in question might not > work as the author expected because of the one-cycle extra release > time... and it would be very hard for them to find the cause of the > problem in that case). > > all best > Øyvind > > > ons. 14. des. 2022 kl. 22:54 skrev Victor Lazzarini > <Victor.Lazzarini@mu.ie <mailto:Victor.Lazzarini@mu.ie>>: > > which turns out to be complicated. > > Without lastcycle, linseg also finishes at the last kcycle without > reaching the target, just as linsegr did (after my bug fix). > So now the situation is slightly more complex because clearly this > is the behaviour of these opcodes, and I am not quite sure what we > need to do > now. > > linseg will reach the final value and hold it there if the > instrument duration is longer than the sum of its segments (by at > least 1 kcycle), but will not reach it if the > duration is equal to it. linsegr will never reach its final value > unless we have an xtratim that is longer than its release duration > by at least 1 kcycle. > > So I would like to see what people think it’s best doing. I can > modify both opcodes to reach the destination with 1 kcycle short at > the end or I can > just modify linsegr. > > > ======================== > Prof. Victor Lazzarini > Maynooth University > Ireland > > > On 14 Dec 2022, at 21:36, Victor Lazzarini > <Victor.Lazzarini@mu.ie <mailto:Victor.Lazzarini@mu.ie>> wrote: > > > > So I got to the bottom of this. What is happening is that the > lastcycle opcode is adding one extra kcycle but only in the case of > no xtratim, > > that is where the discrepancy comes from. I can now adjust the > code accordingly. > > ======================== > > Prof. Victor Lazzarini > > Maynooth University > > Ireland > > > >> On 14 Dec 2022, at 15:12, Richard Knight <richard@1BPM.NET > <mailto:richard@1BPM.NET>> wrote: > >> > >> This is great, thank you. > >> I did wonder, as it's evidently worked like that for a long > time, if it should be a new opcode, even if it could objectively be > considered a bug.. > >> Good/interesting spot with the additional extra time, sounds > quite curious. > >> > >> > >> > >> On 2022-12-14 09:18, Victor Lazzarini wrote: > >>> There was what we could consider a bug in linsegr (if compared to > >>> linseg), in that it never settled exactly on the final value, but > >>> one right before it and so the xtratim solution was not a complete > >>> workaround. How close would depend on ksmps and on the > >>> values of the last segment (start, dur, end). > >>> I have committed a fix to make linsegr behave like linseg, which is > >>> what some would expect. It is possible that someone > >>> would have exploited the bug since it has always been there as > far as > >>> I can see (thirty years or more). > >>> There’s an associated issue I discovered, where it appears that any > >>> added extra time runs to 1 kcycle fewer than the equivalent > >>> p3 time (with no extra time added). My fix includes extending extra > >>> time by 1 kcycle if linsegr is used but this is is likely to affect > >>> other opcodes that depend on extra time. I am not sure where this > >>> discrepancy comes from, but I hope to find out. Once that is > >>> resolved, I can remove the extra kcycle added to linsegr. > >>> This fix has been applied to both csound6 branch (6.19 beta) and > >>> develop (7.0 beta) > >>> ======================== > >>> Prof. Victor Lazzarini > >>> Maynooth University > >>> Ireland > >> > >> Csound mailing list > >> Csound@listserv.heanet.ie <mailto:Csound@listserv.heanet.ie> > >> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0> > >> Send bugs reports to > >> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0> > >> Discussions of bugs and features can be posted here > > > > > > Csound mailing list > > Csound@listserv.heanet.ie <mailto:Csound@listserv.heanet.ie> > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0> > > Send bugs reports to > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0> > > Discussions of bugs and features can be posted here > > > Csound mailing list > Csound@listserv.heanet.ie <mailto:Csound@listserv.heanet.ie> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > <https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND> > Send bugs reports to > https://github.com/csound/csound/issues > <https://github.com/csound/csound/issues> > Discussions of bugs and features can be posted here > > Csound mailing list Csound@listserv.heanet.ie > <mailto:Csound@listserv.heanet.ie> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > <https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND> Send bugs reports to > https://github.com/csound/csound/issues > <https://github.com/csound/csound/issues> Discussions of bugs and > features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-20 08:10
From	Eduardo Moguillansky
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	I don't think this is really solved. Look at the following example. All instruments should end with the same time, and instr 3 and 4 should end with the same value for klin. But they differ in multiple ways. 1 and 2 do seem to agree but 3 and 4 disagree in both duration as value of linseg <CsoundSynthesizer> <CsOptions> --nosound -m0 </CsOptions> <CsInstruments> sr = 44100 ksmps = 64 nchnls = 2 0dbfs = 1 instr 1 kt eventtime println "1) kt: %f", kt endin instr 2 kt eventtime xtratim 0.5 println "2) kt: %f", kt endin instr 3 kt eventtime klin linsegr 0, p3, 1, p3, 0 println "3) kt: %f, klin: %f", kt, klin endin instr 4 kt eventtime xtratim p3 klin linseg 0, p3, 1, p3, 0 println "4) kt: %f, klin: %f", kt, klin endin </CsInstruments> <CsScore> i 1 0 1 i 2 1 0.5 i 3 2 0.5 i 4 3 0.5 f 0 100 </CsScore> </CsoundSynthesizer> On 17.12.22 10:42, Victor Lazzarini wrote: ok, so I think the fix I have already applied is sufficient. Rather than mess with the rate of the final segment, I think to extend the release by 1/kr is a lesser evil. Prof. Victor Lazzarini Maynooth University Ireland On 16 Dec 2022, at 18:17, Arthur Hunkins <000001e1d761dea2-dmarc-request@listserv.heanet.ie> wrote: I agree. Art Hunkins http://www.arthunkins.com On Fri, Dec 16, 2022 at 10:49 AM joachim heintz <jh@joachimheintz.de> wrote: yes i think to treat the -r opcodes differently (compared to linseg etc) and let them reach the target in time, that would be the best solution. On 16/12/2022 13:38, Oeyvind Brandtsegg wrote: > Hi, > If you are still asking for input on this, I have a suggestion: > > linseg, as you describe it works now will reach the end value on time. > We only see it complete the segment if the instr duration is extended > with at least one k cycle. It still makes sense to have it this way, > since all the line segments are joined this way: the end value is also > the start value of the next segment. So it also have to be this way to > ensure that the next segment starts with the correct value at the > described time. > > Then the *r (linsegr) family will always be special, since the release > segment does not have anything coming after it. So it makes sense to let > it finish the release line segment one k-cycle earlier, so that it can > reach the described final value within its life span. It is also ok to > just extend the release time with one k-cycle if you prefer that. The > only possible problem with that is if someone expect the instrument to > be inactive at that exact time (say, if you have an algorithmic > generating process with a polyphony limitation, then the voice will not > be available until the next k-cycle... and if the next event from the > generator algorithm is then skipped, the algorithm in question might not > work as the author expected because of the one-cycle extra release > time... and it would be very hard for them to find the cause of the > problem in that case). > > all best > Øyvind > > > ons. 14. des. 2022 kl. 22:54 skrev Victor Lazzarini > <Victor.Lazzarini@mu.ie <mailto:Victor.Lazzarini@mu.ie>>: > > which turns out to be complicated. > > Without lastcycle, linseg also finishes at the last kcycle without > reaching the target, just as linsegr did (after my bug fix). > So now the situation is slightly more complex because clearly this > is the behaviour of these opcodes, and I am not quite sure what we > need to do > now. > > linseg will reach the final value and hold it there if the > instrument duration is longer than the sum of its segments (by at > least 1 kcycle), but will not reach it if the > duration is equal to it. linsegr will never reach its final value > unless we have an xtratim that is longer than its release duration > by at least 1 kcycle. > > So I would like to see what people think it’s best doing. I can > modify both opcodes to reach the destination with 1 kcycle short at > the end or I can > just modify linsegr. > > > ======================== > Prof. Victor Lazzarini > Maynooth University > Ireland > > > On 14 Dec 2022, at 21:36, Victor Lazzarini > <Victor.Lazzarini@mu.ie <mailto:Victor.Lazzarini@mu.ie>> wrote: > > > > So I got to the bottom of this. What is happening is that the > lastcycle opcode is adding one extra kcycle but only in the case of > no xtratim, > > that is where the discrepancy comes from. I can now adjust the > code accordingly. > > ======================== > > Prof. Victor Lazzarini > > Maynooth University > > Ireland > > > >> On 14 Dec 2022, at 15:12, Richard Knight <richard@1BPM.NET > <mailto:richard@1BPM.NET>> wrote: > >> > >> This is great, thank you. > >> I did wonder, as it's evidently worked like that for a long > time, if it should be a new opcode, even if it could objectively be > considered a bug.. > >> Good/interesting spot with the additional extra time, sounds > quite curious. > >> > >> > >> > >> On 2022-12-14 09:18, Victor Lazzarini wrote: > >>> There was what we could consider a bug in linsegr (if compared to > >>> linseg), in that it never settled exactly on the final value, but > >>> one right before it and so the xtratim solution was not a complete > >>> workaround. How close would depend on ksmps and on the > >>> values of the last segment (start, dur, end). > >>> I have committed a fix to make linsegr behave like linseg, which is > >>> what some would expect. It is possible that someone > >>> would have exploited the bug since it has always been there as > far as > >>> I can see (thirty years or more). > >>> There’s an associated issue I discovered, where it appears that any > >>> added extra time runs to 1 kcycle fewer than the equivalent > >>> p3 time (with no extra time added). My fix includes extending extra > >>> time by 1 kcycle if linsegr is used but this is is likely to affect > >>> other opcodes that depend on extra time. I am not sure where this > >>> discrepancy comes from, but I hope to find out. Once that is > >>> resolved, I can remove the extra kcycle added to linsegr. > >>> This fix has been applied to both csound6 branch (6.19 beta) and > >>> develop (7.0 beta) > >>> ======================== > >>> Prof. Victor Lazzarini > >>> Maynooth University > >>> Ireland > >> > >> Csound mailing list > >> Csound@listserv.heanet.ie <mailto:Csound@listserv.heanet.ie> > >> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0> > >> Send bugs reports to > >> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0> > >> Discussions of bugs and features can be posted here > > > > > > Csound mailing list > > Csound@listserv.heanet.ie <mailto:Csound@listserv.heanet.ie> > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0> > > Send bugs reports to > > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0> > > Discussions of bugs and features can be posted here > > > Csound mailing list > Csound@listserv.heanet.ie <mailto:Csound@listserv.heanet.ie> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > <https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND> > Send bugs reports to > https://github.com/csound/csound/issues > <https://github.com/csound/csound/issues> > Discussions of bugs and features can be posted here > > Csound mailing list Csound@listserv.heanet.ie > <mailto:Csound@listserv.heanet.ie> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND > <https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND> Send bugs reports to > https://github.com/csound/csound/issues > <https://github.com/csound/csound/issues> Discussions of bugs and > features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2022-12-20 10:34
From	Victor Lazzarini
Subject	Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
	yes, that is a side effect of bringing the value to the target. I explained this in my messages. There are two competing solutions: 1) change the end time by adding 1 kcycle 2) change the release rate by removing 1 kcycle from the count. either way there will be a change. It is a tradeoff. I pointed it out on my email. In my opinion, extending the duration by 1 kcycle if linsegr is involved and has the longest release time of all opcodes is the best deal. That is what I have implemented. The other option is not to do anything. So I think something needs to be agreed and then it can be implemented. ======================== Prof. Victor Lazzarini Maynooth University Ireland > On 20 Dec 2022, at 08:10, Eduardo Moguillansky wrote: > > I don't think this is really solved. Look at the following example. > All instruments should end with the same time, and instr 3 and 4 > should end with the same value for klin. But they differ in multiple ways. > 1 and 2 do seem to agree but 3 and 4 disagree in both duration as value of linseg > > > > --nosound > -m0 > > > > sr = 44100 > ksmps = 64 > nchnls = 2 > 0dbfs = 1 > > instr 1 > kt eventtime > println "1) kt: %f", kt > endin > > instr 2 > kt eventtime > xtratim 0.5 > println "2) kt: %f", kt > endin > > instr 3 > kt eventtime > klin linsegr 0, p3, 1, p3, 0 > println "3) kt: %f, klin: %f", kt, klin > endin > > instr 4 > kt eventtime > xtratim p3 > klin linseg 0, p3, 1, p3, 0 > println "4) kt: %f, klin: %f", kt, klin > endin > > > > > i 1 0 1 > i 2 1 0.5 > i 3 2 0.5 > i 4 3 0.5 > > f 0 100 > > > > On 17.12.22 10:42, Victor Lazzarini wrote: >> ok, so I think the fix I have already applied is sufficient. Rather than mess with the rate of the final segment, I think to extend the release by 1/kr is a lesser evil. >> >> Prof. Victor Lazzarini >> Maynooth University >> Ireland >> >>> On 16 Dec 2022, at 18:17, Arthur Hunkins <000001e1d761dea2-dmarc-request@listserv.heanet.ie> wrote: >>> >>> >>> I agree. >>> >>> Art Hunkins >>> http://www.arthunkins.com >>> >>> >>> On Fri, Dec 16, 2022 at 10:49 AM joachim heintz wrote: >>> yes i think to treat the -r opcodes differently (compared to linseg etc) >>> and let them reach the target in time, that would be the best solution. >>> >>> >>> On 16/12/2022 13:38, Oeyvind Brandtsegg wrote: >>> > Hi, >>> > If you are still asking for input on this, I have a suggestion: >>> > >>> > linseg, as you describe it works now will reach the end value on time. >>> > We only see it complete the segment if the instr duration is extended >>> > with at least one k cycle. It still makes sense to have it this way, >>> > since all the line segments are joined this way: the end value is also >>> > the start value of the next segment. So it also have to be this way to >>> > ensure that the next segment starts with the correct value at the >>> > described time. >>> > >>> > Then the *r (linsegr) family will always be special, since the release >>> > segment does not have anything coming after it. So it makes sense to let >>> > it finish the release line segment one k-cycle earlier, so that it can >>> > reach the described final value within its life span. It is also ok to >>> > just extend the release time with one k-cycle if you prefer that. The >>> > only possible problem with that is if someone expect the instrument to >>> > be inactive at that exact time (say, if you have an algorithmic >>> > generating process with a polyphony limitation, then the voice will not >>> > be available until the next k-cycle... and if the next event from the >>> > generator algorithm is then skipped, the algorithm in question might not >>> > work as the author expected because of the one-cycle extra release >>> > time... and it would be very hard for them to find the cause of the >>> > problem in that case). >>> > >>> > all best >>> > Øyvind >>> > >>> > >>> > ons. 14. des. 2022 kl. 22:54 skrev Victor Lazzarini >>> > >: >>> > >>> > which turns out to be complicated. >>> > >>> > Without lastcycle, linseg also finishes at the last kcycle without >>> > reaching the target, just as linsegr did (after my bug fix). >>> > So now the situation is slightly more complex because clearly this >>> > is the behaviour of these opcodes, and I am not quite sure what we >>> > need to do >>> > now. >>> > >>> > linseg will reach the final value and hold it there if the >>> > instrument duration is longer than the sum of its segments (by at >>> > least 1 kcycle), but will not reach it if the >>> > duration is equal to it. linsegr will never reach its final value >>> > unless we have an xtratim that is longer than its release duration >>> > by at least 1 kcycle. >>> > >>> > So I would like to see what people think it’s best doing. I can >>> > modify both opcodes to reach the destination with 1 kcycle short at >>> > the end or I can >>> > just modify linsegr. >>> > >>> > >>> > ======================== >>> > Prof. Victor Lazzarini >>> > Maynooth University >>> > Ireland >>> > >>> > > On 14 Dec 2022, at 21:36, Victor Lazzarini >>> > > wrote: >>> > > >>> > > So I got to the bottom of this. What is happening is that the >>> > lastcycle opcode is adding one extra kcycle but only in the case of >>> > no xtratim, >>> > > that is where the discrepancy comes from. I can now adjust the >>> > code accordingly. >>> > > ======================== >>> > > Prof. Victor Lazzarini >>> > > Maynooth University >>> > > Ireland >>> > > >>> > >> On 14 Dec 2022, at 15:12, Richard Knight >> > > wrote: >>> > >> >>> > >> This is great, thank you. >>> > >> I did wonder, as it's evidently worked like that for a long >>> > time, if it should be a new opcode, even if it could objectively be >>> > considered a bug.. >>> > >> Good/interesting spot with the additional extra time, sounds >>> > quite curious. >>> > >> >>> > >> >>> > >> >>> > >> On 2022-12-14 09:18, Victor Lazzarini wrote: >>> > >>> There was what we could consider a bug in linsegr (if compared to >>> > >>> linseg), in that it never settled exactly on the final value, but >>> > >>> one right before it and so the xtratim solution was not a complete >>> > >>> workaround. How close would depend on ksmps and on the >>> > >>> values of the last segment (start, dur, end). >>> > >>> I have committed a fix to make linsegr behave like linseg, which is >>> > >>> what some would expect. It is possible that someone >>> > >>> would have exploited the bug since it has always been there as >>> > far as >>> > >>> I can see (thirty years or more). >>> > >>> There’s an associated issue I discovered, where it appears that any >>> > >>> added extra time runs to 1 kcycle fewer than the equivalent >>> > >>> p3 time (with no extra time added). My fix includes extending extra >>> > >>> time by 1 kcycle if linsegr is used but this is is likely to affect >>> > >>> other opcodes that depend on extra time. I am not sure where this >>> > >>> discrepancy comes from, but I hope to find out. Once that is >>> > >>> resolved, I can remove the extra kcycle added to linsegr. >>> > >>> This fix has been applied to both csound6 branch (6.19 beta) and >>> > >>> develop (7.0 beta) >>> > >>> ======================== >>> > >>> Prof. Victor Lazzarini >>> > >>> Maynooth University >>> > >>> Ireland >>> > >> >>> > >> Csound mailing list >>> > >> Csound@listserv.heanet.ie >>> > >> >>> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0 >>> > >> Send bugs reports to >>> > >> >>> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0 >>> > >> Discussions of bugs and features can be posted here >>> > > >>> > > >>> > > Csound mailing list >>> > > Csound@listserv.heanet.ie >>> > > >>> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&reserved=0 >>> > > Send bugs reports to >>> > > >>> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&reserved=0 >>> > > Discussions of bugs and features can be posted here >>> > >>> > >>> > Csound mailing list >>> > Csound@listserv.heanet.ie >>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND >>> > >>> > Send bugs reports to >>> > https://github.com/csound/csound/issues >>> > >>> > Discussions of bugs and features can be posted here >>> > >>> > Csound mailing list Csound@listserv.heanet.ie >>> > >>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND >>> > Send bugs reports to >>> > https://github.com/csound/csound/issues >>> > Discussions of bugs and >>> > features can be posted here >>> >>> Csound mailing list >>> Csound@listserv.heanet.ie >>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND >>> Send bugs reports to >>> https://github.com/csound/csound/issues >>> Discussions of bugs and features can be posted here >>> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here >> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here > Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here