One of the applications I developed was corrupting data every now and then, and I always assumed it is a temporary system failure or unavailable database. When this became a real issue I bothered to investigate further and the problem turned out to be one of the most common (well not common enough for me to pay attention I guess) thread safety issues of core Java classes. If you’re thinking your code is not multi-threaded and you don’t need to care about this, think again because most application servers (Tomcat, JBoss, etc.) create multiple threads without you even knowing about it.

As this is a pretty easy mistake to make, I decided to document the solution here…

The mistake:

I had a static variable to define a central date format, which I used through out my application.

public static final SimpleDateFormat DEFAULT_FORMAT = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS");

So when I need to parse a date, or format it I simple make a single line call to:

Constants.DEFAULT_FORMAT.parse(date);

Turns out there are many geeks out there who were looking for something like this and I started to get requests for new features and bug fixes. More interestingly I started to use it myself in music projects. So I decided to take my simple Musician’s Helper application and promote it to its own web page, fix up a number obvious issues and make it available to anyone who is willing to use it. Now an enhanced version of Musician’s Helper is available at:

http://music.isallicare.com

As you might have noticed, I changed the name from “Musician’s Helper” to “music.isallicare.com”, because I already owned this domain and it made sense to recycle it rather than inventing another name. After all I registered this domain name to keep track of things I care about, and music is no exception.

I want to go over the application a bit today and give you an overview of its features, information about how you can get started to use it and what you might expect in the future in terms of new functionality. If you have been following my earlier blogs about music theory, most musical theory concepts can be modeled with the simple set theory, because there are essentially twelve notes and all scales and chords can be defined as a subset of these 12 notes. Music.isallicare.com is a tool that performs these calculations and shows the user the notes that make up a chord or a scale in a number of different views.

Currently the application supports a “Notation View” and a “Table View”, in which the notes that belong to a scale or chord are shown for a specific key. When you first load the application, the initial key is set to “C” and the scale/chord is set to a “Major Scale” (see Figure below, and feel free to click on it to visit the web site).

Music.IsAllICare.com initial page screenshot

The above screenshot is from a “Notation View”, with which most musicians are probably are familiar with. If you click on the tab that says “Table View”, you’ll see the same scale in a Table View as shown below. This view, which I kind of invented, is nothing more than a linear version of a common degrees circle. It shows the degrees on top and corresponding notes at the bottom. The notes of the scale or chord are highlighted with blue. As you can see, the C Major Scale is composed of C,D,E,F,G,A and B.

Screen Shot for Table View

Now let’s change the key, or in proper music lingo, let’s transpose to another key. You can transpose to another key, say to F, by simply clicking on the F on the left panel, or by choosing the “Transpose Menu” and clicking on F.

Transposing the Key

After you click on F, the notes on both Views are updated to reflect the changes. The F Major Scale is composed of F, G, A, Bb (B flat), C and D.

F Major Scale

You obviously can repeat the same for any of the available 12 keys to immediately see which notes belong to your major scale.

The other important feature of the application is to show different scales or chords. If you click on the accordion panel on the left side of the screen titled “Scales”, it will show you a list of most commonly used scales. Currently the application supports the following 8 scales:

As in the case of the keys, simply click on the scale you want to select and all views and titles will be updated dynamically. For example, to see which notes are in the F Diminished Scale, simply click on “Diminished Scale” link on the left.

F Diminished Scale (Table View)

The F Diminished Scale has the notes F, G, Ab, Bb, B, Db, D and E. Needless to say you can view the Notation View by clicking on the appropriate tab as well.

F Diminished Scale (Notation View)

The Chords Tab on the Left Panel works pretty much the same way the Scales Tab does. I included most of the commonly used Chords and all you have to do to see the notes contained in that chord is just to click on it.

Now that we covered the basics, I like to go over a couple of other features, you might want to have a look. One of them is the Link to this page feature. On any key scale/chord combination you can click this button to generate an HTML code that links directly to the page you are currently viewing. This might come in handy while you are blogging and need to refer to a Chord or a Scale.

Link to this page Feature

Another new feature is the Alternate Names for Chords. There are a large number of names and/or symbols associated with different chords (which sometimes gets quite confusing), and now the application gives a list of commonly used alternate names and symbols, where they are available.

Alternate Chord Names

