Welcome to OdfEdit Discussions!

[rousseldenis]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[eturpault]

Hi @rousseldenis, have you the possibility to change the name of this project from ODFEdit to OdfEdit as requested by Oleg (to be homogeneous with GrandOrgue naming) when I started to share this tool ? Thanks.

[rousseldenis]

@eturpault I've tested today the edition (which is in fact a translation) from Dom Bedos demo sample set to GrandOrgue format and it worked like a charm !

Thanks for this. This is a first step to a full support of HW format in GrandOrgue!

[rousseldenis]

Note: I would avoid separate version executable names, so, just keep OdfEdit.py

Versioning is done through git, so the history is preserved.

[eturpault]

Yes I have to improve my way to use GitHub versionning, I am novice in it..., I will try to fix this in what I already delivered, and in the future deliveries.
Good to know that OdfEdit translated correctly this Dom Bedos sample set. I continue to work to improve it and make it more robust against the variety of ways the stops and switches are defined in the sample sets. The next added feature of OdfEdit should be to translate the enclosures, especially for the surround sample sets which have sliders to adjust the audio volume of the close, front, rear samples.
Conditional switches in the HW ODF format can be organized in a complex way (especially in the recent sample sets of Piotr Grabowski), I don't think that all can be translated in GO ODF format, I will see what I can improve. The fact that a Switch object in GO ODF format can refer only to other switches which have a lower index that this switch is a limitation.
If my translation script is supporting enough features of the HW format, why not to give to GrandOrgue the possibility to call it through a DLL for example to open HW sample sets directly in GO, we will see.

[eturpault]

@rousseldenis : I regenerated the releases v2.0 and v2.1, attaching to them the corresponding executables, I hope to have done it as expected. I removed the bin folder. I would like to remove the OdfEdit_2.0.py and OdfEdit_2.1.py files in the src folder but I don't arrive to do it, I created a branch rename_src_files for that but I am stuck to go ahead...

[rousseldenis]

@eturpault I saw you forced push your main branch instead.

That has the annoying thing that you lose history as you squashed your commits.

The better is to:

• Do a branch like you did.
• Push to you repository
• Go to github on your repository, it will propose automatically to do a Pull Request.

[oleg68]

@eturpault Usually binaries are not stored in git repositories. Instead, they may be uploaded to the Release page.

[eturpault]

Thanks for the tip, it is done now.

[oleg68]

@eturpault

. The fact that a Switch object in GO ODF format can refer only to other switches which have a lower index that this switch is a limitation.

Feel free to create feature requests in GrandOrgue for adding missing capabilities necessary for converting from HW.

Often @larspalo objects to implement features in a HW manner. But, from another side, dramatical increasing quantity of available sample sets for GrandOrgue would be a significant value that could help him to agree with them.

[larspalo]

@oleg68 The idea of having IsTremulant at rank level would imply that every pipe in that rank (line of pipes) will always sound as a tremulant affected pipe. The structural construction of Rank and Pipe should always be that every pipe is the model of a single physical pipe (or in the case of multi ranked stops - an array of pipes activated at the same time). Specification of a version of that pipe, sounding under the effect of a tremulant, should not be separated from the non tremmed pipe, unless it's indeed a completely separate physical pipe that is independent of it's "non tremmed" version. As far as I know such an idea is making no sense in real world organs.

[larspalo]

For GOODF I'm thinking of adding the possibility to load extra attack or release samples using MIDI numbers identification from any directory, that could also extend separately to loading tremulant states of the pipes from any directory. At the moment they are supposed to be in a subdirectory (that one can specify at will) of the rank.

[oleg68]

The structural construction of Rank and Pipe should always be that every pipe is the model of a single physical pipe (or in the case of multi ranked stops - an array of pipes activated at the same time). Specification of a version of that pipe, sounding under the effect of a tremulant, should not be separated from the non tremmed pipe.

But HW has a different model: special tremmed ranks. So now it brings some difficults for converting HW->ODF.

Another example is muttichannel samples. Now they are implemented in both HW and GO as separate ranks instead of separate wav-samples of each pipe (or even multichannel wav-files).

[larspalo]

The structural construction of Rank and Pipe should always be that every pipe is the model of a single physical pipe (or in the case of multi ranked stops - an array of pipes activated at the same time). Specification of a version of that pipe, sounding under the effect of a tremulant, should not be separated from the non tremmed pipe.

But HW has a different model: special tremmed ranks. So now it brings some difficults for converting HW->ODF.

Another example is muttichannel samples. Now they are implemented in both HW and GO as separate ranks instead of separate wav-samples of each pipe (or even multichannel wav-files).

HW is not a model to imitate blindly.

Multichannel samples are another discussion really. But basically, they are another "physical impossibility" for most of us mere mortals in real life. What you have is actually being in two (or more) places at the same time - actually hearing the (same) pipe from different places at the same time.

[eturpault]

But what I will object to is any move to allow direct loading of a HW sampleset into GO. I'd see that as infringement. As it's expressed in the Help.txt of OdfEdit I support it wholeheartedly - that a tool allow creation of GO specific odfs using hints from the HW description is not a problem at all, I think.

I agree that it is better to let the HW to GO ODF conversion out of GrandOrgue application. Doing it in GrandOrgue would increase the loading time by some seconds at each HW sample set loading (the time for the conversion to be done), whereas the conversion can be done a single time with OdfEdit after having installed the HW sample set on his computer. It permits also to edit the built GO ODF in order to make some adjustments in it (better objects names for example).

[oleg68]

@eturpault Ive just tried OdfEdit 2.2. Excelent! Sesizing of panels is superb!

I'll create a feature request for OdfEdit

[eturpault]

Thank you @oleg68, I particularly appreciate this comment coming from you.
I would be glad to add interresting features to OdfEdit, don't hesitate do submit your ideas.
I accept the game, you create feature request to OdfEdit, I do the same to GrandOrgue :-)

[eturpault]

Hi @rousseldenis, could you please rename this repo from ODFEdit to OdfEdit ? The way to do it is described here.
It seems that I have not the rights to do it because I don't see the name field.
It will permit to comply with the naming conventions of GrandOrgue as requested by @oleg68 in this comment GrandOrgue/grandorgue#917 (comment)
Thank you.

[rousseldenis]

Hi @eturpault, the repository has already that name :

So, I don't understand your question

[oleg68]

I've already renamed it.