Future Development of Tapper?

David Christian (who I know as a composer of fugues) writes:

Iíll try to make this short --- which can be difficult for me.

I love Tapper!

Even given some quirks, it takes nearly everything I can think and feel about a piece of music and allows me to perform it without actually "learning" it!!

...

The program is wonderful --- it canít really make you sound like you are better than you actually are --- but you can sound your absolute best without much work and that is something I LOVE about technology!!

Thanks so much for making it available; I wish I had downloaded it a long time ago.

Of course, feedback like this is very gratifying, but "..." hides a question he poses which haunts me, namely:

Do you plan to develop it further?

I would love to do more work on the conductor program, but there are many other things vying for my time (not the least of which is: making a living), so it's not likely to be something that gets much attention in the near future. However, it is something I consider worth pursuing, and I do want it to move forward, so I'm trying to think of ways that that might happen.

My hope was that by writing an article about the history of the conductor program and making a freeware demo available, I'd generate interest in the idea, and it would be taken forward by others. This still might happen, of course; the question is: what could I — and you — do to make this more likely?

What I Could Do

I don't have much time to develop Tapper, but I do have a lot of ideas for improving and expanding it. One of the great things about computer programs is that there is no hard boundary between thinking about what a program should do and building a program that does it. In theory, you could write a program — and run it — completely in your mind. The act of writing notes about how a program would work is very real part of creating software; in fact, one way to describe what software programming is: the process of converting the description of a program into a form that is sufficiently unambiguous and complete to serve as instructions for a computer.

So, I could start collecting and sharing my notes for what an improved Tapper might do, and how.

I'll start right now (see below).

What You Can Do

Spread the word among users. Use Tapper, and when you share the results, tell people how you acheived them, and extol the virtues of the conductor program idea. Write articles. Post recommendations to newsgroups. Find people whose MIDI-generated music sounds unexpressive and recommend that they try using Tapper.

Spread the word among people who write about music software. Ask them to review Tapper. Ask them to write an article about the conductor program.

Find me a patron or get me a grant, so that I can afford to work on Tapper full-time. :-)

Seriously, though, I don't think I'm the right person to bring the conductor program to a mass market; I'm not enough of an entrepreneur. So perhaps you should spread the word among software developers. The source code for Tapper is available for free to anyone who asks for it. Tell makers of music software you use to consider adding the conductor program as a new product or a feature of an existing product. As you know, even a simple implementation (which Tapper is — it's pretty trivial) can be very useful (not to mention fun).

Notes for Future Development of Tapper

Let me begin this by responding to two suggestions made by David Christian. He writes:

... [a] recording element would be a wonderful addition --- thus far not implemented. Although, I can accomplish this via other means (I have written a program that does a good job of MIDI recording --- plus I can just use cakewalk or something like that) it would be nice, because after all, the data is there being used anyway so it wouldnít be a huge task to save your performances to a MIDI.

Yes, this is a good idea. The first version of Tapper (which ran under MS-DOS) had this. There were a couple of reasons I didn't include it in the current version. The first was that because I was making it a two-platform project (MacOSX and Windows), I was trying to keep the platform-specific code to a minimum. (This consideration resulted in several other compromises.) The second was that when I started thinking about what the feature would do, I couldn't come up with a way of doing it that was simple (both to use and to implement), didn't exceed the limited GUI I was using (which, by the way, is built on GLUT, the OpenGL utility library), and yet was comprehensive enough to do something useful without requiring the use of other tools. The more I thought about it, the clearer it was that the tool I'd want would have the conductor program as a central component, but would have other features for editing a performance. So, I decided to leave Tapper where it was, as a "demo," and start collecting design ideas for an ‹bertapper that would be a tool I'd want myself.

David's second suggestion was this:

... it might be nice to be able to control voices separately; however this is not so critical since I can edit the MIDI in order to bring out the voices as I would play the piece manually, so really Iím finding itís not as big a deal as I first thought.

You may be interested to know that the first electronic implementation of the conductor program (done by Christopher Strangio) had this feature, with separate triggering for right- and left-hand parts.

And, there is a way to do this in Tapper; it's not easy, but it is feasible: run multiple versions of Tapper in parallel. This requires that you have separate MIDI input for each instance of Tapper (which is easiest if you have one directory for each). Depending on what you use for MIDI output, you might or might not need separate output devices. I've experimented with this with some Chopin pieces in which I wanted the right hand rubato to be completely free of the left hand. It did work, and it did give good results, but it required a lot of practice! So for those pieces, I ended up deciding to just practice the piano instead.

The main reason I haven't added this as a feature is that there wasn't a way to do it that was significantly simpler than running multiple versions. If you have a single display, you run into the problem of what to do when the parts that are being controlled separately get too far apart to be visible on screen at the same time. There's also the need for a configuration tool for selecting multiple MIDI devices, specifying which part goes with which controller, etc.

And, as you found, you can do a lot without this feature. So, I decided that while this would be a good thing to have in the "full-featured," perhaps commercial version of the software, it wasn't important enough to include in the demo.

David's final question was this:

Have you entertained any improvements to the implementation or the interface? Personally, though, I feel it's more than adequate.

I go into this a bit at the end of my article. At this point, Tapper's weakest part is the controller: a keyboard controller is only adequate for some pieces of keyboard music, and it completely inadequate for instruments with intra-note expressive control (winds, brass, strings, etc.), and wind controllers are monophonic. Here's an incomplete list of other things I think are worth pursuing:

  • Integrate conducting, playing, rehearsing, editing. The conductor program paradigm used in Tapper is that you conduct the piece from beginning to end, in real-time, in one take. In other words, it's analogous to what a conductor does during a performance. But a conductor (not to mention the orchestra) does a lot more than that in real life. In rehearsal, a conductor may go over a passage several times, sometimes with only a particular section of the orchestra playing; during this, the conductor may indicate things for the group to do that it might be difficult to conduct explicity in the context of conducting the whole orchestra. The performers in the orchestra also get to go home and work on their parts separately. Finally, in the case of a recorded performance, there may be multiple takes, with passages of each selected and edited together during post production. All these aspects could be combined in a single tool.
  • Control at upper levels of the rhythmic hierarchy. In Tapper, the performer is given control at the bottom of the rhythmic hierarchy. This is sometimes exactly what you want, but there are many situations where it's not. If a piece has several parts that are rhythmically independent (either separate instruments in ensemble music, or several melodic threads in a contrapuntal keyboard music), it may be difficult to learn the piece's rhythmic skeleton. In this case you'd want to conduct the beats (or at least a simplified version of the rhythmic skeleton)
  • , and not every note. The need is greater when there are difficult cross-rhythms; for example, in Leopold Godowsky's Studies on Chopin's Etudes, no. 45, there's a passage in which there are four beat subdivisions at once — 3-against-4-against-6-against-9 — this is definitely a passage I could use some help with, and playing the composite rhythm (which involves dividing each half-measure into 36 parts) is not a practical approach.
  • Memory, history. When you practice a piece, you build up a set of habits which persist. Some of these are technical, but many are interpretive. Ideally, these interpretive habits are available to you as a palette of choices when you're performing. The conductor program ought to work the same way. How? What I'd like to incorporate is haptic feedback, so that when you're performing a piece, you're not just interacting with the score (which you see visually), but with your past interpretations; instead of the user interface being a passive controller, it would be more like a dance partner with a life of its (her?) own: able to follow you when you lead, but also able to do what you'd taught it previously.
  • Game. Playing music is fun, playing Tapper is fun, playing video games is fun. It seems like something which combined all these would be really fun ...