Sound Chaser

The Sound Chaser Music Player/Editor series for OS9/NitrOS9

Thank you all...

First: I would like to thank everyone on the MaltedMedia email list for all their help and for answering my sometimes boring questions on OS-9 and C programming. I would also like to thank Michael Knudsen and Lester Hands as without their help (and their sources) this software would have never come to be. Michael's "Ultimuse 3" and "Ubox3" and Lester's "Lyra", "Musica", and "Lyraplay" sources were the very foundation in which the players were built from. Without these sources, I doubt I would've gotten this far.

I wouold also like to offer a special thanks to Mr Robert Gault. Mr Gault has put up with my endless questions and "problems" with Os-9, RSDOS, HDBDOS, and RGBDOS. He was also a great help in working with the "Lyra" sources as he had worked with this code as well. In fact, Mr Gault was hired by Lester Hands back in the late 80s to do modifications to Lyra so it could run on RGBDOS hard drives and acess the 255 disk RSDOS partition. He was also a great help in getting the DriveWire Midi functioning properly as he had already modified Lyra for DW Midi compatability. Robert Gault is probably one of the finest M/L coders in the Coco Community.

Thank you Mr. Gault.

Prelude:

Around 1985-86, I start working with MIDI using the Tandy Color Computer 2 and a program called Lyra. Eventually I upgraded to a Color Computer 3 and OS9 Level II which allowed me to use Michael J. Knudson's amazing UltiMusE III. I used this software extensively for about 10 years before migrating to IBM PC clones and multitudes of MIDI and Audio software and hardware.

In December of 2011, Mr. Knudson offered me his old Color Computer system and all the old software, including his source code to UltiMusE III. I was estatic to say the least. Not only did I have a chance to work once again on the machine I started out on, but now I had the source code to my favorite software.

Originally, all I wanted to do with this software was to finish a Lyra-to-Umuse3 converter I had started years ago, and to add a couple of features that I felt should have been in the software. The more I thought about it, the more I realized that I had the oportunity to bring UltiMusE III into the new millenium. I could add some of the features (maybe) that I have grown used to on the modern PC and the big DAW (Digital Audio Workstation) software that I currently use. Upon examining the source to Ultimuse, I discovered two things:

1. It was coded in "C" and I've never programed in that language.

and

2. There were over 125 different source files that compiled into the 13 programs that made up the UltiMusE III package. It was HUGE!!

One thing was clear.. I needed to learn "C" if I was to do anything.

Not to be intimidated, I decided that I would first try to do something with UBox3, the jukebox player program for UltiMuse as it was much smaller and maybe I could start my understanding of "C" as well as Mike's programming style.

This is (hopefully) the documentation of that venture into "C" programming and Michael J. Knudson's UBox3 Jukebox player for UltiMusE III. And eventually… UltiMusE III itself.

Just a note:

By the way, most of the programming is being done on the VCC Coco 3 emulator. This allows for a lot of speed in programming as disk access is instantanious, especially if you overclock the CPU and the drives. I also use Roger Taylors “Rainbow IDE” but only for viewing program listings. If Rainbow had a “C” compiler, I would probably use it exclusively, but alas… The main reason I’m not using the real Coco 3 for coding and compiling is speed. If you’ve ever compiled a large “C” program with multiple sources, you probably know what I mean. Large programs can take forever on the Coco. A good example is Ubox3. On the Coco, it takes about 15-20 minutes to compile the 13 files that make up the program. On the VCC emulator with everything overclocked, it takes only about 30 seconds. This allows me to compile, bug check, and run in only a minute or so. I will always run the files on my real Coco to make sure it runs well and since VCC has no MIDI implimentation, I will only be able to check the MIDI output on the Coco 3. I currently use a Coco 3 with a Disto 1 Meg memory upgrade, Eagle AT keyboard interface, Multipak, Glenside MIDI interface and other than intitial boot-up (3.5 floppy). I utilize Aaron Wolfe’s “DriveWire 4” for disk access. This gives me up to 4-120 meg HDs online and all the sources, cmds, and references I need. It also makes it almost instantanious to switch the drives back and forth between the Coco and VCC. Programming on the Coco has never been so easy!!

30. Why Drive A Volkswagon When You Can Drive A Caddy? (09/20/2013)

Ok, it's done. I finally made the decision. All work on HRSView, DW4Man, Sound Chaser, BootMajik, and a few others I haven't even mentioned yet, has come to a sqeaking HALT. There will be no more work on these programs until I finalize a new graphics user interface (GUI). I am tired of CGFX breaking everything I try to do. I have decided to do exactly what I've wanted to do since the very beginning of all these projects. That is to use the sources of Ultimuse 3 as a templet to create a general purpose GUI that incorporates the mouse, "fragged" subroutines, forked & piped graphics and file managers, and virtual memory data storage. In Mike Knudsen's 9 or 10 year stretch of developement for Ultimuse 3, he had worked out almost every known bug. To avoid the various bugs and quirks of the OS-9 sysem, he wrote most of his own text and graphics handlers. The CGFX library is never used in his sources. The only C library used was Carl Krieder's "klib.l". In using Ultimuse 3 for almost 10 years myself, I watched it grow from a small 2 or 3 files package to the final 13 or 14 file package that it became. I've used many graphics oriented, mouse controled programs for OS-9 and RSDOS and I can truthfully say that Ultimuse 3 has the smoothest graphics scrolls, the fastest, most accurate mouse control, and the most intuitive menu system of any Color Computer program I've ever run, bar none. This is why I've decided to use these sources as a templet for my new GUI. Why reinvent the wheel when the wheel already has radial tires, hydraulic suspension, power steering, power brakes and air-conditioning?

