** 2 page AtariPhile / 1485 words **

Bringing Multimedia to the Falcon

Multimedia conveys messages using a number of different methods or media. On a computer this generally means using text, sound and images - both stills and movies. After lots of head scratching multimedia has found its niche in presentation and education where it is both effective and cheap.

Back in 1993 the Falcon was billed as a multimedia machine. Thanks to TOS/GEM and compact applications the Falcon can still turn in a reasonable performance compared with other platforms.
The Falcon sound system is built-in which means programmers can rely on its presence. The video system supports up to 16-bit colour which is good enough for most applications.

MultiPlicity, the Concept
With the above in mind I set out to program MultiPlicity, a multimedia authoring package, as my final year computing project at University.
Presentations are based on a book metaphor. Each presentation is called a book and each screen within that book is a page. Once a book is built, the reader simply clicks on an icon on a page to start a multimedia event.

Putting it together
The first thing I did was to create a Requirements Document containing (shock horror) details about the project. Using a word processor it's easy to add things as you think of them and keep the document up to date. Here's the main headings:
** BL **
* Introduction: General outline of the program's abilities.
* Hardware: Hardware requirements for the program.
* Functions:  Listing of everything the program does and operational requirements (by far the longest section for MultiPlicity).
* Constraints: For MultiPlicity this stated the programs should use GEM and detect the presence of a multitasking OS and act accordingly.
* Test data: How the program will be tested.
* Future enhancements and developments: Anything you envisage adding to future program releases.
** BL end **

The Requirements Document helps determine:
** BL **
* What the program should do but not how it should be done.
* Helps separate what is required, for the program to function, from features which are desirable but not essential.
* Sets the boundaries for the project.
** BL end **

Setting the boundaries was essential because for a multimedia authoring package the sky really is the limit and I only had 15 weeks to complete the project.
One of MultiPlicity's key aims was to call external programs to run multimedia events. This was partly due to time constraints but on reflection a more important reason is flexibility. For example if an external viewer is updated MultiPlicity can use it without changing a single line of code. When I wrote MultiPlicity there wasn't a decent AVI or Quicktime player available. Now Movie Player is available it can also be utilised. The Thing desktop takes the same approach and I suspect this model of program development will increase in popularity.
Not everything in MultiPlicity uses external applications. There are internal routines for handling IMG graphics files, AVR sound files, and ASCII text files. The main reason for this was to give me experience at programming using these types of files - one of the learning objectives I set myself. Of these, only the graphics handling is essential because it's needed for page backgrounds and icons but the audio code is pretty cool too because it utilises the Falcon sound system - something few external players do. Both these routines have been improved in MultiPlicity 2 (with colour and 16-bit stereo support). All this was in the Requirements Document and ensured I didn't get side-tracked coding a FLIC movie player!
So, ready to start coding yet? Everybody yells "NO" but I say possibly, although not the actual project. If, like MultiPlicity, your project relies on coding something you are not sure about, it is worth spending time now to try out a few ideas and see if they work. In MultiPlicity's case, it relied on its ability to call other programs to run concurrently with MultiPlicity. My original plan was to use Pexec(), which is the time-honoured way of calling programs from within others. This didn't prove to be what I wanted because the calling application is frozen until the called application quits. I eventually used shel_write() which is the method used by desktops and works well under MultiTOS, Geneva and MagiC.

Designing the Software
Once you know what the software is supposed to do, it's time to decide how it's going to do it. I would recommend taking a top-down approach. Design the software at a superficial level first going into detail later. So, for example, if you want to open a window, at the top level you would simply write "Open Window". Later you can add the details of how this is done. This means you won't get bogged down with detail when you are still trying to work out the program flow. I use Thought! from Titan Designs for this. It's a bit pricey but makes the whole thing really easy to do.

At the end of the design process, the whole thing can be output to printer either in its diagrammatic form or as pseudo code that can be more or less directly translated into the language of your choice (assuming your design is detailed enough).

The best low-cost solution is to write pseudo code directly using a word processor or text editor. Pseudo code is similar to real code except you don't have to worry about syntax. It works something like this, at the top level you would write:
** NP font on **
1	Open Window

Later on you can add more detail:
1.1	Create window
1.2	Open the window

Going down a further level may result in:
1.1.1	wind_create( window 1 )
1.1.2	wind_set( title = "Window 1" )
1.2.1	wind_open( window 1 )
** NP font off **

At this stage, the commands are almost in C ready to write the actual code. It's worth trying to identify parts of the program which can be recycled, not just in the current project but in future projects as well - a good example of this is the GEM initialisation code which is almost identical for every program. 

Finally, the user interface needs to be designed. For a GEM program you can kill two birds with one stone here by designing the interface using a resource construction program. I used WERCS, which comes with Lattice C, for MultiPlicity, but have now moved onto Interface which is more comprehensive. Once the interface is designed it can be plugged straight into the program code.

Writing the Code
Code should be structured to be as readable as possible. Use indenting if your chosen language allows it and don't be afraid to leave blank lines to separate different parts of a function. Always sprinkle your code liberally with comments so you, or someone else, can figure out what's going on.

For MultiPlicity I used an approach called "incremental prototyping". This involves coding a section, then compiling and test it in isolation. It does sounds tedious and isn't ideal for every project, but for MultiPlicity it worked really well. Seeing the results of my efforts quickly really helped maintain my enthusiasm. This approach also helps to keep debugging down to bite size chunks and is infinitely preferably to wading through 5,000 lines of source code. To a certain extent, incremental prototyping also sets the order in which things should be done - for example, you can't open a GEM window until you have initialised GEM.

If your chosen programming language allows, consider splitting your program into modules. These help reduce compilation times and only entails a small extra overhead to manage.

Testing
There's no such thing as bug-free software but generally speaking the more the better rule applies. Get other people to beta test it for you. If you're on-line it's easy - just ask and you'll get plenty of volunteers. Atarians love to get involved - the Atari community is brilliant like that and one of the reasons I have continued to develop on this platform.

Ongoing development
No program is ever really finished. There is always one more feature to add and there will always be bugs to fix. I released MultiPlicity v1.03 as freeware back in May 1996. Since then I've wanted to implement internal colour support and MagiC support but it took ages to get the relevant information together so there has been a long delay until I finally released MultiPlicity 2 several months ago.

** Boxout **
Multiplicity 2 is shareware and costs £15 to register. Continued development is dependent on support from users so if you're using MultiPlicity please do support Martyn in his efforts.
** BC on **
Martyn Tidd, 6 The Hollow, Gossops Green, Crawley, West Sussex, RH11 8BT
** BC off **
** end boxout **

** Images **
** 0001.GIF **
New, improved Edit Page Object dialog
** 0002.GIF **
Page backgrounds can be in full colour
** 0003.GIF **
Internal graphics routines can display images in a window
** 0005.GIF **
Pictures can be embedded in page backgrounds
** 0006.GIF **
New colour animated icons for both links and objects