Adobe's Flex forum

I have discovered what may prove to be a very helpful resource: Adobe's Flex forum. It appears to be a reasonably well-organized community self-help forum, in which Flex users are encouraged to post their questions and answer those posted by others.

Back in the day (by which I mean "the late 1980's," before many of today's eager young Flex programmers were born), I participated regularly in a similar forum: MacApp.Tech$, devoted to MacApp, the first widely-used object-oriented application framework. It took me a while, but I eventually posted a lot more answers than questions. I hope to be able to be similarly useful to the Flex forum's participants, eventually.

Design Patterns

I stopped programming professionally on February 3rd, 1992, when I joined Microsoft as a Technology Evangelist. After that, any time I needed sample code showing how to use some new Microsoft technology, it was more effective for me to have a consultant code it up than to code it up myself. That way, I'd have the code, and a consultant that was up-to-speed on the new technology, too. I could then aim that consultant at companies who I knew were struggling to implement the technology themselves. Very efficient.

Unfortunately, this put me increasingly out of touch with rapidly-evolving programming practices.

A good example is the notion of "design patterns," which were first described (to my knowledge) as such in late 1994, nearly three years after I'd stopped programming. This is a double whammy, for two reasons.

• First, I don't understand "design patterns." It's another learning curve I have to climb. It's clearly possible to climb it, and I will make it to the top eventually, but it's just one more damn thing between me and my objective.
• Secondly, and more importantly, in the 15 years since "design patterns" were first described, they have become so deeply absorbed by the professional programming community that knowledge of these patterns is simply assumed. This is a huge pain in my ass.

For example, I eventually figured out that, to meet my need for "growing arrows," I would need to implement a custom Tween effect associated with a custom Arrow component. So I read Adobe's online article About Tween Effects, which drove me nuts. It seemed to be using three classes (Tween, TweenEffect, and TweenInstance) to do something that I thought could just as well be done by a single class. Since I'm trying to *understand* what I'm doing, rather than just programming by numbers, this apparently-neededless complexity was a real barrier to my progress. Adobe's documentation said nothing about why this complexity was present.

Then I noticed the word "factory," just once, in the About Tween Effects documentation:

• "mx.effects.TweenEffect: The base factory class for all tween effects."

I vaguely remembered once knowing the meaning of the phrase "class factory," which gave me just enough information to connect the dots from the documentation to the design pattern. So, I drive over to my local Barnes & Noble and bought the original Design Patterns book, plus another written specifically for Actionscript 3. These are ladders of knowledge, helping me scale yet another learning cliff.

I recognize that my situation -- of returning to programming after a 17-year hiatus -- is not common, and that Adobe can not reasonably be expected to write its documentation to accomodate such an uncommon reader. However, it does not seem unreasonable to suggest that, when a given feature of Flex relies on a specific design pattern, the feature's documentation should say so, and perhaps even refer to an online description of that pattern.

I do enjoy learning new things, but I *am* first and foremost trying to get a product out the door. It seems like I'm having to do a depth-first search among the roots of every darn language, tool, and framework, platform, and paradigm I encounter along the way -- and I have no idea how many more of these diversions I'm going to encounter. The number seems to be unbounded. That makes it very hard to plan ahead. This concerns me.

Locrian major

I thought I had found another Prime Scale, the Locrian major, but it turns out to be the same as the Neapolitan (which is arguably not a Prime Scale itself).

Animating an arrow along a path

In many places in my courseware, I need to be able to draw animated arrows -- arrows that start at Point A and grow along a line/curve/path towards Point B, thus indicating through their growth the direction of movement.

This seems like it ought to be a fairly common animation task, but I can't figure out how to do it in Flash, without using a zillion key frames, which kinda defeats the purpose. Google hasn't been able to point me in the right direction. I don't want to take the time to code a component for this, but I may have to do so.

From components to lessons

I'm now happy with the current state of my "keyboard component" and the structure of the surrounding application. It's not entirely customer-ready, but it's in good enough shape that I need to start *using* it. That should expose a lot of weaknesses (and, perhaps, strengths) that I would not discover otherwise.

Therefore, I'm going to shift my focus from the development of components (using Flex) to the development of lessons (using Flash). I've hosted the www.igetitmusic.com domain using GoDaddy's free service, and will start developing lessons, which I will post there. I'll shift this blog over there shortly, too.

The free hosting service imposes a number of advertisements on the site, which I won't to have up there once the site is "legit." For now, though, I need to keep my burn rate to an absolute minimum, so I'm happy to have a free hosting option, ads or no ads.

With some help from Jeffrey Houser, I've almost figured out how to share my source code, so I'll be getting that up soon, too.

Re: The Center of All Things

In JiMS iGetIt! Music System, the notes of the diatonic scale (in any key) are named "Do Re Mi Fa So La Ti." What are the names of the notes of other scales?

I am not aware of any standard mapping of these other scales' notes to tonic solfa names, nor of any standard rules for defining such a mapping, nor of any standard criteria for comparing one mapping-rule to another. One possible mapping-rule might be to "maximize the correspondence between one scale and another."

For example, when mapping the notes of the a given scale to tonic solfa, one might reasonably choose to map them to that set of tonic solfa names that maximzed the given scale's correspondence with the Diatonic scale. Using this mapping-rule, the Harmonic Major and Harmonic Minor scales would be mapped to a set of note-names that differed from the Diatonic by only one note. The Harmonic Minor would have Si instead of So, while the Harmonic Major would have Le instead of La. Those are perfectly cromulent mappings, which usefully expose the similarity of these scales to the Diatonic.

However, that's note the mapping-rule that I used in the just-posted online version of JiMS iGetIt! keyboard, however.

Instead, I chose to use a different mapping-rule: maximize the extent to which the scale is centered on Re. Using this rule, it is obvious that all of the Prime Scales

• include the notes So, Re, and La
• are either
• symmetrical around Re (Diatonic, Melodic, Neapolitan, Double Harmonic), or
• are not symmetrical (Harmonic Major and Harmonic Minor), but are reflections of each other around the Re axis.

I don't know that this mapping-rule is any better, and it may be much worse. By what criteria should different mapping-rules be judged? In the development of JiMS, I had only one criterion throughout: maximizing the efficiency of learning. However, I'm not sure that this criterion delivers a clear answer on this mapping-rule question. Exposing the consistency of the Prime Scales' So-Re-La core is a good thing, but is it better (i.e., more efficiency-increasing) than exposing the near-identicality of the Diatonic and Harmonic scales? I don't know.

Certainly the "Diatonic maximization" rule hews most closely to music-ed tradition, which sees all scales in terms of their difference from the "major scale" (including the other modes of the diatonic scale, which is just bizarre). I happily admit to having a knee-jerk reaction against traditional musical thinking. This reaction forces me to ask "why?" about absolutely everything, which has proven to be a very useful habit. However, if I can't find an efficiency-increasing alternative to a traditional practice, then I'll go with the traditional practice, to meet the secondary criterion of "maximizing compatibility."

For example, I would *love* to change the tonic solfa names to something more meaningful, so that the vowels of the names in the diatonic scale meant something, instead of actively conflicting with meaning as the diatonic vowels currently do. ('i' means 'sharp,' except for Mi and Ti; 'e' means 'flat,' except for Re. This is exactly the kind of inconsistency that makes music so hard.) One alternative set of names would be "Do Ra Ma Fo So La Te", with 'u' meaning flat and 'i' meaning sharp, 'o' meaning the root of a major triad, 'a' meaning the root of a minor triad, and 'e' meaning the root of a diminished triad. There are two problems with this alternative naming: it is meaningful only for the diatonic scale, and it would irritate everyone who had already learned the traditional solfa names. The first concern eliminates any efficiency benefit; the second imposes an efficiency cost. Hence, JiMS uses the traditional solfa names, despite their irritating lack of meaning.

What note-name mapping-rule should JiMS use for non-diatonic scales?

Your comments welcome. :-)

