Ideal objectives:

• Ability of addressing parameters using several different relevant units
• Units of parameters and messages should be setable and getable
• Ramps should be possible to do in various units (e.g. linear or db fade out)

Implemented as attribute:

    @unit hz

Do we also need to specify what alternative units are accepted?

Test Cases:

Test case 1:

Frequency or pitch. Could be described as:
    @unit hz
    @unit radians
    @unit midi
    @unit cent

@unit radians depends on sample rate, and is thus in violation of Integra recommendations

Test case 2:

Gain value. Could be described as:

    @unit midi
    @unit dB
    @unit linear (linear amplitude)  
   

Syntax:

• Setting unit:
  /module/parameter:unit hz
• Getting unit:
  /module/parameter:getunit
• dump all attributes of parameter to module left outlet:
  /module/parameter:dump
• Abbreviated syntax:
  /foo/gain -6 db
  /foo/gain 127 midi
  /foo/gain -6 db ramp 2000
  /foo/gain 127 midi ramp 10000
• Should we operate with a default unit that need not be specified?
  /foo/gain 127
  /foo/gain 127 ramp 1000
• If so, do a message with abbreviated syntax alter unit temporary or permanently? Do the second line below set gain to 0 midi or 0 dB
  /foo/gain -6 db
  /foo/gain 0
• And how is the following to be interpreted, as a dB or midi increase?
  /foo/gain:inc

Unit conversion - native unit format required?

Either the parameter has to communicate value and unit to the algorithm, with conversion taken care of in the algorithm, or the parameter needs a native unit, with alternative units converted to native in jcom.parameter.

Pros of native unit:

• Parameters of @type msg_float or msg_int will store state as a single number. If used in combination with pattrstorage this enables interpolation between presets
• Algorithms gets simpler and more transparent

Cons of native units:

• It would probably be easier to implement ramping in a variety of units in the algorithm than in jcom.parameter. E.g. @type linear could be used for linear crossfades at the same time that @type midi could be used for exponential fade in or out.

Spatialization Case : relative and absolute coordinates

As discussed on the devel-list under the (Spatialization namespace proposal) thread and in SpatDIF - Spatial Sound Description Interchange Format xyz and aed (cartesian-polar) coordinates should be accessible both in :
- an absolute way (for simpler use in different spaces e.g.)
- a relative way (e.g. depending on the actual space, and distance-unit used, e.g. meters, feet, miles... etc...).

Having the relative mode would make a quite special case because then we would have the distances relying on the space's dimensions, that would be provided by the user each time the space changes...
Basically that's just a different scale to apply on each dimension, but then we would need something like another attribute to determine the “real-world" dimensions, something like @relative_dimensions 12. 15. 4. meters
Another parameter of the relative mode would be to determine if we use a corner of the room as reference point, or if we set this depending on the user/listener/spectator, which would create another challenge... because then we could have different reference points for different listeners and these could be moving individually as well...
Then we would need something like /reference_point/n ... though I'm still quite unsure how this would actually work...

Beside the xyz or aed (cartesian-polar)coordinate system there is also the question of distinguishing  different angular formats: deg,rad and gra.