Add support for hot/cold inlets

[tap]

Objects need to respond to the A_CANT method "inletinfo" and then set the hot or cold boolean for each inlet as queried by Max. Here is the code implementing that method in the join object in Max:

void join_inletinfo(t_join *x, void *b, long a, char *t)
{
	long i;

	if (x->triggerlist[0] != -1) {
		*t = 1;
		for (i = 0; i < x->triggerlistlen; i++) {
			if (join_is_trigger_inlet(x, a)) {
				*t = 0;
				break;
			}
		}
	} else
		*t = 0;
}

In Min we can make the hot/cold setting of a property of the individual inlets.

[jobor019]

This has been my biggest gripe in the min-api for a long time, so I dove a bit deeper in the code to see if I could propose a solution to it!

I basically have two proposals:

• one static that simply allows us to pass a bool display_as_hot upon constructing the inlet.
• one dynamic that would allow us to change hot/cold at runtime (similar to objects like join with the @trigger attribute) by passing either a bool or an std::function<bool()> when constructing the inlet

Here's a minimal example of how to use the dynamic solution:

#include "c74_min.h"

using namespace c74::min;

class playground : public object<playground> {
public:

    inlet<> inlet_main{this, "(bang) a default (hot) inlet"}; // backwards compatible
    inlet<> inlet_hot{this, "(bang) a hot inlet", "", true};
    inlet<> inlet_cold{this, "(bang) a cold inlet", "", false};
    inlet<> input_variable{this, "(bang) a variable inlet", "", [this]() { return inlet3ishot.get(); }};

    outlet<> output{this, "(anything) an output"};

    attribute<bool> inlet3ishot{this, "inlet2ishot", false};
};


MIN_EXTERNAL(playground);

I haven't opened a PR yet since I don't know which one to use as the dynamic solution relies on std::variant, which requires MacOS 10.13 minimum (EOL since 2021), while min-api enforces 10.11 (EOL since 2019) as deployment target.

Is there a particular reason why the min-api enforces 10.11 as deployment target or is this just a remnant from what was considered relevant when it was actively developed?

[isabelgk]

Hi @jobor019 ! To answer your question, the enforcement of 10.11 as a deployment target is because of compatibility with Max and its minimum target.

That said, if we used mpark/variant, we could side-step the issue and use mpark::variant without needing to up our requirements and still get the dynamic solution you propose.

[jobor019]

Thanks for getting back to me!

Using std::variant for this solution isn't strictly necessary, it's just an elegant way to do it. It'd be possible to achieve the same result with normal/dynamic polymorphism or simply using two different std::optional member variables. If it's necessary to keep the 10.11 enforcement, I could provide you with a PR that's compatible with that without adding further dependencies.

However, with the release of Max 8.6, the official requirements have been updated to 10.15 minimum, wouldn't it be a good idea to follow for the min-api / max-sdk as well?

I assume (hope?) that there are plans to add support for arrays and strings to both the max-sdk and min-api, and wouldn't that regardless mean that 10.15 would become the minimum requirement?