The Fermi Paradox and a biological basis for sin

It started as a social media post. It explains my answer to the Fermi Paradox.

Humans are perfectly evolved to their environment. Their environment is human civilization. More so, all of the things which make humanity different than the animals are fundamentally ways to be rotten to other humans.

We can't run fast compared to animals, but we can run faster than many humans -- and we can do it holding their stuff. We the ability to communicate a rich array of emotions with our face -- which we can consciously use to lie about how we're feeling. We rely about a spoken language for communication, which allows us to convince our neighbor to do things clearly not in their best interest. We have no clear signs of estrus, and we can mate for pleasure, so we can lie about the fatherhood of our children. We've use clothing to lie about our physical imperfections.

We're basically evolved to lie, cheat and steal from other humans.

It's like a biological basis for original sin, where the ability to know all of these higher-order things is tied deeply to our ability to commit evil. (Religion, then, at its best acts as a filter to tie us back to the kind, social animals of our beginning.)

This would be the filter preventing intelligent life from reaching higher states. It becomes exceptionally hard to escape the fact that you're evolved to be evil to your kin. Backstabbing and distrust is basically baked in to the design. Your environment is your own civilization, and the natural impetus is to become a super-predator there.

It is deeply human to be rotten to each other. The exploration of this rottenness, both in fiction as well as non-fiction, is what daytime television is made of.

Evolution doesn't just stop because you've mastered your environment. It doesn't stop when you've mastered it locally on-planet, and it doesn't stop when you've mastered it and you can play with the stars themselves. Until a race stops having children, it keeps evolving. Shoot, even without children, if people can upgrade their physical form, there's still the ability to evolve.

From an extraterrestrial-visitor context, things go from bad to worse, as the likelihood of other life having solved our problems decreases. Militarized states and power struggles, the abuse of the lower classes, these become universal to the point that surviving them may mean mastering them in ways we've not considered. The notion of extraterrestrial con artists buying planets for baubles becomes all too realistic.

Further libretto research

I was feeling self-conscious about my libretto design, so I wanted to research some further examples.

I ran in to http://www.simplyscripts.com/musical.html and the first one that struck my eye was the The Pirates of Penzance. This was handy because it seems the majority of musicals the "simply scripts" site links to a Russian site that is now offline.

The Pirates of Penzance libretto is hosted on the Gilbert and Sullivan Archive, which might be useful for some, but since it likely uses a similar libretto design for all of them, it is less useful for me.

Of the Pirates of Penance libretto, on the Gilbert and Sullivan Archive page there's a section called "The Words", the first item of which is "Libretto" with three versions, plain-text, Microsoft Word and PDF. These are the versions I will be investigating in this post.

The plain-text version looks like a machine conversion, and has the problems you'd expect with such a conversion. Unicode characters were converted to the "unknown" square box. Line-wrapping is weird at best and hard-to-read at worst. (etc.) It means the plain-text first approach of reStructuredText -- even with the idiosyncrasies it has -- is much easier to read.

This is the first full libretto I've seen (ever). This means the existence of a title page and a "Dramatis Personae" list -- and even the very fact that each act has a distinct location associated with it -- are all new to me. (I had gathered that there should be two acts, and that some plays with one or three acts will eventually be converted in to a two act structure.)

However, my use of "small caps" instead of all caps seems to be backed up, as this is done for the actor names.

The design could be said to use the "Scene" as an actor. The scene setup has the word "Scene" in front of it, styled like any other actor. I like this approach, particularly if some aspect of the scene changes within the act.

There's a use of a period as a separator between the actor and the speech, instead of a colon. I don't understand this. I wonder if this is a vestige of the age of the libretto, as this doesn't make more sense to me than a colon.

One big change between the two designs is the actor's sung parts are formatted differently. Well, specifically, the sung lines are formatted the same, but the location for the singer's name is basically the same as for an actor, while in the design I mentioned in the previous post the singer's name is centered above the sung part.

I think being centered above the sung part is a lot easier to read. I'm glad I saw the other libretto first, because this design would also be harder to deal with from a reStructuredText stand-point.

As an added bit of confusion, the style changes if there are multiple parts sung at once. In this case the singer's names are above the sung parts. If it makes more sense in that context, we add useful consistency if that's the placement all the time.

