gmt-archive.html

GMT-archive

This file contains obsolete elements and notes from previous versions of our <GMT> manual. Previous versions can only be obtained by email request now. They are no longer available on our website.

The <GMT> package consists of the following files:

1.- specific files for <GMT> software version 1.3 - under Microsoft PDS 7.1:

This version is no longer available on our website, but all files for the package can be obtained from the author via email.

File date/time	size	former links for downloads (now via email)
GMT_MIDI BI 03-11-97 3:25p	605	Gmt_midi.bi
GMT_KONS BI 03-11-97 7:15p	167	Gmt_kons.bi
GMT_DEBU BI 03-11-97 3:29p	306	GMT_debu.bi
GMT_MIDI BAS 07-29-97 9:49p	6,571	GMT_midi.BAS
GMT_DEBU BAS 03-11-97 5:33p	3,246	GMT_debu.BAS
GMT_MAIN MAK 07-29-97 11:32p	56	GMT_main.MAK
GMT BAT 03-11-97 2:00a	42	GMT.BAT
GMT_TYPE BI 03-11-97 3:32p	455	GMT_type.BI
GMT_VARS BI 03-11-97 3:34p	1,214	GMT_vars.BI
GMT_USER BI 03-14-97 3:28p	344	GMT_user.BI
GMT_PROC BI 03-13-97 6:54p	415	GMT_proc.BI
GMT_USER BAS 07-29-97 10:47p	11,414	GMT_user.BAS
GMT_MAIN BAS 07-29-97 8:45p	14,388	GMT_MAIN.BAS
KONSTANT BI 03-14-97 3:35p	760	KONSTANT.BI
[This file]		gmt_manual.html

- files provided by Microsoft, with declarations for the interrupt servicing routines and DOS function calls, as required for mouse support etc...

(Owners of the Microsoft Profesional Basic Development system (PDS, Version 7.1) should already have this file.)

QBX BI 03-07-97 11:49a

823

QBX.BI

- files users might want to include, but that are part of our <Harmony Library>. Users that already have version 1.9 of this software, do not have to download it again. Just copy the files listed here to the directory you created for your GMT-projects.

Only some modules contained in HarmLib are used in the GMT-concept. Please study the code in GMT, to understand the how and why's. Downloads for the Harmlib-software -including a very extensive users manual in HTML, should start from : http://www.logosfoundation.org/gmt/HarmonyLibrary.html

The files mentioned here are in their version for Microsoft PDS no longer available on our website. They can be obtained on demand via email form the author directly. Versions for the PB Dos compiler are no longer available neither. We now support only the version of <GMT> + <Harmony Library> (merged together, although in different code modules) running under 32 bit windows using the complete Win32Api.

Harmony Library Download Version (This is also available in a version for PowerBasic 3.5 DOS Compiler on request)

Technical requirements (Versions up to 1.9):

Hardware platform: PC-type computer (80386+30387, 80486, Pentium supported) Math coprocessor required.
Midi I/O card. MusiQuest interfaces, Roland and Soundblastercards all work fine within this environment. The default I/O setting is &H330 / &H220.
QBX/BC7 Microsoft version: Dos should run screen-filling, not in a dos-box window. Win3.11 or Win95 may be running, but will slow down performance. Make sure, in case you have Windows running, it does not use the midi-port. Our code writes directly to the hardware.

Screen should be VGA type.

Virus protection TSR's should be disabled.
QBX/BC7 version: Mouse can be used, but is not strictly required. Have the appropriate dos-drivers. (Useable drivers are included with Microsoft Professional Basic).

Have Microsoft Basic PDS QBX-V7.1 installed properly.

Writing code within the GMT in a minimum of time:

Step 1:

Microsoft Basic PDS V7.1 version:

- load the QBX-environment with the libraries:

QBX /Ah/L Main_LIB.QLB GMT_Main.bas

This loads the Harm_lib library for use in your programs, as well as the procedures and functions required for interrupt handling and register access from within Basic. If you have installed Main_lib in another directory, you have to include the path on the command line. You can also invoke the batch-file provided:

GMT.BAT

This will load the dos-mouse driver as well, in case no driver was load already. Make sure you have all the *.QLB, *.BI, *.LIB files required. It is best to keep them together in your project directory. To simplify code maintenance however, you may also consider adding them to the appropriate directories used by QBX for libraries, binaries etc..., as set in the default options for the program.

In any case, the source-code files and the corresponding includes:

GMT_MAIN.bas ' this will always be the main module.
GMT_Main.bi ' its declaration file
GMT_User.BAS ' here you will have to add all your specifications and declarations for your own task code.
GMT_User.bi ' Declarations for GMT_User.

