Nothing says Rockstar Musician Lifestyle like spreadsheet software. Okay, we might have mixed up the word order a bit in that sentence, but there’s always Python to add some truth to it. After all, if we look at the basic concept of MIDI sequencers, we essentially have a row of time-interval steps, and depending on the user interface, either virtual or actual columns of pitches or individual instruments. From a purely technical point of view, spreadsheets and the like would do just fine here.
Amused by that idea, [Maxime] wrote a Python sequencer that processes CSV files that works with both hardware and software MIDI synthesizers. Being Python, most of the details are implemented in external modules, which makes the code rather compact and easy to follow, considering it supports both drums and melody tracks in the most common scales. If you want to give it a try, all you need is the
mido module, and you should be good to go.
However, if spreadsheets aren’t your thing, [Maxime] has also a browser-based sequencer project with integrated synthesizer ongoing, with a previous version of it also available on GitHub. And in case software simply doesn’t work out for you here, and you prefer a more hands-on experience, don’t worry, MIDI sequencers seem like an unfailing resource for inspiration — whether they’re built into an ancient cash register, are made entirely out of wood, or are built from just everything.
Continue reading “Never Mind The Sheet Music, Here’s Spreadsheet Music”
Let’s be honest, no one likes to see their program crash. It’s a clear sign that something is wrong with our code, and that’s a truth we don’t like to see. We try our best to avoid such a situation, and we’ve seen how compiler warnings and other static code analysis tools can help us to detect and prevent possible flaws in our code, which could otherwise lead to its demise. But what if I told you that crashing your program is actually a great way to improve its overall quality? Now, this obviously sounds a bit counterintuitive, after all we are talking about preventing our code from misbehaving, so why would we want to purposely break it?
Wandering around in an environment of ones and zeroes makes it easy to forget that reality is usually a lot less black and white. Yes, a program crash is bad — it hurts the ego, makes us look bad, and most of all, it is simply annoying. But is it really the worst that could happen? What if, say, some bad pointer handling doesn’t cause an instant segmentation fault, but instead happily introduces some garbage data to the system, widely opening the gates to virtually any outcome imaginable, from minor glitches to severe security vulnerabilities. Is this really a better option? And it doesn’t have to be pointers, or anything of C’s shortcomings in particular, we can end up with invalid data and unforeseen scenarios in virtually any language.
It doesn’t matter how often we hear that every piece of software is too complex to ever fully understand it, or how everything that can go wrong will go wrong. We are fully aware of all the wisdom and cliches, and completely ignore them or weasel our way out of it every time we put a
/* this should never happen */ comment in our code.
So today, we are going to look into our options to deal with such unanticipated situations, how we can utilize a deliberate crash to improve our code in the future, and why the average error message is mostly useless.
Continue reading “Crash your code – Lessons Learned From Debugging Things That Should Never Happen™”
You don’t have to be an avid bookworm to find use for an e-book reader. Take your local wedding band for example: with a big repertoire of songs to cover, you don’t really want to drag huge folders full of chords and lyrics around, tediously browsing through them to find the correct one for every new song. Even the biggest tree corpse enthusiast cannot deny the comfort of an e-book reader here. And since turning the page boils down to simply changing the content on a display, you don’t necessarily need to use your hands for that either. With that in mind, [mosivers] built a WiFi foot switch for his musician brother’s Kindle to flip backwards and forwards through the pages.
After jailbreaking the Kindle and installing busybox, [mosivers] set up a web server to serve two CGI scripts that write the previously recorded input events for forward and backward flipping respectively to
/dev/input/event0, essentially simulating a touch screen press that way. The foot switch, as counterpart, houses a battery-powered ESP8266, acting as access point for the Kindle to connect to, and requesting those page flipping CGI scripts whenever one of its two buttons is pressed.
If you don’t like the idea of jailbreaking your device in order to change the pages without using your hands, you could of course consider combining a more mechanical solution with the foot switch concept. And in case you want to see more of [mosivers], have a look at his DIY talk box project we’ve covered earlier.
Writing device drivers is always a good start for a journey into the Linux kernel code. Of course, the kernel is a highly complex piece of software, and if you mess up your code properly, you might take down the entire system with you. User-space drivers on the other hand might not look as good on your CV, but they can help to work around some of the dangers and complexity of the kernel space. Plus, you don’t necessarily have to limit yourself to C to write them, especially if you are concerned about the usual C pitfalls and the security issues they can lead to.
With that in mind, [Paul Emmerich] is researching the concept of Linux user-space drivers for Intel’s 10Gbit network cards using other high-level languages, and recruits his students to write their final theses about the implementation details of as many languages as possible.
Since some of these languages bring their own memory handling and perform unpredictable garbage collection, performance and latency are two big topics to cover here. But then, the general concept is language-independent, so even if nothing in the world could ever make you give up on C, you might at least take away some new ideas for driver development.
Continue reading “35C3: Safe And Secure Drivers In High-Level Languages”
A little while back, we were talking about utilizing compiler warnings as first step to make our C code less error-prone and increase its general stability and quality. We know now that the C compiler itself can help us here, but we also saw that there’s a limit to it. While it warns us about the most obvious mistakes and suspicious code constructs, it will leave us hanging when things get a bit more complex.
But once again, that doesn’t mean compiler warnings are useless, we simply need to see them for what they are: a first step. So today we are going to take the next step, and have a look at some other common static code analysis tools that can give us more insight about our code.
You may think that voluntarily choosing C as primary language in this day and age might seem nostalgic or anachronistic, but preach and oxidate all you want: C won’t be going anywhere. So let’s make use of the tools we have available that help us write better code, and to defy the pitfalls C is infamous for. And the general concept of static code analysis is universal. After all, many times a bug or other issue isn’t necessarily caused by the language, but rather some general flaw in the code’s logic.
Continue reading “Warnings On Steroids – Static Code Analysis Tools”
Mankind’s fascination with airplanes is unbroken. Whether you’re outside with your camera, getting an actual glimpse of the aircraft, or sitting at home with your RTL-SDR dongle and have a look at them from a distance, tracking them is a fun pastime activity. Provided, of course, that you are living close by an airport or in an area with high enough air traffic. If not, well there’s always real-time tracking online to fall back to, and as [geomatics] will show you, you can build your own live flight tracking system with a few lines of Python.
As it’s usually the case with Python, a lot of functionality is implemented and readily available from external modules, which lets you focus on the actual application without having to worry too much about the details. Similarly, plenty of data can be requested from all sorts of publicly accessible APIs nowadays. If you are looking for a simple-enough example to get into both subjects with a real-world application, [geomatics]’ flight tracker uses cartopy to create a map using Open Street Map data, and retrieves the flight information from ADS-B Exchange‘s public API.
We have seen ADS-B Exchange mentioned a few times before, for example with this ESP8266 based plane spotter and its successor. And if you’re more curious about the air traffic in your direct surroundings, it’s probably time for a DVB USB dongle.
Dividing by zero — the fundamental no-can-do of arithmetic. It is somewhat surrounded by mystery, and is a constant source for internet humor, whether it involves exploding microcontrollers, the collapse of the universe, or crashing your own world by having Siri tell you that you have no friends.
It’s also one of the few things
gcc will warn you about by default, which caused a rather vivid discussion with interesting insights when I recently wrote about compiler warnings. And if you’re running a modern operating system, it might even send you a signal that something’s gone wrong and let you handle it in your code. Dividing by zero is more than theoretical, and serves as a great introduction to signals, so let’s have a closer look at it.
Chances are, the first time you heard about division itself back in elementary school, it was taught that dividing by zero is strictly forbidden — and obviously you didn’t want your teacher call the cops on you, so you obeyed and refrained from it. But as with many other things in life, the older you get, the less restrictive they become, and dividing by zero eventually turned from forbidden into simply being impossible and yielding an undefined result.
And indeed, if a = b/0, it would mean in reverse that a×0 = b. If b itself was zero, the equation would be true for every single number there is, making it impossible to define a concrete value for a. And if b was any other value, no single value multiplied by zero could result in anything non-zero. Once we move into the realms of calculus, we will learn that infinity appears to be the answer, but that’s in the end just replacing one abstract, mind-boggling concept with another one. And it won’t answer one question: how does all this play out in a processor? Continue reading “Creating Black Holes: Division By Zero In Practice”