CODM regressed?

As far as im aware, after version 3.21, a drasic change was made to how the program imports version 1 .organ files, along with how hauptwerk stores its voicing information.

With older versions, all column headers had appropriate names, however in the new version, they are handeled as a, b, c, etc. This is all very well (im assuming this is for space saving purposes, as xml is very inefficient with column headers) but for me this has taken away my only reference point for knowing what a correspnds to. It also makes using the pipe voicing as part of the development process nigh on impossible, as I cant make sense of what genric column a actually contains, etc.

I have been using the hw v1 import due to the relative simplicty of the old scripting language. When you are working on a reasonably large organ (one we have been building has just under 50 stops), the sheer quantity of pipe and data references in the xml file is overwhelming. For that reason ive let hw do most of the work for me, and then use this import as my start point, to further implement wind modelling and other hw3 features. Is there any reason for this generic naming of columns, or perhaps better, a way to circumvent this? It has irritated me so much I actually rolled back to hw3.1 which is what im currently using for the development of this instrument. This way i can copy data between the configuration file and the organ defenition file with relative ease.

Also while im at it, does anyone know of an xml editor which presents true querying of xml tables, as you would do a database. I really would like to see something like how access can query multiple tables, and show all the data at once. Then you can batch copy/update data from one database to another (ie my config file and my odf). I've toyed with x-query but its pretty useless. I know there is also an sql license or something, but how does this actually function?

Appologies if this sounds like a rant, just this really seemed like a massive regression to me, and id quite like to know why.

[mdyde]

Hello,

The CODM itself doesn't use 'compacted' XML format - only the 'full ODF' format is compacted. The XML auto-compacting functionality for v3.20 and later allows organ definition files (ODFs) to load much more quickly.

However, you can just turn it off if you want to see/edit the ODFs in full (non-compacted) form (at the expense of loading times). The options to turn auto-compacting are on the 'General settings | General options | Design tools' screen tab:

The release notice and user guide also cover the XML compacting functionality and options to disable it in more depth (on the Help menu in Hauptwerk).

Here's the section from the release notice:

ENHANCEMENT HW-000957: Performance: compacted XML written in abbreviated form for significant reduction in organ definition and settings loading times.

When Hauptwerk writes XML files in 'compacted' form, very short XML tag names are now used for objects and attributes, and whitespace is reduced, significantly reducing loading times for organ definitions and settings files (for example, halving the time taken to parse some large/complex organ definitions). Because the tag names are unlikely to be intelligible to a human, compacted XML files cannot readily be edited directly using a text or XML editor so sample set producers would normally need to ensure that XML organ definitions are (re)generated in full, non-compacted format before attempting to edit them. Settings exist to enable non-compacted versions of XML files to be generated on the 'General settings | General options | Design tools' and 'Design tools | Load organ (with design options)' screens, as they did for Hauptwerk versions 3.10 and 3.11. These steps are not required if using Hauptwerk's MySQL integration which handles XML compacting/expanding transparently.

http://www.hauptwerk.com/releases

I have been using the hw v1 import due to the relative simplicty of the old scripting language. When you are working on a reasonably large organ (one we have been building has just under 50 stops), the sheer quantity of pipe and data references in the xml file is overwhelming. For that reason ive let hw do most of the work for me, and then use this import as my start point, to further implement wind modelling and other hw3 features.

Are you sure you're actually looking at the Custom Organ Design Module (CODM), rather than the 'full' (compiled) ODF format? The CODM is specifically deisgned to be quick and easy to edit (at least as easy as the Hauptwerk v1 format was).

The CODM user guide covers it - on the Help menu in Hauptwerk, or on-line here:

http://www.hauptwerk.com/documentation

You can find some example CODM organ definition files in the Hauptwerk\HauptwerkUserData\CustomOrganDefinitions folder, including a CODM version of St. Anne's for you to try.

The 'full' ODF format is very complex, and not designed to be user-editable, whereas the CODM format is intentionally designed to be as quick and easy as possible.

I'd recommend using the CODM for creating any organ definitions, rather than using the (obsolete) v1 format, since the v1 format won't allow you to take full advantage of v3's features or realism.

Is there any reason for this generic naming of columns, or perhaps better, a way to circumvent this? It has irritated me so much I actually rolled back to hw3.1 which is what im currently using for the development of this instrument.

New features are always documented in full in the release notice (and user guide), all of which can be found on the Help menu.

Also while im at it, does anyone know of an xml editor which presents true querying of xml tables, as you would do a database. I really would like to see something like how access can query multiple tables, and show all the data at once.

Have a look in the CODM user guide, which has some recommendations for free XML editors.

Martin,

My sincerest apologies! I have totally missed the point of the CODM; I thought I read through the manual but must have somehow assumed that it was basically very similar to the full organ defenition format. I shall have another read through.

It has actually worked out ok, as by working with the imported xml file, I have been able to fully implement v3 functionality (painfully at the least), however the compacting item is just what i was after. Thank you. I guess I should start reading release notes.

Am i right in assuming that a custom organ whence loaded in generates a new full organ defenition file in the C:\Hauptwerk\HauptwerkSampleSetsAndComponents\OrganDefinitions folder? I remember reading something about regenerating parameters so im assuming this is it.

My only worry with this is I have begun working with the full odf for more complex things such as copying of per pipe voicing tables (eg pitch, vol, eq) from the config file to odf. Also with wind modelling, I have been routing C and C# to different windchests etc, and from my quick look in the codm, wind is handled per rank. Is it possible to work with both, or what is at least the normal procedure whence releasing a commercial fully featured set?

[mdyde]

Thanks - no problem.

Am i right in assuming that a custom organ whence loaded in generates a new full organ defenition file in the C:\Hauptwerk\HauptwerkSampleSetsAndComponents\OrganDefinitions folder?

That's correct. The CODM reads CODM ODFs from:

..\Hauptwerk\HauptwerkUserData\CustomOrganDefinitions

... and compiles them to 'full ODFs' in:

..\Hauptwerk\HauptwerkSampleSetsAndComponents\OrganDefinitions

I.e. the idea is that you would normally always edit the (source) CODM ODF files in the former folder, and then recompile (by selecting 'Design tools | Load custom organ' in Hauptwerk).

My only worry with this is I have begun working with the full odf for more complex things such as copying of per pipe voicing tables (eg pitch, vol, eq) from the config file to odf. Also with wind modelling, I have been routing C and C# to different windchests etc, and from my quick look in the codm, wind is handled per rank. Is it possible to work with both, or what is at least the normal procedure whence releasing a commercial fully featured set?

There's no way of de-compiling from a 'full ODF' format to a CODM ODF format, since the CODM format is (intentionally) simpler, so as to be easier and quicker to work with. What some sample set producers do is to work in the CODM initially, and then only edit the compiled 'full ODF' as a final stage for any complex things that aren't adjustable in the CODM (e.g. transfer voicing from the the settings files).

There's no way of de-compiling from a 'full ODF' format to a CODM ODF format, since the CODM format is (intentionally) simpler, so as to be easier and quicker to work with. What some sample set producers do is to work in the CODM initially, and then only edit the compiled 'full ODF' as a final stage for any complex things that aren't adjustable in the CODM (e.g. transfer voicing from the the settings files).

I find that this is by far the easiest way to write a full ODF. All of the hard work and cross-referencing is done by the CODM and then I transfer the generated ODF into MySQL to do anything that the CODM doesn't handle natively. Works well for me.