[Feature request] Extending NumberOfLogicalKeys

[oleg68]

Sometimes it is necessary to extend an existent sample set to a greater number of keys.

It can be done manually but it requires a lot of actions. For example, if the existing sample set has 58 keys and we want to extend it to 61 keys, we have to add Pipe059xxx, Pipe060xxx and Pipe061xxx entries to the ODF, referencing to some existing sample files. Usually the pipes from the same rank but one octave lower are good candidates.

So the stes for each rank are:

• Copy all Pipe047xx entries as Pipe059xxx, Pipe048xxx as Pipe060xxx and Pipe049 as Pipe061xxx
• Adjust the NumberOfLogicalPipes value of the rank from 58 to 61
• Add 1200 to the existing values of Pipe059PitchTuning, Pipe060PitchTuning and Pipe061PitchTuning. Or create these entries with the 1200 value if they did not exist before.
• Add -5 to the existing values of Pipe059Gain, Pipe060Gain and Pipe061Gain. Or create these entries with the -5 value if they did not exist before.

More tweaks may be required for mixture ranks, but these steps are sufficient in most cases.

It would be great if OdfEdit could do it automatically.

This feature is desired either for one Rank or for all selected Ranks, Stops or Manuals to the desired number of keys. The feature is not required for the whole organ because Pedal and other manuals usually have different number of keys.

[eturpault]

Some months ago I started to implement such a feature but I put it on hold. I car resume it when I have time for that. It was completed for the Rank extension part, and in progress for the Stop and Manual. The difficulty at Manual level is to extend the keys graphical attributes. The way to use this feature would be to first select in the sections list a Rank or a Stop or a Manual, then to give to OdfEdit the MIDI note up to which to extend the selected section and its children. Why do you recommend to set a gain -5 for the extended pipes ?

[larspalo]

The difficulty at Manual level is to extend the keys graphical attributes.

Maybe you could just add the option to increase the pipe and key numbers without adding more display keys?

[oleg68]

@eturpault

The difficulty at Manual level is to extend the keys graphical attributes.

You need more graphical elements, but OdfEdit does not (and I think it must not) create them. So could you make this as like for the rank level: reuse the existing graphical elements one octave lower?

Why do you recommend to set a gain -5 for the extended pipes ?

Because resampling samples by one octave up increases it's loudness. -5 is necessary for compensating this effect.

[eturpault]

Yes existing keys images must be reused for the extended keys. If the syntax Key999ImageOn/Key999ImageOff is used it is similar to pipes extensions. If the syntax ImageOn_KEYTYPE/ImageOff_KEYTYPE is used it is a little more tricky as the last KEYTYPE has to be modified. I will try to manage the extension as best as possible.

[larspalo]

I will try to manage the extension as best as possible

You know, the reason I suggest not adding the display keys to an extension is that the background most likely is not adapted to it, nor will the layout of other elements on the console be. Of course, it's your decision to make, but I'd personally avoid it unless an user really explicitly wants to do that and also then takes responsibility for it.

So, at the very least I'd suggest to add both the option to extend compass without adding displayed keys and with displayed extra keys if it's really asked for. But again, it's your call to make...

[eturpault]

Indeed the visual aspect could be strange if additional keys are displayed in a layout not made for it, you are right. If it does not prevent to play these keys with a MIDI keyboard, so it is better to not display them.

[larspalo]

so it is better to not display them

If you want to add the option of displaying them, that's of course ok and might indeed have use cases, but as I suggested above I think the default perhaps should be just the functional extension as I'd expect that many would use it on sample sets that would be converted from HW.

[larspalo]

Both the Bygdsiljum and the Norrfjärden sample set showcases the use of having different number of display keys on the panel than what the manual itself actually have as logical and accessible keys. This makes it possible to for instance play a sounding 61 key compass keyboard without changing the visuals of the displayed manual on the panel.

[larspalo]

So, in addition to the steps Oleg listed above, you can just add to the panel displaying the manual the original number of keys as DisplayKeys=(original number of keys) if you don't want the display to change.

[eturpault]

