Brad Ormand Music Player

11.29.2014 – Songs & Website

Basically, I spent the whole day programming my painting gallery and music player for my site.  I’m making progress.  It’s looking good.  I have this abstracted music player that I built a while back (about 2 years ago with the HTML5 Media API) that I named B.Audio.js, and it has two components: the player root, and the controller, which takes a root and a PlayerUI as arguments.

From back in the day, I have probably built 50 different audio players in Flash, Java, and HTML4/5 for many different purposes for myself and for jobs over the last 10 years, and about the same amount of video players with audio.  In fact, one of the music players I made that I included in my resume portfolio landed me the gig to work on the website for the video game “The Conduit”.  He saw my work and gave me a call.  That particular one actually included a full, 32-band, real-time FFT spectrum analyzer, as well (in Flash).  And, it was part of the game itself as an in-game puzzle where you went to this site for a reward from the publisher (or something like that – can’t remember exactly what).  None of this is to brag, Haha.  In fact, I feel like I’m writing this to my Project Log to record my thoughts, to tell my ongoing story like I would do in a diary, pretty much like everything else in the Blog.  I felt like including those tidbits would provide context for my current experiences to whomever is the reader. 🙂

So, yeah, back to the BradOrmand.com Audio Player – once I provide the audio root and playerUI to the Controller, then I can configure my client JS to manage the additional functionality specific for this site, while the core player controller can be used with different skins and functionality, even a concurrent player.  I wanted to keep it open to be able to be embeddable or searchable later.  I’ll cross that bridge when it comes closer to the time to augment it…

Brad Ormand Music Player

I have the B.Audio.js dispatching events to it’s subscribers and they just do what they need to do on trigger.  For instance, on the music page, the “onLoadProgress( type, time, progRatio, src )” gets triggered by the core player, and it updates the UI, which it gets in it’s class constructor, but doesn’t know what kind of HTMLElement it is, but just that *is* an HTMLElement, being polymorphic, with those standard properties.  That lets me make it whatever I want it to be in the UI as long as it’s a block element, and the playerUI will operate on it.  Here in this call, “type” would be B.Audio.LOAD_PROGRESS, “time” is the timestamp from the event system from B.js, “progRatio” is how much has been loaded so far 0 <= r <= 1, and “src” is the URL of the track.  So, anyway – that’s the kind of stuff I have been into today. Been back in that world.

Brad Ormand Painting Gallery

I mentioned “trigger”, and that’s the name that jQuery uses for dispatching events, but no, I don’t use jQuery for anything here.  I love jQuery and John Resig and like to use jQuery Mobile sometimes, and I even went to their jQuery Conf when they came to Austin.  But, I like to write things in straight JavaScript pretty much as much of the time as possible – like with document.getElementById and querySelectorAll and classList and element.style, etc…  Tending towards the verb: “write” instead of “use”, most of the time.

Some people think it’s harder or more unmanageable to write straight JavaScript and that they *need* a library or two to do anything.  Some won’t consider it.  I encounter it all the time – libraries are added like candy in a shopping basket: Backbone, Mustache, Underscore, Dojo, Bootstrap, jQueryUI, and let’s throw in Angular because, well, I heard it “was good”. Haha.  I’m just having some fun in a rant-y kind of way (It’s funny because it’s true, and I hear this in person lol)…  But, yeh – it can be taken too far.  There’s a balance.  And, it depends on the project.  For instance, Backbone is not the only way MVC/MV* can be implemented (it’s just one way that became popular), nor is Bootstrap’s reset style the best for every application, etc.  And, I generally err on the side of “get something if I think I need it for my specialized needs“, instead of “start a project with these popular libraries and go from there“.

To be fair, when working on large projects with a diversified team, I really do see the wisdom in using a specified library stack, and I work on a project like that at work, and have in many previous jobs.  In fact, I think it’s absolutely vital to understand the popular libraries very well if you want to get a good JS job in the industry.   However, it’s kind of a fun challenge to write something from the base level and write your own libraries to use (utils, MVCs, DOM tools, etc), without anything to “do it for you”.  You learn about the base level.  And, if you stick with them, they get better and better and better.

I think there’s something great about using what API the browsers provide natively as much as possible, going closer to the “hardware” (as possible).  The new DOM core is much more advanced, lately, with better standards adoption across all browsers.  For instance, supporting IE 9+ and the latest FF, Safari, and Chrome is straight easy without jQuery or any lib, actually, with no difficulty (with things like querySelector, XHR2, addEventListener, some CSS transitions and/or requestAnimationFrame, etc).  If you’re supporting back to IE 6, 7, or 8… well, then – you’ll have to go back to earlier tools invented to use with those.

I do, though, make methods to abstract the funky bits like removing a specific class or getting a calculated style, and for bigger projects make MVC structures, etc.  When there’s an id that needs to be gotten, for instance, I just reach for elem.getAttribute( “id” ) instead of $( elem ).attr( “id” );  And, when there’s a style that needs to be set where a class change isn’t appropriate, such as opacity animation, I just go straight for elem.style;  That kinda stuff.  Sometimes, it’s easy to “lose touch” with what browsers actually provide underneath (with clarity), natively, if you focus so much on higher abstractions.  Promises and Deferreds, for instance… not always necessary.  Never really have been, even with XHR1.

Working with the core – it’s a little bit faster, there’s no overhead to manage, keeps me practiced up with the base level and on the edge of the tech by keeping track of what the browser vendors come out with week by week.  And, it’s really not that different at all from using libs in projects, in most cases – you don’t have even to learn a second (or third or 5 ) API on top of what there already is. 😉 .  Personal preference, too, I guess.

I also do the same with my display programming in C for embedded systems.  I’d much rather be close to the hardware and write the driver myself to learn about the different ways devices operate, what voltages they take, different power-on sequences, the rising/falling edge scheme, and etc…, because it’s something in life that I enjoy.  Again, it goes along with the personal preference.

Anyway, enough about that.  I hope I wasn’t that rant-y, but more presenting it from my point of view 🙂 .

I also mixed down a great copy of “Doing Fine” today.  Just great stuff (compared to what I have done before).  It’s really coming along.  I’m finally getting to the point to where I can just really go in to the studio and ProTools and get what I want done and walk out happy.  But, I didn’t always feel that way.  Now, it’s rolling strong.