Almathera Ten Pack 3: CDPD 3

home *** CD-ROM | disk | FTP | other *** search

/ Almathera Ten Pack 3: CDPD 3 / Almathera Ten on Ten - Disc 3: CDPD3.iso / scope / 176-200 / scopedisk199 / experimentiv / experiment.doc < prev

Wrap

Text File | 1995-03-20 | 12.4 KB | 301 lines

Experiment IV, Revision 1.8. --------------------- Legalese -------- This program is copyright 1991, Marc Espie. It is freely distributable, for non-commercial purpose only, provided that the program and this file stay together. THIS PROGRAM IS PROVIDED ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE RESULTS, RELIABILITY AND PERFORMANCE OF THIS PROGRAM IS ASSUMED BY YOU. THIS DISCLAIMER SHALL SUPERCEDE ANY VERBAL OR WRITTEN STATEMENT TO THE CONTRARY. Ok, now I've covered myself. Let's go for some explanations. I want to keep some control over this program right now, because I'm still working on it. ``Commercial purposes'' include inclusion in a so-called ``PD software library'' at a prohibitive cost, like more than $5 by disk. I would appreciate it if you would contact me before including it in any library, because I may have a newer version ready at that point. Experiment IV is a small (<40K) soundtracker music player. As such, it understands a reasonable subset of the various SoundTracker/ProTracker/ NoiseTracker/... commands, that is, it is able to play about every module correctly... each of my collection of 156 modules plays correctly. Support for MED, SMUS, FutureComposer... has not been added yet, nor for packed modules. It is system-friendly: uses a minimal amount of chip memory, returns all resources to the system, aborts gracefully when there is a problem, asks for the audio.device, asks for the interrupts, and gives everything back gracefully. It also does cooperate with other programs for use of the audio.device, which means that your terminal should still be able to beep gracefully... unless that terminal doesn't cooperate with other programs of course. Since it uses the CIAB timer, it should not depend on being run on a PAL or NTSC amiga. Under normal conditions, it is fast enough to be used with a terminal emulator program. It runs almost indifferently on any amiga, though it won't be of much use without some memory: with less than one megabyte, using it with another program will be something of a challenge. (``Almost indifferently'', because it recognizes 2.0 and adds some bonus features on 2.0 systems.) Report serious bugs to espie@flamingo.stanford.edu, and watch out for a newer version. Installation: ------------ This program doesn't really NEED any installation. However, it really cries for the arp.library to be fully functional. The program knows that music: is a good place to search for modules, so if all your modules are at the same place, assign Music: to that place. You can also put it in your startup-sequence or WBStartup (there is a DONOTWAIT tooltype in the icon). Use and features: ---------------- You can start Experiment_IV either from CLI or Workbench. It does detach itself from the CLI. From the CLI, you can give full module names on startup, it will load the first module and start playing. If the arp.library is installed, it does pattern matching. From the workbench, you can shift click on several module icons, likewise. If you don't give any name, it will just wait for you to load anything... which will be a trifle difficult if you are under 1.3 and the arp library is not available. There are some configuration options, that you specify as tooltypes in the icon, or give on the command line. X=x : starting X position of the window. Won't open if somewhat over 500. Y=y : starting Y position of the window. VOLUME=p : p% of maximal volume. PRIORITY=p : audio channel priority, for arbitration with other tasks. START=k : starts the first song at pattern k. REPEAT=n : repeats each song n times. Default is indefinitely. DONOTWAIT : set that for WBStartup use. TRANSPOSE=t : transpose the song t halftones. SPEED=NTSC or SPEED=PAL : starting speed (default is PAL). Transpose is a funny option, not intended to be useful, since it does no range checking... use at your own risk. One of my favorite startups is "exp repeat=1 volume=75 music:#?/#?" ...after you've specified a file or pattern, you have a small window opened and (hopefully) some music running. If no music is playing, check your audio output, then check that no other program has allocated the audio.device but doesn't use it (example: MED, JRComm (sigh...)). There is a status line, with the name of the current module and useful indications (current pattern:length of song). There are five little gadgets at the bottom of that window. - Load. Gets to the next module (if several are specified on start) then asks for a module name (needs the file requester, see installation), loads it and plays it. This is ``seamless'' play, if it is possible to store the two modules in memory at the same time. Otherwise, the first module will stop, the second module will hopefully fit in memory, and play will resume. (In really tight memory conditions, the file requester might refuse to appear...) - Restart. Restart the module at the beginning, useful when the speed is wrong. Also used to restart a module which has replayed N times. - Pause: one click to pause, another to continue. Sometimes, the program isn't playing, and the pause is not on. Either you have no module running, or something else is using the audio.device. - PAL. A speed. You can cycle through Slow/PAL/NTSC/Fast/Scan. PAL and NTSC are the type of the machine that module was composed on, slow and fast are... well... slow and fast. Scan is very fast, a bit noisy, but useful to get somewhere quickly. - Std. This is a ``compatibility'' gadget. Different trackers have different interpretations of the speed commands... I found three different ones. The standard one should be able to play most modules, just toggle and restart for modules which don't play right. If you don't get it to run with any setting, drop me a note...(sigh...) - Close gadget: stops player and quits. Warning: no safecheck, if you close it, you've done it. There is some Workbench support: you can start the player with a set of modules (shift-click), or even use it as the default tool for modules. In that case, the load gadget will first walk through all these startup modules, before bringing up the file requester. Version number: -------------- Whenever the program window is active (just click on the title bar), the screen title bar displays some information about the program, like the version and the compilation date. How to regain memory: -------------------- If you try to close the window while a song is loaded, it will first unload the song and give you some memory back. You'll have to depress close again to actually exit. Customizing modules: ------------------- It's a good idea to add icons to your modules. They should be projects with Experiment_IV as the default tool. You can add some tooltypes to these, like SPEED=NTSC, MODE=STD, MODE=OLD, or MODE=NEW. These will be recognized from workbench or CLI. Albums: ------ You can program whole albums of songs. Just create a file with a text editor with some filenames in it (one filename per line, no spaces before the filename). Put an icon to that file, and add an ALBUM tooltype to it. That's it! Paths of the filenames are relative to the album's directory. You can also put patterns, or even other albums (be careful: recursion is NOT detected). 2.0 specific support: -------------------- I don't really support the 2.0 file requester nor extended dos library right now, but that should come. However, the program opens an appwindow. This means that you can also load songs and albums by just dragging icons into the program window... Nice things: ----------- If you make a mistake and ask it to load a non-module file, the program will most often not be fooled, and just do nothing about it. The pause feature can be used with several players. If you fire up several players at different priorities (option *), the highest priority one will play, unless you pause it, in which case the next one will go. This is very useful for comparing different versions of the same module. Non-confusion option: the song-title display should change colors according to whether or not that player is running. The program tries very hard not to fragment chip memory, and usually succeeds. It just uses the exact amount of chip-memory needed for the samples, besides that needed for the file requester. The program knows about preference fonts, and has a reasonable look under 2.0. Not so nice things: ------------------ There is no error report if something goes wrong, it just exits... There is no check when you hit close by mistake. The chip memory is allocated as a big chunk. If your memory is fragmented, you won't be able to load anything. When the filerequester is up, the program can not listen to every event: the pattern counter doesn't get updated, another program asking for the audio.device will wait till you exit from the requester. The volume control isn't user-friendly, and the player is able to do lots of things that aren't accessible to the user yet. The way options are taken from various icons isn't always intuitive. Known problems: -------------- The player doesn't handle commands 5-9, and not all forms of the extended command (14) exist. ``Finetune'' is a theoretical possibility, not tested in practice. Some range-checks aren't done, the extended speed change (CIA control) is not thoroughly tested and can conflict with real old modules. Some rare non-modules files might get played. The result is a lots of noise, but harmless and bug-free (should be). As with every other players, there are ``pops'' for some sound-changes. Correcting that will be difficult. Under 2.02, the AmigaDOS file requester loses memory when you ask for events (or I've got something wrong...), so the arp file requester is used exclusively. Under 1.3, the tooltypes aren't as flexible. The albums won't be recognized with just ALBUM, you need to enter something like ALBUM=kludge to get it to work. The ``n repeat'' command is simple-minded, it will get confused by modules with lots of GOTOs. The audio.device seems to have problems handling clients waiting for a locked channel. Apparently, ADCMD_LOCK can freeze the ADCMD_ALLOCATE commands as intended, but also AbortIOs of these commands, until there is a change in the allocated channels. So closing a player waiting for channels might just hang until another player frees the channels. Things to do (rough priority order, *=done) ----------------------------------- * cleanup the event handling * release the source code. * full workbench support (including 2.0 appwindow/appicon). - add support for MED, recognizes soundtracker variants. - powerpacker support. - preprocessing of modules to be able to jump anywhere without problems. - instruments library. Compiling: --------- The sources to the program are in a different archive. If you want to recompile the program, there should be no problems... If you have only 1.3, you will have to make some changes to accomodate all the structures not defined in 1.3 (just giving a dummy definition or commenting out part of the code is enough.). Besides that, this is pretty much standard ANSI C and AMIGA OS code. Also, interrupt.c uses the ASM keyword of Lattice. Replacing the C call by an assembly language stub is a two-minute job. It also needs some support for far absolute addresses. If you don't have it, you will have to modify audio_hard.c and interrupt.c (note that you can't have any absolute references to ``task-owned'' variables in audio_hard.c. You will need to disable stack-checking for the interrupt routine modules (all modules flagged with -v in the lattice makefile. Some local peculiarities of my system: the arp includes are installed, and I've got a directory ``custom'' where I stuff some includes (cleanup.h for this project). Cleanup is an ``auto cleanup module''. If you want to modify my program, you had better understand how it works (see cleanup.h). Basically, it enables me to keep track of everything I allocate. It's also very powerful for dynamic backtracking (check the heavy use of it in files.c). The missing ``mymain.c'' is actually the lattice umain.c. It just does handle standard startup, and usually opens a console window on workbench (but I don't want that !). If you don't have Lattice, check your compiler for a suitable startup option. Marc Espie (espie@flamingo.stanford.edu / espie@dmi.ens.fr /espie@FRULM63) 5/20/91, Palo Alto.