Roland | GS-10 | GS-10 bugs - Mountain Utilities

GS-10 bugs - Mountain Utilities
Bugs in the BOSS GS-10
9 August 2005
Mark van den Berg
This document was sent to the
Roland/BOSS distributor in the Low
Countries in August 2005. However, I never
got any response, so if anyone can get
through to a Roland/BOSS distributor (in
whatever country), please let me know!
The BOSS GS-10 Guitar Effects System is a great device. However, the GS-10 does seem to
contain several bugs, which may have to be fixed by means of a firmware upgrade. This
document describes these problems.
Test conditions
All the phenomena described in this document were tested using a computer whose CPU was an
AMD Athlon XP 2100+. The motherboard was an ASUS A7V333 with 512 MB of RAM. The
operating system was Windows XP Professional.
For the MIDI input/output communication between the GS-10 and the computer, two setups were
The MIDI facility of the USB cable:
The GS-10’s Driver Mode was ‘Advanced.’ On the computer, GS-10 USB device driver
versions 1.0 and 1.0.2 were tested. The applications (GS-10 Editor etc.) used the ‘BOSS
GS-10 Control’ MIDI input and output devices.
Standard MIDI cables, running from the standard MIDI input/output sockets on the GS-10
to a third-party sound card in the computer. (The USB cable was unplugged.)
All MIDI-related problems occurred equally in both setups.
Values displayed on the GS-10 during the test sequence (started by holding the Tap and Chorus
buttons while the unit is being switched on): Ver. 1.00 [D749]; EEPROM Check: V1.00
Invalid equalizer responses
The GS-10’s frequency responses for the Low EQ and High EQ parameters of the Equalizer and
Stereo Equalizer effects are wrong for values below 0 dB:
The frequency response plots below (generated by a third-party frequency sweep program) show
the GS-10’s actual responses for several values of the Low EQ parameter (where the Lo-Mid, LoHigh, High EQ and Level parameters are kept at 0 dB). The table (on the right) picks out a few
relevant values. (Note: these values can even be estimated if one sends a 20 Hz signal to the GS10 and then checks the values produced by the GS-10’s own Meter.)
Low EQ parameter Actual response at 20 Hz
Low EQ
+20 dB
+20.0 dB
+15 dB
+15.0 dB
+10 dB
+10.0 dB
+5 dB
+5.0 dB
0 dB
0.0 dB
!5 dB
!2.3 dB
!10 dB
!5.5 dB
!15 dB
!10.7 dB
!20 dB
!24.0 dB
Thus, for most values below 0 dB the actual cuts are substantially less than what they
should be, but for !20 dB the cut is deeper than it should be!
The cause of this weird behavior must be a confusion between linear and logarithmic scales
in the GS-10’s algorithms for the Low EQ parameter: I have found that the GS-10’s actual
responses for the Low EQ values below 0 dB can be approximated by means of a formula like
20 × 10log (1 + 0.04705 × x), where x stands for the Low EQ value.
The High EQ parameter’s behavior is wrong in roughly the same way as described above
for the Low EQ parameter.
Since it’s just a matter of changing a few fixed parameter values in rather simple low- and
high-frequency shelving filter algorithms, it should be relatively easy to fix this problem in the
GS-10. (Obviously, current users would have to be warned that their patches might start to sound
different if their GS-10s are upgraded, but personally I would definitely prefer the upgrade.)
Anomalous muting by inactive FX-2 effect
When the selected (‘temporary’) patch on the GS-10 contains ‘FX-2: Flanger/On’ (e.g. preset
patches 127 or 164) and you then send any temporary patch containing ‘FX-2: Off’ (except if that
patch's FX-2 ‘FX Select’ parameter is also ‘FL’) from GS-10 Librarian (English Windows
versions 1.00 and 1.10) to the GS-10, then the sound is anomalously completely cut off in the
effect chain at the point of FX-2; sound is only restored when FX-2 is switched on again
‘manually’ by any means.
The following procedure demonstrates this problem:
On the GS-10 itself: select patch P101 (‘POWER LEAD’) via the ‘PATCH/VALUE’ knob.
In the GS-10 Librarian program: click on a ‘Temporary Read’ button. This should copy
‘POWER LEAD’ from the GS-10 into the Librarian.
On the GS-10: select patch P127 (‘FLANGE ME OUT!’) via the ‘PATCH/VALUE’ knob.
(In this patch FX-2 is active as FL.)
In GS-10 Librarian: click on the ‘Temporary Write’ button next to the ‘POWER LEAD’
patch. You should then see ‘POWER LEAD p127’ on the GS-10 display. (In this patch
FX-2’s FX Select parameter is PH; however, FX-2 as such is switched off.)
Play something on your guitar. The result: no output from the GS-10’s
speakers/headphones at all! (Scrolling through the Meter Mode positions, one finds that
the sound is cut off at ‘fx-2(ph)’ in the chain.)
The above procedure has been performed by several people on different GS-10s and
computers, each time with the same result, so the problem is not restricted to any individual GS10.
The problem is not specifically related to GS-10 Librarian: using any other MIDI
message-sending program leads to the same result. For instance, in GS-10 Editor the problem
occurs if we ‘import’ a Standard MIDI file (SMF, extension ‘mid’) containing P101 at a moment
when the GS-10’s patch is P127. (Note: the problem does not occur in GS-10 Editor if one opens
a gse file containing P101. However, this is actually a totally different situation: opening such
a gse file causes GS-10 Editor to first send the patch number ‘P101’ to the GS-10, so that the GS10 itself switches to P101 first (without problems), after which GS-10 Editor sends the actual
patch data (which is actually redundant in this case). In other words: the absence of the problem
in this case is totally expected.)
The cause of the problem is probably not a MIDI message overflow: the problem persists
even if long delays (e.g. 1 second!) are inserted between the different MIDI messages (making
up the temporary patch) that are sent to the GS-10.
No GS-10 ‘System’ setting (such as ‘Assign Hold’) appears to be able to remedy this
problem, nor does it seem to have anything to do with Expression Pedal or Assign states; for one
thing, sending the Assign parameters before the other temporary patch parameters doesn’t fix it
The only ‘solution’ that currently does seem to work is an ugly fix: namely to send an extra
MIDI message, setting FX-2’s FX Select to a different value (e.g. PH), before sending the
‘normal’ temporary patch messages. However, I’m not sure that even this works consistently.
My suspicion is that the cause of this problem is a fundamental flaw in the GS-10’s signal
flow logic in relation with the reception of temporary patch MIDI messages, in particular FX-2
messages. (When I inserted long delays between the messages, I found that the sound is indeed
cut off precisely at the moment when the FX-2 area of the temporary patch is received by the GS10.)
Harmonist: key vs. user scales
After a change to an individual effect note in a Harmonist User Scale, the GS-10 incorrectly
doesn't take the key into account when calculating the corresponding MIDI address used for
notifying the computer of this change.
This can be demonstrated as follows:
We select Harmonist as the FX-2 effect, with the following parameters:
HR1 Harm Scale1
D (Bm )
Now suppose the selected Harmonist User Scale 1 has all values at ‘unison’ positions,
i.e. all EFF values are equal to the corresponding DIR values (C , C, D , D, etc.).
We then select ‘DIR’ note C, so that the GS-10 display shows:
User1: C
Now we turn the ‘PITCH/VALUE’ knob clockwise, so that the display becomes:
User1: C +Db
Turning the knob has also caused the GS-10 to send the following SysEx message to the
F0 41 10 00 63 12 03 00 00 00 19 64 F7
So this reports that the value at MIDI address 03 00 00 00 has been set to 19 (meaning: 1
semitone up).
However, this MIDI address is incorrect here, because the key isn’t C/Am, but D/Bm. The
address whose value has actually changed on the GS-10 is 03 00 00 0A, since that is where the
note C lies in the key of D/Bm.
This is confirmed by comparing User Scale 1’s data before and after the change, via a data
request from the computer to the GS-10:
Request (sent from a computer program):
F0 41 10 00 63 11 03 00 00 00 00 00 00 0C 71 F7
GS-10’s response before the change:
F0 41 10 00 63 12 03 00 00 00 18 18 18 18 18 18 18 18 18 18 18
18 5D F7
GS-10’s response after the change:
F0 41 10 00 63 12 03 00 00 00 18 18 18 18 18 18 18 18 18 18 19
18 5C F7
So in spite of what the GS-10 reported when the PITCH/VALUE knob was twisted, the value
at MIDI address 03 00 00 00 hasn’t become 19 at all: it is still 18. On the other hand, the value
at 03 00 00 0A has indeed become 19.
In my view, the solution to this problem is simple: the GS-10 should be modified so that it does
send the correct MIDI addresses at all times.
A related problem with GS-10 Editor:
The GS-10 Editor program (at least the English Windows versions 1.00 and 1.10) doesn’t take
the Harmonist key into account at all, so in GS-10 Editor any user scale is displayed and edited
incorrectly whenever the key is not C/Am. For instance, setting a value in GS-10 Editor’s
‘Harmonist Scale Editor’ edits the wrong note on the GS-10! (This becomes very clear if one sets
the display of the GS-10 itself to the same Harmonist Scale, accessible via the FX-2 button if the
temporary patch’s HR1 Harm parameter is set to that scale.)
Note: As discussed above, when the GS-10 notifies the computer (i.e. GS-10 Editor) of a
data change, the GS-10 doesn’t take the key into account either, so then two ‘wrongs’ happen to
make one ‘right’. But of course this does not alleviate the mismatches that occur when data
changes are made in GS-10 Editor and sent to the GS-10.
Inconsistent Tuner/Meter mode messages
There is an inconsistency in the GS-10’s Tuner/Meter mode operation:
When the Tuner and Meter buttons on the GS-10 itself are pressed, the GS-10 sends totally
consistent MIDI notification messages to the computer, as shown in the table below:
Button pressed on GS-10
Current GS-10 mode
Exit + Meter
Exit + Tuner
However, when a computer program sends mode change requests to the GS-10 (via System
Exclusive messages), the situation is very different: When Tuner mode is triggered from the
computer to the GS-10, the GS-10 correctly echoes the Tuner mode back to the computer.
However, when the Meter mode is triggered from the computer, the GS-10 forgets to echo the
Meter mode back to the computer.
This is particularly problematic when the GS-10 was already in Tuner or Meter mode, since
in that case the GS-10 does echo the ‘Exit’ status back to the computer: so in that case the last
message sent from the GS-10 is indeed the Exit message, whereas the GS-10 has actually ended
up in Meter mode! This is demonstrated by the following table, showing the GS-10’s echoed
responses to the different mode change requests sent from the computer:
New mode (sent from the computer)
Current GS-10 mode
! (!!!)
Exit + Tuner
Exit (!!!)
Exit + Tuner
Exit (!!!)
It is debatable whether it would be worth correcting this inconsistency in the GS-10: the
GS-10 Editor program seems to work around this inconsistency (and third-party programs may
be able to do so too), but obviously it’s a highly inconvenient situation.
USB vs. Patch Level
The position of the (Master) Patch Level parameter in the effect chain is undocumented, but it
turns out to be situated after all the effects, i.e. immediately before the analog outputs:
Input , ..... [, Patch Level] , Output
However, there is an inconsistency in the relationship between Patch Level and the USB tap:
When the USB tap is placed in any position except at the very end of the effect chain, the
USB signal is not affected by Patch Level. This is just as expected. For instance:
Input , ..... , USB , Reverb [, Patch Level] , Output
By analogy, when the USB tap is placed at the very end of the effect chain, we would
expect the following order:
Input , ..... , Reverb , USB [, Patch Level] , Output
However, it turns out that this order does not occur. Instead, Patch Level now does affect
the signal sent from the GS-10 to the USB connection. In other words, it’s as if Patch Level
and the USB tap are reversed here:
Input , ..... , Reverb [, Patch Level] , USB , Output
I don’t know whether this contrasting behavior is intended or not. However, it is definitely very
confusing when one is playing around with the USB tap’s position in the chain.
Obviously there are two ways this behavior could be made consistent: to have Patch Level never
affect the USB tap, or to have Patch Level always affect the USB tap. (The latter would of course
require the application of a ‘copy’ of Patch Level within the USB tap itself – i.e. after the split-off
point from the rest of the chain.) Which of these two solutions is preferable is open to debate;
personally I would probably like Patch Level to always affect the USB tap.
Output Select responses
There may be something wrong with the Output Select parameter. I’m not sure whether there is
actually a problem here, but I thought I would mention it anyway:
The GS-10’s global ‘Output Select’ parameter has 5 values: Line/Phones, Combo AMP, Stack
AMP, Combo Return and Stack Return. However, as far as I could tell, there is no difference
between the responses for Combo AMP and Stack AMP, as shown in the frequency response
plots below. (N.B. Line/Phones is not shown separately: it has a completely flat response.)
Combo AMP/
Stack AMP
Combo Return
Stack Return
Several explanations for this seeming anomaly are possible:
There is no problem: The above frequency response plots are in fact incorrect or have
missed some aspect of Combo AMP and Stack AMP in which these settings do differ.
The identical responses for Combo AMP and Stack AMP are intentional.
This would be very strange, in view of pp. 16 and 29 of the Owner’s Manual, where
Combo AMP and Stack AMP are mentioned separately in several pieces of setup advice.
The identical responses for Combo AMP and Stack AMP are caused by a design error in
the GS-10. If this is the case, the problem should be corrected.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF