Saturday, January 5, 2008

Linux Phone Standards (LiPS)

Targets interoperability & marketability of Linux-based mobile phones through shared open standards and implementations
SOPHIA ANTIPOLIS, FRANCE, December 10, 2007—The Linux Phone Standards (LiPS) Forum today announced completion of the LiPS Release 1.0 specifications, fulfilling the

commitment announced in June of this year. With this release, LiPS enables mobile industry players to achieve basic interoperability for applications and services deployed on Linux-based phones, benefiting Linux-based software stack suppliers, mobile device OEMs and regional and global telecom operators. These specifications include the LiPS Reference Model, Telephony, Messaging, Calendaring and Scheduling, Presence, User Interface Services, Address Book and Voice Call Enablers APIs.
In contrast to recent announcements from other bodies promoting Linux-based mobile software, LiPS output targets interoperability through real open standards and specifications, not de facto acceptance of a single platform implementation. The completed open specifications are publicly available on the LiPS web site at
From Open Standards to Standards-based Phones
The principal advantage to real open standards comes from choice of implementation. As with all formal standards, the challenge lies in moving from “paper standards” to creating code and actual devices. To that end, LiPS Forum members are already building software and equipment that follow the LiPS specifications. LiPS members and their peers across the mobile ecosystem have the choice of creating their own versions of LiPS-compliant code, of licensing implementations from other LiPS members or third parties, or of leveraging and contributing to open source implementations. “Standards-based interoperability is crucial to the success of the global telecommunications marketplace,” declared Haila Wang, president of the LiPS Forum. “LiPS is following the clear path blazed by GSM, TCP/IP, WiFi and other standards that enable communications among device types and brands, over multiple operator networks and across regional markets.”
Delivering on Industry Commitments
“The completion and delivery of the LiPS 1.0 Specification illustrates the power of cooperation among industry leaders,” noted Haila Wang. “LiPS Forum owes a debt of gratitude to Architecture Working Group members, and especially to chair Guilhem Ensuque of Open-Plug”. Having completed its commitments for 2007, LiPS Forum is setting its sights on additional specification work in 2008. Planned for release are the Application Framework, advanced Services APIs, Device Management APIs and additional Enabler APIs (e.g., for multimedia).
About LiPS Forum
The Linux Phone Standards (LiPS) Forum is a consortium of leading industry players formed to standardize the Linux-based services and Application Programming Interfaces (APIs) that most directly influence the development, deployment and interoperability of applications and user-level services.
LiPS Forum was founded in November, 2005 to help accelerate the adoption of Linux in fixed, mobile and converged devices. By standardizing Linux-based services and Application Programming Interfaces (APIs) that influence the development, deployment and interoperability of applications as well as end-user services, device manufacturers, third party software vendors and operators can increasingly differentiate their offerings from competitors and generate revenue. The LiPS Forum now comprises 20 companies from across the mobile industry ecosystem and around the world.
The founding members of the LiPS Forum are ACCESS, ARM, Cellon International, Esmertec, France Telecom, Orange, Huawei Technologies, MIZI Research, Inc., MontaVista Software, Inc., Open-Plug and VirtualLogix

Press Releases
Linux Phone Standards (LiPS) Forum Completes Release of 1.0 Specifications

BT Joins LiPS to Foster Interoperability

Linux Phone Standards Forum and Open Mobile Alliance Create Standardization Liaison

Linux Phone Standards (LiPS) Forum Recruits Industry Veteran Bill Weinberg

Linux Phone Standards (LiPS) Forum Releases Specifications and Roadmap through 2008

OSDL and LiPS coordinate efforts to accelerate Mobile Linux Deployments and LiPS coordinate efforts.pdf

LiPS Gains Momentum gains momentum.pdf

LiPS Launch Release

Tutorial on MIDI and Music Synthesis

The Musical Instrument Digital Interface (MIDI) protocol has been widely accepted and utilized by musicians and composers since its conception in the 1982/1983 time frame. MIDI data is a very efficient method of representing musical performance information, and this makes MIDI an attractive protocol not only for composers or performers, but also for computer applications which produce sound, such as multimedia presentations or computer games. However, the lack of standardization of synthesizer capabilities hindered applications developers and presented new MIDI users with a rather steep learning curve to overcome.

Fortunately, thanks to the publication of the General MIDI System specification, wide acceptance of the most common PC/MIDI interfaces, support for MIDI in Microsoft WINDOWS and other operating systems, and the evolution of low-cost music synthesizers, the MIDI protocol is now seeing widespread use in a growing number of applications. This document is an overview of the standards, practices and terminology associated with the generation of sound using the MIDI protocol.
MIDI vs. Digitized AudioOriginally developed to allow musicians to connect synthesizers together, the MIDI protocol is now finding widespread use as a delivery medium to replace or supplement digitized audio in games and multimedia applications. There are several advantages to generating sound with a MIDI synthesizer rather than using sampled audio from disk or CD-ROM. The first advantage is storage space. Data files used to store digitally sampled audio in PCM format (such as .WAV files) tend to be quite large. This is especially true for lengthy musical pieces captured in stereo using high sampling rates.
MIDI data files, on the other hand, are extremely small when compared with sampled audio files. For instance, files containing high quality stereo sampled audio require about 10 Mbytes of data per minute of sound, while a typical MIDI sequence might consume less than 10 Kbytes of data per minute of sound. This is because the MIDI file does not contain the sampled audio data, it contains only the instructions needed by a synthesizer to play the sounds. These instructions are in the form of MIDI messages, which instruct the synthesizer which sounds to use, which notes to play, and how loud to play each note. The actual sounds are then generated by the synthesizer.
For computers, the smaller file size also means that less of the PCs bandwidth is utilized in spooling this data out to the peripheral which is generating sound. Other advantages of utilizing MIDI to generate sounds include the ability to easily edit the music, and the ability to change the playback speed and the pitch or key of the sounds independently. This last point is particularly important in synthesis applications such as karaoke equipment, where the musical key and tempo of a song may be selected by the user.
MIDI BasicsThe Musical Instrument Digital Interface (MIDI) protocol provides a standardized and efficient means of conveying musical performance information as electronic data. MIDI information is transmitted in "MIDI messages", which can be thought of as instructions which tell a music synthesizer how to play a piece of music. The synthesizer receiving the MIDI data must generate the actual sounds. The MIDI 1.0 Detailed Specification provides a complete description of the MIDI protocol.
The MIDI data stream is a unidirectional asynchronous bit stream at 31.25 Kbits/sec. with 10 bits transmitted per byte (a start bit, 8 data bits, and one stop bit). The MIDI interface on a MIDI instrument will generally include three different MIDI connectors, labeled IN, OUT, and THRU. The MIDI data stream is usually originated by a MIDI controller, such as a musical instrument keyboard, or by a MIDI sequencer. A MIDI controller is a device which is played as an instrument, and it translates the performance into a MIDI data stream in real time (as it is played). A MIDI sequencer is a device which allows MIDI data sequences to be captured, stored, edited, combined, and replayed. The MIDI data output from a MIDI controller or sequencer is transmitted via the devices' MIDI OUT connector.
The recipient of this MIDI data stream is commonly a MIDI sound generator or sound module, which will receive MIDI messages at its MIDI IN connector, and respond to these messages by playing sounds. Figure 1 shows a simple MIDI system, consisting of a MIDI keyboard controller and a MIDI sound module. Note that many MIDI keyboard instruments include both the keyboard controller and the MIDI sound module functions within the same unit. In these units, there is an internal link between the keyboard and the sound module which may be enabled or disabled by setting the "local control" function of the instrument to ON or OFF respectively.
The single physical MIDI Channel is divided into 16 logical channels by the inclusion of a 4 bit Channel number within many of the MIDI messages. A musical instrument keyboard can generally be set to transmit on any one of the sixteen MIDI channels. A MIDI sound source, or sound module, can be set to receive on specific MIDI Channel(s). In the system depicted in Figure 1, the sound module would have to be set to receive the Channel which the keyboard controller is transmitting on in order to play sounds.
Figure 1: A Simple MIDI System

Information received on the MIDI IN connector of a MIDI device is transmitted back out (repeated) at the devices' MIDI THRU connector. Several MIDI sound modules can be daisy-chained by connecting the THRU output of one device to the IN connector of the next device downstream in the chain.

Figure 2 shows a more elaborate MIDI system. In this case, a MIDI keyboard controller is used as an input device to a MIDI sequencer, and there are several sound modules connected to the sequencer's MIDI OUT port. A composer might utilize a system like this to write a piece of music consisting of several different parts, where each part is written for a different instrument. The composer would play the individual parts on the keyboard one at a time, and these individual parts would be captured by the sequencer. The sequencer would then play the parts back together through the sound modules. Each part would be played on a different MIDI Channel, and the sound modules would be set to receive different channels. For example, Sound module number 1 might be set to play the part received on Channel 1 using a piano sound, while module 2 plays the information received on Channel 5 using an acoustic bass sound, and the drum machine plays the percussion part received on MIDI Channel 10.
Figure 2: An Expanded MIDI System

In this example, a different sound module is used to play each part. However, sound modules which are "multitimbral" are capable of playing several different parts simultaneously. A single multitimbral sound module might be configured to receive the piano part on Channel 1, the bass part on Channel 5, and the drum part on Channel 10, and would play all three parts simultaneously.

Figure 3 depicts a PC-based MIDI system. In this system, the PC is equipped with an internal MIDI interface card which sends MIDI data to an external multitimbral MIDI synthesizer module. Application software, such as Multimedia presentation packages, educational software, or games, sends MIDI data to the MIDI interface card in parallel form over the PC bus. The MIDI interface converts this information into serial MIDI data which is sent to the sound module. Since this is a multitimbral module, it can play many different musical parts, such as piano, bass and drums, at the same time. Sophisticated MIDI sequencer software packages are also available for the PC. With this software running on the PC, a user could connect a MIDI keyboard controller to the MIDI IN port of the MIDI interface card, and have the same music composition capabilities discussed in the last two paragraphs.

