Documentation on use is after this history text. --------------------- 9-Nov-94 Jaleo 0.65 Previous versions were incompatible with some video BIOSes. - Slap bass OPL 2op patch cleaned up a bit (was bad at low freqs) - GUS FM LFO okay with any clock source (had required OnCard clock source) - \ now appended to [dir=] entries of R2*.INI files, if needed - Size keeps getting bigger because much of the R2 vox component is in this, and previous versions, but is not yet functional so has been "turned off" ---------------------- 21-Oct-94 Jaleo 0.63z Version included with Ruckus 1.1 shareware release. (now with the 0.65 version) --------------------- 8-Oct-94 Jaleo 0.63 MIDI files with SysEx events could cause problems in the 0.62 version code when using the GUS device, though you may not have noticed any problem. --------------------- 26-Sep-94 Jaleo 0.62 HIMEM.SYS can now be used. HIMEM.SYS is limited to 128 handles, and defaults to only 32. To get 128 use /NUMHANDLES=128. More might be available under Windows enhanced. Best, get 386MAX, or QEMM, or Memory/Net Commander, or something that permits more than 128 XMS handles. (One handle is used for each SuperCached patch, plus one for the INI and another for housekeeping.) ---------------------- 25-Sep-94 Jaleo 0.61b This is Jaleo. It's not quite ready for prime-time, but sure is close. It supports MIDI playback on OPL2, OPL3 (stereo), MPU-401 (generic, and specific support for TBS Maui and Rio), and the GUS (including SuperCache and patch caching). =========================================================================== How To Use Jaleo 0. You must SET PATDIR=path of R2*.INI and OPL *.PAT files This must be set if you play a file from other than the current directory. For example, if Jaleo's support files are in D:\TEST, do: C>set PATDIR=d:\test If you have more than one R2*.INI file, then read the following, else skip to JUMP START. Jaleo looks for the *.INI file in the current directory first, then in PATDIR=. If you have used the file manager to select a file from another drive/directory, then when Jaleo plays that file, Jaleo looks in the directory that Jaleo is currently in for the *.INI file. You can check the current directory by bringing up the FILE MANAGER dialog box. The current directory is shown across the bottom of the dialog window. If the selected device's R2*.INI file is there, then that INI is used rather than the one pointed to by the PATDIR= environment variable. This can be perplexing if you don't understand what's happening because you can edit what you believe to be the INI file and yet never have the changes take because R2 is actually using an INI located in the then-current directory. GUS users see R2GUS.INI files for additional path requirements. ---------- JUMP START ---------- 1. move MC (mouse cursor) to upper-right area and click 2. at first box (Setup), click the down arrow (or box) 3. select MIDI 4. change anything in the dialog box (default should be okay) 5. select okay 6. move MC to upper-left area and click 7. at first box (MIDI), click on device to use 8. change anything in the dialog box (default should be okay, but if OPL3 and SB-Pro, set base port to 2x0 (as in 220, 240, etc.)) 9. select init or cancel (only way to close the dialog box is to successfully init or to cancel) 10. move MC to upper-right, click on FILE box down arrow 11. select PLAY FROM 12. at file dialog box, select drive (if needed), and move to any directory (if needed), then pick up to 8 MIDs 13. select okay 14. press Play 15. alt-X is the only way to exit Odds and evens and in-betweens: 1) GUS in Windows needs to use PIO (selected with DMAdiv) unless you don't have the Gravis Windows driver installed, then you can use DMA. The Gravis VxD prevents notification of a DMA TC IRQ and so will time- out, or so I think. GUS users will probably want to boost the PercEQ to +6dB or so. This is in the MIDI setup dialog box. Makes a big difference. 2) Jaleo under Windows enhanced mode reports a CPU MHz rate always lower than it really is (I've seen from 5% to 50% of true speed). The CPU Load% bar and readings, likewise, are skewed to nonsense (the bar is pegged at 100%, as are the readings). No ill effects -- it's just the way Windows 3.x works. OS/2 should report correct results for both MHz and Load%, though it won't allow any of the font changes (I don't think it will, anyway). 3) Not sure how any of this runs in OS/2 2.0 (not recommended when using the DMA routines since 2.0 doesn't support VDS). Should run a-okay in 2.1. OS/2 behaves more like DOS in a VDM than Windows 3.x ever could, especially when you need to get directly to the metal. Warp? It should do fine in Warp. 4) A short error-is text message is shown next to error numbers. See the errcode.txt file for more detail on those. 5) Color VGA is recommended. Mono VGA should do okay. CGA should have its colors mapped okay, and same with MDA, but results will be less than intended (and not much was intended to begin with). 6) Rio/Maui users, when selecting specific support during init (i.e., not generic MPU-401 device), the DevLvl should be set to -6dB or lower (as in -9, etc.). Or, you can validate that no "DAC saturation" is occuring by looking at the pL: and pR: (peak L/R) and sC: (saturation count, to 32) which is updated every 7 seconds. This info is in the LOAD-STAT view screen, at the lower-right. Values of 7FFF means that that channel's DAC (left/right) is clipping. The sC: value indicates how many times it has clipped since the last reading (taken once every seven seconds or so). The access to on-board state info does tend to slow things down, so best results when using the Rio/Maui selection is to use a view other than LOAD-STAT, or to simply select "generic". Using the IRQ line would improve things when waiting for specific data from the device -- but you don't really need to read access the device while playing something, except if you want to look at those peak levels. 6a) SB16 + Rio users may want to use a /OPGAIN:3 since lower (1 or 2) results in too low of an output level, and 4 or higher seems to cause the SB16 grief (especially the right channel which pops obnoxiously). It's a shame that the Rio has to be mated to the SB16, considering how poor quality the SB16 is (SB line in general if you want my opinion). For AWE32 support -- it is not planned, nor possible, until Creative Labs releases adequate low-level documentation for it. CL's current policy is to restrict all programming development to in-house, CL drivers. Take my advice, don't buy an AWE32. You'll just be throwing out $300. The SB16 part of the AWE32 is of the same quality as regular SB16s, low. Buy something else, you'll be glad you did. If you already have one, tell CL to make low-level programming information available. 7) Rio/Maui users can set the number of voices if Rio/Maui support is specifically specified (i.e., not generic MPU-401 device). All MPU devices play only extended WDS (Windows dual-sequenced files) correctly, so do not select basic WDS (none is fine). The IRQ line is not required. 8) The 4op OPL patches are included though a 4op switch in this version is not provided. Basically a UI problem (have to code a channel selection routine (those 012345...EF drop menus). They need work, anyway, but then so do the 2op ones. A patch editor is already available. 8a) OPL users may want to reset the device (just drop the DEVICE MIDI and select OPLx again) to clear any remaining sound from an early out (stop pressed). I just noticed this (at a high volume). The included MIDI file sounds very good on the Rio; pretty good on the GUS, but pretty odd on the OPLs. If you want to move into decent sound, pick up a Turtle Beach Maui. About $130 mail-order. It's a stand-alone MIDI soundcard (MPU-401 UART compatible, which is perfect). You can use it with your current SB, PAS, or whatever, to replace the often-funky sounding OPLx hardware. ...Night and Day. 9) The AIR value (in MIDI SETUP) should be at least 50% of DIR for good results. Less is okay, but you may notice slurring of notes. Bump the AIR (actual interrupt rate) to around 512 and all will be peachy (or try 32 if you want, or even 8192). The GUS has an onboard clock source that can be used (other cards currently need to use timer-0 or the RTC) and its clock works with DIR=AIR (or close). The GUS can also use the other two clock sources. 10) The SuperCache system is for the GUS and can load the entire standard patch set (5.5MB) into extended memory for near-instant loads. Patch caching is standard. If full 16-bit resolution won't fit in available GRAM (GUS RAM), a retry at 8-bit resolution is made (and R« shown in the LOAD-STAT view). You can SuperCache all patches, a selected subset (see the R2GUS.INI file for all-stars), or just the INI file. Each patch file SuperCached requires an XMS handle, so you may need to extend this amount. 200 should do it. Alt-x exits. --------------- Additional Info --------------- FOR THE GUS - The R2GUS.INI file has PISTOL.PAT used as program #127. If you don't have this patch file, but instead the old RINGWHSL.PAT, edit R2GUS.INI and uncomment the RINGWHSL.PAT entry and comment-out the PISTOL.PAT. PISTOL.PAT is available in the GUS0043.ZIP update, or the newer GUS distribution set. - Patch size is limited to 256K, with sample size limited to 256K. Larger patches can be used (512/512), but this forces all patches to be loaded in as 8-bit (currently). - In the R2GUS.INI file, to select alternate banks, use the MANAGER, MIDI, SETUP dialog box (current you can select from 8 different bank setups in the INI file). This can also be done directly from the SMF, provided it follows the MIDI 1.0 spec and sends both the low and high MSB (play with it). More to come. FOR ALL - Be sure to set the PATDIR= variable, as described above. - Filesize is currently limited to 64K. Larger files won't fly. Don't try. - And what exactly is the LOAD % you ask. This is a measure of the amount of time spent in the background versus nothing at all running. This takes into account all background tasks (e.g., the mouse registers about a 2% peak use). On the graphic, the green bar displays the peak usage, and the the bright-green bar the highest peak over the last second (i.e., it holds the highest peak encountered for each second). This peak reading is actually an average of usage over two periods of 1/40th of a second (0.025sec). So, the peak reading is the current usage over the last 1/20th of a second, where 0% is no use, and 100% is total use. Note that in order for 100% utilization to occur, two 1/40th-sec periods must be completely utilized; not a likely occurance. You can try pressing the PAUSE key on the keyboard momentarily, and when released, you will see a utilization of 50%. This because you can only pause the test code when it's doing ONE of the two tests for the peak average, and so 100% on one test, and 0% on the other (typically), results in an average of 50%, as displayed. The average reading, on the left, is the overall background CPU system utilization over the last second. In other words, it is an average (not a running average) of 40 of the tests (each test last 1/40th of a second). Base readings are taken at program startup, with all interrupts off (for 1/40th of a second, several runs, then averaged). A note on LOAD %. Since the time needed to wait for a device to respond is indepent of CPU speed, it is possible that you may see a higher peak % usage on faster CPUs than slow. This because the CPU is waiting for the device (a constant). Typical average results for most CPUs is around 1%; more on MPU-401 devices, to about 3%. The MPU-401 devices may have very high peak use, to around 30%, eventhough the average is 3% or less. This you will see happen, typically, at the start of play, where large amounts of controller and/or sysex info is sent to the device. The GUS, being 100% software programmed, won't have these momentary lapses of efficiency. Something like that, anyway... Jaleo was built using the current Ruckus 2 beta, available to registered users on the BBS. Current versions of this program, and Ruckus, the toolkit used to build Jaleo, are available for anonymous FTP at: cornel@crl.com anon ftp to ftp.crl.com /users/ro/cornel for Ruckus & Bullet -------------- WWW at ftp://ftp.crl.com/users/ro/cornel --------------- BBS/fax: +1-210-684-8065 / Monday-Friday after 5pm / Weekends 24 hours [-0600]