Re: [sc-users] Problem in Demand/Dwhite?

[walters@xxxxxxxxxxxxxxxxxx]

Thanks for the very clear explanation!

Following up, though, I think that in this example the initial value issue is in Demand, not Impulse. That's what .reciprocal is called on, and looking at Demand_ctor I see this:

	std::fill_n(unit->m_prevout, unit->mNumOutputs, 0.f);

This may be an example of why this problem can't be fixed in the general case, because unless I'm missing something, Demand has no way of knowing at construction time what its first output value will be. Zero is the obvious placeholder in that situation.

> On Dec 5, 2019, at 4:57 PM, jamshark70@xxxxxxxxx wrote:
> 
> On Fri, Dec 6, 2019 at 7:01 AM <walters@xxxxxxxxxxxxxxxxxx> wrote:
>> The Demand/Dwhite combo seems to output 0 throughout the first buffer even if triggered at audio rate on the first sample with 0 out of range.
> 
> Not exactly. The first output sample is the demand-ed value (there are
> no zeros in the output stream).
> 
> b = Buffer.alloc(s, 512, 1);
> 
> a = { RecordBuf.ar(Demand.ar(Impulse.ar(1), 0, Dwhite(4, 8, inf)), b,
> loop: 0, doneAction: 2); Silent.ar(1) }.play;
> 
> b.getn(0, b.numFrames, { |data| d = data });
> d.plot;
> 
> d.first == 0
> -> false
> 
> d.first == d.last
> -> true
> 
> The real problem is kind of a classic one, which I've investigated at
> length in the past (and complained about at length), but we probably
> aren't going to fix it.
> 
> https://github.com/supercollider/supercollider/issues/2343
> 
> Impulse, with initial phase 0, produces 1 as its first "real" output
> sample. But every UGen's constructor (Ctor in resources) needs to
> produce a pre-sample for initialization. Normally we assume that this
> will be the same as the first "real" output: y(-1) = y(0). But for
> some UGens, including Impulse (which is a really big problem), y(-1)
> != y(0) -- for Impulse, the pre-sample is 0.
> 
> So then 'reciprocal' produces a pre-sample = inf, and the RLPF Ctor
> pre-initializes its coefficients based on rq = inf, and after the
> first block, those faulty coefficients get replaced by proper ones.
> 
> I have argued that we should make it an absolute, inviolable rule that
> every UGen's Ctor's initial output sample should be its real output.
> This would complicate some UGens' code, but it would make this class
> of initialization problem disappear forever (instead of cropping up a
> couple times a year, in new contexts).
> 
> Unfortunately https://github.com/supercollider/supercollider/issues/2343#issuecomment-296443946
> is the current status.
> 
>> Fixing this issue will take a lot of work and a lot of API changes. Furthermore, there are still plenty of absent and inconsistent initialization issues in sc3-plugins and other third-party plugins.
>> 
>> We can introduce a workaround UGen that allows manipulation of the initialization sample only. Just a UGen like "PreTrig" that outputs an initial sample of 1 and then outputs silence would work. For example, you could set the initial sample to an arbitrary value with (1 - PreTrig.ar) * sig + (PreTrig.ar * initValue).
> 
> I don't like this, but that's where we are.
> 
> Probably the easiest workaround would be "Demand.ar(...).clip(4, 8)".
> 
> hjh
> 
> _______________________________________________
> sc-users mailing list
> 
> info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> archive: https://listarc.bham.ac.uk/marchives/sc-users/
> search: https://listarc.bham.ac.uk/lists/sc-users/search/


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/