AMA 2009: The Weirdness Continues

After being prompted to do so by a couple of other things I read on the net I went and looked at the 2009 AMA Pro Racing Official Rule Book and discovered something strange. It shouldn't have come as a surprise, given that the DMG has been proposing this all along, but the homologated motorcycles for the new Daytona Sportbike class is strange to say the very least. I guess I kind of thought this would change and it didn't. So next year we're going to have a class where the allowed motorcycles are mixed up to say the very least. That was always a bit of the case with the old AMA Formula Extreme class but at least there it was broken up in such a way that it made sense. Basically, Formuala Extreme allowed the following:

• Liquid-cooled four-cylinders up to 600cc
• Liquid-cooled three-cylinders up to 675cc
• Liquid-cooled two-cylinders up to 850cc
• Air-cooled Desmo-valved, two-valve, two-cylinders up to 1100cc
• Air-cooled four-valve, two-cylinders up to 1200cc
• Air-cooled two-valve, two-cylinders up to 1350cc.

That's a pretty big spread of bikes but it keeps the horsepower ratings in the same general area, probably in the 115bhp range. Some bikes would have made more, some less, but it was generally fairly sane. Very broadly, liquid cooled bikes make more power per cc than
air-cooled, more cylinders generally equals more horsepower (albeit usually less torque) per cc, and more valves per cylinder equals more power per cc. With those very broad rules in mind the logic behing the 2008 rules is pretty clear: different but roughly equitable engine
configurations competing against each other.

The 2009 rules for Daytona Sportbike, on the other hand, and much weirder. The following bikes are homologated right now to run in that class:

• Aprilia RSV, a 1000cc liquid-cooled four-valve V-twin
• BMW HP2 Sport, a 1170cc air-cooled four-valve boxer twin
  
• Buell 1125R, a 1125cc liquid-cooled four-valve V-twin
  
• Ducati 848, a 849cc liquid-cooled four-valve V-twin
• Honda CBR600RR, a 600cc liquid-cooled four-valve inline four cylinder
• Kawasaki ZX-6R, a 600cc liquid-cooled four-valve inline four cylinder
• KTM Super Duke, a 999cc liquid-cooled four-valve V-twin
  
• Suzuki GSX-R600, a 600cc liquid-cooled four-valve inline four cylinder
• Triumph Daytona 675, a 675cc liquid-cooled four-valve three-cylinder
• Yamaha YZF-R6, a 600cc liquid-cooled four-valve inline four cylinder

Should be a strange class to say the very least...

AMA/DMG Official Rules Released. Finally.

The Daytona Motorsports Group, operating as AMA Pro Racing, finally released an official rule book today.  It's taken nine months of arguing, negotiating, threats, personal attacks in the media, and who knows what else to get here, but they finally made it.  I haven't perused the 115-page document yet so I really don't know much about the details.  I do know that there are three primary classes:

• American Superbike - This will be the premier class (after DMG finally dumped the idiotic idea of making a weight- and horsepower-limited 600cc-based class the premier class) and the last I heard will be based mostly around the 2009 rule book that was agreed upon by the manufacturers in 2007.  Also, I keep hearing that this class is ultimately going to shift to using the same rule book as World Superbike, which I applaud heartily and have been advocating for some time.
• Daytona Sportbike - This class is the originally-proposed, aforementioned weight- and horsepower-limited, 600cc-based class that finally ended up.  My understanding is it's kind of a cross between 2008 Formula Xtreme and 2008 Supersport.  Kind of like Formula Xtreme in that there are a variety of different bikes ranging from 600cc inline fours to 1000+ cc twins, but similar to Supersport in that the bikes aren't allowed a very high level of tune.  I'm not sure if the originally proposed weight and horsepower restrictions stood.
• SuperSport - I don't know much about this one yet, but I gather it's similar to SuperSport from previous years.  The big changes are that factory involvement will be severely curtailed or completely disallowed and there will be an age limit for the riders.  This class is intended to be a entry-level class for young riders to use as a springboard into the bigger class.

There haven't been many announcements from the various factories and teams so far.  The only people who've done anything official with regard to their factory team is Yamaha.  The held a media day last week and announced their 2009 racing plans as well as unveiled their 2009 rider lineup, which consists of Ben Bostrom and Josh Hayes on Superbikes and Josh Herrin and Tommy Aquino on Daytona Sportbikes.  Hopefully the announcement of the final rules hasn't come too late for everyone else to get onboard.  I can only assume we'll have a better idea in a couple of weeks when the traditional December tire tests occur at Daytona Internation Speedway.

