Actions taken to create the helpfiles (Simone Spagnol and Davide
Rocchesso, IUAV).

impact_help.pd (2012/09/07): 

- written from scratch by looking at impact_2modalb~.maxhelp 

- default parameter values equal to those of impact_2modalb~.maxhelp

- parameters of the two modal objects and impact divided into three
  graph-on-parent subpatches, to hide the wiring

- all the first-inlet messages to impact_2modalb~ have been kept

- the three pickup points and phase-reverse toggles have been kept,
  although they can be removed

inertial_impact_help.pd (2012/09/07):

- derived from impact_help.pd

- default parameter values changed; six modes activated

- all the first-inlet messages to impact_2modalb~ have been removed,
  except for the specifiers of number of modes

- only one pickup point has been kept

friction_help.pd (2012/09/07):

- written from scratch by looking at friction_2modalb~.maxhelp 

- default parameter values equal to those of friction_2modalb~.maxhelp

- parameters of the two modal objects and impact divided into three
  graph-on-parent subpatches, to hide the wiring

- temporal control of the parameters of modal object 1, in two
  sections, as in friction_2modalb~.maxhelp. Parameters for temporal
  control have been named

- no presets (as in all other help patches, in
  friction_2modalb~.maxhelp there are many)

- rubber mass multiplied by ten (as compared to
  friction_2modalb~.maxhelp) to have sound

onebubble_help.pd (2012/09/07):

- derived from onebubble~-help_old.pd and similar to
  onebubble~.maxhelp (whose external is still affected by a bug that
  makes a strange buzz at the moment)

- _vum_dB has been removed

- the bubble parameters have been made accessible through a
  graph-on-parent subpatch

bubblestream_help.pd (2012/09/07):

- derived from bubblestream~-help_old.pd

- _vum_dB has been removed

- the bubble parameters have been made accessible through a
  graph-on-parent subpatch

- parameter reset button added; default parameters are slightly
  different from bubblestream~-help_old.pd

- as compared to bubblestream~.maxhelp, there are the same sliders in
  a different arrangement

splash_help.pd (2012/09/07):

- derived from splash~-help_old.pd

- _vum_dB has been removed

- the bubble parameters have been made accessible through a
  graph-on-parent subpatch

- as compared to splash~.maxhelp, there are the same sliders in a
  different arrangement

bouncing_help.pd (2012/09/07):

- derived from the old 1_bouncing.pd (now re-included in
  ../SDT_patches)

- the bouncing parameters have been made accessible through a
  graph-on-parent subpatch

- computation of bouncing parameters (including the _dropper
  abstraction) included in the sub_bouncing subpatch

- the low-level abstraction _inertial_impact (used in sub_bouncing)
  can also be opened with a switch from the main window. It allows
  fine control over the impact and resonator parameters. It is the
  same as inertial_impact_help.pd, with 10 additional inlets for
  remotely controlling the parameters, plus two outlets. The same
  abstraction is also used for breaking, rolling and continuous
  crumpling

- parameter reset button added; default parameters are slightly
  different from bubblestream~-help_old.pd

- the parameters of _inertial_impact are initialized to have an impact
  sound that is bouncing-compatible (i.e., not
  breaking-compatible). The initialization generates several messages
  in console ("inertial_obj_b: inertia <= 0 ?!! ...is set to minimum")
  probably due to order of modification of parameters. This doesn't
  seem to affect the sonic behavior, but it would be nice to remove
  them

- as compared to bouncing.maxhelp, here the object weight (or hammer
  mass) is not made is not made accessible in the main window. 

- The sequence of bounces is obtained as delayed bangs, rather than
  implicitely derived from energy dissipation. In this way it is
  possible to have a control of regularity. However, the
  object_softness doesn't seem to do much, also in the .maxhelp
  patch. The role of this parameter has to be re-investigated
  following the crypting notes in the Sounding Object book.

breaking_help.pd (2012/09/21): 

- derived from the old 1_breaking.pd (now re-included in
  ../SDT_patches)

- the breaking parameters have been made accessible through a
  graph-on-parent subpatch

- computation of breaking parameters (including the _dropper
  abstraction) included in the sub-breaking subpatch

- the low-level abstraction _inertial_impact (used in sub-breaking)
  can also be opened with a switch from the main window. It allows
  fine control over the impact and resonator parameters. It is the
  same as inertial_impact_help.pd, with 10 additional inlets for
  remotely controlling the parameters, plus two outlets. The same
  abstraction is also used for breaking, rolling and continuous
  crumpling

- the parameter "strike velocity" is already included in
  _inertial_impact. Therefore, it has been removed from the breaking
  parameters

- the parameters of _inertial_impact are initialized to have an impact
  sound that is breaking-compatible (i.e., not
  bouncing-compatible). The initialization generates several messages
  in console ("inertial_obj_b: inertia <= 0 ?!! ...is set to minimum")
  probably due to order of modification of parameters. This doesn't
  seem to affect the sonic behavior, but it would be nice to remove
  them

- parameter reset button added

- the order of the sliders and some of their names have been
  changed. At the moment, the first four sliders (resistance,
  graininess, tail_cut, and determinism) refer to the temporal
  sequence of events. The three remaining parameters (initial_strike,
  decay, and determinism) act on the intensity of each single impact
  by modulating the strike velocity parameter inside _inertial_impact.