ExploreTuning1

One of the cool things about JiMS iGetIt! note-layout (also used on the now-defunct Thummer) is that it has the same fingering in every tuning of the syntonic temperament.

This is kinda hard to explain, so I wrote a little Flash app to help. Here it is (source code here):


The slider on the left controls the frequency of Re⁰; all of the other notes' frequencies are determined by their geometric relationship to Re⁰, as a combination of octaves and fifths (as described here and here).

The slider on the right changes the width of the tempered major fifth (traditionally, "perfect fifth"), thereby changing the widths of all non-octave intervals -- that is, changing the tuning. A few notable tunings are labeled along the slider's track.

This chart shows what's happening:

(The colors in the chart do NOT correspond to the colors of the keyboard buttons in the applet above.)

On the keyboard app above,
1. Every note in a given note-class (such as all of the Re's) has the same color.
2. Two dfferent note-classes' notes have the same color if their frequencies, in the chart above, intersect in the current tuning.

For example, in 7-tet, a given diatonic note and all of its chromatic variations (a) control the same frequency, and hence (b) are drawn with the same color.  Example: Ra, Re, and Ri are all red in 7-tet. Hence, there are only 7 "frequency classes" in 7-tet.  That is, only 7 frequencies, and their octaves, occur in it.

BUT THERE ARE STLL 19 NOTES PER OCTAVE. Many of them just share the same frequency-classes. For example, Ra, Re, and Ri are still different NOTES; they just happen to control the same frequencies when tuned to 7-tet.

Likewise, if one moves the right-hand slider all the way down to 5-tet, then only the 5 notes of the pentatonic scale have unique frequency-classes, all of the diatonic, chromatic, and enharmonic notes (i.e., all of the notes of well-formed scales of cardinality higher than the pentatonic) share/duplicate these pentatonic notes' frequency-classes.

If one slides the slider up to 12-tet, only the chromatic notes have unique frequency-classes; the enharmonic notes (that is, the notes of those well-formed scale with cardinality higher than the chromatic) share/duplicate these chromatic frequency-classes.

In 19-tet, or 31-tet, or in most other tunings, each note-class of the enharmonic scale controls a different frequency-class.

(One of the strangest tunings is 17-tet, in which the pairs De-Li and Se-My are enharmonic. Set the slider to 17-tet, and play Se⁰ and My⁰, in the upper-left and lower-right corners of the keyboard, respectively.  Different notes, same frequencies.)

This makes me wonder about the relationship between "scales" (that is, subsets of the enharmonic scale's note-classes) and "tunings" (is the pentatonic scale "really" the pentatonic scale all across the tuning range? Why or why not? How about the diatonic scale...in 5-tet?).

Now, the tunings that are far from 12-tet sound like crap when played using harmonic timbres (try it!), such as the timbre produced by the keyboard applet above. That's because the applet is only tempering the tuning, not the timbre, too. Tunings sound best when played using a "related" timbre -- that is, a timbre in which the partials align with the tuning's notes. Indonesian gamelan orchestras, playing in slendro's 5-tet scale, are playing instruments that emit timbres that (when crossed with a harmonic timbre) fit 5-tet. Tradtitional Thai and African music, played in 7-tet, is played on instruments that emit timbres that fit 7-tet...just as Western timbres fit the tunings near 12-tet.

With electronic sound synthesis, one can temper the timbres to match the tuning in real time -- by shoving a timbres' partials around -- so that voila! You get to have (or choose not to have) consonance in any tuning.

Which bring us to Dynamic Tonality.

Here's a simple example of dynamic tonality, using the above keyboard applet:
1. Slide the tuning to 19-tet (using the tuning slider at the right).
2. Play the ReFiLa triad.  Very nice; very restful.
3. Slide the tuning to 5-tet (at the top of the slider).
3. Play the ReFiLa triad again.  Too much tension!  Must release!
4. Slider the tuning back to 19-tet, and play the ReFiLa triad again.  Aha...sweet relief.

What you're experiencing is a novel means of creating tension and relief -- that is, of controlling emotional affect -- in tonal music.
A. In 19-tet, the ReFiLa triad is your basic major triad, which fits well with the harmonic series, and sounds restful.
B. Widening the fifth from 19-tet to 5-tet widens the triad's major third (Re-Fi) by so much that it begins to sound like a sus4 instead. That's one form of tension.
C. Also, widening the fifth from 19-tet to 5-tet pulls the tuning's notes out of alignment with the timbre's (harmonic) partials, creating another form of tension.  The notes are "out of timbre."
D. Tuning back to 19-tet relieves the tension of the pseudo-sus4, and also brings the notes back "into timbre."

If one can temper one's timbres in addition to tempering one's tunings, then one can introduce "out of timbre" tension to any triad, including the tonic major triad.

The above experiment would be more compelling if the underlying synth could alter the frequency of a note being played after it started playing (i.e., pitch bend), but, alas, it cannot (so far as I can tell).

You can explore Dynamic Tonality more deeply with the Max/MPS-based TransFormSynth, described here.

P.S.: Why the ReFiLa triad, instead of the DoMiSo triad? Because Re⁰ -- being the center of symmetry (more or less) of all well-formed scales -- is the "origin note" from which the frequencies of all all other notes are determined. As such, Re's frequency doesn't change when the tuning changes, but the frequencies of all other notes do change. Clearly, the applet need to be extended to support the ability to specify a "tonic note-class," which would make the tonic note-class' members (e.g., Do) stable instead of Re. Always more work to do.  ;-)

Guthman Musical Instrument Competition

The Thummer is a contestant in Georgia Tech's Guthman Musical Instrument Competition, being held later this week.

Dr. Monty Cole, a high school friend of mine, happens to work just down the road at Mercer University, and has kindly offered to present the Thummer there on my behalf.

Unfortunately, we haven't been able to get one of the (rapidly aging) Thummer prototypes working, so the presentation will rely on videos of other people performing on it, rather than a live performance.

Here's the presentation, as a compressed PowerPoint file:  Guthman.zip

It's super-short, relying primarily on three videos.  I'm not sure that the PowerPoint file will be able to locate the videos properly after one downloads, unzips, and moves them to some other file folder. One may need to open the presentation in PowerPoint, go to the slides that contain the videos, double-click on the video graphics, and update the video-link to reference the video files' new location.

Why do the videos have a "Wondershare" logo across their upper-left corner? Because I used a trial version of Wondershare's Video Converter for Mac to convert the video files from WMV to MOV format.

Marek Zabka: Let's Talk

Marek Zabka, a Lecturer at Slovakia's Comenius University, is hot on our heels.

His paper Generalized Tonnetz and Well-Formed GTS: A Scale Theory Inspired by the Neo-Riemannians shows that he's investigating the same generalized approach to music theory that Andy Milne, Bill Sethares, and myself are pursuing (our references here), on which JiMS iGetIt! Music System (JiMS) is based.

Interestingly, Dr. Zabka does not cite any of our papers, which I presume means that he's unuaware of them.

He has not yet connected his approach to isomorphic keyboards or -- more importantly -- to a generalization of timbre, so we're still ahead of the pack.

Clearly, the foundations of our mutual approach are "in the air," much as infinitesimal calculus was in the 1660's and natural selection was in the 1850's.

I don't have Dr. Zabka's contact information, and can't find it on the web. If you, kind Reader, know how to contact him, or can forward this to him, I would welcome the opportunity to welcome him to into our growing collaboration.

Lesson 005.0

Here's my first draft of Lesson 5 in JiMS iGetIt! Music System (source code here):


Same crummy state-controlling button-bar at the bottom, for now. I really must fix that.

This lesson is 640x480, rather than the much smaller dimensions of the previous lessons. The larger size doesn't fit this blog very well, but it makes the lesson's text easier to read -- especially the note-button labels.

In this lesson, we build the "Fundamental Scales" -- that is, music's "well-formed scales." I'm not using the "well-formed scale" phrase yet, because to do so, I also need to introduce Myhill's property, and we're still a few lessons away from that.

In Lesson 6, I expect to introduce the notion of tuning, to show how the world's different musical cultures are related, and to establish the argument that to learn music using JiMS is to use a very general approach -- not limited to traditional Western music, for example. I had hoped to put that into Lesson 5, but it was just too much information. It needed its own lesson.

As of this lesson, my courseware has not just drifted, but positively galloped away from mainstream approaches to music education. Yet one can see that the concepts it introduces are quite simple, when shown using JiMS isomorphic keyboard and on-screen animations.

This lesson is late because I spent a week doing the final packing, cleaning, etc. to get our Austin house on the market. That's done; the coast is clear. More lessons!  (More cowbell!)

Cardinality invariance

All isomorphic note-layouts, by definition, have the property of transpositional invariance: the same fingering in every key.

Non-trivial isomorphic keyboards also have the property of tuning invariance: the same fingering in every tuning (of those temperaments with the same generators as the note-layout).

I've blogged before about the fact that the Wicki note-layout has another invariant property, not yet named: its fingering patterns are the same for well-formed scales of any cardinality (again, assuming that the layout and temperament use the same generators). However, that property has not yet been assigned a name.

I hereby define cardinality invariance as "the same fingering in every well-formed scale, regardless of cardinality" (for a given generator-pair).

JIMS' (Wicki) note-layout has this property. The Wesley note-layout has it, too. Most other isomorphic note-layouts don't have it.  I don't yet know what mathematical characteristics confer it. But now, at least, it has a name: cardinality invariance.

Languages, Frameworks, and Idioms

I've recently realized that I'm not "re-learning how to do computer programming," as I had intended. I'm just learning
- new languages (ActionScript, [M]XML),
- a new framework (Flex),
- new development tools (Eclipse), and
- their relevant idioms.

The data structures, algorithms, and fundamental abstractions are all pretty much the same as they were 17 years ago. There are a few new concepts, but basically, it's old wine in new bottles.

It could be, that a more recently-experienced programmer would look at my code and ask "why aren't you using glorpization here?" -- and the answer would be, I haven't  a clue what glorpization is, because its use became widespread during my programming hiatus, so I never encountered it before.

One example of this, I suspect, is iterators. The use of iterators for traversing collections had only recently come into vogue went I left programming in the early 1990's. So when I returned to programming, using Adobe's Flex, I tended to traverse its ArrayCollections using indexing (that is, "for i=0 to foo.length") rather than iterators, whether implicit ("for each element in foo") or explicit ("cursor = foo.getCursor; result = cursor.findAny(key)...").

Another thing I missed was the introduction of associative arrays as an underlying mechanism of dynamic programming. "Static typing be damned -- just slam another property on that instance!" This was anathema, back then. Now, you can hardly turn around without bumping into associative arrays. XML appears to one big nested associative array. Flex depends on them.

It's quite odd to see a practice that was formerly considered to be a hanging offense -- "Egad! Self-modifying code! Run away, run away!" --  find its way into the core of modern programming.

I am still finding XML to be impenetrable. It's so simple that I can't understand it, because its (assumed) simplicity is shrouded in impenetrable layers of complexity.

My current confusion on the topic reminds me very much of how confused I was when I was first learning object-oriented programming (OOP). Everyone kept describing OOP in anthropomorphic/magical terms that clouded the issue. They'd say "message passing" when what they really meant was a function call. They'd say "overriding a method" when what they meant was a function call.  Only after I discovered C++'s vtables did OOP become clear to me.  At its heart, OOP was just a little bit of compiler (and runtime) code that maintained tables of pointers to functions.  It was simple. Why did everyone insist on hiding this simplicity with layers of complexity?

I'm pretty sure that XML is the same -- a very simple idea layered in complex crap.

For example, my online music education lessons rely heavily on the use of the computer keyboard as a musical input device.  I am quite aware that much of the world does not use the English language's "standard" QWERTY keyboard layout, using other layouts like QWERTZ, AZERTY, etc. instead.  I would like to write my code such that I can add new layouts without recompiling all of my lessons.

I've got all of the relevant data structures working just fine in my code, as in-line ArrayCollections of Key objects (which define a name, code, and physical position for each key) -- but I can't figure out how to implement them in XML. It ought to be brain-dead simple.  It probably IS brain-dead simple.  But I just wasted an entire day on this issue without making any progress whatsoever, as far as I can tell.  Too many layers of complexity around XML's simple core.

So, screw it. For now, I will continue to keep XML in the "too hard" file, along with fly fishing, calculus, preparing beef Wellington, and serialism.

Lesson 004.0

Here's my first draft of Lesson 4 (source code here):


It uses the same crummy state-controlling button-bar at the bottom, for now. I'm going to write a new control for progressing-through-the-lesson-control soon, probably this weekend.

Moodle
I spent some time earlier this week looking at Moodle, the open-source learning management system. I'd like to package my lessons in a Moodle wrapper, because it has excellent support for all sorts of things (like gradebook databases) that I don't want to have to think about. Unfortunately, Moodle's Flash/Flex support is seriously deficient. Fortunately, an effort appears to be underway to address this deficiency. Therefore, I will proceed as if Moodle will have excellent support for Flash within the near-enough future.

I met the Moodle guys when I was living near their home base in Perth, Western Australia. I knew at the time that they had a good chance of beating their commerical competition. The signs were there, even then. Moodle hasn't been gaining market share as rapidly as I had expected, though. It needs some professional help with its evangelism, I suspect, to accelerate its rate of growth. If Moodle doesn't pick up the pace, it could be the next MySpace. It's "do or die" time.

Music & Pedagogy
Lesson 4 is the first lesson to introduce JIMS keyboard. The keyboard is introduced by deriving the pentatonic scale from an octave-reduced stack of (tempered) (major) fifths.  Notice that the lesson never qualifies the term "fifth" -- that is, it doesn't call it a "perfect" fifth or a "major" fifth. I don't want to, or need to, open that can of worms quite yet.  All in good time.

The next lesson, Lesson 5, will state that JIMS' unique approach gives its students the power and flexibility to understand and describe the music of many cultures. It will suppor this statement by extending the Stack of Fifths to produce the diatonic, chromatic, and enharmonic scales, and by showing that -- using a tuning slider -- the student can change the tuning to match that of many different non-Western cultures and Western eras, while retaining the simplicity and consistency of JIMS' keyboard's pattern.

I think that it's important to make this point early on, because immediately after making it, the lessons will shift their focus to the diatonic scale, and spend a LOT of time in the diatonic world thereafter. If the flexibility of the JIMS keyboard isn't demonstrated early on, a knowledgeable music teacher, reviewing JIMS' early lessons, might reasonably conclude that JIMS teaches concepts that are applicable only to the diatonic scale.  I need to plant the seed of JIMS' power early on, even if I don't water it until much later.

Programming
I'm becoming more comfortable with the architecture that I'm using for these lessons, in which the lesson's content is implemented in the transitions between Flex's application states. If I choose the states wisely, then the architecture works well -- even if this architecture is, as I suspect, an unanticipated application of Flex's "state" feature.

Flex's 4 Beta 2's implementation of stateGroups seems to be a bit buggy (as one might expect from a new feature in a beta-version framework).  It seems to clobber properties that aren't set by the relevant states. For example, you'll notice that in Lesson 4 above, the note's octave numbers disappear partway through the lesson. That appears to be a manifestation of the stateGroup bug.  I spent a couple of hours trying to work around it, before deciding that the lack of octave numbers, in those states, was not a big enough bug to worry about. Also, don't use stateGroups to affect the setting of the properties of a slider, because the max/min/value will be set to NaN under conditions that I haven't spent the time to rigorously quantify.

Now, if I were a really serious beta-tester, I'd dig into Adobe's online bug reports and open-source nightly builds of Flex, to track down the bug and try to identify a fix. However, I'm confident that the bug is severe enough that others will have done this work, so it will be fixed in the release version. Although my use of the state feature in my application's architecture is, as I've suggested above, likely to be unusual, the use of stateGroups is not, so other people should be encountering this bug.  If it persists in the next release, I will become more actively concerned.

Schedule
I've decided to try to post a new lesson each week. That would give me fifty lessons in a year. Assuming that I'll make the first dozen free, on a "try before you buy" basis, then those who subscribe to the paid lessons will get an additional 38 lessons (because 50 - 12 = 38). Thirty-eight is more than three dozen, and hence is three times the number of free lessons -- which ought to make the paying customer feel like they are getting enough to make the $29.95 purchase worthwhile. Of course, I'll be adding new lessons constantly thereafter, but with 50, I ought to have enough to "go live" and start selling subscriptions.

I'll have to pause my output while writing a "notation" component, but since JIMS' sequencer-like notation is so much simpler than traditional notation, it shouldn't slow me down by too much.

Lookin' good.  ;-)