The Prime Scales

On a piano keyboard, the notes of the C Major scale have one shape and color (the "white keys"), while the notes that are chromatic to C Major have a different shape and color (the "black keys"). This seems awfully arbitrary. Why C? Why not A, B, or Bb?

On a digital piano, one can easily transpose the keyboard so that any given diatonic scale's notes fall on the white keys. That's cool. But what about other scales? There's more to music than the diatonic scale.

One of the nice things about a "virtual" on-screen keyboard is that one can change the way individual buttons are drawn "on the fly." That allows us to draw the notes/buttons that are in "the current scale" one way, while drawing those that are out of the scale a different way.

The latest version of my Flex iGetIt! keyboard, shown below, allows the user to select one of the Prime Scales from a ComboBox, with the coloration of the keyboard's notes/buttons changing accordingly. The notes of the current scale are the "white keys," whereas the out-of-scale notes are the "black keys."


Why is this a "good thing"?

There are scads of "scale books" that describe scads of "scales." I don't understand this.

As far as I can tell, there are really only a half-dozen scales that are relevant to tonal music -- the previously-mentioned Prime Scales. The scale books are fat with "scales" because

• they confuse scale and mode, treating different modes of the same scale as if they were different scales, and
• they confuse scale and key, treating different keys of the same scale as if they were different scales.