For anyone who's interested, the official rule book can be found here: http://www.amaproracing.com/prorace/pdf/2009%20AMA%20Pro%20Road%20Race%20Regulations.pdf and an articles about Yamaha's Media Day can be found here and here.

The Open Source Musician, Part Two

In this installment of my "The Open Source Musician" series I'll talk about the trails and tribulations of getting my Linux-based home studio computer up and running and starting my first recording projects.  Look here for the first part of the series.

The Software
As mentioned in the previous article, home recording in the UNIX/Linux world is a bit different than doing the same thing in the Windows or Mac world, at least in my (admittedly fairly limited) experience.  Using Cakewalk or similar under Windows one tends to perform most tasks inside Cakewalk itself.  Or at least I always did.  Linux, on the other hand, follows more in the UNIX tradition of having tools that perform a single task very well and is intended to be linked with other tools to get a bigger task completed. As a refresher, the tools I'm using with Linux are as follows:

• JACK, for tying it all together.
• Hydrogen, for creating drum and percussion tracks
• Ardour, as my primary Digital Audio Workstation (DAW) software
• Rosegarden, for non-percussion sequencing
• JAMin, for mastering

It's a bit difficult to decide where to begin because of the amount of interconnectivity of all these bits and pieces so I'll just take the novel approach of beginning at the beginning.  By that I mean I start discussing the software in the same order I would use it if I were starting a new recording project.

JACK
The place I always start is with JACK.  JACK, which is another of those ubiquitous recursive acronyms so popular with Open Source developers, stands for JACK Audio Connection Kit.  The name may not be much of a clue to the neophyte but JACK is in many ways the hub of the Open Source studio.  JACK is very literally the glue that ties all the disparate parts together.  JACK is, very basically, a sound server that sits between the sound card driver (like ALSA) and the software that comprises the studio.  That sounds simple enough that one might wonder why it's needed.  After all, does it have an equivalent on Windows or Mac?  I don't think so (I could easily be wrong) but then again it's not really needed if you're using one software package to record, sequence, mix, master, etc.  Since all these sub-tasks are performed by separate pieces of software in an Open Source studio they all have to have some way to communicate with each other.  That is the function that JACK performs.  All of the software packages listed above (and many more besides) are JACK clients.  That means they all use (or can use) JACK as a transport mechanism for routing audio or MIDI from one software package to another, all internally to the computer.  What's more, JACK doesn't know or care where the audio or MIDI data it's routing comes from.  It treats a guitar plugged into your sound card's recording interface or MIDI coming from your keyboard or electronic drum kit via a USB or serial interface exactly the same as it treats data coming from another source internal to the computer.  If all of this leaves you scratching your head then don't worry too much, it's one of those things that becomes clear when a concrete example is given.

JACK is also the primary place where one concerns oneself with system latency.  JACK is intended to be a very low-latency sound server but making it work as such means getting it configured right and, in some cases, having the right hardware.  As is usually the case in situations like these, having the wrong hardware can make this task nigh upon impossible.  The bad news here is that as far as I'm able to discern setting up JACK is mostly an exercise in trial-and-error.  It definitely was for me and all the guides I've read about setting it up end up suggesting the very same thing.  Once the operating system is configured with a low-latency kernel (this was handled by installing Ubuntu Studio in my case) one simply fires up a command prompt or a program like QJackCtl, plugs in some reasonable defaults, and tries to start it up.  If the server starts successfully you can either move on to the next stage if JACK's latency and performance are adequate with the settings used or, more likely the case, stop the server again, tweak some settings in a quest for lower latency, restart the server, observe, and repeat until satisfied.  Or perhaps I should say "repeat until it's as good as it'll get with your hardware" rather than "repeat until satisfied."

I suppose this is the place that I should note the fact that almost every setback, problem, headache, and complication I've encountered in my quest for an Open Source home studio to date have been related, in one way or another, to JACK.  In fact, I believe I've only had two that were completely unrelated to JACK and I'll talk about those later.  For now I need to qualify that statement because it sounds like JACK is a problematic piece of software, and it emphatically is not.  Or at least it hasn't been for me.  The problems, setbacks, headaches, and complications that have been JACK-related have been either the nature of the beast, misconceptions on my part, things I didn't know or understand, and configuration modifications that were simple once I understood I had to do them.

