diff --git a/_manual/22_using-control-surfaces/02_devices-using-mackielogic-control-protocol/02_ssl-nucleus.html b/_manual/22_using-control-surfaces/02_devices-using-mackielogic-control-protocol/02_ssl-nucleus.html
index e0cb924..fb16f31 100644
--- a/_manual/22_using-control-surfaces/02_devices-using-mackielogic-control-protocol/02_ssl-nucleus.html
+++ b/_manual/22_using-control-surfaces/02_devices-using-mackielogic-control-protocol/02_ssl-nucleus.html
@@ -146,7 +146,8 @@ title: SSL Nucleus
 <h3>Cons</h3>
 <dl>
   <dt>No Master Faster</dt>
-  <dd></dd>
+  <dd>It is not possible to control the level of the Master bus or
+  Monitor section. Really don't know what SSL was thinking here.</dd>
   <dt>No dedicated rec-enable buttons</dt>
   <dd>You have to press the "Rec" button and convert the per-strip
     "Select" buttons into rec-enables</dd>
@@ -193,4 +194,18 @@ title: SSL Nucleus
     buttons, but this is only necessary because of the relatively few
     global buttons on the surface.
   </dd>
+  <dt>Builtin analog signal path</dt>
+  <dd>SSL clearly expects users to route audio back from their
+  computer via the Nucleus' own 2 channel output path, and maybe even
+  use the input path as well. They take up a significant amount of
+  surface space with the controls for this signal path, space that
+  could have been used for a master fader or more Mackie Control
+  buttons. The USB audio device requires a proprietary driver, so
+  Linux users can't use this, and OS X/Windows users will have to
+  install a device driver (very odd for a USB audio device these
+  days). The analog path also no doubt adds notable cost to the
+  Nucleus. There's nothing wrong with this feature for users that
+  don't already have a working analog/digital signal path for their
+  computers. But who is going to spend $5000 on a Nucleus that
+  doesn't have this already?</dd>
 </dl>