You do not have to change these, but you may have to add constants, shared variables or procedures. GMT_User.Bi must reside in your project directory, since you will be changing/adding code to these files. The following code-modules may reside in a directory common to your GMT-programs:

GMT_Midi.BAS ' Midi I/O support code module
GMT_Midi.bi ' ditto declaration file
GMT_Debu.BAS ' Debugging module
GMT_Debu.bi ' declaration file for debugging code.

Obsolete procedures and functions:

[removed since version 2.6:]

ClearMuBuf ()

erase the midi output buffer used for multitasking midi-output functions such as Uit.

ClearMiBuf ()

erase the midi input buffer

Uit (byte%)

This procedure sends a byte to the midi-out buffer. If the midi-out task is enabled, the bytes will be output through the midi-port.

SUB MPUcommand (b?)

sends a command to the midi-port at Madr. This procedure is no longer required if the internal Windows functions are in use.

SUB DSPcommand (b?)

send a command to the Soundblaster DSP chip. This procedure is no longer required if the internal Windows functions are in use.

FUNCTION DSPreset? ()

resets the Soundblaster DSP chip - should return 170 if o.k.This procedure is no longer required if the internal Windows functions are in use.

MpuUart ()

This procedure should be called before entering the multitaskers loop, if an MPU compatible interface is to be used. Its function is to set the midi port to UART-mode. If the I/O address as set in the global variable Madr is different from your hardware, the procedure may hang your computer... (We default the constant to &H330, you can change the value in the *.INI file). We are experiencing problems with this procedure on different hardware platforms however. Therefore in our code we call a separate MPUUART.EXE program to perform this function...

This procedure is no longer required if the internal Windows functions are in use.

MidiIN

This procedure (a task) polls the midi port for input. It writes the received data to the midi input buffer in string format. It also removes running status by adding status bytes as appropriate. The user normally should not interfere with this task nor read the MiBuf string directly. We have provided ample functions to handle midi input.
If the Windows Api functions are used (midimode 4 in GMT.INI) this task uses the regular Windows Callback mechanism. Make sure you do not disable the interrupt!

MidiUit

This task dumps the contents of MuBuf, the internal midi data output buffer to the hardware port. If this task is disabled, no midi out can take place, unless you code uses the direct midi-out functions provided under GMT.

The Midi I/O tasks are pretty critical. So, understand what you are doing if ever changing this code! It is the midi I/O task for the multitasker. If disabled, no midi-I/O can take place. Notice that it's input functions read data to a circular buffer, the length of which is determined by a declared constant. It ignores all real-time midi bytes flowing in, for in this context we have no use for them. This same task handles also all midi-output, by sending out the midi-out circular buffer and keeping a pointer. The user should never write directly to the buffers, but for midi output, he should use the Uit() procedure provided. This tasks uses direct access to the hardware of your midi port. It makes use of either MPU-UART mode or Soundblaster UART mode, a mode that should have been enabled prior to entering the multitasker. (Use the procedure MPUUART provided). The hardware I/O address is contained in the global variables Madr and SBadr, and may be changed corresponding to your hardware settings. By default it is set to &H330 and &H220 in the example *.INI file. If these settings do not correspond to your hardware, your system may hang... If you have soundblaster hardware (set to base adres &H220), this is a better choice. Their midi-interface is DSP based and performs an awfull lot better than Rolands legacy implementation. Note that the source code for the low level midi routines are all written in inline assembler. If you happen to have a genuine Intel motherboard with a Crystal sound chipset, MPU mode is the mode of choice. Set Midimode to value 0 in the *.INI file.

These remarks do not apply if you are using the Win32 api functions.

SUB Kybernos ()

This is internal Task 0: It is the new autoregulator, called Kybernos in the multitasker menu. It returns the global variable Lps&, corresponding to the number of loops per second the multitasker runs at. The return value is integrated but may still show up a lot of jitter if some tasks require excessive processor time. To overcome this inconvenience, we added the type field Task.kloks, such that slow tasks can compensate by setting a corresponding high value internally. You can avoid jitter be letting GMT run for a while with a given task load and then switching the task off. Also, feel free to experiment with the aperture time and integration constants used within the source code of the function.

Muis (h%, v%, b%) [no longer supported]

This procedure retrieved information from the mouse driver in previous versions of <GMT>. PBCC does not support graphic coordinates however. We hope to find an new implementation later, through the Win32api. Sample code can be found in the WinProc callback procedure, where mouse coordinates are displayed in the statusbar below the opening window.