Before  I conclude today’s Blog, I like to list some of the possible future feature enhancements and known issues. If you have other features in mind, have software bugs or content inaccuracies to report, please drop me a line and I’ll try to fix them.

• A Piano View
• A Guitar Keyboard View
• A Bass Keyboard View
• Allow the use of sharps as well as flats
• Use natural sign after a flat sign on the Notation View
• Add modal scales

In the distant future

• Allow to upload Lead Sheets and the ability to transpose them
• Include common progressions and the ability to transpose them
• Show chord inversions

As private and public keys can be used interchangeably, when someone uses his private key to encrypt something, anyone should be able decrypt that message with the corresponding public key. At first this looks totally pointless, as why would someone like to encrypt something others can decrypt using a publicly available key after all? The answer is because by encrypting something with your private key, which can independently be verified to be yours (using your public key), you are essentially certifying that is was created and encrypted by you.

This is not very much different than ordinary ways of proving authenticity; such as sealing an envelope, signing a document with your hand writing, sealing a parchment with seal wax, etc. They all are some sort of, so called “temper evident” containers that provide the recipient some level of guarantee of its authenticity. “Temper Evidence” is a very important concept as certification wouldn’t mean anything if we were not able to verify “what” was actually signed or sealed as much as “who” it was signed by.

So how do we know that someone has not altered a message before we had a chance to view it? When a message (or any computer file for that matter) is encrypted with the originator’s private key, it can be decrypted by anyone who has access to the originator’s public key, which will automatically verify the authenticity of its origin. If the message has been changed even by a bit, the decryption will entirely fail, so the third party would know that the message was altered. There is however a practical issue here as the message recipient needs to decrypt the message to be able to read it. If the recipient doesn’t have the needed software to decrypt the message, or if the message has been corrupted because it was tempered with, or even in the case where the recipient simply isn’t willing to be bothered by decryption, s/he will not be able to read the message. Another issue is that encryption and decryption operations are CPU intensive, and it will get progressively longer to decrypt as the file size increases.

The hash algorithms (see my related Blog Entry here) can help solve both problems. A hash algorithm creates a small fixed-size digest of a file of any size and will squish the original file into a fixed, much smaller size. In other words, any file regardless of their size, will create a relatively small signature that is very hard to temper with. When this smaller version of the payload (i.e. the hash of the original document) is encrypted with the originator’s private key, the recipient can independently hash the original message again and compare it with the hash that comes with the message (of course after decrypting it with the sender’s public key first). This therefore both improves performance significantly by keeping the cryptographic operations to a fixed small size and also retains the original document in the clear, which enables anyone to be able to read it whether they have the infrastructure to validate signatures (i.e. able decrypt) or not.

Now we can go back to our “drop box” from my previous blog entry to explain this better. We used the analogy of ordinary mail boxes to show how Public Key Encryption works.  Now take the same box, and topple it over so the top door is locked with your private key, and the key for the bottom door is attached on the lid with a chain (i.e. it is public), so anyone can open it. If you had an announcement to make, but wanted to make sure that everyone knew it came from you and not from some impostor pretending to be you, you can simply lock copies of your announcement in the top box. Assuming that there is a fancy mechanical mechanism to dispense one announcement at a time, and your audience cannot reach in to replace your original messages; you are essentially signing your announcements.

Not exactly used for security reasons, but vending machines are probably the closest examples of our box model. When you are buying a pop or a candy bar, because they come from a locked location, you have some level of comfort that the contents are not tempered with. The sealed bottle lid or candy bar packaging serves a similar purpose as any alteration in the packaging will alert you. Automated newspaper vending boxes are probably the closest in terms of functionality and appearance to our boxes. Someone locks the newspapers in the top box and newspapers are dispensed at the bottom one at a time.

Newspaper Vending Machines

As is the case of PKI, we can build a box which will serve both functions at the same time:

• keep your inbound messages secure and secret (encryption)
• sign your outbound messages so people believe that they are coming from you (non-repudiation)

So our PKI box design now looks like this:

1. The top door works like Canada Post boxes. It is locked by your public key, which is attached to the lid of the door. Anyone willing to give you a secret message can open the top door, drop the message in and close the door again. The message will drop to the middle section once the door is closed.
2. The middle door is locked with your private key. This is like a safe deposit box and serves two purposes. For one, it keeps the messages that were dropped for you through the top door. And it also keeps your announcements that will be received from the bottom door, which is explained in the next bullet point.
3. The bottom door is again locked with your public key which is attached to the door for convenience. Just like a newspaper vending box, the front door is probably transparent, so your friends can see that you have an announcement to make. As the only way to place these messages in the third box is to drop them from the second l(locked) evel, it gives them a level of confidence that you actually are the author of that announcement.

Public Key Encryption Box

Now there is only one problem. Even if we assume that the box is strong enough to withstand abuse, how do we know that someone didn’t replace the entire box? If someone did so and fooled your friends to believe that this is your box, he will be collecting your secret messages and even making certified announcements impersonating you. So “Quis custodiet ipsos custodes?” or “Who will watch the watchers?”.

This is not a technical problem, it is a fundamental issue of trust. Who do you really trust? Someone you know, the government, family and friends, or no one? Take a real life case where you are trying to get your passport, which is a document that makes a foreign country believe you are who you say you are. At the top level another country trusts your country. Then the government trusts a hierarchy of officers who are in charge of issuing passports. Then this government officer (or a number of them) views your application to decide to give you your passport or not. Once you receive your passport you now have a document that contains a “chain of trust” you can use to cross borders.

In the PKI world it is not much different. As anyone with the right software or mathematical background can generate two prime numbers, someone to have a public and private key pair doesn’t prove much about his identity (although they are perfectly OK to encrypt and decrypt). So the a similar concept of chain of trust exhibits itself in PKI as well, which is achieved by simply signing the public credentials of key owners (collectively referred to as a certificate). Such signing authorities are called Certification Authorities (CA) and their trustworthiness is somewhat warranted by the fact that they are either governments, huge companies or security solution vendors that are audited by independent third-party authorities. In practice, whether someones certificate will be trusted or not pretty much depends on whether your operating system, browser, or cell phone comes with the root certification authorities’ certificate.  The software then climbs up your certificate chain to see if it can trust anyone who vouched for you.

It is also possible to emulate the chain of trust in the world of boxes. All you have to do is to put your boxes in bigger boxes, or rooms to make it a better example. Just like the safe deposit boxes at a bank, we can put our boxes in a room that has a locked entry. Simply because there is no free entry to the room, you are more likely to believe that the box you are getting a signed message from is authentic. It is a lot harder to swipe boxes now, and the message owner probably was escorted inside with the room key owner essentially vouching for the box owner. If you can envision many rooms in a building, each of which containing a number of boxes, you pretty much get how chain of trust works in PKI as well. The same question still remains though. How do you trust the top level entity? The answer is “you just do” because either top entity is too big or well known to suspect, or is trusted by another entity that is.

And this concludes my “An Outside the Look at Public Key Encryption” trilogy. Next time you need to deal with Public Key Encryption, remember that it is all that different than a post box screwed on a newspaper vending machine.

As part of my job I design and implement security software that uses PKI as its basis, and often end up giving crash courses to a wide variety of audiences; ranging from software developers to business people, or customers who are not necessarily well versed in the area of information security.

I won’t try to claim that the mathematics behind PKI is simple, just because it isn’t. But neither is the physics behind semi-conductors, yet very few of us have a problem using a flat screen television or a computer. I believe the real difficulty of understanding PKI originates from the fact that most people don’t have a visual analogue they can use as a reference point, which in many cases makes complex phenomena a lot easier to grasp.

At least that’s how it works for me. So when I started to work with cryptography and PKI in general, I started to look for objects that are analogous to certain cryptographic concepts. Over time I came up with a number of “boxes” that provide good physical representations for symmetric and asymmetric encryption, signing, trust chains, etc. which can sometimes get tricky to visualize.

When I’m working on a security system design, I visualize these boxes, often multiple boxes working together to solve one specific problem. So if you are trying to understand PKI and textbook definitions are not working for you, read on and my boxes might just help.

Symmetric Encryption

Let’s start with the simplest form of encryption. As I have explained in one of my earlier blog entries, symmetric encryption means that the same key is used both to encrypt and decrypt the same object. This is analogous to a simple box with a lock on it. Not much different than a locker you’d find at a gym, or a locked room, or a safe deposit box.

It is a closed box, so nobody can open it unless they have the key. If you have something valuable and don’t want others to have a look at it, you just simply lock it up in your box and keep the key secret. Similarly, if you have a secret computer file, you encrypt it with your key and only those who have access to that key can decrypt it back. In either situation you use the same key to lock or unlock your secret.

As are symmetric cryptographic algorithms, some boxes are stronger than the others. Actual box keys and cryptographic keys have similar properties as well. Whether they are used by a cryptographic algorithm or a wooden box, the “keys” can be objects (a metal key or a X509 key file) or just some information (numbers you memorize to open a combination lock or your encryption password). Symmetric encryption is perfect to keep secrets, but has its limitations to “share secrets”.

Let me explain why locking and sharing doesn’t work well with a real life example where a group of people, say 4, are
using these boxes to exchange secrets. Think of 4 school boys trading secret messages with each other. If everyone kept their secrets to themselves, they would need 4 boxes and 4 keys.

A
B
C
D

That’s trivial enough, one box for each boy and a key to lock/unlock it.

If Boy A wants to trade secrets with Boy B, then they’ll need a separate box just for that, because they cannot give their own keys to the other boy, which will reveal their own personal secrets. If we assume each boy needs a separate box to share secrets with another boy now we need another 6 boxes and 12 keys.

A and B

A and C

A and D

B and C

B and D

C and D

It doesn’t even end there. What happens if 3 boys want to share secrets now? They cannot use their individual boxes, or their common boxes with either of the other two boys. So they will need 4 more boxes and 12 more keys:

A and B and C
A and B and D
A and C and D
B and C and D

If these 4 boys want to share secrets among them (and keep the girls out), they need yet another box and 4 more keys for that

A and B and C and D

Even with only 4 people trying to trade secrets we ended up with 21 boxes and 32 keys. Each boy has to manage 8 keys and 8 boxes if they want to share secrets with 3 other boys.

Try the same thing with 5 people and you’ll end up with 31 boxes, try it with 10 and you’ll need 1023 boxes. Before you reach anywhere close to the population of the town you’re living in, you’ll need more boxes than the stars in the sky.

This is why symmetric encryption can not be used as a reliable and scalable means to exchange confidential information among multiple people. In addition to the exponential growth of boxes and keys that are needed, there is another major reason why symmetric encryption is not a good fit for secure communication. These keys should somehow be distributed to individuals. In the above example, boys can simply swap them during their recess time. But in a real life scenario where parties are not physically at the same location, and in most cases, are not even acquainted with each other, distribution of keys is a major problem. Because the Internet is not secure (at least for now), they cannot send the keys via email. To secure an email you can use encryption, but before that you’ll have to agree on an encryption key, which takes you back to where they’ve started (i.e. you need to share that key to make your email secure). This paradox, sometimes referred to as “Key distribution Problem”, is the other major reason why symmetric encryption is not suited for securing a communication.

Public Key Infrastructure was invented to solve this problem, and I’ll show you how to build a PKI box next week.

I believe a good GUI framework needs to accomplish a number of things:

• It should be easy to write and test
• It should be well documented
• It should look good out of the box
• It should be robust and bug free, should work with all major browsers
• It should be extensible

Marketing presentations and demo applications can give you only so much information about a technology. After 6 weekends of development following are my observations about the Dojo Toolkit:

Coding and Debugging with Dojo

Writing JavaScript code has always been hard. Maybe just because of the “script” in its name, this language has rarely been taken into consideration for any serious project. Part of its bad reputation can be attributed to haphazardly inserted script snippets into HTML, mostly by non-developers, which are responsible for many less than perfect examples of Javascripting out there. As any other language though, if you spend enough time and effort to design your software and write it by abiding commonly accepted development practices,  I don’t think JavaScript is any worse than other scripting languages. This experience taught me to take JavaScript more seriously and use a good IDE to work with it. To implement this project I used my favorite IDE, Eclipse Galileo Edition with a number of extra optional HTML/JS plug-ins. Eclipse is open source and free, so I highly recommend you to give it a shot if you intend to use Dojo Toolkit as part of your project. For your reference, I use the following Eclipse plug-ins and I am pretty happy with the real time syntax checking, dynamic highlighting and other usual features that come with any good IDE.

I don’t debug Javascript within the Eclipse platform, and I am not even sure if this is possible at all. I instead use Firebug plug-in on Mozilla Firefox. This combination however didn’t work that well for this project. So I experimented with Google Chrome debugger and recently IE 8′s debugger for Javascript. As no single debugger came close to satisfying my needs, I used all three. The cross-browser problem I experienced last week also taught me the hard way that, it probably is better to test the code on all three major browsers as you go.

In general coding with Dojo is quite simple and painless. Just be very careful with your HTML syntax and CSS styling as these sometimes prevent Dojo widgets to render correctly. I also recommend you to keep your Javascript in a separate file and not embed into your HTML code. These are my overall ratings for coding and debugging experience with Dojo Toolkit:

Ease of coding:                9

Ease of debugging

with Firefox/Firebug:      5

with Chrome:               7

with IE 8:                 8

Ease of reading source code:   8

Dojo Documentation

Dojo is reasonably well documented for the starter and the online documentation covers most usual and common features. Two problems I had with the documentation in general were:

1. They often are a bit sketchy and/or not complete, and at times they are not always in sync with the code. Examples do not always work.
2. Documentation is dispersed among many different sources and one needs to fish through tutorials, reference documentation and mailing lists to find what they are looking for.

Being a new technology the available online sources for code samples, tutorials and examples are somewhat limited as compared to other technologies. Just to give you an example, my only weeks-old blog entries about Dojo show up on top ten of many Dojo related Google searches, which as flattering as it is, indicates how rare Dojo related online documentation actually is.

I personally figured out how to overcome some challenging tasks, such as overwriting methods in core classes, changing the way certain widgets work, or debugging obscure errors by ether reading the source code or by analyzing the process flow in a debugger. As more people start to use this technology, I believe the documentation will improve both qualitatively and quantitatively.

Document availability:                         7

Document quality:                              7

Third party examples, tutorials, code samples: 6

Looks

Looks are important, and I believe this is where Dojo shines most. If it was not the sex-appeal of Dojo, I would probably have chosen other competitive technologies such as GWT by Google or YUI by Yahoo, which seem to be more mature and stable. What interests me more is to be able to do things in a web browser which people believe is not possible at all: such as dragging and dropping objects, having slider controls, animations, etc. What I like about Dojo’s UI design is that I don’t have to do anything extra to make it look good. As a matter of fact, the less you touch the default design theme, the better off you are.  Dojo comes with 3-4 decent themes you can choose from. You can use third party themes or create one on your own as well.

The visual design is consistent among different browsers as the themes handle most of the cross-browser issues seamlessly. My favorite web sites which helped me a lot while working on Dojo GUI visual designs were:

http://dojocampus.org/explorer/

and

http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/themes/themeTester.html

The former demonstrates most (unfortunately some widgets are missing on that page) available Dojo, Dijit and Dojox widgets with links to relevant documentation. The latter is a theme tester, which again has most of the available features and lets the user switch the themes dynamically to allow them see how different controls look in different themes.

Looks:                    9

Available Themes:         7

Ease of extending Themes: 7

Stability

Frankly I haven’t come across a major bug so far which prevented me from doing what I intended to. Having said that, I had hard time in a number of cases, most of which turned out to be issues unrelated to Dojo libraries, but made it malfunction anyways. For instance some Dojo layout objects would not render on the screen if a hard-coded size is not provided. You might therefore end up with an empty page with no way of knowing why your perfectly working application disappeared after you only played with some CSS styling. In my opinion style should never break the code and objects should fall back to some default size if user doesn’t provide any. Another issue was where the order of loading scripts affected the way the page was rendered, which again was fixed by simply changing the scripts’ location on the HTML  page. Last week’s issue with IE again is a good example of how not closing a simple <span> object can break the entire application on IE, whereas Chrome and Firefox can somehow handle it as if nothing happened.

In general though I would rate Dojo as a stable toolkit, yet one with a steep learning curve and not quite enough reference material to help you along the way.

Stability:                    8

Robustness:                   7

Cross-platform transparency:  8

Extensibility

