linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

Re: [Linuxsampler-devel] Giga vs SFZ: CONFIG_EG_MIN_RELEASE_TIME too big for current audio fragment size & sampling rate!

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

On 03/10/2012 09:20 PM, Andreas Persson wrote:
> On 2012-03-10 21:12, rosea.grammostola wrote:
>> On 03/10/2012 08:59 PM, Andreas Persson wrote:
>>> gdb linuxsampler
>>
>> $ gdb linuxsampler core
>> GNU gdb (GDB) 7.4-debian
>> Copyright (C) 2012 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from /usr/bin/linuxsampler...done.
>> [New LWP 9175]
>> [New LWP 9512]
>> [New LWP 9509]
>> [New LWP 9174]
>>
>> warning: Can't read pathname for load map: Input/output error.
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> Core was generated by `linuxsampler'.
>> Program terminated with signal 11, Segmentation fault.
>> #0  0x00007f8afb13b088 in LinuxSampler::EG::CalculateFadeOutCoeff(float,
>> float) ()
>>       from /usr/lib/linuxsampler/liblinuxsampler.so.3
>>
>
> Did you forget the "bt" command? That's what gives you the stack trace.
>
> Anyway, it looks like you're not running the latest code (I committed
> the fix today, three hours ago).

I updated after your mail, svn up, dpkg-buildpackage


Is this better?

For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/linuxsampler...done.
[New LWP 10072]
[New LWP 10078]
[New LWP 10071]
[New LWP 10075]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `linuxsampler'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f1c4296a088 in LinuxSampler::EG::CalculateFadeOutCoeff(float, 
float) ()
    from /usr/lib/linuxsampler/liblinuxsampler.so.3
(gdb) bt
#0  0x00007f1c4296a088 in LinuxSampler::EG::CalculateFadeOutCoeff(float, 
float) ()
    from /usr/lib/linuxsampler/liblinuxsampler.so.3
#1  0x00007f1c4294de61 in 
LinuxSampler::EngineBase<LinuxSampler::sfz::Voice, sfz::Region, 
sfz::Region, LinuxSampler::sfz::DiskThread, 
LinuxSampler::sfz::InstrumentResourceManager, 
sfz::Instrument>::Connect(LinuxSampler::AudioOutputDevice*) ()
    from /usr/lib/linuxsampler/liblinuxsampler.so.3
#2  0x00007f1c4296c7d2 in 
LinuxSampler::AbstractEngine::AcquireEngine(LinuxSampler::AbstractEngineChannel*, 
LinuxSampler::AudioOutputDevice*) ()
    from /usr/lib/linuxsampler/liblinuxsampler.so.3
#3  0x00007f1c4294a0e2 in 
LinuxSampler::EngineChannelBase<LinuxSampler::sfz::Voice, sfz::Region, 
sfz::Instrument>::Connect(LinuxSampler::AudioOutputDevice*) ()
    from /usr/lib/linuxsampler/liblinuxsampler.so.3
#4  0x00007f1c4288b0e9 in 
LinuxSampler::SamplerChannel::SetAudioOutputDevice(LinuxSampler::AudioOutputDevice*) 
() from /usr/lib/linuxsampler/liblinuxsampler.so.3
#5  0x00007f1c428d79dd in 
LinuxSampler::LSCPServer::SetAudioOutputDevice(unsigned int, unsigned 
int) () from /usr/lib/linuxsampler/liblinuxsampler.so.3
#6  0x00007f1c428b00e1 in yyparse(void*) ()
    from /usr/lib/linuxsampler/liblinuxsampler.so.3
#7  0x00007f1c428d5e31 in LinuxSampler::LSCPServer::Main() ()
    from /usr/lib/linuxsampler/liblinuxsampler.so.3
#8  0x00007f1c429cc884 in LinuxSampler::__pthread_launcher(void*) ()
    from /usr/lib/linuxsampler/liblinuxsampler.so.3
#9  0x00007f1c41c00b50 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#10 0x00007f1c4194b90d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#11 0x0000000000000000 in ?? ()


>
> /Andreas
>
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] Giga vs SFZ: CONFIG_EG_MIN_RELEASE_TIME too big for current audio fragment size & sampling rate!

[Andreas P. <and...@br...>]

On 2012-03-10 21:12, rosea.grammostola wrote:
> On 03/10/2012 08:59 PM, Andreas Persson wrote:
>> gdb linuxsampler
>
> $ gdb linuxsampler core
> GNU gdb (GDB) 7.4-debian
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/bin/linuxsampler...done.
> [New LWP 9175]
> [New LWP 9512]
> [New LWP 9509]
> [New LWP 9174]
>
> warning: Can't read pathname for load map: Input/output error.
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `linuxsampler'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x00007f8afb13b088 in LinuxSampler::EG::CalculateFadeOutCoeff(float,
> float) ()
>      from /usr/lib/linuxsampler/liblinuxsampler.so.3
>

Did you forget the "bt" command? That's what gives you the stack trace.

Anyway, it looks like you're not running the latest code (I committed 
the fix today, three hours ago).

/Andreas

Re: [Linuxsampler-devel] Giga vs SFZ: CONFIG_EG_MIN_RELEASE_TIME too big for current audio fragment size & sampling rate!

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

On 03/10/2012 08:59 PM, Andreas Persson wrote:
> gdb linuxsampler

$ gdb linuxsampler core
GNU gdb (GDB) 7.4-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/linuxsampler...done.
[New LWP 9175]
[New LWP 9512]
[New LWP 9509]
[New LWP 9174]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `linuxsampler'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f8afb13b088 in LinuxSampler::EG::CalculateFadeOutCoeff(float, 
float) ()
    from /usr/lib/linuxsampler/liblinuxsampler.so.3

Re: [Linuxsampler-devel] Giga vs SFZ: CONFIG_EG_MIN_RELEASE_TIME too big for current audio fragment size & sampling rate!

[Andreas P. <and...@br...>]

On 2012-03-10 20:48, rosea.grammostola wrote:
>> That's weird. Can you send me a stack trace?
>
> How do I make one?

ulimit -c unlimited

linuxsampler

... trigger the crash, you'll then get a core-file

gdb linuxsampler <name of the core file>

bt


/Andreas

Re: [Linuxsampler-devel] Giga vs SFZ: CONFIG_EG_MIN_RELEASE_TIME too big for current audio fragment size & sampling rate!

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

On 03/10/2012 08:38 PM, Andreas Persson wrote:
> On 2012-03-10 18:28, rosea.grammostola wrote:
>> On 03/10/2012 05:31 PM, rosea.grammostola wrote:
>>> On 03/10/2012 05:27 PM, Andreas Persson wrote:
>>>> On 2012-03-02 13:23, rosea.grammostola wrote:
>>>>> With Giga files I can have my Jack settings on Frames/Period 64 and
>>>>> Sample Rate 48000 easily.
>>>>> With SFZ on the otherhand I need to set Frames/Period to 128 otherwise I
>>>>> get the message below with a segmentation fault. :(
>>>>
>>>> I think I've fixed this now.
>>>>
>>> Wow, would be nice. You're doing a great job! Highly appreciated!
>>>
>>> \r
>>
>> Still the same behavior
>>
>>
>> LinuxSampler initialization completed. :-)
>>
>> LSCPServer: Client connection established on socket:7.
>> LSCPServer: Client connection established on socket:8.
>> ALSA lib pcm_hw.c:1401:(_snd_pcm_hw_open) Invalid value for card
>> ALSA lib pcm_hw.c:1401:(_snd_pcm_hw_open) Invalid value for card
>> EngineBase: WARNING, CONFIG_EG_MIN_RELEASE_TIME too big for current
>> audio fragment size&   sampling rate! May lead to click sounds if voice
>> stealing chimes in!
>> Starting disk thread...OK
>> EQ support: no
>> Stopping disk thread...OK
>> EngineBase: WARNING, CONFIG_EG_MIN_RELEASE_TIME too big for current
>> audio fragment size&   sampling rate! May lead to click sounds if voice
>> stealing chimes in!
>> Segmentation fault
>
> That's weird. Can you send me a stack trace?

How do I make one?

Re: [Linuxsampler-devel] Giga vs SFZ: CONFIG_EG_MIN_RELEASE_TIME too big for current audio fragment size & sampling rate!

[Andreas P. <and...@br...>]

On 2012-03-10 18:28, rosea.grammostola wrote:
> On 03/10/2012 05:31 PM, rosea.grammostola wrote:
>> On 03/10/2012 05:27 PM, Andreas Persson wrote:
>>> On 2012-03-02 13:23, rosea.grammostola wrote:
>>>> With Giga files I can have my Jack settings on Frames/Period 64 and
>>>> Sample Rate 48000 easily.
>>>> With SFZ on the otherhand I need to set Frames/Period to 128 otherwise I
>>>> get the message below with a segmentation fault. :(
>>>
>>> I think I've fixed this now.
>>>
>> Wow, would be nice. You're doing a great job! Highly appreciated!
>>
>> \r
>
> Still the same behavior
>
>
> LinuxSampler initialization completed. :-)
>
> LSCPServer: Client connection established on socket:7.
> LSCPServer: Client connection established on socket:8.
> ALSA lib pcm_hw.c:1401:(_snd_pcm_hw_open) Invalid value for card
> ALSA lib pcm_hw.c:1401:(_snd_pcm_hw_open) Invalid value for card
> EngineBase: WARNING, CONFIG_EG_MIN_RELEASE_TIME too big for current
> audio fragment size&  sampling rate! May lead to click sounds if voice
> stealing chimes in!
> Starting disk thread...OK
> EQ support: no
> Stopping disk thread...OK
> EngineBase: WARNING, CONFIG_EG_MIN_RELEASE_TIME too big for current
> audio fragment size&  sampling rate! May lead to click sounds if voice
> stealing chimes in!
> Segmentation fault

That's weird. Can you send me a stack trace?

/Andreas

Re: [Linuxsampler-devel] Ardour3 + linuxsampler plugin

[Andreas P. <and...@br...>]

On 2012-03-10 19:23, David Robillard wrote:
> On Thu, 2012-03-08 at 20:50 +0100, Andreas Persson wrote:
>> On 2012-03-06 08:18, Andreas Persson wrote:
>>> On 2012-03-06 06:51, David Robillard wrote:
>>>> On Sun, 2012-03-04 at 14:04 -0500, Edward Diehl wrote:
>>>>> State restore works for gig, SF2 but not SFZ, which I think is a known
>>>>> problem.
>>>>
>>>> Yes, this is because SFZ contains paths which need to be mapped.
>>>> Unfortunately this means LinuxSampler is going to have to rewrite the
>>>> SFZ file on save, but this is the only way to get properly
>>>> archivable/portable sessions.
>>>
>>> It's also because there's a bug in LinuxSampler causing crashes as
>>> pEngine pointer sometimes is null when the instrument loader thread
>>> loads sfz or sf2 files. You fixed this for gig files with a simple
>>> patch, but I'm working on a more thread safe fix for all engines.
>>
>> Done. I've just committed it.
>
> Could this by any chance have fixed deadlocks on exit when running as a
> plugin?  That seems to have gone away.

I did fix a deadlock, in the commit from 2012-03-04, but I got the 
deadlock when the plugin was loaded a second time, not on exit.

/Andreas

Re: [Linuxsampler-devel] Ardour3 + linuxsampler plugin

[David R. <d...@dr...>]

On Sat, 2012-03-10 at 18:40 +0100, Christian Schoenebeck wrote:
> On Saturday 10 March 2012 19:24:33 you wrote:
> > On Fri, 2012-03-09 at 21:05 +0100, Christian Schoenebeck wrote:
> > > On Friday 09 March 2012 21:02:00 David Robillard wrote:
> > > > > > gig::Engine error: Failed to load instrument, cause: Can't open
> > > > > > "/mdkhome/sound/recording/ardour3/PianoLive/plugins/126/state6/Blac
> > > > > > k Grand Medium Ambient.gx01"
> > > > > > 
> > > > > > This file is some other file connected with the Black Grand.
> > > > > 
> > > > > Sigh.  I was under the impression that .gig files were always
> > > > > self-contained.  I do not have any files like this.
> > > > 
> > > > Maybe a dev more familiar with LS can help me with this.  Does the
> > > > engine know about these files?  How can I get a list of them?
> > > 
> > > Those are so called "extension files" of the Giga format. Those were
> > > introduced by Tascam to circumvent the 2GB file size limit of the RIFF
> > > format, on which the Giga format is based on.
> > > 
> > > See method:
> > > 
> > > void File::LoadSamples(progress_t* pProgress);
> > > 
> > > in src/gig.cpp of the libgig sources.
> > 
> > Thanks.  I'll wade around and figure out how to get at this information
> > from LS.
> 
> You mean how to retrieve in the LV2 plugin code whether a .gig file "wants" 
> extensions files and the list of those extension files? Or what else do you need 
> exactly?

