GrandOrgue / GoOdf

A tool for creating/editing organ definition files for GrandOrgue
GNU General Public License v3.0
11 stars 1 forks source link

Enhancement: Numbering of stops et al. #79

Closed pgwid-og closed 4 months ago

pgwid-og commented 6 months ago

A big thank you, Lars, for this great tool!

I had the chance to test it during the last days and and it works really well. So far I have the following suggestions:

1) Numbering of stops: Most ODFs I have seen (and programmed myself) number the stops in relation to the manual (like 101 for the first stop of manual 001). I noticed that new stops written by GoOdf unrelated to this convention. If you have to edit an ODF in a text editor it is more difficult to follow the connection between manuals, stops, switches and ranks, the numbers don't carry syntax information any more. 2) I couldn't work out how to program a compound stop with GoOdf right now (for example: To make a new 16' stop out of a 8' stop I sometimes use 16' pipes of another stop for keys 1-12 and reference the 8' samples starting from key 13). May be I didn't understand the GUI, but may be this functionality doesn't exist in GoODF. So this is something I had to add manually in my recent ODFs. 3) A mistake I ran into was, that I forgot to define added switches in the manual. As far as I know there is no check for correctness in the tool yet, so that you have to write the ODF and start GO. As you know, GO error messages reference the lines of the ODF in many cases, but it can be hard to relate this error in the GUI of GoOdf.

Last but not least: Now that we "custom ODF writers" have two wonderful tools (GoOdf and GoEdit) one asks, how to use them properly. -- My use case is like this: Convert one or more HW-ODFs to a GO-ODF using GoEdit to get proper rank-definitions (pitch-tuning, loudness, crossfades, etc.). Either a) backup the generated ODF (because we are warned that GoOdf might corrupt it) and then add new stops, a new panel and whatnot using GoOdf or b) start a new organ from scratch in GoOdf to build the layout and use only dummy ranks (since as mentioned above, the editing of ranks in GoOdf is not yet to my needs). Instead I finalize the rank definitions via copy and paste from one ore more ODFs in a text editor. Last step is opening the new Custom ODF in GO, testing and code corrections with the help of my text editor (since as said it is not easy to locate the errors using only GoOdf). My wish: In addition to be able to import a combination file from GO (which by the way didn't work for me, but this would be another topic), it would be great to import rank definitions from a second ODF.

Sorry for the long text, I didn't have the time to make it shorter... Oliver

larspalo commented 6 months ago

@pgwid-og Thanks for your interest in, and testing of, GoOdf.

  1. In GoOdf I've choosen not to distribute any numberings based on human readability of the odf, nor to preserve any existing (random) numbering in a read odf. In my opinion, the actual text of the odf should not be interesting for anyone but GrandOrgue itself to read. Thus, not to limit the available number of stops, or their distribution among divisions, in anyway except what limits GO itself imposes, GoOdf just re-orders them from Stop001 and upwards to the last one every time an organ file is saved/written. All references are taken care of properly (or should be). Combinations or settings in/from GO should really never be set for an organ that will change in any way afterwards as they won't be compatible anyway, so I don't even consider that a problem (but rather an user error, or having wrong expectations!).
  2. There are many ways to do this. But the most obvious solution is perhaps using the new "Flexible pipe loading..." button if pipes are re-loaded. I see that I've not covered that topic in a screencast so I'll put that on the TODO list... Another possibility is of course the use of borrowing/referencing either from ranks or using the old REF type version from stops if you want to re-use pipes instead.
  3. No, there is hardly any control over that an organ will actually be possible to open/load in GO as the user can save/write the odf at any stage of production. But a simple thing like adding switch references to manuals (which can be done in "bulk" as you can select multiple ones at once) is quickly fixed.

OdfEdit really shines with its feature to convert HW odfs to GO format. GoOdf is instead more geared towards sample set producers that create "from scratch" to/for GO. However, there's nothing that prevents an user from taking advantage of the best from both options! I myself frequently process a HW sample set (either one that I've bought, a free one or a demo version) in OdfEdit to quickly get an organ to work with and usually adapt/fix/alter things in it by using GoOdf afterwards.

Remember that it's very easy to "Save as..." in GoOdf by just changing the odf name (and possibly modify the ChurchName too). Thus you can just open the .organ file that OdfEdit produced in GoOdf and change the .organ name and save/write it back (under a new name).

However, if you're not converting a HW sample set but rather creating a new one completely from scratch I think you'll find GoOdf very helpful in that process. I really recommend watching the screencasts at https://www.youtube.com/playlist?list=PLNz9AJhjubTdw0pV2nZC_XfphJhJV5ly3 for insights about using GoOdf, and if a topic is not covered yet, please write about it here in the discussions and I'll see what I can do.

larspalo commented 6 months ago

the editing of ranks in GoOdf is not yet to my needs

@pgwid-og Could you perhaps elaborate on that? What exactly is not possible to do with GoOdf at the moment?

to be able to import a combination file from GO

An "exactly" matching .cmb file can be imported in GoOdf to exctract all pipe voicing information only. Combinations are not included as for instance all the setter versions of different combinations cannot be stored in an odf.

it would be great to import rank definitions from a second ODF

Perhaps that could be a feature to include in the future, but when thinking of how fast I can re-create more or less any existing rank/stop internal rank in GoOdf I can't help but wonder if it's worth it.

GoOdf represents a paradigm shift concerning creation/editing of .organ files for GO. The old very error prone text editing and copy/paste actions are gone, which might require a little change of thought (and approach) for the sample set creator... But among the huge amount of improvements present in GoOdf is automatic reference updating of (more or less) any element that can be changed/moved/deleted etc.

