Revisiting the need for additional program banks

[timg11]

The number of program banks available on the Kronos has been discussed at length here before. Some people are satisfied with the number of existing program banks, others (including myself) see a need for more.

I'm sure Korg would like for Kronos owners to continue purchasing new sounds and samples throughout the life of their instrument. In my case, I had filled all my program banks within the first year of owning the Kronos. Now whenever I want to add a new bank, I have to work through a tedious pruning and re-organizing process to make room. The excellent PCGTools software make that process possible, but it is still tedious.

I would definitely purchase more sounds from Korg and others if I had spare banks to load them. Adding more banks seems like the most straightforward solution. Of course, there is no downside for those who don't want or need them.

To "kickstart" the process, I made a fairly detailed proposal on how this expansion could be accomplished earlier this year. The thread "fizzled out" before Dan or other experts weighed in on the idea. I have updated the proposal and slightly simplified it.

I would like comments from those in possession of detailed knowledge of the Kronos on whether it is practical. I'm hoping that by providing the detailed approach, it could get past Korg's "inertia" for implementation.

[michelkeijzers]

Actually, it would be even better if there would be a more flexible model. Like being able to create a PCG file with a flexible amount of program banks, combi banks and set lists.

Actually, more or less the PCG file structure is already possible. The virtual bank file to be used for PCG Tools is a normal PCG file. The only problem is the OS does not read it.

There are some disadvantages of course about big PCG files, like larger file, more memory needs, longer loading times. But it would be nice if some people who use less sounds can use e.g. 4 program banks and 4 combi banks and others can use 100 program banks and 100 combi banks.

[Pedja]

timg11 thanks for this theme. It's not a first time that someone write about that. I am in same situation too, with program and combi banks, only HD banks are not full on my Kronos. It will be really very good that Korg provide in new OS patch, more PCG and combi banks. Thanks for all your attention.

[Melomaniak]

Yes, that would be very nice!

[lucy]

I've only had my Kronos2 for 6 weeks, there are loads of combi slots, probably as many as I will ever need, but I can already see the need for more programme slots.
If it's any incentive to Korg, I'd be spending like crazy on downloads if I could have several more programme banks available on the machine itself.
xx

[danatkorg]

To "kickstart" the process, I made a fairly detailed proposal on how this expansion could be accomplished earlier this year. The thread "fizzled out" before Dan or other experts weighed in on the idea. I have updated the proposal and slightly simplified it.

I would like comments from those in possession of detailed knowledge of the Kronos on whether it is practical. I'm hoping that by providing the detailed approach, it could get past Korg's "inertia" for implementation.

I appreciate your thoughts, but the stuff you address in your proposal isn't the issue. Selection is easily done; we've had the same ideas for years. The problem is that program banks require memory - a lot of it. More banks = less space for samples.

Also, you write:

"Can the Kronos support these additional banks? Given the relatively long amount of time taken to write programs and combis, it is possible that the Kronos uses Flash memory for the program and combi storage. There is no way to know how much is available, but given that modern Flash memory chips come in increments of GiBytes, it is hard to imagine that 23 additional MiBytes would not be available."

Actually, as has been discussed previously, the KRONOS uses the motherboard RAM for everything: system, samples, program banks, sequencer etc. Everything comes out of the same pie.

And yes, it would be nice to support more than 3 GB of RAM, and/or to support more dynamic memory allocation, both of which would be helpful in this case. Neither is going to happen very soon, however.

Best regards,

Dan

[timg11]

Actually, as has been discussed previously, the KRONOS uses the motherboard RAM for everything: system, samples, program banks, sequencer etc. Everything comes out of the same pie.

Dan,

Thanks for the reply.
With the development of "User banks", I don't find I am running up against RAM limits as much.
I would gladly give up 23 Mbytes of RAM to have more program banks.

Are you saying that the RAM requirements for a program bank is much higher than the data structure size that is presented in the MIDI implementation documents? Is my estimate of 23 Mbytes way off in terms of actual impact on the RAM pool?

If 23 Mbytes is correct, and everything really comes out of the same pie, then I think 23 Mbytes is a very tiny amount out of the 3 Gbytes available, in consideration of the value to the users.

