[Stk] BlitSquare bug?

Steven Yi stevenyi at gmail.com
Thu Mar 12 19:33:51 PDT 2015


Hi Gary,

AH... I understand what's going on now.  I think I was too caught up
in the big picture to see the parts; yes, not a bug but an
optimization, and thanks for clearing that up for me!

steven



On Thu, Mar 12, 2015 at 8:33 PM, Gary Scavone <gary at ccrma.stanford.edu> wrote:
> 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
>>>
>



More information about the Stk mailing list