On Mittwoch, 13. Februar 2019 02:27:22 CET Ivan Maguidhir wrote: > > 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 :-)
Ah I see, great! Does that mean you even explored more information/features in those new GSt chunks than currently covered by your patch so far? > > 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 Yep, that was also my idea. > 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? Yes, it goes into the direction I thought about as well. But let's postpone any code for that custom 64-bit extension file feature for the moment and let's just finish the 32-bit GSt extension file feature for now. Because I still want to think about that custom 64-bit extension files feature for a while, since I want it not only to be powerful but also very user friendly. There are some aspects that should be designed appropriately right from the start without having to rewrite everything in libgig, LS and gigedit after a month or so. For instance I would like individual extension files to be sharable among different (main) gig files. If all those individual gig files are probably in separate directories (for instance think about a large directory tree with shared multi samples), then there should be some kind of support for relative paths or something. And that's where things can easily become tricky for not becoming a nightmare for users. Another thing is that adding an extension file in gigedit should be a quick and easy feature. I like the idea of having a 4th tab for showing all extension files, but yet people should also not being forced to make a dozent of clicks and keyboard entries just to create and assign one new extension file. CU Christian _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
