Linux MIDI: a Brief History, Part 1
In 1981, an audio engineer named Dave Smith designed a universal interface for connecting synthesizers together. He presented his basic design at the Audio Engineering Society meeting that year, and in 1982, the Roland corporation expanded the design specification. Later that year Smith's company, Sequential Circuits, produced the Prophet-600, the first MIDI-capable synthesizer.
The first public presentation of a working MIDI connection took place in 1983 at the winter NAMM (National Association of Music Merchandisers) show. A Sequential Circuits Prophet-600 was connected to a Roland Jupiter 6 by each synth's MIDI interface. Connecting synthesizers together certainly was not a new idea, but this means of doing so was new and far more effective than earlier solutions. In the summer of the same year, Yamaha introduced the DX7 FM synthesizer, with MIDI hardware as a standard component. MIDI rapidly found favor with manufacturers that recognized the advantages of standardizing a basic hardware/software interface for data exchange among different machines. It is no exaggeration to say that MIDI fueled an incredibly active period of hardware synthesis development during the late 1980s and early 1990s.
MIDI also was adopted quickly for use with the newly popular personal computer. Manufacturers marketed standalone MIDI interface cards that allowed MIDI data exchange between a host computer and any external MIDI equipment. Software houses created and marketed music composition programs and other MIDI software. Equipped with the right hardware and software, a musician could use the computer to control synthesizers, drum machines, mixers, effects units--anything equipped with MIDI connectors. The extent of control varied, but the efficiency of the MIDI studio made a revolutionary impact on music production.
The MIDI studio of the late 1980s typically included a computer, a keyboard synthesizer, a drum machine, some external rackmount synths, perhaps a MIDI-controllable effects box and a MIDI router box to connect these pieces. At that time, the dominant audio recording medium was tape. By the mid-1990s, though, the MIDI studio was becoming more computer-centric, with soundcards providing better on-board synthesizers and software MIDI sequencers evolving to include audio tracks. By then, audio recording had shifted to the hard-disk. A contemporary MIDI studio still might include a keyboard synth or two, but the computer itself now was able to host software synthesizers and effects processors. At the same time, the computer internally controlled all MIDI connections and routing while running a sequencer capable of recording synchronized MIDI and audio data.
The MIDI specification has responded well to the needs of its community of users. The spec now includes provisions for encoding SMPTE time code, message types for remote operation of machine transport controls, a generalized instrument patch map for synthesizers, a standardized sequence data file format and support for multiport hardware, with a per-port maximum of 16 channels.
For many people, a MIDI refers to a file saved in the MIDI sequence data file format, typically with the .MID extension. If the sequence is orchestrated following the general MIDI (GM) synthesizer patch map, you can play it on any GM-compliant synth and hear the same arrangement of instruments. The quality of instrumental sound varies, of course, from synth to synth. This combination of standard file format and generalized patch map itself has fueled a rather different revolution, the results of which can be evaluated by a quick search for "MIDI files" on Google. As I write this--September 7, 2004--the hits number more than two million. A facile proof, but clearly a lot of people enjoy making and using MIDI files.
MIDI is an acronym for musical instrument digital interface. It is a design specification for a hardware and software interface for the transmission and reception of MIDI data messages. These messages vary in kind and relative significance. For example, when you play a MIDI keyboard, the key press and release actions send on/off messages that trigger the sound capabilities of the receiving synthesizer--which may or may not be the one you're playing. Patch select buttons send MIDI program change messages, pitch bend and mod wheels send continuous streams of data, pedals send their own kind of messages and so on.
The MIDI data stream carries various messages to a target device and activates the device's various capabilities. The original intent was to connect synthesizers, but the MIDI specification now encompasses the control of a wide variety of devices, including non-musical equipment such as lighting systems, pyrotechnic displays and stage hydraulics.
MIDI data essentially is control data, and it is important to note it is not digital audio data. MIDI files are quite small when compared to a WAV or MP3 version of the same file, which gives them much appeal when storage and speed of access are critical considerations.
For the technically minded, here are a few technical statistics: MIDI works at an asynchronous transmission rate of 31.25 kilobits per second, and a single MIDI data byte equals ten bits. A note-on message is three bytes long, so a single key press on your synthesizer keyboard takes about 1 ms to get to the synthesizer itself. Although MIDI is a relatively slow serial communications protocol, it still is good enough to capture and play accurately a human performance.
Despite its popularity, MIDI is not a total solution for computer-based music making. It does not directly deal with audio data, its original keyboard orientation does not lend MIDI to easy implementation for plucked string instruments or wind instruments, and its integer valuation may not provide the fine control sought by the musician or composer. Nevertheless, if your needs do not involve such considerations, then MIDI might be a perfect fit for your music-making endeavors.
Similis sum folio de quo ludunt venti.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide