Re: [Linuxsampler-devel] Multi-part load and save

[Ivan M. <iv...@ma...>]

On 12/02/2019 13:29, Christian Schoenebeck wrote:
> Hi Ivan,
Hi Christian
> So far I haven't had the time to look at your patch thoroughly yet, but here
> some questions ...
No problem at all.
> Are those chunk types also used by GSt or have you introduced them? If you
> have introduced them, what are the precise reasons for introducing them?
Yes, these chunk types are used by GSt. I figured out their structure by 
looking at gig files in a hex editor, some guesswork and modifying of 
libgig and testing its output in the GSt3 editor and main GSt3 
application. I made little text diagrams showing the structure of the 
chunks as well, but I thought including them in the source code might be 
a bit over-the-top :-)
> GSt never supported gig files with 64 bit RIFF file offsets. I introduced that
> feature to allow writing gig files larger than 4 GB witht libgig, as one large
> gig file without extension files that is:
>
> http://doc.linuxsampler.org/Release_Notes/LinuxSampler_2_1_0/#libgig_4_1_0
Sorry about that. I didn't realize 64-bit offsets were an extension. I 
was also thinking of the combined use of WavePoolTable and 
WavePoolTableHi, where WavePoolTableHi stores the extension file number, 
as being a 64-bit offset when it isn't really.
> Having said that, I currently wonder how to expose those two saving options to
> the API appropriately. My  first thought was that mixing both 64 bit offsets
> with extension files does not make sense and that it should be thus an either
> or. That is if a gig file already uses extension files then it would obviously
> save changes distributed over extension files by using all 32 bit offsets,
This is all that the patch allows - the saving of existing libraries 
which use extension files to the same or a new location.
> otherwise if somebody creates a new gig file from scratch with libgig then only
> when explicitly picking offset_size_32bit would cause extension files to be
> written.
I'm going to have a go at implementing this next.
> But on second thought, using both 64 bit and extensions files at the same time
> might be beneficial to split out certain aspects of a gig file intentionally to
> separate files while at the same time retaining things in large files. For
> instance what I could imagine is storing all samples of one sample group to
> the same file and distributing the individual sample groups over individual
> files.. That way sound designers could gain an option to create libraries in a
> more modular approach if desired, which is already standard with almost any
> other mordern sound library file format.

A solution might be to add an offset_size_32bit option to gigedit, as 
you suggested, which would cause the writing of extension files. In 
addition to this an "Extension Files" tab could be added to the 
left-hand pane in gigedit. This tab could contain a TreeView which would 
be inactive while offset_size_32bit was checked, with each 2GB extension 
file visible. Otherwise, users would be allowed to create and manage 
extension files of arbitrary size (but with a fixed offset size of 
64-bits) using the TreeView. Content could then be assigned to the 
created extension files from the other tabs and pages. A new chunk 
similar to the official 'xfil' chunk could be added to the main gig to 
list these extension files. Does that sound like it's workable?

> CU
> Christian
>
All the best,
Ivan