On 5/19/20 12:44 PM, Christian Schoenebeck wrote:
How exactly do you load the file? If the file is explicitly loaded on a
sampler part by file name AND the file is not already used on another sampler
part then the sampler should really load the latest file version.
Things are different if you have multiple samplers parts which are using the
file, in this case the sampler detects that the file is already in use on
another part and simply uses the one that's already loaded instead of loading
the file again from disk.
The sampler might also behave like that if the file is not directly loaded,
but instead indirectly by MIDI program change and MIDI instrument map. In this
case it depends how the load strategy was defined in the instrument map's
entry by you (e.g. "on demand", "on demand hold", "persistent") and of course
as well whether the instrument is used on another part.
But you are right, that even in such cases (if the file is already loaded and
in use), the sampler should check if there's a new version on disk (e.g. by
comparing the file's mod time). That lacking detection is probably due to my
personal preference of just using the gig engine, in which case Gigedit would
be used for any instrument modifications; Gigedit always informs the sampler
explicitly in real-time that certain parts of the file (and which parts
exactly) had been changed and that the sampler should reload these parts.
I suppose the situation might be as you described here. I probably
already loaded one in a channel. Will keep an eye on it.
Same for the database update wait time. I've to restart Linuxsampler and
Fantasia every time I update the database. :-\
Yes, that's currently definitely the case. The sampler currently does not
automatically refresh the instruments DB automatically on external changes to
files.
The sad truth is, there's currently no one actively taking care about the
sampler's sfz engine. And that situation persists for several years now.
I am personally just using the gig engine and hence my entire focus is on this
part of the sampler. I basically only handle odd fixes on sfz engine side. The
only new features on sfz side usually appear these days if they are added to
the common code shared by all 3 engines (gig, sfz, sf2) in which case they
"popup for free" in all other engines.
This is sad indeed. SFZ seems to be a very nice format. Very open and
easy configurable for everyone.
It's not that there are no people working on SFZ on Linux though. Sfizz
is actively developed for instance: https://github.com/sfztools/sfizz
And if I'm not mistaken, drumgizmo also supports SFZ.
The exception on the GPL license for Linuxsampler doesn't help here
probably. I'm sure you've debated this many times, which is not my
intention. But from a practical point of view, I could see how a pure
GPL license could help Linuxsampler here. People are probably more
willing to work on the project instead of starting a new project (sfizz).
Ok, you don't want other commercial parties benefit from your work,
without giving back, but how popular are gig and SFZ in the commercial
world these days? And GPL makes that those other parties should release
their source code additions too of course, so you would also benefit
from it, I would think.
On the positive side, it would be very nice for Linuxaudio to see more
developments on the SFZ side of the linuxsampler and it would help
promote the SFZ format. There are certainly gains. I wonder what you
really have to loose here for yourself, when you remove the commercial
exception.
If there's really a problem in detecting relative vs absolute path here, then
it should be easy to fix.
Thanks. I don't think it has to do with relative vs absolute path indeed.
The mentioned issues can be really frustrating, especially if you don't
know the cause and don't know how to workaround it. These issues drives
you mad on Linuxaudio pretty often to be honest. :)
On the other hand it's good to realize for me as a user that it's pretty
cool I'm able to use good software like this, so thanks for that!
By the way I had a little chat with the guys of
https://vis.versilstudios.com/
They said they released their SFZ stuff for sforzando, cause it had the
largest market share and the problem of the SFZ format for them is the
fact that not all the software supports the same SFZ opcode. Some opcode
works in one and not in the other.
Regards,
\r
_______________________________________________
Linuxsampler-devel mailing list
Linuxsampler-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