Yes, essentially I need to enumerate *all* files that are used.

> > (That 32-bit limit really sucks...)
> 
> Not thaaat bad. ;-) The workaround with extension files is a bit ugly, but it 
> works on all systems. And I'm sure it will be easily resolved for LV2 as well.

Well, it's pretty annoying/ugly here (these *%*^&% non-self-contained
sample banks will be the death of me), but I mean in general.  I've
looked in to using RIFF for things before realizing the 32-bit limit
ruins that idea... oh well.

-dr

Re: [Linuxsampler-devel] Ardour3 + linuxsampler plugin

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

On Saturday 10 March 2012 19:24:33 you wrote:
> On Fri, 2012-03-09 at 21:05 +0100, Christian Schoenebeck wrote:
> > On Friday 09 March 2012 21:02:00 David Robillard wrote:
> > > > > gig::Engine error: Failed to load instrument, cause: Can't open
> > > > > "/mdkhome/sound/recording/ardour3/PianoLive/plugins/126/state6/Blac
> > > > > k Grand Medium Ambient.gx01"
> > > > > 
> > > > > This file is some other file connected with the Black Grand.
> > > > 
> > > > Sigh.  I was under the impression that .gig files were always
> > > > self-contained.  I do not have any files like this.
> > > 
> > > Maybe a dev more familiar with LS can help me with this.  Does the
> > > engine know about these files?  How can I get a list of them?
> > 
> > Those are so called "extension files" of the Giga format. Those were
> > introduced by Tascam to circumvent the 2GB file size limit of the RIFF
> > format, on which the Giga format is based on.
> > 
> > See method:
> > 
> > void File::LoadSamples(progress_t* pProgress);
> > 
> > in src/gig.cpp of the libgig sources.
> 
> Thanks.  I'll wade around and figure out how to get at this information
> from LS.

You mean how to retrieve in the LV2 plugin code whether a .gig file "wants" 
extensions files and the list of those extension files? Or what else do you need 
exactly?

> (That 32-bit limit really sucks...)

Not thaaat bad. ;-) The workaround with extension files is a bit ugly, but it 
works on all systems. And I'm sure it will be easily resolved for LV2 as well.

CU
Christian

Re: [Linuxsampler-devel] Ardour3 + linuxsampler plugin

[David R. <d...@dr...>]

On Fri, 2012-03-09 at 21:05 +0100, Christian Schoenebeck wrote:
> On Friday 09 March 2012 21:02:00 David Robillard wrote:
> > > > gig::Engine error: Failed to load instrument, cause: Can't open
> > > > "/mdkhome/sound/recording/ardour3/PianoLive/plugins/126/state6/Black
> > > > Grand Medium Ambient.gx01"
> > > > 
> > > > This file is some other file connected with the Black Grand.
> > > 
> > > Sigh.  I was under the impression that .gig files were always
> > > self-contained.  I do not have any files like this.
> > 
> > Maybe a dev more familiar with LS can help me with this.  Does the
> > engine know about these files?  How can I get a list of them?
> 
> Those are so called "extension files" of the Giga format. Those were introduced 
> by Tascam to circumvent the 2GB file size limit of the RIFF format, on which 
> the Giga format is based on.
> 
> See method:
> 
> void File::LoadSamples(progress_t* pProgress);
> 
> in src/gig.cpp of the libgig sources.

Thanks.  I'll wade around and figure out how to get at this information
from LS.

(That 32-bit limit really sucks...)

-dr

Re: [Linuxsampler-devel] Ardour3 + linuxsampler plugin

[David R. <d...@dr...>]

On Thu, 2012-03-08 at 20:50 +0100, Andreas Persson wrote:
> On 2012-03-06 08:18, Andreas Persson wrote:
> > On 2012-03-06 06:51, David Robillard wrote:
> >> On Sun, 2012-03-04 at 14:04 -0500, Edward Diehl wrote:
> >>> State restore works for gig, SF2 but not SFZ, which I think is a known
> >>> problem.
> >>
> >> Yes, this is because SFZ contains paths which need to be mapped.
> >> Unfortunately this means LinuxSampler is going to have to rewrite the
> >> SFZ file on save, but this is the only way to get properly
> >> archivable/portable sessions.
> >
> > It's also because there's a bug in LinuxSampler causing crashes as
> > pEngine pointer sometimes is null when the instrument loader thread
> > loads sfz or sf2 files. You fixed this for gig files with a simple
> > patch, but I'm working on a more thread safe fix for all engines.
> 
> Done. I've just committed it.

