On Mittwoch, 13. Februar 2019 18:00:00 CET Ivan Maguidhir wrote:
> 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.
Yeah, there are numerous similar strange things in the gig format. :)
> 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.
That requires some more low-levelish trick. Basically that is done by
retrieving the inode number of two files you want to compare with. If the inode
number is identical (even though having different files names or path) then the
files are actually identical.
So far I haven't done that yet, because that code is system dependent and
sometimes even file system type dependent, so it would need to be implemented
for them individually. But maybe we could start by adding code for the most
popular ones, and the other one would still get the old warning when selecting
Save as ...
Also note that term "inode" is usually used by Linux file systems like
ext2/3/4, other file systems use a different term, even though the concept is
mostly the same.
> 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.
Would be an option, sure. But I still wonder at which point things should be
possible to be assigned to extension files at first place. At the moment I
think
I would probably restrict to assign content to extension files on
a) {sample group} and
b) {instrument} level.
That could already be sufficient I think.
Allowing to assign also individual samples or even dimension regions or
something to extension files would probably be overkill and I think not worth
the hassle.
And for instrument scripts this could also either be done on script group
level or, other possibility: *only* automatically, in the latter case libgig
would rather auto detect which exported instrument references some script and
automatically export the script as well. Both solutions have pros and cons.
But these are just some thoughts for now ...
CU
Christian
_______________________________________________
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