The difficult part of this project is going to be to remove all the Midi playing and score editing code to get the sources down to a compilable version of just a bare menu system with all it's functions still intact. There is a lote of C code contained in the 125+ files that make up the Ultimuse 3 sources. It will not be an easy task. I will be leaving all the mouse, text, menu, dialog and disk i/o functions as with a little modification, they will fit my needs nicely. I will also leave the virtual memory routines intact as with a few changes to the data structure and indexing functions, I can use these roitines to maintain the tons of data arrys that are used in my various projects. Ultimuse 3 also has a unique feature that I've never seen in any other Color Computer OS-9 product before... The main program code stays below a certain size as to leave at least 8k of memory free above the program. This main program handles all mouse and keyboard reads and activates any calls to any menus or functions. When these menus or functions are needed, the main then loads a sub-module into the 8k area and links it with a unique pointer sytem that allows these sub-modules to not only call functions from the main program, but to also call functions and subrouitnes from other (not yet linked or loaded) sub-modules. The main program will then unlink the sub-module, load in the new sub-module, execute the needed function, then unlink the sub-module, load the old sub-module back into the 8k memory and resume where it left off. The amazing thing is that not once does Mike use illegal code to acomplish this. It's all done using standard MW OS-9 C code and standard OS-9 system calls. The sub-modules are all restricted to be under 8k in size (of course) and a special version of "cstart.r" was created that uses the same "global" variables already initialized in the main program. In this way they share the same variable space. When each sub-module is called the first time, the main checks to see if it is in memory already, if not it does an "NMLoad" that loads the module into the system memory therefore leaving the main's 64k workspace intact. Then the main "links" the module into the empty 8k space and executes the needed function. The main keeps tabs on which sub-modules have been loaded into memory and in what order they were loaded and used. When the next sub-module is called, the old sub-module is unlinked, but not unloaded. This double linking system allows the module to hang around in system memory so it's doesn't have to be re-loaded from disk when called again. As each module is used, they are loaded and linked in this fashion which speeds up the whole process once the modules are in memory. The nice thing about this system of using sub-modules is it's not an experiment. It's a proven programming technique that been in use with Ultimuse 3 since 1989 when Mike added the feature. It was then tweaked and perfected for the next 9 or so years until it was flawless. The other thing that Ultimuse 3 does is it runs in 2 independent 64k workspaces. The main program accepts all mouse and keyboard input and decides what functions are needed. But when something is output to the screen, Mike used a piping system to pipe the text and graphics commands to a second process called "Fran". When the main is first started, Fran is forked into a 2nd 64k workspace and proceeds to create the screen. Once the screen is initialized, it returns to the main and basically sleeps till it's needed again. When the main or any sub-module needs something displayed, whether it's graphics or text, the commands are "piped" to Fran and Fran does the display work in the background. While Fran is working, the main continues so that program flow does not stop. To see this in action all you have to do is to run Ultimuse 3 and do a scroll through a music score. While the screen is redrawing, hit a few known menu commands in succession. When the screen finishes with the redraw, the menus will open and perform what ever function you typed in. Keep in mind that these menu drawing functions pipe right back to Fran again to display the menus. It's an amazing system to watch in operation if you've never run Ultimuse 3 before. The whole time all this is going on, the mouse cursor is sitting there waiting for you to make some editing move or menu choice. The only time you really need the keyboard is when entering a filename or description of some sort. Even with that, all menus and functions are still callable with a simple keystroke.

All in all, the ease of programming with using the Ultimuse 3 sources as a templet for my GUI is going to make for an intersting OS-9 project. I have been studying these sources for almost 3 years now and have become very comfortable with the program flow and Mike's C coding style. The first time I ever saw this code, it was like trying to read Japanese. But over time I began to see why Mike did certain things the way he did as most things were avoiding OS-9's "quirks". Mike was a professional C programmer with 2 college degrees, a PHD and a Master's in programming from 2 different Universities. He then worked and retired from Bell Labs as a C programmer. So his knowledge in C coding was not average but extreme. After programming in C on a Unix mainframe all day then coming home to work on Ultimuse 3 in OS-9, it was like working on a high tech drag racing engine all day to come home and procede to "soup up" the family car. OS-9 was just a "mini" version of Unix to him.

So... until I get the Ultimuse 3 code converted to my GUI and can start working in all my previous code from the other projects, there will be no updates to the program packkages or the blogs for "DW4Man", "Sound Chaser", "HRSView", "BootMajik" or "Reclaiming OS-9 For The Coco". Yes, "Reclaiming OS-9 For The Coco" this has become part of this now greatly expanded project. Just wait till you see what I have in store for that project. It's going to be a Coco "one of a kind" feature. Already I have close to 20 different sub-modules started or in planning for this new "Complete OS-9/NitrOS-9 GUI, System Management, and Utility Program Suite". So far, the only working title for the system is "MShell" or "Multi-Management-Shell". This may change as things progress, but for now, "MShell" seems to stick.

Besides... It's easy to type in to a command line :-)

29. Still chasing the sound... (06/02/2013)

In the making of several other projects, DW4Man in particular, I have found better ways to do some things from within this user interface. I've also found ways to conserve memory and optimise routines. So in this point in the Sound Chaser project I am going to end this source set. I will be starting a new source set with better, faster code and hopefully a better interface. So basically I'm going to do a complete rewrite of Sound Chaser. The version currently available seems fairly stable so I will leave it up for Coco/OS-9 users to enjoy. As soon as I get the re-make ready, I will be making the first"official" full blown release of Sound Chaser. This will not be a Beta version. In the process of the rewrite, I hope to get a couple of more players added as I have 2 or 3 in progress and they will be worked on as well. So if you hang in there, Sound Chaser will get a whole new look and feel and maybe even mouse support. This has become a priority with the project now.The one thing I have done is to add the control panel to set the keyboard delays and screen colors. Now you can make your Sound Chaser pink and green if you want. Your custom screen attributes are saved with the defaults so they will persist with each running of Sound Chaser. This is all leading up to the new and improved Sound Chaser....

So wait for it.... it's coming...

28. Well, well... there it is... (04/04/2013)

