The STKSitar opcode can create a buildup of clipped samples as illustrated by the attached csd file

[umlaeute]

as i don't have time right now to look into this myself, so I'm forwarding an oldish (6 years!) bug-report from Debian (here's the original bugreport), that appears to still be present in Csound-6.16

(i also reported this as https://github.com/csound/csound/issues/1526 but was directed here)

The following CSD produces unexpected output: this may be a problem with Csound, or STK, or both -- I'm filing this as a Csound bug because that's the application I'm using when I experience the problem.

The CSD has two descending tone sequences played with the STKSitar opcode. The duration of each note is 0.4 seconds and they are played 0.1 seconds apart, so there should be no more than 4 notes playing simultaneously. Towards the end of the first descending sequence, the volume shoots up dramatically, creating a great deal of distortion.

There is a pause of 1.0 seconds before the second descending sequence, which should be adequate for all notes from the first sequence to complete. Yet when the second sequence plays, the distortion occurs almost immediately, on notes which played without issue during the first tone sequence.

It appears that some sort of buffer is building up and not being flushed adequately, but that's just speculation.

find the CSD in STKSitar_overflow.zip

[jpffitch]

Certainly odd. Replacing all frequencies to 440Hz and it is OK.

So it s inside the Sitar class in C++

[jpffitch]

The more I look the stranger it is.

If I comment out evertthng after the first score blank line it is OK. If I comment out the low note at time 3.7 then it gives an error much earlier! That rather suggests memory but valgrind reports nothing odd. Still no ideas where to look.

Need Michael Gogins I think

[gogins]

I suspect this is an STK bug, but I will look at it.

[gogins]

The following one-line patch to the STK sources causes this behavior to stop, and rendering to look and sound normal.

mkg@xenakis:~/stk$ git diff
diff --git a/src/Sitar.cpp b/src/Sitar.cpp
index 2d3364e..11c493e 100644
--- a/src/Sitar.cpp
+++ b/src/Sitar.cpp
@@ -61,7 +61,7 @@ void Sitar :: setFrequency( StkFloat frequency )
 #endif

   targetDelay_ = (Stk::sampleRate() / frequency);
-  delay_ = targetDelay_ * (1.0 + (0.05 * noise_.tick()));
+  delay_ = targetDelay_;
   delayLine_.setDelay( delay_ );
   loopGain_ = 0.995 + (frequency * 0.0000005);
   if ( loopGain_ > 0.9995 ) loopGain_ = 0.9995;
mkg@xenakis:~/stk$ 

This is enough to prove that the bug lies within the deleted line, or its side effects, and is entirely contained in the STK Sitar class.

I do not understand what is happening well enough to really fix it, but I will open an issue in the STK repository that references this issue.