Although I haven’t written about this much (yet), I have been experimented with Dojo Drag and Drop functionality and was able to overwrite a couple of standard methods to change their behavior to suit my needs. Figuring out how to extend a class took me some time as I am used to more advanced object oriented languages such as Java. But once I got the hang of it, it is actually quite straight forward to extend existing functionality and overwrite it with your own implementation. I implemented my drag and drop methods for an earlier version of Dojo and when I upgraded to the newer version they just kept working without a glitch. I didn’t have to download the source code to extend the functionality either, so I am quite comfortable that one can tailor any existing object into their specific needs easily. The harder part is actually to read the source code of the original method and understand what it actually does.

Ease of extensibility: 9

Flexibility:           9

After this short evaluation of the Dojo Toolkit, I like to conclude this series with a run down of latest improvements of Musician’s Helper, which gracefully served as a reference application for my experimentation over last couple of weeks. I made some final improvements this week, most of which are not directly related to Dojo technologies:

• I improved the left panel where I changed the visual design and enabled highlighting. So the user now knows which key and scale/chord combination is selected at any time.
• I implemented the notation view with a little bit of HTML trickery and a lot of image processing. It still has a number of issues I  have to take care of, but it does what it is supposed to do: shows the notes of a scale or a chord for any given key.
• I also implemented a custom initialization logic, where I can initialise the application with a certain key-scale/chord combination directly through a URL. This is quite useful for someone who is talking about a certain chord or scale and needs a direct link to the correct key-chord/scale. For example if I like to draw your attention to a Ab Diminished chord, now I can provide the direct URL as:

http://karul.org/etc/mhelper/mhelper6.html?key=Ab&sc=Diminished_chord

or if you want to check out D Whole Note Scale you can click on:

http://karul.org/etc/mhelper/mhelper6.html?key=D&sc=WholeNote_scale

I’m planning to polish the Musician’s Helper a bit more, possibly rename it and move it to its own web page after I implement a proper back-end data layer. Until then enjoy this final alpha version and send me your comments if you have any bugs or recommendations.

http://karul.org/etc/mhelper/mhelper6.html

Some of the concepts discussed in this Blog has over the time evolved into an application you might want to check out:

http://music.isallicare.com

Thanks for visiting my Blog     — C. Karul Jan 3, 2010

Once we figure out what notes belong to a key/scale-chord combination, we can show them to the end user in a number of ways. My initial implementation will be a table of Degrees vs. Note names, where notes for the given chord or scale are highlighted. This is sort of the rectangular version of a magic circle as I described in my previous Blog entries Music Theory for Geeks 2 and 3. I’ll call this the Table View.

I’ll start by developing a standard “data” representation of my application, which corresponds to the Model in a, so called, Model-View-Controller architectural pattern. The Table View, as you might have guessed, will be one of my views. If I separate the model from the view now, I won’t need to change my core application logic in the future when I need to implement additional views (such as Notation View, Piano, Guitar, Bass view, etc.).

Because the degrees never change and they always have a length of 12, I’ll model them as a simple array. I’ll model the notes as an array as well, but this time I’ll use an array of size 24. There are 12 notes, but when I transpose a key, I rather start at the 11th degree and iterate up the array to get a list of my transposed list, instead of using an ugly if/then (i.e. if position = 12 go back to 0) condition.

function transposeToKey(keyName) {
    switch(keyName){
        case "C":
            var startPoint = 0;
            break;
        case "Db":
            var startPoint = 1;
            break;
        case "D":
            var startPoint = 2;
            break;
        case "Eb":
            var startPoint = 3;
            break;
        case "E":
            var startPoint = 4;
            break;
        case "F":
            var startPoint = 5;
            break;
        case "Gb":
            var startPoint = 6;
            break;
        case "G":
            var startPoint = 7;
            break;
        case "Ab":
            var startPoint = 8;
            break;
        case "A":
            var startPoint = 9;
            break;
        case "Bb":
            var startPoint = 10;
            break;
        case "B":
            var startPoint = 11;
            break;
    }
    for (var i = 0; i < 12 ; i++) {
        degrees[i] = keys[i+startPoint];
    }
    currentKey = keyName;
    updateInformation();
}

Chromatic_scale:      111111111111
Diminished_chord:     100100100100
Major_chord:          100010010000
Major_scale:          101011010101

Note that I appended the words _chord or _scale at the end of my scale/chord names as some chords and scales happen to have the same names, even though they represent entirely different things (i.e. a major chord and a major scale).

