Grey Rock Studio

Upcoming Presentation: An Introduction to Ubuntu Studio

2009-11-17T15:48:00.000-08:00

An Introduction to Ubuntu Studio
presented by the Ubuntu Vancouver LoCo community
Nov 21st at 2pm

This coming Saturday, Ubuntu Vancouver warmly invites you to learn about the free and open source multimedia production software in the Ubuntu Studio operating system ( http://ubuntustudio.org ). Ubuntu is the world's most popular Linux/GNU distribution and Ubuntu Studio is an official derivative that's designed specifically to help Audio, Video, and Graphic artists. This free community-organized information session will cover all the basic information about Ubuntu Studio, the multimedia creation software it contains, how to learn more, and how artists utilize the software on a daily basis. Many of the applications also work on windows and mac operating systems, so all operating system users are welcome and encouraged to attend. Some Ubuntu Studio installation discs will be available.

This event is presented purely by volunteers and will take place on Nov21st at 2pm in Vancouver. Further information is available at http://is.gd/4Xfmq (the event page) and at http://is.gd/4Mihd (the agenda page). It would be nice (for organizational purposes) if attendees could RSVP at http://is.gd/4Xfmq but it's not required.

Audio artists will find Ardour (a professional DAW), LADSPA plugins, Hydrogen (a drum machine), Denemo (a notation editor based on the lilypond score language), Mixxx (DJ software), PureData (a multimedia programming environment), Audacity (an audio editor), and SooperLooper (a live looping program) particularly interesting - to name just a handful of the free programs installed.
Video artists will find Kino (a DV editor), Blender (a video editor and 3D compositor), and Stopmotion (a stop-motion animation program) quite useful and interesting.
Graphic artists will find Gimp (a bitmap editor - similar to photoshop), Inkscape (a vector graphics editor), Blender (a 3D compositor), Scribus (Desktop publishing software), Agave (a colour pallet tool), and a number of font editing tools and free fonts to be very helpful.

The presentation is expected to take just over an hour, and will include local users and developers of Ubuntu Studio sharing their knowledge, and answering your questions. If you're unable to attend but would like to learn more about Ubuntu Studio, a video recording of this session is planned - I will post the link to this video once it's uploaded. Thanks for your time.

Interesting Online Journal

2009-10-14T15:49:00.000-07:00

I just wanted to post a quick blurb about the latest eContact! from CEC (Canadian Electroacoustic Community). It's theme for the 11.3 release is focused on Open Source. There are a few great articles by Jörn Nettingsmeier that I found useful, and hope others will read. I find it slightly sad that an Ableton producer has an article in here, while many other developers and community members of FOSS programs didn't submit (myself included). 11.3 Logiciels audio « open source » / Open Source for Audio Application

In other news, I can't wait for Ubuntu Studio's Karmic Koala 9.10 release on October 29. This release will have an official RT release version as a kernel that has proven quite stable in the latest beta reports.
I'll be playing October 22nd in Vancouver Canada, at the COPYRIGHT/COPYLEFT and will have a stack of Release Candidate images I plan on giving to friends. If you're in the Vancouver area and would like a copy, come by!

I'd love to see some community artwork developed for that release.

Ubuntu Studio Jaunty

2009-05-13T08:17:00.000-07:00

A couple weeks ago Ubuntu Studio released their 9.04 version. I'm sure you've all installed and begun to configure/tweak/adjust all kinds of settings (well those of you who didn't encounter the random freezing on the RT kernel that some have). I just wanted to give a quick update on a couple new features.

Calf plugin pack. I was able to get this package accepted for the Jaunty cycle, which won't be the only package I help Ubuntu out with. It's a multi-function set of plugins that will work as LADSPA plugins in any LADSPA host (ardour, audacity, jack-rack, etc...), LV2 plugins (once the LV2 standard catches on a little more), or inside their standalone host (which provides the nicest graphical interface right now). For their full documentations take a look at http://calf.sourceforge.net
However, I should note that there are a couple instruments included in the pack that may seem inaccessible to most. This is because the Calf plugin host takes JACK midi input rather than the older ALSA midi that most apps currently use.

Some of you may have already seen the new midi tab within qjackctl's connections window (or worse, had your soundcard on one tab with your programs on the other). Don't despair! There's a solution to bridge the JACK midi and ALSA midi! Introducing a2jmidid http://home.gna.org/a2jmidid/ it serves as a bridge between the two worlds. Infact, I've already built a package for Jaunty and it's sitting in my PPA repository at https://launchpad.net/~stochastic/+archive/ppa

FFADO drivers are now available from Ubuntu! Yes, that's right the world of firewire soundcards just got a whole lot easier. However Jaunty still ships with the old firewire stack, so configuring firewire permissions can be a touch tricky. For most, Ubuntu Studio Controls should be all you need to get things running (though you may find you need to add a 'video' group if one isn't already created). However, for some people who've upgraded into Jaunty rather than installing fresh, it seems Ubuntu Studio Controls doesn't properly set the firewire permission. If this might be affecting you, edit (with sudo permissions) /lib/udev/rules.d/50-udev-default.rules and add this line

KERNEL=="raw1394", GROUP="video"

save the file, (make sure you're in the video group) and reboot.

I've noticed with my Presonus Firepod that the MIDI from FFADO complies with the new Jack MIDI, so some legacy applications have required me to use the above mentioned a2jmidid program as a converter.

I should also make mention that Ubuntu Studio Karmic Koala is looking for more testers willing to do an install every month or so (on either a test partition or a virtual machine). Just drop me an e-mail at: afterthebeep a t gmail dot c o m and I'll include you in the discussion. It's looking like the new 2.0 firewire stack will be included in this release, so even less configurations will be needed, but more tests WILL be needed to start.

Copyleft Call for Artists

2009-05-12T20:49:00.000-07:00

Copyright/Copyleft
Vancouver New Music Festival 2009

:::Call for mash-up artists and sonic collagists:::
The 2009 Vancouver New Music Festival will focus on copyright and appropriation, and will be presenting musicians who have been working and reflecting on issues related to copyright/copyleft, using mash-ups and sonic collages and other approaches. We are looking for local musicians who would like to bring their contribution to the discussion. Selected artists will be invited to perform opening acts at the VNM Festival.

Please send a short bio, a note explaining how your work relates to the theme of Copyright/Copyleft, and a short sample of your work in mp3 format to:
giorgio@newmusic.org by July 15, 2009 .

As space is limited only a few artists will be selected for performance.

PureDataCon09

2009-03-09T22:05:00.001-07:00

I came across this, noticed the deadline extension to March 15th, and thought I should spread the word (as deadline extensions usually mean a lack of submissions).

PdCon09/CALL FOR WORKS:

PdCon09 is the "Third International Puredata Convention", to happen in São Paulo-Brazil/July 2009

EMAIL: pdcon09@estudiolivre.org

NEWS (feb 15th):

- Online Submission procedure is opening on monday 16th!!!

- New Templates and Forms will be posted when the submission is opened!

- WE HAVE A NEW DEADLINE FOR THE SUBMISSION OF WORKS, MONDAY MARCH 15TH OF 2009!!!

ABOUT THE EVENT:
Puredata, or just Pd , is an open source tool for multimedia programming. Because of its open source nature, much of its development result from a community effort of developers worldwide. Some centers do have more people engaged, like the places that held the two previous conventions.

the first convention took place in Graz, Austria, in 2004 http://puredata.info/community/projects/convention04/. The second happened in Montreal, Canada, in 2007 http://pure-data.ca/en/. It is a great satisfaction that we continue this event by bringing it to yet another continent, with the intent to promote the formation of an important group of developers locally. In fact, in may of 2008, we had a national convention in Brazil http://www.estudiolivre.org/tiki-index.php?page=Encontro%20PD, which followed the same format of the previous international conventions, and worked as a first gathering to organize this international event. The format includes the show of artistic works, academic works, discussion regarding the interests of the community, and diverse courses.

CALL FOR WORKS VS. 2.5 (FEB 15TH)

GENERAL CALL
We invite artists, producers, developers and further enthusiasts of the open source tool Puredata to send works and projects alike in the following categories:

A) Art Festival: (Art Installations, Concerts, Performances & Audiovisual Presentations).
B) Mini-Courses & Workshops.
C) Paper Sessions/Posters.
D) Round Tables & Discussions.