pgwid-og commented 6 months ago

the editing of ranks in GoOdf is not yet to my needs

Could you perhaps elaborate on that?

Of course, Lars, thank you for asking: Right now I nearly finished an extension of BIS Romsey Abbey Demo. With the help of Eric (cf. (https://github.com/GrandOrgue/OdfEdit/issues/44) ) I had the main parts already finished, to that core I added a new panel with a few stops/switches/ranks, for example a new Sw-Flute 4' on the basis of the samples the Ch-Twelth: Via text editor this is simple c&p, plus changing the windchestgroup and harmonic number and add a pitchtuning-parameter for the whole rank (btw: I noticed that in this very case that the new HN didn't help when choosing a meantone-temperament instead of the original one whilst playing. To prevent the new stop from playing a fourth too low I will have to apply a pitchcorrection as well. This was new to me, I am pretty sure that in other sample sets I had to use pitchcorrection only for ondulating stops.). I tried the same using only GoOdf: I didn't find a rank-copy-option in the tool, so I used flexible pipe loading. First question to answer: Load release in attack y/n? (since I didn't know, I looked it up in the ODF...). The releases are in subfolders "long", "mid" and "short", so the "Release subfolder prefix" didn't help and I had to manually "add (only) release from...". Then I had to apply the "Max key press time" to each individual release sample (I didn't find the possibility to select all "close" release samples in a group so that I could have had applied this parameter for a whole bunch of samples like "all short releases". And, as you can guess, the correct values for "Max key press time" had to be looked up in the ODF, since there was no indication in the file names. It would have been even worse if I had tried to edit cuepoint positions, tremulant releases or gain parameters per pipe (and yes, in the generated ODF there are some pipe-individual voicings). I stopped this process after editing a few pipes... Don't get me wrong: Your tool is fantastic and together with GoEdit there are excellent possibilities for customizing many more sample sets that are available for GO (or develop new ones), but in my opinion "The old very error prone text editing" is not over yet. I am sure that you are on the right path ("paradigm shift"), but right now we have to deal with messages like "Warning: Nicht verwendeter ODF Eintrag 'Stop062/Pipe018Gain'" and some inconveniences in GoOdf-ranks-creation.

Best regards to Sweden! Oliver P.S. My daughter was in Stockholm last year at the university for the summer semester and enjoyed her stay very much :-)

larspalo commented 6 months ago

First question to answer: Load release in attack y/n?

This means: should a cue be expected to exist in the attack sample file, and if so, should it be loaded as a release?

(I didn't find the possibility to select all "close" release samples in a group so that I could have had applied this parameter for a whole bunch of samples like "all short releases".

This is done after having loaded the releases. You select one of them and hit Ctrl+E to go into the edit release properties dialog, make adjustments for the max key press time and then push the big button labeled "Copy properties to other releases coming from the same directory" at the bottom.

The releases are in subfolders "long", "mid" and "short", so the "Release subfolder prefix" didn't help and I had to manually "add (only) release from...".

Yes, if an odd sample directory structure is used, that's exactly why that option exist. If no time information exist in the folder name, use the button option mentioned above to set basic defaults for every release coming from that directory.

but right now we have to deal with messages like "Warning: Nicht verwendeter ODF Eintrag 'Stop062/Pipe018Gain'" and some inconveniences in GoOdf-ranks-creation.

This should only be possible if you've manually edited the odf afterwards. The originally written odfs from GoOdf should not cause such warnings. If they occur directly from GoOdf - please report them as issues! I suspect most warnings occur simply because you're editing the odf later yourself.

Don't get me wrong

I'm not interested in arguing, I'm only interested in finding out what can be done to improve GoOdf as a tool.

I didn't find a rank-copy-option

No, as complete re-creation of a whole rank can be done extremely quickly if sample structure is sound, I didn't bother with it. Also, simple referencing can be used instead within an odf. However, your suggestion to be able to import whole rank definitions from other already existing .organ files is something I've put on the TODO list as that could indeed be useful to get pipe specific details that have been manually entered earlier. For another approach, especially if the organ is created from scratch without any previous data to draw from, I recommend having a look at screencast nbr 9: https://youtu.be/oAx4VU6-C94?feature=shared to get some options.

Sw-Flute 4' on the basis of the samples the Ch-Twelth

This is very similar to what I show in screencast nbr 10 (https://youtu.be/XIV0TqKfxn0?feature=shared) but I did it the other way around, a 2 2/3' from a 4'.

Bumblebee001 commented 6 months ago

I'm a bit confused. I am creating a sample-set and so far I have most of the pipes as single files with attack and release markers. I have no release folders for mid and short. Do I need to "create" these releases or can GoODF do the job saving me several hours of work?

larspalo commented 6 months ago

@Bumblebee001 If you've recorded the samples with only one release (that in the main attack sample), then you of course don't have multiple releases for that sample set that can be added. For such samples the GrandOrgue feature/enhancement "Release sample scaling" (Files->Settings) exist. But most recent samplings consist of each pipe having multiple releases sampled where you also played the pipe staccato and very short to get the release behaviour and reverb of shorter key strokes.

pgwid-og commented 6 months ago

push the big button labeled "Copy properties to other releases coming from the same directory" at the bottom.

Indeed, I missed this functionality whilst exploring the features of GoOdf.

However, your suggestion to be able to import whole rank definitions from other already existing .organ files is something I've put on the TODO list as that could indeed be useful to get pipe specific details that have been manually entered earlier.

Glad to here that!