It is currently Thu Mar 28, 2024 7:03 am


Editor for ODF files

Sampling pipe organs and turning them into something you can play in Hauptwerk.
  • Author
  • Message
Offline

mren

Member

  • Posts: 4
  • Joined: Fri Mar 17, 2017 6:45 am
  • Location: Germany

Editor for ODF files

PostTue Mar 21, 2017 8:51 am

Hello forum,

I am currently waiting for my pre-built Hauptwerk setup (Noorlander) and have spent the time playing with the demo version of Hauptwerk and different sample sets. Because I wanted a custom design for one of the SP sample sets, I have manually changed the ODF file content. This was quite cumbersome because of the quite "verbose" file format and the non-semantic XML tag names.

Since this may not be the last time, that I have tried to or will do that, I thought about programming an ODF file editor (maybe as open source project?). — Not a fully graphical point-and-click application but rather a "smart" editor which knows the XML tags, maybe provides some technical help and sanity checks.

This leads to a number of questions:
- Is something like that already out there? AECHO might go in that direction but I think of a little bit more, actually http://organ.monespace.net/ORGANWORKS/s ... Aecho.html

- Would that be considered helpful or is it a complete waste of time?

- Is it possible to get a technical specification of the ODF format? This thread suggests so: viewtopic.php?f=4&t=15486&p=115914

- Is anybody out there who would take interest in (joining such a) project?

Thanks for your input; regards
Michael
Offline
User avatar

mdyde

Moderator

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

Re: Editor for ODF files

PostTue Mar 21, 2017 9:36 am

Hello Michael,

[Topic moved here.]

There are two organ definition file (ODF) formats :

- The Custom Organ Design Module (CODM)'s format, which is specifically designed to be reasonably easy to understand and use (for technical users), and is intended to be user-editable. Its user guide is on the Help menu in Hauptwerk, and we do support users creating and editing CODM ODFs (within reason). There are several third-party editors for it.

- The 'full' organ definition format. That isn't intended to be user-editable, is extremely complex, and it would easily be possible to crash or freeze Hauptwerk (or have all manner of other unintended technical consequences, e.g. with combinations, MIDI, auto-detection, Hauptwerk's component installer, etc.) if done incorrectly, or without a good level of understanding, since effectively it's a complex programming language and Hauptwerk couldn't technically/feasibly validate every possible error condition (indirect infinite loops, etc.). Whilst people can edit full-format ODFs if they wish, I think it's important to be clear that it's entirely at their own risk, and that we don't provide any official support for doing so (except to major sample set producers), apart from providing the relevant documentation upon request to licensed users. We also reserve the right not to provide any support when using Hauptwerk with any ODF that's been edited, given the potential for making things misbehave. I wasn't aware of any editors being available for the full ODF format.

mren wrote:- Would that be considered helpful or is it a complete waste of time?


From our perspective, I'd have some reservations about something being made readily available publicly that might encourage people to break things unintentionally (and severely) and thus risking causing a considerable amount of user problems and resulting support for us (especially given that we wouldn't have any easy/reliable way of knowing whether people had edited an existing ODF, and thus caused other issues indirectly, when contacting us for support).

If you really did want to embark upon it, then I think we'd appreciate it if you made it absolutely clear to users that they could easily break Hauptwerk, and that we won't provide support with any user-edited ODFs.

Of course, if you just wanted to make such a utility for your own use, then there would be no problems with that per-se.

mren wrote:- Is it possible to get a technical specification of the ODF format? This thread suggests so: viewtopic.php?f=4&t=15486&p=115914


I've sent you an email accordingly.

mren wrote:This was quite cumbersome because of the quite "verbose" file format and the non-semantic XML tag names.


You need to turn off XML auto-compacting to see the format in a human-comprehensible way. The sample set creator's guide covers that in depth.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline

mren

Member

  • Posts: 4
  • Joined: Fri Mar 17, 2017 6:45 am
  • Location: Germany

Re: Editor for ODF files

PostTue Mar 21, 2017 9:49 am

Hello Martin,

Thanks a lot for your helpful and open reply.

I know about the CODM, however, after a first look into the specification - and being an IT guy - I found it quicker and more straightforward to use the existing ODF 8)

My intension is that people like me will have a tool that actually helps them not breaking the XML code etc. by giving them more information about the tags and the general structure. Of course, those people should know that they could cause serious issues and work on copies (or have backups).

I think I will pursue the idea as a non-public project for now. If I come up with something that is actually running well, I might get in touch with you - if that's okay - to see if we should publish the program as a developer tool explicitely.

Thanks again;
Michael
Offline
User avatar