Applicants are invited to submit in multiple categories, especially if related (example: paper + artwork) - not that this will favor in the selection process.

Please note we are looking for a diverse collection of works, hence there might be a selection among several similar proposals (and more unique and original ones might have some advantage).

Let us know if you have an institution support that may cover travel expenses, we are looking for partnerships to help with funds.

The event will be held in Sao Paulo, Brazil, from July 19th to july 26th, 2009.

Possible (yet to be properly officialized) Locations & Partnerships:
- MIS, Sao Paulo's Museum of Image & Sound.
- PUC, School of Multimedia & Design.
- SESC-SP, Sao Paulo.

Promotional Support:
- CCSL (FOSS Competence Center) http://ccsl.ime.usp.br/

WE HAVE A NEW DEADLINE FOR THE SUBMISSION OF WORKS: MONDAY MARCH 15TH OF 2009!!!

Acceptance notice: APRIL 10th, 2009!
Here is the address to send works & questions to: pdcon09@estudiolivre.org

Addresses of the Official webpage for news updates & more info:
http://convention.puredata.info
http://estudiolivre.org/pdcon09

Proposals for the Art Festival:
Performances, Concerts, Audiovisual Presentations & Art Installations (audio And/Or Visual):
As it is the general concept of the event, we long for the discussion regarding the aesthetics and politics of Free / Open Source Software Culture & technology. In such context, we welcome all forms of works related to audio and/or visual, including real-time interactive works, improvisations, Live electronics/instrumental/electroacoustic mixes, Sound installations, Performances, Network art, Robotics, Software Art and Interdisciplinary works.

Demonstrations and General Info about Artistic works can be submitted online in Portuguese, Spanish, or English. Please, specify the necessary materials so we can do our best to provide them.

If language is a part of the artwork, the festival is open to any idiom, although subtitles in English should be provided when applicable.

We look for art installations that adopted Puredata in its development. Nevertheless, at the last extent, we are open for works realized under the context of Puredata (using puredata in some part of the process) as well as open source tools.

We are looking for partners to help us with tickets. Any suggestion is welcome.

Note for ART-INSTALLATIONS (Audio And/Or Visual):
In order to avoid dependence on travel funds from the event, it would be nice to have some works installed without the need for the artist(s) to be on-site. This also implies that such works should be technically simple.

Call for Posters/Papers:
Abstracts and papers may be submitted in English. The works will be organized in categories depending on what we receive. At first, we contemplate a greater distinction into 3 categories: Technical, Artistic and Theoretical.

The topics are generally open to the usage of Puredata in interactive art production/research, the philosophy and social aspect of Free Open Source Culture, and scientific research. Some possible themes could include:

