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
_______________________________________________
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
