[Stk] BlitSquare bug?

[Steven Yi]

Hi Gary,

There was one other thing I noticed.  At least in my own code, what I
found was that using a starting value of 0.0, the integration of the
bipolar blit started with a dc offset of 0.5.  The dc blocking would
bring that back down exponentially but it took about 2000 samples to
settle in (44.1k sr).  That made sense to me as integrating a +1 and
-1 impulse would just go from 1 to 0 and repeat over time.  I ended up
using -0.5 as an initial value to the integration and that pretty much
had the square stable from around +/-0.5 from the start.

I think a similar change would be for src/BlitSquare.cpp to have this
in reset():

  lastBlitOutput_ = -0.5;

Does that sound correct to you?

Thanks!
steven


On Thu, Mar 12, 2015 at 10:33 PM, Steven Yi <stevenyi at gmail.com> wrote:
> 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
>>>>
>>