- Programming Puredata externals
- Puredata versus Max/MSP
- Puredata versus SuperCollider, CSound, Processing and alike
- Hacking Puredata
- Future Projections for Puredata
- Hacktivist culture
- OpenContent and Creative Commons versus Intellectual Property forms
- Finding an Art Historical context for Open-Source Software Art
- Sampling and Plunderphonics as artistic strategies
- Computer-Supported Cooperative Work
- Networking
- Live Coding
- Philosophy, Culture and Sociology of Open Source Software and Open Works
- Aesthetics of New Media/New Technology Art
- Using Puredata in Science/Research & Artistic Works: (Digital Signal Processing, Generative Works, Artificial Intelligence/Life & Computer-Aided Work in General, User Interfaces - Human computer interaction/Virtual reality interaction -, Realtime Performance, Auditory/Visual perception and cognition, Acoustics/Psychoacoustics Modeling, Sound Synthesis, Timbre & Sound Models, Biological and medical uses of Puredata.

And so on...

Check Submission of Works for Poster & Paper guidelines

If you wish to send a Poster, the limit is 4 pages, other works are limited to 6 pages.

SUBMISSION OF WORKS:
Round Table and Discussions should be proposed on the puredata list:http://lists.puredata.info/listinfo/pd-list, to be discussed and decided upon previously by the community and participants in general.

The rest needs to be sent through our online system, with the provided Paper Template And Forms

The online submission is due to open on monday, Feb 16th of 2009, check http://convention.puredata.info for news and links. Questions about it must be sent to .

Poster Guidelines: 120cm height x 90cm wide

Papers are limited to 6 pages and must be submitted as PDFs.

If you wish to send a Poster, please send a short Paper limited to 4 pages.

We are studying the possibility of publishing the works online (both papers & Posters) in digital/hypertextual format s well as in a printed version with DVD-ROM.

---------------------

http://convention.puredata.info
pdcon09@estudiolivre.org

Beginner ChucK instruments & a cool book

2009-01-27T00:22:00.000-08:00

Well, I've finished an assignment for one of my music classes where I was asked to make three instruments (at least one using fm synthesis), document them, and use them in a composition. The class was a CSound based class, but I hate the rigidity of that language, so I convinced the prof (the one and only Barry Truax) to let me write in ChucK.

I've put them all under GPL and I'll publish the documentation under the GNU Free Document License. The reason why I'm blogging about this? Well, there's two motivations 1) I've yet to publish this stuff anywhere, so what's the point in a GPL license if I don't publish it 2) I think with the accompanying documentation, it's actually a nice intro for someone to learn about ChucK. Don't get me wrong, the ChucK documentation is quite nice, and I'm not about to claim you shouldn't read it if you want to learn ChucK, but seeing a slightly more extensive sythesis design algorithm might be a bit more of an idea starter for the beginner ChucKist.

So here's the documentation: InstDocs.pdf
Instrument 1: add.ck
Instrument 2: gauss.ck
Instrument 3: fm.ck

Oh, and I though I should also mention this wonderful new book that I have no affiliation with, but have been reading quite heavily recently. FLOSS+ART it's a series of essays detailing the changes that FLOSS has brought to Art. Don't miss the torrent link at the bottom of the page!

Lack of time / New PPA repo

2009-01-23T18:35:00.000-08:00

Hello to all you dedicated RSSers out in blogland. I know I've let my posting rate on this blog slip way off, but I do see a resurgence coming soon... But until then, I just thought I'd let everyone know that I've rigged up a PersonalPackageArchive at launchpad.net, and have begun packaging some software for Ubuntu. First off the block is the Calf plugins (Ladspa, lv2, dssi, and standalone) by Krysztof Foltman that I mentioned in a blog post a while back.

The PPA can be found at https://launchpad.net/~stochastic/+archive and will host packages (for now anyways) of Jaunty, Intrepid, and Hardy. It should be noted that these are NOT OFFICIAL packages and they come with no warranty of any kind - use at your own risk. But they seem to work fine so far. Please don't hesitate to let me know if you encounter any issues with it, or would really like a package built, etc...

Oh, and on another 'blowing my own horn' note, I've uploaded an icon set that I put together (mostly from J3Concept's artwork) to Ubuntu-Art.org. Here's the direct link: http://www.ubuntu-art.org/content/show.php/Humanitarian?content=92965 Maybe I should package it and put it into my PPA - or maybe I should concentrate on my schoolwork.

Intrepid Ibex is on its way...

2008-10-20T14:29:00.000-07:00

I recently had a major issue with my X server because I tried to get the 'big desktop' working by installing newer proprietary drivers for my video card (ATI Radeon Xpress 200m) - gdm refused to show up. As a result, and because I needed to get down to work on an overdue midterm paper, I decided that the spare space on my harddrive could easily use an install of the upcoming Intrepid Ibex (to be released on Oct 30th 2008).

I installed regular ubuntu because I needed something as guaranteed to work as soon as possible (installer & all) to get my paper draft up and running. But now that it's installed, I'm installing components of the UbuntuStudio suite as I go (the realtime .27 kernel isn't ready right now, so I've yet to really attack audio testing). This - if it remains stable - may just turn into my Ibex install, so I'm beginning to make myself at home, custom icon set and all.

So far it is quite a nice looking system. Compiz works out of the box (no proprietary driver needed for my - previously fglrx driven - card) and even comes with a few new effects (a cylindrical & spherical desktop cube, etc..). The UbuntuStudio gtk theme has nice looking blue circles as the minimize, maximize, close buttons; nicely shaded buttons; crisp lines; and a rounder looking edge to everything. The only thing that made me want to hurl was the default Ubuntu wallpaper and login screen - ugh!

The 2.6.27 kernel is quite fast, from my informal perceptions, but I'm curious to see if this new responsiveness carries through to the RT kernel once its released. There are also the slew of newer verions of most programs (Gimp 2.6, Ardour 2.5, Kino 1.3, etc...). Beyond that, there are a few basic changes to the logout menu, wireless network manager, and other meaningless items that some UI designer wanted to spend some time on.

