Csound Csound-dev Csound-tekno Search About

Re: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero

Date2022-12-16 15:50
FromScott Daughtrey
SubjectRe: [Csnd] [EXTERNAL] [Csnd] 'linsegr' is not going back to zero
I'm not sure I understand why this is a problem.

I've linked four files. The first, using ksmps value of 2, shows the linsegr values. The envelope "appears" to close at 0.00036, only 36 ten thousandths from 0 (which even if not 0 would essentially be inaudible but please read on). However,  if you look at the final 5 or six values they are literally identical to the values of the next note as it climbs above zero. I don't think this in coincidental.  

The next image,  using printk instead of print k2, clearly shows that the print function ceases before the note hits 2.1 seconds (a 2 second note with .1 release). That seems to simply indicate that once the final control cycle command is reached - go to 0 next - that the print function no longer needs to operate. The printk output, which allows seeing the final reported print time, stops before showing the actual value at 2.1 seconds so it is not actually reporting what occurs as a final value. And yet waveform displays accurately display the audio reaching 0 at exactly 2.1 seconds, to the sample.

The next two images show rendered audio using both a linsegr envelope and a line envelope - the duration of the note with the line envelope is set for 2.1 seconds to compensate for the extra release time of linsegr.

Both images are sample accurate, the visible squares show an exact sample time and value, each square is a sample. They are virtually identical. When a square is selected both examples show an absolute value of 0. In both situations the envelope is unquestionably closed. And both show that the value at exactly 2.1 seconds is zero, not close to 2.1, but literally *exactly* at 2.1 seconds,  with the precision of a single sample. 

Is it not possible that altering the code will in fact cause the envelopes to no longer be sample accurate and instead be off by the amount of the ksmps rate? 

If anything, would it not be possibly worth altering the printk2 and other print functions to instead go on for one extra cycle just to see if that resolves what appears to be a non-issue?

I'm no expect but the rendered audio seems to present a strong arguement. 

https://drive.google.com/file/d/1H9VePx6Nf8vK1ZAS_WPmzt9-aAk44h1i/view?usp=drivesdk

https://drive.google.com/file/d/1HBpMTBbPFsqiYrIzAYRkm_si55vzycEo/view?usp=drivesdk

https://drive.google.com/file/d/1HCiQiTIdYSwUWGrd99xSlMdbet83sqpQ/view?usp=drivesdk

https://drive.google.com/file/d/1HCiQiTIdYSwUWGrd99xSlMdbet83sqpQ/view?usp=drivesdk

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