Yellow-Dog-Man / Resonite-Issues

Issue repository for Resonite.
https://resonite.com
141 stars 2 forks source link

Extend OSC Generics #3108

Open gameboycjp opened 1 month ago

gameboycjp commented 1 month ago

Is your feature request related to a problem? Please describe.

When working with OSC, multidimensional values are usually provided on one path, using indexes. Combining those with multiple OSC components en masse can be fairly obtuse. Being able to use a multidimensional type as a generic arg would simplify the process of using them greatly.

Describe the solution you'd like

Add Resonites multidimensional types as supported generics.

Describe alternatives you've considered

Templates work, but are fairly complicated to create and update.

Additional Context

No response

Requesters

@gamethecupdog

JackTheFoxOtter commented 1 month ago

I'm not quite sure what you mean by multidimensional values, as far as I'm aware that's not part of the OSC specification. From my understanding if you have multiple related values you'd address them by giving them different paths. That's what I did for my OSC implementation when creating a remote with arbitrary buttons. There's paths for "button0" to "buttonN", each having their own values (like "button1/status", "button2/status"...)

Nytra commented 1 month ago

I think they mean having a OSC value component with a type like <int, int, int> that would have three int fields to source values from

gameboycjp commented 1 month ago

Please see the "Multi-Dimensional Values" section on https://wiki.resonite.com/OSC.

JackTheFoxOtter commented 1 month ago

Ah, so you mean OSC messages with multiple arguments. So what you're asking for is basically some higher-level abstraction for combining certain messages to Resonite vector types? I imagine that could be added, a sort of generic OSC combinator component for vector types that allows specifying separate paths / argumentIndizes for the individual members of the corresponding vectors.

gameboycjp commented 1 month ago

I was thinking it could just grab the indices in order, using the ArgumentIndex as an offset, but having a combiner where one can use a list of paths and indices would be a good option too.

JackTheFoxOtter commented 1 month ago

I don't think assuming order of arguments would be a good approach, considering this heavily depends on the implementation. You can't assume the first is always going to be X, or that the values you want to combine are even under the same path to begin with, or immediately following one another. Since this isn't part of the specification, making it something configurable is probably the only good option.