The official writeups for Ibex talk about many improvements for laptop users, including the new Network Manager 0.7, an encrypted private directory inside your home, and a guest login option. There's also a totem plugin for BBC content that you can easily activate in totem's plugin menu.

Overall, despite the troubles the dev team has expressed over the .27-rt kernel, I think this release is a nice improvement that does Ubuntu proud and that I'm very happy running.

Goin' on a Bug Hunt (but I'm not afraid)..

2008-08-08T14:42:00.000-07:00

A great technique to schedule regularly in any home-studio is a bug hunt. Take stock of every piece of hardware/software that you have, and write down a few things about it. The list should include information like make/model, serial number (good for insurance purposes - in fact this list should then be stored away from your studio, preferably in another building or a safety deposit box), and any problems with it's functionality or how it's currently setup (is it production-ready, or is it tucked away in a drawer or case in the closet). Go through, classify each problem (bug) as: urgent, pretty important, somewhat important, just annoying, a potential issue, would be nice if... , or doesn't really matter.

It's good if the list is actually divided between hardware and software, as they involve very different bug fix methodologies. Some people are very good at fixing hardware bugs, but have no clues when it comes to a software problem - others are the exact opposite. The next step for the bug list would be determining the source of the bug; this can't always be done terribly easily, but often the harder to find sources are more educational to the bug hunter (you), revealing information about how a piece of your studio operates under the hood - always useful information.

Once the source of the problem is found, the next logical step is to evaluate how easy it would be to fix; will it cost thousands to repair that circuit in your house's wall, is it merely a loose cable that a quick solder would fix, is it a fundamental code structuring error, is it a software bug that's been fixed in newer versions, etc....? The cost of repairs should also weigh into your mind at this point as some broken equipment just isn't worth fixing, often because it's not something that would be used if it were fixed, or because a repair would cost more than buying a newer (possibly better) model. For those with hardware problems, and little knowledge of home repair, most music stores would be happy to trouble shoot it with you. For those with little software experience, many pro coders will offer free troubleshooting on the appropriate forums, mailing lists, and IRC chat rooms.

In most circumstances a large portion of the bugs you find will be readily fixable, but there will inevitably be a couple bugs that just can't be easily squashed. Sometimes the bugs are inherent to the product (a microphone with a bad response curve could be said to have a bug). I don't consider those to be a lost cause because though identifying the source of them, and realizing that it can't easily be fixed, you're educating yourself in regards to your studio's weaknesses. In future projects, you'll know where those bugs are and you'll be able to skillfully avoid them rather than running headlong into them at the last minute.

This process is also lends itself to a reorganization/cleaning of your studio. You may stumble across a piece of hardware you've forgotten you had, or realize that a particular piece of software that never booted properly before now is working great. Lastly, if you come across any bugs in open source software (or closed source for that matter), you should help the community by reporting them - even if you've already found a fix (report that too!) or have no idea if it's even possible to be fixed - the software developers will be grateful for the bug reports.

The only downside to this process is the time it takes (but I'd argue it actually saves you time in the long run).

Indiamixx portable studio launched

2008-07-31T17:34:00.001-07:00

So it's always nice to see linux and open-source tools being incorporated into, or used as the basis of, new commercial audio tools.

On July 21st, Trinity Audio Group (a Washinton State, USA based company that specializes in portable recorders) announced the arrival of Indamixx a portable studio running on a 64Studio-based linux OS called Transmission. Trinity Audio Group released a similar - but with less features - product back in 2006 called Trinity.

Indamixx looks very sleek with it's 7" 1024x600 touchscreen display, full qwerty keyboard, and 8-way joystick. It has a variety of software pre-installed (Ardour, EnergyXT, Hydrogen, Audacity, Mixxx, ALSA Modular Synth, Gnome CD Master, Rythmbox, Seq24, ZynAddSubFX, VSTHost, IDJC - a personal internet radio broadcaster, Mplayer, Virtual MIDI Keyboard, Audio CD Extractor, 260 LADSPA plugins, gFTP, Skype, Pidgin IM, Transmission BitTorrent, and Epiphany web browser) that all showcase the open-source software world (except for EnergyXT and skype). It's also nice to see VST support offered, though I wonder how complete that support really is.

As for hardware specs, it's processor is a Samsung Q1 Ultra, with 40GB hard drive space, Wifi (802.11g), 2 USB ports, VGA output port, built-in microphone, and speaker. I couldn't find any soundcard specs on the Indamixx beyond sample rates of 16-bit, 24-bit, and 32-bit at 44.1Khz, 48Khz, and 96Khz. However its predecessor, the Trinity, used an Echo soundcard, so my guess would be that they've stuck to the same company. It would be nice to know if it has 1/8", 1/4", or XLR inputs/outputs, or for that matter if there are any inputs/outputs at all (the youtube videos of it do show a 1/8" cord plugged into the top).

Overall this looks quite nice, and I would love to get my hands on one to go sit at the park and write songs with. It is also a very competitively priced unit (at $999US special introductory pricing) in comparison to other hard disk recorders especially so if you consider the interfaces and built-in software of other hard disk recorders. Furthermore, with the wifi capabilities and internet radio software, this mobile computer really is an impressive beast. The only thing I wonder is if people would rather go out and buy a laptop with better performance, and more capabilities for the same price? I think this is a great looking piece of hardware, and would love to write a more detailed review if they were to send me one - hint, hint. ;)

Anything you can do (in Max), I can do better (in PD)

2008-07-29T22:56:00.000-07:00