[danatkorg]

Actually, as has been discussed previously, the KRONOS uses the motherboard RAM for everything: system, samples, program banks, sequencer etc. Everything comes out of the same pie.

Dan,

Thanks for the reply.
With the development of "User banks", I don't find I am running up against RAM limits as much.
I would gladly give up 23 Mbytes of RAM to have more program banks.

Are you saying that the RAM requirements for a program bank is much higher than the data structure size that is presented in the MIDI implementation documents? Is my estimate of 23 Mbytes way off in terms of actual impact on the RAM pool?

If 23 Mbytes is correct, and everything really comes out of the same pie, then I think 23 Mbytes is a very tiny amount out of the 3 Gbytes available, in consideration of the value to the users.

You might well be happy to give up sample RAM for Program banks, but others might not be - especially if it means that difference between an old set of sounds fitting, and not fitting.

For additional program banks, I would strongly encourage people to use the disk. It's fast and easy, and fits thousands of banks. That's the solution for the KRONOS platform, imo.

[EnSoNiQuEs~]

Dan,

thanks for the reply. Please excuse my newbieness to the Kronos program bank methodology, but can you elaborate a bit more on what you said:

"I would strongly encourage people to use the disk. It's fast and easy, and fits thousands of banks."

Do you mean create multiple PCG files for additional program banks, and simply preview them from the disk and only load the ones you need...sort of like prune off/not load what you don't want?

Is that the solution you mention?

(In my other post a day or so ago, I'm trying to figure out how best to load all my AKAI CDs as User Samples[taking up disk space], and solve the program bank limitation. I'm no where near the RAM limit, and would surely sacrifice more RAM for more program banks.)

Any guidance is greatly appreciated.

Thank you.

[michelkeijzers]

