Websocket rooms and rates

[coeur-de-loup]

Would it be possible to instantiate multiple 'rooms', with different priorities? Some time critical things, I want them the fastest possible, but some other things are less critical and can be executed after. Also, would it be faisable to have access to transfers stats and to dynamically change them? In big apps with lots of listeners, this becomes a problem.

[leolabs]

I don't think it's possible to have different rooms with different priorities, unfortunately. In the end, all calls to Live are being made on their main thread which ableton-js has no control over.

I personally haven't had any issues dealing with many listeners. In large projects, I'm dealing with around 10k listeners at once and it seems to work alright for me. What kind of issues are you experiencing?

Could you elaborate on what you mean by transfer stats?

[coeur-de-loup]

If you manage 10k listeners without problem, that means the problem is on my client! The idea with transfer rates was to have a method to throttle some listeners and a listener to to get and listen to these throttle values. For example, when I watch playing_position of clips, maybe I don't need to have 1000 update per second. Sure I can manage in client, but it means we sent those unnecessary updates. A kind of addPolling(prop, pollingRate) instead of a listener...

[leolabs]

Usually, Live sends updates related to playback positions every 60ms, so you'll receive ~16-17 updates per second. This will likely still be more performant than polling every 100ms or so since Live can decide when and how often to send these updates.

[coeur-de-loup]

Ok I see that the code is already optimized on the midi-script. I think it's the way I bridge from my node websocket server to my clients the bottleneck.