Pinerolo sample set conversion

[rousseldenis]

Hi @eturpault,

It seems that I have problems converting Pinerolo sample set for front and rear audio group.

Indeed, even if samples are really there for front and rear, they don't appear in organ settings.

It seems the case with both demo and bought sample sets.

Could you check? Many thanks

[rousseldenis]

OdfEdit 2.19

[rousseldenis]

Analysing, in fact, it seems that front and rear ranks have no parent (stops).

Is there something in HW implementation still unknown about that ?

[oleg68]

[rousseldenis]

@oleg68 yes, I didn't know those options one hour ago 😅

But, you need to reaffect manually ranks to stops.

[eturpault]

This sample set was discussed here #16 (comment)
If you have got the bought HW ODF I would be interrested to get it to analyze it. I am expecting that the links missing in the demo version (between some ranks and stops sections) are defined in the bought version.

[rousseldenis]

This sample set was discussed here #16 (comment) If you have got the bought HW ODF I would be interrested to get it to analyze it. I am expecting that the links missing in the demo version (between some ranks and stops sections) are defined in the bought version.

I will try to convert the full sample set again but only the close perspective was loaded. I'll keep you in touch

[rousseldenis]

With the full sample set converted, I had to assign manually all ranks to their respective stops too.

Note: the sample set is quite detuned.

[eturpault]

This is interresting to know. Probably I am missing something in understanding how Piotr Grabowski is linking his stops to ranks in this HW ODF. Anyway he is using a method that none other editor is using as far as I know. All other are using StopRank sections. Piotr as well is using it in some of his sample sets. But Pinerolo / Duren / Landau / Erfurt HW ODF are not using StopRank sections.

In sample sets of Piotr Grabowski all ranks of the same stop have their ID containing the same value in their two last digits (i.e. 20 for close, 1020 for front, 2020 for rear). These two last digits are given in the stop section, in its field Hint_PrimaryAssociatedRankID. I will try to implement in OdfEdit the use of this kind of relationsip to associate ranks to stops when the classical method (StopRank sections) is not used in the ODF.
I will let you know if it works. In such a case I will publish a new release.

[eturpault]

About the fact that the sample set is quite detuned, you can try to convert the sample set using one of the two options "correct pipes pitch ..." of OdfEdit and see if there is an improvement.

[rousseldenis]

@eturpault @oleg68 I asked Piotr directly 😄

In fact he answered that he bypassed the original StopRank system and created the routing himself from pressed input switch to the created pipe switch.

Maybe a clue to explore more about HW.

[eturpault]

Thanks @rousseldenis for having asked to Piotr directly. With this information now I see clearly in the HW ODF how the keyboard keys are linked to the pipes. Each keyboard key is a switch, which is controlling the state of pipes (playing/not playing) through a network of switches acting under conditional switches controlled by stop switches. It is a concept which cannot be transposed in a GO ODF if I am not wrong.
The only trick that I could try to attemp is the one I described in my previous post, using how Piotr is numbering his ranks sections. But it would work only with sample sets of Piotr. But anyway only him is using such a unusual way to proceed as far as I know.

I already observed in the past that Piotr likes using a lot of switches in his sample sets for the stops or setters effects, here for the keyboards effect he goes much further. The Pinarelo ODF contains 6741 Switch sections ! I am wondering if this is not causing a kind of latency in the keyboards keys effect if the computer is not fast.

[rousseldenis]

@larspalo Do you have an input on that ?

[larspalo]

@rousseldenis Not really. I'm just enjoying the discussion!

But I basically think that @eturpault is right. Within what's reasonable it's of course very good if OdfEdit can make any conversions of "odd" cases to a sane GO equivalent, but if there's absolutely nothing to go on it's very difficult and that I accept.

Rank numbers found as parts of other ID numbers is something I remember was used to detect different HW file linkages in the past (mostly with voicing and tuning), so that might indeed be a good thing to check for if it exists.

[rousseldenis]

@rousseldenis Not really. I'm just enjoying the discussion!

But I basically think that @eturpault is right. Within what's reasonable it's of course very good if OdfEdit can make any conversions of "odd" cases to a sane GO equivalent, but if there's absolutely nothing to go on it's very difficult and that I accept.

Rank numbers found as parts of other ID numbers is something I remember was used to detect different HW file linkages in the past (mostly with voicing and tuning), so that might indeed be a good thing to check for if it exists.

If I would go further, maybe there is something in GO that refrain people to make sample sets available for it as there are limitations. Maybe something that could be explored as the 'why' interests me.

[larspalo]

If I would go further, maybe there is something in GO that refrain people to make sample sets available for it as there are limitations. Maybe something that could be explored as the 'why' interests me.

I think that the main thing "preventing" sample set producers is the view of the economic perspective. Sure, there's also certain features that's currently lacking in GO, but that's mostly a secondary concern, I think. We're getting closer to what can be expected with every release! It's just a question of time in my opinion.

Producing a sample set however is a massive investment, both in resources but most of all in time! If anyone wants to be compensated for it economically then I think that's perfectly fine and fair. However, very few producers except sonus paradisi actually even offer paid samplesets without encryption as they perceive that the risk of economic loss from piracy would be too great...

Personally, I'm quite content with other sample set producers making sample sets for HW that are un-encrypted and can be bought for private conversion and usage in GO even if we as "users" must take responsibility of it. I'm very doubtful about any other scenario...

What is your thoughts on the why? I know of an older post that Piotr made why he's not doing sample sets for GO anymore but besides that... There hasn't really been any commercial approach to providing sample sets specifically for GO except for maybe Mark with his Maltese Historic Pipe organs (https://mhpo.epizy.com/).

Besides a few enthusiasts just like myself that has other priorities, I think that mainly economic concerns would be what's preventing sample set producers from providing sample sets for GO.

However, I'll say it again! I'm not at all that pessimistic about the current situation. If sample set producers provide sample sets for HW that an user needs to buy but still un-encrypted and free for usage in other sample players like GO - then that's fine by me! I'm very thankful to the initiative by @eturpault to ease the conversion of HW sample sets to GO!