Conviction, chapter 4, plus edits.

Dink99
Novice
Posts: 10
Joined: Wed Aug 20, 2014 10:41 am

Re: Conviction, chapter 4, plus edits.

Post by Dink99 »

Thank you!
felfan3000
Katzh-dashi
Posts: 115
Joined: Tue May 22, 2012 5:33 pm

Re: Conviction, chapter 4, plus edits.

Post by felfan3000 »

Oh, wow!

Thanks, Fel!
Linux. It's what you need!
Taliesin
Sorcerer
Posts: 73
Joined: Sun Apr 08, 2012 6:24 pm
Location: Washington State

Re: Conviction, chapter 4, plus edits.

Post by Taliesin »

Goodness! It appears that your creative engines are running like Karrine FTL hyperspace engines. :D

I don't know how you do it, but thanks again for all you do.
User avatar
ilox
Sorcerer
Posts: 62
Joined: Sun Apr 03, 2005 4:06 pm
Location: Adelaide, South Australia
Contact:

Re: Conviction, chapter 4, plus edits.

Post by ilox »

Thanks mate, that's awesome, got lots of reading to do to catch up with Flat Space ;)

Thanks so much for all that you provide for our entertainment.
Cheers, Ian
"From the moment I picked up your book until I laid it down, I was convulsed with laughter.
Some day I intend reading it." ~ unknown
calista241
Katzh-dashi
Posts: 105
Joined: Wed Sep 18, 2013 1:44 pm

Re: Conviction, chapter 4, plus edits.

Post by calista241 »

Awesome chapter Fel. Really excited about this story.
PhilippeO
Novice
Posts: 24
Joined: Sat May 10, 2014 2:43 am

Re: Conviction, chapter 4, plus edits.

Post by PhilippeO »

Thank you Fel.
User avatar
expedient
Mi'Shara
Posts: 522
Joined: Wed Apr 02, 2008 12:24 pm
Location: Pantora

Re: Conviction, chapter 4, plus edits.

Post by expedient »

Excellent work, Fel :mrgreen:
Represented by Senator Riyo Chuchi
anoopijt
Talent
Posts: 2
Joined: Sun Dec 25, 2011 6:14 am

Re: Conviction, chapter 4, plus edits.

Post by anoopijt »

thanks fel
ramouton
Sorcerer
Posts: 89
Joined: Thu Jun 13, 2013 8:46 pm

Re: Conviction, chapter 4, plus edits.

Post by ramouton »

Awesome work. Thanks Fel
User avatar
wetnomad
Katzh-dashi
Posts: 111
Joined: Thu Nov 01, 2012 8:42 am
Location: Hants, England

Re: Conviction, chapter 4, plus edits.

Post by wetnomad »

Many thanks Fel.
User avatar
Hearly
Speed Racer!
Posts: 1077
Joined: Wed Jan 14, 2004 5:06 am

Re: Conviction, chapter 4, plus edits.

Post by Hearly »

Thanks Fel
User avatar
trodrian
Sorcerer
Posts: 89
Joined: Sat Sep 08, 2012 6:33 pm

Re: Conviction, chapter 4, plus edits.

Post by trodrian »

thanks for the new chapter
cpsF21ZwUVHp
Talent
Posts: 3
Joined: Thu Jan 30, 2014 12:28 pm

Re: Conviction, chapter 4, plus edits.

Post by cpsF21ZwUVHp »

thanks a lot.

But I've one issue with the edits. And that's the depiction of audio/video transmission being being stretched or compressed because of the time dilation.

That might have been the case if the signals were analog signals where the playback clock is basically part of the signal. But it just doesn't make any sense for a digital transmission, where the transmission is just filling a buffer at whatever speed the data arrives, and the data itself contains information about the frames per second of the video and samples per second of the audio streams, which are then played back based on the clock in the local hardware.

The effects you would see is either playing for a bit, then stopping with a "buffering..." message, then playing again, and so on, instead of the playback being stretched out. Or a "buffer overflow" (unlikely, the computers shouldn't have any trouble buffering even years of A/V streams, much less a few seconds or minutes, so it would probably just simply work) instead of the playback being compressed.
User avatar
Wolfee
Mi'Shara
Posts: 614
Joined: Sat Apr 08, 2006 2:54 am
Location: USA
Contact:

Re: Conviction, chapter 4, plus edits.

Post by Wolfee »

cpsF21ZwUVHp wrote:thanks a lot.

But I've one issue with the edits. And that's the depiction of audio/video transmission being being stretched or compressed because of the time dilation.

That might have been the case if the signals were analog signals where the playback clock is basically part of the signal. But it just doesn't make any sense for a digital transmission, where the transmission is just filling a buffer at whatever speed the data arrives, and the data itself contains information about the frames per second of the video and samples per second of the audio streams, which are then played back based on the clock in the local hardware.

The effects you would see is either playing for a bit, then stopping with a "buffering..." message, then playing again, and so on, instead of the playback being stretched out. Or a "buffer overflow" (unlikely, the computers shouldn't have any trouble buffering even years of A/V streams, much less a few seconds or minutes, so it would probably just simply work) instead of the playback being compressed.
Agreed - if your using BG1 or whatever the secure biogenic connection to the ships is - there is no lag since its a biogenic connection.
cpsF21ZwUVHp
Talent
Posts: 3
Joined: Thu Jan 30, 2014 12:28 pm

Re: Conviction, chapter 4, plus edits.

Post by cpsF21ZwUVHp »

Wolfee wrote:Agreed - if your using BG1 or whatever the secure biogenic connection to the ships is - there is no lag since its a biogenic connection.
Well, it's not lag from the connection that's the issue, it's that the two endpoints (one in empty space, on in a galaxy) will have time flowing at different speeds.

So even if there is no lag in the connection and the signal is transferred in real-time as it is being created, if one side has local time running twice as fast as the other, you could get the effects described in the story, where the A/V is running slower or faster than normal. But only IF the signal is an analog one, where the signal itself contains the clock that drives presentation at the receiver.

With a digital signal, the latency or bandwidth of the actual data transfer doesn't matter in regards to the rate at which the signal is presented at the receiver. You have a digital stream of data, and part of that data is the information "there is a video stream with 30 frames per second here". The received data is written into a FIFO buffer at whatever speed it arrives, and the system that displays the video is reading data from that buffer at whatever speed is needs to for displaying the 30 frames per second according to a *local* clock.

So if there is a mismatch between the speed that the data arrives and the speed the data is used for displaying, you have two possible outcomes:

If the data arrives faster than it is being displayed (10 seconds pass for the sender for every 5 seconds that pass for the receiver) then all you need is enough space in your FIFO buffer to keep buffering all the data as it arrives, and there will be no visible problem with the playback.

If the data arrives slower than it is being displayed (5 seconds pass for the sender for every 10 seconds that pass for the receiver) then the playback will have to stop once the fifo buffer is empty, showing a "buffering..." message or something like that till there are a few seconds of video in the buffer, then starts playing again (based on the, faulty, assumption that the video data will keep arriving at the same speed as it's being used), only to stop again when the buffer runs empty. Rinse. Repeat.
Locked