Could this by any chance have fixed deadlocks on exit when running as a
plugin?  That seems to have gone away.

Either way, thanks

-dr

Re: [Linuxsampler-devel] Giga vs SFZ: CONFIG_EG_MIN_RELEASE_TIME too big for current audio fragment size & sampling rate!

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

On 03/10/2012 05:31 PM, rosea.grammostola wrote:
> On 03/10/2012 05:27 PM, Andreas Persson wrote:
>> On 2012-03-02 13:23, rosea.grammostola wrote:
>>> With Giga files I can have my Jack settings on Frames/Period 64 and
>>> Sample Rate 48000 easily.
>>> With SFZ on the otherhand I need to set Frames/Period to 128 otherwise I
>>> get the message below with a segmentation fault. :(
>>
>> I think I've fixed this now.
>>
> Wow, would be nice. You're doing a great job! Highly appreciated!
>
> \r

Still the same behavior


LinuxSampler initialization completed. :-)

LSCPServer: Client connection established on socket:7.
LSCPServer: Client connection established on socket:8.
ALSA lib pcm_hw.c:1401:(_snd_pcm_hw_open) Invalid value for card
ALSA lib pcm_hw.c:1401:(_snd_pcm_hw_open) Invalid value for card
EngineBase: WARNING, CONFIG_EG_MIN_RELEASE_TIME too big for current 
audio fragment size & sampling rate! May lead to click sounds if voice 
stealing chimes in!
Starting disk thread...OK
EQ support: no
Stopping disk thread...OK
EngineBase: WARNING, CONFIG_EG_MIN_RELEASE_TIME too big for current 
audio fragment size & sampling rate! May lead to click sounds if voice 
stealing chimes in!
Segmentation fault

Re: [Linuxsampler-devel] Giga vs SFZ: CONFIG_EG_MIN_RELEASE_TIME too big for current audio fragment size & sampling rate!

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