This conceptual confusion can lead to a combinatorial explosion of "scales." Do the math: six Prime Scales times seven modes per scale times fifteen possible keys is 6 * 7 * 15 = 630 possible "scales." Six hundred and thirty! From an educational perspective, that might as well be "infinity." No wonder people hate learning scales! Using the traditional instruments, notation, and theory, there is no end to it. You could study and practice your whole life and never master them all.

I don't see the point. This explosion of "scales" is an artifact of traditional music technology (i.e., traditional instruments and notation). They are not meaningfully distict, except that -- using traditional technology -- they require different notation and different performance gestures. The explosion is not a theory problem; it's a technology problem. Using JiMS, you only have to master the six Prime Scales. Six! That's less than 1/100'th of the traditional number. Two orders of magnitude!

More importantly, by clarifying the relationships between scales, modes, and keys (and chords, and melodies, and tunings, and so on), JiMS inter-relates these important musical concepts, thereby providing a strong theoretical foundation for understanding music.

iGetIt! Keyboard v0.000002

Here's the latest version of my keyboard component:


It looks and behaves much better now. I copied and pasted the code from Flex's Button class into a new class (KBButton) and hacked away everything that I didn't need, which was a lot. I then did the same with the Flex classes needed for programmatic skinning, so that I could draw the keyboard's buttons as I saw fit. The drawing isn't perfect by any means, but at least now I know how control-drawing works.

My next step is to move the sound-generation code out of the KBCanvas (which holds the KBButtons) and into a stand-alone Synth class. In effect, the KBCanvas and its KBButtons (and their KBButtonSkins, and so on) will know only about drawing things on the screen in response to NoteEvents, and the Synths will know only about playing sounds in response to NoteEvents. Importantly, that means that the KBCanvas and the Synth will *not* know about the other. I will be able to change the design and implementation of either one completely indepently of the other. The Flex application will act as the central controller, intercepting keypress events from the user's computer keyboard and re-packaging them as NoteEvents. The KBCanvas and Synth will listen for these events, changing their visual/sonic states, respectively, when such NoteEvents occur. The application will keep its current state in a data structure (the "model") that doesn't know about Synths or on-screen views, either. Hence, a nice clean separation of model, view, and controller (with the application as the controller, and the Synth as a sort of "sonic view").

My progress in implementing these custom controls has been glacially slow, by the standards of commercial software development. But right now, speed isn't the point. It's more important that I soak up Flex's design patterns, Actionscript's idioms, and eclipse's workflow, thereby increasing my overall efficiency, than to get these components done "yesterday." I expect that my efficiency will be improving rapidly from here on out (albeit from a still-low level).

Constructor...and...and

Well, it turned out to be more complicated than "it's the constructor, stupid."

For keyboard events, at least, the event handler has to be installed in the view's application's stage. Unfortunately, the view's application and stage are both "null" when the view's constructor is called.

Therefore, in the view's constructor, I added a listener for the view's "creationComplete" event, which is dispatched at the very end of the view's creation and initialization process.

public function MyView()
{
super();

addEventListener(mx.events.FlexEvent.CREATION_COMPLETE,

creationCompleteHandler);
}

When the view's "creationComplete" message handler is called, the view's application is initialized, but it's stage isn't. So, in the view's "creationComplete" message handler, I added a listener for the application's "applicationComplete" message.

public function creationCompleteHandler(e:Event): void {
parentApplication.addEventListener(FlexEvent.APPLICATION_COMPLETE,

  applicationCompleteHandler);
}

