UltiMusE3

The Original

(Last MJK Release in 1991)

(Last MJK update in 09/16/2002, no "public" release)

UltiMusE III version 9.11.1A

by Michael J. Knudsen

UltiMusE3 for Coco 3 & OS9 Lv 2 by Michael Knudson. UltiMusE3 is by far one of the best music software ever written for the Color Computer. With it's sixteen voice MIDI output and multiple music staff type entry via mouse on a Hi-Res graphics screen, you could say it was the CocoMax of music software. The MIDI implementation was very well thought out and easy to use. Mr. Knudson, being a musician himself, created a unique environment for composing music using a variety of staff types including a percussion staff for drums. With programmable MIDI instrumentation, 16 tracks and a well written manual, you could push your MIDI instrument to it's limits. Mr. Knudson used a unique way of storing the MIDI data in memory utilizing the Get/Put buffers for storage. This allowed fast response and screen updates as well as the best MIDI timing routines on the Color Computer. Using OS9 level II allowed for the now familiar but then almost unheard of multi-tasking environment. I could load and play a 16 part song complete with drums and switch to another window and work on my song lyrics in a word processor while I listened to the music. Pull that off on a Commador 64!!! I also used UltiMusE3 for live performance as my complete back band to accompany my electric/acoustic guitars and vocals.

I used UltiMusE3 for about ten years or more and still use it today with my Coco emulators outputing to my PC's MIDI drivers via Vcc 1.4.3b w/Becker Port support and DriveWire4 MIDI. I still have a few of the .ume's around but most got transferred to my PC via a MIDI cable and are now in standard MIDI files (.mid) I hope to one day get them back to the Umuse format for the Coco. There was quite a few Umuse3 files uploaded to Delphi and now preserved on the net at RTSI and the Repository so there's plenty of music to listen to. We can always use more... so let's hear 'em!

And now downloading to a Coco 3 near you....

First New Release in Over 15 Years!

UltiMusE III version 10.11.4A

Now upgraded to

UltiMusE III version 10.11.4G

by Bill Pierce

Just in time for the 2013 Christmas holiday season, I am releasing the first "NEW" Ultimuse 3 release in 15 years!!!

The new UltiMusE 3 release no longer uses the external OS-9 commands "Tmode" and "PWD" which are now internally handled by Umuse3. No more "tmode version conflicts" or waiting for Umuse3 to "shell out" to tmode or pwd. The only external programs needed will be the UltiMusE3 modules themselves. I've also added a nice internal "bell" sound that sounds much better than the standard OS-9 "bell" sound.

I have also be added 2 new Umuse3 modules:

The first, "Um3W" which is the new DriveWire4 MIDI device/profile manager. With the new module, you can set your DW4 MIDI device and select your DW4 MIDI profile right from the UltiMusE3 MIDI menu! The Umuse3 interface automatically recognizes the presence of DriveWire4 and all DW4 configurations are saved to the default settings file. Each time you run UltiMusE3, it will configure DW4 MIDI to your user defaults. There may be more DW4 capabilities coming soon as well.

The 2nd module "Um3U" is the new Internet Updater function. This feature allows you to check the internet Umuse3 update site for new Umuse3 releases, download the updates, and install them.... right from the UltiMusE 3 menu on your Coco 3 !!!

All you have to do is to restart UliMusE 3 to run the new version. All program files are updated in one (maybe 2) clicks.

This feature uses DriveWire4's internet connection capabilities that allow the Coco to connect to FTP servers. Now you don't have to go to a website and download the latest version... Just click the menu item and UltiMusE 3 will update itself !! I have made a special version 10.11.4A that will reside on the update site just to test the downloader. No new features in this version, only the version numbers differ for testing.

All this of course requires you to have a DriveWire4 enabled 512k Coco 3 running NitrOS-9_dw.

Also an internet connection on your DW4 server for the updater.

UltiMuse III will still run on a non-DW4 system, but the DW4 features will be automatically disabled.

Of course without DW4, you will need a MIDI keyboard or sound module connected to the Coco as always.

With DW4, you have a built in MIDI sound module to play all your UltiMusE III favorites :-)

How do you use these new features you ask?

I am currently putting together a new UltiMusE III manual (in PDF format) for all the new features as well as organizing the old manual which Mike never updated from all his "addendums" that included almost 8 years of additions. I should have it up in a week or so.

In short, to use the new functions, click the MIDI menu (or hit "m") from the main screen and select "Vdw4device" (press "v") for the DW4 Device Manager or "Xdw4profile" (or press "x") for the DW4 Profile manager. To get to the "Updater" feature, just select the "Random" menu (or press "r") from the main screen and click "Update umuse3" (or press "u"). You will be prompted from there on how to update the program.