I had already submitted Sound Chaser for review for the Coco Coding Contest with it's shiney new PDF manual and was later, doing some work on DW4Man. Dw4Man allows Sound Chaser to be launched from it's main manu and I just happen to be checking this feature when I noticed something while playing a Lyra file. I had sent the contest reviewer a version of SC with the Lyra player in debug mode. I had inserted a bunch of "print" statements in the code that print various bits of info to the screen as a file played. I immidiately recompiled it with the debug mode off and sent a copy to the reviewer, Brian Blake. After I did this, I turned debug mode back on because I had seen something that didn't look right with the data. There were several things in the data that didn't match... the whole problem with the timing was scrolling right before my eyes. I spent about 2 hours going through things till I found the cause. There were several unsigned integers being added to signed integers and it was screwing up the delay timer causing "two's compliment" math to be caculated on what was supposed to be a straight add (unsigned). After correcting this, then fixing the Tempo loops from where I had really messed them up trying to fix it before.... I played a file...

IT WORKED CORRECTLY!!!!

I couldn't believe it.. The tempo was slightly off, but it wasn't doubling and tripling in speed with the length of the notes like it was before. I made a few adjustments to the tempo and compared it to the same file playing in the original Lyra running in the XRoar emulator. They were almost identical. Lyra was fixed! Now I can spend my Sound Chaser programming time on getting Orchestra 90 and Bells&Whistles 2 both running. Lyra had been driving me crazy. I had even sent the source to Lester Hands and he couldn't figure out what was wrong. The timing loop had been taken straight from a Lyra player he had attempted to write for OS-9 back in the 80s. It didn't work right in that program either.

Maybe tonight I won't have dreams of Lyra files and C code....

27. Moving the Mule to the stable... (01/22/2013)

Ok, the latest beta release of Sound Chaser is now available on the link (above right).I think I finally have the menu system as stable as I can get it. There's still a couple of error trapping things I'd like to do, but, for the most part, it's stable. Here's a list of the things it will now support/do:

Sound Chaser 1.3.0

Lists and scrolls up to !! 500 !! music files in 6 formats:

Ultimuse 3

Lyra

Musica 1-2

Bells & Whistles II

Orchestra 90cc

Standard Midi

Of the above 6, only 4 currently have players.

Ultimuse 3

Lyra

Musica 1-2

Standard Midi (with limited memory)

Orchestra 90cc and Bells & Whistles II are still under construction

All files in the list can be searched for any phrase in any position in the music title.

A "Play List" can be created to play up to 500 files in the order you choose.

MIDI:

Speech Systems & Glenside MIDI Pak supported

Serial (bitbanger) MIDI supported

Drivewire 4 is fully supported. You can even select your DW4 driver

Sound/Wavetable Synthesis:

Coco 6-bit DAC Sound supported

Orchestra 90 pak (stereo) supported

Speech/Sound Pak supported (untested)

Each player has it's own "Now Playing..." dialog box giving available info on the song being played

File formats can be selected/deselected so that you see only the music formats you want to play.

All music players can be exited with the <BREAK>/<ESC> key

Saving of default parameters now supported.

This saves all driver info and current music directory so that the next time you run Sound Chaser, these parameters will be loaded.

Change your default monitor settings (RGB, Composite, Monochrome)

I'm currently working on setting the right Composite colors as I use a CM-8 RGB

I hope to have color selector soon to set your own colors

Exiting Sound Chaser will restore your original screen settings. No leaving you in an "odd window"

Run OS9 shell cmds

Sound Chaser can also be launched from the DW4Man main menu

Releases all used memory properly on exit

26. Searching everywhere... (12/28/2012)

I decided to take a short break from my Drivewire manager project and work on Sound Chaser a bit. The results are that I now have the search engine fully working!! You can now search through a database of over !! 500 !! songs using any short string of characters. Let's say you know you have a song with "rock" in the title but can't remember the rest of the title. just type "rock" in the search engine and it will locate all instances of the phrase and ask if it is the right one. If it's not the right song, the search engine will continue searching. If it is the right song, the search engine repositions the database cursor to that song ready for playing/selecting. I've also done some refining to the "Selection" window and worked out a couple of bugs that have been lingering there.

I'm still working on the "Lyra" player as well as the "Orchestra 90" player. The problem with the Lyra player is the timer is based on delay loops. With OS-9 doing it's regular interrupts it causes the timer to get out of sync with the player. I may try creating a timer using the VIRQ as that would put the timer itself on the interrupt and it should be stable. I've just never messed with the IRQ and VIRQ and don't know much about them. I've been doing some reading on it in the manuals and it seems to be fairly easy to set up a VIRQ. I just don't know if it would be stable enough for a Midi clock. As for Orchestra 90, I have several ideas. I just haven't had the time to test out some theories of operation to see if they work with the Orchestra 90 file format. I also have a couple of tweeks I would like to make to the Musica player even though I have it pretty much stable now. The one thing I have done for the Musica player was to make the player "stop" whan <BREAK> was pressed. This was something several people had suggested but wave table players block interrupts while playing so that makes it a little harder. I had to cheat a little and do a "direct" keyboard scann and exit if a key had been pressed. I may eventually add the same "pause" feature that the Ultimuse3 player has now that I have the ability to stop the song.

Well, it's back to the Drivewire manager for now, I have a lot of work to do on that project to have it ready for the Coco Coding Contest.

25. Drivewire Rulez!!... (12/07/2012)

