Closed willwade closed 2 years ago
hosseinzoda
commented
5 years ago Well. Two softwares should connect with any form of communication. I think Bluetooth is a good option. Because it does not require difficult configuration. Then pasco itself (UI part) will be the client. And rpi will be a dumb server. Which just listens to what the client says. Like sending button click events. Or playing an audio.
willwade
commented
5 years ago But what if the RPI was there all the time and the screen part only occasionally? Ie the rpi is running all the time and taking input but listening for a viewer at any time?
hosseinzoda
commented
5 years ago I'm thinking rpi would act as something like a bluetooth keyboard or bluetooth audio. Which makes pairing part of it familiar to regular user.
rpi can take inputs and do other things while not being connected to anything. But does it have any use? If so I need to re-think about it.
hosseinzoda
commented
5 years ago For Remote Control over internet same thing applies. There's no need to run pasco in both devices.
How may headless pasco + UI pasco can get synced? So that connected clients can hear and see the same thing.
When I did study how a multi-player real-time game's communication looks like. I've found sync process will get achieved when each client does the whole game simulation at the same time. In a way that if you look at the simulation data in the memory it looks exactly the same for all clients. At only key events are sent between clients. This solution is very good strategy to reduce network bandwidth usage. I've recently saw google's solution for new multi-player gaming solution. Were the simulation is done in the google's data-center then screen video, audio and key events are communicated for users to be able to play.
There's no right solution in here. As far as I can see both can do everything we want.
One good thing about having simulation (server/client) is that they don't need to run exactly the same version of the software. Because the client is not running any simulation. (Server can be any of the two. rpi can be a server, running the simulation. In which it controls the state of the app. It is good when the UI pasco is not always running).
non of them are difficult to implement.
willwade
commented
5 years ago How may headless pasco + UI pasco can get synced? So that connected clients can hear and see the same thing.
I'm only imagining one client. I'm imagining the viewing device wouldn't get sound - that would make it really confusing (generally the client will be in the same room).
The sync idea - similar to gaming - makes a lot of sense. If the settings are on both devices - and the language file the same - I can see a way that that the Rapi pings out its current time and point in the language tree - and a start/stop notification. It could ping out via Bluetooth or TCP/IP - the key is low latency I guess.
hosseinzoda
commented
5 years ago I'm only imagining one client. I'm imagining the viewing device wouldn't get sound - that would make it really confusing (generally the client will be in the same room).
It can get configured to do so. If two of them are in the same room. Bluetooth connectivity makes most sense. It would be neat If we replicate something like how bluetooth speakers/keyboards are connected to devices.
The sync idea - similar to gaming - makes a lot of sense. If the settings are on both devices - and the language file the same - I can see a way that that the Rapi pings out its current time and point in the language tree - and a start/stop notification. It could ping out via Bluetooth or TCP/IP - the key is low latency I guess.
Right. It would use very low bandwidth. My only issue with it is that both clients should update at the same time in order to work correctly. It can work out. If we create bundles that allows remote update of rpi.
gavinhenderson
commented
2 years ago Closing in favour of #246
Ideally, like:
What's best way of that happening? (is this similar to #136 )