For now I’ll create associative arrays in my JavaScript code to keep these definitions. Moving forward, I’ll probably put all of them in a simple file and load to memory during page initiation. JSON might be a pretty good fit considering Dojo has built-in support for it and our data is pretty small in size. Eventually they’ll end up in a database. For now this is how my data definitions look like:

var scaleChordData = new Array();
scaleChordData['Major_scale'] =            ['1','0','1','0','1','1','0','1','0','1','0','1'];
scaleChordData['NaturalMinor_scale'] =     ['1','0','1','1','0','1','0','1','1','0','1','0'];
scaleChordData['HarmonicMinor_scale'] =    ['1','0','1','1','0','1','0','1','1','0','0','1'];
scaleChordData['WholeNote_scale'] =        ['1','0','1','0','1','0','1','0','1','0','1','0'];
scaleChordData['Diminished_scale'] =       ['1','0','1','1','0','1','1','0','1','1','0','1'];
scaleChordData['MajorPentatonic_scale'] =  ['1','0','1','0','1','0','0','1','0','1','0','0'];
scaleChordData['MinorPentatonic_scale'] =  ['1','0','0','1','0','1','0','1','0','0','1','0'];
scaleChordData['Chromatic_scale'] =        ['1','1','1','1','1','1','1','1','1','1','1','1'];

I also have another associative array to keep user friendly name, which I`ll use later to dynamically generate on screen information snippets. I kind of have to keep these two separate arrays in sync, as JavaSctipt doesn`t have a Hash Table or Hash Map that comes with most languages.

var scaleChordName = new Array();
scaleChordName['Major_scale'] =             'Major Scale';
scaleChordName['NaturalMinor_scale'] =      'Minor (Natural) Scale';
scaleChordName['HarmonicMinor_scale'] =     'Minor (Harmonic) Scale';
scaleChordName['WholeNote_scale'] =         'Whole Note Scale';
scaleChordName['MajorPentatonic_scale'] =   'Major Pentatonic Scale';
scaleChordName['MinorPentatonic_scale'] =   'Minor Pentatonic Scale';
scaleChordName['Diminished_scale'] =        'Diminished Scale';
scaleChordName['Chromatic_scale'] =         'Chromatic Scale';

And finally I can get to the part where we highlight scales and chords visually on the screen, so the user can quickly see which notes belong to the scale or chord, and which ones don`t.  For Table View,  highlighting is quite simple. All I need to do is to find the table cells that correspond members of my scale or chord, and then change their style dynamically.

function updateDegreesTable() {
    // Update notes
    for (var i = 1; i < 13 ; i++) {
        var degree = degrees[i-1];
        dojo.byId('r2_c'+i).innerHTML = degree;
    }
    // Update highlighting
    for (var j = 1; j < 13 ; j++) {
        var current = currentScaleChordData[j-1];
        if (current == 1) {
            document.getElementById('r2_c'+j).style.backgroundColor='#ddddff';
        }
        else {
            document.getElementById('r2_c'+j).style.backgroundColor='#ffffff';
        }
    }
}

Finally I wire these two functions up with the keys and scales on the left panel. So when the user clicks on a key or scale link, the transposeToKey and updateDegreesTable functions are called, respectively.

...
  <li class="leftPanel" onClick="transposeToKey('Bb');"><span>B-flat</span><hr></li>
  <li class="leftPanel" onClick="transposeToKey('B');"><span>B</span><hr></li>
</div>
<div dojoType="dijit.layout.AccordionPane" title="Scales">
  <p>
  <li class="leftPanel" onClick="updateScaleChord('Major_scale');"><span>Major</span></li>
  <li class="leftPanel" onClick="updateScaleChord('MajorPentatonic_scale');"><span>Major Pentatonic</span></li>
...

Note that some code was omitted for brevity. And also note that the fisheye animations I used to decorate the left panel items last week didn’t seem to be a great idea anymore after a week of playing with them. So I ended up replacing them with simple text, which I will try to make nicer later.

The application now looks like this, which still has some more work to do but can now show the keys and chord/scale notes for scales as designed:

A working version of the version 3 is available at http://karul.org/etc/mhelper/mhelper3.html.

Some of the concepts discussed in this Blog has over the time evolved into an application you might want to check out:

http://music.isallicare.com

Thanks for visiting my Blog     — C. Karul Jan 3, 2010