[quote="danatkorgYou might well be happy to give up sample RAM for Program banks, but others might not be - especially if it means that difference between an old set of sounds fitting, and not fitting.[/quote]

Personally I think a lot of people would give up like a few 100 MB for another bunch of program and/or combi banks. Actually, I would go even further, like making it possible to have 256 (or as much as possible) program and/or combi banks. The PCG file structure already supports this (hence the Virtual PCG file used by PCG Tools which has 64 extra program and combi banks).

People will possibly need to reduce the sample usage by 100 MB which is a one time step. I think currently all samples from EXs are loaded. It would be better if only those samples are loaded which are actually used by programs.

I cannot imagine loading a file of a few 100 MB takes long, but the processing of a lot of program banks might take some time. This can be optimized by processing them after loading. Or even process them when needed (on the fly) when a program, or combi/set list slot has been selected that uses the programs.

[Sharp]

RAM for sampling is way more important to me. Even if something as small as 20MB was taken from Sample RAM and allocated to Banks, that 20MB is a lost of almost 200MB of samples when you consider streaming.

I'd much rather see things stay as they are with the KRONOS right now and hope that KORG are working on going 64Bit for whatever comes after the KRONOS series.

Regards
Sharp.

[danatkorg]

You might well be happy to give up sample RAM for Program banks, but others might not be - especially if it means that difference between an old set of sounds fitting, and not fitting.

Personally I think a lot of people would give up like a few 100 MB for another bunch of program and/or combi banks. Actually, I would go even further, like making it possible to have 256 (or as much as possible) program and/or combi banks. The PCG file structure already supports this (hence the Virtual PCG file used by PCG Tools which has 64 extra program and combi banks).

People will possibly need to reduce the sample usage by 100 MB which is a one time step.

By a very rough calculation, 256 sets of Program, Combi, Wave Sequence, and Drum Kit banks would be something upwards of 750 MB. That's a lot of samples, even with VMT.

While you may think that people would be happy with some amount of reduction in sample RAM, I can ASSURE you that people would scream bloody murder if they had sounds that fit into memory in version X, which then did not fit in version X+1. It's a non-starter.

As noted previously, I agree that it would be nice if the memory management was dynamic. It's not - and some of that is related to how the KRONOS can still do things that native computer systems cannot, including managing the polyphony of a diverse set of synthesis algorithms and pushing the hardware right to the edge without glitching. Maybe we'll be able to make this different in the future, but if so it would be a very big change.

I think currently all samples from EXs are loaded. It would be better if only those samples are loaded which are actually used by programs.

Of course it would, and we've had the same opinion since about 2001 when we first started work on the OASYS platform. Most things are easier to say than to do, especially with an installed user-base and/or code-base. We've actually taken steps towards this in more recent updates, with the "Load required samples" feature. I agree that it would be nice to take this one step further and do it automatically.

Of course, if you're loading an EXs option bank, all samples will already be used by Programs - we don't include the samples otherwise. It's only if you're loading only a subset of the Programs that this becomes an issue.

- Dan

[Dniss]

I wouldn't want to trade in sample memory for more banks.

I mean, how many banks can someone realistically need in a single project? There's like 1000 program bank and 1000 combi bank in one single pcg file. That's ludicrous.

Save your bank set use a new file for a different project and so on. Since the number of files is only limited by disk space, you could have zillions sets of ...1000 sound bank.

Just my 2 cents.

[jeebustrain]

You might well be happy to give up sample RAM for Program banks, but others might not be - especially if it means that difference between an old set of sounds fitting, and not fitting.

Personally I think a lot of people would give up like a few 100 MB for another bunch of program and/or combi banks. Actually, I would go even further, like making it possible to have 256 (or as much as possible) program and/or combi banks. The PCG file structure already supports this (hence the Virtual PCG file used by PCG Tools which has 64 extra program and combi banks).

People will possibly need to reduce the sample usage by 100 MB which is a one time step.

By a very rough calculation, 256 sets of Program, Combi, Wave Sequence, and Drum Kit banks would be something upwards of 750 MB. That's a lot of samples, even with VMT.

While you may think that people would be happy with some amount of reduction in sample RAM, I can ASSURE you that people would scream bloody murder if they had sounds that fit into memory in version X, which then did not fit in version X+1. It's a non-starter.

As noted previously, I agree that it would be nice if the memory management was dynamic. It's not - and some of that is related to how the KRONOS can still do things that native computer systems cannot, including managing the polyphony of a diverse set of synthesis algorithms and pushing the hardware right to the edge without glitching. Maybe we'll be able to make this different in the future, but if so it would be a very big change.

I think currently all samples from EXs are loaded. It would be better if only those samples are loaded which are actually used by programs.

Of course it would, and we've had the same opinion since about 2001 when we first started work on the OASYS platform. Most things are easier to say than to do, especially with an installed user-base and/or code-base. We've actually taken steps towards this in more recent updates, with the "Load required samples" feature. I agree that it would be nice to take this one step further and do it automatically.

Of course, if you're loading an EXs option bank, all samples will already be used by Programs - we don't include the samples otherwise. It's only if you're loading only a subset of the Programs that this becomes an issue.

- Dan

Thanks for the explanation, Dan. I'm from the camp that would love more banks, but now I completely understand the difficulty a lot better. I think the almost limitless expansion capabilities of modern PCs have spoiled us.

[timg11]

By a very rough calculation, 256 sets of Program, Combi, Wave Sequence, and Drum Kit banks would be something upwards of 750 MB. That's a lot of samples, even with VMT.

Ah - I understand the size gap. Granted you were responding to Michel's suggestion, but I'm only proposing additional Program banks - nothing else. I still have several Combi banks unused, and have never run into shortages of Wave Sequences or Drum Kits.

The largest program structure (EXi) is documented in Prog_EXi_Common.txt as 4960 bytes. A bank of 128 is 634880 bytes. The Kronos currently offers 31 banks, including the fixed I-G bank. That is a total of 18.8 MiBytes. (Mi is 2^20)

The additional 50 program banks I propose would take 30.2 MiBytes. (If they were all HD-1 they would take 22.6 MiBytes, although if the memory allocation is fixed, then presumably the full space is allocated for all).

30 MiBytes is significantly less than 755 MB. Still as you mention, there may be some who have so much sample data they cannot afford to spare even 1 MB. In that case a global setting for "Enable Extra Program Banks" would be a possible solution.