Open munshkr opened 9 months ago
Is a good idea, but with the downside that the animation might look interrupted because the time is all of a sudden reset to a different position. So smooth motion from oscillators and rotation is broken because of it. Maybe the resyncing should only happen when a new client enters the session, or when Hydra is hush()
-ed.
Is a good idea, but with the downside that the animation might look interrupted because the time is all of a sudden reset to a different position. So smooth motion from oscillators and rotation is broken because of it. Maybe the resyncing should only happen when a new client enters the session, or when Hydra is
hush()
-ed.
Hey! Yes, it's not as easy as I thought at first... I guess we'd need to only sync new clients by taking another client as reference. But things can go wrong anyway and drift, so it will never be perfect.
My motivation was mainly solving the use case of having two Hydra windows in the computer, one for rendering in another screen/projector for instance (there are some situations where you don't want to show the code for example, and it'd be great that both windows are synced).
I think it could make sense to just have a section in the Flok documentation explaining the option to re-sync hydra visuals amongst clients. If the .time
variable is exposed as a global/window variable it can just be included in the code and run once before a performance starts to allow users to sync up manually if they prefer. I don't know what the variable is in Flok, but in Hydra it can be reset with hydraSynth.synth.time = 0
(in the past it was H.synth.time = 0
)
I was thinking it'd be interesting to explore syncing Hydra internal clock (the
time
variable onHydraSynth
). We could send thistime
variable on each evaluation and update the time variable on each peer that receives that evaluation message with the senttime
value.