This libretto actually has standard indented paragraphs with very little space between parts. It makes the spoken parts harder to read. My simple solution with hanging-indented paragraphs is so much nicer than this.

There's explicit mention of the song. It sort of surprised me that appeared absent in the earlier libretto.

There's some spacing weirdness in some of the songs that is basically what you'd expect when folks diddle around with indents and spaces. It adds unnecessary variation.

The first thing I noticed with the "Word" version is the libretto is 9,220 words. That backs up the notion that I had from previous research that 10k may be big for a musical. The second thing I notice with the Word file is that there appears to be zero thought about "styles" in the document. This means there's nothing that can be learned from the Word file that can't be learned from the PDF. It also explains the apparent diddling with indents and spacing -- without styles all formatting is just diddling.

Overall, most of the formatting differences were covered with the article that accompanied the other libretto example. The big things were really just missing pieces... that anyone familiar with a libretto would have remembered.

I'm left kind of wanting to convert the Pirates of Penzance libretto to my format...

Writing a libretto in reStructuredText

I'm adapting my February Album Writing Month (FAWM) album in to a musical. I have no experience writing scripts of any sort, so it should be fun.

I was pointed to http://kierenmacmillan.info/perfect-musical-libretto-format/ as a good example of a libretto. I liked it, it looked good. I can now produce something quite similar, from a completely text-based format (by way of an ODT file, allowing third-parties to easily tweak things).

See, the album it is based off of is an art concept album about copyright in the guise of hymn-filk. It was always planned that it would include full sheet music and be released with the most flexible license. This means that the libretto for the musical will be released with the same flexible license (Creative Commons Attribution) as I actually want people to be able to easily modify it.

New tools this year

I had a post a while back about the use of Markdown which then got converted in to ePUB and then to MOBI for Kindle.

I've moved on from that to reStructuredText with Sphinx extensions.

It's a simple plain-text markup -- but far more flexible than Markdown.

It also has direct ePUB output support. The initial "epub theme" isn't super awesome for novels -- it is considered "experimental" -- and the entire tool was designed for technical documentation, but tweaking the theme is straight-forward. I'll be providing a link to the theme I use.

I use a script to give myself a little more flexibility. On its own, Sphinx is great, but I wanted some specific features that weren't available out of the box.

I'll be talking about this more in later posts. I think I have a system in place that will allow me to keep my world notes for all novels in a shared world together, plus single-source an annotated behind-the-scenes version of the novel along with the released version. I should even be able to manage the issue of edits and tracking changes/comments on the source without using Microsoft Word's "track changes" feature.

Procrastinating with the Rijks Museum

I took a break from working on my NaNoWriMo novel to head over to https://www.rijksmuseum.nl/en/ and whip up a quick cover and banner.

"Veggie Time" is the working title of the book. I'm not really happy with it, but it gave me something to stick in the Gimp and can be easily changed later.

This uses the Amazon-recommended best dimensions for a Kindle book cover. I've heard people complain these dimensions look a little thin -- but when I loaded up the image on my phone it all made sense as it almost filled the whole screen.

The Amazon recommendation for the cover is located at https://kdp.amazon.com/self-publishing/help?topicId=A2J0TRG6OPX0VM and the current "best dimensions" as of today were
1563 on the short side, and 2500 on the long side.

The aspect ratio is different than the one required to upload a cover to the NaNoWriMo site, so I had to make a separate cover for that. I got best results actually creating a separate cover. The vast change in dimensions (230x300) meant that the subtitle ("A novel about vegetables and parthenogenesis") was illegible when I just scaled the text.

As an extra NaNo bonus, I've since realized I misspelled "parthenogenesis" on the cover. Since it is
saved as separate layers in The Gimp, it is trivial to fix.

We create worlds.

Reposting from a comment on Google+.

In The Number of the Beast by Robert A. Heinlein, the main characters use a device to travel to alternate universes -- and winds up in fictional universes.

Many years ago I had a dream in which I was giving a presentation or teaching a class. I said, "This is why we're here." I raised my hand, and I created a universe.

