Csound Csound-dev Csound-tekno Search About

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

Date2022-12-09 21:12
FromPhilipp 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 = aIn*gkMicGate


aMic = aMicGated*kInVol
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 = aIn*gkMicGate
;;; 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 = aDelOffset*1
aDelOffsetR = aDelOffset*1.1
; Feedback-Ratio
initc7 1, 2, 0
kFdb ctrl7 1, 2, 0., 1.
; Delay-Buffer
aDumpC 	delayr giDelBufSize1
aDel1C 	deltap3 aDelTime1
		delayw aMic+(aDel1C*kFdb)

aDumpL 	delayr giDelBufSize1
aDel1L 	deltap3 aDelTime1*aDelOffsetL
		delayw aMic+(aDel1C*kFdb)

aDumpR 	delayr giDelBufSize1
aDel1R 	deltap3 aDelTime1*aDelOffsetR
		delayw aMic+(aDel1C*kFdb)


;aDelL sum aDel1C*kInVol, aDel1L*kInVol
;aDelR sum aDel1C*kInVol, aDel1R*kInVol

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

Date2022-12-10 23:53
FromRichard Knight
SubjectRe: [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 = aIn*gkMicGate
> 
> 
> aMic = aMicGated*kInVol
> 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 = aIn*gkMicGate
> ;;; 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 = aDelOffset*1
> aDelOffsetR = aDelOffset*1.1
> ; Feedback-Ratio
> initc7 1, 2, 0
> kFdb ctrl7 1, 2, 0., 1.
> ; Delay-Buffer
> aDumpC 	delayr giDelBufSize1
> aDel1C 	deltap3 aDelTime1
> 		delayw aMic+(aDel1C*kFdb)
> 
> aDumpL 	delayr giDelBufSize1
> aDel1L 	deltap3 aDelTime1*aDelOffsetL
> 		delayw aMic+(aDel1C*kFdb)
> 
> aDumpR 	delayr giDelBufSize1
> aDel1R 	deltap3 aDelTime1*aDelOffsetR
> 		delayw aMic+(aDel1C*kFdb)
> 
> 
> ;aDelL sum aDel1C*kInVol, aDel1L*kInVol
> ;aDelR sum aDel1C*kInVol, aDel1R*kInVol
> 
> 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

Date2022-12-11 10:02
Fromjoachim heintz
SubjectRe: [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 = aIn*gkMicGate
>>
>>
>> aMic = aMicGated*kInVol
>> 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 = aIn*gkMicGate
>> ;;; 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 = aDelOffset*1
>> aDelOffsetR = aDelOffset*1.1
>> ; Feedback-Ratio
>> initc7 1, 2, 0
>> kFdb ctrl7 1, 2, 0., 1.
>> ; Delay-Buffer
>> aDumpC     delayr giDelBufSize1
>> aDel1C     deltap3 aDelTime1
>>         delayw aMic+(aDel1C*kFdb)
>>
>> aDumpL     delayr giDelBufSize1
>> aDel1L     deltap3 aDelTime1*aDelOffsetL
>>         delayw aMic+(aDel1C*kFdb)
>>
>> aDumpR     delayr giDelBufSize1
>> aDel1R     deltap3 aDelTime1*aDelOffsetR
>>         delayw aMic+(aDel1C*kFdb)
>>
>>
>> ;aDelL sum aDel1C*kInVol, aDel1L*kInVol
>> ;aDelR sum aDel1C*kInVol, aDel1R*kInVol
>>
>> 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

Date2022-12-11 15:16
FromRichard Knight
SubjectRe: [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 = aIn*gkMicGate
>>> 
>>> 
>>> aMic = aMicGated*kInVol
>>> 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 = aIn*gkMicGate
>>> ;;; 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 = aDelOffset*1
>>> aDelOffsetR = aDelOffset*1.1
>>> ; Feedback-Ratio
>>> initc7 1, 2, 0
>>> kFdb ctrl7 1, 2, 0., 1.
>>> ; Delay-Buffer
>>> aDumpC     delayr giDelBufSize1
>>> aDel1C     deltap3 aDelTime1
>>>         delayw aMic+(aDel1C*kFdb)
>>> 
>>> aDumpL     delayr giDelBufSize1
>>> aDel1L     deltap3 aDelTime1*aDelOffsetL
>>>         delayw aMic+(aDel1C*kFdb)
>>> 
>>> aDumpR     delayr giDelBufSize1
>>> aDel1R     deltap3 aDelTime1*aDelOffsetR
>>>         delayw aMic+(aDel1C*kFdb)
>>> 
>>> 
>>> ;aDelL sum aDel1C*kInVol, aDel1L*kInVol
>>> ;aDelR sum aDel1C*kInVol, aDel1R*kInVol
>>> 
>>> 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

Date2022-12-11 16:59
Fromjoachim heintz
SubjectRe: [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 = aIn*gkMicGate
>>>>
>>>>
>>>> aMic = aMicGated*kInVol
>>>> 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 = aIn*gkMicGate
>>>> ;;; 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 = aDelOffset*1
>>>> aDelOffsetR = aDelOffset*1.1
>>>> ; Feedback-Ratio
>>>> initc7 1, 2, 0
>>>> kFdb ctrl7 1, 2, 0., 1.
>>>> ; Delay-Buffer
>>>> aDumpC     delayr giDelBufSize1
>>>> aDel1C     deltap3 aDelTime1
>>>>         delayw aMic+(aDel1C*kFdb)
>>>>
>>>> aDumpL     delayr giDelBufSize1
>>>> aDel1L     deltap3 aDelTime1*aDelOffsetL
>>>>         delayw aMic+(aDel1C*kFdb)
>>>>
>>>> aDumpR     delayr giDelBufSize1
>>>> aDel1R     deltap3 aDelTime1*aDelOffsetR
>>>>         delayw aMic+(aDel1C*kFdb)
>>>>
>>>>
>>>> ;aDelL sum aDel1C*kInVol, aDel1L*kInVol
>>>> ;aDelR sum aDel1C*kInVol, aDel1R*kInVol
>>>>
>>>> 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

Date2022-12-11 18:12
FromRichard Knight
SubjectRe: [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

Date2022-12-11 18:17
FromRichard Knight
SubjectRe: [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

Date2022-12-11 18:40
Fromjoachim heintz
SubjectRe: [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

Date2022-12-12 23:54
FromRichard Knight
SubjectRe: [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

Date2022-12-13 05:19
FromPhilipp Neumann
SubjectRe: [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

Date2022-12-14 09:18
FromVictor Lazzarini
SubjectRe: [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

Date2022-12-14 15:12
FromRichard Knight
SubjectRe: [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

Date2022-12-14 15:27
Fromjoachim heintz
SubjectRe: [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

Date2022-12-14 15:54
FromMichael Gogins
SubjectRe: [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

Date2022-12-14 18:25
FromVictor Lazzarini
SubjectRe: [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

Date2022-12-14 21:36
FromVictor Lazzarini
SubjectRe: [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

Date2022-12-14 21:53
FromVictor Lazzarini
SubjectRe: [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

Date2022-12-14 22:01
FromVictor Lazzarini
SubjectRe: [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

Date2022-12-15 09:43
Fromjoachim heintz
SubjectRe: [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

Date2022-12-15 10:14
FromVictor Lazzarini
SubjectRe: [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

Date2022-12-15 11:26
Fromjoachim heintz
SubjectRe: [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

Date2022-12-15 12:24
FromVictor Lazzarini
SubjectRe: [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

Date2022-12-15 16:03
Fromjoachim heintz
SubjectRe: [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

Date2022-12-15 17:09
From"Dr. Richard Boulanger"
SubjectRe: [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

Date2022-12-16 02:24
FromRichard Knight
SubjectRe: [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

Date2022-12-16 12:38
FromOeyvind Brandtsegg
SubjectRe: [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&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&amp;reserved=0
>> Send bugs reports to
>>      https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&amp;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&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&amp;reserved=0
> Send bugs reports to
>        https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&amp;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

Date2022-12-16 15:49
Fromjoachim heintz
SubjectRe: [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

Date2022-12-16 18:15
FromArthur Hunkins <000001e1d761dea2-dmarc-request@LISTSERV.HEANET.IE>
SubjectRe: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
I agree.

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&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&amp;reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&amp;reserved=0>
>      >> Send bugs reports to
>      >>
>     https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&amp;reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&amp;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&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&amp;reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&amp;reserved=0>
>      > Send bugs reports to
>      >
>     https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&amp;reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&amp;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

Date2022-12-17 09:42
FromVictor Lazzarini
SubjectRe: [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.

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&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&amp;reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&amp;reserved=0>
>      >> Send bugs reports to
>      >>
>     https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&amp;reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&amp;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&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&amp;reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&amp;reserved=0>
>      > Send bugs reports to
>      >
>     https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&amp;reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&amp;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

Date2022-12-20 08:10
FromEduardo Moguillansky
SubjectRe: [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.

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&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&amp;reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&amp;reserved=0>
>      >> Send bugs reports to
>      >>
>     https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&amp;reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&amp;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&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&amp;reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.heanet.ie%2Fcgi-bin%2Fwa%3FA0%3DCSOUND&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=z4WNZ2px74hVg0IsTmkLNFLCzWt%2Ff7HbfRIQYK6z8is%3D&amp;reserved=0>
>      > Send bugs reports to
>      >
>     https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&amp;reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcsound%2Fcsound%2Fissues&amp;data=05%7C01%7CVictor.Lazzarini%40mu.ie%7Cefab632ea84a4828b2cf08dade1b4d1a%7C1454f5ccbb354685bbd98621fd8055c9%7C0%7C0%7C638066506089000914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=cc7wXA1liKRj1AV0SooqkX%2B3%2BLowgewsPaM9pTLp8Fo%3D&amp;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

Date2022-12-20 10:34
FromVictor Lazzarini
SubjectRe: [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