Ok, thank you for the suggestions.

[prrobinson81]

I don’t know anything about Python programming unfortunately so I’m not sure there’s anything I can add/help with technically for this feature request, but I’d definitely like to add a +1 vote for the capability. If there’s anything I can help with from a community/testing point of view then I’d be happy to do so though.

[eturpault]

I am currently working on the implementation of this new feature for OdfEdit. The compass extension is working well at rank level, I am now working to do it at stop then manual level. The extension will be possible only at the right of the keyboard.

I wonder if it is interresting to give the possibility to extend also at the left of the keyboard. Has anyone an advice on this point ? It is more tricky to do as it changes the first accessible key and pipe number of the stops. I should deliver a new version of OdfEdit by mid or end of September with this new feature (and some bugs fixing).

[larspalo]

I wonder if it is interresting to give the possibility to extend also at the left of the keyboard. Has anyone an advice on this point ?

I'd too suspect that most users will desire the possibility to extend the range upwards, so I think you're quite correct in your priorities. It's of course possible that someone wants to create for instance sub-octave couplers that act on pipes in an octave beyond (lower than) the normal manual range, but I don't think it's nearly as likely as the upwards extension.

[eturpault]

I have completed the implementation of this feature in OdfEdit and I am now testing it to try to find bugs and fix them. I have observed behaviors which seem to me to be issues, but I may be wrong or it may be normal :

1. When a pipe is defined using the REF:aa:bb:cc syntax, the attributes Pipe999PitchTuning and Pipe999Gain of this pipe, if defined, are ignored by GO (a warning "Unused ODF entry" is displayed in the Log messages window of GO for these attributes).

2. The DisplayKeys attribute seems to be unefficient when defined in a Manual section when the old panel format is used. The extended keys of the manual are displayed by GO in the main panel whereas DisplayKeys is equal to the not extended keys number.

Aside note : the Manual attribute Displayed=N seems to be unefficient, the manual having this setting (defined in Manual or PanelElement section) is displayed all the same.

[larspalo]

@eturpault For your first point: It's perfectly ok and exactly by design. Remember, "borrowing" a pipe means that you're (re-)using a pipe that already exist somewhere else (usually in another stop/from another rank). For most practical situations here on earth, a thing can only exist in one physical form/place at a time - with borrowed pipes it's still just one physical pipe that can be played from more than one stop (in mechanical action it can for instance be done with grooves in the "soundboard" that the pipes are standing on, or with double pallets when borrowing happens across manuals). Thus a borrowed pipe naturally cannot have double pipe attributes (they already exist in the pipe that's referenced)!

[larspalo]

For your second point: I'm not exactly sure how to interpret your text. However, even in old style - where there's no [Panel000] and you need to add Displayed=Y to all elements and add their GUI attributes under their main section too, the DisplayKeys still work (to for instance limit the displayed number of keys while still allowing more to be playable with a connected MIDI keyboard). I attach a DUMMY example where the manual has 61 logical and accessible keys but I only display 56 on the main panel that you can examine. I've not tested it in a really old version of GrandOrgue though...

TestOldStyleAndDisplayKeys.zip

[larspalo]

Aside note : the Manual attribute Displayed=N seems to be unefficient, the manual having this setting (defined in Manual or PanelElement section) is displayed all the same.

Displayed=N is default for all elements since a long time ago under their "backend" sections ([Manual999], [Stop999] etc.). For a true old style ODF you need to add Displayed=Y instead to have anything showing up on the main panel. But on a separate additional panel you should ONLY define what's visible on that panel. You cannot define an "invisible element" except if you actually use a transparent bitmap for it (for whatever reason you might have).

The point is, you define ALL structural elements as their own sections. You display what you want on the main panel with Displayed=Y for old style (or under [Panel000] for new style). On additional panels (new or old style) you only specify what elements you want to have displayed there - the exceptions are images and labels in the new style that are actually defined on each panel (in old style you need images and labels defined as main elements and numbered under [Organ] section)...