Years later, I found myself in a dream, going to a particular time and place on a world I had created. I was as a deity, complete with people fighting each other in my name (two groups indistinguishable to me) and at least one woman petitioning me to bring her son back to life. (I did not, for it would have bound me to that place and time.)

I went to a particular time and place on this world and looked up to watch the birth of the heavens, knowing that while there were other people on the planet, I was the only one looking up and seeing this event. What I saw was the transformation from a mathematical abstraction of a universe to a living, organic universe. It was so beautiful that I collapsed to the ground and wept. (The only time I have cried from overwhelming beauty.)

We, authors, create worlds. Are they real enough that a device may someday allow someone to physically traverse from our world to one of our creation? It would be delightful to think so. All I can say is that it is why I am here. It isn't to be worshiped in isolation, but to share the beauty with others.

Converting from Markdown

I have a ZIP file containing a framework for Ema. I'll be using to redesign and refactor my current novel. It's a blank, with some templates/examples, but otherwise empty and ready to be filled in. This takes the idea of a Wiki-fied beat sheet referencing scenes and converts it in to a single Markdown file that can be processed with pandoc in to something you can tweak later -- or directly in to ebook.

Now, it is possible to convert from your beat sheet -- with each scene marked with a clear identifier -- to a single Markdown document listing all of your scenes in order. This is why the wiki beat sheet uses WikiWords for all links except links to scenes. I also recommended you include chapter titles or scene breaks at the beginning of each of the scene files.