If you've already downloaded ver 10.11.3A and want to upgrade to ver 10.11.4A, you can do thi with the "updater" feature above. The updater will download the new files straight through to your Coco 3 while running Ultimuse 3. This feature utilizes DriveWire4 and the DW4 server must be connected to the internet. You can also download it direct with the link below.

Now where else in the Coco world can this be done but right here at The Barn Studios with Piersoft Software. I am adding this feature in every project I start. This will be a major feature in my upcoming "MShell" NitrOS-9 System Manager software suite as many features will utilize the internet feature.

Check the "MShell - The Ultimate OS-9 Manager" link in the left sidebar for news and updates as well as the "MShell" blog.

Here is a few screenshots of the new UltiMusE III features in action:

Using the DW4 Device Manager

Using the DW4 Profile Manager

Using the Updater feature

I have a few more enhancements planned, but those will probably not come about until after the first of next year (2014).

One of which is the expansion to 32 MIDI channels!!! Imagine that, a Coco 3 playing music in 32 voices!!

Also in the works is a "pause" and "continue" function that will be controlled by the unused joystick button. With a special momentary contact footswitch wired to the alternate joystick port, you will be able to pause and continue a score while in Play mode. This will bring interesting possibilities in using Umuse3 for live performance. There will also be a new score item for "pause". This item will pause the music at a certain point and wait for the alternate joystick button to continue.

Here is a list of just some of the "planned" upcoming features:

32 MIDI Parts per Score

New "Pause" and "Continue" functions

More Parts per Staff (to help faciliate the new parts)

New Clef types including an expanded percussion Clef

Full 128 note General MIDI percussion support

"Named" MIDI Events with "Load" and "Save" functions

New "+8va" and "-8ma" Score items for setting the part octaves

Ability to load and play Lyra files

and much more...

The new Ultimuse 3 release will run on a stock 512k Coco 3 running OS-9 (with KD modded grfdrv) or NitrOS-9.

To use with DW4 support as well as VCC 1.4.3b w/Becker Port support via DriveWire4,

NitrOS-9 w/DriveWire drivers must be used :-)

All this and more for UltiMuse3

Coco-Nut Forever

Bill P.

Here is the "History Of UltiMusE 3" from Mike Knudsen's old AOL Hometown site:

History of UltiMusE™

UltiMusE™ (The Ultimate Music Editor) dates back to 1986, with public introduction in 1988. The program is initimately bound with the Motorola 6809 microprocessor and later the 68000 (68K)family, and Microware's OS-9 operating systems. Hardware platforms were the Radio Shack Color Computer III (Coco3) and Multi-Media One (MM/1). This history will make more sense of the source code once it's released. There have been four families of UltiMusE:

• Coco3 OS-9 Shareware "UltiMusE (Umuse)", 256x192 graphics, begun 1985, released 3/1988
• Coco3 OS-9 vended "UltiMusE-III (Umuse3)", 640x192 graphics, Fall 1989
• MM/1 OS-9 68K version "UltiMusE-K (UmuseK)", 640x208 graphics, c. 1991
• PC LINUX X "UltiMusE-LX (UmuseLX), up to 800x600 graphics, 3/2000, released 3/2001

The Bottom Line (Eat Dessert First)