Toronto-based Interaccess Electronic Media Arts Centre held Anything you can do (in Max), I can do better (in PD) a grudge match between Max/MSP and PD-extended this past July 24th. For those who have never heard of these two audio programming environments, this may not be that interesting, but you should know that the open source PD-extended was the victor. Mind you, the PD team were two people (complete with Mexican wrestler masks and bottles of beer) whereas the Max/MSP team was one guy (in a dress shirt).

The six tasks consisted of creating a buzzer, creating a scoreboard, creating an applause-o-meter, move a clip-art kitten across the screen, make the clip-art kitten dance(,dance,dance), and teaching a new user how to build a patch to make an on-screen image change. And, to directly quote from NowPublic.com (since I read most of my info from there) :

The final event was a game of Pong, in which each team had to build a paddle powered by external input. Max/MSP's kitten-paddle was driven by a scream-o-meter. Pd-dextended's old-school paddle was driven by a piezo-enabled teletubby toy. Yes, someone had to spank Tinky-Winky in order to play the game.

It looks like it was a pretty interesting time from the clips, photos, and write-ups I found:
http://www.interaccess.org/blog/?p=731
http://www.flickr.com/groups/interaccess/
http://www.nowpublic.com/tech-biz/anything-you-can-do-i-can-do-better-midi-software-duel-5

It's good to see that a collaborative open source effort like pd-extended can win in a competition of tasks ('cause who really cares how pretty your programming language is anyway) - even if it was 2-against-1.

A couple quick links

2008-06-30T23:29:00.000-07:00

Sorry for anyone looking for a post in June, I've been a touch busy. But for those die-hards, here are a couple links I've been fortunate to come across and would like to share with you.
The first is a nice UbuntuStudio-based blog I found http://briansbedroom.blogspot.com/
The second is a nice package of extra plugins that haven't yet been packaged for Ubuntu http://calf.sourceforge.net/
The third isn't really a link, but rather a new beta release of the ffado firewire audio driver that I've been test driving, and very pleased with. It takes a bit of work to install it (compiling from source, then compiling svn version of jack), so those new to linux audio should wait for it's full release (should be fairly soon), but advanced users should go take a look at http://www.ffado.org/
Next month I will be a bit more active with the posts, I've already got a few brewing.

Musical Programming Languages

2008-05-30T22:55:00.000-07:00

Musical programming languages are a strange breed of flexibility and usability in the computer music domain. There's actually a long history of musical programming languages (in the context of programming in general) that recently has been seeing a surge of popularity among the arts community. C++, we all would agree bears very little usage bias, while CSound is obviously not a good programming language to check your e-mail with. C++ may be perfectly capable of creating the same results as a CSound program, but the initial knowledge level required to do so is a vastly different range.

The major (read most-popular) open-source audio programming languages are PD (pure data), CSound, SuperCollider, and ChucK. Each of these languages have their own strengths and weaknesses and some are easier to learn than others. For most musicians PD will be the most appealing with the smoothest learning curve as it is the only graphical language of the four. ChucK and SuperCollider are much closer to "real" programming languages in their syntax. CSound is the oldest of these four, with roots from back when you'd write a computer score, set it to compile, and come back three days later to hear your audio file. Because of this, CSound is a very powerful synthesis engine that was written with computational resources in mind.

Many musicians will never need to learn a music programming language, but recently more and more artists are turning to programming languages to give the extra flexibility their project requires. A few possible applications include; using a wii controller to adjust a synthesizer's settings; building your own ultimate modular synthesizer; altering a live signal with a complex chain of adjustments - each of which are manipulated on the fly; trigger effects on/off based on the frequency of the input signal; building audio effects not otherwise available; generating algorithmic melodies, rhythms, etc..; extending the functionality of your favourite program; creating your own custom-designed software; or working with homemade hardware controllers (linux hackers get excited about this stuff).

These are all good reasons for using audio programming languages, but there are some common downfalls to creating these custom audio apps/plugins/tools. The first and most obvious is that the time spent coding the tools quite often overshadows the usefulness of the resulting tool. Many gear-heads fall into this trap when they first learn to program in PD, as they realize that nearly anything is possible so they try to do everything. This could be argued to be comparable to the amount of time/money gear-heads spend on buying hardware in comparison to their actual musical output. The second is that most musicians aren't computer programmers. This may sound like an obvious statement, but it's also a serious problem in music programming languages. The software that musicians develop is more often than not: VERY buggy, inefficient, half-finished, unportable, not documented (not even comments in the code), and essentially broken in design. Because of this, nearly all of the software musicians write becomes a one-off, non-distributed tool that even the creator soon refuses to use (often after the first performance) - in the software world these are called "dead projects" and are seen as massive failures. Even the software some of my university professors - who get grants to write them - create, will be prone to these pitfalls, and it comes down to musicians thinking like musicians rather than programmers; though some musicians will claim they make more musical tools that way. There are exceptions to these faults, but they're unfortunately exceptions and not the norm.

Now that you're aware of these pitfalls, you're one step ahead of the average musical programmer, and you can avoid them in your own code; right? Okay, the I guess I can teach you a bit of programming now.

PD is the easiest for a beginner to stomach because of both it's visual element and it's patch-cord based interface that resembles musical hardware routing. I wrote a quick beginner's tutorial for PD a while back that has been incorporated into the Ubuntu Community Documentation here: https://help.ubuntu.com/community/HowToPureDataIntroduction and I don't want to repeat myself.

#####********* IF YOU KNOW NOTHING ABOUT PD, STOP NOW AND GO READ THAT LINK ********######
At the end of that tutorial I had promised some further examples, so I guess I should deliver. The first thing I'll touch on is the ability to create an abstraction. This is thoroughly explained in the PD documentation so if you're lost after this, go take a read there. Essentially an abstraction allows you to package PD code into a custom named PD object for use in other patches. This feature is invaluable for PD programmers. Without abstractions, code would become a rats nest of patch cords quite fast, and each patch would be a one-off code snippet - preventing any real software development. Abstractions allow the programmer to clean up the code, easily re-use code snippets, and speed up their coding process.