Wow!, It's been a while since I did an update. Well I finally took a break and worked on some other projects. One of which is a DriveWire 4 (DW) manager for OS-9 Level 2. I've been needing to work on this for a while and finally got it started. The best part is that I finally got the internal DW command parser working and was able to put it in Sound Chaser!. Now you no longer have to have the "dw" command in your CMDS dir. Sound Chaser handles the DW commands internally. I think that was the last of the external dependancies in Sound Chaser. I now have the code for "pwd", "tmode" and "dw". The only external programs used now are the individual players for the different music formats. This cuts out a lot of disk activity and will speed the program up in various routines that were having to load these external commands to complete their purpose. I consider this a major breakthrough as almost all programs I see call these commands externally. These routines have been written as "standalone" subs for "C" programming and I will eventually post them on my "Utilities" page after I test run them for awhile to make sure I have all the bugs worked out. I may even start a "C Programming for OS-9 & The Color Computer 3". That would make for an interesting page as I have learned a lot about "C" in the writing of this software. I started this with almost no "C" programming experience. I now feel comfortable converting other programming languages to "C", like "Basic09" and "ASM". I've also upped the tempo control slightly in the Musica player as it seemed to be dragging a bit. If anyone thinks it's still not right, let me know and I'll adjust it more. I'll be updating the Beta version link with the new Sound Chaser Beta so that everyone can get the latest incarnation. I still need to work on the search engine and the Lyra player timing. It will come in time...

24. Settling for less... (09/29/2012)

For now, I've had to settle for less and do a beta release of Sound Chaser with a bugged Lyra player, a midi player that has memory problems, and a search engine that doesn't work. But I want everyone to see the work that HAS been done, so I'm doing the release anyway. Just remember, You were warned! There are a lot of functions working now and bugs fixed. I hope to get the Lyra and SMF problems fixed soon so I can finally start working on the Orchestra90 and Bells & Whistles players. Till then.... Enjoy!

23. Setting the clock... (09/17/2012)

Well, it looks like I may have to drop back to the assembly version of Lyra and work from there. The clock in LyraPlay is all messed up. I tried several things to fix it, but there's a huge difference in the way Lyra works the clock and LyraPlay's clock. I looked through the Umuse code to see how hard it would be to impliment the Umuse clock, but there's just too much involved. I may still extract that clock eventually as it's more stable than a clock based on delays. But for now, the Lyra source will work (I hope). There's just a lot of conversion from RSDOS asm, to OS-9 RMA. Since I had started this already, it's partially done anyway. But there's still a lot to do. I'll probably spend most of this week recording some acoustic guitar music. I've been getting the bug to lay down some tracks and my fingers have been itching. I may even use Ultimuse to lay down some backup music. Basic drums and bass... maybe a little piano... some Hammond organ... you never know when I get started.

22. Music To My Ears... (09/15/2012)

Man, what a night/morning.... I got home from my daughter's last night and went out to the studio to set up my PC to transfer the files to my Coco and test the Lyra player.... and my PC wouldn't boot!! I tried for three hours and couldn't even get a light to come on. I finally give up and went to bed. I got up this morning and went out to the studio, plugged the PC in and a big "POP" can from the area of the power supply. I did some searching online (on my wife's PC) and the best buy I could find for a power supply was at Best Buy. I went to Best Buy, got the supply and came home. It took about 20 minutes to change the supplies, then the PC booted fine. Whew.... one of those days.

Pretty soon, I got back to testing the Lyra player, and after working out a few bugs with the parameter parser, it played music!!. The timing clock problem is still there though. It seems to bog at longer note intervals and speeds up at shorter ones. This leads me to believe the clock counter system that Lester is using in the original player is not equally tempered and the system interrupts make the longer cycles, even longer. I could just block the interrupts and see if that fixes it. This would tell me I have to use the OS9 clock as it's interrupt based and will keep fairly good time as long as there's no disk access or interrupt blocks. I'm think I'm going to test that next. From the way the code looks, there is no "running" clock system. Just a set of timed delays between note block processes. I may be able to block interrupts only on the delay routines and see if that helps. More tests to be made if I'm going to make a release by Monday. The really big problem is that I have to run sound for a band at a benifit tomorrow evening so I'll have to do most of what I want to do tonight. Looks like a late night again....

21. One more for the road... (09/13/2012)

Whew.... That's my general reaction to today's accomplishments. I think I finally have Lyra files playing in Sound Chaser!!

I worked late into the night last night then was at it again early this morning and here it is after 11pm and I now think I have it. There's only one problem... I can't test the player! I came to my daughter's last weekend to stay all week and my Coco is 2 hours drive away from here. VCC will not playback Midi, so I have no way to see if the files are actually playing. What I did do, was to activate VCC's text capture feature and send the Midi data to the bitbanger. I did this with 2 files, one in Ultimuse format and one in Lyra. Both files were the same song. Not exactly the same, but close enough to tell the difference in data in the two files were minimal. I will have to wait till this weekend when I get home to run the true test on a Coco. I still have to look into the timing problem with the Lyra player, but that can wait for now. I'm going to take a break from the Lyra format to work on a few other things that I've been planning for Sound Chaser.

One of the things is a search feature. With access to up to 300 songs in a directory, finding a particular song could become quite a task. Esspecially if you don't know the full name of the song... maybe just one word. Scrolling through 300 songs is rough on the eyes. This is why I would like to add "Search", with wildcard functionallity to make searches easier. I will use the OS9 standard xxx* format for the wildcards. This makes the learning curve much easier. Also, with the growing number of file formats, it's time to start adding some editable parameters to the various formats. Things like changing instruments, midi filters, channel changes, ect. Some of these will be easily adapted into the players as they are called from Sound Chaser in a command line style fork. This meaning I pass a few parameters along with the filename of the song. Things like which Midi driver or sound output to use. It doesn't take much to add more items. Most of these types of routines were in the original editors, so the functionallity is built in... sort of... when I didn't remove it when rewriting it...

Sound Chaser is slowly growing into a full blown "Multi-Format Music Player for OS-9".

P.S. If the Lyra player is indeed working, there will possibly be another "Beta" release this Monday!

20. You Gotta Love Email... (09/12/2012)