UltiMusE was born on 8-bit, 64K home computers (Coco's) with low-resolution graphics, at a time when the mouse and point-and-shoot menus were hardly known outside Xerox PARC and the MacIntosh user base. There were no GUI standards or widget libraries for menus, and Apple sued anyone who tried to market a GUI-based OS (like GEM).

Thus UltiMusE's first LINUX release doesn't have the look and feel of now-standard GUIs, even such antiques as Ghostview and Bitmap. Future releases will go to V classes or Athena 3D widget sets if popular acceptance makes this worthwhile.

But since UltiMusE was written in C for the UNIX-like OS-9 system, it was easy to port to LINUX except for the X Window interface. This was original K&R C, with no ANSI extensions like enumerated types and function protoypes, so my source code looks a bit quaint today, although gradually being modernized.

The Coco UltiMusE user group, which thrived from the late 1980s thru the early '90s, left hundreds of .ume score files on bulletin boards and still on ftp://RTSI.COM.

You Can't Outrun Motorola

The Motorola 6809 multiprocessor chip combined most of the features of the 6800 and 6502 with many signed arithmetic extensions and address indexing modes from the revolutionary DEC PDP-11 minicomputer. (The PDP-11 introduced the Stack, Bus, Carry Bit and other features we take for granted.)

The 6809 was the last and best of the 8-bit micros, including many 16-bit registers for arithmetic and addressing. With two Stack pointer registers it was ideal for Forth and the upcoming C high-level language, yet it remains a joy to program in assembler. Motorola's 16/32-bit 68000 series carried on much of the elegance and power of the 6809's architecture, and launched the Apple MacIntosh, Atari ST, and Amiga. The only popular home computer to use the 6809 was Tandy Radio Shack's Color Computer (Coco) series; the competing Apple, Atari and Commodore models made do with the 6502.

Nine Lives: Microware's OS-9™ Operating System

Microware™ is a small Iowa company (like Collins Radio) with a long history of software for microprocessor-based industrial and business controllers, dedicated terminals, and cable-TV set-top boxes. They began with a structured BASIC for the 6809, followed by a complete operating system, OS-9. Based loosely on UNIX, OS-9 was done over and done right, with modular structure and emphasis on reliability rather than hacker-proof security. It supported pre-emptive multi-tasking before Gates or Jobs could spell it.

I/O device managers and drivers can be loaded and linked into memory without touching the compact kernel. Bus addresses and other local details of device interfaces are adjusted by zapping a few bytes in tiny "device descriptor" modules, without affecting the driver code. Systems can be reconfigured with no compiler, assembler, or linker on site -- unlike UNIX and LINUX where you can't change your socks (let alone a sound card) without recompiling and linking the so-called kernel. (Recently LINUX has adapted loadable device drivers, but not descriptors, so drivers must still be recompiled.)

Every OS-9 memory module -- kernel, device handler, utility, or user application -- includes a 3-byte CRC check code. If "bit rot" occurs on the hard disk, the system will catch this at load time and refuse to run the module. If bits go bad while the module is in RAM, a simple utility will detect that. Viruses don't stand a chance.

In addition to normal UNIX features like pipes and I/O redirection, OS-9 supports program subroutine modules and data modules that reside in RAM and can be linked into any program as needed, like Windows .DLL files but many years earlier.

There have been three relevant versions of OS-9: Level 1 (OS9L1) for a 6809 with fixed 64K RAM; Level 2 (OS9L2) for a 6809 with dynamic memory mapping beyond 64K; and OS-9/68000 (OSK) for the 68000 family with a large flat address space. More recent editions support the PowerPC and Intel x86.

Shacking up with Coco -- The TRS Color Computer

Tandy Radio Shack liked to use the latest processors when innovating a home computer. The TRS-80 used the new Zilog Z80 instead of the old 8080 and 8085, and the Color Computer (1980) skipped the weary 6502 of the other color graphics boxes to advance to the 6809. The "Coco" was solid, affordable, and supported a hardware text screen plus several graphics modes. The small 32x16 text screen finally killed off the Coco for serious spreadsheets and word smithing, and the 256x192 graphics wasn't the best either, but the ROM BASIC by Microsoft supported most high-level graphics operations without the need for machine coding. Nevertheless it was a delight to program in assembler. It had the only built-in D/A converter until the MacIntosh, and could synthesize 6-part music in software. Later, Tandy contracted Microware to adapt OS-9 L1 to the Coco, including C and Pascal, and adding graphics functions.

The Color Computer III (Coco3) was a major improvement, with 512K RAM mapped in 8K blocks, 640x192 graphics, and a full 80x24 hardware text screen. Tandy and Microware ported OS9L2 with a fine graphics windowing system. At $199, it was not only the most architecturally advanced 8-bit computer, with by far the most advanced OS, but the cheapest, and almost fully compatible with its older sisters. In some ways it approached the 68000-based Amiga and Atari ST. Under OS-9's flexible device driver and descriptor system, third-party vendors supplied hard disks and other advanced peripherals, and recently SCSI and IDE interfaces. Tandy withdrew the Coco in the early 1990s, but hobbyists continue to develop "impossible" hardware and software for it.

The Multi-Media One (MM/1) was a small 68000-based home computer running OSK in (usually) 3M of RAM. Actually it used the Philips 68070 integrated processor and Philips VSC graphics chips developed for CDi. Vertical resolution was over 400 lines, but only with the flickering interlace mode well-known to Amigoids. It included a SCSI hard drive, stereo A/D and D/A conversion (quite rare at the time), and an optional MIDI interface (heretofore confined to the Atari ST). Paul Ward, the entrepreneur who marketed it (Tandy was never involved) bellied up after at most 200 units, sold to Coco OS-9 devotees like myself. Its OSK with bundled C, structured BASIC, and Emacs was a powerful development tool.

Original UltiMusE Versions

Shareware Trial: The first shareware version was started on the Coco1 but transferred to the Coco3 with 64K of RAM total for program, graphics images, and I/O buffers. The user got what was left for a score file limited to 1500 notes and other score objects. This was released as shareware to gauge the Coco Community's interest in musical usage of the new MIDI standard. Donations and moral support poured in, and some incredible musical arrangements were crammed into the 1500 notes.

The mouse and 256x192 monochrome graphics screen (a Coco1 legacy) were used only for editing notes on the Score Screen. All the menus were 32x16 character hardware text-screen listings to remind the user what keys to hit for the commands (no clicking). Even Setup/Layout was strictly textual -- the Prompts are a living fossil of that era. Thus the "keyboard shortcuts" were there long before the mouse!

Commercial Coco3: The first commercial release of Umuse3 ($54.95 with free upgrades) featured much better 640x192 graphics with user-selectable colors, and the new graphical Layout screen much like today's (when I dropped the text-driven Layout Prompts, users clamored to have them back)! Scores space went up to nearly 3000 objects.

The Coco3 was a major advance over the Cocos 1 and 2, with 512K RAM and memory mapping hardware (eight blocks of 8K each, just like the PDP-11/34) to allow the new OS-9 Level2 (OS9L2) and each individual process to have up to 64K RAM to itself, and "map" different 8K RAM blocks in and out of that space. Umuse3 was actually a pair of processes: a main "Bill, the music conductor" program pipelined into a separate "Fran, the musical draftswoman" graphics display process. Between them this couple had 128K RAM, allowing for the fancy new graphics. Most source files today still have names beginning with 'B' or 'F', reflecting their original position in the pipeline. (A more famous couple is immortalized in the text screen drivers, where the pat(char*) function calls vanna(char) to put letters on the screen.)

Soon after I developed virtual memory for the score data, allowing up to 32,767 objects in up to 32 pages, though the 6809's address space was still 64K. This was totally transparent to the user, and since all pages resided in the 512K RAM, very fast.

As more features were added, I used another 8K block to map in program subroutine modules from separate disk files, thus extending virtual memory to program as well as data. The most recent version comprises Umuse3, Fran, and nine 8K modules. Today these modules would be called .DLL, but OS-9 supported these back when Bill Gates was still debugging QBasic.

The MM/1 Version: I ported UltiMusE to the MM/1 as UltiMusE-K (UmuseK). After this, all new features were developed first on the free-range MM/1 and then back ported to the Coco's confines. While liberated from the bonds of 64K RAM spaces and chopped-up program modules, the old pipeline architecture still influenced the programming, and is still obvious in the LINUX source code today, mostly in the arms-length separation of the menu graphics from the program. Graphics resolution was only slightly increased, to avoid flicker.

Documentation

The first commercial version (Coco3, 1989) included a 50-page manual, prepared on Dynastar and Dynaform, with a cross-reference index to every topic. As more features were added yearly, update notices were included on disk, but the printed manual was not changed. To document this LINUX release, I merged all the update bulletins into the manual chapters. HTML hyper links now substitute for the cross-index and are quicker to use.

Great Gains in Linux X, but What's Been Lost?

The OS-9 versions all played music by doing their own timing (using system sleep() calls) and sending MIDI bytes to the serial interface exactly when the synthesizer on the cable was to play them (called "UART Mode" on PC sound cards). While this play timing put a load on UME, it permitted real-time controls. You could hold down a key to double or half the tempo, or hit another key to stop the playing and move the score viewpoint to that spot. Other processes barely noticed the load, multitasking during the sleep()s.

LINUX sleep() has a limited timing resolution 10 ms, and in any event sending MIDI bytes to a sound card is a black art. So the current version just writes a temporary .mid file, then forks off a user-supplied utility (like playmidi) to play it. There can be no control over it, except you can hit ENTER and kill() the player process. We do "air play" along with the player, using sleep() timings to dead-reckon where the play is at any given moment, so we can update the score display to foloow the playing, and go to the stopping point in the score. Maybe we will even learn to real-time control the sound card.

OS-9L2's graphics support could monitor the mouse, position the cursor, and send interrupts much like X Events when mouse buttons were pressed. But their support didn't work with my graphics schemes, so I took care of all these myself. This let me implement "Magnetic Cursor Snap" whereby UME responded to each mouse movement on the Score Screen (without a button pressed) by checking to see if the cursor was close to any clickable score object. If so, UME altered the cursor coordinates to snap the cursor over to the object that would be selected if the user were to press the button. X Windows does not allow anyone between the mouse and its cursor. And its enforced arms-length relation with the graphics images prevents the UME user from watching score screens being "squeezed" vertically before going to the printer.

Back to My Home Page

© 2001, 2003 Michael J. Knudsen

KnudsenMJ@AOL.com

(Info now all invalid)