linuxsampler-devel

[Linuxsampler-devel] default_path SFZ

[rosea.grammostola <ros...@gm...>]

Hi,

I've two sfz files. Both with a default_path. In the first Linuxsampler 
is totally okay with the file. In the second it says:


Scheduling 
'/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D.sfz' 
(Index=0) to be loaded in background (if not loaded yet).
Loading sfz instrument 
('/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D.sfz',0)...OK
Caching initial samples...sfz::Engine error: Failed to load instrument, 
cause: 
/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/~/linuxaudio/NDK/samples/kicks/kd14bop/snare_off/cls/kd14bop_cls_001.wav: 
Can't get sample info: System error : No such file or directory.


It seems to search for a relative path, even if default_path is set.


1) 
https://github.com/grammoboy2/NDK-SFZ/blob/master/kicks_D/kd14bop_off_cls_All.sfz

2) 
https://github.com/grammoboy2/NDK-SFZ/blob/master/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D.sfz


Regards,

\r

Re: [Linuxsampler-devel] default_path SFZ

[rosea.grammostola <ros...@gm...>]

Maybe I'm start getting blind, but I don't see why D-3 is working and 
D-3-2 is not:


-rw-r--r-- 1 debian debian 2688 May 18 13:33 
kd14_bop_snare_off_cls-D-3-2.sfz
-rw-r--r-- 1 debian debian 2688 May 18 13:16 kd14_bop_snare_off_cls-D-3.sfz




Scheduling 
'/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D-3-2.sfz' 
(Index=0) to be loaded in background (if not loaded yet).
Loading sfz file 
'/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D-3-2.sfz'...OK
Loading sfz instrument 
('/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D-3-2.sfz',0)...OK
Caching initial samples...OK
Scheduling 
'/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D-3.sfz' 
(Index=0) to be loaded in background (if not loaded yet).
Freeing sfz file from memory...OK
Loading sfz instrument 
('/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D-3.sfz',0)...OK
Caching initial samples...sfz::Engine error: Failed to load instrument, 
cause: 
/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/../../NDK/samples/kicks/kd14bop/snare_off/cls/kd14bop_cls_001.wav: 
Can't get sample info: System error : No such file or directory.

Re: [Linuxsampler-devel] default_path SFZ

[rosea.grammostola <ros...@gm...>]

If I've a sfz that works. Then copy it to a other name... it doesn't 
work anymore. Something strange going on here.

On 5/18/20 1:50 PM, rosea.grammostola wrote:
> Maybe I'm start getting blind, but I don't see why D-3 is working and 
> D-3-2 is not:
>
>
> -rw-r--r-- 1 debian debian 2688 May 18 13:33 
> kd14_bop_snare_off_cls-D-3-2.sfz
> -rw-r--r-- 1 debian debian 2688 May 18 13:16 
> kd14_bop_snare_off_cls-D-3.sfz
>
>
>
>
> Scheduling 
> '/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D-3-2.sfz' 
> (Index=0) to be loaded in background (if not loaded yet).
> Loading sfz file 
> '/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D-3-2.sfz'...OK
> Loading sfz instrument 
> ('/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D-3-2.sfz',0)...OK
> Caching initial samples...OK
> Scheduling 
> '/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D-3.sfz' 
> (Index=0) to be loaded in background (if not loaded yet).
> Freeing sfz file from memory...OK
> Loading sfz instrument 
> ('/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D-3.sfz',0)...OK
> Caching initial samples...sfz::Engine error: Failed to load 
> instrument, cause: 
> /home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/../../NDK/samples/kicks/kd14bop/snare_off/cls/kd14bop_cls_001.wav: 
> Can't get sample info: System error : No such file or directory.

Re: [Linuxsampler-devel] default_path SFZ

[rosea.grammostola <ros...@gm...>]

If you edit a sfz file and load the edited file, LinuxSampler still acts 
on the previous version of the file it seems. Which is a quite 
frustrating workflow.

Same for the database update wait time. I've to restart Linuxsampler and 
Fantasia every time I update the database. :-\


On 5/18/20 2:40 PM, rosea.grammostola wrote:
> If I've a sfz that works. Then copy it to a other name... it doesn't 
> work anymore. Something strange going on here.
>
> On 5/18/20 1:50 PM, rosea.grammostola wrote:
>> Maybe I'm start getting blind, but I don't see why D-3 is working and 
>> D-3-2 is not:
>>
>>
>> -rw-r--r-- 1 debian debian 2688 May 18 13:33 
>> kd14_bop_snare_off_cls-D-3-2.sfz
>> -rw-r--r-- 1 debian debian 2688 May 18 13:16 
>> kd14_bop_snare_off_cls-D-3.sfz
>>
>>
>>
>>
>> Scheduling 
>> '/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D-3-2.sfz' 
>> (Index=0) to be loaded in background (if not loaded yet).
>> Loading sfz file 
>> '/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D-3-2.sfz'...OK
>> Loading sfz instrument 
>> ('/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D-3-2.sfz',0)...OK
>> Caching initial samples...OK
>> Scheduling 
>> '/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D-3.sfz' 
>> (Index=0) to be loaded in background (if not loaded yet).
>> Freeing sfz file from memory...OK
>> Loading sfz instrument 
>> ('/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D-3.sfz',0)...OK
>> Caching initial samples...sfz::Engine error: Failed to load 
>> instrument, cause: 
>> /home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/../../NDK/samples/kicks/kd14bop/snare_off/cls/kd14bop_cls_001.wav: 
>> Can't get sample info: System error : No such file or directory.

Re: [Linuxsampler-devel] default_path SFZ

[Christian S. <sch...@li...>]

On Dienstag, 19. Mai 2020 10:19:28 CEST rosea.grammostola wrote:
> If you edit a sfz file and load the edited file, LinuxSampler still acts
> on the previous version of the file it seems. Which is a quite
> frustrating workflow.

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.

> 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.

On Montag, 18. Mai 2020 12:11:28 CEST rosea.grammostola wrote:
> Hi,
> 
> I've two sfz files. Both with a default_path. In the first Linuxsampler
> is totally okay with the file. In the second it says:
> 
> 
> Scheduling
> '/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D.sf
> z' (Index=0) to be loaded in background (if not loaded yet).
> Loading sfz instrument
> ('/home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/kd14_bop_snare_off_cls-D.s
> fz',0)...OK Caching initial samples...sfz::Engine error: Failed to load
> instrument, cause:
> /home/debian/linuxaudio/SFZ/kicks_pljones_D/bop/~/linuxaudio/NDK/samples/kic
> ks/kd14bop/snare_off/cls/kd14bop_cls_001.wav: Can't get sample info: System
> error : No such file or directory.
> 
> 
> It seems to search for a relative path, even if default_path is set.

If there's really a problem in detecting relative vs absolute path here, then 
it should be easy to fix. The relevant code that handles this is exclusively 
in src/engines/sfz/sfz.cpp and there are just 2 small code sections which 
handle this:

1. [line 1414]

        else if (token == "<control>")
        {
            _current_section = CONTROL;
            default_path = "";
            octave_offset = 0;
            note_offset = 0;
        }


2. [line 1480]

        // sample definition
        if ("sample" == key)
        {
            // handle built-in sample types ...
            if (value == "*silence") {
                pCurDef->sample = value;
                return;
            } else if (value.length() >= 1 && value[0] == '*') {
                std::cerr << "Unknown or unsupported built-in sample type '" 
<< value << "'!" << std::endl;
                return;
            }

            // handle external samples ...
            std::string path = default_path + value;
            #ifndef WIN32
            for (int i = 0; i < path.length(); i++) if (path[i] == '\\') 
path[i] = '/';
            bool absolute = path[0] == '/';
            #else
            bool absolute = path[0] == '/' || path[0] == '\\' ||
                (path.length() >= 2 && isalpha(path[0]) && path[1] == ':');
            #endif
            if (!absolute) path = currentDir + 
LinuxSampler::File::DirSeparator + path;
            if(pCurDef) pCurDef->sample = path;
            return;
        }

        // control header directives
        else if ("default_path" == key)
        {
            switch (_current_section)
            {
            case CONTROL:
                default_path = value;
                break;
            default:
                ; // noop
            }
            return;
        }

So you can easily add debug messages to find out what's going on.

CU
Christian

Re: [Linuxsampler-devel] default_path SFZ

[rosea.grammostola <ros...@gm...>]

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

Re: [Linuxsampler-devel] default_path SFZ

[Christian S. <sch...@li...>]

On Dienstag, 19. Mai 2020 21:09:51 CEST rosea.grammostola wrote:
> 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.

Sure! SFZ is a very simple text based format. Hurdles are not high to start 
some new player based on it. The actual challenge is to bring a new player to 
a certain point and then still keeping development activity high.

> 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).

