ODF Capabilities for Composite Set Creators

[oleg68]

@larspalo

My thoughts are: the user should never need to bother with writing odfs and learning it's specs, that's the sampleset producers burden. GrandOrgue as a software should make it easy for the user to use existing resources in whatever way they like.

Do you see the beauty of it?

You do not consider composite set creators as sampleset producers and consider them as users. It is your right.

But in this case I'd differentiate between two kinds of users: ordinar users - organ players and users who makes organs for other users from another samplesets or convert them from Hauptwerk format.

I agree with you that learning and modifying ODFs is not necessary for the first kind of user. But for now it is the only existing way for the second kind of users. And we must provide ODF capabilities for them until we provide another acceptable way for their work.

Do you see the beauty of it?

I cann't see any beauty in ignorance the existence of composite sampleset creators and converters.

[rousseldenis]

My thought about this, is this should be included in GrandOrgue or in a distinct tool (but supported by organization) ?

[larspalo]

My thought about this, is this should be included in GrandOrgue or in a distinct tool (but supported by organization) ?

There are two aspects, or points of view, as I see it. The sampleset creator definitely needs disctinct tools to help producing .odf files that are of a good quality to be used in GO. The user needs the possibility to, from within GO, use the available resources in a flexible way to suit his/her needs.

No doubt, there can be cross-breeds. But I think we need to keep the perspectives apart in order to further the development in a productive and fruitful way that in the end will benefit the most.

[larspalo]

As you already know, changes in .odf requires reloading of sampleset. Changes in .cmb settings can be done on top of the already loaded samples. A future separation of different settings will further increase the flexibility that the .odf cannot provide.

A disclamer: presently, we have lots of snow falling and electrical power is coming and going. I might not be available every now and then for unknown periods as it is right now...

I agree with you that learning and modifying ODFs is not necessary for the first kind of user. But for now it is the only existing way for the second kind of users. And we must provide ODF capabilities for them until we provide another acceptable way for their work.

Do you see the beauty of it?

I cann't see any beauty in ignorance the existence of composite sampleset creators and converters.

This is unfortunately very true right now. But we must look forward and have greater planning ahead. So, please try to see the greater plan and not cling to old procedures that can be greatly improved if the right will exist. In short, while I do think that composite sampleset assemblers do an inferior work compared to true sampleset creators, I still want to provide easier means for them to acomplish their goal of using resources provided by others. The kind souls providing conversions of existing samplesets (porting from other platforms to GO) fall under another category in my mind - they are closer to being true sampleset creators.

[oleg68]

As you already know, changes in .odf requires reloading of sampleset. Changes in .cmb settings can be done on top of the already loaded samples.

Yes, indeed. Sometimes changing organ settings in .cmb and testing them on fly it is a useful step before saving these changes to the .odf.

A future separation of different settings will further increase the flexibility that the .odf cannot provide.

I doubt in that.

But we must look forward and have greater planning ahead. So, please try to see the greater plan and not cling to old procedures that can be greatly improved if the right will exist

Of cause, the plans ahead are great! But even we provide a simple capability of piking ranks from several organs for user with GUI, this work will rest quite hard:

1. If the number of stops is several dosens, than it will take a lot of time.

2. Downloading a lot of other sample sets for borrowing only few racks from each of them will take huge internet traphic and will require a lot of extra disk space.

3. Just picking stops is not sufficient. There is a lot of work after:

   1. Extending a compass of some ranks
   2. Thin tuning of borrowed pipes with PitchTuning/PitchCorrection and Pipe999PitchTuning
   3. Adjusting volume. Mostly on the rank level, but sometimes on the pipe level
   4. Balancing Release Time [Enhancement] New Per-Pipe Release Truncation Mechanism #774

Capability of making some things not only with GUI but also with automatic tools like sed, awk, shell scripts, crudini, LoopAuditioneer (thank you, Lars) enhances the speed of this work.

