From shampoo@unix.infoserve.net Wed Dec 13 11:19:39 1995 From: shampoo@unix.infoserve.net (Splice) Subject: GS/XG interesting info! Newsgroups: comp.sys.ibm.pc.soundcard.advocacy,alt.music.midi,comp.music.midi,comp.sys.ibm.pc.soundcard.games,comp.sys.ibm.pc.soundcard.misc,comp.sys.ibm.pc.soundcard.tech,comp.sys.ibm.pc.soundcard.music Date: 12 Dec 1995 22:59:54 GMT Path: cs.ruu.nl!sun4nl!EU.net!newsfeed.internetmci.com!news.kei.com!nntp.coast.net!torn!news.bc.net!news.infoserve.net!unix.infoserve.net!shampoo Lines: 403 Message-ID: <4al1ha$kak@news.infoserve.net> NNTP-Posting-Host: unix.infoserve.net X-Newsreader: TIN [version 1.2 PL2] Xref: cs.ruu.nl comp.sys.ibm.pc.soundcard.advocacy:10165 alt.music.midi:10876 comp.music.midi:797 comp.sys.ibm.pc.soundcard.games:11153 comp.sys.ibm.pc.soundcard.misc:14042 comp.sys.ibm.pc.soundcard.tech:21650 comp.sys.ibm.pc.soundcard.music:11198 Roland Sound Canvas/Yamaha XG Series Tips File No 1 (By G.Gregson Author of SCedit/XGedit) Introduction The intention of these Tips files is to provide a series of 'How To' answers to commonly asked questions, regarding the operation and use of these popular sound modules. As the author of SCedit and XGedit, I make no apologies for the references to these excellent editors in carrying out the procedures (although other programs may be used to accomplish the same goals if desired). If you don't like this, or feel that the files read as a a blatant sales pitch for the editors, then you're right!....so please don't read them....enough said!!! A large number of the tips are derived from users questions regarding the ove products. Therefore don't be surprised if you find I've already explained a certain procedure to you personally. However I would like to thank all users (too numerous to mention by name) in advance for their indirect help in producing these files. All trade names/marks etc. are acknowledge and in no way indicate endorsement of these procedures or products. (although XGedit is officially endorsed by Yamaha UK). THIS FILE IS PROVIDED ON THE UNDERSTANDING THAT THE USER ACCEPTS ALL RESPONSIBILITY FOR USE OF THE ENCLOSED TIPS. THE AUTHOR WILL NOT BE LIABLE FOR ANY DAMAGES OR LOSS OF DATA INCURRED BY USE OF THE TIPS. You may not distribute these files for profit except by prior arrangement with the author. GS/XG Overview Question: What is GS/XG and how does it relate to GM? Answer General MIDI standard Level 1 is an MMA ratified specification designed to standardise midi instrument responses to midi files. The intention being to deliver a format by which midi files can be played on different instruments and still provide the same results. To this end the GM spec defines 128 basic patches (sounds or voices) which must be available within all GM instruments. In addition the spec defines a standard drum map (for channel 10 use only), together with a series of defined controller messages. Roland felt that General MIDI didn't go far enough, so created a superset of General MIDI Level 1, which they called the GS Standard. Latterly, Yamaha have also recognised the GM limitations and introduced their own XG specification. The basis behind both specifications is that they obey all the protocols and sound maps of General MIDI but also provide many additional controllers and sounds. Many of the additional controllers provide control over the synths internal working for such things as envelope generation and effects units. These are termed non registered parameters numbers NRPNs, and provide access to features more commonly associated with cumbersome System Exclusive midi messages. Additionally the GS NRPN messages form a subset of the XG messages and may therefore be safely used in songs aimed at both series of modules. It should be noted at this point that System Exclusive messages are not officially covered under the GS spec but in practice are common throughout the range of GS synths (albeit some synths have a richer Sysex set than others). System Exclusive messages are covered under the XG spec but are NOT the same as those defined for GS synths. Interestingly Yamaha has seen fit to include a GS emulation mode in their XG synths (TG300 Mode), which does respond to GS individual parameter system exclusive messages, but not Bulk Dumps? Additional voice selections, beyond those defined by GM, are made using the MIDI bank select message. In both specifications, the bank select message should be transmitted in association with the relevant program change number. Note that the bank change message only comes into affect on receipt of a program change message (hence bank select must be sent first). The GS spec implements a scheme whereby the new bank number must be present in both the MSB and LSB of the bank select message. This can cause problems in some sequencer software, leaving the user wondering what's going wrong! The XG spec is more forgiving, using the MSB to define normal, SFX or Drum bank selection and the LSB to define the actual bank. Therefore in most cases only the LSB is required. Both formats implement a scheme of variation tones, whereby the sounds found in the non GM banks, correspond to variations of the GM sounds of the same program number (e.g. on a GS synth - bank 0 [GM], prog 5, E.Piano may have a variation tone in bank 8, prog 5 of Detuned E.Piano). Both specs also operate a scheme of tone 'fallback', whereby if a variation tone is not present at a given bank program number, then the synth will fall back to using the corresponding GM tone. (the GS spec does this in a cascading fashion, i.e. falling back to the next lowest variation tone of the same program number....this can be confusing). The advantage of the fallback scheme is that if a song uses variation tones and is played on a synth of lesser specification (or purely GM specification) then the voicing will still be acceptable (although not ideal). Question What's the difference between GS and XG synths? Answer The main difference is that XG (being a later spec than GS), offers a greater range of parameters and compatibility across its range of synths. It also has to be said that the XG designers have had the benefit of hindsight in laying out their specification. Hence in general the specification is easier to understand and use. In particular the XG spec offers a much greater range of additional tones (that are guaranteed to be present in all XG synths), plus a more sophisticated effects unit and greater control over envelope generators. It is my belief that 'straight out of the box' the sounds provided by both series of modules are rather dull. Sure, the standard effects macros and variation sounds offer some respite from the overused GM sounds, but the real power of the modules is not fully realised until the user picks up the courage to start tampering with the sounds. It is at this point that the little black boxes come into their own. In this respect the XG modules are somewhat superior. In particularly the greater number of available editable parameters gives rise to finer control over the sounds. Plus the ability to apply effects globally (as per GS) and simultaneously by insertion (i.e. to individual parts) is amazing (e.g. you can set up the general ambience of a song by applying Reverb and Chorus to all parts in the desired proportions, then you can add an additional effect to a single part using the insertion/variation effects). As far as sound quality is concerned; this is a matter of personal taste. Some people claim the Canvas series sounds better, but I suspect its more of a case of what you are used to. In general both offer a good mix of great, indifferent, and down right dreadful sounds. The only real difference here is that the XG series offer more sounds as standard. Its also worth noting that the GS series offers ten or more drum kits, but only two of these are available at any given time. The XG series offers a similar number of drum kits, but all are available all of the time (the only restriction being that only two[or four on the MU80] may be edited variations of the original kits). Getting Ready To Edit OK you've selected every patch your little black box has to offer......and still you can't get that lead guitar sound your masterpiece needs. What do you do now? Go out and buy a Prophecy? .......No! you download SCedit/XGedit and prepare for some serious editing. By the way....you may like to think about registering first....because its going to make life easier in the long run................ Question How do I get my system to allow more than one program at a time to access the synth? Answer You are obviously using a single session multimedia driver. i.e. only one program on the system can use it at any given time. However there are multi session output drivers available which allow multiple programs to output to the driver (but only one program to input) Such a driver is the Twelve Tone MPU401 driver (shipped with Cakewalk, but requiring separate installation from the Windows Control Panel/Drivers applet). More useful though, is Herman Seibs MULTIMID driver. This can transform any 16bit single session driver into a multi session driver for BOTH input and output. Additionally it provides software routing of data >from a drivers output to another drivers input! This allows you to record SCedit/XGedit output directly into a sequencer while your midi file plays in real-time (without the need for an external midi loopback cable) You can obtain Multimid from the following electronic sources: CompuServe GO MIDIFORUM INTERNET Sound Canvas User Group (SCUG) http://www.io.org/~stillwp Note Multimid will only work with 16bit drivers. If you are running under Win95, chances are you are using the supplied single session 32bit drivers. In this case I would advise you to re-install some older 16bit drivers or wait until Herman writes a 32bit version of Multimid. (In my experience there is no loss in performance and plenty of functionality gains to be had from this retrograde). Question I can't get the Multimid thing to work though. It keeps freezing up. Answer If its freezing, its probably because you are piping the output of a driver straight back into its input and thus creating a never ending loop. The correct set-up is to use Multimid to overlay just your output driver. Then set-up the editor and sequencer ports as follows (for non MPU use substitute your output drivers name for MPU-401) SCedit/XGedit OUT should be set to PIPE MPU-401 IN SCedit/XGedit IN should be set to MPU-401IN Sequencer OUT should be set to MPU-401 OUT Sequencer IN should be set to MULTI MPU-401 IN Question I can't get the editor to talk to synth Answer To test if the module is in communication with the program, right click on the display keyboard. If you hear the notes being played then everything is OK. If not :- Confirm the correct drivers are installed by using an alternate program to drive the synth from Windows. Check all midi leads are correctly connected. Once you can hear notes being played from the keyboard, try moving the volume knob within the Part module. If the sound level from the synth changes accordingly then everything is OK. If not:- With SCedit select the Reset All menu or with XGedit select the XG Reset button to ensure the synth is in the correct mode. Check the UNIT Number displayed in the Master Module matches that of the Attached synth (if in doubt Press the GM button and try the Part volume knob again. If the knob now works, then you have probably changed the default setting (16) for the UNIT number. Click on the GM button again to return to Sysex mode and adjust the UNIT number dial until the volume knob works. Question What's all this business about SCedit/XGedit providing real-time editing? Answer The whole idea of producing these editors, was to deliver real-time performance i.e. when you perform edits, they are applied in real-time (much the same as they would be from a control wheel or knob on a real synth front panel). Unfortunately standard Windows controls don't work that way......they only send a value when the control is released. Hence if you move a slider it only sends the final position value (and not the values in between). What this means, is that if you use a conventional editor such as CanvasMan (a fine product.......) then you won't get smooth transitional effects. SCedit/XGedit have been written to overcome these problems, allowing you to hear the transitional changes as the controls are moved, and thus allowing you to get exactly the effect you're after. Furthermore, if the control edits are recorded in real-time they can be used as dynamic effects throughout the body of a song (whooshing filters, wha..wha, LFO ramps) i.e. the sort of effects only provided by synths costing many times the price of your little black box! Question I've tried recording SCedit/XGedit in real time......I can hear the changes but my sequencer doesn't record them. Answer In normal operation SCedit/XGedit output system exclusive parameter change messages, in order to provide access to all available parameters. Unfortunately many (budget) sequencers, such as CakeWalk, provide real-time thru of such messages but don't provide real time recording . Consequently you can hear the edit effect, but it isn't recorded. For true real-time system exclusive recording you will have to upgrade to a sequencer like Cubase. However, all is not lost, most of the important edit parameters are available via GM like Controller messages. These messages can be recorded by all sequencers in real-time. To use this form of editing, press the GM button on the editor. You will notice many of the controls become grey, indicating that they are not available. However the remaining controls should now be correctly recorded by your sequencer (these include Part Envelope, Filter Resonance/Cuttoff, Vibrato and Drum controls) In general the user should be aware of the advantages and disadvantages associated with each mode:- Sysex Messages Allow individual parts to be edited even if they share a common midi channel. Difficult to selectively filter Encompass all available edit parameters More compact for large dumps, therefore faster to transmit. Better for global set-ups Controller Messages Can cause unpredictable or undesirable effects if two parts share the same midi channel Easily selectively filtered May only be used for parameters with equivalent controller, RPN or NRPN numbers. More compact for smaller edits and hence best suited for use within the body of a song. Question I'm experiencing quite noticeable delays when using midi thru on my midi application. Do you know any techniques for getting around this? Answer I'm afraid its down to the way the PC and Windows works!!!! The problem is, that the only LEGAL way of dealing with midi IN within Windows is to set up a Call-back routine. What this does, is direct message received at the IN port to causes an event message to be posted to the Call-back window(application) message queue. However this has problems where 'critical' timing is required:- 1. The serial port (midi) device drivers do not post the event message until a whole midi message has been recieved (therefore in software thru mode the midi bytes do not 'Stream'through the computer .....but are blocked up into packages...hence causing audible delays). 2. The message queue of the application also has to deal with all the other interface messages to the application. Therefore if the application is quite busy (i.e. lots of mouse movement and redraws happening) then there can be a significant delay while messages already in the queue are dealt with (note the queue operates on a First In First Out basis). 3. Windows 3.1 is not PRE-EMPTIVE. Therefore if another application grabs the CPU and does not release it often enough.....all other applications suffer (slow down...or worse still, fail to empty their message queues before they overflow...causing loss of events).Try formatting a floppy disc whilst using a soft midi thru!!!!!! These problems do not affect midi players (i.e. midi OUT) as much, because the application can provide a large buffer of midi events to the output port and let the LOW level operating system interrupts deal with the timing. The only real way around the problem is not to use Windows for software thru (i.e. use external hardware or run in DOS, where an application has exclusive use of the CPU). However, there are a few things you can do to help Windows:- 1. Ensure you always have plenty of ACTUAL memory available (this prevents Windows from paging VIRTUAL memory to disc and thus tying up the CPU with disc transactions (which are dealt with at high priority!) 2. Avoid running any un-needed applications (screen savers, clocks etc...). They may appear to be dormant.....but are in fact consuming background timers (CPU) and memory. 3. Upgrade to Windows95.......this version is pre-emptive and therefore should relieve some of the timing delays. Additionally, since it is 32bit, data can be shifted around faster. The down side is that it really requires about 12Mbytes of installed RAM before any performance improvements are noticeable. Secondly, until true 32bit midi applications become available, all calls to the midi ports will still be thru the Windows 3.1 compatibility stuff (which is all 16bit and NON pre-emptive....in fact even worse than just a plain Windows 3.1). Note: beware of applications claiming to be 32bit Win95 compatible. Most apps I have seen so far, may use some of the 32bit API, but are still using 16bit code to the drivers!!! 4. Always use a true MPU401 card (not a SoundBlaster). The MPU supports processing of midi events in hardware, whereas the SB16 etc use software. The best card is Rolands Super MPU401 (but expensive for what it does). I'm sorry I can't be of more help here (but I didn't write the Windows operating system)Hopefully when Win95 takes off, more TRUE 32bit applications will appear (as well as new multi channel midi sound cards....i.e. cards with processors that handle multi channel midi data in hardware....thus removing the timing from the CPU....these are supported under the new Win95 Multimedia architecture). Until then you'll have to tolerate the timing imperfections or use alternate hardware. Lets Get Editing! The next Tips file will discuss the various editable parameters available within the synths........so download the editors and register them to make sure you're ready!!! Gary Gregson 19th October 1995 -- -- Splice Proud owner of a Yamaha DB50XG * Vancouver, BC, Canada * Internet: shampoo@unix.infoserve.net "Good friends, are friends that stab you in the chest, not the back!" -------------------------------------------------------------------------