The first problem I encountered with JACK was just configuration.  As mentioned previously it's a mostly trial-and-error affair.  That seems kind of archaic and crappy but I honestly don't think it can be helped.  After all, the latency that can be achieved by a given system is entirely dependent UPON that system.  How are the JACK developers supposed to know the capabilities or eccentricities of your sound card?  Or worse, upon your sound card when it's combined with your driver version, motherboard, kernel revision, etc.  I suppose they could compile databases of cards and their performance metrics or write code that performs various and sundry tests trying to discover a good base setting but honestly I'd rather see them keep writing great code and let me worry about making it work on my system.

The second problem, or perhaps misconception, involved multiple sound cards.  My system has a AC97-based sound card on the mother board and as I mentioned in the last article I installed a old Sound Blaster Audigy Platinum when I set the machine up.  I originally had both cards enabled and Ubuntu Studio had no problem with that at all, in and of itself.  To make things even more complicated, I sometimes had a third sound card (at least as far as Ubuntu Studio and ALSA were concerned) because I was using my Digitech GNX4 as an audio interface via it's built-in USB connectivity.  When the GNX4 is connected to the computer Ubuntu treats it just like another sound card.  JACK really didn't have a problem with the multiple sound cards, it just didn't like being told to use an interface on one card for recording and an interface on another for playback.  What I was trying to do originally was to use my GNX4 as a recording interface but use the Audigy as the playback interface so I could monitor what I was playing or listening back to through my speakers (the GNX4 is a floor-unit guitar effects processor, among other things, and needs to be plugged into a power amp or used with headphones to be heard).  JACK didn't care for that configuration at all.  Some reading lead me to the information that JACK can only be used with one audio interface at a time due to issues with synchronizing the master clocks (and therefore the audio) on multiple sound cards.  That kind of made sense once it was pointed out to me, but it was still a bummer given my available configuration options, and even moreso because at the time I'd been unable to get the external breakout box for the Audigy to work (a problem I later solved, thereby greatly simplifying my setup.  The problem with the Audigy ended up being a power connection I missed during install.).  Since I had to use the same hardware interface for both recording and playback at any given time I was relegated to using my GNX4 and a set of headphones anytime I was recording tracks.  Thankfully Ubuntu Studio's handling of the GNX4's USB interface was seamless enough that I was able to do so.  JACK's performance did suffer in this configuration though, resulting in some Xruns from time to time.  Xruns are JACK's way of telling you it's having trouble keeping up and is loosing pieces of data.  They are A Bad Thing, and something that's to be avoided whenever possible.  I'm quite certain the Xruns were being caused by the system trying to pass audio data from the GNX4 to the computer (recording) and from the computer to the GNX4(playback), all through a USB 1.1 connection (because that's all the GNX4 supports).  Anyway, this configuration worked ok for a while, until it led me directly to problem number three.

Problem number three had to do with sample rates.  During all of my previous work I was switching more-or-less randomly between 44.1K and 48K sampling rates in an effort to optimize my JACK performance.  When I started recording with the GNX4 as the interface I happened to have the system set to 44.1.  Since it worked I didn't bother to check the 48k setting.  I got the first-run drum track, a guitar track, and a bass track all laid down for the original song I was trying to record while setting up and testing my new studio workstation.  Once I got the rhythm tracks recorded I wanted to switch back to just listening through my speakers (verses the headphones which were the only way I had to monitor sound through the GNX4) so I could experiment with some effects as well as routing, mixing, and mastering.  When I reconfigured JACK to use my sound card as the interface the problem showed itself.  JACK wouldn't operate with my sound card at 44.1K and wouldn't operate with the GNX4 at 48K.  The GNX4 only supports 44.1K sample rates so I thought I was dead in the water.  After some more reading about the emu10k1 chipset that is at the heart of the Audigy I discovered that there were two different ways it can be used to record.  One way is with what I guess would be best termed the "primary" or "consumer" recording interface and one way that is directly through the chip's onboard 16-channel mixer.  The emu10k1 chipset operates natively at 48K and if recording is being done directly through the mixer that's the only rate it will operate at.  If, however, one uses the "primary" recording interface the card will do hardware-based on-the-fly resampling to 44.1k.  I had JACK set up to record directly from onboard mixer so it would fail if I tried to operate at 44.1k.  Reconfiguring JACK to use the other interface allowed me to switch to a 44.1k rate and continue without Ardour complaining about different sample rates and, if those complaints were ignored, playing the song back too fast and slightly pitch-shifted.  This might seem as though the problem were solved, and it was to a point, but I noticed after working this way for a little while that JACK's performance was definitely degraded by having the card operating at a non-native sample rate.  This performance degradation surfaced in the form of a markedly increased number of Xruns while working with the audio in Ardour.  I ultimately ended up solving this problem by finding the missing power connection and getting the breakout box for the Audigy working.  Once I had that fixed I decided to not waste any more time with it and simply re-recorded my drum, guitar, and bass tracks through the Audigy at it's native 48k sample rate.

In the next installment of series I'll talk more about Ardour, Rosegarden, and JAMin, with maybe a bit about Hydrogen thrown in as well.  Stay tuned.

The Open Source Musician, Part One

Over the last couple of weeks I've been slowly assembling a small home recording studio based around the Linux operating system. I've been playing guitar and piano for many years and I've always liked writing and recording music.  I've also had home studios of various kinds over the years. When I suddenly found myself with a spare computer that was semi-modern at a time when I'm also playing a lot of guitar, practicing with a band (albeit only a temporary, one-off band) and really getting back into making music, I decided it was time to assemble a PC-based recording studio. I've been wanting to do so for years and have in fact used various versions of Cakewalk at different times and really enjoyed it. I just never really had everything I needed in one place at the same time for it to really work out.

Once the decision was made it was a very small step to deciding to try it as a Linux based studio. I'd read about Ubuntu Studio several times while playing with Rosegarden over the last few months but I never had a computer to install it on. That problem was now solved so it was time to forge ahead.

The Box
The computer that this studio is based around is a 2.8GHz Dual-core Intel chip on an Intel motherboard. In has a lower-end NVidia G-Force video card and originally had no sound card available other than the on-board AC97 sound module. The crappy on-board sound card is fine for listening to music and playing the occasional game of Open Arena but it wasn't going to cut it for serious audio work. With that situation being untenable I decided to harvest the old Creative Sound Blaster Audigy Platinum out of my ancient (circa 1999 originally, but it's had a LOT of upgrades through the years) dual-processor Pentium 3 box that's become so unreliable that it's unusable. I originally bought this sound card for the purpose of using it with Cakewalk probably about 6 years ago, and it was the highest-end Sound Blaster available at the time. Specifically, it has Creative's SoundFont-based MIDI sequencer on board (anything you can do on the hardware to free up memory and CPU cycles is a good thing) and it also has a break-out box with S/PDIF, MIDI, and Mic/Instrument inputs on it. That's a nice-to-have feature since it means I don't have to go crawling behind my computer everytime I want to jack in an instrument. This soundcard isn't ideal by any means but I decided it would definitely work in the short-term until I decided what I really wanted. Lastly, I bumped the box's memory up from 512Mb to 2.5Gb.

