Menu
▾
▴
linuxsampler-devel
|
From: Edward D. <di...@um...> - 2012-02-26 16:42:17
|
I rebuilt linuxsampler (libgig, qsampler) all with SVN 2322, but still the state is not restored. My state.ttl file says: <> a pset:Preset ; lv2:appliesTo <http://linuxsampler.org/plugins/linuxsampler> . manifest.ttl has this: <state.ttl> a pset:Preset ; rdfs:seeAlso <state.ttl> ; lv2:appliesTo <http://linuxsampler.org/plugins/linuxsampler> . I do not see any mention of the gig file I had previously loaded. Also, tried the linuxsampler plugin in Qtractor, but this somehow causes an immediate segfault. I've been having this problem since Qtractor 5.3. I'll report the details to the Qtractor forum. |
|
From: David R. <d...@dr...> - 2012-02-29 22:10:07
Attachments:
linuxsampler_lv2_path_type.diff
|
On Sun, 2012-02-26 at 11:42 -0500, Edward Diehl wrote: > I rebuilt linuxsampler (libgig, qsampler) all with SVN 2322, but still the > state is not restored. My state.ttl file says: > > <> > a pset:Preset ; > lv2:appliesTo <http://linuxsampler.org/plugins/linuxsampler> . > > manifest.ttl has this: > > <state.ttl> > a pset:Preset ; > rdfs:seeAlso <state.ttl> ; > lv2:appliesTo <http://linuxsampler.org/plugins/linuxsampler> . > > I do not see any mention of the gig file I had previously loaded. > > Also, tried the linuxsampler plugin in Qtractor, but this somehow causes an > immediate segfault. I've been having this problem since Qtractor 5.3. > I'll report the details to the Qtractor forum. Sorry, I broke something. Patch attached. This should match latest SVN of LV2 stuff and Ardour. I havn't tested it and don't know the state of QTractor at the moment. -dr |
|
From: Edward D. <di...@um...> - 2012-02-29 22:50:00
|
Thanks for the patch which I'll try tonight. I reported the linuxsampler crash to Rui Nuno Capela's Qtractor forum and Rui was able to fix the problem, after which the linuxsampler state restoration worked perfectly for gig, sfz, and sf2 files. On Wed, 29 Feb 2012 17:09:57 -0500, David Robillard <d...@dr...> wrote: > On Sun, 2012-02-26 at 11:42 -0500, Edward Diehl wrote: >> I rebuilt linuxsampler (libgig, qsampler) all with SVN 2322, but still >> the >> state is not restored. My state.ttl file says: >> >> <> >> a pset:Preset ; >> lv2:appliesTo <http://linuxsampler.org/plugins/linuxsampler> . >> >> manifest.ttl has this: >> >> <state.ttl> >> a pset:Preset ; >> rdfs:seeAlso <state.ttl> ; >> lv2:appliesTo <http://linuxsampler.org/plugins/linuxsampler> . >> >> I do not see any mention of the gig file I had previously loaded. >> >> Also, tried the linuxsampler plugin in Qtractor, but this somehow causes >> an >> immediate segfault. I've been having this problem since Qtractor 5.3. >> I'll report the details to the Qtractor forum. > > Sorry, I broke something. Patch attached. > > This should match latest SVN of LV2 stuff and Ardour. I havn't tested > it and don't know the state of QTractor at the moment. > > -dr |
|
From: Edward D. <di...@um...> - 2012-03-01 01:16:04
|
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 Don't know if all that was really needed, but did not want to miss anything. Ardour plugin state file is the same as before: <> a pset:Preset ; lv2:appliesTo <http://linuxsampler.org/plugins/linuxsampler> . No mention of the gig file I'd loaded. Also where you start ardour you get 2 of these which seems redundant: Loading LV2 state from /mdkhome/sound/recording/ardour3/lstest/plugins/126/state1/state.ttl So either there is still a bug or I'm missing something. Linuxsampler lv2 restore works fine in Qtractor. On Wed, 29 Feb 2012 17:09:57 -0500, David Robillard <d...@dr...> wrote: > On Sun, 2012-02-26 at 11:42 -0500, Edward Diehl wrote: >> I rebuilt linuxsampler (libgig, qsampler) all with SVN 2322, but still >> the >> state is not restored. My state.ttl file says: >> >> <> >> a pset:Preset ; >> lv2:appliesTo <http://linuxsampler.org/plugins/linuxsampler> . >> >> manifest.ttl has this: >> >> <state.ttl> >> a pset:Preset ; >> rdfs:seeAlso <state.ttl> ; >> lv2:appliesTo <http://linuxsampler.org/plugins/linuxsampler> . >> >> I do not see any mention of the gig file I had previously loaded. >> >> Also, tried the linuxsampler plugin in Qtractor, but this somehow causes >> an >> immediate segfault. I've been having this problem since Qtractor 5.3. >> I'll report the details to the Qtractor forum. > > Sorry, I broke something. Patch attached. > > This should match latest SVN of LV2 stuff and Ardour. I havn't tested > it and don't know the state of QTractor at the moment. > > -dr -- Edward Diehl Associate Research Scientist 367C West Hall Office: 734-936-9662 University of Michigan Fax: 734-936-6529 450 Church St Sec'y: 734-615-5811 Ann Arbor, MI 48109-1120 di...@um... |
|
From: David R. <d...@dr...> - 2012-03-03 22:39:45
|
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 |
|
From: Edward D. <di...@um...> - 2012-03-04 19:04:35
|
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 |
|
From: David R. <d...@dr...> - 2012-03-06 05:51:43
|
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 |
|
From: Andreas P. <and...@br...> - 2012-03-06 07:18:07
|
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 |
|
From: David R. <d...@dr...> - 2012-03-06 23:36:31
|
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 |
|
From: Edward D. <di...@um...> - 2012-03-06 19:59:40
|
> 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. |
|
From: David R. <d...@dr...> - 2012-03-06 23:52:33
|
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 |
|
From: Edward D. <di...@um...> - 2012-03-07 03:12:34
|
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. |
|
From: David R. <d...@dr...> - 2012-03-07 20:18:46
|
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 |
|
From: Andreas P. <and...@br...> - 2012-03-08 19:50:50
|
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 |
|
From: David R. <d...@dr...> - 2012-03-09 20:02:10
|
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 |
|
From: Christian S. <sch...@li...> - 2012-03-09 21:40:46
|
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 |
|
From: David R. <d...@dr...> - 2012-03-10 18:23:36
|
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 |
|
From: Andreas P. <and...@br...> - 2012-03-10 19:31:46
|
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 |
|
From: David R. <d...@dr...> - 2012-03-10 18:24:43
|
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 |
|
From: Christian S. <sch...@li...> - 2012-03-10 18:37:07
|
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 |
|
From: David R. <d...@dr...> - 2012-03-10 18:52:31
|
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 |
|
From: Christian S. <sch...@li...> - 2012-03-11 14:54:49
|
On Saturday 10 March 2012 19:52:21 David Robillard wrote: > > > > 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. Really? What is the purpose to enumerate all used files in the LV2 session? Because from sampler perspective, only the "main" instrument file name has to be passed when loading a session. The sampler (or in this case libgig) will then automatically detect and retrieve the list of extension files from the main gig file and load the extension files automatically. Anyway, if you really need to enumerate all files, tell me, then I will patch libgig for this task. > > > > (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. Depends for what you want to use it. If its a custom application you can also just use 64 bit RIFF chunk offsets instead of 32 bit ones of the original RIFF format and that's it. Some people also did it like this: they placed all RIFF chunks into the first 2 GB of the file, and e.g. placed their huge audio sample data after all those RIFF chunks and used 64 bit file offsets to reference the sample data from RIFF chunks. However Tascam decided not to do that for the Gig format, in favor of the extension files solution, because there are many systems which still have a 2 GB file size limit in general. CU Christian |
|
From: David R. <d...@dr...> - 2012-03-11 19:26:44
|
On Sun, 2012-03-11 at 14:58 +0100, Christian Schoenebeck wrote: > On Saturday 10 March 2012 19:52:21 David Robillard wrote: > > > > > 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. > > Really? What is the purpose to enumerate all used files in the LV2 session? > Because from sampler perspective, only the "main" instrument file name has to > be passed when loading a session. The sampler (or in this case libgig) will > then automatically detect and retrieve the list of extension files from the > main gig file and load the extension files automatically. Because the host needs to know where all the files are to make session archival possible. The Lilv (and thus Ardour) implementation, for example, makes symlinks to all those files in the session directory, and the plugin state refers to those instead. That way all external file references are transparent and you can make a deep archive with tar -h. This is so, e.g., I can roll up a session I've been working on, send it to you, and it will actually work; or when you're finished a piece you can archive it and be sure all the component bits are archived along with it. > Anyway, if you really need to enumerate all files, tell me, then I will patch > libgig for this task. That would be great, thanks. -dr |
|
From: Christian S. <sch...@li...> - 2012-03-12 15:28:20
|
On Sunday 11 March 2012 20:26:35 David Robillard wrote: > Because the host needs to know where all the files are to make session > archival possible. Yes, makes sense. > > Anyway, if you really need to enumerate all files, tell me, then I will > > patch libgig for this task. > > That would be great, thanks. Please update libgig and linuxsampler from svn. The EngineChannel class now has a method: String EngineChannel::InstrumentFileName(int index) additionally to the already existing, equal named method without argument. So calling this new method with argument zero is equivalent as calling the method without argument, that is it will return the file name of the "main" instrument file (e.g. "foo.gig"), where as calling the method with argument 1, 2, 3, ... will return the name of the respective extension file (e.g. "foo.gx01", "foo.gx02", "foo.gx03", ...). It will return an empty string if index is out of bounds (e.g. end of extension file list exceeded). Let me know if you need something else. CU Christian |
|
From: David R. <d...@dr...> - 2012-03-12 17:05:08
|
On Mon, 2012-03-12 at 15:31 +0100, Christian Schoenebeck wrote: > On Sunday 11 March 2012 20:26:35 David Robillard wrote: > > Because the host needs to know where all the files are to make session > > archival possible. > > Yes, makes sense. > > > > Anyway, if you really need to enumerate all files, tell me, then I will > > > patch libgig for this task. > > > > That would be great, thanks. > > Please update libgig and linuxsampler from svn. The EngineChannel class now > has a method: > > String EngineChannel::InstrumentFileName(int index) > > additionally to the already existing, equal named method without argument. So > calling this new method with argument zero is equivalent as calling the method > without argument, that is it will return the file name of the "main" instrument > file (e.g. "foo.gig"), where as calling the method with argument 1, 2, 3, ... > will return the name of the respective extension file (e.g. "foo.gx01", > "foo.gx02", "foo.gx03", ...). It will return an empty string if index is out > of bounds (e.g. end of extension file list exceeded). Perfect, thanks a lot. I will try to get the LV2 stuff working. It seems implicit that the .gxnn files are in the same directory as the main .gig, so simply telling the host about them should work fine. If those paths are referred to in state anywhere, the modified versions would have to be used... (already done for the .gig) Thanks, -dr |
Thanks for helping keep SourceForge clean.
X