I opened my email yesterday modrning at about 3:am as I had been up late working on the Lyra player and got a nice suprise. Lester Hands had sent me a zips of about 6 different source packages for OS9 programs. One of the packages was the OS9 LyraPlay juke box. This was the code I needed. LyraPlay is a combo menu/cmd line program in an 80 column text window that allows you to select Lyra files from a scrollable list or play a single song from the command line. The thing that got me excited was... it was in "C"! Now I have a fairly decent player that works that will take only a small amount of modification to make my Lyra player for Sound Chaser. Since it was so late... or early rather, I decided to go to bed and get some rest so I would have a clear head when I start going through the code. Later on yesterday, I was up and at it. After going through the sources, I've found most of what I need. I had noticed recently while using the LyraPlay program, that there is some tempo issues on certain songs. It seems that some of my song collection plays at a really slow speed while others play at the right tempo. These same songs play correctly in the RSDOS version of Lyra. I need to compare the 2 timing loops and see whare the difference is and try to correct this. I may even try to pull the clock routines from the umuse player and find a way to make it work in the Lyra player as umuse uses the OS9 system clock which is always running and bases it's timing routines on the current clock time. This "C" code, along with the routines I have already developed with the RMA assembler, should be ready for some beta testing in a couple of days. With the Lyra player, I will now have three completed players for the Sound Chaser package. I will have Ultimuse 3, Lyra, and Musica. This leaves Orchestra 90, Standard Midi, Bells & Whistles 2 and a Sound player. Of these players, I already have a good base program for 3 of them.

But for now... Let's get Lyra playing.

19. Back in the saddle.... (09/10/2012)

Well, I'm back at it again. I've spent the last week or so pouring over the Lyra source code looking for all the routines I need to implement a Lyra player in Sound Chaser. Since the code is RSDOS assembly, that's not an easy task. In RSDOS asm, there are no "structured" variable spaces so programmers have a habit of "need a variable? stick it here" type of coding. Also, since RSDOS provides no easy way to deal with graphics in assembly, all the code for loading and playing a file is mixed with the code for displaying the music on the screen. Since my player will be Cmd line only, there is no need for all the graphics code. Wading through what is needed and what is not takes time. OS-9 made life easy with system calls for about any function you need. I applaud the old guys from MicroWare. I just wish Microsoft would have been paying attention and designed Windows in a similar fashion, life in computing would be much easier now.

For now, I decided to do the Lyra player in assembler as transferring the RSDOS asm code will be a little easier. Once I get the code working, I may go through it and try converting it to "C" as most of the hard work of arranging all those variables is done. I have succeeded in setting up my player to actually load the Lyra file in memory by just allocating variable space for it in the vsect. I know eventually, I will attempt to use the virtual memory system from Ultimuse and create a VM system that will be re-usable for any project. But... that's a project for another day. The lyra file loads with no problems and I'm able to create my title screen complete with the imbedded song title text and include any other info from the file I want. I'm now going through the play routines and that's where things get tricky. In some of the play subs, Mr. Hands uses all the registers avialable on the Coco to manipulate the data fast. With OS-9 assembly, using the "U" register for anything but the stack is a definate "no-no". Trying to find a way around use of the "U" reg in some routines is difficult as there's no other regs to substitute and references to the data area are in constant use. With no "U" reg, there's no way to access this area correctly. I've had to pull some neat little tricks by creating new variables to store values in temporarally and index from them with as little code as possible. There's still a lot of work to be done in the play routines because of this one factor. Ahh well... who said it would be easy?

18. Secret Codes... (09/04/2012)

I feel Like Bond... James Bond.... As I peruse the code to both Lyra and Musica, both by Lester Hands, I feel like some secret agent who has gotten a hold of secret documents. I've had a desire for these sources since the 80s . All their secrets have been revealed. Now I can impliment some of the things in Musica that my "PlayMus2" player for "Sound Chaser" skips over. It's all there, the voice changes, the channel panning for stereo play... And Lyra... it will take me a while on this one, as Lyra uses a lot of ROM calls and jumps to other routines, all together 5 seperate asm files. Sorting through the Lyra code to find all the components of the Play routine and converting them to OS9 "C" and "ASM" will take some work. But I will have a Lyra player that is stable with proper timing.

Earlier this week, I worked a bit on the SC code and corrected a couple of bugs that had been bothering me. I still have one that I just can not fugure out. That's my Load & Save default configuration routines. I can get them to work, but when I save a config file, the file size is 0. I even directly copied another config routine, directly from another program source and it does the same thing. But yet, if I run the other program, the config save works flawlessly. It has me pulling my hair out... and at my age, there's not much to pull. All the code does, is to write a config file consisting of the various variables that have been set within Sound Chaser, then on next startup, reads these variables from disk and sets the new session the same as the last. Simple enough? I guess not. There is something that I am missing and can't figure out what it is. The routine creates the file, appears to write to it. Then when I check the file, it has a file size of 0 and should be at least 14 bytes. The file attributes are being set properly... I'll figure it out somewhow.

17. Google IS Your Friend.. (08/07/2012)

Just out of curiosity, I did a search for Lester Hands on Google. Guess what? I found him!! I sent him an e-mail requesting the source to Lyra to be released to Public Domain and he has given permission. Now I'll have the source code so that I can finish the Lyra player for Sound Chaser! Lester has promised to look for all the old disks for Lyra and Musica sources and send them to me. I am anticipating recieving the package.This may even prompt an effort to convert Lyra to OS9 and move it to Nitro. This has been a dream for many years. But... for now it'll be the Lyra player for Sound Chaser. The source code will give me all the loading and timing routines that I am having trouble with. I hope to be posting good news on the Lyra player soon.. But as I stated above, I'm going to take a break as I've even been dreaming in "C" code lately and that's not a good sign.

16. A Much Needed Break... (08/04/2012)

The past few weeks I have been obsessed with this program! After completing a few more features, which include the File Selection routines, a rather sketchy Lyra player and an even sketchier Standard Midi player, and a preferrences file routine, I think I'm going to take a break for a couple of weeks. I have been ignoring work here in the studio as I have a concert recording of a woodwind quartet, "Bella Venti" that I need to process, several songs by "Dead Man's Hand" that need digital mastering and I have tons of yardwork that needs to be done.... or I may work on another Coco project... My wife would kill me! I have however, made a lot of progress on SoundChaser and hope to be releasing yet another BETA version soon.