Finally, in the "applicationComplete" handler, the view's application's stage is initialized, allowing me to install listeners for keyboard events, which was the whole purpose of the exercise.

public function applicationCompleteHandler(e:Event): void {
parentApplication.stage.addEventListener(KeyboardEvent.KEY_DOWN, keyHandler);
parentApplication.stage.addEventListener(KeyboardEvent.KEY_UP, keyHandler);
}

This solution requires two "preparatory" layers of event listeners just to get to a point in the initialization cycle where the view's application's stage's state is stable. It strikes me as being an obscure kludge rather than an elegant design. Its only virtue is that is honors encapsulation. It reaches *up* into its super-classes' properties (parentApplication and parentApplication.stage), which is perfectly legit.

The only other solution I could think of was to install the keyboard listener within the scope of the application's code, rather than the view's. This, however, would require having the application "know about" its sub-view's keyHandler function -- that is, reaching *down* into a component's implementation details, which is a heinous violation of encapsulation.

If anyone knows of a cleaner solution, I'd love to hear about it.

Constructors, source code, and best practices

In my earlier post What I Hate About Computer Programming, I described a series of failed attempts and work-arounds that I flailed through in an attempt to solve a given problem.

In it, I wrote:

The right time to add these event listeners is when the PitchSlider's instance is done being created. The Slider class' superclass, UIComponent, has a nice little "creationCompleteHandler()" method that's called at just the right time, too.

Well, apparently, the right time to add such event listeners is in the view's constructors, which I would have thought was WAY too early in the construction/initialization process. The constructor happens to be one of the few methods that isn't marked as "mx_internal" (because it can't be, being a constructor, and all).

How did I learn this? By studying the source code to Adobe's Flex framework, which is installed along with the Flex SDK.

I've spent much of the last few days doing nothing but studying Flex's source code. There's no better tool for learning a framework that walking through its source code, both linearly (reading straight through a file) and interactively (stepping through it with a debugger). That's how I learned to use MacApp (the first widely-used application framework for personal computers) back in the mid-1980's. I don't think there were any books on MacApp then; the source was the only info available. You can hardly walk through a bookstore today without tripping over books on Flex, which is great, but nothing beats access to the source code.

As I said about MacApp "back in the day,"

MacApp is not just a bunch of user interface code, it is a library of accumulated wisdom on Macintosh programming.

These days, "accumulated wisdom" is called "best practice," but it's the same idea.

The more things change...

Solid Components

I've decided that my next task will be polishing up the PitchSlider component to where it implements the "best practices" of Flex component coding, as best I can, and then doing the same for the on-screen keyboard component. The knowledge and skill that I gain from learning to do one simple thing *right* will, I suspect, be much more leveraged than learning to do many things in a half-assed manner.

iGetIt! QWERTY keyboard component, v.000001

Here's my first crack at implementing the iGetIt!/JIMS note-layout on a standard computer keyboard:



PLEASE NOTE: you must click on the component with your mouse before it will start recognizing keyboard presses. Other than that, the on-screen keyboard does not respond to mouse clicks; you play it by pressing the keys of your computer's physical keyboard.

This component is not done by any means. It suffers from myriad annoying little problems. However, the basic functionality is there. You can use your computer keyboard to control musical notes in the iGetIt!/JIMS note-layout.

The pitch slider changes the pitch of "Re0," which is the note controlled by the QWERTY keyboard's 'H' key. This allows you to "change key" to any arbitrary frequency in a one-octave range. It should be noted that the selected pitch does NOT need to match the pitches defined by the standard A4=440Hz concert pitch in 12-tone equal temperament tuning; the structure of (harmonic) musical sound is the same for every frequency and tuning.

I do not propose that such a pitch slider is a good user interface for changing keys during performace. It's just a tool for demonstrating that the pattern of (tonic solfa) notes used by the iGetIt! keyboard stays the same, no matter what frequency is chosen as its key.

Each button displays its QWERTY label, its note name (e.g., Re0 on the keyboard's H key), and the coordinates of that note in tonal space (e.g., [0, 0] for Re0). The note Re0 is the "origin," which sounds the pitch chosen using the Pitch Slider. The pitch of note [x, y] is (x*P8 + y*P5) cents away from the pitch of Re0, where P8 is the octave (1200 cents) and P5 is the tempered perfect fifth (currently defaulting to 700 cents, with no user interface for changing that default). (If you think that sounds complicated, check out the formula for determining the pitch of a note in 12-tone equal temperament.) The coordinates are displayed for debugging purposes; no novice music student needs to see them.

An octave's notes are numbered from Re, rather than from Do as is typical. This is not a feature of the iGetIt!/JIMS music system; it's a bug that I haven't addressed yet. Notes are traditionally numbered from D0 and I see no reason to change that.

Each button's information is drawn poorly, due to problems that I do not yet know how to fix, but it's legible.

If it doesn't work on your browser/computer configuration, please let me know.

"View source..." doesn't work, because I don't yet know how to make the source available. Once I figure that out, I'll come back and make it work.

Thanks! :-)

What I Hate About Computer Programming

By and large, I'm enjoying my return to computer programming after a 17-year hiatus. However, the experience is also reminding me of the things about computer programming that I hated before, and still hate today.

Here's an example.

My PitchSlider component is a subclass of the Flex class named VSlider.  No problems there. In PitchSlider's current implementation, one must specify, in one's application, a "thumbHandler()" function that deals with mouse presses on the slider's thumb (the thing you drag around to change the slider's value, and hence the pitch of the PitchSlider).  This implementation is kinda grungy, because the application using the PitchSlider needs to know a lot about how of the PitchSlider's internal details.  It's a "tightly-coupled" design. What I'd like to do is move the thumb-handling code into the PitchSlider class instead -- hiding it from the application -- and then dispatch a custom event when the thumb is released, advising all listeners that the pitch slider's pitch has changed. This latter approach would enable a looser coupling between the PitchSlider and its container/application, which is a Good Thing.

