Menu
▾
▴
linuxsampler-devel
|
From: Ivan M. <iv...@ma...> - 2018-12-08 17:34:33
|
Hi everyone I've attached two small patches that I'm using that you might also find useful. linuxsampler-2.1.0.svn1-sustain_release_velocity.patch causes sustain release samples to be played with the latest Note On velocity of each key instead of the current hard-coded velocity of 127 (the highest). This was causing me a problem while playing some piano instruments like PMI Emperor 24-bit where I would hear an unnaturally loud thump and string noise on releasing the sustain pedal even after playing very softly. libgig-4.1.0.svn5-load_giga4_as_giga3.patch causes GigaStudio 4 instruments to be loaded as if they were GigaStudio 3 instruments. They are currently loaded as if they were GigaStudio 2 instruments making them unplayable (usually the same samples on every key). I have a set of about 25 GigaStudio 4 instruments which were included on my GigaStudio 4 installation discs. There are only one or two of these instruments which don't behave as expected with this patch. Kind regards, Ivan |
|
From: Christian S. <sch...@li...> - 2018-12-09 12:00:04
|
On Samstag, 8. Dezember 2018 17:15:54 CET Ivan Maguidhir wrote: > Hi everyone Hi Ivan! > libgig-4.1.0.svn5-load_giga4_as_giga3.patch causes GigaStudio 4 > instruments to be loaded as if they were GigaStudio 3 instruments. They > are currently loaded as if they were GigaStudio 2 instruments making > them unplayable (usually the same samples on every key). I have a set of > about 25 GigaStudio 4 instruments which were included on my GigaStudio 4 > installation discs. There are only one or two of these instruments which > don't behave as expected with this patch. That makes sense. What does gigdump print as global file information for a gig v4 file? Have you already checked for interesting new features in GSt4 that we might be missing yet? > linuxsampler-2.1.0.svn1-sustain_release_velocity.patch causes sustain > release samples to be played with the latest Note On velocity of each > key instead of the current hard-coded velocity of 127 (the highest). > This was causing me a problem while playing some piano instruments like > PMI Emperor 24-bit where I would hear an unnaturally loud thump and > string noise on releasing the sustain pedal even after playing very softly. Have you compared this behaviour with your GigaStudio 4 software there? Is that what GSt4 does when releasing the sustain pedal? So for instance if you press sustain down, then trigger a key with high velocity, then a 2nd time the same key with low velocity, then release the sustain pedal, would GSt then play a soft release trigger voice? CU Christian |
|
From: Ivan M. <iv...@ma...> - 2018-12-09 19:39:38
|
On 09/12/2018 11:59, Christian Schoenebeck wrote: > On Samstag, 8. Dezember 2018 17:15:54 CET Ivan Maguidhir wrote: >> Hi everyone > Hi Ivan! Hi Christian. Thanks for the quick response. > >> libgig-4.1.0.svn5-load_giga4_as_giga3.patch causes GigaStudio 4 >> instruments to be loaded as if they were GigaStudio 3 instruments. They >> are currently loaded as if they were GigaStudio 2 instruments making >> them unplayable (usually the same samples on every key). I have a set of >> about 25 GigaStudio 4 instruments which were included on my GigaStudio 4 >> installation discs. There are only one or two of these instruments which >> don't behave as expected with this patch. > That makes sense. What does gigdump print as global file information for a gig > v4 file? Here's a link to a zip file containing dumps of all the GSt4 instruments mentioned. http://www.maguidhir.ie/GSt4_Dumps.zip > > Have you already checked for interesting new features in GSt4 that we might be > missing yet? Not really, but I did notice problems with some of the GSt4 instruments. Two instruments called SONiVOX Alto Saxophone.gig and SONiVOX Harmon Mute Trumpet.gig seem to have clipping or a slight crackling noise on all notes. Also, an instrument called SONiVOX Synth Pads.gig does not work as expected at all. Looking at it in gigedit it has relatively few samples and many regions share a single sample. I think it might rely on filters to generate the different patches? Anyway, it currently produces ear damaging squeaks and squawks before crashing the linuxsampler backend. When I debugged this crash I found out that it happens because linuxsampler doesn't have enough audio samples to resample to pitches that cover the entire keyboard and still have the required block size (256 in my case) to send to ALSA/JACK. Find attached a patch that prevents the crash by dropping notes. I didn't submit this yesterday as it's a bit of a hack and I'm not sure if it's correct. The SONiVOX Synth Pads.gig instrument still doesn't produce the sounds it's supposed to with this patch. I will try to investigate how GSt4 handles this instrument if I can get it running in a VM. >> linuxsampler-2.1.0.svn1-sustain_release_velocity.patch causes sustain >> release samples to be played with the latest Note On velocity of each >> key instead of the current hard-coded velocity of 127 (the highest). >> This was causing me a problem while playing some piano instruments like >> PMI Emperor 24-bit where I would hear an unnaturally loud thump and >> string noise on releasing the sustain pedal even after playing very softly. > Have you compared this behaviour with your GigaStudio 4 software there? Is > that what GSt4 does when releasing the sustain pedal? So for instance if you > press sustain down, then trigger a key with high velocity, then a 2nd time the > same key with low velocity, then release the sustain pedal, would GSt then > play a soft release trigger voice? Not yet. It's actually years since I've used GSt4. I'm going to try and get it working in a Windows XP VM this evening. I wrote a piece of software several years ago for sending MIDI from JACK on Linux to a driver running in a Windows VM over Ethernet. I hope I can find it again. Using this I should be able to test the sustain pedal behaviour. > > CU > Christian All the best, Ivan > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Christian S. <sch...@li...> - 2018-12-10 14:53:39
|
On Sonntag, 9. Dezember 2018 19:39:23 CET Ivan Maguidhir wrote: > > That makes sense. What does gigdump print as global file information for a > > gig v4 file? > > Here's a link to a zip file containing dumps of all the GSt4 instruments > mentioned. I applied your libgig patch to SVN and added gig::File::VERSION_4 as new version identifier according to your dumps. Thanks! I also added a new option to gigedit File->Properties->File Format so that one could explicitly store with gig v4 file format. That might help when toying around with new gig v4 features. > Find attached a patch that > prevents the crash by dropping notes. I didn't submit this yesterday as > it's a bit of a hack and I'm not sure if it's correct. The SONiVOX Synth > Pads.gig instrument still doesn't produce the sounds it's supposed to > with this patch. I will try to investigate how GSt4 handles this > instrument if I can get it running in a VM. The patch prevents the crash, that's correct, but the root cause seems to be that your gig file uses a higher sample playback start position than previously max. allowed and expected by the engine. So obviously even with the patch you won't be able to play the instrument correctly. Probably they raised that playback start position limit in v4. Since you are one of the very few people still having a working GSt 4 installation, that might also be valueable to see what maximum playback start position is allowed in the GSt 4 instrument editor. Once we know the max. playback start position in GSt Instr. Editor 4 we can raise that limit on LS side and that would resolve that issue correctly. > > Have you compared this behaviour with your GigaStudio 4 software there? Is > > that what GSt4 does when releasing the sustain pedal? So for instance if > > you press sustain down, then trigger a key with high velocity, then a 2nd > > time the same key with low velocity, then release the sustain pedal, > > would GSt then play a soft release trigger voice? > > Not yet. It's actually years since I've used GSt4. I'm going to try and > get it working in a Windows XP VM this evening. I wrote a piece of > software several years ago for sending MIDI from JACK on Linux to a > driver running in a Windows VM over Ethernet. I hope I can find it > again. Using this I should be able to test the sustain pedal behaviour. Interesting! Might be a useful piece of software for other people as well. :-) I wait a bit before applying your sustain patch to LS. Let's see what test results you get there with GSt 4 on this issue. Thanks! CU Christian |
|
From: Ivan M. <iv...@ma...> - 2018-12-12 14:03:25
|
Hi Christian On 10/12/2018 14:53, Christian Schoenebeck wrote: > On Sonntag, 9. Dezember 2018 19:39:23 CET Ivan Maguidhir wrote: >>> That makes sense. What does gigdump print as global file information for a >>> gig v4 file? >> Here's a link to a zip file containing dumps of all the GSt4 instruments >> mentioned. > I applied your libgig patch to SVN and added gig::File::VERSION_4 as new > version identifier according to your dumps. Thanks! > > I also added a new option to gigedit File->Properties->File Format so that one > could explicitly store with gig v4 file format. That might help when toying > around with new gig v4 features. > Many thanks for doing this and for the mention on the website. >> Find attached a patch that >> prevents the crash by dropping notes. I didn't submit this yesterday as >> it's a bit of a hack and I'm not sure if it's correct. The SONiVOX Synth >> Pads.gig instrument still doesn't produce the sounds it's supposed to >> with this patch. I will try to investigate how GSt4 handles this >> instrument if I can get it running in a VM. > The patch prevents the crash, that's correct, but the root cause seems to be > that your gig file uses a higher sample playback start position than previously > max. allowed and expected by the engine. So obviously even with the patch you > won't be able to play the instrument correctly. > > Probably they raised that playback start position limit in v4. Since you are > one of the very few people still having a working GSt 4 installation, that > might also be valueable to see what maximum playback start position is allowed > in the GSt 4 instrument editor. > > Once we know the max. playback start position in GSt Instr. Editor 4 we can > raise that limit on LS side and that would resolve that issue correctly. I haven't been able to get GSt4 working in a VirtualBox VM with the USB licenser passed through from the host so far :-( I'll keep working on this to find a solution. I might be able to find out the max start position by looking at the instrument editor in a debugger, I'll give this a try later today. >>> Have you compared this behaviour with your GigaStudio 4 software there? Is >>> that what GSt4 does when releasing the sustain pedal? So for instance if >>> you press sustain down, then trigger a key with high velocity, then a 2nd >>> time the same key with low velocity, then release the sustain pedal, >>> would GSt then play a soft release trigger voice? >> Not yet. It's actually years since I've used GSt4. I'm going to try and >> get it working in a Windows XP VM this evening. I wrote a piece of >> software several years ago for sending MIDI from JACK on Linux to a >> driver running in a Windows VM over Ethernet. I hope I can find it >> again. Using this I should be able to test the sustain pedal behaviour. > Interesting! Might be a useful piece of software for other people as well. :-) I should finish it off and publish it. I gave up on it because I could never get the audio over Ethernet part of it working. The idea was to be enable the use VSTs etc. running on Windows in Linux programs like Ardour. > > I wait a bit before applying your sustain patch to LS. Let's see what test > results you get there with GSt 4 on this issue. I didn't specify it in earlier emails but the the Sustain Release issue applies to GSt3 also. In fact the instrument I mentioned, PMI Emperor, is actually a GSt3 instrument. As I couldn't get GSt4 working I set up a VM running GSt3 this morning. I recorded a MIDI file on my Linux host containing a loud note followed by a soft note with the sustain pedal pressed followed by the release of the sustain pedal, as you suggested. When this file is played through LinuxSampler with my patch applied I hear the notes followed by the sustain release samples played at the velocity of the last note. When the file is played through GSt3 I hear no sustain release samples at all. So it would seem that neither the current behaviour nor the behaviour with my patch applied are correct. I think the sustain release behaviour changed from version 1.0 here http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=2927 > Thanks! > > CU > Christian All the best, Ivan > > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Jaime T <eno...@gm...> - 2018-12-13 09:19:38
|
On Sat, 8 Dec 2018 at 17:34, Ivan Maguidhir <iv...@ma...> wrote: > This was causing me a problem while playing some piano instruments like > PMI Emperor 24-bit where I would hear an unnaturally loud thump and > string noise on releasing the sustain pedal even after playing very softly. I have exactly the same problem with the original Gigapiano. I haven't had a chance to try out your fix yet, but thank you for finding this! (The problem makes linuxsampler unusable with that instrument). |
|
From: Ivan M. <iv...@ma...> - 2018-12-13 22:19:41
|
No problem at all Jaime. Glad to hear it will help! On 13/12/2018 09:19, Jaime T wrote: > I have exactly the same problem with the original Gigapiano. I haven't > had a chance to try out your fix yet, but thank you for finding this! > (The problem makes linuxsampler unusable with that instrument). |
|
From: Christian S. <sch...@li...> - 2018-12-13 13:23:36
|
On Mittwoch, 12. Dezember 2018 14:02:55 CET Ivan Maguidhir wrote:
> I haven't been able to get GSt4 working in a VirtualBox VM with the USB
> licenser passed through from the host so far :-( I'll keep working on
> this to find a solution. I might be able to find out the max start
> position by looking at the instrument editor in a debugger, I'll give
> this a try later today.
You think the USB dongle is the problem? I guess you are just passing through
the USB dongle for direct acess to the Virtualbox guest OS, that works usually
quite well due to its simplicity. Maybe there is rather a problem with the
GSt 4 license server on the Internet. Have you checked which server and port
the installer is trying to reach?
> I should finish it off and publish it. I gave up on it because I could
> never get the audio over Ethernet part of it working. The idea was to be
> enable the use VSTs etc. running on Windows in Linux programs like Ardour.
Yeah, that can be tricky. Sounds like a good candidate for somebody else
trying to add the missing bricks. In general I would not expect low latencies
though.
> > I wait a bit before applying your sustain patch to LS. Let's see what test
> > results you get there with GSt 4 on this issue.
>
> I didn't specify it in earlier emails but the the Sustain Release issue
> applies to GSt3 also. In fact the instrument I mentioned, PMI Emperor,
Well, chances are that GSt actually never played release triggered samples
when releasing the sustain pedal. That would explain what you are observing
there.
What we could do is adding a LS specific file format extension so that anybody
might simply pick his preferred behaviour with LS and probably revert the
default behaviour back to not playing any release samples on sustain up. So a
new option in gigedit like:
1. Default (no release trigger samples on sustain up)
2. Release trigger on sustain up using 127 velocity
3. Release trigger on sustain up using latest note-on velocity
4. Release trigger on sustain up using continuous CC64 info ("half pedal"
support).
CU
Christian
|
|
From: Ivan M. <iv...@ma...> - 2018-12-13 21:41:47
|
Hi Christian On 13/12/2018 13:23, Christian Schoenebeck wrote: > You think the USB dongle is the problem? I guess you are just passing through > the USB dongle for direct acess to the Virtualbox guest OS, that works usually > quite well due to its simplicity. Maybe there is rather a problem with the > GSt 4 license server on the Internet. Have you checked which server and port > the installer is trying to reach? The activation for Gigastudio 4 is different to previous versions in that it's completely offline. There is no license server and the applications depend entirely on the presence of an eLicenser with a valid license to launch. The problem I was having is that the old version of the eLicenser software included with Gigastudio 4 can't read my eLicenser anymore. The latest version of the eLicenser software from Steinberg can read my eLicenser but Gigastudio 4 doesn't seem to be able to use this software, probably due to changes to the interfaces of DLLs etc. since 2008. The good news is that I put on my grey hat yesterday evening and now have GSEdit4 running in a VM. As a result I was able to check what the maximum Sample Start Offset is - it's still 2000, it hasn't changed. This can be verified at the bottom of page 166 in the GSEdit4 User Manual available here https://tascam.com/us/product/gigastudio_4/download. I hope to get GStudio4 running soon in a similar way. > Well, chances are that GSt actually never played release triggered samples > when releasing the sustain pedal. That would explain what you are observing > there. Yes, it looks like it could be a GSt3 bug. > What we could do is adding a LS specific file format extension so that anybody > might simply pick his preferred behaviour with LS and probably revert the > default behaviour back to not playing any release samples on sustain up. So a > new option in gigedit like: > > 1. Default (no release trigger samples on sustain up) > 2. Release trigger on sustain up using 127 velocity > 3. Release trigger on sustain up using latest note-on velocity > 4. Release trigger on sustain up using continuous CC64 info ("half pedal" > support). Defaulting to no release trigger samples and giving users the option to change this sounds great. It could also be implemented as a scripting command so that users don't have to modify their gig files. Let me know if I can help with making the changes and many thanks for your time spent on this. > CU > Christian All the best, Ivan > > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Ivan M. <iv...@ma...> - 2018-12-18 03:32:08
|
Hi Christian and everyone On 14/12/2018 12:08, Christian Schoenebeck wrote: > Well, that already a great step! Most of our valueable GSt infos we got were > by using the GSt instrument editor. > > However when the limit is still 2000 then I don't understand why you got the > sample offset problem at first place. When you look into config.h you will see > that the default value for precaching samples is 32768, so even if you have > samples there with 2000 start offsest, you should not get into any problems. I'd like to see how that Sonivox Synth instrument looks and behaves in GSEdit4 and GStudio4. That might provide some clues. I'll do that as soon as I can. > I would probably first implement it as optional dimension region option in > libgig and add a combo box for that in gigedit on dimension region level as > well. Find attached a few patches with an implementation of this. The option can only be modified at instrument level in gigedit, but gets populated down into the DimensionRegions of the instrument during saving, where it is easily accessible by linuxsampler, and vice versa during loading. I didn't implement half-pedaling because I'm not sure that the release samples should be played until the sustain pedal is fully released, I can change this easily though. I also included some work towards supporting writing of multi-part gig files and a small fix in gigedit where a pointer to a std::vector on the stack was being used by a ChoiceEntry widget after it had gone out of scope. I will continue working on the multi-part gig file writing as I would really like to be able to edit my PMI pianos in gigedit. > Then later on one could still add a NKSP script function allowing to override > the behaviour by script. Keep in mind most users are no software developers. > So writing a NKSP script is often beyond their abilities. You are right. The gigedit way is preferable. > CU > Christian All the best, Ivan |
|
From: Ivan M. <iv...@ma...> - 2018-12-20 00:10:14
Attachments:
linuxsampler-2.1.0.svn1-sustain_up_release2.patch
|
Hi I've attached an updated version of the linuxsampler-2.1.0.svn1 patch I submitted on Tuesday morning. The previous one should have worked most of the time but the logic wasn't quite correct. I'm using copies of Tascam GigaPiano II, edited in gigedit, to test my changes btw and they appear to be working. All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2018-12-20 10:38:24
|
On Donnerstag, 20. Dezember 2018 00:10:00 CET Ivan Maguidhir wrote: > I've attached an updated version of the linuxsampler-2.1.0.svn1 patch I > submitted on Tuesday morning. > The previous one should have worked most of the time but the logic > wasn't quite correct. I'm using copies of Tascam GigaPiano II, edited in > gigedit, to test my changes btw and they appear to be working. I probably have to adjust your changes a bit. I will do so in the next couple days. Thanks Ivan! CU Christian |
|
From: Christian S. <sch...@li...> - 2018-12-20 23:30:41
|
On Donnerstag, 20. Dezember 2018 11:38:04 CET Christian Schoenebeck wrote:
> On Donnerstag, 20. Dezember 2018 00:10:00 CET Ivan Maguidhir wrote:
> > I've attached an updated version of the linuxsampler-2.1.0.svn1 patch I
> > submitted on Tuesday morning.
> > The previous one should have worked most of the time but the logic
> > wasn't quite correct. I'm using copies of Tascam GigaPiano II, edited in
> > gigedit, to test my changes btw and they appear to be working.
>
> I probably have to adjust your changes a bit. I will do so in the next
> couple days.
Question, what's that about?
- if (fileNo == lastFileNo) break;
+ if (fileNo == lastFileNo) {
+ // add the .gx99 extension file if present
+ // this can be present even with a single .gig file
+ sprintf(suffix, ".gx%02d", 99);
+ name.replace(nameLen, 5, suffix);
+ try {
+ file = new RIFF::File(name);
+ ExtensionFiles.push_back(file);
+ }
+ catch(...) {
+ }
+ break;
+ }
// open extension file (*.gx01, *.gx02, ...)
fileNo++;
You have libraries where you only have two files like foo.gig and foo.gx99 ?
Sounds very odd to me.
CU
Christian
|
|
From: Ivan M. <iv...@ma...> - 2018-12-21 00:52:46
|
Hi Christian On 20/12/2018 23:30, Christian Schoenebeck wrote: > You have libraries where you only have two files like foo.gig and foo.gx99 ? > Sounds very odd to me. The Tascam GigaPiano II instrument, from the GigaStudio3 installation CDs, that I mentioned earlier actually has this structure. It seems to always be a small file. In the case of GigaPiano it seems to contain pedal up resonance data, an impulse response maybe? All the other instruments I have which have the .gx99 file are large multi-part instruments. > CU > Christian All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2018-12-21 10:33:03
|
On Freitag, 21. Dezember 2018 00:52:30 CET Ivan Maguidhir wrote: > Hi Christian > > On 20/12/2018 23:30, Christian Schoenebeck wrote: > > You have libraries where you only have two files like foo.gig and foo.gx99 > > ? Sounds very odd to me. > > The Tascam GigaPiano II instrument, from the GigaStudio3 installation > CDs, that I mentioned earlier actually has this structure. It seems to > always be a small file. In the case of GigaPiano it seems to contain > pedal up resonance data, an impulse response maybe? All the other > instruments I have which have the .gx99 file are large multi-part > instruments. Ok, that is one side of the coin. But usually all extension files are also mentioned in the main gig file, or to be more precise, their precise extension file number is stored in the upper (hi) wave table entry. And this is not the case in your libraries? I mean that's an important aspect. Samples referenced and stored in extension files only work if their correct extension file number was stored in the main gig file's wavetable this way. So simply loading some extension file which would not be used at all in the end would not really make sense. CU Christian |
|
From: Jaime T <eno...@gm...> - 2018-12-21 18:26:11
|
I admit that I don't fully understand everything that's been said in this thread, but I've found a thread of conversation (from 2006!) in a "Native Instruments" forum that looks very much like it is related to the subjects being discussed here (they are talking about problems with pedal-up release samples). I'm posting the url on the off-chance that anyone working on these problems finds the information useful: https://www.native-instruments.com/forum/threads/gigastudio-imports.35286/ HTH, Jaime |
|
From: Ivan M. <iv...@ma...> - 2018-12-21 18:49:53
|
Hi Christian On 21/12/2018 10:32, Christian Schoenebeck wrote: > Ok, that is one side of the coin. But usually all extension files are also > mentioned in the main gig file, or to be more precise, their precise extension > file number is stored in the upper (hi) wave table entry. And this is not the > case in your libraries? You appear to be assuming that there is wave data in all extension files however, from what I have seen there is no wave data in files with the .gx99 extension. They are usually only 1-2 megabytes in size. > I mean that's an important aspect. Samples referenced and stored in extension > files only work if their correct extension file number was stored in the main > gig file's wavetable this way. So simply loading some extension file which would > not be used at all in the end would not really make sense. It makes sense from the point of view of preserving the structure of the input files during a Save As operation in gigedit, for example. > CU > Christian All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2018-12-21 19:54:25
|
On Freitag, 21. Dezember 2018 18:49:36 CET Ivan Maguidhir wrote: > On 21/12/2018 10:32, Christian Schoenebeck wrote: > > Ok, that is one side of the coin. But usually all extension files are also > > mentioned in the main gig file, or to be more precise, their precise > > extension file number is stored in the upper (hi) wave table entry. And > > this is not the case in your libraries? > > You appear to be assuming that there is wave data in all extension files > however, from what I have seen there is no wave data in files with the > .gx99 extension. They are usually only 1-2 megabytes in size. I am not assuming anything. That's the point. I am trying to understand what the actual purpose of the file is and whether the proposed change is still suboptimal, hence I am asking. > > I mean that's an important aspect. Samples referenced and stored in > > extension files only work if their correct extension file number was > > stored in the main gig file's wavetable this way. So simply loading some > > extension file which would not be used at all in the end would not really > > make sense. > > It makes sense from the point of view of preserving the structure of the > input files during a Save As operation in gigedit, for example. libgig does not support writing gigs with extension files, it is read only. CU Christian |
|
From: Ivan M. <iv...@ma...> - 2018-12-21 23:03:02
|
Hi Christian On 21/12/2018 19:54, Christian Schoenebeck wrote: > I am not assuming anything. That's the point. I am trying to understand what > the actual purpose of the file is and whether the proposed change is still > suboptimal, hence I am asking. What I know about the .gx99 file is that it is part of the instrument (obviously) and a valid RIFF file. Upon examination in a hex editor I noticed several "Piano PedalUp Resonance" strings hence my guess that it could be an impulse response. Here <http://www.maguidhir.ie/GigaPiano_Dumps.zip> is a gigdump of the main gig and a rifftree of the .gx99 file. > libgig does not support writing gigs with extension files, it is read only. This needs to change if users are expected to set instrument options in gigedit. Most of the piano instruments I have use extension files for their wave data. I included some code in my libgig patch which causes extension files to be re-saved/saved during Save/Save As which I thought would be a good starting point. > CU > Christian All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2018-12-23 19:51:32
|
On Donnerstag, 20. Dezember 2018 11:38:04 CET Christian Schoenebeck wrote:
> On Donnerstag, 20. Dezember 2018 00:10:00 CET Ivan Maguidhir wrote:
> > I've attached an updated version of the linuxsampler-2.1.0.svn1 patch I
> > submitted on Tuesday morning.
> > The previous one should have worked most of the time but the logic
> > wasn't quite correct. I'm using copies of Tascam GigaPiano II, edited in
> > gigedit, to test my changes btw and they appear to be working.
>
> I probably have to adjust your changes a bit. I will do so in the next
> couple days.
Ok, I committed changes against libgig and LS for this sustain pedal up issue.
This time I took a different approach of what you orginally suggested with
your patches.
On libgig side my intention was to only use one subchunk ("LSDE") for all
format extensions that we might introduce on DimensionRegion level.
On LS side I had to use a more complex solution, that's because your runtime
check against active voice objects would have its limitations, e.g. when the
regular voice already came to its end (e.g. short sample) then no release
trigger sample would have been triggered since the voice object was gone
already.
As a side effect of that implementation on LS side, there is now actually
already a code in place for allowing the complete opposite: playing release
trigger samples only on sustain pedal up, but not on note-off. So i wonder
whether I should add that somewhat exotic option to libgig as well?
CU
Christian
|
|
From: Ivan M. <iv...@ma...> - 2018-12-23 21:22:53
|
Hi Christian
On 23/12/2018 19:51, Christian Schoenebeck wrote:
> On libgig side my intention was to only use one subchunk ("LSDE") for all
> format extensions that we might introduce on DimensionRegion level.
That's a much better design! Brilliant, thanks!
It did occur to me to try this by giving the new subchunk a version
number but the difficulty was that the chunks ordinarily have to be a
fixed size.
> On LS side I had to use a more complex solution, that's because your runtime
> check against active voice objects would have its limitations, e.g. when the
> regular voice already came to its end (e.g. short sample) then no release
> trigger sample would have been triggered since the voice object was gone
> already.
It never occurred to me that this would happen. In retrospect and
without cheating by looking at your code I probably would have
maintained a map between key and setting. Thanks for this change as well!
> As a side effect of that implementation on LS side, there is now actually
> already a code in place for allowing the complete opposite: playing release
> trigger samples only on sustain pedal up, but not on note-off. So i wonder
> whether I should add that somewhat exotic option to libgig as well?
This could be useful if the note-off release trigger samples in a
particular instrument were annoying / too loud as was the case with a
converted instrument in the thread linked to by Jaime T. I think it
would be a good idea to include it.
> CU
> Christian
All the best,
Ivan
|
|
From: Christian S. <sch...@li...> - 2018-12-23 23:18:35
|
On Sonntag, 23. Dezember 2018 21:22:37 CET Ivan Maguidhir wrote: > > As a side effect of that implementation on LS side, there is now actually > > already a code in place for allowing the complete opposite: playing > > release > > trigger samples only on sustain pedal up, but not on note-off. So i wonder > > whether I should add that somewhat exotic option to libgig as well? > > This could be useful if the note-off release trigger samples in a > particular instrument were annoying / too loud as was the case with a > converted instrument in the thread linked to by Jaime T. I think it > would be a good idea to include it. Done. I also committed required changes to gigedit. You find a new combo box and a new checkbox on the "Misc" tab there. Didn't have the time to test these things. I'm off for couple days now; Christmas obligations. Happy Christmas holidays guys, and don't drink too much! :) CU Christian |
|
From: Ivan M. <iv...@ma...> - 2018-12-23 23:45:13
|
On 23/12/2018 23:18, Christian Schoenebeck wrote: > Happy Christmas holidays guys, and don't drink too much! :) Thanks Christian! The same to you. |
|
From: Ivan M. <iv...@ma...> - 2019-01-02 22:36:59
Attachments:
linuxsampler-2.1.0.svn3-or_operator.patch
|
Hi Christian On 23/12/2018 23:18, Christian Schoenebeck wrote: > I also committed required changes to gigedit. You find a new combo box and a > new checkbox on the "Misc" tab there. > > Didn't have the time to test these things. I'm off for couple days now; > Christmas obligations. I just want to draw your attention to the 'or' operator for release_trigger_t at the top of linuxsampler/src/engines/common/Note.h. This operator calls itself recursively causing a segmentation fault when I load an instrument containing release trigger samples and try to play it. Casting variables a and b to int before the bitwise operation solves the problem but I'm not sure if that's what you intended? I've attached a patch with my suggested change. All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-01-03 12:13:12
|
On Wednesday, 2. Januar 2019 22:36:45 CET Ivan Maguidhir wrote: > I just want to draw your attention to the 'or' operator for > release_trigger_t at the top of linuxsampler/src/engines/common/Note.h. > This operator calls itself recursively causing a segmentation fault when > I load an instrument containing release trigger samples and try to play > it. Casting variables a and b to int before the bitwise operation solves > the problem but I'm not sure if that's what you intended? I've attached > a patch with my suggested change. Yep, I overlooked that one. I just committed your patch (SVN r3452). Thanks Ivan! CU Christian |
Thanks for helping keep SourceForge clean.
X