By encasing a mundane (yet laborious) set of instructions into a single abstraction, anytime those instructions need to be called, it's simple and elegant to create a new object and call the abstraction's name. To create an abstraction simply save your pd patch as examplepatch.pd, then open 'Path...' from the File menu, enter the folder that your abstraction was saved to (you may want to save the settings), then open a new patch and create an object named examplepatch. To see the original code, right click on the new object and select open.

You can send data to and from these abstractions in two different ways. The first is to use "inlet", "inlet~", "outlet", and "outlet~" objects in the abstraction's code. These will allow you to connect patch cords to and from your abstraction. This method is simple and best for beginners. The second method involves the "send", "receive", "throw~", and "catch~" objects. These all take a name for an argument that will point to the send/receive/throw~/catch~ object that's giving/receiving the data. The upside of the send/receive method is its flexibility, whereas the downside is that it allows you to loose track of signal flow quite easily - particularly when multiple signals are going to the same place or vice/versa.

This encapsulation of a code snippet is an essential element of the Object Oriented Programming style. This style is a very prominent code writing method in modern computer programming. I'm not computer scientist, so I won't attempt a definition for you here, but I will tell you that PD is designed to use the OOP style. By coding a snippet such as a soundfile looper, then saving it as an abstraction, you'll be able to reuse that code chunk to make life easier when you go to build your ultimate sampler, and again when you want to incorporate sampling into a custom-built guitar processor. Abstractions can be nested inside one another too, allowing for very complex patches to be organized very efficiently.

I'll end by saying that PD is a wonderful beginner's programming language that can accomplish quite a bit, but it does have its limitations. For a VERY detailed read on PD, I'd recommend Miller Puckette's (the man who wrote PD) new book The Theory and Technique of Electronic Music, available as a free download online. The other three music programming languages that I mentioned at the top of this post should also be explored by those who have a penchant for flexibility and power (my personal favourite is ChucK).

Compression for beginners

2008-05-14T22:02:00.000-07:00

Dynamics processing is a dangerous but essential beast in audio processing. It is also one of the most important effects in the mastering process of a song. But before we begin, I must refer you to the problem with over-compression:

Ear-fatigue and excessive loudness as described by turnmeup.org

Dynamics processing (compression/limiting/expansion/gating etc...) is an essential tool in getting the right mix of sound, but if abused, can totally ruin the listen-ability of a track or album. Don't think that louder is always better, monitor your songs at different volumes (via your amplifier volume control) before deciding on your final settings.

Ok, so now that that's out of the way, I can introduce the wonderful things dynamics processing can do for you. The most common, is to increase the presence of dynamic midtones.

I once heard an explanation of a compressor as a man sitting at a volume knob, auto adjusting the signal's gain, based on how loud the incoming signal is. This is a neat little visual that helps beginners understand some of the settings.

Compression is the most commonly used form of dynamics processing. In the LADSPA set, there are a number of compression plugins: SC4 (as well as the other SC numbers), SE4, TAP Dynamics, Dyson Compressor, C* Compress, and Simple Compressor. There's also the compressors inside JAMin that have specific frequency bands, along with many other mastering tools. For now, we'll look at SC4, by Steve Harris, for the example as JAMin's tools deserve a full post on their own. Here's a look at SC4 hosted in Ardour:

Compressors track the amplitude (either sample level or RMS level) of the incoming signal and adjust the output volume according to it's settings. Quite often the compressor's settings are pictured as a dynamics graph. Unfortunately, no LADSPA plugin has done this as it is quite helpful for beginners to understand things, and for novices to see the settings (I don't think it's even possible in the LADSPA language). However, JAMin does have some nice graphs for its multiband compressor (see below):

The graphs can be read with the incoming level on the x-axis, and the corresponding output level on the y-axis (the thick black horizontal line is 0db). The red graph shows no change to the sound, while the other two have similar characteristics (though the green has more makeup gain and a sharper knee).

The most important setting on a compressor is the threshold level. This sets the threshold db level for the compressor to begin lowering the gain. The red graph has a threshold of 0db and therefore is never triggered to begin turning the volume down (though other settings also need to be set properly for this to truly occur). The threshold can be most clearly seen on the green graph, though the same threshold setting was used on the blue one. It is essentially the joining point between the two vectors of gain settings.

The knee setting on compressors can be seen best in the blue graph. It softens the joining point between the two vectors. SC4 has theirs labeled as the knee radius in db, which can be visualized better if you imagine a full circle nestled into the threshold as tight as it can go. A softer knee (i.e. a larger knee radius) will effectively give you a decrease in volume (more compression) around the threshold area and an overall smoother curve to your compression (but less precision on the threshold point).

The ratio could also be argued as the most important setting on a compressor; it determines the ratio at which the signals above the threshold are compressed. A ratio of 1:1 would nullify the compressor - what comes in is what goes out (the red graph could be achieved with this, though I did it with a threshold of 0db). A ratio of 2:1 means that for every 2db increase (from the threshold) in the incoming signal the increase will be cut to 1db in the output. The ratio on the green slope is about a 4:1. Graphically, the ratio is the inverse slope (i.e. 2:1 has a run of 2 and a rise of 1 - and slope is rise over run 1/2).

So far all the compressor has done is turned down the volume during the loud bits, which makes the overall mix quieter. The makeup gain is there to boost the signal back to a healthy level. A good rule of thumb is to always have a similar volume level coming out as you had going in (though not exactly), this helps the ear understand what the compressor has actually done to the sound as music is perceived differently at different volumes.