Unfortunately, writing PitchSlider this way appears to be *&^%$#@ing impossible.

All I need to do is override three methods of VSlider's superclass, named Slider: onThumbPress(), onThumMove(), and onThumbRelease(). My overrides would call the inherited method and then (respectively) start playing the current pitch; change the current pitch; and stop playing the current pitch (then dispatching a custom event indicating the final pitch).  That should be no problem, I figured; this kind of "extension by subclassing" is exactly what object-oriented programming is all about. 15 minutes, tops.

But noooooo.  Inside of the Slider class, these methods are hidden away in a special "mx_internal" namespace. A Google search on "mx_internal" indicated that any method flagged mx_internal is not to be overridden because Adobe (creators of the Flex framework, of which the Slider class is a part) might change its implementation in future, and therefore wants to be able to say "here there be dragons; use these implementation details at your own risk."

Excuse me?  I can't override any of the three methods that uniquely distinguish sliders from all other controls? WTF? When I was napping with Rip van Winkle, did subclassing become passe?

There had to be a way around this. 

Google led me to a discussion of how to get past the "mx_internal" barrier: just import and then use the mx_internal namespace.  Good enough --  I'd use this work-around in the short run to get the PitchSlider working, so that I could focus my attention on learning how to use try/catch blocks or some other more-pressing concern.

But noooooo.  The work-around works when *calling* hidden methods, but not when *over-riding* them. Instead, the compiler barfs an error message that is helpful only as the basis of another Google search.  Googling it, I found an official Adobe bug report saying that the work-around didn't work when using it to override methods.  This required *another* work-around, to wit, omitting the keyword "override" in the definition of the function.

Fine, OK, whatever. Omitting the "override" keyword did indeed allow the code to compile, thus successfully working around the compiler bug. I figured that I was home free.

But noooooo. Running the application threw up a run-time error, telling me that I had illegally overriden a Flex method.

*&^%$#@er - *&^%$#@ers!

Apparently I was simply not going to be allowed to do the obviously-right thing by overriding these *&^%$#@ing methods.

Deep breath. Om mani padme hum. I am but scum on Buddha's foot; all striving is vanity; and this *&^%$#@ing approach isn't helping me to attain any *&^%$#@ing enlightenment anyway, so forget it and move on (as the Dalai Lama might say).

Time to go to Plan B: have my PitchSlider add event listeners to itself, so that it can "notify itself" when its *&^%$#@ing super-class is done handling thumb press, movement, and release actions.