15. The Memory Ain't What It Used To Be... (07/02/2012)

Over the past few days, I've been working on the File Selection routines. The plan is: To be able to hit enter on a file to select it. If it was already selected, then it is deselected. The file is marked by turning the filename green. In trying to do this task, I had to add a few more large variables to keep up with the selection of a possible 300 files. Now it seems I'm discovering why Mike had Ultimuse jumping through hoops (it seems) just to do a simple task. There seems to be a major memory leak between OS-9 and the way "C" stores it's variables. Too much in the wrong place and it starts writing over itself. Once a few things were added, the program ran fine, till I noticed when I brought up some menus and realized the menu items were not as they should be. There were incomplete sentences, lines from other menus... But everything worked as it should. It seems that just the string storage is being affected. I think I'm right in assuming that the strings are stored near the end of the file once compiled. It may just be a case of running out of 64k workspace, but I don't think so. I can sometimes, move the variables to another sub-file and they return to normal and the problem disappears. Sometimes it makes the program un-compilable. I think there is a limit to how large each subfile in a compilation can be as well as it's variable space. I know that in Ultimuse, Mike kept very strict rules on how large each file could be. He was also "fragging" out files to be loaded in to the workspace in a way that OS9 thought it was part of the original program and the main program could call routines as if they were part of that file. These files could be swapped in and out. I know that no given file I have in this file system is any larger that those in Ultimuse or any other large "C'" sources I've looked at. I'll just keep subbing things out to other files till I figure out what OS9 and "C" are doing to my variables.

Oh... and the file selection routines are doing nicely. All I have left is to create my play loop to play the selection. While I was in the menus, I added a few things. I now have a "Monitor Type" selection under the "View" menu and I've added the ability to enable/disable all the file types from the "Options" menu. This will allow you to select only certain types of files to display and select. This makes it easier for now since all the players are not completed. I still have a few bugs to work out in the Lyra and Standard Midi players, but they are near completion.

14. Alpha Beta Soup... (06/28/2012)

I now have a link to a Beta version of Sound Chaser for you to try out. It's by NO means complete and probably has a few bugs.

Please read the SoundChaser.doc file on the dsk image before attempting to run the program.

The file is a 720k 3.5 inch disk image with DNS set to 1

If you get an ERROR 247 when trying to view this disk, then type "Dmode /d0 dns=3", then try again.

If you find any bugs or have suggestions for new features, please feel free to e-mail me or contact me on Maltedmedia Coco list.

13. To Be... Or Not To Be... Lyra. (06/28/2012)

I have been really going at it with the Lyra player the past few days. It's getting real close to actually playing a file. I've also added more to the playing status windows for the Ultimuse and Musica players. They now tell you what song is playing and what device is being used. The Ultimuse status widow actually gives quite a few details as much of this had already been done in the base code for Mike Knudson's UBox3. As soon as I get a few more things figured out in the Musica format, I'll be displaying some song detail info there as well. I've also added a "Return To Main Menu" selection to all menus as well as sub-menus so that you don't get stuck having to make a selection you didn't intend on making.

As for Orhcestra 90.. I think I've come up with a solution for Orch90 as it plays files much like Musica does, just that in Musica, you must keep all note columns equal. This meaning that if you have a quarter note in one voice, all other voices must use a quarter note in that slot. Let's say you want a measure of music with 2 half notes in part one and 2 quarter and four eighth notes in part two. You must break down the part one so you have the same values as in part 2 but as running notes that actually sound like two big notes. In Orchestra 90, you could could use any type of note, anywhere. The unique thing Orch90 did different was that it "Scored" the file first, then you played it. This would scan the file and prepare all voices with the proper note values so that it played much like the Musica file, just behind the scenes. I'm pretty sure I can implement this style of play with the various "playmus" codes I've collected and written. This makes me wonder if I couldn't make one play module work with all types of "wavetable synthesis" player such as Musica, Bells & Whistles 2, Orchestra 90 ect. If I get the Orch90 player going... I think this could be done.

Well... it's back to work on the Lyra Player

12. Current Status Report (06/20/20112)

Ok... Here is the current status of "Sound Chaser":

GUI: For the most part, the GUI is done. There are a few things here and there I would like add, but the layout of the screen and menus will pretty much stay as they are.

Menus:

Files: All but one of the submenus here are working.

View: No working subs yet. I hope to add screen color & monitor type selections here so each user can set up their screen to the colors they like. Personally, I like the defaults as they are easy on the eyes.

Opts: As of right now, only 2 Options & sub-menus are working. The others are being slowly worked in as the various players mature.

Tools: No working menus yet. I'm not really sure what will go here. Any suggestions?

Select: This menu opens a window, showing the songs you have selected in the main GUI, in the order of their selection. A few cmd keys will work here: u-unselect the song under the cursor, U-Unselect all songs, p-play the song under the cursor, P- Play all songs in the list in order of selection, D-Delete the Song from the list, ENTER-Exit the Selection menu.

Misc: This one now holds a selection to view the credits

Edit: Nothing working but Edit will eventually be where you can turn things on/off and probably some filters of various sorts.

Help: This selection works but it doesn't show much yet, just the obvious "Key" choices. As features get added, this menu will grow as well.

eXit: This works as expected... it closes the program and exits to OS-9

That's about it for the menus. There are currently 4 types of files shown in the directory screen and only 2 will actually play. The directory shows Lyra, Ultimuse, Musica and Orchestra 90. Only Ultimuse and Musica will play. Lyra is very close to the playing stage now as I have been sorting through the various info I've gathered and have come up with a (hopefully) easy way in which to play the Lyra files. I will be adding the Standard Midi File player soon as it is working, I just need to give it some more memory. It is using a little too much memory when loading whole Midi files so I want to filter some of the data out that has nothing to do with the actual playing of the music then this one will be ready. As with the rest of the players, it too will be a stand-alone, command line player as well.

