ISF: "My input count" as a local Internal

[Terry Payman]

Apologies for spamming with a repeat feature request
I've just been testing one of my ISFs where this feature would be very useful, and I couldn't resist asking again.

If the input count of an ISF could be made available to it as a local Internal, functionality such as the MultiMix's "Repeat" function could be implemented. The Feature could be named something like "My Input Count", emphasising that it's local to the module.

Use case examples:
- A variant of the MultiMix module, having an alternative to the linear mix between adjacent inputs (eg non-additive mixing or Vidvox transitions).

- An AddMany module that would linearly add all the active inputs then divide by the input count.

Naturally the module would have a finite input capacity as Inputs would need to be explicitly declared, but it would be very handy not to have to keep changing an explicit "Wrap" setting as inputs were added or removed.

[Sadler]

Here's my take if I understand correctly. I can see a benefit to this but it would break the ISF standard and possibly its stateless requirement. Other apps are happy to break the standard (Synesthesia) but doing that precludes the ISF editor and website and any other ISF apps from our toolset. Where I need to know the number of inputs I put a long in the JSON and choose at design-time. Also since all inputs need to be declared you don't gain much and you can iterate using that count. The glsl would be like if (1) then A, if (2) then A and B and so on.

A possible kludge way to do it without breaking the standard - if users were to include a specific input value in the JSON - e.g. "magic_input_count" then magic could populate that without user interaction or even UI (though it would show up in ISFEditor).

[Terry Payman]

...Here's my take if I understand correctly. I can see a benefit to this but it would break the ISF standard and possibly its stateless requirement...

With great respect I disagree that my proposal breaks the ISF standard, and apologise for not making it clear that I was referring to a Magic Internal such as Playlist Entry #, Frame Rate or Iteration #, and that this would be made visible to a module only via one of its declared ISF inputs.

I propose one more such Magic Internal, giving the code encapsulated within the ISF access to the Magic environment outside. The only difference would be the scope of the Internal, which would be limited to the particular module.

Magic adjusts the number of input pins displayed on a module according to the <actual number connected>, rather than the number of Inputs declared within the ISF code.
This clearly does not break the ISF standard, so nor would my proposal to make the <actual number connected> available locally to a module as a Magic Internal ("My Input Count") via one of its declared ISF Inputs.

[Sadler]

Ah, yes. I did misunderstand - good that you clarified. So I could replace any drop-down or long parameter with an internal that sets the source count from the number of inputs. That would work where all the inputs were the same.

[Terry Payman]

... That would work where all the inputs were the same.

Ah, thanks, I hadn't considered that, but I think it would still work if the actual input count was appropriately Offset.

[Magic]

I'm not sure I understand this. Why would such a value be useful? MultiMix already has a Repeat parameter that automatically loops around based on the number of inputs. Is it because you want to create ISF modules that have that functionality? Then you'd have to explicitly declare a new "image" input for each input, so it wouldn't be that much less inconvenient than changing the Wrap value manually.

If your thought is to predefine, let's say, 20 "image" inputs in some ISF module, but you only use 2 or 3, then that's a bit inefficient. The ISF has to be ready to process 20 inputs so it would reduce performance. This is one of the reasons that MultiMix and InputSelector are not ISF modules.

[Terry Payman]

... MultiMix already has a Repeat parameter that automatically loops around based on the number of inputs. Is it because you want to create ISF modules that have that functionality?

That is my main use case, specifically with non-linear transitions between the two active inputs. Non-additive mix would be my first choice, but the framework would allow for ISF transitions too. I presume this is a standard VDMX feature, as they published many "Transition" ISFs.

... you'd have to explicitly declare a new "image" input for each input, so it wouldn't be that much less inconvenient than changing the Wrap value manually.

From my viewpoint
- The explicit declaration needs only to be done once, and then can be AI assisted.
- The Wrap value would need to be adjusted for every instance of the ISF where the number of active inputs was different to the default count. This is somewhat disruptive to the design flow, and error prone if a very large number of active inputs have to be counted each time a change is made.

...
If your thought is to predefine, let's say, 20 "image" inputs in some ISF module, but you only use 2 or 3, then that's a bit inefficient. The ISF has to be ready to process 20 inputs so it would reduce performance...

Accepted. My aim is to streamline the creative use of the ISF by facilitating iterative development of a scene when input count might be increase or decrease. Once design is finalised (and if efficiency is inadequate) AI can readily be used to customise the number of declared inputs to the ISF to suit each specific case - building growing family of "child" ISFs.

...This is one of the reasons that MultiMix and InputSelector are not ISF modules.

The biggest benefit I find with these modules is that unselected inputs are not rendered - and I suspect that would not be the case with an ISF MultiMix variant*. My ideal "MultiMix+" module would be precompiled to give the same selective rendering benefit, but would have a file input to select a two-input transition ISF of the user's choice. I thought that might be too big an ask, hence my interim suggestion - which also has use cases beyond the MultiMix.

EDIT: *I find no efficiency hit from coded but unconnected inputs in an ISF.