POC complete. Four questions and a sanity check before attempting full implementation.

Greetings,

I completed a POC of my Max For Live project. I think I have enough information to attempt a full implementation, but I have a few questions. My goal is to try - as much as possible - to avoid spending six weeks implementing my full project only to find some deal breaking issue at the very end.

Background

My project consists of controlling Live parameters based on incoming MIDI notes and/or dial turns. It will require lots of live.remote~ objects, possibly hundreds. In my testing, I had no problem instantiating 10,000 live.remote~ objects. Since I want to allow dynamic mappings, and since live.remote~ objects cannot be dynamically instantiated, I need to have a large set of live.remote~ objects created and waiting in a "bank."

After a lot of research, I learned that live.remote~ can control Live parameters in the high-priority thread IF it is given a signal input as opposed to say, a float. Then I learned about the sig~ object, and I simply sent my float values to a sig~ object before sending them to live.remote~, and it seems to work fine.

Question 1

Is it (forcing live.remote~ to run in the high-priority thread) really that easy? Is simply passing a float value to a sig~ object and then to live.remote~ enough to force live.remote~ to run in the high-priority thread?

Question 2

In order to save CPU, some users suggested they down sample signals sent to live.remote~. But, that seems unnecessary given when I read a Max employee write here (emphasis mine):

There is a lot of plumbing required to update parameters in a Live set at audio rate and keep things cool in Live. Note that you can send a different value for each sample and the CPU will not increase over that value. Also adding multiple live.remote~s hooked up in this way does not continue to add CPU load at the same rate.

Considering the above, is there a need to down sample signals I send to live.remote~ in my case?

Question 3

Does anyone have experience using many hundreds of live.remote~ objects? Have you noticed any stability issues or performance degradation as you scale up the number of live.remote~ objects in your devices?

Question 4

I read some users say they experienced latency issues with live.remote~, but from what I can tell, most of those issues were due to their own implementation. After all, it seems Live's own Expression Control device seems to use live.remote~ just fine. Are there any latency issues I need to worry about?

Many thanks for taking the time.