CurrentWindow/tab/screen event?
NaturalDevCR opened this issue · 9 comments
Is there a way to programatically switch a view in the Ui, for example if I want to switch to the EQ screen, or the Gain Screen?
Also is there a way to get all available snapshots and channel names?
Thanks in advance
Is there a way to programatically switch a view in the Ui, for example if I want to switch to the EQ screen, or the Gain Screen?
No, the UI is purely local. The mixer doesn't track or publish any information about connected clients, so we cannot control anything else than the actual global mixer parameters.
Also is there a way to get all available snapshots and channel names?
Support for channel names will be added in the next release (see #74). It allows you to retrieve individual channel names. If you know which channels exist on hardware you can use this to read all channel names.
Reading shows, snapshots and cues is not trivial in the current implementation. This information is only published on request in a whole different message format than all other parameters. Therefore, I'd only implement this if there's a really good reason to do so. What is easily available is the current show and snapshot.
@fmalcher It would be nice to have a method to get all the message streams not only the SET and SETD messages, this would help to implement our own watchers/obervables for other tipe of raw messages in order to get some of this information.
I don't think it's clever to publish all events. There are a lot of messages coming from the mixer, e.g. the VU meter values. I would always restrict the messages stream to certain types. It would be possible to allow more types, but I'd approach this with great caution.
The state is only populated using SETD and SETS messages, so there has to be come second filtering to allow more types. My problem is that I don't the the value of ripping the implementation apart just for snapshot and show lists.
Edit: Btw, there is already a way to get all messages but I do not recommend relying on this. It's public but it's considered private API that could change at any time:
conn.conn.allMessages$
I actually was able to watch the allMessages$ but It won't get the PLIST messages to list the playlists and tracks for the player, also I can't see anything related to the track names... I see only VU, SETD, SETS, RTA and ACTIVE messages, I did filter the messages to hide the VU and RTA messages since there a lot of messages of that type.
But in the Web socket messages I can see the PLIST messages...
@fmalcher
This are some of the messages that conn.conn.allMessages$ won't show
Send: 3:::MEDIA_GET_PLISTS
Receive: 3:::PLISTS^Recordings
When you click on the Playlist the message sent is:
3:::MEDIA_GET_PLIST_TRACKS^Recordings
and finally you get the list of tracks
3:::PLIST_TRACKS^Recordings^uirec-20221111_075035.wav^uirec-20221113_072322.wav^uirec-20221113_225002.wav^uirec-20221207_011842.wav
This messages, and the ones for listing the shows snapshots, would be useful messages... as of the ones for getting the channels names...
I mean having access to those messages would complete a wide range of useful ways to interact with the mixers.
Anyway I understand if you don't want to add support for this... Thanks!
allMessages$ will actually emit messages for plists, shows, snapshots and cues. However, those messages are not broadcasted to all clients but are sent individually on request.
So, whenever a client sends MEDIA_GET_PLISTS the mixer will reply with PLISTS.
Since the connection lib doesn't request any of those, the info will never be sent by the mixer.
You can try and call conn.sendMessage('MEDIA_GET_PLISTS') and you should see the response in allMessages$.
The communication model for this is completely different from the rest of the global state. I suppose they didn't want to maintain a big nested structure of show/snapshots/cues and plists/tracks, so each client must request a certain branch of the state which will then be delivered by the mixer. This makes it rather difficult since it needs a whole new design compared to the global state.
as of the ones for getting the channels names...
Channel names are part of the global mixer state. They will be supported in the next release, it's already implemented.
@fmalcher thanks for the detailed response, that would work for me, you said I should not rely on the allMessages$ because it could change in the future, is there any reason to block this API in the future? I mean doesn't hurt if it's there for custom implementations...
And sorry for bothering a lot with questions... i'm wondering if there is a way to manually unsubscribe from events... example:
conn.store.state$.subscribe((value:any) => { if (!this.mixerModel){ this.mixerModel = value.model } })
Then later:
conn.store.state$.unsubscribe()
because it could change in the future, is there any reason to block this API in the future?
Not exactly, you can actually use it. However, I cannot guarantee that the internal API stays consistent over the years. Exposing too many internals would make refactoring more or less impossible.
The same applies for state$: I refactored the way the state is stored internally. It is now stored as a flat object, see 203cda0 . This will not change the facade API of the library but the underlying storage format and the actual output of state$.
And sorry for bothering a lot with questions... i'm wondering if there is a way to manually unsubscribe from events... example:
In this particular case you could do:
const subscription = conn.store.state$.subscribe(........);
// later
subscription.unsubscribe();However, I would rather use something like this if you just want to get the first emitted value:
const model$ = conn.store.state$.pipe(
map(state => state.model),
filter(e => !!e),
first()
);
model$.subscribe(.....)It will only emit once when the first truthy value is available.