I've personally abandoned the usage of the old style panels and consider them only vital for backwards compatibility (actually using older sample sets). In all ways I can imagine, the new Panel format is by far superior to the basic HW1 or old panel format, at least in my own opinion.

[eturpault]

Thank you @larspalo for all these detailed explanations. So OdfEdit will not retune pipes having the REF syntax. The new panel style is definively better than the old one. OdfEdit uses the new style for HW to GO ODF conversion.

About the DisplayKeys attribute, I understand thanks to your example TestOldStyleAndDisplayKeys that DisplayKeys has to be defined in the PanelElement (Manual) and not in the Manual section when the new style is used in the ODF. This was my error to define it in the Manual section with the new style. For the compass extension feature OdfEdit has to take in consideration the old and new formats when setting the DisplayKeys attribute.

[larspalo]

So OdfEdit will not retune pipes having the REF syntax.

I think you're absolutely right. In fact, the more "modern" GrandOrgue way to achieve the same kind of borrowing is by using references to ranks (or parts of them). But for the extensions you'll want to re-use the samples (perhaps one octave lower is a good approach as noted above) by loading them again as new pipes. Thus there's no borrowing going on but a re-usage of existing samples loaded as new pipes. A small but very important distinction in this case.

[eturpault]

This new feature is implemented in OdfEdit v2.14. I let this issue opened to permit discussions and feedbacks about this implementation.

[oleg68]

@eturpault Thank you for implementing this issue in OdfEdit 2.14.

A few notes:

1. OdfEdit asks for the last MIDI number. It is difficult to calculate it for a particular user. The picture of the keyboard with MIDI numbers helps but it is still not easy. Could you ask for the number of keys instead?

2. When GO extends the compass it ignores the Pipe999Tuning entries of borrowed pipes. For example, if Pipe048PitchTuning=16.5, I expect Pipe060PitchTuning=1216.5, but GrandOrgue puts Pipe060PitchTuning=1200.

[eturpault]

@oleg68 thanks for the feedback.

1. I can ask for the number of keys to add if you think it is easier for a user, no problem. I will do it for the next version.
2. OdfEdit actually takes into account the PitchTuning of borrowed pipes, but considering wrongly that the tunning value is an integer when converting the string value to a numeric value, so the conversion gives 0 with your example because the conversion to an integer value has failed. I will fix this for the next version considering a convertion to a float value. I have just done the test, it works well with this fix.

[eturpault]

I prefer to keep the possibility to define a MIDI note for the extension, it is convenient as well. So the user will have the possibility to define either a number of notes to add or the MIDI note up to make the extension.

[oleg68]

either a number of notes to add

Not the number of notes to add but the target total number of notes. Because users usually know how many keys the keyboard has (now there are only 49-, 61-, 76- or 88- on the marketplace).

[eturpault]

I propose this prompt in case a Manual section has been selected, would it be ok ? :

If a Stop or Rank section has been selected, the prompt would remain the same as today.

[eturpault]

The maximum number of keys that OdfEdit should accept is 73 (from MIDI 36 to 108), isn'it ?

[oleg68]

I propose this prompt in case a Manual section has been selected, would it be ok ? :

If a Stop or Rank section has been selected, the prompt would remain the same as today.

No, I'd prefer to specify the target number of keys on the stop and the rank level as well.

[eturpault]

In some sample sets there are stops and/or ranks not covering the entire manual compass by design. So I think that for stops and ranks it is better to define the extension using MIDI notes. Standard users will do an extension at manuel level only.

[oleg68]

In some sample sets there are stops and/or ranks not covering the entire manual compass by design. So I think that for stops and ranks it is better to define the extension using MIDI notes. Standard users will do an extension at manuel level only.

When the user makes the extension only for moving the Stop/Rank into another composite organ, he/she is not necessary to extend the manual level.

[eturpault]

If the user is able to rework a sample set by moving Stops/Ranks, he will be able to understand the usage of MIDI notes for doing the extensions. I prefer to keep this way to do for Stop/Rank levels.

[eturpault]

OdfEdit v2.15 asks for the new number of keys instead of a MIDI note in case of Manual compass extension.