Yamaha SW1000XG Advanced Manualbook page 37

Cakewalk anomalies
Cakewalk has a unique way of handling system exclusive data. It takes the sysex bytes out of the MIDI file, and
places them in its own Cakewalk SYX viewer. It then adds a META21 (MIDI Meta event 21) to the event list at the
location where the sysex event occurred. This in turn calls the appropriate place handle where the sysex data is
stored in the SYX viewer window. For small amounts of sysex this is fine, however as we have now seen, the
SW1000XG (along with many other devices from a wide range of manufacturers) can use a lot of sysex data for
control of parameters. If a MIDI file that you load into Cakewalk does contain a large amount of sysex, Cakewalk will
sometimes try to place all of the data together in one great big sysex bank for the SYX viewer. This is a feature of
Cakewalk that may cause problems with your XG MIDI files.
This anomaly can be problematic for anyone using sysex, in so much that sysex cannot be handled in this way, as
sysex should be separated by at least 1 MIDI tick between each sysex string, and normally should go out in a specific
order. A classic example of this is the basic rules of XG.
For an XG device to be correctly initialised one should first send a sysex message for GM reset, this allows non-XG
devices to at least have a rough go at playing back the MIDI file if no XG device is present. This in turn should be
followed by a 200ms gap to allow the GM reset to work, and then an XG reset sysex string, followed by a 50ms gap
(The gaps give the system time to perform the resets), before sending any further sysex or controller data out. This
information is covered in great depth in our XG specification sheet, which is available from your Yamaha subsidiary
or from our Yamaha websites.
Cakewalk also handles program changes in this 'block together' way, taking the standard Bank select MSB message,
followed by the bank select LSB message, and program change, and converting them all into a single Cakewalk
patch change message. This is fine whilst working just inside Cakewalk, but as soon as you go to play your MIDI file
in another application, the program change message can be split back to it's former state in an incorrect order. This
also happens in Cakewalk with NRPN and RPN messages, where the data in concatenated together to form a single
event message.
Yamaha therefore recommend caution when playing or arranging complex MIDI files in Cakewalk which use lots of
sysex data. This is especially true if you make your MIDI file set-up bar in XGEDIT, and import it into Cakewalk. This
we must stress is not a limitation of XG or of XGEdit, but of the way Cakewalk (as of time of writing) handles these
data types. If you are purely constructing your MIDI file in Cakewalk itself, and saving as a Cakewalk bundle or work
file, then these problems should not manifest themselves. However as many people use XGEdit with Cakewalk, or
construct MIDI files in other applications, or aim to have them played in other applications, Yamaha feel that these
important points should be noted.
Cakewalk in version 9.0 introduced a new technology known as AudioX. The AudioX system basically defines the
control system framework for a soundcard or audio device within the driver code for the card itself. It contains many
parameters which make developing control surfaces for API based cards (such as the Yamaha DS2416, which does
not use MIDI for control, but low level API commands) easier. Its relevance to the SW1000XG however is minimal, as
the SW1000XG offers a far more broad-based method of support. This is by just using simple MIDI data for control,
which will work in every software application that supports MIDI.
The advantage of the SW1000XG method is that a mix made with the SW1000XG is written as standard MIDI events
to the event list, and consequently can be exported for use in other applications, whereas a mix made with low level
API calls or special event types cannot.
As of going to press, Cakewalk 9.0 began to address many of the anomalies covered in this chapter. Please
contact your local Cakewalk supplier for more info on this exciting new upgrade.
To summarise and make a few important points.
The SW1000XG is a little too complex to be supported effectively by Cakewalk StudioWare. Whilst small panels can
offer some control over the main synth parameters, trying to control many of the sysex based parameters can lead to
complications due to limitations in StudioWare with snapshots, and large amounts of sysex being sent out.
Cakewalk prior to version 8.03 would actively filter sysex thru, so please update to at least this version. This was due
to an anomaly with the Windows API. Cakewalk added the sysex thru feature to 8.03 when this anomaly was
resolved.
If you have a set-up bar created in XGEdit, be careful when loading it into Cakewalk, as it will sometimes 'block' the
data together to form a huge sysex bank which will result in the data ordering being incorrect. Also take some caution
with the option to reset controllers on stop in Cakewalk as this can affect playback of drum parts.
If you install more than 2 Hubi pipes (LB1 & LB2 is normal – LB3 & LB4 is for the more complex set-ups above) be
careful that you don't have an infinite loopback happening inside Cakewalk and XGEDIT. Make sure that pipes
feeding one way are not looping back on themselves (the diagram below shows how they should be configured)
The SW1000XG will not help with you running Cakewalk effects or Active movie style effects. It will help by reducing
the CPU load for mixing, and audio data processing (track playback) and using the SW1000XG on board effects
instead of some of the Cakewalk ones will obviously lighten your CPU use. Cakewalk's latency in mixing audio can
be greatly reduced by using an application such as XGEdit with the SW1000XG analogue mixer to control the volume
levels of the SW1000XG.
37