VP: retired page
From Sonikmatter
The overriding objectives I had when I created VP where simple to understand (if not always simple to achieve):
- Make VP interact in real-time with the machine so that changes could be auditioned immediately during the creative process.
- Make VP cross-platform so that it could run on the widest set machines, particularly the PC (Windows) and the Mac.
- Make VP relatively simple to maintain and accommodate changes in the Kurzweil VAST OS's.
- Make VP responsive.
- Try not to reinvent what the current interface does quite well.
- Last but not least… save my poor little buttons!
Contents |
Make it easy to learn.
Of all of the approaches that I considered, I chose to write VP so that it used the same interface that we humans use, thus VP is using the visual interface also as a programmatic interface. The overriding reason was to get the real-time feel of being able to audition sounds during the creative process just like you can do on the real interface. A pleasant side effect of this is a friendly learning curve; if you are familiar with the real interface (which I assume you are) then learning the new one should be a snap. Moreover, you can switch between the two in the same editing session without losing a beat.
Make it easy to get around and see what is going on.
One of the overriding design factors was to be able to quickly move around all of the information in an object (especially Programs). I wanted to be able to "see" what was going on. Like pages in a book I wanted to be able to turn back & forth at the click of a button and change the data with equal ease. If I have, for example, an LFO, I wanted to be able to quickly see where it is being used with the hope of understanding its role in the concert of possible settings in a good Program. (While the current VP interface is a huge step forward over where we were before, there are still many opportunities to innovate in this area as I explore graphical representations of data in future versions.)
Make it responsive during the creative process.
I wanted the interface to be responsive but this was a difficult undertaking (remember the slow interface and the picture cell phone). There is a solution however. The key is to make the user interface appear responsive even of the communication channel is slow. All we really care about as a user is my perceived responsiveness. This can be achieved for the most part by using clever (but often complicated) data caching schemes that allow VP to give the illusion that the Kurzweil is responding quickly even when it isn't.
There is a lot to keep track of in there.
So far we have discussed a user interface that is trying to appear responsive by employing data caching schemes and a few other tricks. But there is also another consideration. We must remember that the Kurzweil can only consume commands at a relatively low maximum rate and that it gets unhappy when we push it too far. This gives rise to a complicated but necessary data processing subsystem that keeps track of what is being sent to the Kurzweil, the time it was sent, and the time the next thing can be sent. So we have several processing threads bouncing around simultaneously--like Santa's elves, each doing their particular task in synchronization with the other elves. If anyone makes a mistake, Santa's sleigh crashes and burns and there is no more Christmas. It's a heavy responsibility.
Want to know more? Read You Know It Don't Come Easy
| Main Page : | Kurzweil : | VAST Programmer : | Bug Reports : | Feature Requests |