There are a number of different configurations of PC-based MIDI systems possible. For instance, the MIDI interface and the MIDI sound module might be combined on the PC add-in card. In fact, the Multimedia PC (MPC) Specification requires that all MPC systems include a music synthesizer, and the synthesizer is normally included on the audio adapter card (the "sound card") along with the MIDI interface function. Until recently, most PC sound cards included FM synthesizers with limited capabilities and marginal sound quality. With these systems, an external wavetable synthesizer module might be added to get better sound quality. Recently, more advanced sound cards have been appearing which include high quality wavetable music synthesizers on-board, or as a daughter-card options. With the increasing use of the MIDI protocol in PC applications, this trend is sure to continue.
Figure 3: A PC-Based MIDI System

MIDI Messages
A MIDI message is made up of an eight-bit status byte which is generally followed by one or two data bytes. There are a number of different types of MIDI messages. At the highest level, MIDI messages are classified as being either Channel Messages or System Messages. Channel messages are those which apply to a specific Channel, and the Channel number is included in the status byte for these messages. System messages are not Channel specific, and no Channel number is indicated in their status bytes.
Channel Messages may be further classified as being either Channel Voice Messages, or Mode Messages. Channel Voice Messages carry musical performance data, and these messages comprise most of the traffic in a typical MIDI data stream. Channel Mode messages affect the way a receiving instrument will respond to the Channel Voice messages.

Channel Voice Messages
Channel Voice Messages are used to send musical performance information. The messages in this category are the Note On, Note Off, Polyphonic Key Pressure, Channel Pressure, Pitch Bend Change, Program Change, and the Control Change messages.

Note On / Note Off / Velocity
In MIDI systems, the activation of a particular note and the release of the same note are considered as two separate events. When a key is pressed on a MIDI keyboard instrument or MIDI keyboard controller, the keyboard sends a Note On message on the MIDI OUT port. The keyboard may be set to transmit on any one of the sixteen logical MIDI channels, and the status byte for the Note On message will indicate the selected Channel number. The Note On status byte is followed by two data bytes, which specify key number (indicating which key was pressed) and velocity (how hard the key was pressed).
The key number is used in the receiving synthesizer to select which note should be played, and the velocity is normally used to control the amplitude of the note. When the key is released, the keyboard instrument or controller will send a Note Off message. The Note Off message also includes data bytes for the key number and for the velocity with which the key was released. The Note Off velocity information is normally ignored.

Some MIDI keyboard instruments have the ability to sense the amount of pressure which is being applied to the keys while they are depressed. This pressure information, commonly called "aftertouch", may be used to control some aspects of the sound produced by the synthesizer (vibrato, for example). If the keyboard has a pressure sensor for each key, then the resulting "polyphonic aftertouch" information would be sent in the form of Polyphonic Key Pressure messages. These messages include separate data bytes for key number and pressure amount. It is currently more common for keyboard instruments to sense only a single pressure level for the entire keyboard. This "Channel aftertouch" information is sent using the Channel Pressure message, which needs only one data byte to specify the pressure value.

Pitch Bend
The Pitch Bend Change message is normally sent from a keyboard instrument in response to changes in position of the pitch bend wheel. The pitch bend information is used to modify the pitch of sounds being played on a given Channel. The Pitch Bend message includes two data bytes to specify the pitch bend value. Two bytes are required to allow fine enough resolution to make pitch changes resulting from movement of the pitch bend wheel seem to occur in a continuous manner rather than in steps.

Program Change
The Program Change message is used to specify the type of instrument which should be used to play sounds on a given Channel. This message needs only one data byte which specifies the new program number.

Control Change
MIDI Control Change messages are used to control a wide variety of functions in a synthesizer. Control Change messages, like other MIDI Channel messages, should only affect the Channel number indicated in the status byte. The Control Change status byte is followed by one data byte indicating the "controller number", and a second byte which specifies the "control value". The controller number identifies which function of the synthesizer is to be controlled by the message. A complete list of assigned controllers is found in the MIDI 1.0 Detailed Specification.

- Bank Select
Controller number zero (with 32 as the LSB) is defined as the bank select. The bank select function is used in some synthesizers in conjunction with the MIDI Program Change message to expand the number of different instrument sounds which may be specified (the Program Change message alone allows selection of one of 128 possible program numbers). The additional sounds are selected by preceding the Program Change message with a Control Change message which specifies a new value for Controller zero and Controller 32, allowing 16,384 banks of 128 sound each.
Since the MIDI specification does not describe the manner in which a synthesizer's banks are to be mapped to Bank Select messages, there is no standard way for a Bank Select message to select a specific synthesizer bank. Some manufacturers, such as Roland (with "GS") and Yamaha (with "XG") , have adopted their own practices to assure some standardization within their own product lines.

Controller number 6 (Data Entry), in conjunction with Controller numbers 96 (Data Increment), 97 (Data Decrement), 98 (Registered Parameter Number LSB), 99 (Registered Parameter Number MSB), 100 (Non-Registered Parameter Number LSB), and 101 (Non-Registered Parameter Number MSB), extend the number of controllers available via MIDI. Parameter data is transferred by first selecting the parameter number to be edited using controllers 98 and 99 or 100 and 101, and then adjusting the data value for that parameter using controller number 6, 96, or 97.
RPN and NRPN are typically used to send parameter data to a synthesizer in order to edit sound patches or other data. Registered parameters are those which have been assigned some particular function by the MIDI Manufacturers Association (MMA) and the Japan MIDI Standards Committee (JMSC). For example, there are Registered Parameter numbers assigned to control pitch bend sensitivity and master tuning for a synthesizer. Non-Registered parameters have not been assigned specific functions, and may be used for different functions by different manufacturers. Here again, Roland and Yamaha, among others, have adopted their own practices to assure some standardization.

