Jump to content

"Bugs" in the documentation

Recommended Posts

The subject says it all...




Documentation seemingly not updated (neither reference nor examples) after function has been changed for the argument :position. For example, the following example call throws an error
(length-divide2 '(1 2 2) '(1/16) '(1/4 1/4 1/4 1/4)
                :type 'n :position 'e)


> Error: There is no POSITION named: e.
>        Allowed POSITION: 'f (first) 'l (last) 'c (center) and '? (at random).


BTW: Unfortunately, that helpful error message is not shown if I try to directly output the above expression (e.g., with cmd-2). Instead it then says 
> Error: OMN Parse Error: (annotate (parse-omn-audition-phrase) (fail nil nil))


Ideally, when creating output the original exception with the much more clear error message would be thrown.
Anyway, thanks for such clear error messages! 
doc uses seemingly undefined function PITCH-VECTOR-MAP
LENGTH-ADJUST reference 
shown output of first example call to LENGTH-ADJUST incorrect (seemingly the value of my-phrase was changed later).
There are several similar errors in the documentation -- do you want such cases reported?
again, shown output of some calls to GEN-LENGTH-CARTESIAN incorrect (possibly the see changed later?)
Some functions used in code are reported as undefined by system (downloaded version 1.0.15665)
function INTEGER-TO-PITCH used in harmonic-path.rtfd
BTW: Calls to the function klangreihen in harmonic-path.rtfd also result in errors. 
If the count argument is not given to LENGTH-MODIFY, then seemingly count is randomised. That should be documented, otherwise it is confusing.
In the following example I would otherwise expect always the same result (a 1/16 added to all notes, but not the rests), but notes are randomly    modified or not.
  1/16 '(1/8 1/8 1/8 1/8 -1/8 1/8 1/8 -1/8)
  :operator 'add :type 'n)


Also, the value 'all for :type is not documented (but thanks for your error messages pointing that out!!)


VELOCITY-INVERT ignores dynamics marks like cresc. It would be useful if (and users may expect that) those are also inverted. 

If not, then at least the documentation should mention this for completeness.



VELOCITY-RETROGRADE reverses the order of dynamics, including marks like cresc., but it might make more sense for users if such dynamics are "turned around" in the result, e.g., (f> p) -> (p< f)


Of course, this is a bit more tricky :-)

Again, if not then the the documentation should perhaps at least mention this for completeness.


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

Terms of Use Privacy Policy