Em qui., 21 de jan. de 2021 às 19:14, Alexandre Torres Porres
My solution for ELSE seems to be as simple as it can get, you can just one [preset] object for any parameters of any type you want! It's basically vanilla making use of [text] and [savestate], it only needs one external, which is based on cyclone/grab. My concern is that I'm missing possible strategies and use cases with it.
I thought of a way to make my vanilla approach quite closer to my final design for ELSE. It'd require some ninja dynamic patching, but it'd be pretty pretty straight-forward if this happens https://github.com/pure-data/pure-data/pull/604 - this PR adds an inlet to [receive] so we can set receive names (there's another PR/issue we'd need to take care first),
The vanilla design would still need things like number boxes to have sends and receives to get and set preset values. Receive names would be passed as arguments and we'd have some naming conventions for send, like ending with "-set", so we don't need to pass them also as arguments (it'd be too much pollution in my opinion).
Proof of concept
[image: Screen Shot 2021-01-22 at 01.19.22.png] Not that I think we *need* 100% vanilla solutions everytime... but it's a nice exercise. And this is pretty much the same of my ELSE abstraction, it'd have the same features! The difference is that my ELSE design doesn't require the [send] objects. I'm just not doing this vanilla approach now because I don't wanna spend time doing ninja stuff. I can wait to see if we can get that PR that adds an inlet to receive before I revisit this.
The design seems pretty simple and powerful. As far as the other strategies go, I don't think I'm missing use cases or features of other current systems out there. There's the "morphing" or "interpolation" thing that I may be still neglecting and thinking that using things "line" objects is just as fine, but let's see. I'll also look into how max does interpolation, someone already told me that, I think I have an idea for that too.
cheers