If the work is big, there is a high desire to save the result of this work and to reuse it more than once. For now, ODF is an evident artifact of saving and redistributing it. Maybe in the future we learn to generate .odf automatically from .cmb?

[larspalo]

Well, in the past we've had (at least) one person copying samples from others and re-distributing them under different organ names as if it was his own work. This is completely respectless behaviour that we should not encourage.

What is actually more traffic? The same samples being re-packaged, existing in multiple places and moved around in countless of copies... Or, re-using resources from existing sampleset packages, that are free and available to the users, that basically then need to exist in only one place on the users computer.

Maybe in the future we learn to generate .odf automatically from .cmb?

I'd rather put that as exporting from multiple resources... In the future I hope we have more than just .cmb.

[oleg68]

What is actually more traffic? The same samples being re-packaged, existing in multiple places and moved around in countless of copies... Or, re-using resources from existing sampleset packages, that are free and available to the users, that basically then need to exist in only one place on the users computer.

If there are 100 free sample sets each of 20 stops. Suppose each whole sample set takes 10 Gb of files, each stop - 500Mb. Total are 1 Tb.

If I want to make a composite set with 100 stops, taking one stop from each source sample set. I need to download and unpack 1 Tb of files. I can repack only the samples included in my target sampleset with an ODF, it will take 50Gb.

For installing my prepared composite sample set, a user have to download and unpack only 50Gb of files, and not to download the source sample sets.

But in your approach for picking up 100 stops from 100 samplesets with GUI user have to download and unpack 1Tb of files again. Instead of 50Gb in my approach.

[larspalo]

But in your approach for picking up 100 stops from 100 samplesets with GUI user have to download and unpack 1Tb of files again. Instead of 50Gb in my approach.

Actually, when another user decides that he wants to change one stop, you'll have to download the same 99 again that you already have to test his "creation".

[oleg68]

Actually, when another user decides that he wants to change one stop, you'll have to download the same 99 again that you already have to test his "creation".

If the user has already downloaded the composite sample set (50 Gb) and wants to replace one stop, then he/she have to download only one additional source sample set (10Gb) for borrowing a stop from.

Of cause, if he repacks the composite sample set, I need to download the whole pack. Like appimage.

Otherwise we should provide something similar to a package manager in linux for downloading intersecting parts of different organs only once, where whould be minimal unit would be not one sample set, but one rank from it.

[larspalo]

And we must provide ODF capabilities for them until we provide another acceptable way for their work.

There's one problem with this,though. One thing I've learned is that open source development is driven by need. If we provide a way to accomplish a goal, then that way will be adopted as the right way to do it and development of a better way will most likely cease. I seriously think we should dream big and strive for a higher level.

[oleg68]

If we dream big and ahead, the possible approach, an opposite to that Lars wants, might be the following:

1. Now .cmb file contains either .odf adjustments and setup-specific things. To move setup-specific things to a separate place Restoring Organ Settings to ones from ODF without losing Audio Group distribution #731 (comment)
2. To get rid of .cmb file at all. Odf would be enough.
3. All changings made by a user should be saves as a patch to the odf. (not necessary of the patch format. May be the same ini-format, where only the added or redefined values exist).
4. We need some tool for applying this patch to an odf and producing a new one.
5. It requires that all settings with GUI would be savable to odf.
6. A separate thing - saving stop combinations. Now they are saved to the same .cmb file that sometimes causes some problems (Import settings and Import Combination menu entries are the neighbors now and it is very simple to select one instead another). To save combinations to a separate human readable file.

[larspalo]

Right... At least you should NEVER allow overwriting an existing .odf from within GO. ;-) Creating new ones... perhaps but I'd like a completely different format, that doesn't confuse the original .odfs from the user created one with references to different resources.

But many of the other things I'm not at all directly opposed, you just say them in a different way...

My vision definitely separates combination files (stop combinations) as the one true meaning of .cmb (combination) file.

For the 5. I think all GUI settings that are logically connected - for instance pipe voicings should have their own settings file. Other user settings will require their own. A few of the benefits could be:

1. The original ODF is always intact as produced and can be reverted to if needed
2. Different settings that doesn't cause conflicts might easily be exchanged at will and the user can produce different versions of the same organ to be used without needing to re-load it.
3. Some re-use of setup related things between different organs might be possible
4. The user gets better freedom to mix and match the setups without needing to bother with the actual file contents

But yes, it's a lot of work to implement this in a robust way.

By design, the ODF should contain things that constructs the organ, never the users preferences on how to render that organ.

[oleg68]

It is just misunderstanding. I didn't tell about overriding an existing odf file. I told about overriding values from the original odf file and storing the new values (and only them) in another file (patch).

I totally agree that the original odf file must be kept unmodified (read-only).

I like your idea of splitting organ setting across several files. But it also can be implemented as different patches to the single source ODF file (including adding settings that can never appear in the source odf).

[larspalo]

@oleg68 To me it's just semantics. Basically, we seem to agree on the overall goal - that's most important, I think.

[oleg68]

The kind souls providing conversions of existing samplesets (porting from other platforms to GO) fall under another category in my mind - they are closer to being true sampleset creators.

But sometimes they are the same people: they take a lot of demo samplesets in Hauptwerk format, select stops from them and produce a single composite sampleset for GrandOrgue.

Basically, we seem to agree on the overall goal - that's most important, I think.

Let's make a path to this goal from the current state.

1. Now the only way of making a composite set is to creade a single ODF. I hope, you agree.
2. I agree with enchancing GUI settings, including capability of creating composite organs with GUI in the future
3. I agree with splitting organ settings and exchanging parts of them
4. I insist on keeping the capability of making a single ODF for composite set creators. As I understand, you disagree and you would like to abandon this capability.
5. I totally agree with you that distributing composite or modified samplesets without reference to the original ones is an odd behavior.

[larspalo]

But sometimes they are the same people: they take a lot of demo samplesets in Hauptwerk format, select stops from them and produce a single composite sampleset for GrandOrgue.

Porting a HW sampleset to GO without adding or changing more than necessary to make it usable in GO is great! Making composite organs... In my opinion, not so much - but I can understand some people will want to do that, and that's of course their choice to make.

1. Now the only way of making a composite set is to creade a single ODF. I hope, you agree.

Yes, at the moment this is the only available choice. And whatever changes we make to ease for an average user to use different resources from other packages from with the GUI, this will always be an available path to take for anyone that wants it.

2\. I agree with enchancing GUI settings, including capability of creating composite organs with GUI in the future

This is mostly to make it easier for non-technical users to in an acceptable way use the different resources available from existing samplesets, no matter if it's from one single sampleset or from many different.

3\. I agree with splitting organ settings and exchanging parts of them

