So, as I got ready for my next field recording excursion I reflected on how much easier things are, now we have flash memory. I mean, what a great invention! Non-volatile, no moving parts, light as a feather, and tiny. Did someone win a Nobel prize for this? I hope so.
It's also truly ridiculous how much memory I carry. For fun I thought I'd do a little inventory.
Hopefully this article will suit beginners as well as slightly more seasoned recordists.
So I did what every field recording mammal does on a day like today... I went out for a walk with two different recorders and three sets of stereo microphones. I thought I'd share with you some sounds, since every now and then it's fun to compare gear. Well, in truth I have been in more of a philosophical than technical mindset lately, so this was a nice change of pace.
What follows is a microphone comparison that developed over three updates. I think it's done now!
In August of last year I wrote a number of articles on the Zoom F8. One of these listed firmware suggestions to improve the recorder. Since then Firmware 3.0 was released, so I've edited that article to indicate which of the suggestions have been implemented. The majority have, which is incredible service on the part of Zoom. (I know some of you are reading this, so thanks!)
To aid in linguistic understanding and to further world peace, I've been compiling a helpful dictionary. The start of a new year seems a good time to share, before we are overwhelmed with a new crop of jargon.
Virtual: On a computer.
The cloud: On someone else's computer, trusted implicitly for your security and privacy.
Platform as a service: On the internet.
Web 2.0: A method of refreshing advertisements without reloading the entire web page.
It shines with a brilliance we did not expect, attracting our attention. Though we can't discern shape or colour, it's impossible to look away. This is the cynosure.
It's that very experience of being-in-the-world that "Lenore" explores. It's also the experience of watching this performance unfold.
Quite a number of people have asked me about the new Tascam DR-100 mkIII recorder. I have not used this unit, so the following analysis is based on the reference manual and promotional material.
Tascam have released a large number of digital audio recorders, but like many companies has not been addressing the needs of the field recordist. Their strength has been in tools for musicians, so their recorders have been oriented towards recording practice sessions or live performance. Low pre-amp noise is not a priority in these cases, and their previous units have had middling sound quality and spotty feature sets.
The same is true of the 60D and 70D models, designed for DSLR video shooters. These are feature rich but far to cheap to contain decent components. The pre-amps are OK for their designed purpose, but in my experience are intolerant of the different impedance loading scenarios that professional microphones might bring.
While I haven't used the 701D it appears to share the same innards as the 60D/70D. And then there's the revised 60D MkII... good grief not another model! According to the company's own literature the pres have been "improved" to be like the 40D, which are poor.
So, Tascam has so far not produced a smaller recorder sufficient for nature recording. How does the new unit measure up?
I have been creating websites for almost as long as there has been a web. For many years I was CTO of a business that did things then thought impossible (namely, large data transfers and processing). For two years I wrote Perl scripts. I have many hours of server configuration in my distant past, now thankfully (mostly) forgotten.
I now require a simple, open, extensible, standards-based solution. I am technically capable and don't mind programming a solution. But any coding must be in Python, since other languages waste my time. (I trust that is partisan enough!)
I will now summarise five different website development methods, as I see them.
The downsides of this method soon become apparent: maintenance, repetition, and sheer drudgery.
2. Generated static
Desktop tools can automate some or all of the process. Templates can be used to provide a basic pattern for a set of web pages. Specific data then fills out each instance. Code modules can be added to provide extra functionality. But the end result is still a set of static HTML files that can be viewed from anywhere.
Back when there were few available solutions I wrote my own programme, Wasp. This app worked in two modes, one of which was generated static files. And I have been using it ever since!
3. Dynamic server, fixed structure
This includes blogging sites like Blogger and most "easy" web front-ends. Content is delivered from a web server using CGI, but the process is completely hidden. The user is responsible for the content, and can modify the visuals to a degree.
This blog is one example. It is written on Blogger, which makes the basic process of posting articles quite easy. But the customisations you see here are the result of many hours of hacking and deciphering secret tech. When I dive into the code now, I have no idea what is going on.
A bigger issue is that the solution is closed. When (not "if") the Blogger engine disappear, my site disappears... and migration may not be an option. The knowledge learnt in one proprietary system is not transferable to another. They are a poor investment.
4. Dynamic server, dynamic structure
This category includes Content Management Systems (CMS), which range from the simple and cheap (Wordpress) to the complicated and terribly expensive (many corporate solutions). These provide a great deal of control over the structure and look of your website, and also easy methods to enter content.
This flexibility requires an increased commitment of time and effort. The same comments as above regarding the proprietary nature apply.
It's a given that a CMS option places constraints on server requirements and is often associated with increased monthly costs. It also restricts the choice of hosts. But these days the most popular solutions are supported by a variety of vendors.
I have developed client sites in Textpattern, which is open and free. Years later, these sites are still functional, but eventually will fade. All sites require maintenance as the underlying software versions change.
A CMS is a complicated beast. If you are building sites for a living, the investment you make in learning one might well pay off. Your customisations will be re-used often enough to be worth the time it takes to develop them.
But this isn't the case if you're using a system only occasionally. You will never remember all the little techniques and "gotchas". (That's why there's a thriving industry of Wordpress consultants.)
5. Dynamic framework
These code skeletons provide hooks into the web server and some useful scaffolding. They incorporate a CGI interface, so that dynamic websites can be served from Apache and the like. They assume that you have considerable programming skills, since you will be coding your own website structure and functionality.
My own Wasp was a workable solution. But it was made in an era when standard interfaces like WSGI did not even exist. It is out-dated and inferior to contemporary tools.
I spent a good deal of time evaluating the Python-based CMS solutions, but I am only going to present a summary here. The complexity of these systems, each with their own terminologies and assumptions, makes any comparison time-consuming and potentially error-prone.
The biggest issue is the amount of commitment necessary to properly review a product. Something simple and flexible at first glance may turn out to have hidden limitations.
We can break a CMS down to three areas of functionality: the templating system, data layer, and coding framework.
I am picky about templating. Certain products, typified by CherryPy, use "Pythonic" templating. What this means is that you mix in your code with your HTML template. To me this is a bad idea. Anything in a template should look like HTML (or meta-HTML). The Python code should stay in the code engine. This is doubly true in team development, where one expects a division of labour between the designer and programmer.
However, pragmatics comes into play. Sometimes it is easier to put logic in the template. A good solution will not require this but will support it.
Luckily, the situation in the last few years has stabilised and it seems that Jinja is the winner. This clear and powerful templating language is used in all of the CMS that made my final cut. The same was not true even a year ago, so be wary of reviews on the internet that are stale.
When it comes to the data, some products (eg. Django) bundle in an Object Relational Mapper (ORM), which is a way of translating from object-oriented code to set-oriented information in a database. My experience with these has been tainted, since they are terribly inefficient for large data sets. But for a website I am sure they are just fine. Nonetheless, I prefer that simpler options are also available.
Some coding frameworks are massive and bundle in as much functionality as possible (Django). Others are minimal and expect the developer to fill in the rest (Flask, Pyramid). I prefer the latter approach, since I won't be trapped by pre-made decisions.
This is true even if there is a rich ecosystem of developed plugins. There are several problems with using a plugin to add functionality. First, the plugin architecture itself my be restrictive or require excessive cognitive overhead. Second, you have just added a point of weakness, especially when it comes to security (Wordpress, cough). Third, you now rely on the plugin developer for timely updates as the main system evolves.
I will spare you further details of the forty or so systems I investigated. For me, Flask would be the system I'd choose when developing a dynamic website. But I'd keep an eye on Pyramid as well.
For a personal site, do I need dynamic content? Well, what does it have to do? (Have a look.)
I need to display a snazzy home page incorporating a couple hundred informative entries on my various activities. I want to filter these articles by category and show related articles for each, based on tags. The articles need to be sorted in reverse chronology, like a blog. And I will be adding more all the time.
So, yes, it does at first seem like dynamic content is needed.
What is needed is a darned good static site generator.
So I wrote one.
(To be continued.)
Adam Curtis is a neoconservative documentary film-maker funded exhaustively by the BBC. "HyperNormalisation" (view here) is his latest product, a sprawling collage of thoughts about contemporary political power. It displays his usual hallmarks: a totalising and reductive view of complexity, a disparaging view of artists, a dismissal of women that is essentially sexist, and an ignorance of philosophical thought, stemming from an inherent anti-intellectualism and self-aggrandizement.
His works are heralded without much criticism. This article will act as partial corrective.
The big problem has always been supporting the variety of software platforms in use. It's a significant challenge creating a unified experience for users of different web browsers on different operating systems. The recent proliferation of hand-held devices has increased the number of software platforms (Android, iOS), the number of rendering engines, and the variety of screen sizes in use.
In addition, the principle of responsive design holds that one single code-base should suffice for all viewer implementations.
That is why I am using Bootstrap, and specifically the new version 4 release of this platform. (Though this is still in alpha, I don't want to dedicate time to version 3, knowing the structure is imminently to change.)
Though the internal docs are good, there isn't much third party documentation on Bootstrap 4. I've been experimenting with layout and this article is the result.
Explore my many activities using the main menu above and search form below. Subscribe in each category to get new articles automatically. Visit my master page for even more. Email "robin [at] robinparmar [dot] com".
recent posts: all
Please contribute what you can to fund my research and artistic activities. Every little bit is appreciated. Thanks!
Search This Site
Field Recording Gear