Module API v2

[Jeka8833]

I propose a significant update to the module system so that many modules can operate in parallel without parameter conflicts.

What is required for this:

1. Remove all module launch locks.

This will allow a module to start even without sending anything. The user will be able to install all modules. However, a conflict system for modules sharing resources must be implemented, see point 2.3.

2. Add a new API v2.
   1. Add a separate addParameter method for each module.

   This will precisely track which module sent data and what was changed.

   Data will be written to a queue from which the flush method (see point 2.2) will create a separate packet.

   2. Add a separate flush method for each module.

   Once a module finishes modifying data, it should call the data-sending method; at this point, the data will enter the mixer (see point 3) and be assigned a timestamp.

   3. Decide how to send a module stop command.

   The current stop algorithm is simply terrible (in my personal opinion). If this is not fixed, the situation will worsen; I believe there will be people who want to run 20 modules in parallel xD.

   4. Allow a module to send a list of conflicting modules.

   This is necessary if there is a common resource, for example, two modules trying to use the same UDP port.

   Both modules should be blocked even if only one reports a conflict. The user will have to choose only one module.

3. Create a parameter mixer class.

The class will monitor which parameters are not updating and set priorities for each module's parameters.

Let's assume that the parameter hasn't been updated for several seconds. In this case, it will be considered that the module is no longer tracking the parameter, and control will be passed to another module.

4. Transfer information from API v1 (Current API) to the mixer.

This will ensure the backward compatibility of modules. However, all modules using API v1 will be collectively labeled as Legacy in the mixer.

5. Add mixer management to the UI.

This will not be easy because over a hundred parameters already exist. I can't figure out how to do it and have never worked with design. + The situation is complicated by the fact that modules can change the decision about which parameters they track, which is a complex task to avoid confusing the user.

6. Create a class for sending OSC.

As soon as the module performs a flush (see section 2.2), the data should:

• Filter in the mixer (see section 3).
• Pass through OneEuroFilter.
• Enter the queue.

Sender thread:

• Takes all available data from the queue in one operation and packs it into one large packet.
• Determines which parameters the avatar expects.
• Sends the data

Solution to the Producer-Consumer Problem: discard old packets or block the module thread (Although blocking can cause tracking delay if the module receives too many UDP packets).

Keynotes:

1. It is necessary to design API v2 in such a way that it does not need to be redesigned upon release; it's better to review it several times during the planning stage.
2. The UI will be a nightmare because there are over a hundred parameters.

What this solves:

1. Eliminates the need to restart VRCFT.

For example, if you used a VR headset and then decided to switch to something that doesn’t require a headset (MeowFace, FoxyFace, etc.).

Currently, the user needs to restart VRCFT to use the new modules.

2. Modules will constantly search for and maintain connections to external APIs.
3. Modules can send as much information as they currently have.

This is the beginning of a dialogue where anyone interested can familiarize themselves with the scope of work and make corrections and suggestions. I'm not saying I will be doing this, but understanding the scope of work is also essential.