Great, I see this as an opportunity to make the system more robust and be able to re-use some settings or easily exchange them without re-loading the organ (or even worse - registering the organ as a new one, when it's only settings/adaptations that have changed).

4\. I insist on keeping the capability of making a single ODF for composite set creators. As I understand, you disagree and you would like to abandon this capability.

This will always be a possible path, as it's the same as creating a new organ sampleset. My main point of this whole discussion is that the user adaptations/settings for/from samplesets should be kept apart from the odf format. That's simply why I think that release tail trunctation belongs in the GUI and (for now) in the .cmb file - later most likely in some other settings file.

We will need to setup a roadmap of the necessary changes, and there are a lot of them, that we will need to implement in order to reach the goal. Also they should be broken down into smaller parts if possible, to ease the development.

[oleg68]

This will always be a possible path, as it's the same as creating a new organ sampleset.

But it requires complete revoicing capabilities in ODF, including all new features.

My main point of this whole discussion is that the user adaptations/settings for/from samplesets should be kept apart from the odf format.

I do not oppose of changing the format of settings. But my point is to have the same entities available in the Organ Settings and ODF belong to voicing with the capability of export Old Odf + Revoicing settings to a New Odf. It will add more flexibility.

[larspalo]

But it requires complete revoicing capabilities in ODF, including all new features.

I'll always come back to the main issue. The tailoring of the reverb tail is user preference. You don't want to accept it, I understand. But here's the final ultimate reason for why the reverb tail shaping should be separate from odf and only as a user configurable setting - in a patch or separate settings file or whatever:

The reverb tail is not part of the organ itself. It is the effect of a pipe situated in a certain (specific) room. The actual samples though - they are in fact recorded in a (specific) room and they should be part of the odf. The exact shaping of them is, and should always be, user preferences.

When I sample an organ and put together a sampleset, I record that organ pipe for pipe, note for note as best I deem possible under the current conditions. Later in processing I'll try to do my best to make the end result as good as possible too, but that will never, ever, be (in the odf) making manipulations of the reverb tails I've painstakingly recorder and processed earlier.

No, reverb tail shaping is not voicing! It's putting the pipes in a different room or changing the ambience... That should not be done in the odf, because such things doesn't belong there. It's not the same as altering pitch or altering volume/gain - that's voicing/tuning. We should always remember to roots of GrandOrgue - it's a software for playing sampled organs.

GrandOrgue is a sample based pipe organ simulator.

[oleg68]

Yes, exactly, reverb tail is not a property of the organ pipe. It is a property of the room where the organ has been recorded.

You postulate that one ODF describes one and the only one physical organ in it's room. But in case of a composite set it is not true.

When we want to use the pipes recorded in different rooms together in a composite set, we must virtually transfer them to some one room and align their reverb tails. Otherwise the composite set will sound very strange, especially when the stops from both rooms are played simultaneosly.

So this feature is higly necessary for making composite ODFs.

Another thing if we play with the same (possible composite) sample set in different rooms: at home and in a church. There is no any natural reveberation at home, so I'd use full reveberation recorded in the sampleset. But playing in a church that has a natural reveberation, I'd decrease the reveberation tail with the GO panel. It is really the user preference, not odf. And in most cases decreasing at the organ level would be enough, it would not be necessary to do this at the pipe level.

[larspalo]

You postulate that one ODF describes one and the only one physical organ in it's room. But in case of a composite set it is not true.

Yes it is, because what you actually do is picking pipes from different organs/locations and put them together as a "new" organ in some other location. And simply put, that should be done down on sample level to be "true". That will always be the only way I can accept as a "real" composite organ (could possibly exist IRL). But there are of course possible issues with this... For instance you might have samples that are possible to freely distribute but not modify. Then the easy way is just to keep the samples as is and add configuration settings on top. You want to have that only in the .odf and I say it should be in (unadultered) .odf + .cmb at the moment for puristic reasons.

And yes, to be effective doing a composite organ, what you most likely have to do anyway is to go for the pipes with the least amount of natural reverb and adjust the longer accordingly. If that's too little reverb for your taste, then you have to add it later artificially anyway...

But if you humor me for a little. Lets say for a second that we only put the settings in the .cmb file. What are the consequences? Currently, to distribute a composite organ you'll have to make one .odf file for the basic organ composition, then you have to make/export a .cmb file with the adapted settings. Another user must load the organ, import the .cmb settings and then save the organ to have it functional as you intended. And not mess with the .odf too much... Because then the .cmb file will have issues importing. Those issues, within reason, we can address (and I think some of them already have been). By the way, to begin with, you should have the legal rights to at all distribute the samples in question. Samples that are not allowed to re-distribute should not be that either!

If we in the future have the possibility to distribute the composite organ as a package that will automatically do the configurational steps needed - then I think we're golden...

If you're not satisfied with this approach... In the mean time... We could still keep the official GO "pure" and you, or someone else, branch off a repository for the "temporarily fixed" GO version for composite organ enthusiasts until we have a working solution that's acceptable.

[rousseldenis]

I agree on that point.

Even if I admit I exercised myself to do HW demo organs ODF for GrandOrgue (remember I'm a baby in GO devs) - not composites as I'm quite a purist, we need to separate things.

IMHO, ODF should be designed for samplers as they know the instrument they have recorded. Definitions can be enhanced with requests of some of them to lower the technical gaps with other softwares and to attract them to use GO (see @Jean-Gabriel1982 comments here under - some are interested in but some are leaving GO like Piotr Grabowski).

I've not yet the knowledge on cmb files but I tend to say it's safe to let that layer on top of ODF to let people adjust things according to their specific needs.

[larspalo]

Also, an argument of doing the composites with referenced resources, instead of actual sample inclusion in the distribution, is that if the distributions of samples is prohibited by anyone except their originator, an user can get them from the original source without legal issues for anyone. For samples that are free to re-distribute this is of course not an issue at all, but not all samples fall into that category.

I also feel that we should be very careful in relation to the vendors that actually supply samples that can be used within GO and not encourage any behaviours that might discourage them from continuing providing samples(ets) for the GO community.

And yes, as @rousseldenis points out above, we desperately need tools for sampleset developers that will make it easier for them to produce samplesets of high quality, free or commercial, that the GO community can benefit from. As soon as possible I'd like to get away from needing anyone to make any manual edits in the .odf whatsoever, instead we should have tools for that to ensure good quality and ease of production.

[larspalo]

A very easy implementation that would ease the user interaction would likely be to enable automatic loading of a .cmb with the same name as .odf if it's existing in the sampleset directory (for ease of distribution).

[Jean-Gabriel1982]

Hello everyone,
I join @larspalo for the creation of a .cmb file which would contain all the POST configuration of the organ.

that is to say that I think that the .odf file should homogenize

• the sound volume
• the temperament
• the reverb of the composite organ, and then, up to the user to work:
• reverb, depending on the place where the organ will be placed
• volume of stops note by note (as GO already does)
• harmonization of stops note by note (new function - see Features request … for the future #785)

and this last work can be exported in a .cmb file

[oleg68]

And yes, to be effective doing a composite organ, what you most likely have to do anyway is to go for the pipes with the least amount of natural reverb and adjust the longer accordingly. If that's too little reverb for your taste, then you have to add it later artificially anyway...

No, it is not a good solution. The natural reverd recordes in the release samples is better than the artificial one.

A better solution is to use the natural reverb from most of stops and to truncate the tail only for samples that are extremally wet

[larspalo]

Well it really depends on what samples you're combining and what effect you're after... But normally, the least common denominator will be what you must use to get a good result.

Anyway, the more I've been thinking about it, I think that for the future GO might benefit from a general simplification of the .odf overall. In that all settings that are not really structurally important for the organ should be broken out into separate file(s) - especially all those that the user (and actually the sampleset creator too) can configure from within the GUI instead of tediously write them into the .odf with hundreds of similar lines. Again, this is perhaps a new topic...

[larspalo]

@oleg68 I've created a branch in my GO fork named bundleCmb to show how easy GO can use an exported settingsfile that have the same name as the odf as default settings, if present in same directory.

[oleg68]

@larspalo Thank you, Lars. It is better than nothing. Please make a PR.

But I'm not sure that distributing both odf and cmb files is a desired future of GrandOrgue, because

1. It is very hard to edit a cmb file with a text editor.
2. It is hard to maintain a lot of small heavy linked keys in two different files. I agree with splitting one file to several parts only if there are a few links between their contents.
3. There is a way to import new odf to the current organ settings. It does not work very well, but such way exists. But there is no any way to import a cmb from the organ producer to the one of the user.
4. Regarding to Pipe999ReleaseTruncation is still not sufficient to set the same value for all release samples of the pipe. If each pipe has, for example, three releases, the first is the shortest, and the last is the longest. If I add some stop from a very wet sample set with three releases of each pipes, I have to truncate these three releases differently. It is more desirable to have Release999Truncation setting at the rank level with different values for Release001, Release002 and Release003, but the same for all pipes, than different for all pipes but the same for all releases.

[larspalo]

1. No one is supposed to edit the cmb with a text editor. Everyone should edit a cmb from within GO.
2. It depends. This is an area that needs more research, thought and work to be a viable option - but I think the main benefit will be much easier work even for a sampleset producer. The end goal will of course be to never even have to bother with editing any file - odf or cmb or whatever settings file - with a text editor (for reaching this we'll need external tools for sure).
3. The GO parsing of the cmb will most likely need (a lot of) attention to make it more robust to differences in setups and even some changes in the main odf. My current experiment just enabled that if a cmb file with the same name as the .organ file exist in the same directory, the cmb will be used as default settings (that even can be reverted back to) until the user decides to adapt them. So, in a way, with the small addition I made in my bundleCmb branch it's possible to include an exported settings file with the .organ file that's then used as default settings for any user. However, this needs more work to make sure it behaves properly.
4. Still you make assumptions about how the pipes lay out within a rank... In truth - you cannot really make such assumptions. You can have three releases for one pipe, then 5 releases for the next, then 4 for the next, and so on - the order of long to short (or short to long, or just mixed however) can be anything that the MaxKeyPressTime dictates, it really doesn't matter. While on the release subject - I'd indeed like to see an improvement on the built in feature of GO that does the Release Sample Scaling - again not done in odf, but in user configurable ways.

[larspalo]

@oleg68 Further testing reveals that this approach (bundling a settings file with the odf) is actually fairly stable. Even with different audio setups the bundled settings file works, and with a side bonus too it seems... If audio groups were set in the settings file they are actually preserved as defaults! Even if the groups doesn't exist for the user, the suggestion of the sampleset distributor will be apparent for the user. This discovery approaches partly the #732.

[oleg68]

My current experiment just enabled that if a cmb file with the same name as the .organ file exist in the same directory, the cmb will be used as default settings (that even can be reverted back to) until the user decides to adapt them. So, in a way, with the small addition I made in my bundleCmb branch it's possible to include an exported settings file with the .organ file that's then used as default settings for any user

The real case:

1. A sample set producer issued the .organ+.cmb pair
2. The user set up and made it's own .cmb
3. The sample set producer made some changes in his pair. For example, added a stop in odf and the release truncation in the corresponding cmb.
4. The user can import the new odf into existing user cmb. But he/she cann't import ones from the sampleset-cmb to the user-cmb.

[larspalo]

The real case:

Ok, the .organ + settings file that a sampleset producer supplies are always only the defaults. If an user imports his own settings (or if the presets still match) they will always override the defaults.

As I see it, where we need to improve on this concept now is likely in the parsing of the settings file that should allow for a greater tolerance of re-using the settings that still match without errors.

4\. The user can import the new odf into existing user cmb. But he/she cann't import ones from the sampleset-cmb to the user-cmb.

No, the user never ever imports any odf. If a sampleset producer supply a patch it should overwrite the old odf and settingsfile with new ones (that serve as the new defaults). The user should either just continue with the already created presets or import his own settings file to keep his/her custom work. Again, it's likely in the tolerances of changes we need to improve on this strategy.

[oleg68]

Still you make assumptions about how the pipes lay out within a rank... In truth - you cannot really make such assumptions. You can have three releases for one pipe, then 5 releases for the next, then 4 for the next, and so on - the order of long to short (or short to long, or just mixed however) can be anything that the MaxKeyPressTime dictates, it really doesn't matter.

1. One of the most famous sample set provider - Sonus Paradisi - gives three release samples for each pipe.
2. Anyway the same truncation value for all releases of one pipe is not correct.

While on the release subject - I'd indeed like to see an improvement on the built in feature of GO that does the Release Sample Scaling - again not done in odf, but in user configurable ways.

Now release sample scaling may be enabled or disabled only globally. But it'd be better to have this on the rank level, especially for composite sets.

[larspalo]

1. One of the most famous sample set provider - Sonus Paradisi - gives three release samples for each pipe.

They might have standardized things now, but in one of the few samplesets that I've bought from them (St Carlo Brescia) you have for instance 3 attacks with the standard releases included and 9 additional releases:

Pipe001=.\000370\pipe\Principale\036-c.wav
Pipe001AttackCount=02
Pipe001Attack001=.\000370\pipe\Principale\036-c__bis1.wav
Pipe001Attack002=.\000370\pipe\Principale\036-c__bis2.wav
Pipe001ReleaseCount=009
Pipe001Release001=.\000370\pipe\Principale\rel_0100\036-c.wav
Pipe001Release001CuePoint=0
Pipe001Release001MaxKeyPressTime=100
Pipe001Release002=.\000370\pipe\Principale\rel_0100\036-c__bis1.wav
Pipe001Release002CuePoint=0
Pipe001Release002MaxKeyPressTime=100
Pipe001Release003=.\000370\pipe\Principale\rel_0100\036-c__bis2.wav
Pipe001Release003CuePoint=0
Pipe001Release003MaxKeyPressTime=100
Pipe001Release004=.\000370\pipe\Principale\rel_0250\036-c.wav
Pipe001Release004CuePoint=0
Pipe001Release004MaxKeyPressTime=250
Pipe001Release005=.\000370\pipe\Principale\rel_0250\036-c__bis1.wav
Pipe001Release005CuePoint=0
Pipe001Release005MaxKeyPressTime=250
Pipe001Release006=.\000370\pipe\Principale\rel_0250\036-c__bis2.wav
Pipe001Release006CuePoint=0
Pipe001Release006MaxKeyPressTime=250
Pipe001Release007=.\000370\pipe\Principale\rel_0560\036-c.wav
Pipe001Release007CuePoint=0
Pipe001Release007MaxKeyPressTime=560
Pipe001Release008=.\000370\pipe\Principale\rel_0560\036-c__bis1.wav
Pipe001Release008CuePoint=0
Pipe001Release008MaxKeyPressTime=560
Pipe001Release009=.\000370\pipe\Principale\rel_0560\036-c__bis2.wav
Pipe001Release009CuePoint=0
Pipe001Release009MaxKeyPressTime=560

2\. Anyway the same truncation value for all releases of one pipe is not correct.

If the intention of the multiple releases are for the subtle differences in reverb buildup depending on attack length - then no, it's not good enough. Though, if the releases were scaled uniformly and then the Release Sample Scaling effect did an effective job of adapting them according to attack length then it's no more strange than the composite creation in itself.

Now release sample scaling may be enabled or disabled only globally. But it'd be better to have this on the rank level, especially for composite sets.

Make sure you differentiate between "Reverb tail shortening" and the "Release Sample Scaling". They are two different things.

[oleg68]

No one is supposed to edit the cmb with a text editor. Everyone should edit a cmb from within GO.

This is a reason why it is better to provide plain text files for the sampleset builder (or assembler). It's too difficult to set a lot of values with GUI.

[larspalo]

This is a reason why it is better to provide plain text files for the sampleset builder (or assembler). It's too difficult to set a lot of values with GUI.

Right... I don't think many users would agree with you on that, but I could be wrong...

[larspalo]

Actually, when I worked on some of my samplesets (like Kalvträsk for instance) I first prepared the basic odf, loaded the organ in GO and made all the voicing adjustments there, then exported the settings and extracted all the necessary lines from the .cmb and pasted them into the .organ file at the proper place for each of them one by one. This is much too much work I think now...

It's so much more effective to just produce the basic odf as I want it to be, make all the adjustments in GO and export the settings with the same name as the .organ file and put it in the same directory and be done with it.

[larspalo]

@oleg68 @rousseldenis At the risk of being accused of thread necromancy - I've finally been able to put together a small program for creating (and hopefully in the future editing) .organ files. Basically everything one can do in an odf is possible to create from this program (one of the few things I've ignored is the tracker delay). If you want to test it, you'll find it at https://github.com/larspalo/GOODF. If you do test it, please think about if this is a way forward or not - that is: if you believe it's a good idea to devote any more time to keep developing it or not.