Attack and release times are the speed at which the little man inside the compressor reacts to the incoming signal in his changing of the gain knob (attack being how fast he turns it down after an attack is sensed, release is the other way round). These settings allow for fine tuned control over the sound, such as allowing the attack transients through. Attack settings will limit the amount of makeup gain you can have without your attacks clipping, so watch out. Release settings should be used where the instrument has a slow release time itself.

The SC4 compressor has a nice feature of RMS/peak mix. This allows you to select the mix between RMS or peak envelope following. RMS is generally a more natural sounding compression as its values are closer to what the human ear perceives as loudness. Peak values are more useful if you're wanting to decrease sharp spikes in the sound source.

Lastly, but not least is the sidechain input that can be found on some compressors (such as SC2 and SC3). What this does is allows you to control the gain of a particular track (just as you would in any other compressor) but with a separate input source providing the gain reduction control (i.e. the little man is listening to an entirely different track - the sidechain input - adjusting the gain accordingly, but he's effecting the track he's not paying attention to). This effect is most commonly used in electronica where the kick drum needs to be very prominent. The bass line is compressed with the kick drum as the sidechain input, allowing the kick drum to stand out as the most prominent low-end instrument without having the bassline whimper away.

This covers the basics of what compressors do, but by no means gives you an explanation on how to effectively use them (I shudder to think of the over compressed songs that will now be created). Some of the only parting words I can offer is that less is more.... LESS IS MORE. Don't kill your dynamic range just to make things sound louder - your listener will just turn the track down and all you've done is squash the waveform to a pulp. Play around, and when you think you've got it right, reduce the settings a bit; less is more.

Netlabels

2008-05-10T14:14:00.000-07:00

So my blog's subtitle is vague enough that I can safely stretch the subject matter of my posts every now and then. Today, the open-source phenomenon of a netlabel is my subject.

The netlabel is an online record label. Quite often, netlabels give their music away for free and could be seen more as a promotional tool than a money-making business. The most common netlabel is the Creative-Commons licensed netlabel, as the freedom associated with the Creative-Commons license allows for easy distribution of artists music.

The Internet Archive is a wonderful resource for netlabels; it catalogs and backs up the offerings of netlabels on a regular basis (some even utilize it as a hosting service). Furthermore one can search through the netlabel section of the IA at the main netlabel page: http://www.archive.org/details/netlabels though its services are only available to Creative Commons licensed labels (for obvious legal reasons). Their listing also gives a nice means of estimating the growth in the netlabel trend; the number of "sub-collections" can be translated to be number of "labels" and the number of "items" is the number of albums (of any length) released. As of this writing there are 896 "sub-collections" and 12,788 "items"; I read an article written just over three years ago, that claimed the numbers were 170 and 3,000 ish - which gives a bit of perspective on the growth rate of the netlabel phenomenon.

The benefit of Creative Commons music freely available online is huge. Radio producers can use them as backing-tracks for any commercial, movies can use them as soundtracks, etc.. without worrying about the royalties and legal issues normally involved. Also, these songs are available for other artists to utilize as a vast array of sampling options in their own music. Of course there are various versions of Creative Commons licenses and not all allow for commercial use of the song without the artist's consent. But, most importantly, music is becoming a legally shared commodity and artists are realizing that money isn't what they do this for - more would be happy to reach thousands of people than to earn $20 for selling thousands of iTunes downloads (just an exaggeration - not actual earnings numbers). In my personal opinion art should be open for people to hear/see/experience it, though I also realize that financial restrictions are a part of life.

A few labels that I personally enjoy and listen to regularly (your tastes may vary) are:

Sutemos - a somewhat avant garde, but high-quality, electronica label from Lithuania.

20kbps - a genre-defying label whose acceptance requirement is that every song needs to be encoded at 20kbps or less. I don't enjoy all of their stuff, but some is brilliant (this may just be the computer audio nerd in me appreciating the worship of lo-fi).

CCMixter - probably the most famous netlabel (soulseek records might also take that title), it's full of various genres and quality artists. It's major interest is not in releasing an end product, but rather in the continuing evolution of their projects and songs.

Clinical Archives - an avant garde, experimental label, open to all forms of sound art. They have a fairly extensive collection from many talented experimenters.

EVIL Records - an electronica label based in Spain. They don't have many releases, but they're fairly good.

Rhythms with Hydrogen

2008-05-04T00:31:00.000-07:00

So today I'd like to run through the features of my favourite drum machine. Okay, so it's not actually a machine, but rather a piece of software that slaughters any drum machine I've ever seen.

Hydrogen is a well developed soft drum kit for Linux (I'm running version 0.9.3). It features a fully configurable pattern editor, a song editor, a mixer, an instrument editor, and a drumkit manager. The pattern editor and song editor are both fairly straightforward and fully configurable. Beginners should take note of the song editor's select mode, which can be toggled in the buttons above the pattern names; this allows for much quicker editing. The pattern editor allows you to either enter a pattern manually or record a pattern with either a MIDI device or Hydrogen's built in keyboard bindings:

The mixer has a couple nice features; the humanize controls for both velocity and timing, as well as the four LADSPA effect inserts that have sends from each instrument channel. The instrument editor is where I think Hydrogen shines. It allows up to 16 simultaneous layers of samples to be used per drum, contains an ADSR envelope control, a lowpass filter with adjustable resonance, a random pitch percentage, and a manual pitch control - FOR EACH INSTRUMENT. Finally, once you're done tweaking all these settings to perfection, you can save your instrument settings as a drumkit. The drumkit manager allows easy switching between saved or downloaded drumkits (see Hydrogen's website for free downloadable drumkits).