libgig, libakai, libsf2, liblscp, QSampler, Gigedit, Fantasia are all pure GPL 
or even LGPL. People could contribute directly to those, they could have used 
them for other projects, forked them and lead them into other directions 
according to their own ideas. But: no activity difference to LS at all.

Likewise if you look at other Linux audio projects beyond a certain maturity 
level: almost no activity anymore nowadays. Most of the time it's like this: 
somebody starts a new project, there's activity for some time, and then after 
a certain point it stops. Many great LAD projects suffered this death (e.g. 
Rezound).

> 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?

I think you are underestimating how many SFZ based products are already out 
there. Most virtual instrument startups today use some kind of SFZ based 
player nowadays. They just acquire a permanent license for one of those many 
SFZ players out there for a cheap fee, optimize their sounds for that 
particular player and that's it.

But yes, most other ones are either transfering 10k+x to NI (as most 
professionals on Mac/PC only want Kontakt libs), and yet some other very few 
actors develop their own proprietary player.

> > 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!

You're welcome!

> 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.

Yep, the main issue with SFZ always was that there was never some standard. 
For a long time it was even hard to find infos for individual opcodes.

But even if there was a successful standardization effort for opcodes: it's 
not that this would lay ground for an application independent sound format; 
you still would have different filters, different EQs, different EGs, and many 
other tiny differences in behaviour that will simply cause your library sound 
different with each player used.

CU
Christian

Re: [Linuxsampler-devel] default_path SFZ

[rosea.grammostola <ros...@gm...>]

On 5/19/20 11:56 PM, Christian Schoenebeck wrote:
> Sure! SFZ is a very simple text based format. Hurdles are not high to start
> some new player based on it. The actual challenge is to bring a new player to
> a certain point and then still keeping development activity high.
Sure.
>
>> 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).
> libgig, libakai, libsf2, liblscp, QSampler, Gigedit, Fantasia are all pure GPL
> or even LGPL. People could contribute directly to those, they could have used
> them for other projects, forked them and lead them into other directions
> according to their own ideas. But: no activity difference to LS at all.

It's not that pure GPL is a guarantee for contributions, but people do 
mention the license of Linuxsampler now and then when discussing SFZ 
developments as a reason to look further. It's definitely a issue for some.

The developer of Sfizz did mention the license of Linuxsampler too, but 
he also wanted to start from scratch because he didn't feel ready yet to 
contribute to a larger project like Linuxsampler. Maybe in future, who 
knows. But that would be more likely if Linuxsampler would be full GPL I 
think.


>
> Likewise if you look at other Linux audio projects beyond a certain maturity
> level: almost no activity anymore nowadays. Most of the time it's like this:
> somebody starts a new project, there's activity for some time, and then after
> a certain point it stops. Many great LAD projects suffered this death (e.g.
> Rezound).

Latest commit 6 days ago ;)

https://github.com/ddurham2/rezound