Channel Mode Messages
Channel Mode messages (MIDI controller numbers 121 through 127) affect the way a synthesizer responds to MIDI data. Controller number 121 is used to reset all controllers. Controller number 122 is used to enable or disable Local Control (In a MIDI synthesizer which has it's own keyboard, the functions of the keyboard controller and the synthesizer can be isolated by turning Local Control off). Controller numbers 124 through 127 are used to select between Omni Mode On or Off, and to select between the Mono Mode or Poly Mode of operation.
When Omni mode is On, the synthesizer will respond to incoming MIDI data on all channels. When Omni mode is Off, the synthesizer will only respond to MIDI messages on one Channel. When Poly mode is selected, incoming Note On messages are played polyphonically. This means that when multiple Note On messages are received, each note is assigned its own voice (subject to the number of voices available in the synthesizer). The result is that multiple notes are played at the same time. When Mono mode is selected, a single voice is assigned per MIDI Channel. This means that only one note can be played on a given Channel at a given time. Most modern MIDI synthesizers will default to Omni On/Poly mode of operation. In this mode, the synthesizer will play note messages received on any MIDI Channel, and notes received on each Channel are played polyphonically. In the Omni Off/Poly mode of operation, the synthesizer will receive on a single Channel and play the notes received on this Channel polyphonically. This mode could be useful when several synthesizers are daisy-chained using MIDI THRU. In this case each synthesizer in the chain can be set to play one part (the MIDI data on one Channel), and ignore the information related to the other parts.
Note that a MIDI instrument has one MIDI Channel which is designated as its "Basic Channel". The Basic Channel assignment may be hard-wired, or it may be selectable. Mode messages can only be received by an instrument on the Basic Channel.

System Messages
MIDI System Messages are classified as being System Common Messages, System Real Time Messages, or System Exclusive Messages. System Common messages are intended for all receivers in the system. System Real Time messages are used for synchronization between clock-based MIDI components. System Exclusive messages include a Manufacturer's Identification (ID) code, and are used to transfer any number of data bytes in a format specified by the referenced manufacturer.

System Common Messages
The System Common Messages which are currently defined include MTC Quarter Frame, Song Select, Song Position Pointer, Tune Request, and End Of Exclusive (EOX). The MTC Quarter Frame message is part of the MIDI Time Code information used for synchronization of MIDI equipment and other equipment, such as audio or video tape machines.
The Song Select message is used with MIDI equipment, such as sequencers or drum machines, which can store and recall a number of different songs. The Song Position Pointer is used to set a sequencer to start playback of a song at some point other than at the beginning. The Song Position Pointer value is related to the number of MIDI clocks which would have elapsed between the beginning of the song and the desired point in the song. This message can only be used with equipment which recognizes MIDI System Real Time Messages (MIDI Sync).
The Tune Request message is generally used to request an analog synthesizer to retune its' internal oscillators. This message is generally not needed with digital synthesizers.The EOX message is used to flag the end of a System Exclusive message, which can include a variable number of data bytes.

System Real Time Messages
The MIDI System Real Time messages are used to synchronize all of the MIDI clock-based equipment within a system, such as sequencers and drum machines. Most of the System Real Time messages are normally ignored by keyboard instruments and synthesizers. To help ensure accurate timing, System Real Time messages are given priority over other messages, and these single-byte messages may occur anywhere in the data stream (a Real Time message may appear between the status byte and data byte of some other MIDI message).
The System Real Time messages are the Timing Clock, Start, Continue, Stop, Active Sensing, and the System Reset message. The Timing Clock message is the master clock which sets the tempo for playback of a sequence. The Timing Clock message is sent 24 times per quarter note. The Start, Continue, and Stop messages are used to control playback of the sequence.
The Active Sensing signal is used to help eliminate "stuck notes" which may occur if a MIDI cable is disconnected during playback of a MIDI sequence. Without Active Sensing, if a cable is disconnected during playback, then some notes may be left playing indefinitely because they have been activated by a Note On message, but the corresponding Note Off message will never be received.
The System Reset message, as the name implies, is used to reset and initialize any equipment which receives the message. This message is generally not sent automatically by transmitting devices, and must be initiated manually by a user.

System Exclusive Messages
System Exclusive messages may be used to send data such as patch parameters or sample data between MIDI devices. Manufacturers of MIDI equipment may define their own formats for System Exclusive data. Manufacturers are granted unique identification (ID) numbers by the MMA or the JMSC, and the manufacturer ID number is included as part of the System Exclusive message. The manufacturers ID is followed by any number of data bytes, and the data transmission is terminated with the EOX message. Manufacturers are required to publish the details of their System Exclusive data formats, and other manufacturers may freely utilize these formats, provided that they do not alter or utilize the format in a way which conflicts with the original manufacturers specifications.
Certain System Exclusive ID numbers are reserved for special protocols. Among these are the MIDI Sample Dump Standard, which is a System Exclusive data format defined in the MIDI specification for the transmission of sample data between MIDI devices, as well as MIDI Show Control and MIDI Machine Control.

Running Status
Since MIDI data is transmitted serially, it is possible that musical events which originally occurred at the same time and must be sent one at a time in the MIDI data stream may not actually be played at exactly the same time. With a data transmission rate of 31.25 Kbit/s and 10 bits transmitted per byte of MIDI data, a 3-byte Note On or Note Off message takes about 1 ms to be sent, which is generally short enough that the events are perceived as having occurred simultaneously. In fact, for a person playing a MIDI instrument keyboard, the time skew between playback of notes when 10 keys are pressed simultaneously should not exceed 10 ms, and this would not be perceptible.
However, MIDI data being sent from a sequencer can include a number of different parts. On a given beat, there may be a large number of musical events which should occur simultaneously, and the delays introduced by serialization of this information might be noticeable. To help reduce the amount of data transmitted in the MIDI data stream, a technique called "running status" may be employed.
Running status considers the fact that it is very common for a string of consecutive messages to be of the same message type. For instance, when a chord is played on a keyboard, 10 successive Note On messages may be generated, followed by 10 Note Off messages. When running status is used, a status byte is sent for a message only when the message is not of the same type as the last message sent on the same Channel. The status byte for subsequent messages of the same type may be omitted (only the data bytes are sent for these subsequent messages).
The effectiveness of running status can be enhanced by sending Note On messages with a velocity of zero in place of Note Off messages. In this case, long strings of Note On messages will often occur. Changes in some of the MIDI controllers or movement of the pitch bend wheel on a musical instrument can produce a staggering number of MIDI Channel voice messages, and running status can also help a great deal in these instances.

MIDI Sequencers and Standard MIDI Files
MIDI messages are received and processed by a MIDI synthesizer in real time. When the synthesizer receives a MIDI "note on" message it plays the appropriate sound. When the corresponding "note off" message is received, the synthesizer turns the note off. If the source of the MIDI data is a musical instrument keyboard, then this data is being generated in real time. When a key is pressed on the keyboard, a "note on" message is generated in real time. In these real time applications, there is no need for timing information to be sent along with the MIDI messages.
However, if the MIDI data is to be stored as a data file, and/or edited using a sequencer, then some form of "time-stamping" for the MIDI messages is required. The Standard MIDI Files specification provides a standardized method for handling time-stamped MIDI data. This standardized file format for time-stamped MIDI data allows different applications, such as sequencers, scoring packages, and multimedia presentation software, to share MIDI data files.
The specification for Standard MIDI Files defines three formats for MIDI files. MIDI sequencers can generally manage multiple MIDI data streams, or "tracks". Standard MIDI files using Format 0 store all of the MIDI sequence data in a single track. Format 1 files store MIDI data as a collection of tracks. Format 2 files can store several independent patterns. Format 2 is generally not used by MIDI sequencers for musical applications. Most sophisticated MIDI sequencers can read either Format 0 or Format 1 Standard MIDI Files. Format 0 files may be smaller, and thus conserve storage space. They may also be transferred using slightly less system bandwidth than Format 1 files. However, Format 1 files may be viewed and edited more directly, and are therefore generally preferred.

Synthesizer Basics
The polyphony of a sound generator refers to its ability to play more than one note at a time. Polyphony is generally measured or specified as a number of notes or voices. Most of the early music synthesizers were monophonic, meaning that they could only play one note at a time. If you pressed five keys simultaneously on the keyboard of a monophonic synthesizer, you would only hear one note. Pressing five keys on the keyboard of a synthesizer which was polyphonic with four voices of polyphony would, in general, produce four notes. If the keyboard had more voices (many modern sound modules have 16, 24, or 32 note polyphony), then you would hear all five of the notes.

The different sounds that a synthesizer or sound generator can produce are sometimes called "patches", "programs", "algorithms", or "timbres". Programmable synthesizers commonly assign "program numbers" (or patch numbers) to each sound. For instance, a sound module might use patch number 1 for its acoustic piano sound, and patch number 36 for its fretless bass sound. The association of all patch numbers to all sounds is often referred to as a patch map.
Via MIDI, a Program Change message is used to tell a device receiving on a given Channel to change the instrument sound being used. For example, a sequencer could set up devices on Channel 4 to play fretless bass sounds by sending a Program Change message for Channel four with a data byte value of 36 (this is the General MIDI program number for the fretless bass patch).
Multitimbral Mode
A synthesizer or sound generator is said to be multitimbral if it is capable of producing two or more different instrument sounds simultaneously. If a synthesizer can play five notes simultaneously, and it can produce a piano sound and an acoustic bass sound at the same time, then it is multitimbral. With enough notes of polyphony and "parts" (multitimbral) a single synthesizer could produce the entire sound of a band or orchestra.
Multitimbral operation will generally require the use of a sequencer to send the various MIDI messages required. For example, a sequencer could send MIDI messages for a piano part on Channel 1, bass on Channel 2, saxophone on Channel 3, drums on Channel 10, etc. A 16 part multitimbral synthesizer could receive a different part on each of MIDI's 16 logical channels.
The polyphony of a multitimbral synthesizer is usually allocated dynamically among the different parts (timbres) being used. At any given instant five voices might be needed for the piano part, two voices for the bass, one for the saxophone, plus 6 voices for the drums. Note that some sounds on some synthesizers actually utilize more than one "voice", so the number of notes which may be produced simultaneously may be less than the stated polyphony of the synthesizer, depending on which sounds are being utilized.

The General MIDI (GM) System
At the beginning of a MIDI sequence, a Program Change message is usually sent on each Channel used in the piece in order to set up the appropriate instrument sound for each part. The Program Change message tells the synthesizer which patch number should be used for a particular MIDI Channel. If the synthesizer receiving the MIDI sequence uses the same patch map (the assignment of patch numbers to sounds) that was used in the composition of the sequence, then the sounds will be assigned as intended.Prior to General MIDI, there was no standard for the relationship of patch numbers to specific sounds for synthesizers. Thus, a MIDI sequence might produce different sounds when played on different synthesizers, even though the synthesizers had comparable types of sounds. For example, if the composer had selected patch number 5 for Channel 1, intending this to be an electric piano sound, but the synthesizer playing the MIDI data had a tuba sound mapped at patch number 5, then the notes intended for the piano would be played on the tuba when using this synthesizer (even though this synthesizer may have a fine electric piano sound available at some other patch number).
The General MIDI (GM) Specification defines a set of general capabilities for General MIDI Instruments. The General MIDI Specification includes the definition of a General MIDI Sound Set (a patch map), a General MIDI Percussion map (mapping of percussion sounds to note numbers), and a set of General MIDI Performance capabilities (number of voices, types of MIDI messages recognized, etc.). A MIDI sequence which has been generated for use on a General MIDI Instrument should play correctly on any General MIDI synthesizer or sound module.
The General MIDI system utilizes MIDI Channels 1-9 and 11-16 for chromatic instrument sounds, while Channel number 10 is utilized for "key-based" percussion sounds. These instrument sounds are grouped into "sets" of related sounds. For example, program numbers 1-8 are piano sounds, 9-16 are chromatic percussion sounds, 17-24 are organ sounds, 25-32 are guitar sounds, etc.
For the instrument sounds on channels 1-9 and 11-16, the note number in a Note On message is used to select the pitch of the sound which will be played. For example if the Vibraphone instrument (program number 12) has been selected on Channel 3, then playing note number 60 on Channel 3 would play the middle C note (this would be the default note to pitch assignment on most instruments), and note number 59 on Channel 3 would play B below middle C. Both notes would be played using the Vibraphone sound.
The General MIDI percussion sounds are set on Channel 10. For these "key-based" sounds, the note number data in a Note On message is used differently. Note numbers on Channel 10 are used to select which drum sound will be played. For example, a Note On message on Channel 10 with note number 60 will play a Hi Bongo drum sound. Note number 59 on Channel 10 will play the Ride Cymbal 2 sound.
It should be noted that the General MIDI system specifies sounds using program numbers 1 through 128. The MIDI Program Change message used to select these sounds uses an 8-bit byte, which corresponds to decimal numbering from 0 through 127, to specify the desired program number. Thus, to select GM sound number 10, the Glockenspiel, the Program Change message will have a data byte with the decimal value 9.
The General MIDI system specifies which instrument or sound corresponds with each program/patch number, but General MIDI does not specify how these sounds are produced. Thus, program number 1 should select the Acoustic Grand Piano sound on any General MIDI instrument. However, the Acoustic Grand Piano sound on two General MIDI synthesizers which use different synthesis techniques may sound quite different.

Synthesis Technology: FM and Wavetable
There are a number of different technologies or algorithms used to create sounds in music synthesizers. Two widely used techniques are Frequency Modulation (FM) synthesis and Wavetable synthesis.
FM synthesis techniques generally use one periodic signal (the modulator) to modulate the frequency of another signal (the carrier). If the modulating signal is in the audible range, then the result will be a significant change in the timbre of the carrier signal. Each FM voice requires a minimum of two signal generators. These generators are commonly referred to as "operators", and different FM synthesis implementations have varying degrees of control over the operator parameters.
Sophisticated FM systems may use 4 or 6 operators per voice, and the operators may have adjustable envelopes which allow adjustment of the attack and decay rates of the signal. Although FM systems were implemented in the analog domain on early synthesizer keyboards, modern FM synthesis implementations are done digitally.
FM synthesis techniques are very useful for creating expressive new synthesized sounds. However, if the goal of the synthesis system is to recreate the sound of some existing instrument, this can generally be done more accurately with digital sample-based techniques.
Digital sampling systems store high quality sound samples digitally, and then replay these sounds on demand. Digital sample-based synthesis systems may employ a variety of special techniques, such as sample looping, pitch shifting, mathematical interpolation, and digital filtering, in order to reduce the amount of memory required to store the sound samples (or to get more types of sounds from a given amount of memory). These sample-based synthesis systems are often called "wavetable" synthesizers (the sample memory in these systems contains a large number of sampled sound segments, and can be thought of as a "table" of sound waveforms which may be looked up and utilized when needed).

Wavetable Synthesis Techniques
The majority of professional synthesizers available today use some form of sampled-sound or Wavetable synthesis. The trend for multimedia sound products is also towards wavetable synthesis. To help prospective MIDI developers, a number of the techniques employed in this type of synthesis are discussed in the following paragraphs.

Looping and Envelope Generation
One of the primary techniques used in wavetable synthesizers to conserve sample memory space is the looping of sampled sound segments. For many instrument sounds, the sound can be modeled as consisting of two major sections: the attack section and the sustain section. The attack section is the initial part of the sound, where the amplitude and the spectral characteristics of the sound may be changing very rapidly. The sustain section of the sound is that part of the sound following the attack, where the characteristics of the sound are changing less dynamically.
Figure 4 shows a waveform with portions which could be considered the attack and the sustain sections indicated. In this example, the spectral characteristics of the waveform remain constant throughout the sustain section, while the amplitude is decreasing at a fairly constant rate. This is an exaggerated example, in most natural instrument sounds, both the spectral characteristics and the amplitude continue to change through the duration of the sound. The sustain section, if one can be identified, is that section for which the characteristics of the sound are relatively constant.

Figure 4: Attack and Sustain Portions of a Waveform

Figure 5: Looping of a Sample Segment

A great deal of memory can be saved in wavetable synthesis systems by storing only a short segment of the sustain section of the waveform, and then looping this segment during playback. Figure 5 shows a two period segment of the sustain section from the waveform in Figure 4, which has been looped to create a steady state signal. If the original sound had a fairly constant spectral content and amplitude during the sustained section, then the sound resulting from this looping operation should be a good approximation of the sustained section of the original.
For many acoustic string instruments, the spectral characteristics of the sound remain fairly constant during the sustain section, while the amplitude of the signal decays. This can be simulated with a looped segment by multiplying the looped samples by a decreasing gain factor during playback to get the desired shape or envelope. The amplitude envelope of a sound is commonly modeled as consisting of some number of linear segments. An example is the commonly used four part piecewise-linear Attack-Decay-Sustain-Release (ADSR) envelope model. Figure 6 depicts a typical ADSR envelope shape, and Figure 7 shows the result of applying this envelope to the looped waveform from Figure 5.

Figure 6: A Typical ADSR Amplitude Envelope

Figure 7: ADSR Envelope Applied to a Looped Sample Segment

A typical wavetable synthesis system would store sample data for the attack section and the looped section of an instrument sound. These sample segments might be referred to as the initial sound and the loop sound. The initial sound is played once through, and then the loop sound is played repetitively until the note ends. An envelope generator function is used to create an envelope which is appropriate for the particular instrument, and this envelope is applied to the output samples during playback.
Playback of the initial wave (with the attack portion of the envelope applied) begins when a Note On message is received. The length of the initial sound segment is fixed by the number of samples in the segment, and the length of the attack and decay sections of the envelope are generally also fixed for a given instrument sound.
The sustain section will continue to repeat the loop samples while applying the sustain envelope slope (which decays slowly in our examples), until a Note Off message is applied. The Note Off message triggers the beginning of the release portion of the envelope.

Loop Length
The loop length is measured as a number of samples, and the length of the loop should be equal to an integral number of periods of the fundamental pitch of the sound being played (if this is not true, then an undesirable "pitch shift" will occur during playback when the looping begins). In practice, the length of the loop segment for an acoustic instrument sample may be many periods with respect to the fundamental pitch of the sound. If the sound has a natural vibrato or chorus effect, then it is generally desirable to have the loop segment length be an integral multiple of the period of the vibrato or chorus.

One-Shot Sounds
The previous paragraphs discussed dividing a sampled sound into an attack section and a sustain section, and then using looping techniques to minimize the storage requirements for the sustain portion. However, some sounds, particularly sounds of short duration or sounds whose characteristics change dynamically throughout their duration, are not suitable for looped playback techniques. Short drum sounds often fit this description. These sounds are stored as a single sample segment which is played once through with no looping. This class of sounds are referred to as "one-shot" sounds.

Sample Editing and Processing
There are a number of sample editing and processing steps involved in preparing sampled sounds for use in a wavetable synthesis system. The requirements for editing the original sample data to identify and extract the initial and loop segments have already been mentioned.
Editing may also be required to make the endpoints of the loop segment compatible. If the amplitude and the slope of the waveform at the beginning of the loop segment do not match those at the end of the loop, then a repetitive "glitch" will be heard during playback of the looped section. Additional processing may be performed to "compress" the dynamic range of the sound to improve the signal/quantizing noise ratio or to conserve sample memory. This topic is addressed next.
When all of the sample processing has been completed, the resulting sampled sound segments for the various instruments are tabulated to form the sample memory for the synthesizer.

Sample Data Compression
The signal-to-quantizing noise ratio for a digitally sampled signal is limited by sample word size (the number of bits per sample), and by the amplitude of the digitized signal. Most acoustic instrument sounds reach their peak amplitude very quickly, and the amplitude then slowly decays from this peak. The ear's sensitivity dynamically adjusts to signal level. Even in systems utilizing a relatively small sample word size, the quantizing noise level is generally not perceptible when the signal is near maximum amplitude. However, as the signal level decays, the ear becomes more sensitive, and the noise level will appear to increase. Of course, using a larger word size will reduce the quantizing noise, but there is a considerable price penalty paid if the number of samples is large.
Compression techniques may be used to improve the signal-to-quantizing noise ratio for some sampled sounds. These techniques reduce the dynamic range of the sound samples stored in the sample memory. The sample data is decompressed during playback to restore the dynamic range of the signal. This allows the use of sample memory with a smaller word size (smaller dynamic range) than is utilized in the rest of the system. There are a number of different compression techniques which may be used to compress the dynamic range of a signal.
Note that there is some compression effect inherent in the looping techniques described earlier. If the loop segment is stored at an amplitude level which makes full use of the dynamic range available in the sample memory, and the processor and D/A converters used for playback have a wider dynamic range than the sample memory, then the application of a decay envelope during playback will have a decompression effect similar to that described in the previous paragraph.

Pitch Shifting
In order to minimize sample memory requirements, wavetable synthesis systems utilize pitch shifting, or pitch transposition techniques, to generate a number of different notes from a single sound sample of a given instrument. For example, if the sample memory contains a sample of a middle C note on the acoustic piano, then this same sample data could be used to generate the C# note or D note above middle C using pitch shifting.
Pitch shifting is accomplished by accessing the stored sample data at different rates during playback. For example, if a pointer is used to address the sample memory for a sound, and the pointer is incremented by one after each access, then the samples for this sound would be accessed sequentially, resulting in some particular pitch. If the pointer increment was two rather than one, then only every second sample would be played, and the resulting pitch would be shifted up by one octave (the frequency would be doubled).
In the previous example, the sample memory address pointer was incremented by an integer number of samples. This allows only a limited set of pitch shifts. In a more general case, the memory pointer would consist of an integer part and a fractional part, and the increment value could be a fractional number of samples. The memory pointer is often referred to as a "phase accumulator" and the increment value is then the "phase increment". The integer part of the phase accumulator is used to address the sample memory, the fractional part is used to maintain frequency accuracy.
For example if the phase increment value was equivalent to 1/2, then the pitch would be shifted down by one octave (the frequency would be halved). A phase increment value of 1.05946 (the twelfth root of two) would create a pitch shift of one musical half-step (i.e. from C to C#) compared with an increment of 1. When non-integer increment values are utilized, the frequency resolution for playback is determined by the number of bits used to represent the fractional part of the address pointer and the address increment parameter.

InterpolationWhen the fractional part of the address pointer is non-zero, then the "desired value" falls between available data samples. Figure 8 depicts a simplified addressing scheme wherein the Address Pointer and the increment parameter each have a 4-bit integer part and a 4-bit fractional part. In this case, the increment value is equal to 1 1/2 samples. Very simple systems might simply ignore the fractional part of the address when determining the sample value to be sent to the D/A converter. The data values sent to the D/A converter when using this approach are indicated in the Figure 8, case I.

Figure 8: Sample Memory Addressing and Interpolation

A slightly better approach would be to use the nearest available sample value. More sophisticated systems would perform some type of mathematical interpolation between available data points in order to get a value to be used for playback. Values which might be sent to the D/A when interpolation is employed are shown as case II. Note that the overall frequency accuracy would be the same for both cases indicated, but the output is severely distorted in the case where interpolation is not used.
There are a number of different algorithms used for interpolation between sample values. The simplest is linear interpolation. With linear interpolation, interpolated value is simply the weighted average of the two nearest samples, with the fractional address used as a weighting constant. For example, if the address pointer indicated an address of (n+K), where n is the integer part of the address and K is the fractional part, than the interpolated value can be calculated as s(n+K) = (1-K)s(n) + (K)s(n+1), where s(n) is the sample data value at address n. More sophisticated interpolation techniques can be utilized to further reduce distortion, but these techniques are computationally expensive.

Oversampling of the sound samples may also be used to improve distortion in wavetable synthesis systems. For example, if 4X oversampling were utilized for a particular instrument sound sample, then an address increment value of 4 would be used for playback with no pitch shift. The data points chosen during playback will be closer to the "desired values", on the average, than they would be if no oversampling were utilized because of the increased number of data points used to represent the waveform. Of course, oversampling has a high cost in terms of sample memory requirements.
In many cases, the best approach may be to utilize linear interpolation combined with varying degrees of oversampling where needed. The linear interpolation technique provides reasonable accuracy for many sounds, without the high penalty in terms of processing power required for more sophisticated interpolation methods. For those sounds which need better accuracy, oversampling is employed. With this approach, the additional memory required for oversampling is only utilized where it is most needed. The combined effect of linear interpolation and selective oversampling can produce excellent results.

When the pitch of a sampled sound is changed during playback, the timbre of the sound is changed somewhat also. The effect is less noticeable for small changes in pitch (up to a few semitones), than it is for a large pitch shift. To retain a natural sound, a particular sample of an instrument sound will only be useful for recreating a limited range of notes. To get coverage of the entire instrument range, a number of different samples, each with a limited range of notes, are used. The resulting instrument implementation is often referred to as a "multisampled" instrument. This technique can be thought of as splitting a musical instrument keyboard into a number of ranges of notes, with a different sound sample used for each range. Each of these ranges is referred to as a split, or key split.
Velocity splits refer to the use of different samples for different note velocities. Using velocity splits, one sample might be utilized if a particular note is played softly, where a different sample would be utilized for the same note of the same instrument when played with a higher velocity. This technique is not commonly used to produce basic sound samples because of the added memory expense, but both key splitting and velocity splitting techniques can be utilized as a performance enhancement. For instance, a key split might allow a fretless bass sound on the lower octaves of a keyboard, while the upper octaves play a vibraphone. Similarly, a velocity split might "layer" strings on top of an acoustic piano sound when the keys are hit with higher velocity.

Aliasing Noise
Earlier paragraphs discussed the timbre changes which result from pitch shifting. The resampling techniques used to shift the pitch of a stored sound sample can also result in the introduction of aliasing noise into an instrument sound. The generation of aliasing noise can also limit the amount of pitch shifting which may be effectively applied to a sound sample. Sounds which are rich in upper harmonic content will generally have more of a problem with aliasing noise. Low-pass filtering applied after interpolation can help eliminate the undesirable effect of aliasing noise. The use of oversampling also helps eliminate aliasing noise.

LFOs for Vibrato and Tremolo
Vibrato and tremolo are effects which are often produced by musicians playing acoustic instruments. Vibrato is basically a low-frequency modulation of the pitch of a note, while tremolo is modulation of the amplitude of the sound. These effects are simulated in synthesizers by implementing low-frequency oscillators (LFOs) which are used to modulate the pitch or amplitude of the synthesized sound being produced.
Natural vibrato and tremolo effects tend to increase in strength as a note is sustained. This is accomplished in synthesizers by applying an envelope generator to the LFO. For example, a flute sound might have a tremolo effect which begins at some point after the note has sounded, and the tremolo effect gradually increases to some maximum level, where it remains until the note stops sounding.

Layering refers to a technique in which multiple sounds are utilized for each note played. This technique can be used to generate very rich sounds, and may also be useful for increasing the number of instrument patches which can be created from a limited sample set. Note that layered sounds generally utilize more than one voice of polyphony for each note played, and thus the number of voices available is effectively reduced when these sounds are being used.

Digital Filtering
It was mentioned earlier that low-pass filtering may be used to help eliminate noise which may be generated during the pitch shifting process. There are also a number of ways in which digital filtering is used in the timbre generation process to improve the resulting instrument sound. In these applications, the digital filter implementation is polyphonic, meaning that a separate filter is implemented for each voice being generated, and the filter implementation should have dynamically adjustable cutoff frequency and/or Q.
For many acoustic instruments, the character of the tone which is produced changes dramatically as a function of the amplitude level at which the instrument is played. For example, the tone of an acoustic piano may be very bright when the instrument is played forcefully, but much more mellow when it is played softly. Velocity splits, which utilize different sample segments for different note velocities, can be implemented to simulate this phenomena.
Another very powerful technique is to implement a digital low-pass filter for each note with a cutoff frequency which varies as a function of the note velocity. This polyphonic digital filter dynamically adjusts the output frequency spectrum of the synthesized sound as a function of note velocity, allowing a very effective recreation of the acoustic instrument timbre.
Another important application of digital filtering is in smoothing out the transitions between samples in key-based splits. At the border between two splits, there will be two adjacent notes which are based on different samples. Normally, one of these samples will have been pitch shifted up to create the required note, while the other will have been shifted down in pitch. As a result, the timbre of these two adjacent notes may be significantly different, making the split obvious. This problem may be alleviated by employing a digital filter which uses the note number to control the filter characteristics. A table may be constructed containing the filter characteristics for each note number of a given instrument. The filter characteristics are chosen to compensate for the pitch shifting associated with the key splits used for that instrument.
It is also common to control the characteristics of the digital filter using an envelope generator or an LFO. The result is an instrument timbre which has a spectrum which changes as a function of time. An envelope generator might be used to control the filter cutoff frequency generate a timbre which is very bright at the onset, but which gradually becomes more mellow as the note decays. Sweeping the cutoff frequency of a filter with a high Q setting using an envelope generator or LFO can help when trying to simulate the sounds of analog synthesizers.

The PC to MIDI Connection
To use MIDI with a personal computer, a PC to MIDI interface product is generally required (there are a few personal computers which come equipped with built-in MIDI interfaces). There are a number of MIDI interface products for PCs. The most common types of MIDI interfaces for IBM compatibles are add-in cards which plug into an expansion slot on the PC bus, but there are also serial port MIDI interfaces (connects to a serial port on the PC) and parallel port MIDI interfaces (connects to the PC printer port). Most other popular personal computers will use a serial port connection.
The fundamental function of a MIDI interface for the PC is to convert parallel data bytes from the PC data bus into the serial MIDI data format and vice versa (a UART function). However, "smart" MIDI interfaces may provide a number of more sophisticated functions, such as generation of MIDI timing data, MIDI data buffering, MIDI message filtering, synchronization to external tape machines, and more.
The specific interface design used has some specific importance to the multimedia market, due to the need for essentially transparent operation of games and other applications which use General MIDI. GM does not define how the game is supposed to connect with the synthesizer, so sound-card standards are also needed to assure proper operation. While some PC operating systems provide device independence, this is not true of the typical IBM-PC running MS-DOS, where hardware MIDI interface standards are required.
The defacto standard for MIDI interface add-in cards for the IBM-PC is the Roland MPU-401 interface. The MPU-401 is a smart MIDI interface, which also supports a dumb mode of operation (often referred to as "UART mode"). There are a number of MPU-401 compatible MIDI interfaces on the market, some which only support the UART (dumb) mode of operation. In addition, many IBM-PC add-in sound cards include built-in MIDI interfaces which implement the UART mode functions of the MPU-401.

PC Compatibility Issues
There are two levels of compatibility which must be considered for MIDI applications running on the PC. First is the compatibility of the application with the MIDI interface being used. The second is the compatibility of the application with the MIDI synthesizer. For the purposes of this tutorial we will be talking only about IBM-PC and compatible systems, though much of this information can also be applied to other PC systems. Compatibility considerations under DOS and the Microsoft Windows operating system are discussed in the following paragraphs.

MS-DOS Applications
MS-DOS applications which utilize MIDI synthesizers include MIDI sequencing software, music scoring applications, and a variety of games. In terms of MIDI interface compatibility, virtually all of these applications support the MPU-401 interface, and most only require the UART mode. These applications should work correctly on any compatible PC equipped with a MPU-401, a full-featured MPU-401 compatible, or a sound card with a MPU-401 UART-mode capability. Other MIDI interfaces, such as serial port or parallel port MIDI adapters, will only work if the application provides support for that particular model of MIDI interface.
A particular application may provide support for a number of different models of synthesizers or sound modules. Prior to the General MIDI standard, there was no widely accepted standard patch set for synthesizers, so applications generally needed to provide support for each of the most popular synthesizers at the time. If the application did not support the particular model of synthesizer or sound module that was attached to the PC, then the sounds produced by the application might not be the sounds which were intended. Modern applications can provide support for a General MIDI (GM) synthesizer, and any GM-compatible sound source should produce the correct sounds.

Multimedia PC (MPC) Systems
The number of applications for high quality audio functions on the PC (including music synthesis) grew explosively after the introduction of Microsoft Windows 3.0 with Multimedia Extensions ("Windows with Multimedia") in 1991. These extensions are also incorporated into the Windows 3.1 operating system. The Multimedia PC (MPC) specification, originally published by Microsoft in 1991, is now published and maintained by the Multimedia PC Marketing Council, a subsidiary of the Software Publishers Association. The MPC specification states the minimum requirements for multimedia-capable Personal Computers to ensure compatibility in running multimedia applications based on Windows 3.1 or Windows with Multimedia.
The audio capabilities of an MPC system must include digital audio recording and playback (linear PCM sampling), music synthesis, and audio mixing. The current MPC specifications define two different levels of performance. The requirements for music synthesizers in MPC level 1 and MPC level 2 systems are essentially the same, although the digital audio recording and playback requirements for MPC level 1 and MPC level 2 compliance are different.
For MIDI, the current MPC specifications attempt to balance performance and cost issues by defining two types of synthesizers; a "Base Multitimbral Synthesizer", and an "Extended Multitimbral Synthesizer". Both the Base and the Extended synthesizer are expected to use a General MIDI patch set, but neither actually meets the full requirements of General MIDI polyphony or simultaneous timbres. Base Multitimbral Synthesizers must be capable of playing 6 "melodic notes" and "2 percussive" notes simultaneously, using 3 "melodic timbres" and 2 "percussive timbres".
The formal requirements for an Extended Multitimbral Synthesizer are only that it must have capabilities which exceed those specified for a Base Multitimbral Synthesizer. However, the "goals" for an Extended synthesizer include the ability to play 16 melodic notes and 8 percussive notes simultaneously, using 9 melodic timbres and 8 percussive timbres.
The MPC specification also includes an authoring standard for MIDI composition. This standard requires that each MIDI file contain two arrangements of the same song, one for Base synthesizers and one for Extended synthesizers, allowing for differences in available polyphony and timbres. The MIDI data for the Base synthesizer arrangement is sent on MIDI channels 13 - 16 (with the percussion track on Channel 16), and the Extended synthesizer arrangement utilizes channels 1 - 10 (percussion is on Channel 10).

This technique is intended to optimize the MIDI file to play on both types of synthesizer, but is also a potential source of problems for GM synthesizers. A GM synthesizer will receive on all 16 Channels and subsequently play both performances, including playing the Channel 16 percussion track, but with a melodic instrument.
Microsoft has addressed this issue for future versions of Windows by recommending the full General MIDI model instead of the Base/Extended model. However, existing MIDI data which has been authored for the Microsoft dual-format will continue to be a problem for next-generation Windows systems, and is a problem in any system today that contains a full GM-compatible synthesizer.
The only current solution is to use the Windows MIDI mapper, as described below, to block the playback of the extra Channels. Unfortunately, this will also result in blocking needed data on those same Channels in a GM-compatible score. The ideal solution might be to develop a scheme for identifying Standard MIDI Files containing base/extended data, and to provide a "dynamic" MIDI mapping scheme which takes into account the type of file being played. This approach could also be applied to other standardized formats which offer some small problems for GM hardware, such as Roland's GS and Yamaha's XG formats.

Microsoft Windows Configuration
Windows applications address hardware devices such as MIDI interfaces or synthesizers through the use of drivers. The drivers provide applications software with a common interface through which hardware may be accessed, and this simplifies the hardware compatibility issue. Synthesizer drivers must be installed using the Windows Driver applet within the Control Panel.
When a MIDI interface or synthesizer is installed in the PC and a suitable device driver has been loaded, the Windows MIDI Mapper applet will then appear within the Control Panel. MIDI messages are sent from an application to the MIDI Mapper, which then routes the messages to the appropriate device driver. The MIDI Mapper may be set to perform some filtering or translations of the MIDI messages in route from the application to the driver. The processing to be performed by the MIDI Mapper is defined in the MIDI Mapper Setups, Patch Maps, and Key Maps.
MIDI Mapper Setups are used to assign MIDI channels to device drivers. For instance, If you have an MPU-401 interface with a General MIDI synthesizer and you also have a Creative Labs Sound Blaster card in your system, you might wish to assign channels 13 to 16 to the Ad Lib driver (which will drive the Base-level FM synthesizer on the Sound Blaster), and assign channels 1 - 10 to the MPU-401 driver. In this case, MPC compatible MIDI files will play on both the General MIDI synthesizer and the FM synthesizer at the same time. The General MIDI synthesizer will play the Extended arrangement on MIDI channels 1 - 10, and the FM synthesizer will play the Base arrangement on channels 13-16.
The MIDI Mapper Setups can also be used to change the Channel number of MIDI messages. If you have MIDI files which were composed for a General MIDI instrument, and you are playing them on a Base Multitimbral Synthesizer, you would probably want to take the MIDI percussion data coming from your application on Channel 10 and send this information to the device driver on Channel 16.
The MIDI Mapper patch maps are used to translate patch numbers when playing MPC or General MIDI files on synthesizers which do not use the General MIDI patch numbers. Patch maps can also be used to play MIDI files which were arranged for non-GM synthesizers on GM synthesizers. For example, the Windows-supplied MT-32 patch map can be used when playing GM-compatible .MID files on the Roland MT-32 sound module or LAPC-1 sound card. The MIDI Mapper key maps perform a similar function, translating the key numbers contained in MIDI Note On and Note Off messages. This capability is useful for translating GM-compatible percussion parts for playback on non-GM synthesizers or vice-versa. The Windows-supplied MT-32 key map changes the key-to-drum sound assignments used for General MIDI to those used by the MT-32 and LAPC-1.

The MIDI protocol provides an efficient format for conveying musical performance data, and the Standard MIDI Files specification ensures that different applications can share time-stamped MIDI data. While this alone is largely sufficient for the working MIDI musician, the storage efficiency and on-the-fly editing capability of MIDI data also makes MIDI an attractive vehicle for generation of sounds in multimedia applications, computer games, or high-end karaoke equipment.
The General MIDI system provides a common set of capabilities and a common patch map for high polyphony, multitimbral synthesizers, providing musical sequence authors and multimedia applications developers with a common target platform for synthesis. With the greater realism which comes from wavetable synthesis, and as newer, interactive, applications come along, MIDI-driven synthesizers will continue to be an important component for sound generation devices and multimedia applications.

Perl, Sockets and TCP/IP Networking

An simplified introduction to sockets
Sockets are a mechanism that allows programs to communicate, either on the same machine or across a network. The way it works is pretty simple: Each machine on a network is identified by some address. In this tutorial we will talk about tcp/ip networking, so by network address we mean an IP address. (like Apart from the IP address that specifies a machine, each machine has a number of ports that allow handling multiple connections simultaneously.

A program that wishes to receive a connection from another program, asks the operating system to create a socket and bind it to some port. Then the program sits and listens on the socket it has created to receive incoming connections. The other program also creates a socket for communicating witht he receiver. The caller needs to specify the IP address and the port number of the receiving end. If all goes well, and as we will see shortly, the two programs establish a communication through the network using their sockets. The two programs may exchange information, each by writing to and reading from the socket it has created.
Can I do this with Perl?
Sure. Perl provides support for the socket API natively. Although the interface is not that bad anyway, there is also a very convenient module, IO::Socket that works like a wrapper on the native API and provides a simpler and easier way to deal with sockets. We'll use IO::Socket in this tutorial to demonstrate writing two simple programs that communicate with sockets.

The Receiver
The first thing we need to do is to create a socket. We will use it to receive connections. The code below shows how to create a receiving socket. Note that we need to specify the local hostname and the port to which the socket will be bound. Of course, if the port is already in use this call will fail. Also note the 'Listen' parameter: this is the maximum number of connections that can be queued by the socket waiting for you to accept and process them. For the time being we will only accept a maximum of one connection at any time. (This means that a connection attempt while we're dealing with another connection, will return with an error like 'connection refused') Finally the 'Reuse' option tells the system to allow reuse of the port after the program exits. This is to ensure that if our program exits abnormally and does not properly close the socket, running it again will allow opening a new socket on the same port.
1 use IO::Socket;
2 my $sock = new IO::Socket::INET (
3 LocalHost => 'thekla',
4 LocalPort => '7070',
5 Proto => 'tcp',
6 Listen => 1,
7 Reuse => 1,
8 );
9 die "Could not create socket: $!\n" unless $sock;

Now the socket is ready to receive incoming connections. To wait for a connection, we use the accept() method which will return a new socket through which we can communicate with the calling program. Information exchange is achieved by reading/writing on the new socket. The socket can be treated like a regular filehandle.

10 my $new_sock = $sock->accept();
11 while(<$new_sock>) {
12 print $_;
13 }
14 close($sock);

The Caller

The other side of the communication is even simpler. All we need to do is to create a socket specifying the remote address and port. The constructor will return a socket object after the connection has been etablished, and we may start sending data right away by writing onto the socket like any other filehandle.

1 use IO::Socket;
2 my $sock = new IO::Socket::INET (
3 PeerAddr => 'asomatos',
4 PeerPort => '7070',
5 Proto => 'tcp',
6 );
7 die "Could not create socket: $!\n" unless $sock;
8 print $sock "Hello there!\n";
9 close($sock);

Go ahead and try it!
You can easily try out the example programs above. All you need to do is execute the receiver first and then the sender. On the receiver end, you will see the line "Hello there!" printed on the terminal screen. If you do not have a network, you can still use 'localhost' for the hostname of both the receiver and caller just to test it out.

An important issue to consider in this style of communication is that the two ends must follow a commonly-agreed procedure of data exchange. Otherwise it is very easy to end up in a deadlock situation where either both ends try to read, or both ends try to write. Ther is no way to guess whether the other end has finshed sending data, unless there is some protocol of communication between them that denotes logical sections of the communication in the contents of the transmitted messages. In the example above, the model is very simplistic: The caller sends a message and closes its end of the connection, while the receiver just reads the data until it's all finished.
Usually client-server transactions consist of a caller (the client) sending a request, followed by the receiver (server) sending back a reply. In order for the server to understand when the request is finished, there is some agreed marker (such as two consecutive empty lines, or a line saying "END REQUEST") that denotes the last line in the request. The server, starts sending its reply only after this line has been received, and afterwards closes the socket. The receiver, after sending the entire request switches to reading until the socket is closed, so it will receive the reply. More complex schemes can be established in a similar mannere, according to your needs and taste. What is important is to make sure that the two ends of the communication have a way of knowing when to speak and when to listen, thus avoiding the possibility of getting locked up.

Friday, January 4, 2008

Basic Concepts of SMS Technology

In the following sections, we will introduce to you some basic concepts of the SMS technology.

1. Validity Period of an SMS Message
Preferences - Do not show ads
An SMS message is stored temporarily in the SMS center if the recipient mobile phone is offline. It is possible to specify the period after which the SMS message will be deleted from the SMS center so that the SMS message will not be forwarded to the recipient mobile phone when it becomes online. This period is called the validity period.

Here is an example that illustrates how validity period can be used. Suppose you find a very interesting program that is showing on TV now. You think your friend may want to watch it. So, you send a text message to tell your friend about the TV program. Let's say the TV program lasts for an hour. Your SMS text message will not be useful to your friend if his mobile phone is not available before the program finishes. In this situation, you may want to send a text message with a validity period of one hour to your friend. The wireless carrier will not deliver the SMS text message to your friend if his mobile phone is not available before the validity period ends.
A mobile phone should have a menu option that can be used to set the validity period. After setting it, the mobile phone will include the validity period in the outbound SMS messages automatically.

2. Message Status Reports
Sometimes you may want to know whether an SMS message has reached the recipient mobile phone successfully. To get this information, you need to set a flag in the SMS message to notify the SMS center that you want a status report about the delivery of this SMS message. The status report is sent to you in the form of an SMS message.
A mobile phone should have a menu option that can be used to set whether the status report feature is on or off. After setting it, the mobile phone will set the corresponding flag in the outbound SMS messages for you automatically. The status report feature is turned off by default on most mobile phones and GSM / GPRS modems.

3. Message Submission Reports
After leaving the mobile phone, an SMS message goes to the SMS center. When it reaches the SMS center, the SMS center will send back a message submission report to the mobile phone to inform whether there are any errors or failures (e.g. incorrect SMS message format, busy SMS center, etc). If there is no error or failure, the SMS center sends back a positive submission report to the mobile phone. Otherwise it sends back a negative submission report to the mobile phone. The mobile phone may then notify the user that the message submission was failed and what caused the failure.
If the mobile phone does not receive the message submission report after a period of time, it concludes that the message submission report has been lost. The mobile phone may then re-send the SMS message to the SMS center. A flag will be set in the new SMS message to inform the SMS center that this SMS message has been sent before. If the previous message submission was successful, the SMS center will ignore the new SMS message but send back a message submission report to the mobile phone. This mechanism prevents the sending of the same SMS message to the recipient multiple times.
Sometimes the message submission report mechanism is not used and the acknowledgement of message submission is done in a lower layer.

4. Message Delivery Reports
After receiving an SMS message, the recipient mobile phone will send back a message delivery report to the SMS center to inform whether there are any errors or failures (example causes: unsupported SMS message format, not enough storage space, etc). This process is transparent to the mobile user. If there is no error or failure, the recipient mobile phone sends back a positive delivery report to the SMS center. Otherwise it sends back a negative delivery report to the SMS center.
If the sender requested a status report earlier, the SMS center sends a status report to the sender when it receives the message delivery report from the recipient.
If the SMS center does not receive the message delivery report after a period of time, it concludes that the message delivery report has been lost. The SMS center then re-sends the SMS message to the recipient.
Sometimes the message delivery report mechanism is not used and the acknowledgement of message delivery is done in a lower layer.

Setting Mikrotik VPN / PPTP

PPTP Server :
- Mikrotik OS 2.9.0 Stable (Latest Version)

- CPU and motherboard : advanced 4th generation (core frequency 100MHz or more), 5th generation (Intel Pentium, Cyrix 6X86, AMD K5 or comparable) or newer uniprocessor Intel IA-32 (i386) compatible (multiple processors are not supported)
- RAM :minimum 32 MiB, maximum 1 GiB; 64 MiB or more recommended
- STORAGE medium :standard ATA/IDE interface controller and drive (not supported SCSI, USB controllers n drives, RAID controllers that require additional drivers) minimum of 64 Mb space; Flash and Microdrive devices may be connected using an adapted with ATA interface.

NOTE : If your machine have SATA Drive, ensure that your Machine BIOS, support COMBINED / LEGACY mode at SATA CONTROLLER (ini pengalaman pribadi), klo enggak coba tukerin tu mesin ma yang support aja hehehe .. ato jual ato anggurin dan minta maap hihihi tapi tetep usaha dulu ampe mentok n kringetan sapa tau ada ide.

Cara Memasak :

1. Install Mikrotik OS
- Siapkan bumbu dapur .. hehe ... bukan dink .. beli mesin dulu .. server / PC minimal Pentium II juga gak papa RAM 64
- Di server / PC kudu ada minimal 2 ethernet, 1 ke arah Firewall dan 1 lagi ke Network yang akan dituju dr Internet via VPN.
- Siapkan CDROM untuk install (ini salah satu cara selain lewat Net Install dan Flashdisk belajar ndiri buat PR)
- Burn Source CD Mikrotik OS masukan ke CDROM
- Boot dari CDROM
- Ikuti petunjuk yang ada, jangan ragu2 hehehehe, klo salah ya .. coba lagi .. rusak Purchased lagi ^_^
- Install paket2 utama : System, PPP (untuk PPTP), Advanced Tools, Routing, Security.
- Setelah semua paket y6ang dibutuhkan diinstall maka untuk menginstallnya tekan "I"
- Lama Install jika PC / Server Sehat sekitar 5 menit lebih dr itu .. buang aja servernya ganti yang baru ..
- Setelah diinstall beres .. maka klo normal semuanya .. saat system restart .. maka akan kluar halaman login Mikrotik.

2. Configure Mikrotik OS (untuk VPN / PPTP)
- Login dengan Default User : Username : admin
Password : gak usah diisi langsung ENTER saja
- ketik "/setup"
- pilih untuk setup networknya .. ikuti petunjuk yang ada .. coba aja jangan takut .. gak hamil kok
- Sesuaikan IP addressnya dengan Network ID IP PC / Server tempat backup konfigurasi Mikrotik Sebelumnya agar bisa di-FTP (ini klo udah pernah install dan di-backup configurasinya)
- test ping ke IP PC / Server backup bila normal .. maka siap melakukan restore.

3. Restore Configurasi :
- FTP dulu ke mikrotik dengan IP, User dan password sesuai configurasi sebelumnya.
- setelah masuk ketik "bin" trus ENTER untuk mode binary
- kemudian ketik "put FILE_BACKUP_MIKROTIK" trus enter .. kuduna mah sukses (NOTE: sebelum melakukan FTP, harus ada di folder tempat si file backup berada).
- ketik "quit" untuk kluar
- di PC / Server tempat backup-an mikrotik, buka Internet Explorer trus ketikan dah disitu "IP_ADDRESS_MIKROTIK_ELU"
- download program WINBOX.EXE di Web yang terbuka (klik aja gambar Winbox-nya).
- Setelah download kelar .. klik 2 kali tu downloadan .. klo normal akan muncul si WINBOX
- ketikin di WINBOX, IP ADDRESS mikrotik lu, username ma passwordnya trus CONNECT
- Setelah berhasil masuk .. klik di FILE .. kemudian pilih File yang ada .. klik "RESTORE"
- DONE --> reboot MIKROTIk (Klik SYSTEM --> SHUTDOWN --> REBOOT)

4. Backup Configurasi :
- Sebaiknya setiap malam konfigurasi Mikrotik di backup agar tidak bingung bila ada masalah dengan masuk ke FILE di WINBOX
- Hapus backup sebelumnya (pastikan sudah dibackup), dan setelah kosong klik tombol BACKUP.
- buka START --> RUN --> CMD di PC yang akan jadi tempat backup
- masuk ke folder tempat file backup mo ditaruh (contoh "d:" kemudian "cd MikrotikBckup")
- ftp ke Mikrotik (misal :"ftp IP_MIKROTIK_ELU" trus ENTER)
- masukin User dan password
- setelah masuk.. maka masuk ke mode BIN dengan cara ketik "bin" trus ENTER.
- ketik "ls" untuk menampilkan isi backup
- ketik "get NAMA_FILE_BACKUP" Trus ENTER untuk mengambilnya.
- ketik "QUIT" untuk kluar

5. Firewall Rules di Mikrotik :
- Di WINBOX, Klik IP --> Firewall --> SOURCE NAT
- Di tabel Source NAT, add :

6. Mengaktifkan PPTP Server :
- di WINBOX, klik INTERFACE --> SETTING --> PPTP Server
- Setelah muncul tabel PPTP Server maka enable-kan, seluruh parameter default, dan check seluruh authentication yang ada (agar tidak ribet nyetting security di client PPTP).
- buat IP POOL yang berperan memberikan IP Dynamic pada setiap koneksi PPTP yang masuk dan berhasil konek dengan cara :
a. klik IP --> POOL, klik tanda "+" dan berikan NAMA serta masukkkan network atau range IP.
b. klik OK, Selesai .. sudah ? belum .. jalan masih panjang kawan heheeh .. terusin baca bawahnya gih .. ^_^
- buat USER PPTP dengan cara :
a. klik PPP --> Profiles, edit profile defaultnya dengan klik 2 kali (mo nambah juga gak papa, cuman biar gak ribet aja hehe)
b. masukkan LOCAL ADDRESS dengan IP ADDRESS yang dipegang oleh interface yang terhubung ke MESIN FIREWALL
c. drop down menu REMOTE ADDRESS dan pilih nama IP POOL yang udah dibuat (makanya IP POOL-nya gw duluin biar gak ditanya hehehe)
d. klik APPLY --> OK
e. klik SECRETS, NAME : isi dengan USERNAME dan PASSWORD untuk CLIENT
f. Masih di SECRETS, bagian SERVICE : pilih PPTP
g. Masih di SECRETS juga, jika diinginkan client hanya dial VPN dr IP public tertentu maka bagian CALLER ID diisi dengan IP PUBLIC Client tersebut (bisanya untuk kasus client adalah ISP atau Corporate Laen, untuk monitoring).
h. Jika ada kasus client menggunakan IP address LOCAL yang sama dengan IP Address yang didapat dari PPTP (biasanya client di Internet gedung atau perusahaan) maka jika koneksi VPN sudah ESTABLISH dan masih belum bisa ping, di bagian REMOTE ADDRESS untuk SECRETS dari user bersangkutan harus diisi dengan IP ADDRESS diluar dr range IP POOL tapi masih dalam satu network, kemudian tambahkan routing DEFAULT di PC CLIENT tersebut.

1. Boot dr CD dengan CD Linux bersangkutan di dalamnya.
2. Selanjutnya seperti install OS biasa hehehe .. coba tanya mbah google untuk ini ato STTers yang laen pada jago2 tuh .. banyak kok source-nya.
3. Package yang dipilih saat install untuk keperluan ini gak usah semua .. banyak euy dan gak manfaat, contohnya X-Window, gak manfaat itu, khan buat server, Command line aja.
Package yang perlu :
- KERNEL DEVELOPMENT : ini agar kita saat install RPM tertentu atau Source TGZ gak perlu compile macem2.
- EDITORS : buat ngedit mbah .. klo gak diinstal .. mo configure-nya gimana ? hehehe
- FIREWALL : butuh IPTABLESnya doank
- hmm .. lupa heheh .. kayanya masih ada yang laen .. sesuaiin aja dah sambil liat2 keterangan ma baca2 n belajar.
4. bila udah sukses install LINUX-nya maka tinggal install RPM tambahan seperti :
a. SHOREWALL : download dari dan baca juga dokumentasinya
b. SNMP : udah ada di CD linux REDHAT tinggal di RPM-kan, caranya ? baca google, hehehe gampang kok
c. MRTG : download dan baca dokumentasinya di
d. HTTP : udah ada di CD LINUX REDHAT tinggal di RPM-in dan configure, caranya ? sama .. baca google lagi
e. WEBMIN : download dan baca dokumentasinya di, gampang cari aja package RPM yang buat REDHAT.
- DNAT TCP 1723 ke IP server PPTP
- DNAT Protocol 47 ke IP server PPTP
- RULES yang laen, sesuaikan dengan kebutuhan.
- DEFAULT RULES harus close all klo gak mao ada traffic2 maling hehehe.


IIS Security Checklist

The following checklist is a summary of the security points which should be checked prior to bringing an IIS server online. In cases where these points are not followed, the admin may want to securely document the known security issues for referral should a security compromise occur.

General assumptions:
No IIS on a domain controller
Install only services needed (ftp, www, smtp, nntp). Mailing out does NOT require smtp; use CDOSYS.DLL (a COM based method native to Windows) or a 3rd party executable like blat.exe for web applications that require outgoing mail.
Virtual directories are NEVER used across servers.
The underlying Windows OS has been secured.
Only system administrators are local administrators.
Design Guidelines
Websites should NEVER be on the system drive.
Setup SSL if transmitted information is sensitive. Require SSL (Remove ability to access via port 80) if SSL is enabled.
All FTP sites, and as needed WWW sites should enable IP filtering for UW-only sites. Ipsec filters can be used to accomplish this.
Virtual directories should be used as little as possible. They aren't needed unless you need to span drives. And if you need to span drives reconsider based on the security implications.
Remove NTFS write perms everywhere possible.
Don't make it easy to find your scripts and code. Hackers target code seeking vulnerabilities they can use to take control of the server. Good ideas include:
Don't use an obvious name for your scripts directory. 'Scripts', 'cgi-bin', 'exchange', and 'bin' are so common that automated tools look for them.
Consider renaming the extension on all of your scripts to something uncommon. For example, rename myscript.asp to myscript.dum. This will require adding an ISAPI extension mapping for .dum to the appropriate code handler (asp.dll in this case). This makes your scripts harder to find. Incidentally, specifically renaming all .asp scripts to .html works fine without modifying the ISAPI extension mapping.
Consider compiling scripts into dll files. This not only protects the code from analysis, but it also results in a major performance gain. Compiled code runs about 20 times faster.
Web applications (i.e. scripts and executables) only need a limited amount of permissions to run properly. Giving more permissions than is necessary allows a malicious hacker to download and analyze your code for vulnerabilities. The minimum permissions needed are: NTFS: Read, IIS: Execute. IIS: Read is NOT required, and will allow a hacker to download your code.
Be careful when using the Add/Remove control panel on an IIS Server. If you open the Windows components, Windows will inadvertently reset all ISAPI filter and extensions to the default, and may reset other things. This is a poor design by Microsoft that you need to be careful with.
Installation configuration
Delete all default virtual directories (icon w/ world on top of folder) and application roots (icon w/ green ball in box)
Delete iisadmin
Delete iissamples
Delete msadc.
Delete iishelp
Delete scripts
Delete printers
Delete ALL default content.
Delete %systemdirectory%\inetsrv\iisadmin
Delete %systemdirectory%\inetsrv\iisadmpwd
Delete inetpub\wwwroot (or \ftproot or \smtproot)
Delete inetpub\scripts
Delete inetpub\iissamples
Delete inetpub\adminscripts
Delete %systemroot%\help\iishelp\iis
Delete %systemroot%\web\printers
Delete %systemdrive%\program files\common files\system\msadc. Only websites that integrate with Microsoft Access databases need msadc.
Configure Default Website with extremely secure settings (e.g. require ssl, Integrated Windows auth only, accessible from only one IP, NTFS perms to none on an empty home directory, etc.), then stop the site. This results in a broken default website that 80% of hackers will blindly attack, instead of your real website.
Configure all website(s) with host header matching the DNS name of the site. Go to ISM, Web Site tab, Advanced button, Select "All Unassigned" (or the specific IP) and Edit Button, and designate the host header in the appropriate field. Do this for both http and https. Do NOT configure default website with host header. This will prevent 90% of all automated hacking tools from working by sending them to your crippled default website.
Home directory IIS perms: Enable Read and Log. TURN OFF Write, Index, Browsing, Script Source Access (only WebDAV uses this), and Frontpage Web permissions. Set execute permissions to None. Enable execute permissions for the directory that holds your scripts.
Disable all unnecessary ISAPI filters. Do this under ISM, ISAPI filters tab.
Delete the Frontpage ISAPI filter (or extensions on older IIS servers), if you have a choice. If Frontpage ISAPI (extensions) is required, make them read only. On older IIS servers, you disable Frontpage extensions with the following command: "c:\program files\common files\microsoft shared\web server extensions\40\bin\fpsrvadm -o uninstall -p all".
Digest Authentication. This authentication method requires support for reversibly encrypted passwords-which is a bad idea. Reversible encrypted passwords are very insecure. Delete this filter.
HTTP Compression. This filter allows compression of the http stream. This is a nice feature, but might be at the expense of security.
SSL. It's unlikely you wouldn't want SSL support, but if you don't need it, then delete it.
Delete the dll files associated with ISAPI filters that you disabled. Frontpage: fpexdll.dll, Digest: md5filt.dll, Compression: compfilt.dll, SSL: sspifilt.dll.
Unmap the following extensions (if possible):
.asa, .asp, .bat, .cdx, .cer, .htr, .htw, .ida, .idc, .idq, .printer, .shtm, .shtml, .stm
Within ISM, go to the Home Directory tab, and choose Configuration button.
Disable "Enable Parent Paths" setting. Go to ISM, Home Directory tab, Configuration button, App Options tab, uncheck checkbox. This prevents malicious web traversal without knowing the underlying directory structure. Web developers can not use paths like ..\..\default.htm and must use fully qualified paths.
Patch level
Apply Service Packs and hotfixes. UpdateExpert makes this very easy or Microsoft's HfCheck tool can be used.
Install high encryption pack (comes with Windows 2000 SP2) so 128 bit encryption is available.
Authentication model:
Basic authentication disabled at site level, virtual directory level, directory level -Everywhere!
Digest authentication disabled everywhere.
IUSR & IWAM accounts should not be domain users nor should they be guests. If no anonymous access is required, delete these accounts.
If web data is ultra-sensitive consider placing server outside a domain.
Authorization Changes
Enable IIS auditing, change to W3 extended logging, and check that the info that is being logged is appropriate. (e.g. Is username needed?) Consider enabling the following items: Date and time, IP address of the client, IP address of the server, Server port, Username, HTTP method used to access your site, URI Stern, URI Query, Status of the request.
Set permission to IIS logs to system and local administrators only.
Remove write perms to hklm\software for non-admin accounts. Administrators & System: FULL, Everyone: Read/Execute
Restrict NTFS perms to ALL executables on system. NTFS perms: Administrators & System: FULL, Users: Read/Execute. Give IUSR account execute permissions sparingly.
Restrict perms to any script interpreters such as perl. NTFS perms: Administrators & System: FULL, Everyone: Read/Execute. Give IUSR account execute permissions sparingly.
Ensure Everyone has only read on:
Web root
%systemroot%\program files\common files\
Re-used with permission from Stanford University for which I originally wrote this documentation,