11. While We're At It... (06/17/2012)

While I was digging in SC's menus, I decided to also add the option to select different MIDI devices for the Midi players; Lyra, Ultimuse3, MidiPlay, ect. Now under the "Options", "Set MIDI Out Drv" you can select the Coco's Serial Port, Speech Systems Midi Pak (Glenside's works here too), User defined /MIDI driver or DriveWire4 /MIDI driver. I can also add the Colorchestra Midi Pak if any one needs it. All the drivers I have installed seem to work fine. I have the hardware Midi Pak and have used both the Serial port and the DriveWire4 port successfully. I hope to be adding more options to the Midi players soon like; Instrument assignment, Channel changing, transposing and others. Another thing I need to do is get the "Files","Save User Options" working so we will be able to save all these options as the defaults on startup. I guess I'm waiting on getting most of the options installed so I'll know how I want to arrange the ".init" file. It will most likely be stored in the SYS directory like most init files.

10. Can't Get A Break... (06/15/2012

I decided to try and add a <BREAK> routine to the Musica player. It's written totally in OS9 Assembler and blocks the interupts during play. Even though this is an OS-9 no-no.. Most "sound" players of any kind still have to do this, even under OS-9. I tried stealing the break routine from Play5 but it seem to send the Coco on vacation somewhere near Haiti and it didn't want to come back. So that one was trashed. Then while I was in PlayMuse's code, I wanted to work on being able to use different sound sources. I started by going back to SC's menus and adding the features I wanted there, then I slowly worked out a plan for PlayMuse. I've succesfully worked in routines in SC to select the Coco's internal DAC, the Orchestra 90 stereo ports and the Speech Systems Stereo pak. The selection is done in the SC "Options" menu under "Set Sound Output". This selection leads to the "Select Sound Type" menu to use either of the three sound options. I'm happy to say the DAC works as it should and since I have no Orchestra 90 at the moment till I find where I stashed mine, that it does work in VCC and in MESS. I'll double check it on the real hardware as soon as I locate my unit. As for the Speech Systems pak... I do not own this and the code was derived from another piece of software that used the unit, I'm hoping it works. I will find someone soon to BETA test it on the hardware. I'm currently looking into the RS Speech & Sound Pak to see if I can add that as an option too, but as of yet I have no info on the device.

9. Pumpin’ Up The Volume (06/08/2012)

Since I had the Musica module working, I decided to sort through the original Ubox3 code and get the Umuse format going, After going through the code once, removing all menu and print routines, leaving just the play routines, I added a few commands to load the Umuse score from the command line. I then run the compiler, fixed a cople of errors, run it again, then tried playing a file from the cmd line. I could hear the beat of some strange instrument and some percussion, but no where near what it should sound like. Something was definitely wrong. I went through the original code again and noticed a couple of things I had missed before. After recompiling, I tried the score again from the cmd line. Metallica’s “Enter Sandman” blasted through my sound system! This was really easier than what I thought it would be. I can thank Mike for making his code so modular as well as commenting it so well. It was a breeze to modify. Even the MIDI out parameters can be passed from Sound Chaser to the play module so that the user can select the MIDI device that they are using. I now know I need to go back to the Musica play module and add a parameter parser to the code. I would like the user to be able to set their sound output device on it as well…. But alas… It’s 2:00 AM and my mind is getting tired. Time to quit for a while. I’ll need a clear head to start on the Orchestra 90 and Lyra formats as they will be the toughest to implement. I have no source code for either player and both the OS9 Lyra player and RSDOS Orch 90 code will have to be disected by hand and players extracted. Orch 90 in particular is extremely complex as it has it’s own DOS routines and it’s own Telecom terminal. LyraPlay was written in “C” so it will be all over the place as far as ML goes. Lots of fun for me. Well… off to bed.

8. Making some noise !!! (06/06/2012)

This “C” stuff is getting easier all the time! The more I wade through all the Ubox3 code and various others, the more I understand. Of course the K&R manual as well as all the OS-9 manuals have been a tremendous help. It also helps that I’ve done 6809 assembly (OS-9 and RSDOS), RSDOS Basic, Basic09, MS Visual Basic, MS Quick Basic, and MS Small Basic. I find The MW OS-9 “C” language to be a little more criptic, but all-n-all, it seems to be pretty complete. With all the library extensions that have been created through the years, it has become fairly easy to create something usefull.

In the past day or so, the progress has been pretty fast. It took some manuvering, but I got the directory scrolling to work. This was quite an acomplishment. Using just the up and down, right and left arrow keys, you can scroll through up to 200 music files. I will eventually push it to see how many files I can go for, but for now 200 is plenty. The cursor will automatically screen wrap on the left/right screen boundries and will go to the next page on up and down. If the first or last pages are exceeded, the program wraps to the last and first pages respectively. The roughest thing I had to impliment here was when the last page is not full. I had to jump through some hoops to make the cursor go only to the directory selections and not the empty spaces, but it now works fine.

The next thing I’ve worked on is actualy playing some music. Since this was all based on Ubox3, you may think that playing a Umuse3 file would have been automatic, but remember, I removed all the Umuse3 code and rewrote the program structure. The format I worked on first was Musica. I had a disassembly of PlayMus for OS-9 and with a few modifications, I can now call it from Sound Chaser. If you select a file other than a Musica file, you will get a prompt telling you what format the file is, then hitting enter to take you back to the selection process. Pressing “P” on a musica file results in the file playing on the Coco!!! Now this is what it’s really all about, playing the music. Warning! There are a lot of Musica files out there that have an embedded player. They tipically have the “.bin” extension but I have found a few with the “.mus” extension. These files WILL load and play, but the result is a bunch of static. I will research the file format to find a way to ID these files and bypass them. Soon I will start working on a way to pass some parameters to the Musica player so I can utilize the different sound sources such as the Speech Systems Stereopak, the Radio Shack Speech and Sound card, the Orchestra 90 pak or just outputting the sound via the 6-bit DAC on the CoCo.

7. Smokin! (06/04/2012)

I’ve made a lot of progress over the past few days. My new system structure is up and running. I think I’m going to have to drop Zack’s “window,h” library though. It was doing well for a while… It was restoring my old window upon exit up until I got the program actually reading music directories. It seems some of the “system” calls I’m using in “C” are conflicting somehow with the window.h library and my screen comes back with the shell clobbered. It only seems to do this on exiting Sound Chaser. I’ve had to drop back to just killing my window and reopening a clean one on exiting. It works for now, but I hope to find my problem with window.h so I can exit properly.

Sound Chaser will now read a directory and find several different music formats and display them in the selection window. For now, it will only show 54 music files. I’m working on a way to scoll the directory so you can select and play from over 100 files. Mike’s directory routines from Ubox3 were invalueble in reading the files. His system of sorting through the files and finding only the ones you want is really nice. I’ve ended up using a lot of Mike’s routines as they are well written and in some cases, the only way you would probably be able to do the task anyway.

Thanks to CGFX7, I have implimented a menuing system that will allow me to add a lot of features without a lot of overhead. The pull-down menus will work on either a text or graphics screen. I may eventually go as far as to use the user’s own screen for the display and have a “color selector” for setting the colors then returning them to their original state on exit. As you will see from the screenshots, there’s been a lot of action with this project lately and I hope to get more done in the next month or so.

Here’s a few screenshots of Sound chaser so far.

(old pics, new ones coming)

<Figure 4> The new program structure.

In <Figure 5> you will see that I’ve got the directory read up and running. Sound Chaser reads the selected directory and finds all the “.ume”, “.lyr”, “.mus” and “.orc” (so far) files in the directory. It reads the first 54 music files into an array then chops the “.xxx” from the end of the file for the display. Then Sound Chaser (SC) will display the files for selection. I’m not sure as of yet how I want the selection to work, but I know I want to be able to select multiple files and play them in the order of selection.

<Figure 5> Sound Chaser displaying 5 types of music file formats.

The next shot is the “File” pull-down menu. So far, there are 6 choices here, first to return to the main program. I hope to have it also exit the menu by hitting <BREAK> but with using CGXF7, I think the macro is doint it’s own trapping and won’t let me at the interrupt. I’ll have to do some checking on this one. The second option (working) is to select a new directory of music files.

<Figure 6> Sound Chaser’s “Pull-Down” menu system.

SC will display the contents of the current directory, then prompt for a new one. An error message will appear if you type it in wrong, the it will re-prompt. Hitting <ENTER> will exit and take you back to the main loop. The third menu chois is to save user options (not working). Here I will be implimenting several options such as screen colors, MIDI device type (Speech Systems, Colorchestra, or Serial), sound destination (Speech & Sound, Orchestra90, DAC) and if I implement it, Mouse type (Left/Right, Hi/Low Rez). The fourth menu choice is to DIR non music. This will display all the files in the directory, not just the music files. The fifth choice is the standard “OS-9 Shell”. This will run an OS-9 Shell in our workspace and prompt for your command. Once you type the command, it “Shells” to OS-9 and runs the command and any parameters you provided. The sixth choice is the “Exit To OS-9” which ends the program.

Our next screen shot, <figure 7> is of the “Help” menu (working). This menu shows an overlay window of menu listings and shortcut keys.

<Figure 7> Sound Chaser displaying a “Help” menu.

Next in <figure 8> we have a shot of the “Dir Non-Muisc” in action. This can be helpful in finding your music directories.

<Figure 8> Using the “Dir Non Music” selection

Next, <figure 9> is the result of the above. I was in my music directory, so that was all that listed

<Figure 9> The results of the above selection.

Next is a shot of the “Change Directory” showing the prompt.

<Figure 10> Using the “Change Directory” function.

<Figure 11> Preparing to run a “Shell Cmd”.

<Figure 12> The complete “Shell Cmd”.

Finally, we exit back to OS-9, <figure 13>.

<Figure 1> Michael J. Knudson’s original “Ubox3” program displaying a few UltiMusE III files.

Notice that there are no file extentions.

<Figure 2> Another shot of Ubox3 with several files selected

1. Getting It All Together (01/01/2012 - app. 05/19/2012)

The first order of business was to gather all the tools Mike used for the compilation process. As I had his system, it would seem this to be an easy task. Alas... woe is me.. When the system was shipped to me, there was a loose screw in the hard drive case. The screw had lodged itself in the circuits of the power supply. As I turned on my "new" Coco system, a distinct smell of circuits burning was in the air. Needless to say, the hard drive wasinaccessable. I eventually rigged up a new power supply and got the drives spinning. After several days of making boot disks for OS9, I finally got one that would read the drives, but HD 1 would not read. I found all the source code to Umuse on HD 0 but the drive would only read for about 15 minutes before it would error out and not be readable again until the unit had cooled. I spent several weeks transferring files a few at the time, from the hard drive to my virtual HDs on my PC which I could then read with the Coco via Drivewire 4 or with VCC, the Coco emulator. Call it "bit rot", "shipping damage", or just my bad luck... some of the files were corrupt and would not read. Luckilly, the source code seemed to be intact. It was the CMDS directory that seemed to have the most of the "bad code". Mike uses a lot of "special" and homemade "C" tools to compile Umuse, so I needed this code. As luck would have it, he had included a number of floppy disks in my system, so I had to search through the disks and find one file here... another there and so on. There were even a couple of the utilities that I could not find but there was source code for them on the HD, so I had to compile them myself. Eventually, with a test run to compile Mike's last incarnation of UBox3, I had succes!!. The tools were complete... now on to learning "C" and remodeling the UBox3 program!

More coming soon... !!

BP

web counter