On 03/10/2012 05:27 PM, Andreas Persson wrote:
> On 2012-03-02 13:23, rosea.grammostola wrote:
>> With Giga files I can have my Jack settings on Frames/Period 64 and
>> Sample Rate 48000 easily.
>> With SFZ on the otherhand I need to set Frames/Period to 128 otherwise I
>> get the message below with a segmentation fault. :(
>
> I think I've fixed this now.
>
Wow, would be nice. You're doing a great job! Highly appreciated!

\r

Re: [Linuxsampler-devel] Giga vs SFZ: CONFIG_EG_MIN_RELEASE_TIME too big for current audio fragment size & sampling rate!

[Andreas P. <and...@br...>]

On 2012-03-02 13:23, rosea.grammostola wrote:
> With Giga files I can have my Jack settings on Frames/Period 64 and
> Sample Rate 48000 easily.
> With SFZ on the otherhand I need to set Frames/Period to 128 otherwise I
> get the message below with a segmentation fault. :(

I think I've fixed this now.

/Andreas

Re: [Linuxsampler-devel] Ardour3 + linuxsampler plugin

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

On Friday 09 March 2012 21:02:00 David Robillard wrote:
> > > gig::Engine error: Failed to load instrument, cause: Can't open
> > > "/mdkhome/sound/recording/ardour3/PianoLive/plugins/126/state6/Black
> > > Grand Medium Ambient.gx01"
> > > 
> > > This file is some other file connected with the Black Grand.
> > 
> > Sigh.  I was under the impression that .gig files were always
> > self-contained.  I do not have any files like this.
> 
> Maybe a dev more familiar with LS can help me with this.  Does the
> engine know about these files?  How can I get a list of them?

Those are so called "extension files" of the Giga format. Those were introduced 
by Tascam to circumvent the 2GB file size limit of the RIFF format, on which 
the Giga format is based on.

See method:

void File::LoadSamples(progress_t* pProgress);

in src/gig.cpp of the libgig sources.

CU
Christian

Re: [Linuxsampler-devel] Ardour3 + linuxsampler plugin

[David R. <d...@dr...>]

On Wed, 2012-03-07 at 15:18 -0500, David Robillard wrote:
> On Tue, 2012-03-06 at 22:12 -0500, Edward Diehl wrote:
> > Ok, fine, do the state restoration the right way.  Here are 2 other
> > things I notice:
> [...]
> > 2. Also, I discovered another case of linuxsampler non-state recovery:
> > large, multifile gig files.  I have the 6 GB SampleTekk Black Grand
> > which is split in multiple files.  It seems the state recovery can
> > only handle single file gig files, probably due to the same path
> > issues that currently prevent SFZ recovery.  I get this message when
> > trying to restore an Ardour3 session with a saved linuxsampler Black
> > Grand gig file loaded:
> [...]
> > Scheduling
> > '/mdkhome/sound/recording/ardour3/PianoLive/plugins/126/state6/Black
> > Grand Medium Ambient.gig' (Index=0) to be loaded in background (if not
> > loaded yet).
> [...]
> > gig::Engine error: Failed to load instrument, cause: Can't open
> > "/mdkhome/sound/recording/ardour3/PianoLive/plugins/126/state6/Black
> > Grand Medium Ambient.gx01" 
> > 
> > This file is some other file connected with the Black Grand.
> 
> Sigh.  I was under the impression that .gig files were always
> self-contained.  I do not have any files like this.

Maybe a dev more familiar with LS can help me with this.  Does the
engine know about these files?  How can I get a list of them?

-dr

Re: [Linuxsampler-devel] Ardour3 + linuxsampler plugin

[Andreas P. <and...@br...>]

On 2012-03-06 08:18, Andreas Persson wrote:
> On 2012-03-06 06:51, David Robillard wrote:
>> On Sun, 2012-03-04 at 14:04 -0500, Edward Diehl wrote:
>>> State restore works for gig, SF2 but not SFZ, which I think is a known
>>> problem.
>>
>> Yes, this is because SFZ contains paths which need to be mapped.
>> Unfortunately this means LinuxSampler is going to have to rewrite the
>> SFZ file on save, but this is the only way to get properly
>> archivable/portable sessions.
>
> It's also because there's a bug in LinuxSampler causing crashes as
> pEngine pointer sometimes is null when the instrument loader thread
> loads sfz or sf2 files. You fixed this for gig files with a simple
> patch, but I'm working on a more thread safe fix for all engines.

Done. I've just committed it.

/Andreas

Re: [Linuxsampler-devel] Ardour3 + linuxsampler plugin

[David R. <d...@dr...>]

On Tue, 2012-03-06 at 22:12 -0500, Edward Diehl wrote:
> Ok, fine, do the state restoration the right way.  Here are 2 other
> things I notice:
[...]
> 2. Also, I discovered another case of linuxsampler non-state recovery:
> large, multifile gig files.  I have the 6 GB SampleTekk Black Grand
> which is split in multiple files.  It seems the state recovery can
> only handle single file gig files, probably due to the same path
> issues that currently prevent SFZ recovery.  I get this message when
> trying to restore an Ardour3 session with a saved linuxsampler Black
> Grand gig file loaded:
[...]
> Scheduling
> '/mdkhome/sound/recording/ardour3/PianoLive/plugins/126/state6/Black
> Grand Medium Ambient.gig' (Index=0) to be loaded in background (if not
> loaded yet).
[...]
> gig::Engine error: Failed to load instrument, cause: Can't open
> "/mdkhome/sound/recording/ardour3/PianoLive/plugins/126/state6/Black
> Grand Medium Ambient.gx01" 
> 
> This file is some other file connected with the Black Grand.

Sigh.  I was under the impression that .gig files were always
self-contained.  I do not have any files like this.

-dr

Re: [Linuxsampler-devel] Ardour3 + linuxsampler plugin

[Edward D. <di...@um...>]

Ok, fine, do the state restoration the right way.  Here are 2 other
things I notice:

1. Concerning lilv I get 6 of this message when starting ardour3: 

lilv_plugin_load_ports_if_necessary(): error: Plugin
<file:///usr/lib/lv2/ingen.lv2/stereo_effect.ttl> is missing port 4/6

