Latency compensation. This why most people do not perceive any latency or lipsync issue when browsing YouTube on their phones with their expensive bluetooth headsets that have ridiculous amounts of latency (>250ms).
I don't know about podcasts and stuff, but for music, you can already OBS this puzzle out real quick and use the natural song bars as synchronization steps.
1. One musician plays simple bars, repetitive stuff, and streams it.
2. Second musician receives the audio from musician 1, records a multi audio track video of himself alone (in one track) and the musician 1 output in another.
3. Stack undefinitely.
You play to what you hear, in real time. All tracks are recorded separately in separate computers and can be edited together quite easily.
Plus, this is already how most jams work in real life.
> "now" isn't a single universal instant, it's a moving target
Rhythm is already a moving target, a delay cycle. Musicians just need to know the beat 1 for each bar (which they should already know, as it is their job).
> Our Universe has one very inconvenient problem: it has an unbreakable speed limit. While it may seem instant, light takes quite a while to get around, traveling at just under 300,000 KM per second.
Google and Azure Availability Zones seem to break that limit daily ... ;-)
This works for a listener down the chain, but obviously can't work for performers playing together. The article mentions a producer listening to remotely located performers as they were playing together, but fails to mention how these remotely located performers can sync to each other in the first place.
I think this would be easier to explain using strips of paper. Start by placing the strips horizontally, drawing a vertical line across all of them with a red pen. Then, shift the strips to the right relative to each other to represent latency. Next, having fold a section of each strip onto itself to shorten them beforehand, unfold them to show an extended length representing delay. Finally, fold them back again to represent waiting for the remaining delay from the transmit track.
For example, you got a drummer that does their thing.
The bass can react to the drummer.
The guitar and vocals can react to drummer and bass.
Each one could get a finished version, but with so much delay that they can't meaningfully react to each one coming after them or being on the same level.
Each performer plays to a backing track, and their performances are synchronised by artificial delay. They don’t hear the composite performance in realtime while playing (although they can hear a delayed version, if desired).
I request you to edit the article and also add the point that "30 mins is only from the perspective of the observer on earth or mars" For a person who is actually making the voyage at the speed of light (impossible if you mass honestly) it is instantaneous
9 comments
[ 140 ms ] story [ 92.2 ms ] thread1. One musician plays simple bars, repetitive stuff, and streams it.
2. Second musician receives the audio from musician 1, records a multi audio track video of himself alone (in one track) and the musician 1 output in another.
3. Stack undefinitely.
You play to what you hear, in real time. All tracks are recorded separately in separate computers and can be edited together quite easily.
Plus, this is already how most jams work in real life.
> "now" isn't a single universal instant, it's a moving target
Rhythm is already a moving target, a delay cycle. Musicians just need to know the beat 1 for each bar (which they should already know, as it is their job).
Google and Azure Availability Zones seem to break that limit daily ... ;-)
For example, you got a drummer that does their thing.
The bass can react to the drummer.
The guitar and vocals can react to drummer and bass.
Each one could get a finished version, but with so much delay that they can't meaningfully react to each one coming after them or being on the same level.