SNEX weirdness or me ?

[Christoph Hart]

So I could dumb it down to a minimal test case which is indeed failing:

struct Outer
{
	struct Inner
	{
		int processInner() const
		{
			// this should not compile,
			// the variable resolver must detect that we're
			// in the inner class and not the Outer
			return a0;
		}
		
		int value = 0;
	};
	
	Inner data1;
	
	int a0 = 12;

	int processOuter()
	{
		return data1.processInner();
	}
};

Outer outer;

int main(int input)
{
	return outer.processOuter();
}

So the parser does not detect that it's an illegal operation and just creates a pointer with a 4 byte offset (as it would for the valid member access). This then works with the first instance because the memory address of data1 is the same as the Outer object itself, but it will not work with other memory addresses (this is why your filter failed at the second channel).

Now the fix shouldn't be too difficult but it's been quite some time that I crawled around in the internals of the SNEX compiler...

[ustk]

@Christoph-Hart said in SNEX weirdness or me ?:

• Your TwoOverT is in fact TwoTimesT. This blows up the filter immediately :)

Nope, T = 1/fs, TwoOverT = 2 / (1 / fs) => simplifies in 2*fs

• You're still using an outer class variable in processFilter (in this case a0).

I am trying to keep common/shared things together and separate what it needs to be. Now I could place a0 as class member but would it be better or not, this I don't know. :smiling_face_with_halo:

I was thinking about a shared memory issue or something related, but as for the technicality of it

In the case of such simple DSP like filter, harmonics, etc... Would using struct over class change anything in the context of SNEX?

[Christoph Hart]

Nope, T = 1/fs, TwoOverT = 2 / (1 / fs) => simplifies in 2*fs

One formula (yours) is blowing the filter into NaNs immediately and one formula (mine) makes the filter work ok(ish) - it still blows up if the cutoff frequency goes near Nyquist.

I am trying to keep common/shared things together and separate what it needs to be.

Yes that's a good approach, all you need to do to make it work is to add another argument to the processFilter() function where you pass in a0 from the outer class. It's just not legal C++ to access the outer member from the inner class.

[ustk]

@Christoph-Hart said in SNEX weirdness or me ?:

One formula (yours) is blowing the filter into NaNs immediately and one formula (mine) makes the filter work ok(ish) - it still blows up if the cutoff frequency goes near Nyquist.

Yeah I got that blowing which is part of this algorithm (Pirkle/Zavalishin) so it is mandatory to OS at a minimum of x2, and only then I could stabilise it

It's just not legal C++ to access the outer member from the inner class.

Oh thanks! That is quite an important hint!

[Christoph Hart]

@ustk should be fixed - the compiler will scream at you now…

[ustk]

@Christoph-Hart So in the end I was doing something silly that didn't need a fix if I had followed the conventional approach of C++

[Christoph Hart]

@ustk yes, but it's the job of the compiler to tell you that you're doing something stupid and the actual effect it had on your class was totally unpredictable, so it's definitely better now than before :)

[ustk]

@Christoph-Hart Hmmm... So now it complains on the index type in the process template

private:
	using IndexType = index::clamped<MAX_NUM_CHANNELS, false>;
	IndexType idx;

But it is impossible to stick it as member parameter or declare it as constant, am I right?
So what would be the procedure then?
Sorry for the C++ crash course I still need...

[ustk]

@Christoph-Hart both process and idx are in the same template so this shouldn't be an issue if I am not mistaken

[ustk]

@ustk Boing boing

[ustk]

@Christoph-Hart Even doing this throws the error:

It seems index is considered to be outside

[Christoph Hart]

@ustk ah yeah actually I caught a similar error with the index classes in my test suite when I implemented the fix but it seems that the test suite didn‘t cover index usage within a class.

Back to the SNEX compiler internals I guess…

[Christoph Hart]

Alright, please try again, now it should not mess with the index templates anymore.

[ustk]

@Christoph-Hart Thanks! Building now...

[ustk]

@Christoph-Hart Working smoothly! Thanks a lot for the fix!