One of the few options I wish was available would be relative tempo changes, as currently the only solution is to manually program the slower/faster tempo sections of any song to fit onto a pattern that internally is still running at the global tempo setting. This is a bit of a hack that I would rather not have to bother with.

All this is nice, but more than just software is needed to make good rhythms, you need to know a bit about anticipation.

Musically, any event that's repeated three (or more) times will be expected by the listener to continue being repeated. This even applies to non-audible pulses. One of the key features to any good beat is how it plays with this anticipation factor. Some beats emphasize the anticipation and build up toward the expected repetition, others use the anticipation to throw the listener off (usually considered a break-beat if it's repeated as part of the rhythm).

I should note that three is not a common pattern size in most music, the average song uses four (duh). This is called duple meter (things can be broken easily into two), and usually the overall structure of the bar phrases, song sections, and micro-rhythms will relate to the duple. I've heard it explained that three is the minimum number of repetitions to set up a pattern, five starts to get too long, so four is just right.

When writing your rhythms, consider where your listener's micro, macro, and normal anticipations are being drawn. If you've been focusing on downbeats and suddenly switch to an upbeat focused pattern, you'll be messing with their heads a bit (it's kinda fun to mess with people's heads sometimes, but they'll get pissed off if it happens too much or unpredictably). Overall, try to find a balance between predictable and unexpected so that everything remains interesting.

UbuntuStudio Sound Servers

2008-05-02T03:58:00.000-07:00

Sound servers in Ubuntu have changed for this release of Hardy, and it's confusing some. This is a post I made on Ubuntu Forums, to explain the current situation a little and I thought it deserved to be posted to this blog as it may help some people who are just getting started, or freshly confused with this new PulseAudio thing:

Well the simple answer to most of your questions is "variety is the spice of life".

when entering the field of audio recording, there are those who want to talk to their grandson on voip/skype, and those who want to master a CD of their choir/orchestra/rock band recording; oh and EVERYONE in-between. There CAN'T be a single button solution.

Unix/Linux kinda takes pride in the fact that there are so many versions of the systems available in nearly every aspect of the software ladder (or attempts at such). The fact that all of these various systems exist, gives the other programmers choice of design and execution method. Some are more robust, some are faster, some are simpler, and some are dead/dying.

-ALSA, for example, is Ubuntu's default go-to sound driver. That makes things do ding when you login, plays movies, etc... for most, this will suffice as their sound.
-OSS is not used by default on many (I'm not really sure about the exact accuracy of this, but I know it's general truth) or any audio apps in Ubuntu, but it's there as a legacy system that ALSA is nearly entirely compatible with (I'm no developer, just a user).
-Jack is the server best suited for rich and hearty audio WORK with your computer. Think of this as a really great... (insert excellent hot rod analogy car here) where the one who works with that car(d) can tune it just how they need to make it purr.
-Pulse Audio is the new guy on the block for Ubuntu, which allows communication to the same soundcard from various different other sound servers at any given time. (i.e. Ardour can still be on, running jack, while you pause to listen to a firefox youtube video. This wasn't possible prior, as Jack's compexity {/* developers, please read as 'robust' */} was preventing general app developers from adopting it as a output choice in their apps) Think of it as a really crazy multi-adapter for all your sound plugs in the virtual world.

I also did a bit of digging for the original thread starter and learned what a mux was from wikipedia: http://en.wikipedia.org/wiki/Multiplexer and now I know where that most exellent local electronic music producer gets his ever so appropriate moniker.

My working methods

2008-05-01T13:36:00.000-07:00

To start things off, I'd like to give a quick rundown of my usual working method with audio. For the most part I utilize sound samples and recordings as my means of composition (we'll call that music concrete style work), though I'm getting further and further into synthesis techniques everyday now. I also regularly write acoustic music using lilypond (no GUI, just hard coding straight into lilypond), but even then I'm inclined to sample/quote other music in my creation process. I personally think my inclination for twisting samples stems from my DJ roots.

To record things I generally either use Ardour or Rezound though there are tons of different recording apps loaded onto my computer (not to mention the audio programming lanugages that can all be used to record). If I just want the audio file as a sample Rezound is much faster and simpler to use, but if I know what I'm recording is going to end up in an Ardour session anyway (such as if I'm recording soundscapes etc...) then I'll record straight into Ardour.

Rezound's editing capabilities are quite nice. It gives remarkable feedback for clipped samples (a bright pink bar against the blue/green background); even if it's just one sample that's clipped, it will be visible at any zoom ratio. During recording, it's dialog gives a count of the number of clipped samples as well as a very responsive volume meter. It also comes with many essential wave editor functions such as mix paste, resample, curved gain, LADSPA plugin support, various looping playback modes, and a bunch of built-in effects, such as a convolution filter and morphing arbitrary FIR filter (essentially a parametric eq that can change over time). These don't quite give the same flexibility that Ardour's LADSPA features do, but for a wav editor I'm VERY happy with rezound. Furthermore it can function perfectly fine without jack running, which is nice if I ever run into troubles with jack (or freebob for that matter).

Ardour should need no introduction. It's the behemoth of the linux audio world - better than pro tools in my opinion. It's octophonic mixing capabilities are one of my current favorite features as SFU regularly allows me access to octophonic performace spaces. With it's ability to automate LADSPA plugin settings, not to mention it's ability to host them in nearly any combination imaginable, nearly any sound needed can be achieved. Generally I use Ardour as my music concrete composition tool, arranging and tweaking samples as I see fit. I then use it's export feature to bounce everything down to a wav output file or perform it live through my soundcard (a Presonus Firepod) depending on the situation.