[Stk] BlitSquare bug?

[Gary Scavone]

Hi Steven,

I see what you are talking about but I do not consider it as a bug.  Rather, it is something that could be made more efficient. The line 

  lastBlitOutput_ += temp;

is the integration (not leaky) and the line

   lastFrame_[0] = lastBlitOutput_ - dcbState_ + 0.999 * lastFrame_[0];

is the one pole / one zero DC blocker (if “dcbState_ was not included, it would be a leaky integrator, but the zero makes it a DC blocker … with the zero and pole almost cancelling each other out).  It is true that “temp" and “dcbState_" end up being equivalent, so that the addition with “temp" and the subtraction with “dcbState_" could be skipped as:

   //lastBlitOutput_ += temp;
   lastFrame_[0] = lastBlitOutput_ + 0.999 * lastFrame_[0];

However, I wouldn’t want to make that simplification without a lot of explanatory text so that the integration and subsequent DC blocking are relatively clear to a reader.  In fact, I think there should be a bit more explanatory commenting in the code as written.

Does that clarify things?

—gary

> On Mar 12, 2015, at 4:48 PM, Steven Yi <stevenyi at gmail.com> wrote:
> 
> Hi Gary,
> 
> I've gone through again my analysis again and I still see a problem.
> Let me see if I can explain what I'm seeing better.
> 
> In BlitSquare.h, I see the integration really happening in this line:
> 
>  lastFrame_[0] = lastBlitOutput_ - dcbState_ + 0.999 * lastFrame_[0];
> 
> where the newly calculated value for lastBlitOutput_ and the leaky add
> of 0.999 * lastFrame_[0] occur.
> 
> This line:
> 
> lastBlitOutput_ += temp;
> 
> adds temp, but the following line:
> 
>  lastFrame_[0] = lastBlitOutput_ - dcbState_ + 0.999 * lastFrame_[0];
> 
> stubtracts dcbState_.  But the way the code is, by the time temp is
> added and dcbState_ is subtracted, temp and dcbState_ are always equal
> to each other. If we put the two above lines together, you get:
> 
> lastFrame_[0] = lasBlitOutput_ + temp - dcbState_ + 0.999 * lastFrame_[0];
> 
> but since temp == dcbState, the above is equivalent to:
> 
> lastFrame_[0] = lastBlitOutput_ + 0.999 * lastFrame_[0];
> 
> You can see it if you walk through the code and notice:
> 
>  StkFloat temp = lastBlitOutput_;
>  dcbState_ = lastBlitOutput_;
> 
> The only time when those two values would not be equal to each other
> is on the initial pass, if lastBlitOutput_ was initialized to a
> different value than dcbState_.  However, BlitSquare::reset() sets
> both to 0.
> 
> Hopefully that's a little clearer.  If not, I can write up some code
> to show the issue that way.
> 
> Thanks,
> steven
> 
> On Thu, Mar 12, 2015 at 1:56 PM, Gary Scavone <gary at ccrma.stanford.edu> wrote:
>> Hi Steven,
>> 
>> The bandlimited square wave is formed by integrating a bipolar blit.  So, the line:
>> 
>>  lastBlitOutput_ += temp;
>> 
>> accomplishes the integration.  The subsequent filtering operation is a one-pole DC blocker and the line:
>> 
>>  dcbState_ = lastBlitOutput_;
>> 
>> simply saves the current input state for the subsequent iteration. The DC blocker is required to avoid a DC offset that can accumulate over time from the integration.
>> 
>> I don’t see a bug in the code.
>> 
>> Regards,
>> 
>> —gary
>> 
>> On Mar 3, 2015, at 10:11 AM, Steven Yi <stevenyi at gmail.com> wrote:
>> 
>>> Hi All,
>>> 
>>> I was translating the STK code for BlitSquare to another language and
>>> I have a question about the code.  As far as I can tell, the code in
>>> BlitSquare.h for the tick method looks to have a bug.  I noticed this:
>>> 
>>> StkFloat temp = lastBlitOutput_;
>>> ...
>>> lastBlitOutput_ += temp;
>>> 
>>> // Now apply DC blocker.
>>> lastFrame_[0] = lastBlitOutput_ - dcbState_ + 0.999 * lastFrame_[0];
>>> dcbState_ = lastBlitOutput_;
>>> 
>>> The value of dcbState_ and temp are both set to the lastBlitOutput_.
>>> The calculation adds temp, but then subtracts dbcState_, which
>>> effectively makes the line calculating last_frame_[0] :
>>> 
>>> lastFrame_[0] = lastBlitOutput_ + 0.999 * lastFrame_[0];
>>> 
>>> if one takes out the "lastBlitOutput_ += temp" line.
>>> 
>>> In my translated code, I've plotted both the direct translation as
>>> well as a version removing the use of temp and dcbState_ and I got the
>>> same results.
>>> 
>>> Could someone confirm my analysis about this code?
>>> 
>>> Thanks!
>>> steven
>>> 
>>> _______________________________________________
>>> Stk mailing list
>>> Stk at ccrma.stanford.edu
>>> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
>>