AmpFeature2Client: return fast and slow curves instead of their difference

[elgiano]

To better understand how the AmpSlicer works, I find it useful to look at both fast and slow curves instead of only looking at their difference. So I'm making this extra client to get those into a buffer.

• Single output buffer: numChannels = inputChannels * 2 ([fast, slow] for each input channel)
• Envelope.hpp: I added a processSampleSeparate method that returns a tuple<double, double>. Original processing code is not repeated, but encapsulated in a private processSampleCommon method.

I'm opening this PR mainly for review of how I wrote the C++, looking forward for style/refactor change requests!
Code is tested (on mono and multi-channel buffers), but not documented yet.

thanks @weefuzzy for the info about custom NRT adaptors!

P.S. I also have the "trivial" SC code for flucoma-sc here. I don't do Max or PD but it should be as trivial :)

[elgiano]

Afterthought: maybe it would be better, instead of making a new client, to equip AmpFeature with a select mechanism?
I made it here:
dev...elgiano:flucoma-core:feature/ampfeature-select

[jamesb93]

This is a cool idea! I can't comment on the c++ side of things, but in practice I think that having the object output both curves and the delta would be the easiest way. That way you don't have to do a fancy buffer operation in order to grab the delta and then you could @select the output you want (names unsure). That's just my 2c.

[elgiano]

@jamesb93 I totally agree, and the work is already done on that other branch. The thing is that AmpFeature2 doesn't break the current AmpFeature, while the other branch would. It's possible to set \diff as the only default output for retrocompatibility though. I'm waiting for more comments, but I would actually be happier to close this PR in favor of a new one from dev...elgiano:flucoma-core:feature/ampfeature-select

[weefuzzy]

Thanks for your patience @elgiano. I think I'm more of a fan of the ampfeature-select branch, but I'll look at both more closely (I seem to vary between preferring more objects vs preferring more attributes / options!).

A next big chunk of work for me is to try and improve the usability of the API for making clients, so this is a really valuable exercise from my perspective!

[elgiano]

Great, I understand the fluctuating preference and opportunity for API improvement. I have to say it wasn't too hard to copy other objects for making a new client. Of course there were parts that didn't "self-document" very well immediately (the NRT adapter), but with your advice it was quite straightforward to make sense of it all. so thanks a lot, and of course take your time

…

On Mon, Sep 12, 2022, 14:18 Owen Green ***@***.***> wrote: Thanks for your patience @elgiano <https://github.com/elgiano>. I think I'm more of a fan of the ampfeature-select branch, but I'll look at both more closely (I seem to vary between preferring more objects vs preferring more attributes / options!). A next big chunk of work for me is to try and improve the usability of the API for making clients, so this is a really valuable exercise from my perspective! — Reply to this email directly, view it on GitHub <#198 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACNMWWTW2S4UXEN3HFMXC3V54NQBANCNFSM6AAAAAAQEKEOFY> . You are receiving this because you were mentioned.Message ID: ***@***.***>