Getting the Project Off the Ground
With the computer built and ready it was time to install the OS. I won't go into to much detail here because frankly it was pretty painless. I've installed several flavors of both Ubuntu and SUSE over the last few years and they are getting steadily better. At this point I find installing a modern Linux distro far less painful than installing Windows XP. The installations (for me, at least) do a good job of hardware detection and they are clear, concise, and beautiful. The only thing I tend to struggle with anymore is getting the video card set up and getting the display centered on the monitor, but that's something for another post.

Ubuntu Studio, my distro of choice for this application, is a Ubuntu spin-off that's targeted toward content creation. Specifically, it's geared toward music production, video production, and photography and image production. I left off the video production stuff since I don't do anything in that realm and don't really intend to start. I left the photography and image stuff because it has some 3D modeling software, but in retrospect I could have foregone that as well since my other computer has the same software and is much better suited, hardware-wise, to 3D work. Oh well, I'll just remember that for the eventual upgrade or re-installation.

The reason I chose Ubuntu Studio is because, as part of it's audio package, it comes with all the software packages I needed (more on this later) but more importantly it can be configured out of the box to run as a low-latency system. This is a very, very important feature for people working with multitrack audio and, especially, MIDI. Without getting too deep into detail here, latency refers in this instance to the time elapsed between an event happening (a MIDI keyboard key being pressed, for example) and the sound being heard coming through the speakers. Achieving sufficiently low latencies in Linux requires the utilization of a real-time kernel, and thus my reason for using Ubuntu Studio. The real-time kernel is created by patching a standard kernel. I can and have done this in the past, but why bother? Some wonderful souls in the open source community have done it for me, and included all the software with it, so I'm using it.

