Thursday, May 25, 2017

Arduino IDE: Best practices and gotchas

Programming for the Arduino is designed to be easy for beginners. The Integrated Development Environment (IDE) provides a safe place to write code, and handles the make and compiler steps that are required to create processor instructions from your C++ code.

This is fine for trivial applications and school exercises. But as soon as you try to use structured code (including classes and custom libraries) on a larger project, mysterious errors and roadblocks become the order of the day.

This article will consider best practices for working within the IDE. I will document a number of common errors and their workarounds. My perspective is of an experienced Python coder who finds C++ full of needless obfuscation. But we can make it work!
Wednesday, May 03, 2017

Valentine's Day microphone test revisited

OK, so this article was meant to be posted months ago. Something happened and it went into limbo. Only one reader, Wojtek, noticed. I am not sure what this says about the popularity of this blog!

In the original Valentine's Day microphone comparison I tested three sets of mics in different scenarios. The files are still available, so you should visit that article if you haven't already.
Wednesday, March 15, 2017

Great invention: flash memory



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.
Wednesday, February 15, 2017

Comments on field recording gear

This article will provide technical details and discussion for my Valentine's Day microphone comparison. First I will outline some requirements for field recording and discuss one useful specification. Then I'll discuss the specifics of the gear, typical pricing, and conclude with some remarks about relative value.

Hopefully this article will suit beginners as well as slightly more seasoned recordists.
Tuesday, February 14, 2017

Valentine's Day microphone comparison

It's Valentine's Day, which means that spring has sprung here in Ireland. I know my Canadian friends will find that hard to believe! But the crocus are out, the trees are budding, and birds are starting their courtship and territory marking.

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!
Tuesday, February 14, 2017

Zoom F8 Firmware Update 3

This is a rather belated post. But, as you can see from my website, I've been rather busy.

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!)
Thursday, January 05, 2017

The Devil's Dictionary of internet terminology

This internet business is big money, people tell me. And apparently most of the money is spent by the marketing department, inventing new buzzwords. If I had a penny for every time someone used one of these nonsensical terms, well, then I'd have an internet business model.

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.

User-driven: Market-driven.

Market-driven: Profit-driven.
Saturday, November 12, 2016

Grasping at cynosures: a review of "Lenore" by Angie Smalis and Colin Gee



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.
Thursday, November 10, 2016

Tascam DR-100 mkIII recorder



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.

Track record
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?
Tuesday, November 08, 2016

How to building a website in 2016

After many years I have updated my personal website. In the process I had to consider what might be the "right way" to build a site in the current era. This post will discuss different options, categorised under five headings.

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.

1. Static
This is the simplest way to create a website. Create the HTML, CSS, and Javascript manually. Combine with JPG graphics. Upload to any old web host. Done.

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.

Comparing CMS
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.

However...

Reconsidering
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.

But, in fact, all of this can actually be done with static files. The different views of the data can all be determined ahead of time (so long as there are not too many). Certain changing content can be provided on the front-end using Javascript, without requiring server-side actions.

What is needed is a darned good static site generator.

So I wrote one.

(To be continued.)