Revisiting the need for additional program banks

[danatkorg]

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.

That might work for your specific needs, but not for the general case - and the latter is what we have to solve for.

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)

That's SysEx. Due to various factors, a bank of 128 EXi Programs requires just shy of 2 MB of internal memory. (For practical purposes in this conversation, I'm using MB in its common but less precise usage, in which it is equivalent to MiB. )

So, when you write...

The additional 50 program banks I propose would take 30.2 MiBytes.

...it's actually closer to 100 MB.

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.

But, as noted, we don't currently have the luxury of dynamic memory allocation.

[danatkorg]

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?

That's part of it, yes.

The other part is to feel free to save and load banks to disk as required. I never worry about keeping everything loaded at once; instead, I have different PCGs for different projects, as necessary.

(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.

Specifically with Akai CDs, many that I've seen are crowded with minor variations of the same sound - for instance, one version that uses the mod wheel to control filter cutoff, another that uses aftertouch, etc. You may be able to get all of the actual useful sounds with just a few Programs per Volume. This will depend on the specific libraries, of course.

[timg11]

But, as noted, we don't currently have the luxury of dynamic memory allocation.

I'd be happy with non-dynamic. I remember on the Triton Studio, if I changed the SCSI mode from target to host, I had to restart for it to take effect.
A similar approach to change the global setting, and then reboot to load a with a different memory allocation would be fine. It sounds like most people are polarized between wanting more program banks and not caring so much about sample ram, or those that care only about sample ram, and don't need program banks. So most of us would make the setting once, and never change it.

I do understand that such a scheme makes it more difficult to test and maintain the OS, but it might be a viable "stop gap" on the way to a 64 bit future....

[danatkorg]

But, as noted, we don't currently have the luxury of dynamic memory allocation.

I'd be happy with non-dynamic. I remember on the Triton Studio, if I changed the SCSI mode from target to host, I had to restart for it to take effect.

A similar approach to change the global setting, and then reboot to load a with a different memory allocation would be fine. It sounds like most people are polarized between wanting more program banks and not caring so much about sample ram, or those that care only about sample ram, and don't need program banks. So most of us would make the setting once, and never change it.

I do understand that such a scheme makes it more difficult to test and maintain the OS, but it might be a viable "stop gap" on the way to a 64 bit future....

I understand the desire. Unfortunately , I don't think that this would be a practical approach. For one thing, it would have wide-ranging side effects throughout the system, including disk operations, Program selection, SysEx, front panel, and internal data references (e.g. Combi -> Program, Program -> Wave Sequence etc.).

[Aziz1008]

If memory will ever allow more banks, we can switch them by pressing simultaneously for example A-I and B-U, A-I and C-U and so on. That would give us almost 256 banks. Also, there's a desire to switch to expanded banks not only by dual pressing of buttons, but sequentially pressing one after another within short period of time. This is more handy than having to press both banks. But actually I think banks number is more than enough. You have to dedicate one bank as Temporary project bank and overwrite its content with new project.

I think Musical instrument should not try to mimic a computer. There're so many bells and whistles in pc that just distract you from music, so I have bought Kronos. Just to find that it is almost as complicated as my PC)) That's why I love my Roland GW 7 - a simple instrument which forces me to be a musician, and not sound engineer/programmer.