blog@tomauger.com

Although the Behringer FC-1010 seems to be a simpler match-up for getting foot-pedal control, with expression input, to Ableton Live, the Boss (Roland) FC-50 is a solid choice in a more robust and compact format. Given that I was able to pick one up on Craigslist for about $100, I figured this would be the way to go.

The real challenge with the FC-50 is that it sends MIDI PC (Program Change) data, not CC (Controller Change) data. Since the FC-50 was designed to control patch switching for external synths and guitar effects racks, PC data was the right call. Unfortunately for those of us in the DAW generation, especially Ableton Live users, PC messages are not as useful or versatile as CC data. Ableton Live, specifically, at least as of version 8, converts all PC MIDI data into Pitch Bend (PB) data, and all on the same PB #, so although you COULD use the PB data to trigger, for example, a global clip start, you couldn’t take advantage of the fact that the FC-50 has 5 footswitches. If I wanted just 1 footswitch, there are a lot easier ways to go about hooking one up to Ableton.

Well, getting the FC-50 working exactly as I wanted it proved to be a little challenging for me, given my hardware and software configuration, but for what it’s worth, I”m posting my experience here, in case it may be of use to others. I am by no means a MIDI wizard, but with about 5 hours of research, installation and experimentation, I was able to create a configuration that for now appears to meet my needs, which are:

• leverage all 5 foot-pedals to be able to MIDI- or Key-map to any toggle-based Live control input, such as track start, overdub on/off, move up/down scene etc.
• leverage the Expression pedal input capabilities and map Expression to any continuous controller in Live (not just volume)
• spend no additional money to do all this

(more…)

I’ve got an extended warranty on my Dell XPS M1730 and I gotta say, Dell is great about sending replacement parts in a prompt and professional manner.

But talk about overpackaging! The items shipped to me were a laptop power supply and cable. The cable (just a regular power plug) was packaged inside its own little box with foam on either side. The power pack was in a larger box, padded as well. All of that was then put in a really large, mostly empty box. I understand from a logistics standpoint why such a blunder might occur, but come on guys. What’s all this talk about more corporate responsibility?

So I ran into a bit of a snag yesterday when I was working for the first time with the most excellent Greensock TweenLite ActionScript class. Naturally I panicked and blamed everything on the class. Fortunately the author of the class, Jack Doyle was listening in on his forums and responded to my surprise within minutes of my posting the query there. He assured me that his class was iron-tight and pointed me in a direction that led me to uncover the error of my ways.

How naive I was! Ah, the shame of it all.

So, to hopefully forestall any future embarassment on the part of you, my reader, who has miraculously stumbled upon this obscure piece of flotsam in the vast ocean that is the InterMegaWeb, let me expound upon the dangers of ActionScript’s pass-by-reference.

But first, let me set the stage by introducing TweenLite a little. Although the class has absolutely no bearing whatsoever on the problem I was experiencing, the way the class is designed kind of allows one to fall into the trap fairly easily, and makes a good example. And besides, it’s a very useful class, so if this is your first introduction to it, I will consider that I did you a service.

TweenLite serves to bolster ActionScript support for tweening things over time without using the Timeline or the Flash IDE. For those of us foolish enough to try to animate things using code, the built-in native Flash Tween class is woefully poor, performance-wise. There are tests to prove it (beware: when testing the native Flash Tween class, be sure to lower the values as it will crash your browser – that’s just how bad the Flash class is!). The TweenLite tween class is a joy to use.

Let’s say you want to tween a MovieClip named myClip across the stage from x = 100 to x = 500, and from y = 100 to y = 400, and you want it done over 5 seconds:

TweenLite.to(myClip, 5, {x:500, y:400});

The previous example assumes that myClip is already at x = 100 and y = 100. Over the next 5 seconds, it will move its way toward (500,400) incrementally each frame. You don’t have to do a damned thing but sit back and watch. Very sweet.

You can even add other, custom parameters to TweenLite to tweak its behaviour. Say you wanted a 1-second delay before the object actually started to move:

TweenLite.to(myClip, 5, {x:500, y:400, delay:1});

Simple. And then of course I had to get in there, try to make things even more user-friendly and that’s when stuff starting blowing up.

(more…)

This is a quickie. I recently had a lengthy form using the <label> tag, and needed to switch label methods. Being industriously lazy, I figured a Regular Expression search and replace would do the trick. Fortunately DreamWeaver CS4 supports Regular Expressions in its Search and Replace dialog box (as long as you turn the appropriate checkbox on!).

In case you’re not too familiar with the <label> tag, it can be used in two ways:

<label>First Name<input type="text" name="firstName" /></label>

and

<label for="firstname">First Name</label><input type="text" name="firstName" />

