fixes non-initialisation for NRT version of AmpGate.

[tremblap]

This seems to fix the filter having memories between calls. @weefuzzy I just have 2 very quick questions for you:

• is the NRT adaptor running init on all those automagically converted? I don't know where to look so any pointers welcome.
• is the way I do it in this PR for that object which has its own magic adaptor the right way?

Thanks for your help

[tremblap]

https://discourse.flucoma.org/t/problems-batch-slicing-with-fluid-bufampgate/2192/6

Pd patch available should that be preferred.

[weefuzzy]

• is the NRT adaptor running init on all those automagically converted? I don't know where to look so any pointers welcome.

If init == reset then, yes. The adaptor for AmpGate isn't any more magic than the others, it just needs its own because it's a weirdo. The trouble being that, as here, gremlins are prone to creep in because duplication.

The equivalent code for the other slicers is here in FluidClientNRTWrapper.hpp (which is a prime candidate for breaking up into more digestible pieces, because huge):

flucoma-core/include/clients/common/FluidNRTClientWrapper.hpp

Lines 697 to 702 in 0ad031e

	std::vector<HostVectorView> input{{nullptr, 0, 0}};
	std::vector<HostVectorView> output{{nullptr, 0, 0}};
	client.reset(c);
	for (index i = 0, N = nHops; i < N; ++i)
	{
	input[0] = monoSource.row(0)(Slice(i * VectorSize, VectorSize));

• is the way I do it in this PR for that object which has its own magic adaptor the right way?

Just adding a reset call? Seems reasonable – that's what everything else does; the variation is whether is has to be done repeatedly (for the multichannel case) or not.

[tremblap]

thanks so much for the quick reply - I'll study that wrapper which will become handy with the biz adaptor needed for voiceallocator!