It does not cause any obvious ill effect.

2. Also, I discovered another case of linuxsampler non-state recovery:
large, multifile gig files.  I have the 6 GB SampleTekk Black Grand
which is split in multiple files.  It seems the state recovery can
only handle single file gig files, probably due to the same path
issues that currently prevent SFZ recovery.  I get this message when
trying to restore an Ardour3 session with a saved linuxsampler Black
Grand gig file loaded:

Loading LV2 state from
/mdkhome/sound/recording/ardour3/PianoLive/plugins/126/state6/state.ttl
Stopping disk thread...OK
Starting disk thread...OK
EQ support: no
Scheduling
'/mdkhome/sound/recording/ardour3/PianoLive/plugins/126/state6/Black
Grand Medium Ambient.gig' (Index=0) to be loaded in background (if not
loaded yet).

[...so far so good ... but later on ...]

gig::Engine error: Failed to load instrument, cause: Can't open
"/mdkhome/sound/recording/ardour3/PianoLive/plugins/126/state6/Black
Grand Medium Ambient.gx01" 

This file is some other file connected with the Black Grand.

Re: [Linuxsampler-devel] Ardour3 + linuxsampler plugin

[David R. <d...@dr...>]

On Tue, 2012-03-06 at 14:59 -0500, Edward Diehl wrote:
> > Yes, this is because SFZ contains paths which need to be mapped.
> > Unfortunately this means LinuxSampler is going to have to rewrite the
> > SFZ file on save, but this is the only way to get properly
> > archivable/portable sessions.
>  
> Its nice to SFZ save to a portable session, but from my point of view the
> 1st order problem is to save at all, and adding portability can be a future
> improvement.   Anyway, thanks again for the nice work.

Unfortunately that pragmatic-from-the-user-perspective view is not a
very good idea in the grand scheme of things.  I deliberately do not
plan to complicate the state API or change Ardour's implementation to
accommodate this, because it's broken behaviour nobody actually wants
anyway.  Not working at all makes it so there is an incentive to do it
correctly ;)

On a sociological level, "oh, well, you can maybe map your paths if you
feel like it" means, in practice, that we just don't have portable
sessions at all.  The spec says plugins MUST map ALL paths because this
is required for things to work.  The plugin *can* disobey and not tell
the host about paths at all, but since the plugin is violating the spec
in that situation any and all breakage is the plugin's fault by
definition.

The overriding argument here is the fact that not only will it not work,
it will *silently* break, and it is impossible for the host to give the
user the ability to resolve the problem, or even report that a problem
has occurred (other than the plugin not working).  I think it's
reasonable to say that situation is unacceptable.

As for working, it will work when it is done.  Please keep in mind this
functionality is still unreleased and experimental at this time.

-dr

Re: [Linuxsampler-devel] Ardour3 + linuxsampler plugin

[David R. <d...@dr...>]

On Tue, 2012-03-06 at 08:18 +0100, Andreas Persson wrote:
> On 2012-03-06 06:51, David Robillard wrote:
> > On Sun, 2012-03-04 at 14:04 -0500, Edward Diehl wrote:
> >> State restore works for gig, SF2 but not SFZ, which I think is a known
> >> problem.
> >
> > Yes, this is because SFZ contains paths which need to be mapped.
> > Unfortunately this means LinuxSampler is going to have to rewrite the
> > SFZ file on save, but this is the only way to get properly
> > archivable/portable sessions.
> 
> It's also because there's a bug in LinuxSampler causing crashes as 
> pEngine pointer sometimes is null when the instrument loader thread 
> loads sfz or sf2 files. You fixed this for gig files with a simple 
> patch, but I'm working on a more thread safe fix for all engines.

Yeah, I never really did have a deep understanding of that one.

> I don't know how much it matters, but note that a normal sfz file (one 
> you might download from Internet) uses relative paths to the samples. 
> The paths are relative to the location of the sfz file. (The fact that 
> we support absolute paths is in my opinion something that we can ignore 
> when saving the state - if the user has chosen to use absolute paths, he 
> has also chosen to create a non-portable session.)

This could be an option (though technically the rule is the plugin must
map all paths).  It could be problematic if several sfz files share a
directory and large set of samples and one particular sfz only uses a
subset.  I don't know if this is common.