The parameters h%,v% and b% are empty on entry and after the call, contain the horizontal and vertical mouse position coordinates as integers. The b% variable return the button information.

SUB MenuScreen (b%) [no longer supported]

The parameter is for updates of sections of the screen. The value corresponds to the tasknumber that needs an update

SUB DebugScreen (b%) [no longer supported]

The bottom screen used for debug feedback. The parameter corresponds to the appropriate debug task.

SUB IntroScreen () [no longer supported]

Displays a welcome screen at startup. May ask some set up questions and parameters and displays the setting as found in the *.INI file.

SUB InitMouse () [no longer supported]

This procedure initializes the mouse function by calling the mouse driver. It is called once before entering the multitasking loop. In previous versions this used assembly language and interrupt handling. Now it is handled through internal functions in PowerBasic CC. We had to drop graphic coordinates however...

SUB InitMidi ()

initialize midiport settings: now handled via the main opening menu.

Keyhandler () [no longer supported]

This procedure is defined as internal task nr.1. If you disable it, the user has no longer any control over the keyboard. The default polling rate (the task().freq ) should be fairly slow, since we should not expect more than ca. 16 keystrokes a second from the user. This task handles mouse input within the dos box as well.

To understand exact operation, please look into the source code.

MuisHandler (hor%, ver%) NOW OBSOLETE

This procedure is defined as internal task nr.13. It basically doubles the functions implement for keyboard controll. Polling however should be faster. This code has undergone a lot of changes since version 1.9. Power Basic does support mice directly, although only in character based modes.

Autoregulate ALIAS Kybernos () NOW OBSOLETE

This task autoregulates the multitasker by dynamically adjusting the rsi's of all activated tasks in function of the actual loop speed of GMT. In order to function properly, the user should granulate his code as much as possible. So, do not put a lot of code in a single task procedure! Distribute the load. The task worked as task 0 by calling the function MTSpeed& in versions before 2.0.

Removed functions/procedures from gmt_midi since version 3.8

Legacy functions and procedures, no longer supported since version 3.7 (01.08.1999):

GetNewController% (k?,c?, remove?)

GetOldController% (k?,c?, remove?)

k?= requested midi-channel

c?= controller number to trace

remove? = 0 or 1 switch

The first function reads the most recent midi-controller information from the midi-in buffer. The channel to read controller information from, should be passed to the function (k? parameter, byte). The range for k? is limited to the range for valid midi-channels: 0-15. The number of the controller to read should also be passed to the function as parameter c?. The last parameter serves as a switch: if set to 0, the function leaves the midibuffer intact, else it removed the data returned from the buffer. In the latter case, it cannot be retrieved again. All legal midi controller number can be accepted. Check you midi equipment to know what controllers it sends out. Controller nr.1 is generally mapped to reflect the position of the modulation wheel on keyboard synths. The function returns a single Midi-byte value (7-bit number) as an integer. If no information was found in the midi input buffer, the function returns -1.

The two versions of the function retrieve resp. the most recent information found in the buffer or the oldest information present in the midi input buffer. Normally only the function GetOldController% will we used.

GetNewMidiNote% (k?, remove?)

GetOldMidiNote% (k?, remove?)

The first function reads the most recent note information from the midi-in buffer and returns an integer value composed of the note and velocity information as two Msb%-Lsb% bytes (Note-byte & Velocity-byte). The function does delete the data it returns from the buffer, if the remove? parameter is set. The parameter k? stands for the midi-channel from which to read a byte. Thus legal values of k? should be limited to the range 0 - 15. If no data was found in the buffer, the functions returns -1.

The two versions of the function retrieve resp. the most recent information found in the buffer or the oldest information present in the midi input buffer.Normally only the function GetOldMidiNote% will we used.

GetNewPressure% (k?, remove?)

GetOldPressure% (k?, remove?)

Analogue to previous functions, this one returns key pressure information (160 + channel,note, value byte sequences). The value returned by the function is an integer packed with 2 bytes. If no data was found in the buffer, the function returns -1. The note byte is the msb, the value byte is the lsb.

The two versions of the function retrieve resp. the most recent information found in the buffer or the oldest information present in the midi input buffer.

A bug in versions before 2.3 - we forgot that this message returned 2 bytes- has been killed.Normally only the function GetOldPressure% will we used.

GetNewPitchBend% (k?, remove?)

GetOldPitchBend% (k?, remove?)

