Early Preview: New Symphonic Work

Amongst the 3 dozen or so musical sketches I’m working on, this one has bubbled to the surface, mostly because my Mom asked me for a copy, which has encouraged me to take this one closer to completion than anything I’ve done in the last little while.

DOWNLOAD: New Symphonic Movement I (free download for PERSONAL USE ONLY)

It remains unnamed at the moment, though its working title is “Humble Beginnings” simply because it arose from a single, late-night improvisation of a very unique and texture-rich instrument from the German company Native Instruments called ‘Massive‘. Add a little Orchestral percussion and you have something interesting.

Once I started to get into it, I decided to highlight some of the hidden textures and emergent melodies within the texture using standard orchestral instrumentation – cellos, violins, oboe and clarinet, a little french horn. All of this courtesy of Edirol’s Orchestral plug-in. Finally, the Steinberg Grand Piano (de rigueur, and frankly a little overdone in this version – I will be cutting it back with great prejudice: it’s sounding a lot like my old stuff and the ‘Auger Sound’ is getting on my nerves), and a really cool violin sample using my wife’s cheapo Chinese-made violin for an oriental violin solo melody near the end. I call this instrument the “Shing Jea” violin, after Jeremy Soule’s Guild Wars Factions soundtrack (click here for a little sample on YouTube).

Anyway, here’s the first, unmastered cut. Because of the intense dynamics, you have to be careful of your speakers – I will be running it through a compresser and equalizer and other things to get a better loudness ratio before it’s finalized.

Enjoy.

Forge

DF Forge

Reclaiming the

Have you discovered the <button> tag yet? It’s actually pretty cool, making it easy(er) to style submit buttons and the like to do things like, say, put pretty icons in front of the button text and so forth.

The button tag looks like this:

<button type=”submit” name=”action” value=”delete_123″>Delete This Item</button>

You can even put other cool HTML inside the button:

<button type=”submit” name=”submit” value=”resetPwd”><span class=”resetIcon”>Reset Your Password</span></button>

This gives you a lot of control, which otherwise might need to be done with one or more (non-semantic) wrappers outside of an <input type=”submit” /> tag.

The real beauty (for me) of the <button> tag, is that the value that is send to your server-side (PHP, Perl whatever) can be different from the message that is displayed to the user. In the first example shown, you could imagine a list of products, each of which has a “Delete This Item” button. The User sees “Delete This Item”, but the server gets “delete_123″ and, with some very simple string splitting, can figure out what action you want it to do (delete) and what item to delete (123).

Cool.

Well, well, well, this is probably the first time I’ve seen IE break the server-side of things, but they’ve managed to cock that up too. Note that this has supposedly been addressed in IE8, but we’re not just targeting IE8 when we write RIAs are we?

The issue is that IE 6, 7 contravene the HTML 4.0 standard, and send the <button> tag’s innerHTML rather than the value!

Can you imagine that?

So what the server gets (when submitted from IE only) is:

<SPAN class=resetIcon>Reset Your Password</SPAN>

(do note that IE converts to upper case AND removes quotes from attributes as well. Awesomeness.)

All other browsers submit:

resetPwd.

Read the rest of this entry »

Dynamically adding FORM input fields with JavaScript… with the usual workarounds for IE

Came across the most frustrating IE bug (for IE 7 anyway, there are rumours that this has been fixed in IE8, though I haven’t dared to try yet.

let’s set it up: you have an existing <FORM> element somewhere on your page, and for whatever reason you would like to add elements (such as a hidden field, or a textbox) to this form dynamically from a JavaScript function.

(Sane) Non-IE code:

newField = document.createElement("input");
newField.setAttribute("name", "myNewField");
newField.setAttribute("type", "hidden");
newField.setAttribute("value", "it is a secret");

theForm = document.getElementById("myForm");
theForm.appendChild(newField);

Loverly! A little wordy and all that, but hey, that’s what working (correctly) with the DOM is like, and we get used to it. Though we never love it (that’s where MooTools etc come in…)

Of course, if we do a little peeking around with

alert(theForm.innerHTML);

Everything is beautiful in the “good” browsers (FF and Chrome et al) and then we look at IE. Guess what?

Internet Explorer does not allow you to set the name attribute of an element after it’s been created. Yep. It’s a read-only property. element.setAttribute(“name”, “whatever”) fails. silently.

In some peabrained propellerhead way, I can see that this makes sense – IE used to use “name” the way the DOM uses ID, and changing something’s ID after it’s created can cause havoc. If you’re a lazy-ass, short-sighted programmer of course.

But we already knew that that’s a primary job qualification of the IE development team, right?

Enough griping, Tom you ass, what’s the workaround?

IE has this really ugly (mis)implementation of document.createElement() that fails in all other browsers, where you can actually pass the entire HTML element as a string. Not just the node name (ie: “input”) but the actual HTML (ie: “<input name=’blah’>”).

This is the ONLY time you can set the name attribute – on creating the element.

But I mentioned that it fails (errors out) in other browsers.

So, we wrap the whole ugly baby in a swaddling try…catch statement and send it down the river like so….

Ugly-ass Try…Catch Wrapper for Uglier-Ass IE Element Creation Code

try {
  // for IE, curse it
  newField = document.createElement("<input name='uglyBaby'>");
} catch (error) {
  // for all other sane browsers that bothered to read the DOM specification
  newField = document.createElement("input");
  newField.setAttribute("name", "happyChild");
}

// ... and then you can set all your other attributes nicely here for all browsers...

I need to go puke somewhere. Please excuse me.

IE DOM Elements don’t support hasOwnProperty()

Couldn’t find anything really definitive on this, so here it is. Object.hasOwnProperty() is defined by EMACS and is supposed to be present on any (and all) objects in JavaScript.

So this would (normally) make a good way to make sure that a DOM element has a certain method before calling it (particularly to be safe if the DOM object for some reason doesn’t exist as expected)

For example:

elem = document.getElementById("someDOMElement");
if (elem.hasOwnProperty("innerHTML")){
  // ... do something cool with the innerHTML of this element
}

Unfortunately, this technique fails out of hand in IE because, although native Objects do support this method, for some reason DOM objects do NOT. So it will always fail, and more likely give you the dreaded “object does not support this property or method”, which is precisely the reason you wanted to use this method in the first place!

IE can go to hell. What’s wrong with these people?