It is currently Fri Mar 29, 2024 9:37 am


Error in CODM manual

Using the CODM to create your own organ definitions, exchange CODM organ definitions, ...
  • Author
  • Message
Offline
User avatar

wurlitzerwilly

Member

  • Posts: 944
  • Joined: Tue Mar 06, 2007 11:21 am
  • Location: South Coast, UK.

Error in CODM manual

PostSun Mar 22, 2009 1:07 pm

Brett/Martin.

There is a mistake in the latest CODM manual for HW 3xx on page 122.

Table: ShortcutPiston

Starting on page 121, PistonActionTypeCode - Description column states "Determines how the piston will be linked to the target object.
Can be either:
4. Reversible.................
5. The piston will............"

The figures should be:
1. Reversible.................
2. The piston will............

Also, by chance I tried to compile a Custom ODF with no "ReferencedObjectTypeCode" set (by mistake).
HW complied nothing at all and returned to 'Standby' with no organ loaded, but did not give an error message. No big deal, but off-putting until I realised. :)

Actually, I just played with it a little more and there appears to be no error reporting for that section. If a StopCode is specified, but no ReferencedObjectTypeCode is set, it compiles OK. However, if a CouplerCode is specified but no ReferencedObjectTypeCode, HW just does nothing and no error message. I haven't tried it with a TremulantCode set, but I presume it will do the same.

Also, is it actually necessary to use a "ReferencedObjectTypeCode" field at all? If a "StopCode", "CouplerCode" or "TremulantCode" is specified, then the parser should (IMO) be able to tell which "ReferencedObjectTypeCode" is set.
Regards,

Alan.
(Paramount Organ Works)
Offline
User avatar

mdyde

Moderator

  • Posts: 15446
  • Joined: Fri Mar 14, 2003 1:19 pm
  • Location: UK

PostSun Mar 22, 2009 4:46 pm

Hello Alan,

There is a mistake in the latest CODM manual for HW 3xx on page 122.

Table: ShortcutPiston

Starting on page 121, PistonActionTypeCode - Description column states "Determines how the piston will be linked to the target object.
Can be either:
4. Reversible.................
5. The piston will............"

The figures should be:
1. Reversible.................
2. The piston will............


Sorry for the mistake. I've logged it as bug to correct in a future version of the document. (It was actually due to the word processor misbehaving with the list numbering.)

Also, by chance I tried to compile a Custom ODF with no "ReferencedObjectTypeCode" set (by mistake).
HW complied nothing at all and returned to 'Standby' with no organ loaded, but did not give an error message. No big deal, but off-putting until I realised. :)

Actually, I just played with it a little more and there appears to be no error reporting for that section. If a StopCode is specified, but no ReferencedObjectTypeCode is set, it compiles OK. However, if a CouplerCode is specified but no ReferencedObjectTypeCode, HW just does nothing and no error message. I haven't tried it with a TremulantCode set, but I presume it will do the same.


I've also logged that as a bug. If you don't specify a value for ShortcutPiston.ReferencedObjectTypeCode then it (correctly) defaults to assuming the object type is a stop. However, if you haven't actually specified a stop code then an error occurs internally, which prevents the organ definition being generated. Hauptwerk should trap that error explicitly and report it.

Also, is it actually necessary to use a "ReferencedObjectTypeCode" field at all? If a "StopCode", "CouplerCode" or "TremulantCode" is specified, then the parser should (IMO) be able to tell which "ReferencedObjectTypeCode" is set.


Although the object type could currently be inferred from which other fields have been specified, it was designed that way to allow flexibility to extend the functionality for other more complex situations later if needed. So that's intentional.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline
User avatar

wurlitzerwilly

Member

  • Posts: 944
  • Joined: Tue Mar 06, 2007 11:21 am
  • Location: South Coast, UK.

PostSun Mar 22, 2009 7:17 pm

mdyde wrote:Hello Alan,

Sorry for the mistake. I've logged it as bug to correct in a future version of the document. (It was actually due to the word processor misbehaving with the list numbering.)

I've also logged that as a bug. If you don't specify a value for ShortcutPiston.ReferencedObjectTypeCode then it (correctly) defaults to assuming the object type is a stop. However, if you haven't actually specified a stop code then an error occurs internally, which prevents the organ definition being generated. Hauptwerk should trap that error explicitly and report it.

Although the object type could currently be inferred from which other fields have been specified, it was designed that way to allow flexibility to extend the functionality for other more complex situations later if needed. So that's intentional.


Thanks Martin.

As you know, I usually report these things privately, but in this case I thought it might be better 'public' so others can correct their manuals immediately.

Naughty word processor! It's also changing some spellings. I notice things like "behaviour" now = "behavior", or is that part of the new corporate image. <grin>
Regards,

Alan.
(Paramount Organ Works)

Return to Custom Organ Design Module (CODM)

Who is online

Users browsing this forum: No registered users and 2 guests