I've been discussing my foray into programming again. There were times when I questioned this decision...mostly as I re-discovered the reason people write about best practices in programming and application design while getting a better grasp on the thought behind some of the questions asked on the programmers Stack Exchange site.
I'm nearing my self-imposed deadline for a beta (well, alpha release is probably more accurate) before I cut this project loose and start moving into something new. And of course, I ran into a glitch during what was supposed to be a simple feature addition.
What was supposed to be a simple sample program had become a bit of a mishmash in goal alterations, so the simple thing I originally mapped out in my head was now a little more complicated. How was I going to troubleshoot this problem?
I did it in what is probably the hard way. I would place messages in various spots along what I had traced to be the application's flow of logic. If it were about to call a subroutine, I placed a message box with a diagnostic message so I'd know that the program had hit that particular area of code and, when appropriate, it had diagnostic information about the state of a particular variable.
This way of thinking probably goes back to my first programming experiences using environments like the built-in BASIC interpreters in the Commodore and Apple II. Even when I graduated to QBASIC-esque variants there weren't many great options in debugging; later, in college, I was working in C++ IDEs where debugging facilities had improved, but we rarely worked with them. Instead the assignments tended to be small and inserting hand-made breakpoints into the application meant getting the assignment completed in time and in usable shape.
There wasn't really any emphasis on using the debugging tools.
I suppose at some point the idea of inserting code that let me know what was going on at certain points in an application became a "cross platform" way to debug a problem. I didn't have assignments or projects so large that specialized tools were necessary, and even if I did need to run a tool for debugging, I was afraid to invest a lot of time into learning a tool that would only work with one environment on one platform. It makes me relive memories of support issues past when we had people flip out because a menu changed in a new release of Office; they became dependent on the clicks to accomplish a goal rather than the skills to navigate to the feature they're seeking.
At the same time...like when I was creating this application...there were points when I wished I could easily have the IDE step through each line of execution so I could see what exactly happened at each point in execution flow. And part of me thinks this has to be built in to the Visual Studio IDE and is blatantly obvious to seasoned programmers...there's just so many buttons that by the time I figured out how to do what I wanted to do, I'd probably have solved my problem three times over using my rudimentary system of debugging.
It occurs to me that I hadn't run into a case where debugging tools were taught, required, or demonstrated. "Insert code here to tell the programmer what is happening at this point" was portable...it works in compiled and scripted applications and in most languages...and seemed rather intuitive.
So how much am I missing in approaching debugging this way? Is this even a legitimate method used by professional programmers?
Is there a decent tutorial for a preferred method of debugging, or how to approach debugging? Or is debugging another skill acquired with experience?
I suppose I should fret over this more, but my next project will involve playing with some Ruby on Rails; Visual Studio's built-in debugging tools will probably not be of much assistance there. I suppose this also means having to figure out a different way to debug applications with the change in platform...
Thursday, December 26, 2013
Thursday, December 19, 2013
Releasing Your (Software) Projects...Self-Imposed Feature Creep
I've been working on my proof-of-concept VB.Net program for awhile now...
It started as a curiosity, a toe-dip into the pond of testing my rusty brain. I wanted to experiment with something that had been floating in my head a little while.
For the most part I got the core of the application down. It's simple. There's a lot of room for improvement, granted, but it was relatively simple. And I really need to test it out, once I get one more piece of behind-the-scenes functionality implemented.
See, that was part of the problem. Even though this was supposed to be a neat little proof-of-concept test application for me to take a concept and make it work, I still ran into bumps where I ended up wanting to tweak it a little more. I only worked on it a little bit at a time; usually an hour or two after work a few nights a week. Which isn't optimal for the way my head works. I usually need a large block of time dedicated to sorting through a problem and figuring things out; but if I wanted to get to work in the morning feeling like more than a zombie, I had to get to sleep at a decent time. So that kind of limited my time spent on the project.
Then there is the podcast. I currently spend an hour recording, around the end of the workday, the audio material. Then I typically spend an hour and a half to three hours total going through the material, editing it, taking notes, and getting it posted to the feed site on Tuesday so it will be available to my meager audience on Wednesday. That takes about two nights off my "available for hobby" schedule.
Every time I got close to feeling like, "Eh...it's good enough for government work..." I come up with one more thing I want to investigate or tweak. Some design ideas I abandoned from what I originally had in mind...usually because of time, or the thing I wanted to do just wasn't of high enough priority to make that particular item worth pursuing.
Little tweaks kept calling me, and given that I'm rustier than the Tin Man after a rainstorm, it takes me longer than it should to put a tweak in place. I'm even more handicapped when I insist on doing it in discrete blocks of time after work a few days a week. It was supposed to be a small proof of concept thing...not a full on project!
Thus was another lesson in software projects. Without the mapping and specs pre-mapped, as I've mentioned before, you end up feeling like you need to keep altering and tweaking the program ad infinitum. You need a set of goals lined up so that at some point, you just say, "It's done." Maybe it's not really done, but it's met the spec.
Of course part of it is, no doubt, embarrassment at how it would be received, since no serious programmer uses VB.Net (of course.) I'm not entirely sure why this is, since .NET languages largely compile down to a common language runtime (which is the whole point of .NET as I understand it...) so...maybe it's a fear of the culture. A side effect of working with smart people is feeling like you're always one or three steps outside the pack.
I need to move on to one of the projects I've been wanting to use for learning Ruby, which means I needed to come up with a deadline to stop this current experiment. I decided that there is one last thing I wanted to try to get working, and after that is finished I'd show it to my manager for a bit of a constructive criticism. My deadline will be the new year. I'll take my system home with me over the holiday and work on the last feature, then come the new year send it his way to have a look.
It'll be a mess, no doubt; I have no illusions that it did things "right" all the way through. I really should have focused on using classes to implement part of it rather than my mangled hard-coded approach. And there are definitely parts that could have used more error checking.
On the other hand, it was the first time I'd approached a programming project in some time. And the end result was that the basic idea, the basic functionality, worked. Given more experience and time it probably would turn out better. I really need to keep working at it to develop better habits and solve more problems, and I need to move on before everything becomes an excuse to procrastinate. Then nothing will get accomplished.
To try keeping myself on my self-imposed deadline, I asked my manager if he could take a look and offer some constructive feedback come January; having someone else know about it might help keep me on my timetable. So there it is. Over break, I'll spend some time polishing it slightly, then test it out, then have it reviewed by someone in a position of experience to tell me how full of blech it is.
Then I can move on to the Ruby tutorials and create a whole new type of blech.
It started as a curiosity, a toe-dip into the pond of testing my rusty brain. I wanted to experiment with something that had been floating in my head a little while.
For the most part I got the core of the application down. It's simple. There's a lot of room for improvement, granted, but it was relatively simple. And I really need to test it out, once I get one more piece of behind-the-scenes functionality implemented.
See, that was part of the problem. Even though this was supposed to be a neat little proof-of-concept test application for me to take a concept and make it work, I still ran into bumps where I ended up wanting to tweak it a little more. I only worked on it a little bit at a time; usually an hour or two after work a few nights a week. Which isn't optimal for the way my head works. I usually need a large block of time dedicated to sorting through a problem and figuring things out; but if I wanted to get to work in the morning feeling like more than a zombie, I had to get to sleep at a decent time. So that kind of limited my time spent on the project.
Then there is the podcast. I currently spend an hour recording, around the end of the workday, the audio material. Then I typically spend an hour and a half to three hours total going through the material, editing it, taking notes, and getting it posted to the feed site on Tuesday so it will be available to my meager audience on Wednesday. That takes about two nights off my "available for hobby" schedule.
Every time I got close to feeling like, "Eh...it's good enough for government work..." I come up with one more thing I want to investigate or tweak. Some design ideas I abandoned from what I originally had in mind...usually because of time, or the thing I wanted to do just wasn't of high enough priority to make that particular item worth pursuing.
Little tweaks kept calling me, and given that I'm rustier than the Tin Man after a rainstorm, it takes me longer than it should to put a tweak in place. I'm even more handicapped when I insist on doing it in discrete blocks of time after work a few days a week. It was supposed to be a small proof of concept thing...not a full on project!
Thus was another lesson in software projects. Without the mapping and specs pre-mapped, as I've mentioned before, you end up feeling like you need to keep altering and tweaking the program ad infinitum. You need a set of goals lined up so that at some point, you just say, "It's done." Maybe it's not really done, but it's met the spec.
Of course part of it is, no doubt, embarrassment at how it would be received, since no serious programmer uses VB.Net (of course.) I'm not entirely sure why this is, since .NET languages largely compile down to a common language runtime (which is the whole point of .NET as I understand it...) so...maybe it's a fear of the culture. A side effect of working with smart people is feeling like you're always one or three steps outside the pack.
I need to move on to one of the projects I've been wanting to use for learning Ruby, which means I needed to come up with a deadline to stop this current experiment. I decided that there is one last thing I wanted to try to get working, and after that is finished I'd show it to my manager for a bit of a constructive criticism. My deadline will be the new year. I'll take my system home with me over the holiday and work on the last feature, then come the new year send it his way to have a look.
It'll be a mess, no doubt; I have no illusions that it did things "right" all the way through. I really should have focused on using classes to implement part of it rather than my mangled hard-coded approach. And there are definitely parts that could have used more error checking.
On the other hand, it was the first time I'd approached a programming project in some time. And the end result was that the basic idea, the basic functionality, worked. Given more experience and time it probably would turn out better. I really need to keep working at it to develop better habits and solve more problems, and I need to move on before everything becomes an excuse to procrastinate. Then nothing will get accomplished.
To try keeping myself on my self-imposed deadline, I asked my manager if he could take a look and offer some constructive feedback come January; having someone else know about it might help keep me on my timetable. So there it is. Over break, I'll spend some time polishing it slightly, then test it out, then have it reviewed by someone in a position of experience to tell me how full of blech it is.
Then I can move on to the Ruby tutorials and create a whole new type of blech.
Saturday, December 7, 2013
How to Start a Podcast
I've been relatively quiet lately not just because I'm squeezing in a little spare time once in awhile to the programming project...which I keep ending up spending more time than anticipated on because I'm finding things to tweak...but because I'm working on a podcasting project.
Generally speaking I end up gathering a couple of items over the weekend to talk about and add them to a Trello list dedicated to tracking podcast items. Not that I dedicate the weekend to this task, but it's a task I set a deadline of accomplishing on Saturday or Sunday so there is time to have things organized before recording.
Lately I've been recording on Monday night. The podcast ends up being about an hour (aim for 45 minutes, end up being an hour...) If I'm up to it, I can get to the apartment and begin editing, although usually that is a task I dedicate to Tuesday night.
I take a fairly loose approach to the podcast; there's not much to edit. I insert some intro music. I tack on some outro music. I edit the podcast to trim pauses and extraneous bits, shortening the recording by about...oh, five minutes. Really much, if not most, of the recorded material ends up being the podcast. No special effects, not much in the way of inserted material. It's a recorded chat with bullet points.
What am I using to record?
We...my recording partner and I...are decidedly doing this on the cheap. I use a Macintosh with Garageband to do the actual recording. I splurged on purchasing a couple of USB microphones, which makes a significant difference. Those things are sensitive. They pick up keyboard keystrokes and pens clicking against the desktop. Believe me...you don't want to fidget or eat or drink while recording. If you can, open any show notes and links you may need ahead of time to minimize the noise factor.
My cohost is normally remote, so we use Google Hangouts to collaborate. When Pete is available to cohost he normally creates a recording of himself on his side of the conversation.
Me, I use LineIn and Soundflower for the Macintosh. It's a kind of virtual audio device for redirecting audio input and output. Here's what I do...
I first have a copy of LineIn created (so there's LineIn and LineIn Copy.) And after installing Soundflower, I have an additional 2ch and 64ch virtual sound device on the Macintosh. I launch LineIn and tell it to use my USB mic as the input, and for output use the 64 channel device. In the same application I can tell it to use the stereo channels 1 and 2 for that microphone.
In the second copy of LineIn, I capture the 2ch device for input, then as output direct it to use the 64 channel virtual device as well, only using stereo 3 and 4 for output. Click "pass through" for both, and sound should now jump on the meter when the microphone picks up noise.
Next launch the Google hangout, and link up with the cohost. I tell the hangout to use, as output, the 2ch device. See where this is going?
At this point I have the microphone funneled into channels 1 and 2 on the 64ch device, and the Google Hangout funneled into channels 3 and 4 on the 64ch device.
Garageband is another example of an Apple application that is adequate for basic home use, just adequate enough that it gets frustratingly irritating if you want to do anything more than the basic home use (if you're do that, you're doing pro work, and they firmly believe you should pay gold bars to afford the privilege of doing something more advanced than the absolute basic home use features...) That means that it takes as input one device. Now you know why I am using LineIn. LineIn lets me take two "devices"...sound from the Hangout and from my microphone...and mix it into one device Garageband can see. Tell Garageband to use the 64ch device as the input, and then create one track for the microphone and another track for the hangout.
The microphone track uses channels 1/2 stereo, and the Hangout track uses channels 3/4 stereo.
I enable multitrack recording and show the track monitoring. When I monitor I should be able to hear the sound from the Hangout.
For sound output, I can use the default or headset or whatever is handy; but recently I was experimenting with the idea of interviews. This creates a new set of issues, since my microphones are sensitive enough that they can pick up both voices, despite careful tuning and settings twirling. On of the more obvious problems if the remote person was to talk to a guest was, how would the guest hear?
Once again, fixed on the cheap. I had a USB headset and I had headphones connected to the built-in output on the Mac. The Mac has an "Audio MIDI Setup" utility included; in this utility you can create what's called a multi-output device. This takes however many sound outputs and aggregates them into a single virtual output device. Create the device, checkmark what hardware you want to include in the virtual output, and voila...sound is sent to all the devices simultaneously. Now if you set the Mac to use the multi-output device as the default output for sound, anything coming out of the hangout (through GarageBand) will be heard on both my USB headset and the built-in output device at the same time...so a guest being recorded will be able to hear a remote co-host.
Back to Garageband, I click on the multi-record for the two audio tracks (and third, if I'm recording on a second microphone for a guest) and...we talk. For about an hour, give or take. Go over topics, whatever springs to mind, while trying to stay mindful of the time we've taken so we don't go much over the hour and we try to stay in the vicinity of the topic. Of course, room noises are cut down during the session; fans off, bubble-lamps are turned off, etc...anything distracting that might get picked up on the recording I try to minimize.
In our setup, after getting the recording finished I get Pete's recording of his own voice track. This gives a generally cleaner copy of his side of the conversation, without the compression noise or packety static from the Hangout mingled in with his words.
I drop his track in, line it up with my own track so the words line up in the right places, and then go to work chopping away and inserting music.
Once the intro/outro/chopping is done, I export it as an MP3. Plain old MP3. Garageband has support for artwork and such...enhanced audio, I think they call it?...built in. But if you use MP3 format, it won't export with the enhanced features. Go figure.
I then import the MP3 into iTunes. Open the Get Information inspector element, and then click on the album art tab and from there add the graphic for the podcast. Close it out...it'll save the ID3 tags (the artwork.) Then from iTunes I tell it to show the file in Finder, make a copy of it to an outside folder, and delete the iTunes copy.
The last steps are to upload the file to my storage provider (I already use their RSS feed to ping it out to the iTunes store, so I can edit the information on my storage provider and it'll ping Apple for me to push it to the Apple store.)
I wrap it up with a trip to the blog on Blogspot for the podcast and entering the shownotes there, along with links to my hosting provider. Done! I tweet it out to the world, and tens of people see that it's ready to listen to.
I'm not overly specific in my description, I know. I could give a step by step tutorial...really, it's specific to my workflow, and the specific steps aren't as important as the end goal. Podcasting is one of those things in which there are a myriad number of ways to achieve the end goal of podcasting and no single "this is how you do it" methodology behind it.
At the most basic level, it's creating an audio file, sticking it on a host server and making sure that host server allows an RSS feed for listeners to subscribe to. That's it. I still get surprised when a "hip teacher" will have a class "record a podcast" when in reality they're just recording an audio file and sharing it...the cast part of podcast is supposed to allude to the idea of broadcasting the file, so if you don't save it to a (mostly) public server for people to subscribe to, it's not podcasting. You're literally making a recording to share.
Get it right already...
After that, there's all kind of variations for what you can do to prettify and spruce up the podcast. You don't necessarily need album art; but iTunes kind of penalizes you if you don't have it. We have swearing and references to boobs in our podcast, so I make sure the explicit tag is set in the ratings. You can set enhancements to the audio so there are set chapters, and changing album art so people who watch your podcast with the proper viewer can see a virtual slideshow.
How can you record? There are people that use the built in microphone on the computer (although...yuck. It's quite noisy and not great at picking up your voice well.) Or do what I did and get an inexpensive USB mic. Other people buy USB mixers to control the microphones. Others get handheld devices made to record their voices, or even get microphones for the iPhone and import their run-and-gun audio into iTunes to be edited within Garageband. There are still other podcasters that have the equivalent of an actual studio set up; I know Scott Sigler records his podcast novels in a special closet lined with sound-absorbing foam to maximize his recording quality. Sure, it cooks him when it's a hot day and there's no AC in his closed mini-room where he is sitting and sweating his ass off during a recording session, but the sound quality is fantastic.
Sound editing for post processing can be free (Garageband!) or there are expensive audio editing suites. Much as with the microphone options (free built-in mic on the laptop up to microphones costing hundreds of dollars plugging into a soundboard for audio amping and mixing) the software editing choices depend on what you're willing and able to spend for the final product.
Hosting your audio files is quite a decision to make...moving your RSS feed later, especially when you're tied to an aggregator like iTunes, sucks. Fortunately I haven't had to do this, but I've heard other people doing it, and they all generally had the consensus conclusion that it sucks as a process.
There are free options...but the consensus I found while researching was that the free storage from places like archive.org delivered slow access, as they generally didn't have money to spend on infrastructure to deliver content at a decent pace (after all, it's free. What are you complaining about?)
If you have servers set up for other purposes, you can go through the steps to create a server for storing the audio recordings and dishing out the RSS feeds. Maybe it's more for a "low cost" solution, as you can get storage relatively cheap, depending on your bandwidth usage, from a cloud provider like Amazon. I didn't want the additional hassle of maintaining the servers though.
Actual podcast providers usually have accounts set up for relatively low fees, and they often throw in bonuses like not having to edit those God-awful XML feed files and perhaps even a nice stats page added to boot. Libsyn is very affordable, has good support, and so far I've not regretted using them.
Some people think that iTunes stores podcasts. I mean, they invented the term "podcast" in the first place, right?
Well, they did invent it, they did make it popular, but they do not host your files. They are an aggregator and search engine so people can better find your stuff. You're responsible for finding the server on which to store your files for users to download. iTunes is a simple (and free) way to get people to find your stuff. Using the iTunes store to get users is a purely optional thing, if you think you can get more people to directly subscribe to your show via the blog or your show host account.
While my storage provider has a "show blog" feature for show notes and such (show notes...where you put in information like links to what you've talked about, or a summary of the show for reference, and/or contact information...nice search-engine features to enhance your show information) I preferred using Blogspot to power a show blog. I didn't want to set up a mail address as I knew it would solicit spam, and while my show isn't all that popular, it's a waste to have mail resources tied up as yet another thing to monitor and maintain. The blog allowed me to create notes while also allowing feedback from listeners if they were so inclined, plus Blogspot was free. Want to give feedback? Just leave it at the blog! It archives my show notes, it lets me link to an embedded player, and it provided transparent feedback from users while cutting back on spam.
To elaborate on my original "what's a podcast" definition...
I've enjoyed experimenting with podcasting. I definitely have a face for radio, I enjoy hearing myself talk, and I'm generally opinionated, plus podcasting gives you practice. I am hoping to integrate some form of interviews into my podcasts so I can practice talking to people and getting to know them better; interviewing is a separate, special kind of skill if you want to do it well.
Managing a podcast is also a special skill; I can see why some productions end up hiring producers and editors. Not just for the obvious...I've been doing a podcast for a few weeks now, and we don't have many listeners. Which can get disheartening. It's hard to grow a listenership, and we're still tweaking the format. There are a LOT of podcasts out there. Standing out is nowhere near as easy as it was a few years ago. It takes dedication to not podfade, the term for a podcast that kind of...disappears. Editing takes more than twice as long as it does to record (although after having to set up the equipment and routing audio for the session, I sometimes question that...) because if I record an hour of audio, I have to listen to that hour, stopping to chop out parts of pauses or sound glitches along the way, and backing up to listen to the portions I cut to make sure they transition properly. Hour recording...another hour and twenty minutes listening and cutting and making notes for the show notes...then time to type up those notes and do the actual upload to the servers...that's why I end up scheduling a night for recording and another night for editing and upload.
And why, you see, I started off saying that my programming project got squeezed just a little bit more. I know have about two or three nights when I can tweak that program a little more. I promised myself I'd get the show up before Wednesday each week, and so far I've been doing pretty good with that. Late Tuesday night I'm tweeting out the show links shortly before midnight rolls around, and I'm patting myself on the back that I managed to produce another show on schedule and on budget.
But I really find it fun. I suppose that part of me wishes I knew how to integrate this into my job with supporting technology, or integrating learning to program with podcasting. It could be quite a blast for me...but in the meantime, I'm going to keep aiming to get these out on time, and trying to slowly grow a listener base.
"Good morning, good day and good night!"
Generally speaking I end up gathering a couple of items over the weekend to talk about and add them to a Trello list dedicated to tracking podcast items. Not that I dedicate the weekend to this task, but it's a task I set a deadline of accomplishing on Saturday or Sunday so there is time to have things organized before recording.
Lately I've been recording on Monday night. The podcast ends up being about an hour (aim for 45 minutes, end up being an hour...) If I'm up to it, I can get to the apartment and begin editing, although usually that is a task I dedicate to Tuesday night.
I take a fairly loose approach to the podcast; there's not much to edit. I insert some intro music. I tack on some outro music. I edit the podcast to trim pauses and extraneous bits, shortening the recording by about...oh, five minutes. Really much, if not most, of the recorded material ends up being the podcast. No special effects, not much in the way of inserted material. It's a recorded chat with bullet points.
What am I using to record?
We...my recording partner and I...are decidedly doing this on the cheap. I use a Macintosh with Garageband to do the actual recording. I splurged on purchasing a couple of USB microphones, which makes a significant difference. Those things are sensitive. They pick up keyboard keystrokes and pens clicking against the desktop. Believe me...you don't want to fidget or eat or drink while recording. If you can, open any show notes and links you may need ahead of time to minimize the noise factor.
My cohost is normally remote, so we use Google Hangouts to collaborate. When Pete is available to cohost he normally creates a recording of himself on his side of the conversation.
Me, I use LineIn and Soundflower for the Macintosh. It's a kind of virtual audio device for redirecting audio input and output. Here's what I do...
I first have a copy of LineIn created (so there's LineIn and LineIn Copy.) And after installing Soundflower, I have an additional 2ch and 64ch virtual sound device on the Macintosh. I launch LineIn and tell it to use my USB mic as the input, and for output use the 64 channel device. In the same application I can tell it to use the stereo channels 1 and 2 for that microphone.
In the second copy of LineIn, I capture the 2ch device for input, then as output direct it to use the 64 channel virtual device as well, only using stereo 3 and 4 for output. Click "pass through" for both, and sound should now jump on the meter when the microphone picks up noise.
Next launch the Google hangout, and link up with the cohost. I tell the hangout to use, as output, the 2ch device. See where this is going?
At this point I have the microphone funneled into channels 1 and 2 on the 64ch device, and the Google Hangout funneled into channels 3 and 4 on the 64ch device.
Garageband is another example of an Apple application that is adequate for basic home use, just adequate enough that it gets frustratingly irritating if you want to do anything more than the basic home use (if you're do that, you're doing pro work, and they firmly believe you should pay gold bars to afford the privilege of doing something more advanced than the absolute basic home use features...) That means that it takes as input one device. Now you know why I am using LineIn. LineIn lets me take two "devices"...sound from the Hangout and from my microphone...and mix it into one device Garageband can see. Tell Garageband to use the 64ch device as the input, and then create one track for the microphone and another track for the hangout.
The microphone track uses channels 1/2 stereo, and the Hangout track uses channels 3/4 stereo.
I enable multitrack recording and show the track monitoring. When I monitor I should be able to hear the sound from the Hangout.
For sound output, I can use the default or headset or whatever is handy; but recently I was experimenting with the idea of interviews. This creates a new set of issues, since my microphones are sensitive enough that they can pick up both voices, despite careful tuning and settings twirling. On of the more obvious problems if the remote person was to talk to a guest was, how would the guest hear?
Once again, fixed on the cheap. I had a USB headset and I had headphones connected to the built-in output on the Mac. The Mac has an "Audio MIDI Setup" utility included; in this utility you can create what's called a multi-output device. This takes however many sound outputs and aggregates them into a single virtual output device. Create the device, checkmark what hardware you want to include in the virtual output, and voila...sound is sent to all the devices simultaneously. Now if you set the Mac to use the multi-output device as the default output for sound, anything coming out of the hangout (through GarageBand) will be heard on both my USB headset and the built-in output device at the same time...so a guest being recorded will be able to hear a remote co-host.
Back to Garageband, I click on the multi-record for the two audio tracks (and third, if I'm recording on a second microphone for a guest) and...we talk. For about an hour, give or take. Go over topics, whatever springs to mind, while trying to stay mindful of the time we've taken so we don't go much over the hour and we try to stay in the vicinity of the topic. Of course, room noises are cut down during the session; fans off, bubble-lamps are turned off, etc...anything distracting that might get picked up on the recording I try to minimize.
In our setup, after getting the recording finished I get Pete's recording of his own voice track. This gives a generally cleaner copy of his side of the conversation, without the compression noise or packety static from the Hangout mingled in with his words.
I drop his track in, line it up with my own track so the words line up in the right places, and then go to work chopping away and inserting music.
Once the intro/outro/chopping is done, I export it as an MP3. Plain old MP3. Garageband has support for artwork and such...enhanced audio, I think they call it?...built in. But if you use MP3 format, it won't export with the enhanced features. Go figure.
I then import the MP3 into iTunes. Open the Get Information inspector element, and then click on the album art tab and from there add the graphic for the podcast. Close it out...it'll save the ID3 tags (the artwork.) Then from iTunes I tell it to show the file in Finder, make a copy of it to an outside folder, and delete the iTunes copy.
The last steps are to upload the file to my storage provider (I already use their RSS feed to ping it out to the iTunes store, so I can edit the information on my storage provider and it'll ping Apple for me to push it to the Apple store.)
I wrap it up with a trip to the blog on Blogspot for the podcast and entering the shownotes there, along with links to my hosting provider. Done! I tweet it out to the world, and tens of people see that it's ready to listen to.
I'm not overly specific in my description, I know. I could give a step by step tutorial...really, it's specific to my workflow, and the specific steps aren't as important as the end goal. Podcasting is one of those things in which there are a myriad number of ways to achieve the end goal of podcasting and no single "this is how you do it" methodology behind it.
At the most basic level, it's creating an audio file, sticking it on a host server and making sure that host server allows an RSS feed for listeners to subscribe to. That's it. I still get surprised when a "hip teacher" will have a class "record a podcast" when in reality they're just recording an audio file and sharing it...the cast part of podcast is supposed to allude to the idea of broadcasting the file, so if you don't save it to a (mostly) public server for people to subscribe to, it's not podcasting. You're literally making a recording to share.
Get it right already...
After that, there's all kind of variations for what you can do to prettify and spruce up the podcast. You don't necessarily need album art; but iTunes kind of penalizes you if you don't have it. We have swearing and references to boobs in our podcast, so I make sure the explicit tag is set in the ratings. You can set enhancements to the audio so there are set chapters, and changing album art so people who watch your podcast with the proper viewer can see a virtual slideshow.
How can you record? There are people that use the built in microphone on the computer (although...yuck. It's quite noisy and not great at picking up your voice well.) Or do what I did and get an inexpensive USB mic. Other people buy USB mixers to control the microphones. Others get handheld devices made to record their voices, or even get microphones for the iPhone and import their run-and-gun audio into iTunes to be edited within Garageband. There are still other podcasters that have the equivalent of an actual studio set up; I know Scott Sigler records his podcast novels in a special closet lined with sound-absorbing foam to maximize his recording quality. Sure, it cooks him when it's a hot day and there's no AC in his closed mini-room where he is sitting and sweating his ass off during a recording session, but the sound quality is fantastic.
Sound editing for post processing can be free (Garageband!) or there are expensive audio editing suites. Much as with the microphone options (free built-in mic on the laptop up to microphones costing hundreds of dollars plugging into a soundboard for audio amping and mixing) the software editing choices depend on what you're willing and able to spend for the final product.
Hosting your audio files is quite a decision to make...moving your RSS feed later, especially when you're tied to an aggregator like iTunes, sucks. Fortunately I haven't had to do this, but I've heard other people doing it, and they all generally had the consensus conclusion that it sucks as a process.
There are free options...but the consensus I found while researching was that the free storage from places like archive.org delivered slow access, as they generally didn't have money to spend on infrastructure to deliver content at a decent pace (after all, it's free. What are you complaining about?)
If you have servers set up for other purposes, you can go through the steps to create a server for storing the audio recordings and dishing out the RSS feeds. Maybe it's more for a "low cost" solution, as you can get storage relatively cheap, depending on your bandwidth usage, from a cloud provider like Amazon. I didn't want the additional hassle of maintaining the servers though.
Actual podcast providers usually have accounts set up for relatively low fees, and they often throw in bonuses like not having to edit those God-awful XML feed files and perhaps even a nice stats page added to boot. Libsyn is very affordable, has good support, and so far I've not regretted using them.
Some people think that iTunes stores podcasts. I mean, they invented the term "podcast" in the first place, right?
Well, they did invent it, they did make it popular, but they do not host your files. They are an aggregator and search engine so people can better find your stuff. You're responsible for finding the server on which to store your files for users to download. iTunes is a simple (and free) way to get people to find your stuff. Using the iTunes store to get users is a purely optional thing, if you think you can get more people to directly subscribe to your show via the blog or your show host account.
While my storage provider has a "show blog" feature for show notes and such (show notes...where you put in information like links to what you've talked about, or a summary of the show for reference, and/or contact information...nice search-engine features to enhance your show information) I preferred using Blogspot to power a show blog. I didn't want to set up a mail address as I knew it would solicit spam, and while my show isn't all that popular, it's a waste to have mail resources tied up as yet another thing to monitor and maintain. The blog allowed me to create notes while also allowing feedback from listeners if they were so inclined, plus Blogspot was free. Want to give feedback? Just leave it at the blog! It archives my show notes, it lets me link to an embedded player, and it provided transparent feedback from users while cutting back on spam.
To elaborate on my original "what's a podcast" definition...
- Create an audio file
- Upload the audio file to a server with an RSS feed
- Create a presence for your show notes and information...such as with a blog.
- Create the audio file
- Edit the audio file for an intro and outro jingle...remember to respect copyright
- Edit the pauses, um's, and errrr's out of the file
- Add album art
- Upload to a storage provider
- Edit the description of the show, edit ratings
- Create show notes that are accessible to potential and current listeners
I've enjoyed experimenting with podcasting. I definitely have a face for radio, I enjoy hearing myself talk, and I'm generally opinionated, plus podcasting gives you practice. I am hoping to integrate some form of interviews into my podcasts so I can practice talking to people and getting to know them better; interviewing is a separate, special kind of skill if you want to do it well.
Managing a podcast is also a special skill; I can see why some productions end up hiring producers and editors. Not just for the obvious...I've been doing a podcast for a few weeks now, and we don't have many listeners. Which can get disheartening. It's hard to grow a listenership, and we're still tweaking the format. There are a LOT of podcasts out there. Standing out is nowhere near as easy as it was a few years ago. It takes dedication to not podfade, the term for a podcast that kind of...disappears. Editing takes more than twice as long as it does to record (although after having to set up the equipment and routing audio for the session, I sometimes question that...) because if I record an hour of audio, I have to listen to that hour, stopping to chop out parts of pauses or sound glitches along the way, and backing up to listen to the portions I cut to make sure they transition properly. Hour recording...another hour and twenty minutes listening and cutting and making notes for the show notes...then time to type up those notes and do the actual upload to the servers...that's why I end up scheduling a night for recording and another night for editing and upload.
And why, you see, I started off saying that my programming project got squeezed just a little bit more. I know have about two or three nights when I can tweak that program a little more. I promised myself I'd get the show up before Wednesday each week, and so far I've been doing pretty good with that. Late Tuesday night I'm tweeting out the show links shortly before midnight rolls around, and I'm patting myself on the back that I managed to produce another show on schedule and on budget.
But I really find it fun. I suppose that part of me wishes I knew how to integrate this into my job with supporting technology, or integrating learning to program with podcasting. It could be quite a blast for me...but in the meantime, I'm going to keep aiming to get these out on time, and trying to slowly grow a listener base.
"Good morning, good day and good night!"
Subscribe to:
Posts (Atom)