ODF-defined Crescendo

[Bumblebee001]

I am not sure I am asking the write question but here goes:

Is it possible to get GO to enable one to create a crescendo pedal and unique graphics to the odf (rather than setting and saving as a cmb file)?

This appears to be a long standing issue that has never been addressed. I just briefly reviewed a series of posts that included those from my sorely missed friend Panos who died 8 years ago! Posts go back 11 years!

[Bumblebee001]

https://www.magle.dk/music-forums/threads/crescendo-pedal-for-grandorgue.16346/

[larspalo]

Well, the graphics of a crescendo swell is no different from that of an enclosure. You can create an image for each step just in the same way.

But here's the real problem: there's currently no way to program a "fixed" crescendo from the odf. A sample set producer cannot "program" a "protected" crescendo step sequence in the odf that the user cannot mess with. Many (older) organs with a register crescendo swell couldn't be programmed at all by the organist - only used as it was setup by the organ builder. This can right now not be modelled in GrandOrgue.

As a workaround it's currently possible to create default settings (for crescendo swells, as well as many other things) by exporting a .cmb with the same name as the .organ file and place it in the same directory. But it would be great if there was a protected crescendo (odf) mode that could model older types of fixed crescendo pedals.

[Bumblebee001]

What about an “unprotected” crescendo? If users want to mess about, who’s to stop them? How should that effect me and my sample set production?

On Thu, 03 Aug 2023 at 21:32, larspalo @.***> wrote:

Well, the graphics of a crescendo swell is no different from that of an enclosure. You can create an image for each step just in the same way.

But here's the real problem: there's currently no way to program a "fixed" crescendo from the odf. A sample set producer cannot "program" a "protected" crescendo step sequence in the odf that the user cannot mess with. Many (older) organs with a register crescendo swell couldn't be programmed at all by the organist - only used as it was setup by the organ builder. This can right now not be modelled in GrandOrgue.

As a workaround it's currently possible to create default settings (for crescendo swells, as well as many other things) by exporting a .cmb with the same name as the .organ file and place it in the same directory. But it would be great if there was a protected crescendo (odf) mode that could model older types of fixed crescendo pedals.

— Reply to this email directly, view it on GitHub https://github.com/GrandOrgue/grandorgue/issues/1624#issuecomment-1664526217, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVM7NW24ZDOAPXYBJPS7UTXTP4FVANCNFSM6AAAAAA3CHXPDQ . You are receiving this because you authored the thread.Message ID: @.***>

[larspalo]

The "unprotected" crescendo already exist (as version A, B, C, and C) that can be programmed by default by .cmb. But currently there's no way to make them protected so that they cannot be changed by an user. And in your case, with the current sample set you're working on, the possiblity to change them could mean very strange experiences for the user from what they would not normally expect...

[Bumblebee001]

I think you mean they can be changed by the user…. I will add a readme doc to explain

On Thu, 03 Aug 2023 at 21:57, larspalo @.***> wrote:

The "unprotected" crescendo already exist (as version A, B, C, and C) that can be programmed by default by .cmb. But currently there's no way to make them protected so that they cannot be changed by an user. And in your case, with the current sample set you're working on, the possiblity to change them could mean very strange experiences for the user from what they would not normally expect...

— Reply to this email directly, view it on GitHub https://github.com/GrandOrgue/grandorgue/issues/1624#issuecomment-1664572889, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVM7NRON7JS64NMTVQUI5DXTP7DRANCNFSM6AAAAAA3CHXPDQ . You are receiving this because you authored the thread.Message ID: @.***>

[larspalo]

I suggest that we create a real separate Crescendo object for the odf inclusion: [Crescendo] and not mix it with the setter crescendo(s) at all. The already existing built in setter crescendos A, B, C and D we just leave alone and only allow referencing them as before (and in the process clean out the odf setting of the OverrideMode, lines 372 and 373 in GOSetter.cpp, for them and keep that setting purely for cmb).

This new odf [Crescendo] should display in GUI as any other normal swell/enclosure and have exactly the same attributes and possibilities to display on any panel. Structurally though, it should be possible to specify the number of steps like CrescendoStepCount= maybe up to 32 like the built in versions. We can of course also add the OverrideMode= option. A Protected= boolean option like other combinations to either allow or dis-allow user editing of step content could either be set for the crescendo globally or for each step. Each crescendo step [CrescendoStepXX] should be defined just like a general which means that the scope of the crescendo can be limited to only that which is suitable for what the instrument to model requires.

[larspalo]

@jefferycrowley You're using the old style panel format with the [SetterElement999] entries, I'd advice that you to learn to use the new panel format instead. Also, this thread is actually an issue - feature request, really, for GrandOrgue. Thus we shouldn't clutter it with information that perhaps should have their own topic as a general discussion instead.

This issue is about having a feature to define/program the crescendo steps of odf defined (not the built in) crescendos that would be possible to easily pre-program and protect from user tampering with if the organ model requires it. The built in crescendos of GO already provide the user with enough possibilities - this is about providing the sample set producer with an option to re-create actual organs as faithful models in GO.