The right time to add these event listeners is when the PitchSlider's instance is done being created. The Slider class' superclass, UIComponent, has a nice little "creationCompleteHandler()" method that's called at just the right time, too.  I figured that I would just override that method to install my event listeners. It's not an "mx_internal" method, either, so that should work.

But noooooo.  creationCompleteHandler() is marked as a "private" method, which means that it can't be overriden, either.

*&^%$#@er - *&^%$#@ers!

I was never a great computer programmer.  I was good, but never great.  And I know that I've been out of the loop for an outrageously long time, so...perhaps there's some new way to accomplish this task that would be patently obvious to anyone lacking grey hair. I'd welcome the opportunity to become enlightened.

But *&^%$#@us *&^%$#@ing *&^%$#@st, I absolutely HATE this cascading series of problems, work-arounds, and work-arounds for work-arounds, with each level delaying the release of my product by hours or even days.  I just want things to *&^%$#@ing *work*.

(It's exactly this kind of short-tempered frustration that drove me to create the iGetIt! Music System in the first place, of course.  If I'd been more patient, I would have just learned music the way everyone else did...the hard way.)

Guido d'Arezzo and "movable Ut"

Almost a thousand years ago, Guido d'Arezzo invented the idea of teaching novice singers to "sight read written music." Before then, a singer had to *memorize* every chant in the Church's canon. To support his radical idea, Guido developed new technology (the musical staff and solfeggio) and new pedagogy (such as the hymn Ut queant laxis, which facilitated learning solfeggio). Using these innovations, Guido cut the time needed to train a competent singer from ten years to "one, or at most two" -- an efficiency gain of at least 5:1, and perhaps 10:1.

Bill Sethares was kind enough to loan me book with English translations of Guido's surviving writings. This book is so out-of-print that neither Amazon nor Google Books has it. Guido's writing make it exceedingly clear that his staff did NOT denote pitches, but rather denoted the same thing that the iGetIt! staff denotes: intervals-from-Do (or Ut, as Guido called it).

As the translator, Dr. Dolores Pesce, summarized (p. 23): "For Guido, D as a sounding pitch is not fixed, but D as a notational symbol has a very fixed meaning--its intervallic context."