If a really painfully simple assumption like "the directory the .sfz is
in, in its entirety, is the sfz and should be saved" actually works in
99% of cases, it's probably good enough.  Otherwise you'd at least have
to scan the sfz, and it seems a small step from scanning to rewriting it
with modified paths.

-dr

Re: [Linuxsampler-devel] Ardour3 + linuxsampler plugin

[Edward D. <di...@um...>]

> Yes, this is because SFZ contains paths which need to be mapped.
> Unfortunately this means LinuxSampler is going to have to rewrite the
> SFZ file on save, but this is the only way to get properly
> archivable/portable sessions.
 
Its nice to SFZ save to a portable session, but from my point of view the
1st order problem is to save at all, and adding portability can be a future
improvement.   Anyway, thanks again for the nice work.
 

Re: [Linuxsampler-devel] Ardour3 + linuxsampler plugin

[Andreas P. <and...@br...>]

On 2012-03-06 06:51, David Robillard wrote:
> On Sun, 2012-03-04 at 14:04 -0500, Edward Diehl wrote:
>> State restore works for gig, SF2 but not SFZ, which I think is a known
>> problem.
>
> Yes, this is because SFZ contains paths which need to be mapped.
> Unfortunately this means LinuxSampler is going to have to rewrite the
> SFZ file on save, but this is the only way to get properly
> archivable/portable sessions.

It's also because there's a bug in LinuxSampler causing crashes as 
pEngine pointer sometimes is null when the instrument loader thread 
loads sfz or sf2 files. You fixed this for gig files with a simple 
patch, but I'm working on a more thread safe fix for all engines.

I don't know how much it matters, but note that a normal sfz file (one 
you might download from Internet) uses relative paths to the samples. 
The paths are relative to the location of the sfz file. (The fact that 
we support absolute paths is in my opinion something that we can ignore 
when saving the state - if the user has chosen to use absolute paths, he 
has also chosen to create a non-portable session.)

/Andreas

Re: [Linuxsampler-devel] Ardour3 + linuxsampler plugin

[David R. <d...@dr...>]

On Sun, 2012-03-04 at 14:04 -0500, Edward Diehl wrote:
> I have gotten the LV2 state restoration working in Ardour3.  I was
> missing a configuration option on lv2-svn.  This must be built with
> the --experimental option to get lilv state support.  So I did:
> o build lv2-svn latest SVN with  --experimental configure flag
> o build drobilla.net with latest SVN
> o build ardour3 with latest SVN
> State restore works for gig, SF2 but not SFZ, which I think is a known
> problem.

Yes, this is because SFZ contains paths which need to be mapped.
Unfortunately this means LinuxSampler is going to have to rewrite the
SFZ file on save, but this is the only way to get properly
archivable/portable sessions.

> Qtractor, however, can restore gig, SF2, and SFZ

This is because Qtractor just doesn't implement path mapping, which
means you can't archive sessions and if you move things it will break
(mysteriously, and it is impossible for the host to allow the user to
deal with this in a friendly way since it doesn't even know about it)

> Thanks for the help.

You're welcome.

-dr

P.S. Please don't top-post http://idallen.com/topposting.html

Re: [Linuxsampler-devel] Ardour3 + linuxsampler plugin

[Edward D. <di...@um...>]

I have gotten the LV2 state restoration working in Ardour3.  I was
missing a configuration option on lv2-svn.  This must be built with
the --experimental option to get lilv state support.  So I did:
o build lv2-svn latest SVN with  --experimental configure flag
o build drobilla.net with latest SVN
o build ardour3 with latest SVN
State restore works for gig, SF2 but not SFZ, which I think is a known
problem.
Qtractor, however, can restore gig, SF2, and SFZ

Thanks for the help.

On Sat, 03 Mar 2012 17:39:36 -0500, David Robillard <d...@dr...> wrote:
> On Wed, 2012-02-29 at 20:15 -0500, Edward Diehl wrote:
>> I still do not get the linuxsampler state restoration in ardour3.  Here
>> is what I did:
>> 
>> o applied patch to linuxsampler; recompiled & installed
>> o built Ardour3 SVN 11569
>> o built lv2-svn SVN 572
>> o drobilla-lad SVN 4005
> 
> I just tried it with the latest version of everything and the mentioned
> patch and it works fine *on a new session*.
> 
> It will not load old ones, the format changed.
> 
> -dr