(The pandoc documentation generates an eBook using a chapter per file -- this is required to get pandoc's table of contents working -- but because scenes may be reordered in the beat sheet before the chapters are finalized, we can't just start out with this technique. Now, "pandoc" will still work to convert to other formats, but if you want to convert directly to an ebook you'll need to split the file in to chapters after we stitch the scenes together.)

The magic happens by way of "regular expressions". These allow you to perform replacement operations leveraging parts of your earlier text.

Using Notepad++ and CMD.exe

(I used Notepad++ in my example here primarily because when it installs, it has an easy context-menu item to launch it. (And it is free and open-source.) WriteMonkey is a Windows-native Markdown editor that has regular expression support, so you should be able to use it instead of Notepad++ relatively easily. Unfortunately, MarkdownPad -- for all its flash -- totally lacks any replace support, let alone regular expression support.)

The editors bundled with Windows do not support regular expressions. Notepad++ is a free multi-file editor with regular expression support. It's also open-source (GPL license). Similar techniques should work with any number of editors.

First save a copy of your "BeatSheet.txt" to "MakeWhole.bat". Open "MakeWhole.bat" in Notepad++. You will be making changes to the file, and you do not want to lose your beat sheet.

Next you need to perform a Search -> "Replace...", then set the "search mode" to "regular expression".

In the "Find What" field: ^.*([{](.*)[}]).*$

In the "Replace To" field: type "\2.txt" >> WholeDocument.txt

Unfortunately, I didn't see a way to remove the non-title lines, so they will need to be removed by hand. Delete every line that doesn't begin with "type".

These "TYPE" commands will result in appending the files to the "WholeDocument.txt" file.

If you think you may (accidentally or not) run the script more than once, you should change the ">>" on the first line to ">". This will cause the script to overwrite the file when it starts, then append to it. (Without this change, or a "del WholeDocument.txt" added to the beginning of the file, it will keep appending the files resulting in a WholeDocument.txt file which is less than usable.)

We're not quite done, though. Ema creates files with spaces turned in to underscores, so right now the files will all be not found.

This is also easy to fix using regular expressions.

In the "Find What" field: "(.*) (.*)"

In the the "Replace To" field: "\1_\2" 

Note that each time you perform this replace, it only removes a single space from the filenames, so you may need to run it more than once.

This should leave you with a "MakeWhole.bat" file which will work to create a WholeDocument.txt file.

One idiosyncrasy of this method is that if you do not end your files with a blank line, the first octothorpe/hash (#) in the file will but up against the last paragraph of the previous file. CMD.exe doesn't have an easy method to add an empty line to the file, but you can create a file with a single blank line, then "type empty.txt" >> WholeDocument.txt between each of the scene lines if that is an issue for you.

There isn't an easy way to  split the chapters out of the WholeDocument.txt using just an editor and CMD.exe. Hey, it is Windows, you have to expect some pain. -- Or you can install CoreUtils for Windows and use csplit, as mentioned in the "Using GnuWin packages" section.

Using GnuWin packages

The GnuWin packages are free/libre software packages to provide some tools which are standard on every operating system except Windows.

We will need to install CoreUtils for Windows and sed for Windows.We do not install a shell, so these will run from CMD.exe and create a BAT file to assist.

sed -n -e 'y/ /_/' -e 's/^.*\({\(.*\)}\).*$/cat "\2.txt"\nc:\\path\\to\\echo.exe/p' < BeatSheet.txt > MakeWhole.bat

MakeWhole.bat > WholeDocument.txt

This automatically adds a newline between files. This gives you one file called "WholeDocument.txt" and it splits the chapters out in files called ChapterXX (no extension -- with XX replaced with numbers starting with 00.)

Now, I've not tested it, however I know that you will need the absolute path to the CoreUtils "echo.exe" command before it will work. Without an absolute path it will use the CMD.exe internal "echo" command (even if you specify echo.exe -- it will actually echo "exe"), Unfortunately, I do not know the path the GnuWin packages install to, so I can not provide the path. I have substituted \\path\\to\\echo.exe instead. You need to replace it with the path to "echo.exe" included in the CoreUtils for Windows package with the backslashes doubled.

If you want to split the WholeDocument.txt file in to chapters, it is as simple as:

csplit -z -b %02d.txt -f Chapter WholeDocument.txt '/^# [A-Za-z0-9]/' '{*}'

This will split the file in to chapters and keep the files with a ".txt" extension so Windows can open them.

Using GNU tools (Linux, Mac OS X, or Cygwin)
If using standard GNU-style tools from Linux, Mac OS X or Cygwin you would use (these should two commands on two lines -- they wrap in this display):

sed -n -e 'y/ /_/' -e 's/^.*\({\(.*\)}\).*$/\2.txt/p' < BeatSheet.txt | (while read FILE ; do cat "$FILE" ; echo ; done) > WholeDocument.txt

csplit -z -f Chapter WholeDocument.txt '/^# [A-Za-z0-9]/' '{*}'

This automatically adds a newline between files. This gives you one file called "WholeDocument.txt" and it splits the chapters out in files called ChapterXX (no extension -- with XX replaced with numbers starting with 00.)

Using the pandoc technique to create an ebook should now give you the table of contents, as expected.

If using ikiwiki instead of Ema

I am a big fan of ikiwiki, but the syntax is different from Ema. Since we normally use WikiWords to link documents most of the time the differences will be invisible.

(It is expected that if you're using ikiwiki, you're using Linux, Mac OS X, Cygwin or another environment which is similar. -- ikiwiki doesn't want to run in Windows.)

First, you'll want to convert the draft/empty Ema-formatted files to ikiwiki standards. To start off, we need to rename them. I like to use mmv, which would work like so:

mmv *.txt '#1.mdwn'

The difference between Ema is ikiwiki uses double-square-brackets for links to other wiki-pages [[like so]] and allows spaces in filenames. Ema uses {curly braces}, and converts spaces to underscores. Since we normally expect WikiWords to work, the only place this shows up as an issue is the beat sheet.

It is left to your discretion as to whether you want to rename my "Scene_Title.txt" (now .mdwn) file using 'mv' or 'mmv'. It is just one file, and there's just one underscore/space, so it is trivial one way or the other.

Converting the Ema-style scene titles to ikiwiki is done through a simple "sed" command:

 sed -i -e 's/{\(.*\)}/\[\[\1\]\]/g' *.mdwn

That performs an ïn-place change between the Ema-style wiki-link and the ikiwiki-style wiki-link.

Now for the differences in the compilation stage:

sed -n -e 's/^.*\(\[\[\(.*\)\]\]\).*$/\2.mdwn/p' < BeatSheet.mdwn | (while read FILE ; do cat "$FILE" ; echo ; done) > WholeDocument.mdwn

csplit -z -f Chapter WholeDocument.mdwn '/^# [A-Za-z0-9]/' '{*}'

The two differences are again, the spaces are left unmolested, and the extension is "mdwn" instead of "txt".