rewriting history
…in which we emerge victorious, we’d like to think.
Porting old material to new formats is not always straightforward. The translation is often imprecise, and even narrative elements become elusive, falling prey to mechanics. You walk the no-man’s land between documentary (stringing together recollections, annotating random snapshots), conservation (replacing the rotting canvas thread by thread in hope of retaining the painted gesture), and revival (with a nod to the original, re-creating something else). You navigate by memory and what mementos you collected, knowing your former, fellow travelers collected other bits and probably recall the whole business differently. Once you’re each done and stumble out, you’ll realize where you’ve landed.
In our “last” blog post, our next overhaul, we announced our internal campaign to consolidate commentary, opinion, and self-congratulatory posts here in WordPress, while removing source material for sharing to more robust external websites. That took a while, but 2020 afforded some unique opportunities for over-focus thanks to the COVID-19 lockdowns, and now it’s done. Our ccHost and MediaWiki pages are retired, and all material is available elsewhere.
So why the air quotes? Well, because we’ve posted rather a lot since that “last” post. In the course of the port, we had to review, retag, relink, or relocate 82 wiki pages, 93 blog posts, and 386 sound files. Many of those wiki pages became new blog entries or project pages. While some of the material remained in place and intact, some of it had to be republished, and much of that begged to be reorganized. And that meant choosing “when” to republish it. One could:
- Pour the original wiki contents into a WordPress blog page and back-date the post date to match.
- Annotate the original wiki contents, fudging the publication date to match the original as above, but adding a separate date for each note.
- Rewrite and reorganize the material, noting the original source date in the text but using the actual publication date for the post.
There’s no single good answer except, perhaps, to leave file dates undisturbed wherever possible. Even this becomes an issue when up/downloading files between platforms. So we’ve done all of the above.
The wiki timeline was sacrificed when necessary, while files that could be retained in place were left temporally unmolested. If file metadata was updated, it was usually because some problem—a poor audio level or missing format—had to be addressed. But those posts based on wiki articles? Well, I’ve tried to follow the logic outlined above. Meaning, of course, do not trust the “post” date: it may only exist to serve the current narrative.
Which brings me to our third rewrite of the Long Beach SoundWalk 2012 project and its many cross-linked blog articles—eleven, as of this writing—and at least one subproject:
- First published as a media slide show in April, 2014, it used a post date of September 1, 2012 corresponding to the event itself, just so the projects would appear in the proper order on the main page
- In its second appearance, almost exactly six years later, the project sprouted hundreds of lines of additional text, yet captured the content of only three of our original thirteen MediaWiki pages. The September 1 post date remained unchanged.
- The latest revision aims to resurrect the other ten pages of content and to provide additional commentary and more friendly navigation. I’ve also taken the liberty of adding a few more pictures but leaving the project post date unchanged.
Why does any of this matter? Perhaps an illustration will help. The featured image for this article started out as this:
The next update—should there ever be one—will hopefully just add links to documentary media files as yet unpublished. In the meantime:
Read the fine print…