They look similar, but the salient difference here is that one form of the <label> tag usage encapsulates the form element, while the other does not. There are various (mostly) CSS-related reasons why you would choose one over the other, most notably in terms of whether you would rather be able to have a block surround your text label and input form, or whether you would rather be able to have two separate blocks (which might need to be encapsulated by further markup – such as an ordered list item, as suggested on A List Apart.

Anyway, I was using the first form, and needed to switch to the second form of the tag. The following two regular expressions will do that for you:

“Find” RegExp: <label>([^<]+)(<input.+name=”([^"]+)” \/>)<\/label> 

“Replace” RegExp: <label for=”$3″>$1</label>$2

What’s cool here is that it automatically populates the “for” attribute of the label with the “name” attribute of the input tag, while leaving the rest in place.

Big Disclaimer: There is a good chance that this RegExp will not work for your specific situation, because it is highly specific. If you are not familiar with Perl-style Regular Expressions, you will most likely not be able to make much use of this unless your input tags are exactly the same as mine (ie: the “name” attribute is the last attribute before the closing />, all your spacing is the same, everything is lower case etc). If you would like me to craft a more generic RegExp, leave a comment and I will do one up.

It’s been documented quite a bit on the web already: proper use of  unobtrusive JavaScript in your web pages to achieve not only behavioural separation (keeping content, style and functionality separated into HTML, CSS and JavaScript documents respectively) but also degrade gracefully, to support browsers or platforms where JavaScript is not available. These two concepts form the heart of the development ethic in New Web development:

• Keep your HTML markup completely free of all inline styles and inline JavaScript (in essence, try to use only those attributes inside your HTML tags that are absolutely necessary
• Do not make JavaScript a requirement to be able to access content / functionality on your sites (anticipate the user who is not using JavaScript during the browsing experience)

Using DOM traversal methods such as getElementsByTagName() and regular expressions on the class attribute, you can fairly easily parse through your markup and unobtrusively add in your behavioural JavaScript, eliminating the need to add onClick=”" or onMouseOver=”" attributes inline. However, this is all still done with JavaScript so at some point, the JavaScript code to do this unobtrusive replacement must be executed. Since it can only be executed once all the relevant DOM elements have been loaded, this has been traditionally done using the (inline) onLoad=”" attribute within the <BODY> tag.

For the purists, this represents an issue since we’re not achieving total separation. One migh argue that even putting the <script> tag in the head of the document is too tight of a coupling, but I don’t know of anyone who has cracked that chestnut yet, nor does it seem likely that we’re even going to go there.

Regardless of whether you’re that die-hard, there’s a certain elegance in letting your scripts execute themselves without any further dependencies in the HTML – you include the external .js file in your HTML’s header tag and it takes care of itself from then on. Set it and forget it.

(more…)

Apparently, the Western Digital MyBook line of external USB/Firewire hard drives have their share of problems. Fortunately, I haven’t had (knock on linoleum) the sorts of hardware failures that many have reported.

However, when using the MyBook via 4-pin firewire attached to my smoking Dell XPS Notebook, I have intermittently experienced complete lockups as the Plug and Play driver kicks in and craps out. It hasn’t helped installing the WD Drivers that are highly suspect, so in fact I uninstalled everything on my computer that smacked of “Western” or “Digital” (well, sort of) using Add/Remove Programs.

One trick that appears to be working is quite simple: don’t plug the power into the hard drive until AFTER you have plugged the firewire cable into the computer. Could be blatant superstition, but so far, so good. Okay, to be honest, I’ve only tried it the one time but that time it worked!!

Anyway, just a tip. Try it out if you’re experiencing troubles. Let me know how it turns out. Then buy Seagate.

So, with great trepidation I unleashed just a tiny little portion of CS4 on my primary production workstation a few weeks ago: Flash CS4 and Dreamweaver CS4. I foolishly decided to work on what was supposed to be a dead-simple mini project (with a mini deadline) using Flash CS4. Sort of a “trial by fire”. Well, I got burnt. Badly.

Turned-on by the new Timeline / Motion Tweening model (they finally listened and brought back the AfterEffects-style animation model from LiveMotion – remember LiveMotion?) I jumped into a very simple project: I was going to do a little “slideshow” of images that would simply fade in, grow a little on the screen and then fade out. Sounds dead simple, right? And in CS3 it would have been a snap. Turns out that it IS a snap in CS4, it just took me over two weeks to figure it out, with Jen DeHaan of Adobe’s patient help. Sounds like the cats on the Adobe Flash team made some pretty funky decisions regarding the new timeline. Let me walk you through what I’ve learned.

Or you can just follow the threads on the Adobe Forums here and here.

In a nutshell the problem is this: by default, the behaviour of the new motion tween in Flash CS4 is that it takes over the entire layer that it is on. As much as the Adobe guys claim that this is “object-level” motion tween, it still completely consumes the layer it’s on in the timeline. What’s worse, by default, it’s actually very hard to mix two different movieClip or Graphic symbol animations on the same layer of the timeline. What occurs is that if you have one symbol with a Motion Tween attached to it in a layer, and then on some later frame in that same layer you try to add a Motion Tween to a different symbol, that symbol gets hijacked and actually physically becomes the earlier symbol. That’s right. You drag a symbol onto a layer that already has a Motion Tweened symbol on it, and as soon as you add Motion Tween to the new symbol – BAM! it becomes the other symbol. In fact, even if you look at that symbol in the Library, it’s been changed!

Don’t believe me? Read on…
(more…)

 I don’t like wasting people’s time (what few readers I may have) with rants and raves, but I got hit in the gut twice recently by unfortunate updates.

Being the progressive guy that I am, I upgraded my Adobe Acrobat Reader software (upon ceaseless prompting by Adobe Updater) to Acrobat Reader 9. I also installed Adobe Acrobat (the full version) 8 within a short timeframe. At some point in that flurry of acrobatic upgrades, I lost my ability to display PDFs in my browser window. Explorer, Firefox, Safari, Opera – nada, zilch, bubkus, zeeero. Like so many other busy (lazy) computer professionals, I ignored it and did the Ctrl-click Save As… workaround.

Then today, after having been adamantly refusing to upgrade Firefox 2.0.0.19 to 3 (for a host of reasons – though it is installed on my web development testing laptop), I caught, out of the corner of my eye, Firefox unashamedly installing FF 3.0.5 without my consent. I cancelled, went to my prefs, ensured that “automatic updates” was OFF(!!) and happily went about my business. In due course I shut down Firefox, and later re-opened. To be greeted by the message “Firefox is installing updates.” And that was all there was to it. No choice in the matter – bend over this won’t hurt a bit. Of course that meant that my plugins stopped working (what would I do without Firebug??) and since then Firefox has been crashing like Amtrak in winter. Thanks.

So naturally, the next time I was trying to open up a PDF in a browser and got the friendly error message to the effect of “error – The Adobe Acrobat/Reader that is running can not be used to view PDF files in a Web Browser. Please exit Adobe Acrobat/Reader and try again.” I LOOOOOSE it. I grabbed my computer in a figure 4 headlock, deaked it out with a headfake to the GPU and slammed an uppercut right up the USB.  “Is that ‘can not be used to view PDF files in a Web Browser’ enough for ya?” I gloated.

Solutions, Tom, not problems please. This is a constructive blog.

Right. So, after reassembling my GPU and rubbing some vaseline on my USB ports, I did some research. Many complains, some very bizarrre solutions (from Adobe) involving clearing out some registry keys, everything quite suspect. The most promising option was to open the Reader Software, go to Preferences > Internet and make sure “View in browser” was turned on. It was – so I turned it off, quit the app, relaunched, turned it on and tried again. Nothing. Not even re-loading the browser solved it.

So I uninstalled, and re-installed Acrobat 8. I found a very helpful Adobe Acrobat 8 standalone installer which has worked without a hitch. So until Adobe gets their act together (I’m completely flabbergasted that their Acrobat 9 for Windows is so crippled and hasn’t been fixed yet), do yourself the favour and do not upgrade. If you have, and are experiencing the same issues, do uninstall Acrobat 9 and then install Reader 8.

Happy surfing!

Well, I’ve been delinquent again with my regular posts here. Partially because I’m starting a new blog over at blog.zeitguys.com along with my other co-conspirators. But that’s no excuse.

Partially due to the encouragement of people who’ve stumbled upon some of my other tips and tricks, here’s a quickie that had me stumped for quite some time. I hope it’s of help.

The Issue:

When styling a SELECT tag using CSS and increasing the font size, in Explorer (7) the visual display area of the drop-down menu increases correspondingly. In Firefox, the form SELECT tag does not scale correctly – it cuts off some of the text. The larger the font size, the more the text gets cut off. This is the case regardless of whether you’re using pixels, points or ems. Line-height also has no bearing on it.

It turns out after some experimentation, and a completely random Google hit to some obscure Java CSS reference pages that gave me the idea, that in Firefox you also need to set the same font size in your OPTION tags.

So…

select, option {

	font-size:1.4em;

}

Will do the trick…

So remember, if you’re setting font-size in a SELECT tag, set the same font-size in your OPTIONs as well (unless you’re using a fixed width for the tag, in which case it doesn’t matter).

To me this seems like a basic problem in many Flash-based interfaces. I think Adobe did too, which is why in AS3 they completely revamped their approach to layering display objects.

This leaves those of us stuck back in AS2.0-land (because some customers insist they want their Flash published as FlashPlayer 8! ) scratching our heads. Kirupa, Senocular and other worthies have come up with an interesting technique which keeps a “top-layer” counter, increments it by 2 every time you want to swap depths. While this works perfectly well, there’s something about the technique that, to me (no offense guys: you’re genii), seems like quick-and-dirty (with the emphasis on dirty) code. At some point, I reason, one just HAS to hit that upper layer limit. I’m sure it’s like layer 65538 or something, but still – since you’re using SwapDepths() anyway, why can’t you just find that currently top MovieClip and swap the one you want with it. That way you’re never increasing the top layer count and away you go.

So here’s my take on a bringToFront function. (Note: this is an update to the previous version with some substantial improvements).

Here I’ve added the bringToFront function to the MovieClip prototype, so that you can use it with any movieclip as if it were a native method, like this: myMC.bringToFront();

(more…)