Inheritance model

[michelkeijzers]

As promised some time ago, I would write something about the so called inheritance model as I named it.

The title sounds strange, but in this post I want to show an idea how to fix one of the most spoken problem in the korgforums: programs cannot be edited in combi mode.

Alltough this is not completely true, it is true that only one program can be changed and to change another program you have to save the first program before you switch to another program if you want to retain the changes.

First, there is already a bit of inheritance inside a combi. If you look at the <OSC> page, you find e.g. the parameter 'portamento'. It can be set to PRG or set to an overridden value. If you select PRG, the value of the program itself is used, otherwise the new value is used.
However, this is only implemented for a few parameters. So the basic idea: why not do it for ALL parameters?

This means that instead of the few overridden parameters, all same screens for a program should be accessible from the combi mode (having the same view of course, except maybe for a field to show you are in combi mode).

If you select PRG, the original program value will be selected. And the value should be added in e.g. brackets.
If you select a value, then the program value is not used but the overridden value.

"Maybe it would even be better to have two types of override modes per parameter: PRG (using the program value), ABS (override it to an absolute value), % (change the value as a percentage of the program value), and +/- (change the value with a modifier). E.g. the volume of any parameter of each program in a combi can be like on of the four formats:
PRG[40] : the value of the original program will be used (which is 40)
ABS 80 : the value is overriden to a fixed value of 80
-20% [60]: the value is changed by -20% compared to the original program value which results in 60
+10 [90]: the value is changed by +10 compared to the original program value which results in 90."

However, you can even add a new inheritance level: not only for overridden program parameters in a combi as described above but also for a complete combi. Like changing the overall volume of a combi to -20% to lower the values of all programs in the combi with 20%, or changing the transpose of all programs to +4 (so you don't have to change every program in the combi).

However, this can give problems because drum programs should not be transposed. Therefor for every parameter there should be a check box that says if it may be overridden or not (both in programs and combi timbres). So if you disable this feature for the drum program and change the transpose to ABS +4 the drum program will still remain its programmed value in the combi timbre (except if it is set not to be overriden in the program).

Maybe it sounds a bit complicated, but it's very flexible and really consequent for all parameters.

The disadvantage is that the storage space will increase (about a factor 16 plus a bit).
This means not 35 MB but about 700 MB ... but with the 4 GB expansion it would not be a problem.

Korg wants to be flexible ... this would be the ultimate way.

Shoot at the idea

[EvilDragon]

Not really 700 MB either. Stephen Kay indulged me and calculated how much RAM it would take if every combi in Kronos was self-contained (meaning that ALL programs are contained in combi file, and can be edited without changing the original program):

http://www.korgforums.com/forum/phpBB2/ ... 502#377502

[michelkeijzers]

Not really 700 MB either. Stephen Kay indulged me and calculated how much RAM it would take if every combi in Kronos was self-contained (meaning that ALL programs are contained in combi file, and can be edited without changing the original program):

http://www.korgforums.com/forum/phpBB2/ ... 502#377502

Thanks for that post, very interesting. So it's even less. However, my 'inheritance' settings (disable inheritance and inheritance type will add also quite some extra need of memory). For EVERY parameter there will be an enable/disable inheritance and inheritance type (Prg, Abs, %, Rel value). Very costly but very flexible. But it really doesn't matter that much if it would be 30MB, 60 or 300MB (if the next SSD will be bigger not at all).

and by the way ... thanks for replying ... I was afraid my post was to long to be read

[EvilDragon]

Actually, I don't see a lot of point in those different inheritance modes, when you can simply directly change the WHOLE program, if a combi is self-contained!

So, RAM utilization would actually be pretty conservative if nothing but self-contained combis are being used - IMHO there's no need for "inheritance types" as you've described. I'd be awesomely happy with just the self-contained combis. But, that won't happen on the Kronos most likely...

[michelkeijzers]

This post was only made to make clear as an alternative of what could be possible.

The advantages of the inheritance modes are:
- you can use the programs and use them in combis exactly as they are (every parameter should be set to overridable (default) and in the combi set to PRG. This is the default behavior as it is now.
- by setting a parameter in the program (inside a combi) to either %, Abs or Rel it behaves like a Tone Adjust, except that it works for ANY parameter and has a bit more options.
- by having the disable override boolean you can make sure some parameters cannot be overridden (like transpose for drum programs).
- if you improve a single program automatically all combis making use of it will improved.
- for the generic combi inheritance settings, you can e.g. change one transpose variable to change all timbres in a combi to a value (requested in a post as wish).

So actually this model would solve several problems.

Of course I understand we will not soon see something of this, especially not int he current Kronos, but I think it is an idea to take (partly) into account.