The Next Steps
Once the computer was upgraded with plenty of RAM, a useable sound card, and a operating system, the time had come to start learning about audio creation on Linux. As usual with the Linux/UNIX crowd and the Open Source community, the process of recording music on Linux is a bit different from the ways the same task is accomplished on Mac or Windows. I don't have much experience with recording on a Mac but from what I've seen it isn't substantially different from Windows in process or workflow, only in which software packages are used.

On Windows and Mac people tend to use "Swiss Army Knife" software that does a lot of things like handle the multi-track recording and MIDI sequencing, controls audio effects, and can be used for final mixdown and mastering. Commercial software vendors tend to build all kinds of features into a single package because they figure (and rightly so, I guess, if you're actually buying the software) that if they can set it up so you don't need any software other than theirs you're more likely to buy their software in the first place.

The Open Source developers, on the other hand, don't really have to worry about market forces and consequently can focus their attention and efforts on the tasks they wish to get accomplished. That circumstance tends to make the available Open Source audio software follow the traditional UNIX software philosophy of having a tool that does one job, does it well, and can be combined with other tools to accomplish a given task. So, with that in mind, here are the software packages that I'm using in my home studio:

• Ardour, as my primary Digital Audio Workstation (DAW) software
• Hydrogen, for creating drum and percussion tracks
• Rosegarden, for non-percussion sequencing
• JAMin, for mastering
• JACK, for tying it all together.

Most of these programs can be pretty complicated, hence my trepidation when getting started with all of this. I don't mind a steep learning curve but having to learn five programs essentially at once to get the job done is daunting nonetheless. It's worthwhile, because the one-tool-per-job paradigm lends itself beautifully to having a very flexible system once you've learned enough, but getting started is definitely more difficult. Not only must one learn about the individual programs, one must also learn which software to use for what task and how they all connect together.

I'll post part two of this series sometime within the next day or two. I'm not sure what that one will cover other than the trials and tribulations of getting it all set up and working. I may or may not leave the actual recording part for a third (or fourth?) post. Stay tuned.

Ben Spies in Portugal

Ben Spies has made his official World Superbike Debut with the Yamaha Motor Italia WSBK squad.  Ben rode the both the outgoing 2008 Yamaha R1 as well as the new 2009 "Long Bang" bike.  He managed to turn in times within a couple of tenths of Haga's race pace and less than half a second off Bayliss'.  Pretty impressive for a guy riding new track on tires he's never ridden, with a new team, and a brand-new, undeveloped motorcycle. Maybe I'm optimistic but I think Spies could be a contender his first year in World Superbike. I'd rather have seen him go to MotoGP but I think WSBK was a good choice too. I'm just happy he moved to the world stage and didn't follow in Mladin's "big fish in a little pond" footsteps by staying in America and dominating.

See the whole article here: http://www.roadracingworld.com/news/article/?lnk=rss&article=34926

Back to the Mountains, or The Last Ride of the Year

Very suddenly last Saturday night I found myself slated to leave the following Sunday morning for a group ride up to Tuggles Gap, in Floyd County, VA. Tuggles Gap is the site of a tasty restaurant that is situated adjacent to the Blue Ridge Parkway, is a destination for motorcyclists, and, of course, is surrounded by twisty mountain roads.

This was to be the last real ride of the year for the group I ride with the most so of course I wanted to go. That desire to go was unfortunately tempered by a large dose of trepidation on a few different fronts. Namely:

• It would be my longest ride since the crash back in May and I was unsure how my still-healing knee would take it.
• It was my first mountain ride since the crash and frankly the sketchy, blind corners (like the one that was the site of my crash) that the mountains are so full of scare the crap out of me now.
• It was to be my longest ride to date on the new Monster. Admittedly, a minor worry. I was mostly just hoping not to be too uncomfortable.

I left home Sunday morning a bit before 9am with the goal of meeting the other riders at a fast-food place along I-40 at about 9:15am. The weather was beautiful, albeit a bit on the frosty side. My outdoor thermometer was reading 48 degrees F. on my front porch when I left. I met the other riders and we got the trip underway. Riding with me and my Monster were a Kawasaki Concourse, a Honda ST1300, a BMW R1200GS, a Yamaha FJR1300, and a Ducati Multistrada.

The ride up to Tuggles Gap took us about four hours and was pretty uneventful. The day never really got as warm as I would have liked and consequently I never completely warmed up. On the other hand, we were gaining altitude the entire morning and I was never really that cold either. The roads were fairly typical in the NC foothills: Lots of trees, lots of long, sweeping curves, and not too much traffic. The kind of thing I've always liked. Once we crossed into Virginia and got close to the Gap things changed a bit and we hit the first of what I consider the "real" mountain roads, i.e. rising and falling roads full of blind and decreasing-radius turns, and sharp, rising switchbacks. All sprinkled liberally with wet spots, fallen leaves, and gravel, of course. The kinds of roads my friend Jim, who's been riding in these mountains for decades, so eloquently calls "goat paths."

This little section was the first time I'd ridden roads like this since the crash. I was fairly unsettled so I let the rest of the riders go on ahead, dialed back the speed, and just took it easy. I managed to get through it without scaring myself, but saying I enjoyed it would be a bit of an overstatement.

We had a nice, leisurely lunch at the Tuggles Gap Restaurant, full of the comraderie that I so value on motorcycle trips. We talked about all kinds of things, but of course mostly motorcycles. Lunch was good but soon enough finished and it was time to get the bikes back on the road and get headed toward home.

Rather than head back the way we'd come the decision was made to take a route back that would have us on more of these typical mountain roads. I wasn't thrilled with the idea, much preferring to stick with the long sweepers rather than the "goat paths," but of course I went along without complaint. The route took us east along the NC/Virginia boarder toward Danville, VA and encompassed VA Highway 40, not to be confused with Interstate 40. Large sections of this road turned out to conform to Jim's "goat path" definition beautifully, including a sharp, blind, decreasing-radius, 15mph (posted) corner that was strown with gravel. Listening to the stories at the next gas stop, this corner scared everyone in the group but me (I was following my previous pattern of letting the rest go and slowing way, way down). In fact, one of our riders actually lost the back end on this curve but was able to save it. Another overcooked it into the decreasing radius section, had to slam the bike over on it's side to make the curve, and indeed wound up overcorning and almost ended up in the grass on the inside of the corner before he could get the bike back upright and going straight again. Maybe there's a good reason these roads scare me, no?

This was the last eventful section of the ride. From there we all decided to hit the super-slab highway and just make time getting home. We were all tired, the temperature was dropping again, and, having originally planned on being back in Raleigh by 4pm or so, we were a couple of hours behind schedule. I ended up getting home around 6pm.

The Monster turned out to be a pretty good bike for the trip, my only real complaints being lack of luggage and lack of range. The bike confirmed yet again that it was a good selection for my current single-bike status. The Monster's seat was good enough, my wrists weren't hurting, and I was generally in pretty good shape for having spent most of 9 hours on a motorcycle. I had some aches and pains but most of them were attributable more to not being acclimated to spending large amounts of time on a motorcycle anymore rather than the motorcycle itself. The Monster wasn't as comfortable as the Multistrada would have been, but it was not bad at all. Had I done this same ride on my 1098 I would probably have been visiting a chiropractor afterwards.

The jury is still out on the "mountain experience" for me. I've quite honestly been scared of riding in the mountains since my untimely encounter with a truck on a twisty mountain road near Sparta, NC back in May. This trip was something of a "getting back on the horse" trip for me, but I'm not sure it really helped. I enjoyed most of the ride, but the twisty mountain sections I could have happily done without. Even now I have no real desire to repeat the experience. That leaves me with the question of whether it's simply a confidence problem that I'll eventually overcome or if the mountains are now one of my boogeymen. I honestly don't know. The strange thing is that I would happily, eagerly, and willingly have gotten back on a motorcyle the day after the crash if I could have. I've never once experienced even the slightest bit of hesitation or trepidation about riding bikes. As I said before though: those mountain roads scare the crap out of me.