At least the LAU mailinglist is far more quiet then years ago, (not sure 
what I should conclude from this yet). On the other hand, projects like 
Ardour, Muse, Non-session-manager, Zynaddsubfx, Radium, Qtractor etc. 
are still pretty active in development these days.

Re: [Linuxsampler-devel] default_path SFZ

[Christian S. <sch...@li...>]

On Samstag, 23. Mai 2020 17:17:34 CEST rosea.grammostola wrote:
> On 5/19/20 11:56 PM, Christian Schoenebeck wrote:
> > Sure! SFZ is a very simple text based format. Hurdles are not high to
> > start
> > some new player based on it. The actual challenge is to bring a new player
> > to a certain point and then still keeping development activity high.
> 
> Sure.
> 
> >> 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).
> > 
> > libgig, libakai, libsf2, liblscp, QSampler, Gigedit, Fantasia are all pure
> > GPL or even LGPL. People could contribute directly to those, they could
> > have used them for other projects, forked them and lead them into other
> > directions according to their own ideas. But: no activity difference to
> > LS at all.
> It's not that pure GPL is a guarantee for contributions, but people do
> mention the license of Linuxsampler now and then when discussing SFZ
> developments as a reason to look further. It's definitely a issue for some.
> 
> The developer of Sfizz did mention the license of Linuxsampler too, but
> he also wanted to start from scratch because he didn't feel ready yet to
> contribute to a larger project like Linuxsampler. Maybe in future, who
> knows. But that would be more likely if Linuxsampler would be full GPL I
> think.

I have not seen anybody starting a project, and then heading to another 
similar one.

I've been thinking about license relaxing myself as well, but more because of 
user aspects, i.e. convenient precompiled availability of LS in users' 
distribution of their choice, and there maybe preconfigured/customized for 
certain use case aspects. Like I said, from contribution point of view though, 
I don't think it would make any significant difference.

> > Likewise if you look at other Linux audio projects beyond a certain
> > maturity level: almost no activity anymore nowadays. Most of the time
> > it's like this: somebody starts a new project, there's activity for some
> > time, and then after a certain point it stops. Many great LAD projects
> > suffered this death (e.g. Rezound).
> 
> Latest commit 6 days ago ;)
> 
> https://github.com/ddurham2/rezound

Wow, a sign of life after years! :)

> At least the LAU mailinglist is far more quiet then years ago, (not sure
> what I should conclude from this yet). On the other hand, projects like
> Ardour, Muse, Non-session-manager, Zynaddsubfx, Radium, Qtractor etc.
> are still pretty active in development these days.

Who knows, fact is that communication ways and habits also shifted with the 
years. Many people no longer want to use mailing lists. It's like when I 
started coding, communication was typically on dedicated newsgroup networks, 
which we also thought of just being a relict of old times. Same situation with 
MLs today.

Just wait couple more years and you'll see a real game changer with AI 
thriving as dominant servant in engineering, and a significant change how 
exactly (and how little) humans will still be part of that engineering 
process. [ dramatic music playing ]

CU
Christian

Re: [Linuxsampler-devel] default_path SFZ

[rosea.grammostola <ros...@gm...>]

On 5/27/20 2:40 PM, Christian Schoenebeck wrote:

> I've been thinking about license relaxing myself as well, but more because of
> user aspects, i.e. convenient precompiled availability of LS in users'
> distribution of their choice, and there maybe preconfigured/customized for
> certain use case aspects. Like I said, from contribution point of view though,
> I don't think it would make any significant difference.
>
>
That step would be very significant for Linuxaudio users. Will be quite 
a thing. Would be pretty cool if you would do so. Along with SFZ it can 
become a popular tool to grab for when making music I think.

Contributions to other projects in the open source community sounds in 
theory better then it is in reality probably. Having said that, it 
wouldn't surprise me at all if contributions to linuxsampler will rise, 
especially on the SFZ and LV2 side of it.

Regars,

\r