For those of you wondering about the status of my 16 layer Steinway-C piano, I felt it appropriate to mention a problem which I have run into. This may also effect others who are working on extremely large instruments.
I would like to keep all of the long recorded note decays, which would result in the 16 layer piano being about 5 Gigabytes when all the layers are merged.
However, I have hit what seems to be an internal limit of the Gigasampler editor when trying to create a single instrument file larger than 2 Gigabytes. It seems that no matter how much free space I have on my harddisk, the gigasampler editor will not recognize any free space above a 2 Gig size limit. The edit reports:
\"Temp Free 2047.7 MB \"
in the status bar regardless of the fact that I have much more space free on the gigasampler\'s temp drive.
If I ignore this and try to create and save a file with the oversized extra layer,then I get a \"error creating chunk\" error message and the editor save process aborts.
I will be sending an e-mail to the folks at Nemesys regarding this, but was wondering if any other folks have hit this 2 gig instrument limit.
If so, have any of you found a way around it.
I\'m running on Win\'98, and the disk partition itself is at 6 Gigs.
There should be plenty of room as far as Windows is concerned.
Thanks in advance for any help.
I have posted a status page for the progress of the new 16 layer piano at: http://www.wstco.com/gigastatus/
and I will include any information about breaking the 2 gigabyte file size barrier for gigainstruments on that page if I do learn of any workarounds.
Warren, I don\'t have any great tips to get around your problem, but I do wonder what kind of system would be necessary for such a huge instrument. My P3-500 w/ 128 megs and 2 huge hard drives (one is U2W scsi) was kind of at the edge for the Boesendorfer, I had to expand the memory to 256 to make this one run consistently well alongside a sequencer, and that\'s a lot smaller(!) than yours. And while GS itself is quite low latency for me, the kernel extensions that make this possible are pretty system intensive and when it hits the disk hard to stream in notes, I get buffer underruns if my recorders are run with input buffers < about 100ms. Without the disk thrash, I can run many things and still record well with input buffers under 20ms.
So I\'ve got a pretty heavyweight system, but I probably don\'t have the disk space on my fastest disk for a 5G piano, and I might not have enough memory to run such a monster. Just a request that whatever you do should be runnable by mortals, you may be pushing the limit! (I\'m not trying to be discouraging, I dig what you\'re trying to do!)
I have a similar concern. But so far, I have tested the layers and the in-process combined instrument on a Pentium-II, 333MHz machine, and everything is running quite well on that lowly device. It is only running Cakewalk and Gigasampler, but I am using this system to verify that my piano instrument should be useable on most typical systems.
In addition to Gigasampler, I use other, non-real-time software for MIDI rendering, which is not limited in polyphony, and which can handle the full number of layers (at least so far).
However, it looks like even the new Gigastudio will be limited to a 4Gig instrument file. I guess this is the downside of requiring a single, huge instrument file rather than keeping the samples as independent individual wavefiles in a library directory.
The number of strike layers the Gigasampler can handle is directly related to the RAM, so that the start of each sample can be pre-loaded to provide the low latency for real-time playback. I knew about this limit, and was prepared to perhaps make a version with fewer layers for folks with \"only\" 256MB of RAM. However, I had been under the impression that disk space usage was not the limiting issue. Evidently this is not correct, and file size can indeed limit the instruments.
I\'ll do the best I can within the limitations of the Gigasampler (and the upcoming Gigastudio). But unless the folks at Nemesys can give me some work-arounds, it looks like I may have to await the next generation \"Tera-Sampler-Studio\" before the software can handle all the sample layers and polyphony I would really like to have to model things more accurately.
The limit on a 32 bit file system is 2^32 = 4GB, so we are looking into this - you should be able to achieve at least 4GB per individual file.
Another option is the 100% lossless compression technology as used within several of the Nemesys instruments.
The Plus side:
 On piano gets appx 2:1 with no quality loss whatsoever.
 less disk space.
 faster backup/restore times
 better streaming on hard disk (more polyphony on some systems)
 bank exporting of individual encoded waves are \'pirate resistant\' (proprietary compression format)
The minus side:
 no direct export of individual samples for wave editing (without re-sampling within GigaSampler/GigaStudio)
 the compression tool is \'internal use only\' status (i.e. not ready for large scale release) , and not made widely availible for this reason.
Nemesys can license it free of charge in certain special cases like this that can benefit from it. We can extend this to Warren if he sees this as a viable solution.
It could be possibly be \'productized\' for open release if there is enough need for it.
Danny Lux : What if you split the
pedal up and down samples into 2 separate patches
I had not used this feature before, but it seems to work OK.
Distributing the piano as two separate instruments which have to be loaded as two layers may confuse some users, but this is a technique I can use myself in the meantime. For some of the pedal-down tricks, I need to rely on having those layers kept in exact phase-lock with the other pedal-up layers. Perhaps someone from Nemesys can comment on whether this is the case when two separate instruments are layered in this manner. If the triggering of the two layers can vary within +/- the latency, then this may change my strategy.
Jim Van Buskirk : The limit on a 32 bit file system is 2^32 = 4GB, so we are looking into this - you should be able to achieve at least 4GB per individual file.
Another option is the 100% lossless compression technology as used within several of the Nemesys instruments
The hard disk I am using for the gigasampler\'s \"temp\" directory, and also onto which I am attempting to save the 2+Gig instrument, is a pure FAT32 formatted disk. However, if this info helps in the investigation, the Gigasampler program itself is running from a different hard disk, which was previously converted from FAT16 to FAT32. If it is possible that the conversion left some residual \"FAT16\" info set somewhere which the gigasampler editor is finding, I am willing to try re-installing new on the pure FAT32 harddisk if you think this might help.
I would also like to take you up on the offer to use the compression on the samples. The plusses seem to outweigh the minuses on that decision.
Can you also comment on whether the 4 gig limit will remain for a total instrument file in the new Gigastudio. There is some ambiguity (see software issues post) as to whether this will apply to the overall gigainstrument file or a single sample embedded in an instrument file for the new Gigastudio editor.
Bill : I’m wondering if you have the temp directory set to a different drive that has less space
No, I wish it were that simple, but I have the directories set properly. I did try a few different temp directories with the same results before posting about the issue.
I would love to have access to the lossless compression scheme as well. As I put together my library of sounds, I am going through hard disk space like crazy. Also, I want to be able to get as much throughput from my drives as possible. If a piano for instance compresses at a 2 to 1 ratio, playing that piano would tax the GS hard disk half as hard. That is a major improvement. I\'ll bet the 190 voice count that is being touted for Gigastudio makes good use of this compression scheme. Count mine as a vote for making this software available.