mdyde

Moderator

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

Re: Editor for ODF files

PostTue Mar 21, 2017 9:57 am

Thanks very much, Michael.

Yes -- of course.
Best regards, Martin.
Hauptwerk software designer/developer, Milan Digital Audio.
Offline

HeAu

Member

  • Posts: 105
  • Joined: Sat May 21, 2005 1:33 pm
  • Location: Austria, Salzburg

Re: Editor for ODF files

PostSat Mar 25, 2017 1:12 pm

Dear Michael!

MS Access is able to import XML-files. You only need to rename or better copy the ODF to *.XML . In MS Access then you can do all your changes and sanity checks in a very comfortable way. After this you can export the tables you changed to xml. BUT from my experience it is not possible to export all tables together in a single xml. Each table will be exported into its own xml file. You will have to replace the modified section in the ODF with the exported table. A modification of the header within the exported xml will be necessary too.
I thought myself to create some vba code to export and merge the multiple xml files together. But as I am not a sample set producer nor am I a licenced HW4 user I did not yet follow this path.

Rgds
heau
Offline

japrenticeuk

Member

  • Posts: 23
  • Joined: Sat Apr 29, 2017 1:32 pm

Re: Editor for ODF files

PostThu May 03, 2018 6:19 am

Jumping in to and old thread in case it helps anyone -

I have used Microsoft Access (version in Office 365). Importing ODFs is fine after changing the file extension to .xml

You get a table per "table" of the ODF. Of course all the id numbers are text fields so don't sort very well but a query doing a val() on the fields of interest can overcome this point.

As mentioned above one has to do more work to export multiple tables but a bit of VBA listing dummy queries that just display every field of the tables is not too hard
Code: Select all
Private Sub Command0_Click()
   ' Purpose: Exports the queried Organ tables to XML
 
   Dim objAD As AdditionalData
 
   ' Create the AdditionalData object.
   Set objAD = Application.CreateAdditionalData
 
   ' Add the related tables to the object.
   With objAD
       .Add "QqDisplayPage"
       .Add "qqTextStyle"
       .Add "qqTextInstance"
       .Add "QqImageSet"
       .Add "QqImageSetElement"
      .Add "QqCombination"
      .Add "QqCombinationElement"
       .Add "QqImageSetInstance"
       .Add "QqKeyImageSet"
       .Add "QqDivision"
       .Add "qqDivisionInput"
       .Add "QqSwitch"
       .Add "QqSwitchLinkage"
       .Add "QqKeyboard"
       .Add "QqKeyboardKey"
       .Add "QqKeyAction"
       .Add "QqRank"
       .Add "QqStop"
       .Add "QqStopRank"
      .Add "QqContinuousControl"
      .Add "qqContinuousControlStageSwitch"
      .Add "QqContinuousControlImageSetStage"
       .Add "QqEnclosure"
       .Add "QqEnclosurePipe"
       .Add "QqTremulant"
       .Add "QqTremulantWaveform"
       .Add "QqTremulantWaveformPipe"
      .Add "QqContinuousControlLinkage"
       .Add "QqSample"
       .Add "QqWindCompartment"
       .Add "QqWindCompartmentLinkage"
       .Add "QqPipe_SoundEngine01"
       .Add "QqPipe_SoundEngine01_Layer"
       .Add "QqPipe_SoundEngine01_AttackSample"
       .Add "QqPipe_SoundEngine01_ReleaseSample"
       .Add "QqRequiredInstallationPackage"
' etc. etc.
   End With
   ' Export the Orders table along with the addtional data.
   Application.ExportXML acExportQuery, _
   DataSource:="Qq_General", _
   DataTarget:="d:\junk\OrganDatabases\TestingODF.xml", _
   AdditionalData:=objAD
MsgBox "XML exported"
End Sub


This takes 30 seconds or so on a big ODF on a Core i7

The exported XML needs tarting up to put the <ObjectList> level of structure in. I have a 65 line Python program that does this surprisingly quickly even on a big organ. PM me if you want a copy.

There is one Access gotcha. A blank XML item e.g.
Code: Select all
<AlternateScreenLayout1_Text></AlternateScreenLayout1_Text>


imports as an empty string. If you show the table in datasheet mode and click in the field, type something and then delete it Access ends up putting a NULL in the field. NULL in Access is a strange beast as NULL != NULL - only isNull() will test for it. My Update queries to do systematic re-wiring tend to get into trouble with this (e.g. attempting val([ffff]) where field ffff is NULL raises an exception).

Hope this helps

John

Return to Creating sample sets / recording organs

Who is online

Users browsing this forum: No registered users and 2 guests