@database 07880e20-0 @master Ram Disk:Iss2/ARTech.guide @$VER: 1.2 @author "Osma Ahvenlampi" @(c) "FS Publications" @remark Created with Heddley v1.1 (c) Edd Dumbill 1994 @node "Main" "Amiga Report Technical Journal, Volume 1 Issue 2" @{b}@{fg shine}Amiga Report Technical Journal@{ub}@{fg text} _________________________________________________________________ @{b}Amiga Report Technical Journal Volume 1 Issue 2@{ub} _________________________________________________________________ Amiga Report Technical Journal and ARTJ are Copyright © 1995, FS Publications, All Rights Reserved. _________________________________________________________________ @{b}In this issue@{ub} @{fg shine}Departments@{fg text} @{"Editorial" link "Editorial" 0} @{"Pointers" link "Pointers" 0} -- Hot spots, news, and files @{fg shine}Features@{fg text} @{"Genetic Algorithms" link "GeneticAlgorithms" 0} by Marcel Offermans @{"Making videos on Amiga" link "Video" 0} by Lee Roskin @{"A survey" link "Survey" 0} about what you think is important in a good program Robert Reiswig continues the @{"Installer guide" link "Installer2" 0} from the first issue _________________________________________________________________ Producing Editor, Osma Ahvenlampi, Osma.Ahvenlampi@hut.fi Supervising Editor, Jason Compton, jcompton@xnet.com, FS Publications. @{"Contributors, staff, and contact addresses" link "Staff" 0} _________________________________________________________________ Views, Opinions and Articles presented herein are not necessarily those of the editors and staff of Amiga Report Technical Journal, hereafter ARTJ, or of FS Publications. Permission to reprint articles is hereby denied, unless otherwise noted. All reprint requests should be directed to the editor. ARTJ and/or portions therein may not be edited in any way without prior written permission. However, translation into a language other than English is acceptible, provided the editor is notified beforehand and the original meaning is not altered. ARTJ may be distributed on privately owned not-for-profit bulletin board systems (fees to cover cost of operation are acceptable), and major online services such as (but not limited to) Delphi and Portal. Distribution on public domain disks is acceptable provided proceeds are only to cover the cost of the disk (e.g. no more than $5 US). CD-ROM compilers should contact the editor. Distribution on for-profit magazine cover disks requires written permission from the editor. ARTJ is a not-for-profit publication. ARTJ, at the time of publication, is believed reasonably accurate. ARTJ, its staff and contributors are not and cannot be held responsible for the use or misuse of information contained herein or the results obtained there from. ARTJ is not affiliated with Escom AG. All items quoted in whole or in part are done so under the Fair Use Provision of the Copyright Laws of the United States Penal Code. Any Electronic Mail sent to the editors may be reprinted, in whole or in part, without any previous permission of the author, unless said electronic mail is specifically requested not to be reprinted. _________________________________________________________________ @endnode @node "Editorial" "Editorial" Recently, I had an argument with a friend about program optimisation. I thought a great utility he had made could be made user friendlier, and thus, in my view, much better, by adding some extra strings in it. The friend thought these would just be a waste of memory, however little they would take. We've had this kind of arguments before, when he has wanted versions of programs optimised for his CPU model, "to save those few cycles". Most of the time, I think this kind of tweaking is just ridiculous. Who is going to miss a few bytes of memory, or a couple of CPU cycles each second, when the majority of users have both to spare? Of course, he thinks the same way of me, claiming that I'm on the way to bloated code. This is an example of the diversity of goals people have while developing programs. Some think it a win if they can shave off 30 bytes from their 15k utility, some wouldn't care the slightest if it took twice as much. Some think a graphic user interface just slows them down, while others hate "cryptic" command line arguments. There are people who never use advanced features in a program, but like it goodlooking, while another group don't pay attention to the aesthetics, as long as the software can fill their every need. There are only two aspects I think everyone agrees on. A program should not crash, and it should not be slow. I believe no one would argue against these two points, but I can not be sure. Does someone out there disagree? We programmers have a hard task in trying to satisfy as many as possible. Especially in a field like Amiga, where the users are few to start with, a developer can not afford to turn off a significant group of potential users. Because of this, I would like to ask all of you, developers and users alike, what is it that you expect in a good program? I know many of you are very tired of surveys, but I think this is a different one. Please, take a couple of minutes to @{"fill out the form" link "Survey" 0} later in the issue, and send it to artech@warped.com, with a subject of "User preference survey". I played with the idea of making this survey a WWW form, or even an ARexx script, but due to the variety of medias ARTech is distributed through, a conventional ASCII letter will probably work best. Sorry. Maybe you'll see some cool forms later. Last, while definitely not least, I would like to apologise for the long delay between the first ARTech issue and this second one. I can not say that things would have been hectic here, because they have not. After taking over the job of editing ARTech from Greg Block, who began this magazine, I was faced with the serious of problem of not having any articles to fill a magazine with. The problem remains. Because of this, I want to take this opportunity to ask you, the reader, to contribute to ARTech. We are not just a programmer magazine, we are a magazine for every technically oriented Amiga user in the world. Tell us what you do with your Amiga, and how you do it. The address is the same as before, artech@warped.com. I wish to give all of you an interesting magazine, one worth reading. Help make it possible. Yours, Osma Ahvenlampi, editor of Amiga Report Technical Journal. @endnode @node "Pointers" "Pointers" /* Pointers.c */ #include "pointerdefs.h" ULONG Main(int Attraction) { Object *Pointers = NULL; Pointers = NewObject(PointerClass, NULL, POINTER_FTP, NewObject( FTPPointerClass, NULL, FTP_Site, AMINET, FTP_Filename, @{fg shine}"misc/emu/ShapeShift3_0.lha"@{fg text}, FTP_ShortDesc, "Macintosh II emulator, V3.0", FTP_FullDesc, "misc/emu/ShapeShift3_0.readme", FTP_Flags, FTP_COOL | FTP_EMULATOR | FTP_USEFUL, TAG_DONE), POINTER_FTP, NewObject( FTPPointerClass, NULL, FTP_Site, AMINET, FTP_Filename, @{fg shine}"dev/gcc/ixemul4101bin.lha"@{fg text}, FTP_ShortDesc, "IXemul.library 41.1", FTP_FullDesc, "dev/gcc/ixemul4101bin.readme", FTP_Flags, FTP_GCC | FTP_LIBRARY | FTP_SOURCE, TAG_DONE), POINTER_FTP, NewObject( FTPPointerClass, NULL, FTP_Site, AMINET, FTP_Filename, @{fg shine}"gfx/board/CGraphX20u.lha"@{fg text}, FTP_ShortDesc, "CyberGraphX intuiemo update 2.0", FTP_FullDesc, "gfx/board/CGraphX20u.readme", FTP_Flags, FTP_RTG | FTP_LIBRARY | FTP_COOL, TAG_DONE), POINTER_FTP, NewObject( FTPPointerClass, NULL, FTP_Site, AMINET, FTP_Filename, @{fg shine}"dev/misc/HWGRCSp11f.lha"@{fg text}, FTP_ShortDesc, "GNU Revision Control System 5.6.0.1, " "Patch 11, SAS/C port", FTP_FullDesc, "dev/misc/HWGRCSp11f.readme", FTP_Flags, FTP_DEVTOOL | FTP_ESSENTIAL | FTP_SOURCE, TAG_DONE), POINTER_FTP, NewObject( FTPPointerClass, NULL, FTP_Site, AMINET, FTP_Filename, @{fg shine}"util/dtype/tiff.dtype.lha"@{fg text}, FTP_ShortDesc, "TIFF datatype. Converts 24bit images " "to 256 colors with Floyd-Steinberg " "dithering", FTP_FullDesc, "util/dtype/tiff.dtype.readme", FTP_Flags, FTP_DATATYPE | FTP_FUNKY | FTP_24BIT | FTP_ SOURCE, TAG_DONE), POINTER_FTP, NewObject( FTPPointerClass, NULL, FTP_Site, AMINET, FTP_Filename, @{fg shine}"util/dtype/textdtpatch.lha"@{fg text}, FTP_ShortDesc, "Patches text.datatype to support " "searching", FTP_FullDesc, "util/dtype/textdtpatch.readme", FTP_Flags, FTP_GROOVY | FTP_DATATYPE | FTP_SOURCE, TAG_DONE), TAG_DONE); if(Pointers) { DisposeObject(Pointers); return ((FUNKY | COOL | THRIVING)); } else return(NULL); } /* * If you would like to see your pointer entered into next month's * Main(Attraction), EMail your struct definition to artech@warped.co. */ @endnode @node "GeneticAlgorithms" "Genetic Algorithms" @{b}Genetic Algorithms@{ub} @{fg shine}Marcel Offermans @{fg text} _________________________________________________________________ @{b}Introduction@{ub} Genetic algorithms have recently received much attention because of their ability to solve difficult problems, just like for example neural networks. Although they are completely different, both have their origin in Biology. There are even cases where both algorithms are used to complement each other. This article is an introduction to genetic algorithms and their implementation on a computer. @{b}What is a genetic algorithm?@{ub} Genetic algorithms are based on processes that can be found in natural evolution. Their origin, as mentioned before, lies in Biology rather than Computer Science. The exact mechanisms behind natural evolution aren't known very well, but some of its aspects are. Evolution works with chromosomes: organic information carriers which contain the exact characteristics of a living being. The living being can be 'built' by decoding its chromosomes. How this is done isn't known exactly, but the following properties are commonly accepted: * Evolution is a process that works on chromosomes instead of the living beings they represent. * Natural selection is the relation between chromosomes and the performance of their decoded structures. The process of natural selection ensures that chromosomes that represent a good structure will more often reproduce than others. * Evolution occurs while reproducing. Mutations can be the reason that chromosomes of children sometimes differ from the ones of their parents in certain places. The chromosomes of the parents are combined in a certain way to create new and different chromosomes for the children. * Biologic evolution has no memory. All that it knows about individuals that perform well in their environment is stored in the set of chromosomes of the present individuals and in the way that chromosomes are encoded. These properties were the reason that John Holland [4] started to research computer algorithms based on this principle. He wrote algorithms that could reproduce chromosomes, represented as binary bitstrings, strings containing '1's and '0's. Just like in nature, these strings were manipulated blindly in order to get good chromosomes. The reproduction mechanism knew nothing about the problem it was solving. @{b}What can you use it for?@{ub} One of the regions in which genetic algorithms perform quite well is in optimization. A genetic algorithm is very robust, which means that it works for a broad range of problems. When you compare it to more traditional optimization algorithms, the most important differences are: * genetic algorithms work with a coded version of the parameters; * they don't search from one single point, but from a population of points; * they use 'pay-off' information instead of derivatives or other auxiliary knowledge; * they use stochastic reproduction instead of deterministic rules. A lot of problems can be seen as optimization problems. Optimization problems are (in this instance) formulated as mathematical models with many independent parameters that result in one so called fitness function. This fitness function describes the 'quality' of the model (or individual) for that set of parameters. In the fitness function, you can model all kinds of conflicting demands. All you need to do now is to optimize one, usually quite complicated, function: f(x1, x2, x3, ..., xN) Where x1, x2, x3, ..., xN are the independent parameters that need to be determined. If you want to use a genetic algorithm, you need to make sure that this function is always bigger than zero, but that can easily be done. The following chapter will explain how you go about when you want to optimize such a function with a genetic algorithm. @{b}How to create the chromosomes?@{ub} The first thing you have to do is encode the independent parameters into a chromosome. This chromosome then carries all the essential information about that particular individual. There are two different ways of encoding the parameters: * in binary format; * in floating-point format [5]. When you use binary encoding, you use N bits for each parameter, where N can be different for every paremeter. If a parameter can vary between a minimum value MIN and a maximum value MAX, the following formula can be used to determine the resolution: r = (MAX - MIN) * (2^N - 1) The meaning of this resolution is obvious. The chromosome is created by putting all encoded parameters after one another. By decoding the chromosome again, the original values of the parameters can be found. When you use a floating-point encoding, the chromosome is created by putting all the floating point numbers after one another. This means the encoding and decoding steps don't have to take place. Comparing both methods shows us that a binary encoding is more work, since you have to encode and decode your parameters every time. This is a clear disadvantage. However, a binary encoded chromosome has a lot more elements (every bit is considered to be an element) than a floating-point encoded one. Having more elements is considered to be an advantage. @{b}What does the genetic algorithm do?@{ub} In general, a genetic algorithm works as follows. In the first population all chromosomes are generated randomly. Their fitness is then determined. At this point the genetic algorithm can start generating new populations. Usually, the population size is kept constant for convenience. Reproduction consists of three distinct steps: * selection; * crossover; * mutation. These steps will now be discussed in detail. Selection represents a very important aspect of the genetic algorithm: survival of the fittest. This is usually implemented as a weighed selection, which means that individuals with a higher fitness have a better chance of being chosen. It is possible for an individual to be selected more than once, or not at all. Crossover is the most important mechanism of the algorithm. It makes two new individuals by somehow combining two old ones. There are several variations of crossover. The most simple version is one-point crossover. It works by selecting a point at which the chomosomes are cut off randomly. The parts that are cut off are then switched to make two new chromosomes. @{"A picture that illustrates how crossover can be done." link "GA_Crossover.gif/MAIN" 0} Mutation introduces random changes to chromosomes. It is a mechanism that has only a small chance of occurring. It simply flips a bit in a chromosome, or if the chromosome is made out of floating point numbers, it changes a number. @{"A picture that illustrates how mutation can be done." link "GA_Mutation.gif/MAIN" 0} This simple process is repeated until the entire population is reproduced. The new population is decoded and the fitness of the newly created individuals is calculated. At this point, the process starts all over again. At first, it is difficult to see why this leads to better individuals. The most important thing is that it does. More or less solid mathematical proofs can be found in literature [2], [3], [4] and [5]. The best way to learn more about genetic algorithms is to try them out yourself. Creating a simple implementation isn't very difficult, and optimizing simple functions will give you an insight in the speed of these algorithms and their ability to find global optima, regardless of the complexity of the function. Learning more about genetic algorithms The newsgroup "comp.ai.genetic" and its FAQ are a good starting point if you want to learn more about genetic algorithms. There are all kinds of free and commercial software packages available, written for different platforms in different languages (C, C++, LISP, Matlab Toolbox, ...). Feel free to contact me if you have any questions about genetic algorithms. I hope you found this article interesting. If there's enough response, I'll write more articles, in which I will discuss various implementations in greater detail. About the author I study Mechanical Engineering at the Delft University of Technology and have designed and implemented a genetic algorithm to optimize designs. This program is called GOOD [1]. The engine itself is written in ANSI C and there's a nice GUI for the Amiga and a text-based portable UI for other platforms. In my spare time, my biggest hobby is the Amiga. I sincerely hope that Amiga Technologies will be able to once again make it a popular platform. The best of luck to them. I'll do my best to contribute to the Amiga community as much as I can. Marcel Offermans e-mail: M.F.Offermans@WbMT.TUDelft.NL @{b}References@{ub} [1] Offermans, M. F., GOOD - Generator Of Optimal Designs, Delft University of Technology, Dept. of Mechanical Engineering and Marine Technology, 1994. [2] Davis, L., Handbook of Genetic Algorithms, New York: Van Nostrand Reinhold, 1991. [3] Goldberg, D. E., Genetic Algorithms in search, optimization, and machine learning, Reading: Addison-Wesley Publishing Corporation, Inc., 1989 [4] Holland, J., Adaptation in Natural and Artificial Systems, Ann Harbor: University of Michican Press, 1975. [5] Michalewicz, Z., Genetic Algorithms + Data Structures = Evolution Programs, Berlin: Springer-Verlag, 1992. _________________________________________________________________ Copyright © 1995 Marcel Offermans, All Rights Reserved. No part of this article may be copied or distributed in electronic or printed publications without prior permission of the author. Permission is hereby granted to the Amiga Report Tech Journal. @endnode @node "Video" "Making videos on Amiga" @{b}Using Three Amiga Computers Simultaneously To Make Music Videos@{ub} @{fg shine}Lee Roskin @{fg text} _________________________________________________________________ I make music videos using an A500, an A1000, an A1200, a Hi8 genlock, a Hi8 video camera and casette recorder at the same time. The productions are like a recorded performance with no overdubbing or editing involved. I have a semi-converted PAL A500 that I use for my music source. I play Mods that I got online and from the Ultimate Mod Collection CD (using EdPlayer) through an Amiga Audio Expander ( from Contraption Industries) and record onto the master Hi8 tape along with the video material. In recent months I have used the A500 to control my CD-Rom drive to play audio CD's (using AsimTunes software). The music that I like to use is Techno and from commercial CD's I like to use what is called Trance. The audio is also connected to a Mind Light 7 device which is connected to the A1200. The A1200 runs the Visual Aurals Music Animation System which is the Mind Light 7 real time audio digitizer and Visual Aurals software from Geodesic Productions, Deluth, GA (404-8220566). The Mind Light 7 captures the incoming music and sends the information to the second mouse port and Visual Aurals turns that into a truly fantastic animated light show that responds to the music. The keyboard of the 1200 controls the parameters of the lightshow which allows almost unlimited modifications of the visual material. The lightshow puts patterns, colors, objects and graphics on the screen which respond to the music and the control of the operator. The Visual Aurals system is about seven years old (now being re-developed by Geodesic) so I have use the 1200 under the Original Chip Set on boot-up. The RGB output of the lightshow is viewed on a monitor and passed onto a SuperGenSX genlock by Digital Creations. The RGB material is mixed with composite video material input from an A1000. The relative amounts of the mixture is controlled by the operator by means of the background and graphics dissolves sliders on the unit. A Live! real time video digitizer is connected to the A1000 which is running software by Invision which controls the colors and special effects of the Live! digitizer. The keyboard of the A1000 activates color maps which I have created and assigned to various keys and a trackball controls such things as color cycling and special effects. The Live! is digitizing in real time video material coming from a video camera. I use a Canon A1 Digial Hi8 Camcorder which is aimed at a video monitor which is showing the composite video output from the genlock. In other words the camera is shooting video feedback which has been modified by the A1000 and mixed with lightshow material from the A1200. This is a little hard to explain with words and to understand. The S-Video output from the genlock is recorded on a Sony Hi8 video casette recorder which is monitored on the monitor which the camera is aimed at. It's a little confusing but when everything is adjusted the effect is quite interesting. There is a video feedback loop that is being modified by the lightshow and the video digitizer. It works. I use several controls on the camera to get the effects I want such as focus, zoom, shutter speed and exposure (I haven't gotten around to "white balance" yet). I have a lot of controls available and the effect is, I think, quite fantastic -- what used to be called "psychedelic" which goes well with the Techno Trance music. I create background graphics for the lightshow (which cycle colors to the music) using Brilliance and ImageMasterRt. I've made many hours of music videos in this manner which I have put on to VHS tape which very few people are interested in but I like to look and listen to them very much. I think the effect would be really fantastic if it were projected on a very big screen at a disco or live music performance. @endnode @node "Survey" "A survey" @{b}The Amiga Report Technical Journal program feature preference survey.@{ub} @{fg shine}Please email filled out replies to artech@warped.com with the subject "User preference survey". Other addresses elsewhere in the magazine.@{fg text} Please choose a value between 1 and 5 according to the importance of the mentioned feature in your opinion. 1 = "not important at all", 5 = "essential". 1. Pretty interface [ ] 2. Command line usage [ ] 3. ARexx interface [ ] 4. Interface in your native language [ ] 5. Detailed documentation [ ] 6. Documentation in your native language [ ] 7. Stability [ ] 8. Low memory usage [ ] 9. No mouse required for full interface control [ ] 10. No mouse required for most important features [ ] 11. Extensive configurability [ ] 12. Many flashy features [ ] 13. Speed [ ] Some background questions. A. Country _________________ B. Where did you find/read ARTech [ ]WWW [ ]Aminet [ ]BBS @endnode @node "Installer2" "Installer guide" @{b}Installer Basics - Starting An Installer Script@{ub} @{fg shine}Robert Reiswig @{fg text} _________________________________________________________________ @{b}Introduction: 2 Much E-Mail@{ub} Due to the amount of E-Mail that I received over the last article I decided to do a second installment. That and the new ARTech editor, Osma Ahvenlampi (Tau on IRC), asked me if I was interested in doing a second article. I received a total of 2 messages... The first message I got was dealing with where to find the installer and more info on it. If you are looking for the installer binary, it is on the OS Install disk that came with your Amiga on the 'Install Disk'. @{b}The people behind Installer@{ub} The only other message I received turned out to be one of the original programmers of the Installer. Of course I had many questions for him. Joe Pearce was very nice in answering my first set of questions that I had left unanswered in the last article. Also he answered a second set of questions I had twice. (My mailbox had problems and he replyed twice!) "I read your 'Installer Basics #1' article and wanted to answer your question of who programmed the Installer. 'Sylvan Technical Arts' was David 'Talin' Joiner's company. (Talin created Faery Tale Adventure, Music-X, etc.) David and I did the bulk of the development of the Installer, with bits and pieces of Commodore-created code added to get things (mostly) right." This is from the follow up set of questions: RR So you and David were the 2 key guys behind the installer stuff? JP Basically, with informal input from a number of people. RR Did Commodore ask you guys to do it? JP David came up with the idea of making a configurable installer after all the problems he had with the installation program for Music-X. Dave mentioned what he was working on to people at Commodore, who thought it was a good idea. RR Did they contract you guys out to do it? JP Yep. RR Do you know the guys at CBM that worked on it? JP The main people were Paul Higginbottom and David Junod (if I remember correctly). RR Do you have a better date when you started and finished the project? JP We started in early 1990. There were actually two Installers. One worked under Kickstart 1.3 and 2.0, and was contracted by CATS. A second version that had extra features, but only worked under 2.0, was contracted by Engineering at CBM. RR What is the diffs between the 115144 byte and 67K installers? JP I think the bigger installer is the 1.3 version, while the 67K version is the 2.0-only version compressed with Imploder. I would like to thank Joe for the above. @{b}Making an Install script@{ub} In the last article I was not sure on how to go about giving examples of the installer. I had suggested picking a program off aminet that did not have an installer and doing a simple installer for it. Jacob Ellis, jacob@nah.oau.org (Jacob on IRC), suggested that I use Play16. Play16 is 'a versatile soundplayer for the Amiga'. If you have not tried Play16, DO! It can be found on aminet as mus/play/Play16_1_5.lha. NOTE: If you do not already have the "Installer" program in your "c:" directory, it would be a good idea to get your Install Disk (the one that comes with the Operating System Disks), and copy the Installer from there to "c:"! At least place it somewhere in your path. [Ed: Some people prefer another directory. When you make an installer script, please do not explicitly set the path of the default tool. Use just plain "Installer".] @{b}PreScript@{ub} The very first thing to do is get an Icon for installer and set the tooltypes to values that are needed. The last Installer Article talked about this. Here is the ones I have set for this example: MINUSER=EXPERT DEFUSER=EXPERT APPNAME=PLAY16 It is recommended that installer be run from the icon, with the stack set at 10000. Running it from the CLI is _not_ recommended, it was added to the installer for debugging scripts. @{b}Asking The Right Questions@{ub} The first thing to do is to look at the archive/program you want to install. Looking at the Play16 archive these are the steps I will take to install the program. 1. Show info on the program that is about to be installed 2. Ask If the user wants 'Play16' 'Docs' or 'CyberSound' installed 3. If the user wants the Docs installed, find out if German or English is wanted. 4. Check and Ask what CPU is installed 5. Ask where to copy stuff 6. Copy over the selected file 7. End For this installment I will go over the Displaying of the Intro message and asking what the user wants to be installed. To 'print' or display information to the installer window you use the 'message' command. An example might look like this: (message "Hello") This will print the word 'Hello' in the top of the window. The installer will center the line for you. For our example here I want to position the words and add double quotes. In order to do this you need to use a few special sequences of characters to do this , so the installer won't get confused. These have the same syntax as 'C'. \\ = backslash \" = double quote \0 = NULL \n = newline \r = return \t = tab The information I want to print is the name of the program and the Authors name and email address. Here is an example: (message "\n\nPlay16 version 1.5\n\nA versatile soundplayer " "for the Amiga\n\n\nby\n\n\nThomas Wenzel\n\n" "wenzel@unixserv.rz.fh-hannover.de") Pay attention to the way several strings are combined to one, and '\n' being used to cut the lines shorter and center them. @{"A picture of how the window should look like" link "IN_About.gif/MAIN" 0} @{"Here is how it would look if you could see the '\n' in the window" link "IN_About2.gif/MAIN" 0} _________________________________________________________________ Now to ask the user what parts of the archive to install. There are 3 parts 'Play16', 'Docs' and 'CyberSound'. To do this you can use the 'askoptions' command. Here is the example: (set Picks (askoptions (prompt "What do you wish to install?") (help "What do you wish to install?") (choices " Play16 - Binary" " Docs - Information" " CyberSound - 14bit Sound" ) (default -1) ) ) There are a few things going on here. First ... when you use 'askoptions' it will give the user as many choices as you give them. In this case 3. What happens is that 'askoptions' returns a bit mask number for the answer. This is a bit like the SCSI ID jumppers on a Hard Drive. Each position or place holder represents a value. Here is an example table: Option # Bit Value -------------------- 1 1 2 2 3 4 4 8 5 16 6 32 In this case the answer/value will be stored in the variable 'Picks'. By using the 'set' command you can store the answer in a variable and then use this information later to make decision. In our example if the user selected all 3 options you can figure out what they selected by looking at what 'askoptions' has returned. With all 3 selceted a 7 will be returned. It takes the bit mask values for all 3 postitions and adds them up: 1 + 2 + 4 = 7 Back to the 'askoptions' options. There are many options you can use with 'askoptions'. I have kept it simple here. Here are explainations of the options I used: (prompt "What do you wish to install?") ; ^This is what is shown at the top of the window, this tells the ; user what to do. (help "What do you wish to install?") ; ^If the user clicks on 'help' this is what they will see. If ; you have time, it would be good to expand on the help section. ; This way the user can click on 'help' and read the section for info ; on what there options are in depth. (choices " Play16 - Binary" " Docs - Information" " CyberSound - 14bit Sound" ) ** OR ** (choices " Play16 - Binary" " Docs - Information" " CyberSound - 14bit Sound") ; ^Note the layout of the 2 examples... both will give the same results! ; You can have as many as will fit in the window. As with all of the ; installer the text must have "'s around them. NOTE: I added a space at ; the front-end of the text, this way the text is not butted up aginst the ; check boxes. (default -1) ; ^This is what the default check boxes/options are pre-set to. A -1 will ; select all the choices and a 0 will select none. If you wish to mix and ; match what is selected (ie option 1 and 3) again it uses bit masked ; values, so if 1 and 3 were to be default it would be set to 1 + 4 = 5 ; (look at the table above) @{"The 'askoptions' should look like this" link "IN_Select.gif/MAIN" 0} So far the script looks like this: (message "\n\nPlay16 version 1.5\n\nA versatile soundplayer " "for the Amiga\n\n\nby\n\n\nThomas Wenzel\n\n" "wenzel@unixserv.rz.fh-hannover.de") (set Picks (askoptions (prompt "What do you wish to install?") (help "What do you wish to install?") (choices " Play16 - Binary" " Docs - Information" " CyberSound - 14bit Sound" ) (default -1) ) ) Well that is about if for now ... hoped you learned something! If you wish to get more detailed information there is an Installer archive in/on the Fred Fish Collection. _________________________________________________________________ This article is ©1995 by Robert Reiswig. If you wish to reprint this (all you have to do is ask) or have any questions please let me know! I can be reached at rcr@netcom.com. @endnode @node "Staff" "Contributors, staff, and contact addresses" @{b}Amiga Report Technical Journal is an FS Publications production.@{ub} @{fg shine}Staff@{fg text} Producing Editor, Osma Ahvenlampi, Osma.Ahvenlampi@hut.fi Supervising Editor, Jason Compton, jcompton@xnet.com, FS Publications. @{fg shine}Contributors to this issue@{fg text} Marcel Offermans, M.F.Offermans@WbMT.TUDelft.NL Lee Roskin, krish@cup.portal.com Robert Reiswig, rcr@netcom.com @{fg shine}Contact addresses@{fg text} Email: artech@warped.com Snail mail: ARTech c/o Osma Ahvenlampi Rekipellontie 2 F 55 00940 Helsinki Finland @endnode