On 13/02/2019 15:30, Christian Schoenebeck wrote:
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?
No. There isn't that much in them. The xfil chunk consists of a 32-bit
count, followed by a series of 144 byte records containing a filename
string, the file extension repeated and a dlsid. The doxf chunk contains
a 32-bit integer, a string and a dlsid. The libraries with extension
files that I tested all had this integer set to '99' which I think
corresponds to the .gx99 file extension. And yet changing this to
different values and renaming the extension file accordingly doesn't
produce output that GSt3 can open. The string also appears redundant as
changing it or 'zeroing' it has no discernible effect in the GSt3 editor
or main app. Its contents don't appear in the GSt3 editor File Info
dialog either. So in my patch LS doesn't change anything except the
dlsid in the doxf chunk.
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.
Agreed. I'll make a start on getting libgig to create 32-bit GSt
extension files.
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.
Yes. Support for relative paths would be good. I was thinking of
relative paths recently when wondering how to detect the user calling
"Save As..." on the same gig file so that libgig could call "Save" instead.
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.
The Drag & Drop that is used for assigning samples is great. I wonder if
something similar could be used for assigning content to extension
files? I'll have to think about it more though.
CU
Christian
All the best,
Ivan
_______________________________________________
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
