BUILDING & MAINTAINING A COMPUTER MIDI& MULTIMEDIA MUSIC TEACHING LAB
BUILDING & MAINTAINING A COMPUTER MIDIArticle Sections:
Startup Menus, DOS/Win |
PC & Sound Ergonomics |
Desktop: Enhancing and Saving |
OS Environment Specifics
Memory Management |
Tweaks for Running CD-ROM Programs |
Old Software Graphics Mode in New Windows
Coexisting DOS and Windows |
Upgrading: Memory |
Some XP Anomalies with Old Software |
CD-ROM Drive Speed Issues
MIDI Evolutionary Struggles |
Getting all MIDI Sounds |
Failure During Windows Installations
MIDI Latency Problems |
Roland Sequencer Incompatibilities
Backup Your Settings & System! |
Safely Testing New Software |
Rights Management and its Consequences
Expiration of Software, Installers |
Internet Security |
Our Tribute to "Weird Stuff" & other resources
The Future: Win XP, versus Vista or Linux
In Regina Roper's companion articles on music technology and using the computer music lab, we discuss how the lab is employed to provide instructional programs to assist with note identification and ear training, and music history and pedagogical topics. In this article we provide specifics of the nuts-and-bolts of the technical structure of the lab, hard-won lessons from years of struggling with changes in operating systems and PC hardware.
The most important element in the efficient, effective use of electronic technology in the piano studio is making the machinery intuitively usable for all the students. It does no good whatsoever for a piano teacher to interrupt a live one-on-one lesson to come into the lab to reboot a recalcitrant machine that has locked up or crashed on a program, or to help adjust audio levels or make the midi keyboard work. The ergonomics of the system MUST be simple, straightforward, and predictable so that one touch of the power button is all you need to start up the lab; the on-screen display should guide the student the rest of the way!Our piano labs are arranged to start with an operating system appropriate for most of the programs. We use MicrosoftTM WindowsR for certain modern programs, and find that it is often desirable to use both old (16-bit) and newer (32-bit) versions (on different computers) -- for programs developed for specific platforms. And we use plain old DOS for other software that was written many years ago, and that is dependent upon specific hardware MIDI cards that won't operate correctly under Windows.
The DOS machines boot up into a menu program (an old one obtained in the late 1980s, surely by now discontinued "abandonware" but similar to many that are still available in shareware or freeware via Internet websites.) All the student has to do is to scroll up or down with keyboard or mouse, select the program given in the day's lab assignment, and click the mouse or press the ENTER key. If necessary, we can even show a hint at the bottom of the screen (such as "make sure to turn on the power button on the MIDI piano".) We can even use the menuing program to start the old 16-bit versions of Windows 3.11; at the termination of Windows, the computer restores the DOS menu program. This simple process is even easier than using the much more complex, multidimensional Windows desktop, with its often bewildering variety of icons. And, if necessary, this DOS menu program allows for the creation of external batch files to start processes or to adjust parameters for specific requirements of the MIDI keyboard (such as sending a MIDI reset command before commencing the music software. This has eliminated many startup glitches with old DOS music software, and reduced our need to supervise the setup and preparation for each student's use of the computer labs.)
You will note that on the DOS menu above, the left hand side uses the function keys to access DOS disk commands: luckily this software provided a means of locking those with a password, which keeps "prying eyes" from doing mischief on our systems unless, of course, they are really intent on doing harm and rebooting and bypassing the autoexec.bat (none of our students has ever misbehaved in this way!)
• EQUIPMENT ERGONOMICS:While MS-Windows provides a handy (but often confusing and frustrating) music mixer panel, allowing the adjustment of relative levels of MIDI synthesizer, WAV sound, and line audio inputs and outputs from the computer, DOS computers typically have no such program available (though some old DOS soundcards did supply a crude, clumsy one.) Yet we find that students have the tendency to misadjust such mixing applets, leaving the computer lab system out of kilter. "Ms. Roper, I can't hear the piano!" is the plaintive complaint from the next lab student.
At first, we developed our own small external audio mixer devices, based around simple opamp circuitry that we made and packaged for each lab. But over the years we tired of the construction of these devices, and found a much easier replacement: small "multimedia mixers" designed for school computer labs, and originally sold for a fairly high price. We located one at a favorite haunt of ours, the computer surplus store WEIRD STUFF (more on that below) and eagerly added it to our primary lab system; a year or two later, the dealer got a fairly large shipment of the same gadgets and we purchased no less than eight of them (with four standing ready as spares or for future projects.) These small mixers (see the photo below of the little box with multiple knobs, between the speaker and the computer monitor) have three stereo inputs, a pair of headphone outputs with separate volume control, and adaptor cables and plugs that fit most external devices, and run from a very small "wall wart" power supply that is included: incredibly handy, efficient gadgets but with two irritating characteristics: first, the LED pilot light is blinding, and draws one's attention away from other things; and second, the silk-screened labels for the controls won't fit YOUR applications. So we have to cover up the pilot light (using a small gummed "dot"), and relabel the knobs -- then the units are perfect.
We adjust the volume controls of all external gadgets and either lock them into place, or mark them clearly, and then slip the mixer knobs on their shafts until they all point "straight up" symmetrically. Having pre-adjusted the relative volumes of the MIDI keyboard audio output signal, CD player, and computer sound card output, we have a nice consistent balance for each of these input signals to the headphones or speaker power amp. Most of the time, if more than one student is present in our computer labs, headphones are used; but speakers are also available by pressing a single switch next to the display monitor (and we have equipped each station with a very high quality, good-sounding "amplified computer speaker system" consisting of satellite treble speakers and subwoofer: we were able to find a superb unit made by Midland, originally priced at more than $150, at an amazing "closeout" price of just $26 each at a chainstore computer dealer clearance table.)
Also, be advised that unless you want your lab sound volume to be set very low, you may need a considerable amount of audio amplifier power to keep from distorting badly on MIDI piano sound, or CD recordings of piano music. The "waveshape" of the attacks of piano notes is very steep, with much higher "peak to average" power ratio than the envelope of recorded ensemble music, which often may be compressed to a fairly constant volume. You may find that the audio amplifier chips in the PC sound card are unable to achieve a realistic volume or tone with solo piano sound. In that case, you must use an external speaker boost amplifier. Back in the old days of high fidelity (the fifties) the wattage power of amps was standardized to a specific electrical reference: 5-10 watts of "real" power was truly measured and reported honestly, and with decent speakers could achieve a natural volume level (for the technogeek: perhaps at least 90-100 dB SPL, A-weighted: the volume peaks I have measured in our main lab when Regina plays the Yamaha grand in typical music.) But I have seen puny, cheap oriental PC speakers with boosters, claiming "125 watts" on the box, rated by some ludicrous standard ('PMPUTW240VYAK', or "peak music power under a tailwind, feeding a 110v amp with 240v from the electric stove connector, listening to imaginary music sampled from reversed yak-calls.") 5 to 10 genuine watts of amp power will probably suffice, the actual output capability of reputable "multimedia speaker systems" in the new-unit retail price range of about $100-150.
When using Windows, we also pre-set the volume sliders of its mixer, and then either turn off the applet so that it does not appear in the "tray", or lock its controls (if the sound card permits this function.) That way, both the DOS and Windows programs maintain correct sound levels for each program, every time the lab is booted up. This attention to the ergonomics of the sound controls was one of the most important things done to insure that our labs run smoothly and effortlessly.
One important reason that the level balances between MIDI sounds, CD audio tracks, and WAV files are so critical in our music lab is due to the relative volume levels of classical music on WAV and CD tracks, and the blistering, ear-burning loudness of rock or pop tracks and synthesizer sounds. We have some multimedia CD-ROM programs, notably "Composer Quest", "Professor Piccolo", Intersound's "BACH", and a few others, that mix these types of sounds together, using blasts of rock or pop 'stingers' interspersed with classical tracks, probably to pander to the tastes of youngsters who are not classical music afficianados. The classical music tracks on CD's are "cut" much lower in average level than pop or rock music, since (say) a solo grand piano is not nearly as loud to the ear as a rock ensemble with screaming distorted guitars, synthesizers, pounding bass, and drum kit. So, it's necessary to turn the "CD audio" input slider almost all the way up, and the "WAV Sound" and "Synthesizer" (or "MIDI") sliders way down. One must try all the various programs to achieve a reasonable compromise so that other programs, without these level anomalies, will be usable.
We've written complaints or explanations of this to the authors of some programs, but they do not seem to appreciate the problem. In some cases we have registered a 20 dB drop in level for the classical music tracks compared to others in the same program, a huge amount that causes the classical parts to be nearly inaudible: so don't be afraid to alter the "default" Windows mixer panel settings as required.
|
We're certainly not "cable fanatics" like some audiophiles, who spend more on the AC power conditioning and audio interconnects for their "high end" stereos than most 'normal' people spend on their entire houseful of entertainment electronics. But we DO worry about the connections of our lab audio and computer equipment into the AC power mains. We would recommend using a central power controller for each lab station, with a built-in surge suppressor, so that you may label each power switch for the appropriate device: piano, computer, audio amplifier, etc. That way, you may use the lab only for playing a CD or noodling on the MIDI keyboard, with the computer off; or vice versa. And in areas where your AC power is not absolutely reliable nearly 100% of the time, you might consider adding a hefty uninterruptible power supply with self-contained rechargeable battery backup, hooked between the AC wall socket and the main lab power controller switch. A computer running Windows does not "cleanly" power down unless you properly close the operating system; a sudden power outage often leaves "trash" on the hard drive. When Windows reboots, you have to sit through a tedious process of waiting for "Scandisk" to clean up the mess. And early Win 3.1 lacks this automatic disk-maintenance feature. Using a "UPS" will prevent the problem during short failures of up to several minutes. Furthermore, the better units will help condition the AC power and remove occasional transient glitches. UPS devices are getting cheaper and cheaper; we've found 350 to 500 KVA units (giving at least a couple of minutes of computer operation during an outage) for under $70. Use a larger capacity one for -- say -- a Pentium IV system running XP, with a 19" monitor. |
We have found that Windows 3.1 will start nicely from the DOS menu program, so that the student may seamlessly switch between programs that must run only from DOS, into Windows, and back again (this necessitated doing some technical tricks to optimize the computer's memory that are specific to this particular old menuing program, beyond the scope of this general article.) The Windows desktop is daunting to a youngster who only needs to find one or two icons to start a program; so we created two special Win 3.1 program groups: "Music Theory" and "Multimedia"; placed into them an arrangement of all appropriate program icons; and then set Windows to "Save" the group and desktop arrangement when we were satisfied with the layout (by pressing simultaneously the LEFT SHIFT key while clicking on 'EXIT WINDOWS' from the File menu.) Then, we made sure to turn OFF the "Save Settings on Exit" parameter so that each time Win 3.1 starts up, the exact saved desktop arrangement appears, even if a student has accidentally dragged or even deleted an icon. (And as an extension of our 'control-freak paranoia', we even have a backup subdirectory on the Win 3.1 computers for saving copies of all of Windows' *.ini, *.grp, and *.dat files, in case they become corrupted and need to be reloaded.)
Later 32-bit versions of Windows pose more problems in the stability of the desktop arrangement. There does not seem to be a readily available method of precisely SAVING the exact icon placement that is absolutely foolproof and recoverable. But since we tend to use Win 3.1 more often, due to the nature of the old multimedia software programs and their requirements, we haven't had much trouble with "messy desktops" in the later Windows versions; if something does get out of place, we just shrug and "rebuild" the desktop as needed.
Or, you might prefer a simpler, but absolutely free utility, called "Save My Desktop", written by Johnny Tucker. It is a small program that will do much the same thing as WinTidy (although you may not have the icon "Auto Arrange" function turned on; and it only works on Win95/98/ME/NT/2000.) Download it here.
Custom Roper Studio Windows' Screensaver Images
MS-Windows is the standard of the "non-Mac" PC world now, but we still use DOS programs, since some of them have never been upgraded to run correctly in Windows. DOS MIDI programs make direct "hardware calls" to the MIDI synthesizer chips and sound functions of the system sound card; some of them even require special old MIDI adaptor cards with UART chips for specialized functions (such as the old Electronics Courseware Systems programs that we used for many years, but have now phased out.) When any of these programs are started under Windows -- if they run at all -- they probably won't run the MIDI piano or produce sounds of any kind. So, two of our labs "boot to DOS" and use Music Quest MIDI adaptor cards for the piano, plus SoundBlaster-compatible ISA sound cards. Setups for these devices are sometimes difficult, and are so context-dependent that the details are beyond the scope of this article. Usually the cards are provided with manuals, and diskette driver disks with "README" files that will explain how to edit your system's CONFIG.SYS and AUTOEXEC.BAT files to initialize and engage the functions on these cards so that the software programs can invoke them.
Ibis Programs (left), originally for DOS midi/sound cards, are still superb for teaching rhythm, note recognition, and ear training.
Only one version was ported to Windows (3.1): "NotePlay". We still use the DOS version.
Windows, however, sends its OWN set of system commands to the peripheral devices in the system, using its own Windows drivers. Thus, many old DOS programs for MIDI piano and sound functions will NOT work correctly under Win 3.1 or later versions. Some of the excellent software developed in the early 1990s by the now-defunct Ibis Company (for which Regina acted as beta-tester) are still of great use: Rhythm Play, Note Play, Rhythm Ace, and Ear Play; we keep these on our DOS lab since no Windows-specific versions were ever published (and the programs must be booted under "raw DOS" to work correctly with the MIDI keyboard.) Be careful when buying music software from certain retailers' catalogs: be certain to get the specifics of their compatibility with various OS's. Just because a program will START under Windows, does not guarantee that its functionality will be equal to its operation under DOS, as intended by the original developer.
Win 3.1, and DOS itself, requires the user to optimize the system memory management in order to run some programs that make great demands on the computer's use of RAM. MS-Windows supplies its own rudimentary memory management fuction, which works fairly well -- though it does not squeeze out the last drop of available conventional memory, needed for certain demanding DOS programs (like the old pedagogy software "Rudiments" that we used to use.) There are many commercial memory manager products: the most famous (and best) were published by Quarterdeck-QEMM and Helix. They all work reasonably well on a Pentium computer, especially on the motherboards and chipsets made by Intel. On 486 systems (notably some of the "clone" motherboards from the orient, without trademarks) the memory managers often fail rather miserably, and produce a rickety, shaky system that is prone to crashes and memory conflicts. We recommend that you employ a "conservative" setting of the memory manager, and avoid any kind of "stealth" mode that caches system BIOS, for the most reliable use of DOS software.
If you only use Win 3.1 software on your system, you may be able to use settings that are more aggressive if your motherboard is well-designed and bug-free. We have built dozens of 386 and 486 computers, and breathed a huge sigh of relief when we finally replaced all of them with early Pentium systems: those seem much more stable using the same OS, memory manager, and software. And of course, the Pentium of a given CPU speed is three or four times faster in excecution than a 486 rated at the same clock speed: helpful with demanding multimedia software that runs simultaneously both images and sounds.
Thank goodness the later versions of Windows handle all the memory management automatically: good for us end-users; bad for Helix, QEMM, etc.!
Win 3.1 users of "CD-ROM multimedia application" software programs, integrating sounds, videos/still images, and text display may want to be sure to adjust the sound buffers for maximum RAM storage of sound clips loaded off the CD-ROM drive.
If your DOS/Win 3.1 system has sufficient RAM -- probably 16M or more -- you should use expanded memory in order to provide CD-ROM memory caching. Consult your memory manager software documentation, and MS-DOS's help for their MSCDEX.EXE (Microsoft CD Rom extension) executable program file, required in your system's AUTOEXEC.BAT.
UPDATE: 2/05: Indeed, some W95/98+ 32-bit programs have memory leaks; or perhaps Windows simply does not restore memory properly after certain "memory hog" programs are run. For instance, "CoolEdit" (a now-discontinued digital audio editing program) fails to restore system memory in our Win98/ME systems. After a music-editing session, we often find it beneficial to run "Mpower" by Mindbeat, a freeware utility that returns the full system RAM to OS-availability. Read this review, and download here.
All versions of Windows, as far as we know, prior to the latest - XP - were limited in the ability to run different screen display parameters during a Windows session. Unfortunately, the old multimedia CD-ROM programs that we purchased in the early 1990s -- some of which are now defunct and have disappeared from retailers' shelves, though they're still useful -- require that the computer display be set only for 640x480 pixel display ratio at precisely 256 colors, which was the default for a few years during the introduction of Windows 3.1. You sometimes cannot even install these programs with Windows 95, 98, or ME if your machine is set for (say) 16-bit high color, or 800x600 pixel display mode.
The poor 'solution' (if you could call it that) was to set your later version of Windows for 256 colors at 640x480. But web browsing is LOUSY that way; and with large-sized displays the graphics look garish, coarse, and over-magnified.
We were thrilled that the new version of MS's Windows XP operating system, introduced a couple of years ago, had a "compatibility wizard" that allowed each specific program to be set up as it wanted to be: thus, your system could be installed in a modern default of, say, high color with 1024x768 pixels, but you could use the compatibility settings to force a program to install with the old-fashioned lower resolution settings it demanded. The compatibility controls also allow various settings for the screen display size -- windowed or full-scale -- and to emulate the behavior of earlier versions of Windows back to Win 95 (often helpful for old Win 3.1-era 16-bit software.) It is beyond the scope of this article to get into elaborate settings for various pieces of old software that you may or may not have; suffice it to say that the XP Help menus have most of the information you will need to adjust old programs to install correctly in XP: old MIDI programs, that is, that work correctly on Win 3.1! Again, the very oldest MIDI and musical sound software that was developed ONLY FOR DOS will not work correctly in XP, since the software produces "hardware calls" to the system that Windows will intercept: sorry!
So, if you like some of these old programs for DOS, our best advice is to keep your old computer: this helps, for example, if you have some multimedia programs that cause crashes with certain modern video cards. The solution may be to run them on old hardware that worked when the programs were new.
UPDATE: 2/05: Recently while browsing one of the invaluable "Windows Secrets" books by Brian Livingston, we discovered a virtually "buried", obscure Windows utility, found in the SYSTEM folder on Win 95-98-ME, called "mkcompat.exe". The "Make Compatible" program was designed to enable W95+ users to optimize old DOS and Windows 3.1 programs that were fussy or unstable under the later Windows operating systems. The good news: it's included free with Windows, and automatically installed along with the OS. The bad news: it seems to have little significant functionality to help any of our relatively-obscure music software programs (or anything else we've found, save only one long-forgotten word processor we sometimes need to retrieve old articles written in a proprietary format.) Mkcompat has no documentation nor Help files, and its options are complicated and nerdish: if YOU know what "Ignore discardable segment attributes" might mean, you're way beyond this article! And it does not solve the inability of pre-XP versions of Windows to change screen display mode on-the-fly and automatically at the start of a particular program. But, who knows: maybe the adventuresome and patient technoid at your piano studio might enjoy experimenting with it. Just click on the executable file mkcompat.exe to start it.
When we rebuilt our last 486 lab computer, replacing the motherboard with a 166 MHz Pentium on a board with a PCI bus, we naturally changed the antique Tseng Labs ISA video card to a new PCI-bus card with 4M of memory, thinking that we had made a distinct improvement. WRONG!
We immediately discovered that at least four of our Win 3.1 programs would not run on this new system: they all locked up during the programs' internal videos or animations. The culprit: "Video for Windows" (they kept changing versions, and ran all the way, as we recall, from 0.9 to 1.0e or g as bugs were discovered.) This utility, which was supplied by Microsoft but not built into Windows 3.1, was usually provided on the CD-ROM installation disk for the particular piece of software. We did some Googling and discovered that "VFW" had well-documented problems with certain video cards, notably the new one we had just installed! (See this article on the MS Knowledge Base about their own Microsoft classical music education program "Microsoft Schubert", a video crashing problem that also applies to their "Microsoft Strauss".)
The solution to this problem was, unfortunately, to take out the new S3-chip video card, and put in the old 1MByte Tseng video card into an ISA slot on the Pentium system motherboard. All programs now ran perfectly with no video anomalies. It is often necessary to make sure that you use software on contemporary hardware devices that are similar to what the program developers used, because they cannot possibly anticipate incompatibilities arising in later hardware and OS's. Be particularly careful about sound cards and video cards in this respect!
If you do not wish to keep an old inadequate computer to run your old software, you might find a good deal on a late-era 486 or early Pentium system: sometimes as cheap as $40-50! We haunt the used computer and surplus electronics stores in the Santa Clara valley for such gadgetry, and for the parts needed to keep these old, obsolete beasts alive: see our comments about the Sunnyvale store called "Weird Stuff" near the end of the article, below, for more information.
Furthermore, you might occasionally be able to make a very good deal on "abandonware" (as it is sometimes called): old DOS and early Win 3.1 16-bit software and operating systems. We have now converted our Win 3.1 machine to "Windows for Workgroups" 3.11 ("WFW"), available at a very good price at "Weird Stuff" and a few other stores: it seems to be much more stable, reliable, and crash-free than 'regular' Win 3.1. We also discovered, during our tests of WFW, that on the rare occasion when a badly-written program caused a lockup, the OS did not leave any "lost allocation units" on the hard drive, as 'regular' Win 3.1 almost always does due to the way it uses the Windows swap file: another plus, eliminating the need to run SCANDISK after a Windows crash. And WFW is a network-friendly version of Win 3.1, allowing us to set up our old computers on our modern ethernet system. For student lab purposes, Windows for Workgroups may be started in "non-network mode" by merely using the command line
If you wish to use WFW on your modern PC network, you should install Microsoft's updated TCP-IP32b protocol: download the self-extractor file TCP32B.EXE at the MS Support website along with the instructions in the various text files found therein; and you may find this overview of WFW networking a helpful resource.
In a certain number of instances, even when an upgrade was prepared, it was unsatisfactory. Without naming names to embarrass the well-known company, one major work of pedagogical software has TERRIBLE MISTAKES in the Windows version; we can't and won't use it, because students will be completely misled when they try to answer questions about key signatures and note identification. We were shocked at these blunders. The Windows version of this program is on one of our systems, unused; we still rely on the c.1992 DOS edition. Another program has musical snippets for identification, and transposed the filenames for two famous Rachmaninoff works, confusing a symphony with an excerpt from the famous Paganini Rhapsody. Yet another one used a bad edition of "Für Elise" -- in the wrong key, and radically simplified! Forward movement is not always progress...
So, if you think you might want to keep original old DOS versions of programs you have in later Windows 3.1 or 95/98 upgrades, here are some ways to do it:
ABOVE: Notepad editor has opened the system file MsDos.sys and shows the second section, [Options], allowing a choice of booting the "gui" (Windows' graphical user interface) or starting with a command prompt. The default value is "1" (normal Windows startup.)
If the BootGUI option is "0", then at the computer system startup, from the command line you may -- when desired -- type WIN and press the enter key, commencing the Win95 graphical interface. Or, old-timers who are fond of "raw DOS" may do their command-line magic. Normally, users of Win95+ systems who do not employ DOS need not load an autoexec.bat or config.sys file at all; but in this case, you must set up the machine's DOS path, memory management, and device drivers purely for your DOS programs, BEFORE Windows starts. Windows will more-or-less ignore most of those settings, and load its own "virtual drivers". But you will take a conventional memory size hit that may impact some Windows programs; check on the web for advice about Windows 95 memory management if necessary, as the details are beyond the scope of this present article.
The easiest and most foolproof way to edit the MsDos.sys file is to use "TweakUI", a small utility application that has been developed for each version of Windows from 95 forward. The Boot option menu will permit you to choose to boot to the "GUI" (graphical user interface; i. e., Windows) or to the command line prompt. Download the W95 edition of TweakUI at this official Microsoft link.
LEFT: Boot Menu Option, TweakUI 1.33 running under Windows 95.
Note the TweakUI Boot menu option "Start GUI automatically". With this box checked -- the normal Windows default -- the OS's graphical interface begins as soon as the computer boots its autoexec.bat file (if any), requiring no user keyboard input at that point (in other words, Windows 'really' starts.) Without the check mark, the system boots to a DOS prompt. Oddly, this "Boot" menu is presented by TweakUI version 1.33 when loaded under Windows 95 or 98, but not in ME (I don't know about W2000; never tried TweakUI in it; and XP users really should bypass 1.33 in favor of a different and more elaborate version, 2.01 or later.)
Those hardy and adventuresome souls who would like to "roll their own" and do manual editing of MsDos.sys are invited to read the instructions given at either the Windows-Help! website MsDos.sys page, or in the distinctly left-brained technical article on the official Microsoft Support site.
This process for setting up the boot display parameters is exactly what we've used to organize an old computer that runs our CD music library database. As explained and shown in the picture at the end of this article, an old machine boots first into the ancient DOS database program "PC-File". When it closes, we may -- at the DOS prompt -- either shut it off or start Windows (on our network) for moving around updated copies of the music database. We first tried it with DOS and WFW 3.11, which is clumsy to use on a network. Win 98 starts and closes very sluggishly, but the wait is much less annoying with the older MS operating system, W95.
Remember that not all DOS programs will work when executed from Windows, either by clicking on their executable file using the Windows Explorer, or from a desktop shortcut. This is because DOS-only programs require "real mode drivers" that Windows sometimes intercepts and replaces with its own "virtual drivers"; that's why our old MIDI programs written before Windows WILL NOT WORK AT ALL with Windows. You MUST start them FROM DOS, though you certainly may have Windows on the computer, as long as you haven't started it yet. This is of course very hard to do with Win ME and impossible with XP; and it is almost pointless with W98, as we explain below.
NOTE: Finally, as regards the present usefulness of old Win 95, one should be aware that the first version was extremely limited in functionality, in some ways not a very happy upgrade from Win 3.1. It is necessary to apply updates to the OS in order to obtain many of the user functions that were later incorporated into Win 98. There were formerly many webpages and articles about this, and even a functioning (as of February 2005) Microsoft Windows 95 update site -- usable only if one had replaced the steam-driven Internet Explorer 3 to the more modern version 5.5 -- but by spring or summer of 2005, many of these pages are destined to disappear from the Net. Accordingly, we aren't giving links here that we'll have to discard in a short time; we suggest you merely do a web search for "Windows 95 update" or "upgrading to Windows 95 OSR2" to see what links are available.
But why do it? Windows 98 takes a much longer time to load, AND TO QUIT, than Win 95 does. It really benefits from 2-3 times as much system RAM, if not more, than the (relatively) lean and lithe Win 95. Unless, of course, you simply don't have a copy of W95 gathering dust somewhere, unused and unappreciated, and DO have W98 available, you might consider setting up your "DOS and Windows" machine with DOS and 95, not 98. (Hint: if you are near a computer surplus dealer, you may be able to find brand new, shrink-wrapped copies of W95 for about $25! This old OS is, for all practical purposes, "abandonware".) And because Win 95 was the "logical" upgrade for older Windows 3.1 systems, a certain amount of care was taken with testing it with the DOS and Win 3.1 applications that were fairly recent. Furthermore, Win 95's install disk has many drivers for old peripheral cards, even some of the sound, video, and network cards dating slightly earlier than 1990. A considerable time elapsed between the period of development and the release of W95 and W98; by then, there was less concern for Windows' capability to run software written before 1995 for non-plug&play systems, and W98's install disk has dropped many of the old drivers.
Secret Hint:
If you are running W95/98 on a PC without Power Management, at the close of Windows you'll see the following instruction: "It's now safe to turn off your computer." SURPRISE! Just try, instead, typing:mode co80and pressing the ENTER key. Voila! You will get a DOS prompt. You may, if you like, run DOS programs, or even type WIN and press ENTER to restart Windows. This might come in useful one day, if you really did not mean to shut down!
Furthermore, many old software applications written during the DOS period were timing dependent and were designed to function properly on CPU's of a certain speed range. For example, the famous Borland Turbo Pascal language compiler -- used widely -- expected a particular characteristic of performance in the module controlling screen display writes; modern fast computers (quicker than somewhere around 300 to 400 MHz) often cause these old programs to display the "CRT bug" and fail to start, giving a "runtime error". You may find, as we have, that some of your old DOS-era music software has this limitation, and others, that make it useless on a modern machine with a clock speed of hundreds of Megahertz to over a Gigahertz. So, there's life in that old Pentium 1 sitting in the garage, or buried in a closet, as long as you haven't housecleaned away your old software!
Unless you have some specific reason for keeping Win9x on your computer -- perhaps the hardware is old, underpowered, or inadequate, or cost is an important consideration -- we suggest that you abandon Win 95 through ME in favor of XP for the most flexible compatibility with old Win 3.1 and later Windows software -- even for using some "non MIDI" DOS programs, which often run perfectly well in XP. And if you are still using Windows 3.1, you might consider upgrading to Windows for Workgroups 3.11 to obtain better reliability (with those old Windows OS's we find that 32 MBytes of system memory is adequate, and 64M -- which is the bare minimum we find acceptable for Win 9x -- will really make your system zing! And, of course, with XP you should not consider anything less than 256 MBytes of system memory, or even more.)
Video memory required by Windows 3.1's "standard" (for old 13-14" VGA color monitors and the early multimedia CD-ROM software running at 640x480 pixels and 256 colors) was about 1 megabyte on the video card: this is the minimum amount of video card memory we find useful on such a system. In upgrading to Pentium motherboards from old 486 ISA systems, we have frequently changed video cards to newer PCI-bus models with 2 to 4 MB of memory (perfectly adequate for 800x600 pixel ratio at "16 bit" color.) Fancy, expensive video cards are unlikely to be necessary for standard web-surfing or the kinds of music programs you will use in a piano lab.
WHEN YOU HAVE 'PERFECTED' YOUR INSTALLATION OF WINDOWS 3.1, SAVE IT INCLUDING ALL WINDOWS SUBDIRECTORIES IN ANOTHER PLACE ON YOUR SYSTEM -- ANOTHER FOLDER OR DRIVE -- AS A BACKUP. It may come in handy one day!
• A Few XP Anomalies: Upgrading From Win 95 Programs
We had better luck, generally, installing old Win 3.1 software in XP, than in adapting some of our old Win 95 era programs, due to XP's greater reliance on common file locations and the Windows registry.
The early practical version of Windows -- 3.1 -- relied very little on the registry, essentially an internal database that kept track of file types and linkages for various programs on the system. Most of the custom parameters of individual programs were stored in "INI" files (sometimes located within the programs' own subdirectories, but more often stuffed into the Windows directory in a sort of jumble) or in the two important setup files, WIN.INI and SYSTEM.INI. Later versions of Windows from W95 forward have tried to maintain some attention to these settings for "legacy" software, but by Win 98 and above, the registry was now the place where almost all program parameters were stored. Old Win 3.1 programs are sometimes a bit problematical for later OS's, because they rely on ancient 16-bit drivers that -- say -- XP may not "like". Luckily, almost all the music programs we tried to port from Win 3.1 to XP were adaptable and installed conveniently, requiring only attention to their video compatibility mode for setup and final running mode.
Some programs written for Win 95, however, just won't work in XP. We were forced to upgrade the pedagogy program teorķa to Version 2.0 because the original edition refused to save files to the expected location, changed in XP with its all-new, complex series of nested folders for common user files. This was a simple fix, but it necessitated downloading a gigantic 20 megabyte file, which was nearly impossible at the time due to our shaky dialup Internet connection (no longer a problem for us on DSL.) Though the author of teorķa gave us a small discount for the update (since we were a registered user) we nevertheless had to pay for the privilege, a bit frustrating since almost all earlier Windows software we had been using posed no such problem.
Two other exceptions included a scoring program, which absolutely REFUSED to load and install from the original expensive CD-ROM disk (which kept giving us an anomalous and incorrect warning that it was an "ILLEGAL COPY": not true! We had paid more than $100, direct from the factory, for that disk!) An email to the company yielded no answer whatsoever. At last, we remembered that we had also purchased an earlier version on floppy disks; that installed flawlessly with no such erroneous message about "illegality" (what an affront to a licensed, paid customer!) Another program, a well-known piece of fancy instructional software, simply could not copy its files to an expected location that was standard in an earlier version of Windows, so the installation from the CD-ROM disk failed. After studying what went wrong, we got the idea of copying the ENTIRE disk onto its own hard drive folder. Win XP machines come with gargantuan hard drives these days -- many gigabytes -- compared to the old small drives of Win 3.1 and 95 -- so we had about 10 GB of free space. The CD-ROM installation disk took only about 300 MB of space, an inconsequential amount. That did the trick! Now the program not only installed, but also looked NOT to the CD-ROM drive for its "on the fly" sound files, but to the hard drive installation folder: the program runs faster and does not require the use of the CD-ROM disk. Sooner or later, however, we shall purchase the specific Windows XP upgrade for this program, and delete our other "hacked" installation, since the later one has better features.
This small obstacle was but one of many experiences we have had over the years in using "niche" software. Music education programs are perhaps the ultimate examples of such obscure stuff, in the entire vast cosmos of the PC. Are such programs 0.01% of the overall market, or 0.0001% -- or less? You can well understand that the end user and customer becomes, in effect, the beta-tester for such products. The companies that design such stuff will never have as many potential customers as entrepreneurs who produce web browsers or digital camera photo processing software. This leads to two distinct consequences: (1) high cost of the software, compared to equivalently complicated programs for more "normal" interests; and (2) bugs that are never found, in use situations that are never contemplated by the developers. We have had far worse problems in the past than this recent small glitch with the music game, so the trend seems to be a general improvement in program reliability and sophistication, along with the rest of the industry. But frustrations are still to be encountered, and to be expected as a normal event in the bumpy road through the home computing maze. (Ms. Roper and I have both contributed more comments and complaints about such issues in a companion article about our computer labs, written -- we hate to admit -- rather a long time ago.)
• Different Performance of CD-ROM Drives Perceived under XP
XP also seemed much fussier about the technical performance of the CD-ROM drive. When we built the machine, we simply took the old 40x CD-ROM drive (only about 3 years old) from the Win 98 computer we were rebuilding. But when Win XP read audio files (either WAV or CD format) from this drive, it produced a horrible crunching noise that did NOT occur under Win 98. We tried every conceivable trick to correct the problem, including a recommended upgrade to Version 9 of the Windows Media Player. Nothing solved the noise anomalies. Finally, we purchased a brand new 56x CD-ROM drive, and the problem stopped immediately. Yet, the old 40x drive worked flawlessly in other machines running Win 98 or ME...strange.
One final residual problem with our lab XP computer has prevented the use of a certain multimedia program that reads all its files from the CD disk, interspersing graphics and WAV files continuously. Under our Win 3.1 machines -- after setting the audio buffers to '9' as explained above -- the program runs perfectly, and even did so with slowish 486 computers, with seamless, noiseless transitions of the audio files. Under ONE of our two XP machines, however, the sound is full of glitches: burps, clicks, and other momentary interruptions. As the files are read from the CD, they aren't apparently cached and buffered effectively to maintain an even stream of audio. Our other XP machine, in the author's office, runs the program perfectly. The difference seems to reside in the sound chips in the two systems. The office machine uses the old Turtle Beach/Malibu sound card; the new lab computer has onboard sound built into the motherboard using a different sound chip. Oddly, the ancient sound card handles the sound data stream more smoothly: why, we can't fathom. After consulting advanced XP manuals, and the MS Knowledge Base, we can't find any settings in the OS that are comparable to the optional MCI Sound Driver buffer settings for Win 3.1, so a solution has not yet been found. So, we haven't moved the programs from our Win 3.1 lab, to our XP lab.
UPDATE: 2/05: Say, DON'T throw out your old, "slow" CD-ROM drives when upgrading to better hardware. If you are still using Win 3.1 "oldies but goodies" as we are, a fast CD-ROM drive is not necessarily desirable. For example: in our Lab 1, a Pentium 150 MHz system, we had been using a 40x drive. It had replaced the old original 8x (!-wow; how quickly we forget) that barely loaded files fast enough for multimedia applications. Sure, the 40x drive seemed "lightning fast" all right; but it made a HECK of a noise, revving up to an alarming rate and growling away ominously on some CD-ROM programs. In February 2005 we rebuilt the lab machine, and our first "natural" assumption was to put in an even FASTER drive. But was a 56x drive really necessary? We did some experiments, and found that a SLOWER drive was, indeed, BETTER! We changed from the 40x speed drive back to an even older 24x drive -- and the growling was gone! The multimedia CD-ROM programs started and ran just fine, without the mechanical noise that was sometimes so irritating. Now, this system runs Windows for Workgroups 3.1, not a later version of Windows. But -- amazingly -- even the 24x drive on an allegedly "slow" old computer, runs certain pre-1995 CD-ROM multimedia applications far better than the 56x drive does on our XP Pro lab machine (with a CPU clock speed that is ten times faster!) The lesson learned: Don't fall for the myth that LATER IS ALWAYS BETTER. Newer hardware does not always offer an improvement, within the context of the computer software you want to run, and when it was written. Old, slower equipment may work BETTER and provide more satisfaction under some circumstances!
Of course, in this particular case, one must remember that old CD-ROM drives built before about 2001 or 2000 may not read home-brew CDRs, especially on W3.1 systems. If you have the time, inclination, and garage full of discarded PCs that we have, you can certainly find out if a slower or faster CD-ROM drive is better for your own application. Changing the CD-ROM drive is one of the simplest modifications to a PC that even a beginner can tackle, as long as you remember exactly how the drive connector ribbon cable is attached, with the "red wire" on the 40-lead cable oriented nearest the 4-lead power plug. Remember, too, that Win95 and later tend to change the letter of the CD-ROM drive if you replace the hardware; your "E Drive" might slip back to "D", for instance. Check the Device Manager under System Properties (right-click "My Computer") after changing the CD-ROM drive to see what letter it was assigned, or to change it to the one you want. In XP this is more complicated and requires using Aministrative Services from the control panel: a lengthy procedure that you'll want to bone up on by reading this Microsoft article.
One cautionary note must be observed for those of us who have old, traditional MIDI piano keyboards, sequencers, and other external devices that must be connected to a computer. For many years, these gadgets were hooked to the 25-pin "gameport" of the computer sound card. We had not realized that this had been abandoned in 2003 by MOST computer makers, until we made a purchase of a brand-new "eMachine" computer, a great bargain with a fast CPU, Windows XP Home Edition, and tons of software at an amazingly low price of only $399. After so many years of "homebrewing" our own computers, we thought it would be a breeze just to put down the credit card on the counter; pick up the box; take the system home; and hook it up. But, NO!
What we discovered, in shock and dismay, was that there was no gameport! The maker left it out; we had NO way to hook up our Roland sequencer and piano. Nada. Nothing. Forget about it...
It seems that the makers have decided you must use the USB port from now on! And that means all new connectors; and figuring out how to adapt your OLD sequencer and piano, and to deal with any incompatibilities that may (will) arise. We did some research and found that it would cost us about $100 or more to adapt EACH midi piano to USB; we would have to mail-order the MIDI USB routers -- they weren't available anywhere locally -- and to get all new cables. What a problem! And some research via Google showed that many people were having trouble with USB initialization of their MIDI instruments, sometimes requiring computer reboots (no, it's NOT supposed to happen; but it DOES happen!), or disconnecting-reconnecting the MIDI devices several times until they "take" and activate. Or you might find that the USB port does not provide enough electrical current...then you need to purchase an externally-powered USB router. Then, there is the complexity of forward and backward compatibility issues with USB 1.0 versus USB 2.0: on and on...
Of course, once you make these changes, the equipment won't work on earlier computers until you change all the cables and connectors. ALL THIS TROUBLE AND EXPENSE simply because the makers of computers just had to leave out one connector on the back panel!
We said NO!
So, back to the store went the new "eMachine" system, and we built another computer using a conventional sound card with gameport, and though lots of labor was involved, we did not have to change our MIDI peripherals, waiting days or weeks for mail-order deliveries.
An alternative would have been to tear the new ready-made computer apart; change the BIOS settings and shut off the internal sound system; add a sound card; and reconfigure everything. But this would void the warranty. So the choice we made was, for the present, to continue to build our own systems and use our "legacy" MIDI equipment with them. In future, we may be forced to adapt; but not now, thank goodness.
We're no MIDI experts -- at least we're not in the league of studio musicians who use MIDI all day long on a plethora of devices -- but have learned one- step- at- a- time while trying to cope with changes of MIDI standards and devices over the years. Our first MIDI piano/software combination used antique c.1989 Music Quest MIDI cards with UART chips that had embedded hardware instructions that old DOS software programs invoked. The cards produced signals directly back to our simple MIDI controller keyboards that made them respond to piano keyboard input, and to create piano tones in the instruments from the MIDI data output; the cards also routed MIDI data to the synthesizer chip on early sound cards (which produced a rather raw, buzzy tonality that at least had the right PITCH if not the correct timbre.)
When Windows 3.1 was introduced, one could use more advanced sound control methods and properties, including some rare, expensive Yamaha sound cards with complicated wave table synthesizers: we never got one of those, unfortunately, and continued to use that buzzy synth sound from the computer audio system, preferring instead to turn off the computer speakers and to turn up the piano speaker and get the "correct" piano tone.
At some point in the early 1990's, MIDI-II was introduced, and the makers of MIDI controller cards left off the complicated UART chips: those cards will not run the earliest DOS piano software produced by such companies as Electronics Courseware Systems (producers of "Keyboard Name Game", "Keyboard Note Play", and the like.) If you cannot obtain an original pre-MIDI II controller card, you must use these programs in "sound off" mode.
We prefer now to run the second generation of DOS piano software that eliminates the need for the MIDI UART chip, or even later Windows-era piano software that relies on the sound card's own synthesizer or wave table. Unfortunately there are very few sound cards for Win 3.1 that have a wave table; but around 1995 we located a superb Turtle Beach/Voyetra "Malibu" sound card that could provide wave table function under Windows 95+, and in Win 3.1 had an excellent synthesizer chip that could simulate a piano tone that was incredibly close to a good wave table sample.
We purchased as many of the Malibu sound cards as we could find, and currently have five of them on systems using Win 3.1 to XP: they are exceptionally useful and universal cards that you might keep an eye out for. Under Win 3.1 the built-in synthesized sounds may be enhanced somewhat by running an inexpensive shareware sequencer program called "WinGroove", written by Hiroki Nakayama. We registered a copy but now rarely use it, since the Malibu card's native synthesized sounds quite well replicate the first 128 of the general MIDI sounds; with other cards under Win 3.1, WinGroove may be exceptionally helpful (however, its setup is somewhat fussy, and it does not work effectively on systems slower than, say, a 486-66.)
One caveat about MIDI controllers/pianos: not all of them use "OMNI" mode. We discovered this arcane issue a few years ago when a company sent us a sample of new music software that purported to teach piano performance using fancy multimedia techniques. We could NOT get back any piano sound from the program on any of our MIDI instruments, ranging from inexpensive Radio Shack midi keyboards to a $1000+ Casio CPS-80 to our big Roland piano that cost originally more than $4000! Emails were exchanged with the software authors and publishers to no avail. They had NO idea or solution...
Finally, our friend Bill Griffin, owner of Allegro Music (a dealer in piano lab equipment and instruments) clued us in: he intuited that the MIDI keyboard had to have OMNI mode. And he rented us a brand new instrument that worked with the software! We wrote back to the authors and pointed out that their box, literature, and website stated that their program "worked on any MIDI piano" and that this was actually not correct; OMNI mode was essential! They replied that they hadn't realized that people would try it on pianos that DID NOT HAVE it, so it hadn't been pointed out.
So, don't be surprised if your various generations of MIDI devices, sound cards, controllers, pianos, and software fail to produce what you expect from them. MIDI is supposed to be standardized; but like everything else in the technological world, standards seem to evolve constantly, much faster than normal people can cope with or tolerate.
UPDATE: 2/08: I can't retract a WORD of what I've written in this article about the unreliability of USB, even on a new computer running the latest updates of Win XP. In early 2008, a classical music enthusiast of my acquaintance posted on the newsgroup rec.music.classical.recordings that he was using an external hard drive and moved the USB hub (apparently shifting its position on the table); the hard drive was instantly "scrambled", losing the contents of the file allocation table. After much repair wizardry by a friend, many of the files were retrieved -- but they had lost their original names, and now some 100+ gigabytes of files were unintelligible to him, and more or less useless, many being music files with the names recording the identity of the works and performers. Other posters chimed in with similar tales of woe: one person lost 500 Gigs of files that same way! Just today, I spent two solid hours with three XP systems, TRYING to get a USB external hard drive to initialize. Two of the computers simply refused (though they worked fine with other USB devices, such as webcams); the third machine required about six reboots and a dozen power cycles of the external drive before the operating system recognized it. I do NOT want to hook up pianos to our computers that way, and have problems at the start of lab sessions!
• "Windows can't find file 32midisnd.sys..."
If it weren't for copyright, I'd have included here an illustration of Edvard Munch's The Scream; so I snapped my own visage in a familar pose, and created my own version. For being an impatient person, I am usually bouncing off the walls of the computer lab during almost any attempt to install a new MIDI card or other peripheral in our various Windows systems; the ghastly expression in Munch's famous painting perfectly captures my mood ("The horror...!")
Problem is, Windows seems to have trouble installing many devices. The difficulty has existed since the inception of Win 95, though it seems entirely unpredictable: sometimes it runs smoothly; sometimes installation grinds to a dead halt, failing miserably.
The ideal scenario should be this: (a) you boot up the operating system with a new peripheral card; (b) the motherboard plug-and-play function passes the correct identification of the card, read from its chips, to the OS; (c) Windows immediately decides to look for further information about the device; searches for any descriptions already loaded in its Registry; if finding none, requests an external driver disk; (d) Windows reads the contents of the driver floppy or CD-ROM installation disk, correctly identifying and located the information file (the cryptic instructions it needs for proper installation, contained in a textfile with .INF extension); (e) it carefully recalls the location of this file so that it may refer to it, repeatedly, during the installation process; and (f) the OS copies all appropriate drivers into the Windows SYSTEM folder or elsewhere as needed, "registering" the files and rendering all functions of the peripheral card operable.
What actually seems to happen is this: (a) the motherboard plug-and-play BIOS gets confused, and perhaps fails to pass on the proper identification to Windows; (b) the OS realizes that there is SOME KIND of new card present in the system, but can't QUITE figure out what it is -- so that the end-user has to choose from a series of options that are not exactly appropriate: often a MIDI card or other perfectly normal, well-documented device must be declared to Windows as simply being called "Other", for it fails to be pigeonholed in the exact category that Windows refers to; (c) the OS tries to begin the installation of drivers, but cannot locate or parse the INF file; (d) the first go-round of the installation fails; you reboot the system and perhaps repeat the process with other unsatisfactory results, each time being slightly different but always concluding with a botched non-installation. The new peripheral shows up in the Device Manager with a big, bad, ugly "yellow exclamation point" next to it, and a detailed comment "This device is not working properly; you must reinstall the driver file."
After many years of dealing with this incessantly-repeated phenomenon, I have intuited that there are two or three main reasons for the breakdown of the process:
One would think that this problem would have been dealt with in the first upgrades to Windows 95, the OS2 version; but it has not been solved even in XP. I have tended to find that Windows 98 and 95 do have this particular bug with more predictability than Windows ME or XP, but it still occurs in those later versions from time to time. This can mean two, three, or more tries to install a device, and even a complete failure to accomplish what should have been a simple, straightforward task.
Often the best way to accomplish a successful peripheral installation is to copy the entire installation disk (floppy or CD-ROM) to the hard drive. Windows' File Manager search functions seem to work better on the local machine hard drive than on the directories of "removable disks". So, if you utterly fail to be able to install a device satisfactorily, and the failure seems to be related to "missing files", try making an arbitrary subdirectory/folder on your hard drive, and copying to it the entire installation disk. Log onto THAT hard drive location when Windows asks you for an installation disk. And be sure that you make note of any INF files that may be present. They are the critical ones that give Windows the instructions it needs. Occasionally they may be corrupted, incomplete, or un-parsable (perhaps very old ones for Win 3.1 that -- say -- XP does not really understand.) Left-clicking on an INF file should open the Windows Notepad; the file should be readable as lines of text containing instructions (that are probably incomprehensible, even to many experts; but they should not be gibberish characters.) Warning: remember not to right-click an INF file unless you absolutely intend to install it. Right-clicking such a file may cause Windows to try parsing and acting on it immediately, or at least to offer you the option to do so. You could accidentally activate this function at an inappropriate time.
If, during an upgrade or installation, you find that the above suggestions fail to solve a problem, you might as a last resort write down carefully, word for word, any error messages you get onscreen, and paste the message into a web search engine, such as Google. Be aware, though, that specific memory address error locations are probably unique to the installation on YOUR own system, so the addresses given (such as "memory address 0x4000af50") are generally irrelevant for troubleshooting, being more useful as a general indicator of a system memory failure or conflict (only an expert running a memory analyzer and a debugger on your computer could probably benefit from those exact hex address locations.) However, it IS entirely useful (and often repeatable over a wide population of computer users) to search for the same specific types of errors, and precise syntax: one can often pinpoint the exact cause of the problem, and see that other people are experiencing it as well with that OS and device; but it's then rather frustrating to find only further posts on websites, forums, and in newsgroups that merely corroborate the problem without offering a positive solution. If nobody seems to be able to fix the trouble, perhaps you may learn that what you're trying to do just simply won't work in your exact software/hardware context.
In order to find out about common problems and solutions (and perhaps vicariously to 'enjoy' masochistically some of the callers' horror stories), I used to make a point of listening to the now-discontinued Bob O'Donnell program "Everything Technology" (formerly "Everything Computers"), broadcast at 10AM Pacific time on KSFO-560, San Francisco. Bob's old archived programs are available as streaming files; and the better-known Leo Laporte is now heard on a comparable program on KGO AM-810 on Sunday from 11 am to 1 pm. As much as I appreciate Leo, I do feel sorry to lose Bob O'Donnell (a MIDI expert, who sometimes touched on technical issues relevant to piano and music instruction and composing.)
I sometimes have a wistful fantasy: that one day, long into the future, someone at Microsoft will look at the way the installation process works, and decide "Maybe it's time we broke down and rewrote these routines instead of merely importing the old code we hacked out for Chicago" [the in-house name for Win95]. Will it ever happen? Sigh...
A general dictionary may define latency as being "the state of being dormant"; in the PC-MIDI world, latency could be described as a delay between the initiation of a MIDI signal, and its reproduction through the system sound card and/or in an onscreen display of an instrumental keyboard. Latency problems often occur with older hardware using slow chips, or if adjustable data buffers are set too low. The best-developed MIDI pedagogical software (such as the excellent program Music Ace) is likely to have foolproof user settings for fine-tuning the entire MIDI chain/computer, so that when a piano key is depressed by the player, the MIDI sound emanates instantly from the speakers at the precise moment that something relevant to it appears onscreen.But there is no "global setting" for this in Windows or DOS; it is up to the author of a MIDI application to add such a function. Sometimes the problem of long, frustrating MIDI latency may be resolved by using a faster computer CPU (for instance, the program teoria had latency delays under Win98 on our old 100 MHz 486, though it has no trace of latency when running on our new 1.6 GHz Pentium IV using XP-Pro.) At other times, the latency problem is simply built-in to the software architecture, which might have been created with a primitive, poor, or inefficient language. In such cases, one may have to defeat the "MIDI Thru" settings of the software program, muting the MIDI output from the PC sound system; otherwise there will be terribly irritating "double notes" or excruciating waits after depressing a piano key. If the program is still being supported, you may find suggestions on the company website (though, often we find that developers are wary about making admissions of potential problems in the documentation for the software. Or, the problems show up long after the product marketing has begun, so that their explanations and solutions don't show up in the instruction manual.)
• Roland MIDI Incompatibilities
When, in 2001, we purchased a new, expensive Yahama "Clavinova" digital piano, we were assured enthusiastically by the local salesman that the instrument would be backward-compatible with the old Roland file format, as Regina was anxious now to be able to use some of the hundreds of diskettes she had created on the MT-200 during live lessons in the main studio. But, nearly $5000 later, we found that the salesman had misled us: the Clavinova made no sense of the files and could not read or load them. So we have a permanent file incompatibility problem that can be overcome only by loading the files into the MT-200; outputing the digital data into the computer, and re-recording a new MIDI file in real-time, a daunting process that -- considering the labor involved, over many weeks' time -- we don't even consider attempting. Furthermore, we had earlier discovered that even the current model of Roland pianos did not seem to be capable of making any sense out of the files from the old MT-200 sequencer; so the gadget is "lost in time" as far as modern equipment is concerned, even while being fully functional in its original sense. It is frustrating to have two instruments, not a decade old and costing originally $1500 each, to be so utterly obsolete; but that's the inevitable consequence of change in a technological world where future profit is dependent upon upgrades to new hardware and software.
Here's another "computer anxiety factor": at the Roper Piano Studio we have a dread of crashed hard drives (dating back to an unfortunate experience in the 1980's on our antique 8MHz IBM XT computer), so we've developed a backup fetish. Why re-invent the wheel? It might take us several days of dedicated, steady work to put together a "new old computer" from parts; install the OS and software; and set up all the felicities of the computer lab. If the system's drive fails, or if we need to upgrade the hardware while retaining the OS and programs, we find that it is often possible to save redoing all of this hard work by using a backup. In former times we used Norton Backup 1.0 for DOS, and dozens and dozens of floppy disks: a tedious process that might take most of an afternoon to back up a couple of hundred megabytes of disk data. Then we decided to keep a perfect bit-by-bit backup copy of our hard drives on the shelf; changing a drive can be done in only a few minutes if one should fail or become hopelessly cobbled up in some complicated way. We have used the programs "Diskclone" and "Drive Copy" with considerable success over the years.
The latest hard drive backup software, probably to prevent difficulties with the makers of operating systems, will produce a slightly "crippled" copy of the hard drive that won't immediately boot. You must run a utility on the backup program's CD drive, booting from it, that will "unlock" the hard drive so that it will boot up: a minor inconvenience but worth the trouble to keep a backup of a REALLY large and complex modern system. Older OS's and simpler programs may often be backed up merely by "dragging and dropping" their program folders onto a blank CD-ROM drive in the later versions of Windows, with systems equipped with the appropriate CD burners and software; we do this over the network and have made backup CD's containing the necessary files to keep the DOS/Win 3.11 systems completely documented so that a rebuild takes as little work as possible. (One must pay close attention to the filename character conventions of DOS & Win 3.1 vs. later Windows -- i. e., short versus long names -- and to change the CD's "read-only" file attributes after copying, when using this method of backing up files.)
Often, if you have changed hardware -- video cards, sound cards, motherboards -- you MUST re-install Windows. Our preferred method is to use a backed up version from the old system, and install OVER it using the new hardware; this keeps all the complicated program parameters intact while allowing Windows to change only what is absolutely necessary. The normal wisdom is to do ONLY a "clean install" of Windows onto new hardware, and then rebuild the system by reinstalling the old programs and data files. Frankly, we've found that our method works fine MOST of the time, as long as the original installation was flawless! We have even installed Win 98 over Win 3.1, or Win XP over Win ME this way -- and everything worked fine.
If you have a blank hard drive, or one with the old OS in place, what do you have to lose? If the process fails, you may merely "wipe" the drive and start over again with a "clean install" of Windows in the recommended fashion. Of course, if you MUST keep the old version of Windows intact, then make a backup hard drive copy and store it away safely, and you won't lose anything. As long as you don't use it in another computer, ever, you are not violating (in our view) the license; it is merely a safety backup for archival, security purposes.
There is an endless amount of advice we could give, based on our many mistakes over the years: but perhaps the most important thing is to make a DOS and a Windows boot floppy disk for your computer! Instructions are provided by Windows, and a general source of helpful advice may be found on Bob O'Donnell's "Everything Computers" website on his Troubleshooting Resource Page.
I carefully worded the headline to this section, since I do mean merely "contemplating". For -- as explained above in the section quoting Hutber's law about the coexistence of DOS and Windows applications on the same computer -- if you value the careful work you've expended in setting up an ergonomically usable lab PC, you should take care to protect what you've achieved before trying to install any new application you haven't tried on a specific unique hardware setup. There are pitfalls to be wary about --
• Old DOS/Windows 3.1 era software:Though old software may be useful, remember that it was developed in a different era, with less strict controls on installation processes, and less flexible equipment. DOS music/MIDI programs tend to run properly only on certain hardware, specifically the sound, video, and MIDI cards that the developers had on hand for testing. That means, of course, that a DOS program from 1990 has no built-in adaptibility for later hardware. And DOS, a simple operating system, has no forward-compatibility, and little backward compatibility. DOS 3.3, for example, is a "snapshot in time" and may not work correctly with the batch files written in programs developed when DOS 5 was current -- unless the authors were careful and TESTED the software under all previous versions of the OS; most (sadly) seemed not to have done so. And they certainly did not contemplate running their applications in the "virtual OS" provided to DOS programs by a Windows machine.
But perhaps the worst blunders made by developers of old software occurred during the installation procedures. It seems likely that more often than not, the install program changes the critical autoexec.bat and config.sys files on the PC, sometimes wrecking other program functionality or even disabling the peripherals, or clobbering the memory management. 9 out of 10 times, the installation programs alter the PATH statement in the autoexec.bat file, with total disregard to what it already says. Sometimes the existing PATH is completely trashed, replaced by a single path statement to the 'new' program; i. e. PATH=D:\C-CLEF or something of that nature. The old PATH statement to the locations of other programs, or to the Windows directory, will be over-written. This alone tends to make many old programs instantly inoperable, at the expense of the new one being installed. We railed against this and wrote letter after letter of complaint to developers, to no avail. The only recourse is to SAVE THE EXISTING AUTOEXEC.BAT and CONFIG.SYS FILES BEFORE TRYING TO INSTALL A PIECE OF SOFTWARE! Unless you enjoy writing and testing these crucial setup files -- I confess I rather do; but I'm a software writer! -- you may be faced with days of work or the need to secure assistance, in order to get your machine back in perfect order again, if you allow these critical files to be wrecked. At least, by using the old original copy and comparing it with the new one, you (or a PC-expert assistant) can rewrite the file's commands properly.
On occasion, an old program's installation process (executable or batch file) will merely add a final line to the autoexec.bat file that will start the program, or change the PATH statement. I have found that these added statements will come AFTER other ones that are absolutely essential, often conflicting with system needs and operationally disabling the 'new' program; the stupid authors of the installation programs did not apparently even CONSIDER this likely occurrence. The silliest thing is, for instance, adding a statement about a new program AFTER the previously- existing last line statement WIN at the end of the autoexec.bat file! Thus, the program will try to start itself AFTER you exit Windows...what can such software writers have been smoking?
Another program that we tried, but won't use, ignores its own proper subdirectory and insists on writing files directly into the boot hard drive's root directory (a frankly lousy idea that was probably added, I intuit, at the last minute as a "bug fix" to correct an improperly-written main application.) I wrote a letter of complaint to the developer and received, unfortunately, a rather uncomprehendingly dismissive reply. As a software developer myself, I can assure the gentle reader that procedures exist in common software languages that enable any program TO FIND ITS OWN FILES AND OWN LOCATION, and to read and write data to the "correct place". The amateurishly incompetent developers and project managers of this application simply ignored those procedures and rules.
Therefore, when contemplating the installation and use of such old programs, I always try them out on a COMPARABLE SYSTEM that is separate from a working lab computer. And, even if I am satisfied and wish to use the software in the lab, I tend to do a careful backup of crucial parts of the machine's hard drive: the Windows subdirectories; the boot files (autoexec.bat, config.sys); any profiles or data files of an existing memory manager (i. e., QEMM's "pro" file); and any existing operation menu in its state just before installation of the new program.
• Windows 32 bit OS's, and old/new applications:
Unfortunately, rather little can be done to protect a Windows 95 or 98 system from being "clobbered" by a bad program installation. A Registry backup is advised before installing new software; if possible, familiarize yourself with the use of the command-line utility SCANREG -- see a good advanced book on using those OS's, such as Brian Livingston's invaluable "Secrets" series -- so that you may, under the worst of all circumstances, roll your machine back to an earlier 'clean' registry after booting it from a startup floppy.
Users of Windows from ME forward are wise to set a new System Restore point and to back up the Registry before installing new software. If you are using WinTidy (as we recommend in this article) you should save your pre-installation desktop arrangement.
Some old Win 3.1-era apps make silly, unnecessary changes to the autoexec.bat and config.sys files, which (if you are using no DOS applications) are not needed in Win95+. They often add themselves to a PATH statement, ignored by Windows 95 or later. These settings are properly transferred to the properties of the desktop shortcuts that start the programs, or to the Start menu settings. Windows tries to do this correctly, and usually succeeds. But if you do rely in any way on existing autoexec.bat/config.sys files in your Win 95+ systems, SAVE THEM FIRST before installing any old Win 3.1-era app. Compare the files to see if the changes are necessary or proper.
Furthermore, old Win 3.1 apps do not -- in 99% of cases -- have a proper "uninstall" feature. Seldom do the writers even bother to document the process in a README file, and to inform the user exactly what files are written to the hard drive, and to what directories. If you need to take out such programs, you will have to attempt the process with a Windows application, such as McAfee's UNINSTALLER, since Windows itself won't have an automated uninstall process for such old software. In some cases, it may be wisest to leave the unused software safely in place; new Windows machines have HUGE hard drives that are dozens of times larger in capacity than old Win 3.1 era PC's. Leave the old stuff alone and forget about it (unless its presence is somehow negatively impacting the system); delete the desktop shortcuts but leave the files in the program's folder alone. You can also bet that such old software wrote 16-bit driver and dll files to the Windows SYSTEM folder. They may simply go "dormant" and be harmless, just taking up a small amount of drive space. (Of course, leaving an old unused app on the drive may not be possible if a new version refuses to coexist with earlier incarnations of the same application; one may have to make the proper decision on a case- by- case basis.)
New 32-bit Windows apps are written with more tightly-controlled rules, and tend to use a sophisticated installation package that works according to strict Windows system structure. But some applications sometimes change installed Windows plugins or applets (such as DirectX or Shockwave) which do not take into consideration the needs of other programs installed earlier. You should run a system report using a utility such as Lavasys' Everest Home Edition (a freeware app available for no-cost download on the web: a quick search will turn up many links and recommendations.) This helpful program will run on any Win95+ system and report in detail on the hardware, OS, installed modules and programs, and every conceivable detail of the hardware and software environment. We always save a report for each machine in ASCII text form on the root directory of each PC's hard drive, readable from a boot floppy using a simple text editor in case we cannot boot up Windows properly. This program will tell us, for instance, exactly what video card is installed, in case the crucial driver files become corrupted, preventing a proper Windows bootup. And once you are sure that the new application works fine -- without affecting anything else on the system -- run a new report establishing the current state of the system.
• Ugly Things to Come -- Here Now
One of the worst aspects of today's increasingly paranoid computer environment is that developers are once again introducing insidious forms of copy-protection into their software. In the DOS era, such efforts failed, and by the early nineties most programs were "clean" and copyable from disk to disk. Developers whined that their programs were being "stolen", but such freedom made the life of the system administrator a much easier one. You could test programs before installing them "permanently"; and easily upgrade your computer hardware without getting an entirely new copy of valuable software that you had no intention of "stealing" anyway (after all, you'd already paid for it, and merely had to move it to a better PC.)
But with today's web software downloads, all too often you get a zipped file that has to be installed with a unique password that is provided by an automated process supplied by a function on the developer's server. If you change the machine in any way, though of course you are making no attempt to "steal" the software you've paid for and legitimately use, you may find that the program will no longer run; it may even insult you and accuse you onscreen of theft. One program we employ effectively prevents the use of the OS's defrag process! If we perform normal (and recommended) occasional disk defragmentation, the program refuses to start, claiming that it is an "altered" or "unauthorized" copy! Another one (as mentioned above) refuses to install in XP, claiming that the installation CD-ROM is an "illegal copy". Yet this factory-produced commercial CD-ROM installation disk cost us a hundred dollars and is NOT a copy; it merely has a stupid, clumsy copy protection program that can't understand something unexpected when files are copied into an XP system. So, just because a program you've purchased installed properly years ago on (say) Win 3.1 or 98, you have no real guarantee that it will re-install when you upgrade to XP (or later) OS's. If the application is invaluable and unique, you may have no choice whatsoever: you will have to keep it on the OS with which it properly works.
|
One day we changed an office machine and were forced to do a complete system rebuild after a hard drive reformat. A favorite application, which we'd obtained two years earlier as a shareware web download (subsequently purchasing two costly registered upgrades for full functionality) refused to re-install, informing us tersely that the key generator program "was out of date." PLUNK! Down the drain went nearly $200 in registration fees; the program was no longer sold and its authoring company was out of business. What to do? We had no recollection whatsoever that the EULA (end-user licensing agreement) had admitted that the software was 'time dependent'; indeed, on checking later, it did not honestly and openly admit that! We finally figured out how to manipulate the date in a way that enabled us to install the program, but learned in the process to be careful of web-downloaded software and the registration process to obtain the full usage of what you've paid for as an end-user. Chances are that some obscure setting in the Windows registry saved the date of first installation, encoded in an unreadable form and secreted somewhere not at all obvious; you'd never find it. So an attempt to reinstall a program YOU PAID FOR AND ARE ENTITLED TO USE could fail unless you start from scratch after deleting the ENTIRE Registry, obliterating Windows and requiring a complete system reconstruction. Forcing a paid customer to do this, with no other recourse, is severe punishment, but some software authors do it "to protect themselves" in case a few people are tempted to abuse the user-license by, say, trying to extend the date of a free trial period. So, expect much less flexibility in matters of installation/re-installation from downloaded software, compared to hard copies on commercially- pressed CD-ROMs. As traditional "old time" music teachers who grew up before home computers existed, can we ever imagine or adjust to a world in which a copy of a score, or a music pedagogy book, blithely informs us that 'this resource is out of date and you can't use it'? Yet this time is coming, as every concrete artifact that we see, read, and hear is being digitized.Lesson learned: be forewarned. Carefully save every downloaded file, serial number, key generator (don't recopy the file and lose the date stamp!); and if you are not certain, email the developers and ask them if their license for the program entitles you to move it to a new machine, if you upgrade.
The author refers to one of many file folders of diskettes and CD-R copies of downloads. All system BIOS settings, program serial numbers, and information for installation and use of each program are collected here: thus there are very few chances of anything being lost or mislaid. |
We've heard worse horror stories from our Mac friends. A scientist acquaintance, who works in the public sector, once told me that every year or even more often than that, his department upgraded the Mac OS's as each new "decimal point" upgrade was released. Repeatedly, however, a $10,000 spectrum analysis application was 'clobbered' and rendered useless for weeks or months, since it balked at almost every OS upgrade. The management of the department refused to allow at least some of the Macs to "stay" on an old OS; so valuable time was lost every year during a long period after each "forced upgrade", until the developers released a patch.
Luckily, the operator of the private piano studio is under no such obligation to follow the constant "upgrade harping" by applications and OS's: so our advice is to be rather cautious and conservative about OS upgrades. Certain recent OS upgrades or web updates are not always felicitous, and may restrict your use of live digital recording and file transfers, frustrating for our students as they are creating their own music on the PC and sequencer; but the software often tries to enforce a nonexistent copyright. As professional piano teachers, we are cognizant of the rules, and expect our students to buy professionally-published copies of their musical scores from the authorized publishers, and to purchase commercial audio CD recordings and cassettes, in support of the entire edifice of the creators and performers of music. It would be nice to have the freedom of choice we experienced in the past; but the movement toward a "digitally locked down world" seems inevitable. If you have some old "legacy" application that you need to use to record digital sound files, be aware that it MAY NOT work with the latest media players and OS's; so be careful of casual upgrades.
During the period of the 2003 summer convention by the Music Teachers' Association, while Ms. Roper was working in the booth of the publisher of her pedagogy books Just the Facts, the present author was happily installing his first little computer network at home: four machines, hooked by ethernet in the simplest possible manner through a Linksys router. We were still using a dialup Internet connection for a few hours during the day, and hadn't expected that our "constantly changing" dynamic IP address would attract any evil-minded computer crackers. WRONG!
One day after our network went in, while surfing websites we contracted the "W32/Pate.b" virus, which first infected the author's office XP Pro system and then propagated to the other three computers on the small network. A hacker-cracker had invaded our network and installed this "Trojan" program to control our computers! It took many hours of work after trying several different anti-virus programs (we found that Symantec's "VirusScan" worked best at eliminating it, but NOT by running it on any system that had the infection; rather, the program had to be run over the network from a clean machine.) In all our previous years of computer and Internet use, we had never contracted a single virus, being careful NOT to open unknown email attachments or to visit "dangerous" websites that might install "spyware". But the XP system was vulnerable at that particular time; and it only took a few hours for an "evil-doer" to find it and attack it.
We know better now; we have acquired an SMC hardware router/firewall that is more-or-less invulnerable; regularly run Gibson's Security Checks; and are even more vigilant than before about Windows updating and email safety (we use Eudora, not MS-Windows' Outlook Express, for greater control of email attachments.) So, our advice is that if you have a network, or even if you are simply using dialup Internet access on one computer that is also used for important work (such as your piano lab), you make certain to "contain" its vulnerabilities by keeping the OS updated. Use a firewall at all times! This can be dicey with old OS's and telephone modem connections, so if you MUST use the Internet, take precautions: don't take chances and just assume that "all will be well." Many of our colleagues have had their systems and email invaded, and have had a lot more trouble cleaning everything up than WE had (being computer-geek types who "never say die"!) And be sure to get at least one up-to-date anti-virus program, and KEEP it updated!
Just on the day we wrote this paragraph of the present article, in Regina's perusal of the Piano Pedagogy mailing list -- see the end of the article for more information -- she read the sad tale of a teacher whose entire music lab was stolen! Yes: everything, including not only the computer and monitor, but also the MIDI piano, CDs, and other audio gadgets. The equipment may all be replaced, but the worst part of this tragedy is that the teacher had all of her lab information -- studio and student records, assignments, bookkeeping, documents -- on the lab computer! It wasn't backed up, nor located on any other machine for redundancy.
This is a cautionary tale that should be taken to heart: be sure NOT to put your valuable, irreplaceable business documents on your lab computer. Or -- if you must do so -- keep them in a NON-SHARED folder that can't be seen by your network without an elaborate, hard-to-fake password; and be CERTAIN to back up the information on another computer and, preferably, alternative media (CD-ROM copies, floppies, etc.)
Weird Stuff has since moved its location to an industrial park at 384 West Caribbean Drive, Sunnyvale (an extension of Mathilda Avenue, just around the corner from the world-headquarters of Yahoo.) This helpful map can get you there; be sure to look at their interesting website for further information about some of the countless thousands of products you'll find. Not everything is always available; stock rotates. But you can obtain good monitors with lots of remaining life; complete computers or the parts to make them -- including just about every possible card for any need (except, drat it, old MIDI cards with UARTs, which we've never found there!) -- memory chips; hard drives and CD-ROM drives; printers; networking equipment: you name it! We are especially greatful to several of their fine employees (such as the printer specialist Terry) who have gone out of their way to find obscure things for us during an intense period of recent upgrading: so we offered to let our colleagues know about this nice store and its friendly, quite well-informed, employees. (They even have a Weird Cam webcam: maybe Regina can catch Stephen poking around the store, looking for ISA cards or empty CD cases...)
We also shop at some other computer surplus stores, notably Action Computers in Sunnyvale (for connectors, cables, adaptors, and many low-priced new accessories); and [DELETED] on Highway 101 in Santa Clara (which we used to plug here in this article because of deals on closeouts and newly-discontinued products; sadly now they are a mess, refusing to honor the posted prices, overcharging at the register, and failing to properly maintain their stock.) We also don't do much shopping at a famous local chain of electronics stores whose name rhymes with "sty" (as in pig-sty, which is what some of their facilities look like.) We have been disappointed by that company many times in the past, and now shop there ONLY in emergencies, and then usually just for things without moving or electrical parts (this pretty much leaves paper, magazines, and perhaps brand-new shrink wrapped software as the only things we'll risk buying from them.)
Long after I wrote and posted this article -- which may seem quaint since it deals with such "obsolete" technology -- one of our Saturday morning students came in with his little brother, who brought along a very nifty new laptop that he proudly demonstrated to me, which was running the then brand-new Microsoft Windows Vista operating system (I know, I know: trademarks apply, yada-yada.) I sat down and touched the mouse pad, but ==POOF!== the mouse cursor disappeared. I beat a hasty retreat, not wanting to do any further damage. Then the next week I mentioned this to the manager of a local technology store, who happens to be a very canny friend of mine. "Yes," he said sadly, "this happens to me, too: I hate Vista and wish I hadn't upgraded to it." I then did a lot of checking, and could not find one single person, anywhere, who was willing to express anything enthusiastic about Vista. As far as trying to install it yourself: well, it seems an almost preposterous idea. If you are something of a masochist, you may enjoy vicariously experiencing the agony of a Microsoft employee named Andy Pennell, who recounts an appalling story of trying to set it up on his own home machine. So, my advice to other piano instructors is to stick with the tried-and-true Win XP (which I rather like, and have almost no trouble with -- on good hardware.) As far as Linux is concerned: just where are you going to find any software relevant to piano pedagogy? It's nonexistent; and setting up and maintaining Linux (which I've tried) requires something odd or unique in your DNA, as far as I can tell.
Self-portrait of the author in his garage computer repair workshop,
pooped out after being up 'til 3:30 am struggling with an old PC.
• Click here for Pedagogy Article No. 1 No. 2, No. 3, No. 4, No. 5 or No. 6.
• Press BACK key to return, or click here for Roper Piano Studio Home Page.
Copyright (c) 1999-2008 Regina L. Roper - All Rights Reserved. All trademarks or copyrights are property of their respective copyright holders. Last modified: Wednesday 31 December 2008 at 8:20 pm.
Save All Your Studio Software With Care,