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<g>).

I'm sorry I can't be of more help here (but I didn't write the Windows 
operating system<G>)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!"
-------------------------------------------------------------------------

