Page 1 of 1

Editing a custom organ definition in JSON format

PostPosted: Thu Oct 21, 2021 2:30 pm
by carlrobert
Hi,

Just curious: Has anyone tried editing the organ definition using JSON, converted from and back to XML?
For my first, minor edits learning to use the CODM, I found the database format to be a bit awkward to navigate.
I tried converting the XML to JSON using a few lines of Python and IMO it looks quite manageable for minor edits.
There is still a lot of visual clutter but at least the bulk of the document is not XML start and end tags :)

Code: Select all
{
"Hauptwerk": {
   "@FileFormat": "CustomOrgan",
   "@FileFormatVersion": 5.0,
   "ObjectList": [
      {
         "@ObjectType": "_general",
         "_general": {
            "UniqueOrganID": {
               "$": 801010
            },
            "Name": {
               "$": "Example Custom Organ 0"
            },
            "ShortName": {
               "$": "Example Organ 0"
            },
            "OrganDefinitionFilenameExcludingExtension": {
               "$": "ExampleCustomOrgan0"
            }, ...

Re: Editing a custom organ definition in JSON format

PostPosted: Thu Oct 21, 2021 2:37 pm
by mdyde
Hello carlrobert,

I have no experience myself with converting CODM ODF files to/from JSON format, but just in case you weren't aware of it, Hauptwerk does have native functionality (on the 'Design tools' menu) for exporting/importing CODM ODFs to/from SQLite databases. The intention was always that SQL editors would be the primary means used for editing ODFs, rather than editing XML files by hand in a text editor. Various editors exist for SQLite databases, ranging from basic free ones (such as DB Browser for SQLite) to ones designed for professional use (e.g Navicat for SQLite).

Re: Editing a custom organ definition in JSON format

PostPosted: Thu Oct 21, 2021 2:58 pm
by vpo-organist
carlrobert, you have recognized this correctly, but have not yet thought it through to the end.

In fact, XML is the most cumbersome format to take.
The parsers are slow and it is exhausting - not to say deadly - for the eyes to read.

With Json, after a while you will wonder why you always have to type the superfluous quotation marks.
If you have empty elements (without value), then you just write unnecessary stuff to waste your life time.

Then you think further and maybe come to the following format :-)

Code: Select all
[division]
; 3 = Standard division: manual 2 (Swell, Schwellwerk, Recit Expressif, Accompaniment or equivalent)
DivisionCode: 3
Name: SWELL
ShortName: Swell
NumberOfKeys: 56
MIDINoteNumOfFirstKey: 36
NumberOfKeyActionNodesIfDifferentFromNumberOfKeys: 0
MIDINoteNumOfFirstKeyActionNodeIfDifferentFromFirstKey: 0
AccessibleForMIDIInputAndOutput: Y
WindModel_EnableWindModel: Y
WindModel_TotalResrvrAndWndchstVolMetresCubed: 1.5
WindModel_AreaOfReservoirTableMetresSquared: 1.5
WindModel_ResrvrBellowsPositiveDampingCoeff: 20
WindModel_WindchestPressureDropPctAtMaxLoad: 2
PercussiveEngagingKeyActionNoise_RankID
PercussiveEngagingKeyActionNoise_ChooseMIDINoteNumRandomly: N
PercussiveDisengagingKeyActionNoise_RankID
PercussiveDisengagingKeyActionNoise_ChooseMIDINoteNumRandomly: N
SustainingKeyActionNoise_RankID
SustainingKeyActionNoise_ChooseMIDINoteNumberRandomly: N


From this you can easy generate this eye cancer inducing format:

Code: Select all
<division>
  <DivisionCode>3</DivisionCode>
  <Name>SWELL</Name>
  <ShortName>Swell</ShortName>
  <NumberOfKeys>56</NumberOfKeys>
  <MIDINoteNumOfFirstKey>36</MIDINoteNumOfFirstKey>
<NumberOfKeyActionNodesIfDifferentFromNumberOfKeys>0</NumberOfKeyActionNodesIfDifferentFromNumberOfKeys>
<MIDINoteNumOfFirstKeyActionNodeIfDifferentFromFirstKey>0</MIDINoteNumOfFirstKeyActionNodeIfDifferentFromFirstKey>
  <AccessibleForMIDIInputAndOutput>Y</AccessibleForMIDIInputAndOutput>
  <WindModel_EnableWindModel>Y</WindModel_EnableWindModel>
  <WindModel_TotalResrvrAndWndchstVolMetresCubed>1.5</WindModel_TotalResrvrAndWndchstVolMetresCubed>
  <WindModel_AreaOfReservoirTableMetresSquared>1.5</WindModel_AreaOfReservoirTableMetresSquared>
  <WindModel_ResrvrBellowsPositiveDampingCoeff>20</WindModel_ResrvrBellowsPositiveDampingCoeff>
  <WindModel_WindchestPressureDropPctAtMaxLoad>2</WindModel_WindchestPressureDropPctAtMaxLoad>
  <PercussiveEngagingKeyActionNoise_RankID></PercussiveEngagingKeyActionNoise_RankID>
<PercussiveEngagingKeyActionNoise_ChooseMIDINoteNumRandomly>N</PercussiveEngagingKeyActionNoise_ChooseMIDINoteNumRandomly>
  <PercussiveDisengagingKeyActionNoise_RankID></PercussiveDisengagingKeyActionNoise_RankID>
<PercussiveDisengagingKeyActionNoise_ChooseMIDINoteNumRandomly>N</PercussiveDisengagingKeyActionNoise_ChooseMIDINoteNumRandomly>
  <SustainingKeyActionNoise_RankID></SustainingKeyActionNoise_RankID>
<SustainingKeyActionNoise_ChooseMIDINoteNumberRandomly>N</SustainingKeyActionNoise_ChooseMIDINoteNumberRandomly>
</division>

Re: Editing a custom organ definition in JSON format

PostPosted: Sun Oct 24, 2021 6:57 pm
by larason2
I had trouble finding a free app that does SQlite well on the Mac, so I ended up just using a free coding app called Atom. It takes some getting used to, but after a while the XML tags with the “< >” brackets don’t bother me. No eye cancer so far either!

Re: Editing a custom organ definition in JSON format

PostPosted: Sat Oct 30, 2021 10:02 am
by tf11972
I don't want to advertise, but there is now a good tool on the market from a german developer with which you can edit XML files quite comfortably in table form. The app costs 24 euros per licence, but that is money well spent. If you are interested, I will send you the link by PM.