That is, D did not denote a pitch (frequency); it denoted the same thing that Re denotes in "moveable Do with a La-based minor:" the note that is the center of symmetry in the diatonic scale. Guido denoted intervals, not pitches--just as does the iGetIt! Music System (formerly known as the ThumMusic System). This is not an interpretation; Guido says this very clearly in his own words (albeit in terms of a hexachordal system that, unlike the iGetIt! Music System, doesn't temper out the syntonic comma, and is hence much more complicated).

Why did music notation evolve towards notating pitches? I don't have a good reference for this, but in a nutshell the answer is: instruments. Guido's notation was intended for unaccompanied singers, for whom changes of key were trivially easy.  Heck, for singers the tough problem isn't changing keys, it's staying in any one key. A person's natural tendency is to sing flatter and flatter as one's vocal muscles tire.

But instruments are different. To make instrumental sight-reading possible, each note-head on the staff needs to correspond to a particular instrument-control gesture, and for most instruments, that gesture is different for every pitch, so pitches--not intervals--need to be notated for musical instruments.

Point being: the iGetIt! Music System is doing it "old school" -- very old school. We can do this because a performer using an isomorphic button-field, combined with electronic transposition, can easily play a piece in any given key...just as Guido's singers could.

We're bringing music notation back to the future.

It just goes to show that, as Guido would have said, plus ça change, plus c'est la même chose (except, of course that he would have said it in Latin).

MVC

After squirrelling around for a couple of days trying to come up with an architecture for my first suite of Flex/Flash/AIR components & apps, I eventually settled on... MVC (Model, View, Controller). Flex's generalized dependency (binding) mechanism and event model make this very easy to do (so far, anyway).

JIMS

My approach to displaying and controlling musical information has two names:

• Academically, it's the Isomorphic Music System (IMS), a name that has no trademark issues.
  
• Commercially, it's the iGetIt!(tm) Music System, which obviously DOES have trademark issues.
  

These two names have the same acronym: IMS. It just occurred to me that I can call it JIMS, thus making a pun on my first name. The J would stand for JIMS, of course, thus making it a recursive acronym, which are much beloved by nerds everywhere.

I wouldn't market the system at JIMS -- iGetIt! is a much better marketing name -- but I still think that JIMS is funny. So, to the list above list of names, I'm adding:

• Nerdily, it's JIMS.
  

Clearly, I'm nerdy, and proud of it.  ;-)

First Flash control: PitchSlider

To develop my forthcoming music education courseware using Adobe's Flash/Flex/AIR, I'm developing a suite of components that display and control musical information.  This is going well, considering. Although I have a Computer Science degree, I haven't written a line of code since 1992...17 years ago.  Climbing up the Flash/Flex/AIR/ActionScript/Eclipse/XML learning curve is fun but challenging.

My first Flash control is a slider that allows the user to choose a frequency (it works best if you drag the thumb slowly):

No big deal, but writing it helped me understand a lot of stuff, including Flash 10's new sound synthesis API SampleDataEvent. 

I've seen other posts in which the source code to such controls is easily available (by right-clicking on the control and choosing "View Source" from a pop-up menu), but I don't know how to support that feature. I can't find any documentation for it; apparently it's so "obvious" that it is never described. If a reader could please tell me how to add support for Flash's "View Source" feature -- in full newbie-tutorial detail -- I'd be happy to make the code available for this and subsequent iGetIt! controls.  (iGetIt!'s proprietary value is in the patent-pending iGetIt! Music System and the lessons based on it, not in its Flash controls.)

I expect to use the PitchSlider control (or something like it) to show the student that musical pitch (frequency) is continuous, varying in a smooth and unbroken manner. Some frequencies have names (such as 440Hz, which is named A4), and some do not, but all are musically equal. The structure of music is the same for all frequencies.  Obviously, this ignores a ton of psychoacoustic issues like the human ear's range of hearing and critical band, but... close enough, as a first approximation.

Thumtronics is dead; long live iGetIt! Music!

I've copied the contents of my old ThumMusings blog into this new iGetIt! Music blog, to provide a bit of continuity.

It's over

Thumtronics is dead.  :-(

For years now, I've been trying to raise money to finish the Thummer's  design and to manufacture its first production run. In that time, I received many promises, but no checks. Now, the global financial crisis has dried up all funding for early-stage companies. Thumtronics is now in bankruptcy.  It's over.

To Thumtronics' investors, I offer my sincerest apologies. I did my best. I put everything I had into it -- every penny, every hour, every effort.  I'm sorry. I hope that you will forgive me, and more importantly, that you won't hold my failure against the next guy who comes to you with a great idea.

I've tried diligently for years to license Thumtronics' patents to other companies, with no success. Most of Thumtronics' (pending) patents will fall into the public domain due to non-payment of fees.

Once Thumtronics' bankruptcy is final, I'll place the design documents for the Thummer prototypes on the web, as the basis of an open-source hardware project. Completing the Thummer's design would be a great team project for an electronics/mechanical engineering class. Once an open-source reference design was completed, anyone who wanted to make Thummers could do so.

For example, a firm like Hong Kong's Medeli to work with HK UST's students to finish the Thummer's design, then to collect partially pre-paid orders online until receiving enough orders to justify making the initial production run. If nothing else, this would be a great way to identify (and hire) the university's best students.

Hopefully, through an open-source approach, Thummers will someday become available.  I hope so, because I want one!  :-)

In the meantime, I've started a new company, iGetIt! Music. It has no website yet (although I've registered the domain). iGetIt! is just me and an Internet-connected computer in my bedroom -- a classic micro-ISV. iGetIt! is focused on developing online music education courseware using the computer keyboard (and possibly iPhone) as its input device. iGetIt! doesn't have the potential to rake in the big bucks that Thumtronics had, but if I'm lucky I ought to be able to make a living out of it. In these troubled economic times that's a whole lot better than nothing.

My biggest challenge now is getting back into the swing of computer programming. It's been 22 years since I got my Computer Science degree, and 17 years since I last programmed for a living. I was on the cutting edge of object-oriented programming back then, and mostly I'm finding that today's tools make it very easy to do things that required lots of hand-coding back then.  I'll start a new blog shortly to document my progress and share what I've learned.

So...Thumtronics is dead. Long live iGetIt! Music!  :-)