This function operates just like reading the bendwheel information but it returns the bend value in cents directly instead of the awkward shifted 14-bit msb-lsb format defined in the midi standard. The function reads the most recent pitch-bend information from the midi-in buffer for the channel passed in k% (range=0-15) and returns a value in CENTS (+/- 100) based on the bendrange set in your equipment. Bendrange is supposed to be set to be +/- 1 semitone on you hardware prior to using these functions. Normally only the function GetOldPitchBend% will we used.

GetNewAfterTouch% (BYVAL k?, BYVAL remove?)
GetOldAfterTouch% (BYVAL k?, BYVAL remove?)

Analogue to previous functions, this one returns aftertouch information. The value returned by the function is a single byte packed in an integer. If no data was found in the buffer, the function returns -1.

GetNewProgChange% (BYVAL k?, BYVAL remove?)

GetOldProgChange% (BYVAL k?, BYVAL remove?)

Removed obsolete functions from versions prior to 2.7:

Section library: Harmony Library Harm_Viz

DECLARE SUB ShowStaff (crd%, v%, h%)

DECLARE SUB DrawFclef (v%, h%)

DECLARE SUB DrawGclef (v%, h%)

DECLARE SUB ShowLargeStaff (crd%, v%, h%)

SUB ShowStaff (i%, v%,h%)

This procedure is equivalent to ShowCrd(), but makes use of internal graphics statements offered by Microsoft Basic. The displayed chords look much better, but the procedure is about 20% times slower.

(2.5ms on a 100MHz Pentium). The parameters are the same is for ShowCrd().

SUB ShowLargeStaff (i%, v%,h%)

This procedure is again equivalent to the previous ones, but displays the staff and notes twice as large on the screen. We implement the function to allow us using the screen to communicate with musicians in performances of our music. This format is readable from a certain distance on a large monitor. Since there is a lot more to draw, this procedure is again slower then the previous ones. In this case a call takes about 6.4ms on the Pentium 100MHz platform.

With the following parameters for v% and h%, there will be place for 36 chords on a whole screen:

v%= 1 to 16, step 15

h%= 4 to 72, step 13 (if this is changed to step 12, the staves will connect and form an uninterrupted staff.

SUB DrawGclef (v%,h%)

SUB DrawFclef (v%,h%)

Removed from HarmonyLibrary.html:

These procedures are selfexplaining: the first one displays a G-clef in front of a staff drawn using the ShowLargeStaff procedure, whilst the DrawFclef procedure does the same for an F-clef. In the latter case, make sure you transpose your chord accordingly! Putting an F-clef will not handle transposition in itself. (The rotate or transposition functions provided in HARM_GEN can be used to this end).

The parameters v% and h% determine the screen coordinates and should be the same as those used when calling ShowLargeStaff. The clef should be placed after the staff is drawn.

The list for Microsoft PDS is included in the file KONSTANT.BI and we let its full content follow here:

CONST False = 0
CONST d0 = 1, d1 = 2, d2 = 4, d3 = 8, d4 = 16, d5 = 32, d6 = 64, d7 = 128, d8 = 256
CONST d9 = 512, d10 = 1024, d11 = 2048, d12 = 4096, d13 = 8192, d14 = 16384, d15 = 32768
CONST d16 = 65536, d17 = 131072, d18 = 262144, d19 = 524288, d20 = 1048576, d21 = 2097152
CONST d22 = 4194304, d23 = 8388608, d24 = 16777216, d25 = 33554432, d26 = 67108864
CONST d27 = &H8000000, d28 = &H10000000, d29 = &H20000000, d30 = &H40000000

' constants describing musical modes:

CONST md0 = 2741, md1 = 2477, md2 = 1453, md3 = 2733
CONST md4 = 2731, md5 = 2795, md6 = 2507, md7 = 2475
CONST md8 = 1365, md9 = 585, md10 = 677, md11 = &HFFF

' midi-port I/O adress for midi-support module

CONST Madr% = &H330

' constants for tuning and fourier transform support in the module AKU

CONST Pi = 3.141592654
CONST Pi2 = 6.283185307

In the implementation for Power Basic 3.5 we had to circumvent the problem that it does not support non-integer constants. So we created a set of public declared variables. This file is named HarmKons.Inc. The type declarations for Power Basic can be found in the include file HarmType.Inc.

<Index >	<Introduction>	<General Functions>
<Fuzzy Functions>	<Analysis Functions>	<Acoustical Functions>
<Visualisation Functions>	<File Management>

Visit Logos' Homepage

Visit Godfried-Willem Raes' pages

Get the Harmony Library for Windows & Power Basic

Filedate: 2002-05-30