Skip to content

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

Closed

Description

@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 csound/csound#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

Activity

  1. jpffitch commented on Sep 20, 2021

    @jpffitch
    Contributor

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

    So it s inside the Sitar class in C++

  2. jpffitch commented on Sep 22, 2021

    @jpffitch
    Contributor

    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

  3. gogins commented on Oct 3, 2021

    @gogins
    Contributor

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

  4. gogins commented on Oct 4, 2021

    @gogins
    Contributor

    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.

  5. vlazzarini commented on Oct 11, 2026

    @vlazzarini
    Member

    ok so this is not an issue for this repository, closing it.

  6. vlazzarini commented on Oct 13, 2026

    @vlazzarini
    Member

    @umlaeute actually we're offering a local patch now as per #48

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions