On Mittwoch, 20. Februar 2019 16:38:31 CET Ivan Maguidhir wrote:
> On 20/02/2019 12:36, Christian Schoenebeck wrote:
> > Please share your design ideas before implementing anything to avoid
> > substantial code rewrites later on.
>
> Sorry about that. I will in future.
Ok, I just committed the libgig changes for writing gig extension files (SVN
r3474). Please review and test them, because most nostably I do not have any
gigs with extension files so I cannot test it, and I am also missing some
knowledge about the new chunks (see below).
These were the adjustments I made regarding your patch:
1. Moved out all file path parsing code as helper functions, instead of doing
those string parsing tasks directly in the file saving / loading methods.
and more importantly:
2. I tried to generalize your code more in order to also allow to save gigs
with any different amount of extension files. So it is now also valid to
remove or add extension files without getting an exception when eventually
trying to save it.
But there is still some work to do for my changes in (2.) for becoming
actually useful; most importantly when saving a gig file, the samples should
automatically be (re)assigned over individual extension files and accordingly
also the amount of extension files should automatically be increased or
decreased accordingly. I have no plans in the next days or so to do that
though. I will process the MSVC patch next.
Also note in DLS.cpp, where it is now automatically creating the 'doxf' chunk
if missing, I was assuming a chunk size of 148 bytes. Is that correct?
And I also figured out now what this ominous ".gx99" file is about: that's for
writing convolution effect data (a.k.a. GigaPulse). So now that makes more
sense why that is always handled separately as .gx99.
> > For example looking at your screen shot, I don't think that setting a
> > maximum file size for extension files is necessary at all. I think the
> > GSt way of saving extension files (.gx01, .gx02, ... , .gx99) should only
> > be used for saving gig files intended to be compatible with the
> > GigaStudio software, and in that case the max. files size would be always
> > 2GB anyway.
>
> The changes I've made to gigedit and libgig are only for creating
> Gigastudio compatible extension files. I included the max file size
> setting only because it's there in the GSt3 save dialog. As you
Ah, interesting, I see. Ok, then fine, I did not know that. My knowledge was
that GigaStudio would always simply distribute over 2GB files when saving. I
did not know there was an option to change the individual file size.
> correctly point out no one would really need to change this value. The
> default setting in the GSt3 editor is 2040. I think this is in
> mebibytes. My idea was to add/remove extension files as samples are
> being added/removed instead of doing all the work of splitting the .gig
> up during a File::Save().
So I would suggest simply adding two checkboxes to gigedit's file format
dialog:
- "Large File Support" (default on)
- "GigaStudio Legacy Extension Files" (default off)
And if you want you can also preserve your individual file size setting of
course. And when "GigaStudio Legacy Extension Files" is turned on, then "Large
File Support" is automatically turned off and vice versa. So there would only
be 3 possibilities:
1. Large File On, Legacy Ext. Off
2. Large File Off, Legacy Ext. Off
3. Large File Off, Legacy Ext. On
And later on (not yet now), I would add a third checkbox e.g. "Next Gen.
Extension Files (incompatible with GigaStudio)" with the more fancy way of
modularizing parts of a gig file, like we discussed recently and hopefully will
discuss in more detail soon.
> > Please also note that I am currently adjusting your previous libgig patch
> > for allowing to save also with a different amount of extension files. So
> > keep that in mind to avoid we two are working on the same thing. I expect
> > to commit these libgig changes in the next couple hours.
>
> Many thanks for doing that.
Thanks for your patch Ivan!
CU
Christian
_______________________________________________
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
