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

[Linuxsampler-devel] msvc patch

[justnope <spa...@te...>]

Hi,

This is a first attempt to compile the library with msvc.
The changes are:
* ssize_t -> size_t
* vasprintf -> vsnprintf, malloc, sprintf
* removed unavailable headers
* added cmake file

To compile it, use cmake <source dir>. This will generate a visual 
studio solution file which you can open and build the project. In the 
cmake file I've added the option to make all symbols in the library 
public (or whatever the right term is), so it behaves like gcc. This 
avoids polluting the source code with DLL_EXPORT defines 
(__declspec(dllexport/dllimport)).

It's possible I missed some things which configure generates. I'll add 
those to CMakeLists.txt in the future.

Currently it only builds the library and not the tools. I'm hoping to 
add those later.

There's also a message in the source code "type_info::raw_name() 
demangling has not been tested yet with Microsoft compiler! Feedback 
appreciated!"

I'm working on lmms porting the code to msvc and to be honest I'm not 
that familiar with libgig, but if you let me know what triggers that 
code, I'll gladly try it out.

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

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

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

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

[Ivan M. <iv...@ma...>]

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

Re: [Linuxsampler-devel] svn gigedit and gtkmm-3.24.0 compilation issue

[Miroslav Š. <for...@fo...>]

thanks for guiding me and for the work you do! :-)

regards.

miroslav


Dne 2019-01-02 17:44, Christian Schoenebeck napsal:
> On Wednesday, 2. Januar 2019 13:55:00 CET Miroslav Šulc wrote:
>> thank you for guiding me :-) here's the patch that works for me:
>> https://cgit.gentoo.org/dev/fordfrog.git/tree/media-sound/gigedit/files/gige
>> dit-9999-gtkmm-3.24.patch
> 
> Perfect! And it is now in SVN r3450 on our side.
> 
> Thanks for your patch Miroslav!
> 
> CU
> Christian
> 
> 
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] svn gigedit and gtkmm-3.24.0 compilation issue

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

On Wednesday, 2. Januar 2019 13:55:00 CET Miroslav Šulc wrote:
> thank you for guiding me :-) here's the patch that works for me:
> https://cgit.gentoo.org/dev/fordfrog.git/tree/media-sound/gigedit/files/gige
> dit-9999-gtkmm-3.24.patch

Perfect! And it is now in SVN r3450 on our side.

Thanks for your patch Miroslav!

CU
Christian

Re: [Linuxsampler-devel] svn gigedit and gtkmm-3.24.0 compilation issue

[Miroslav Š. <for...@fo...>]

hi again,

thank you for guiding me :-) here's the patch that works for me: 
https://cgit.gentoo.org/dev/fordfrog.git/tree/media-sound/gigedit/files/gigedit-9999-gtkmm-3.24.patch

regards.

miroslav


Dne 2019-01-01 20:50, Christian Schoenebeck napsal:
> On Dienstag, 1. Januar 2019 20:23:52 CET Miroslav Šulc wrote:
>> thanks for the clarification. i patched the file (patch attached) and
>> the original errors are gone, but now i get these:
>> 
>> mainwindow.cpp: In constructor ‘PropDialog::PropDialog()’:
>> mainwindow.cpp:2769:11: error: ‘class Table’ has no member named
>> ‘set_margin’; did you mean ‘set_halign’?
>>       table.set_margin(5);
>>             ^~~~~~~~~~
>>             set_halign
> 
> If you look at the mentioned locations of those errors in the source 
> files you
> will see there are the same GTK version checks as previously described.
> Adjusting them in the same way should do the trick.
> 
> You are a Gentoo user, you can do that! :)
> 
> CU
> Christian
> 
> 
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] svn gigedit and gtkmm-3.24.0 compilation issue

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

On Dienstag, 1. Januar 2019 20:23:52 CET Miroslav Šulc wrote:
> thanks for the clarification. i patched the file (patch attached) and
> the original errors are gone, but now i get these:
> 
> mainwindow.cpp: In constructor ‘PropDialog::PropDialog()’:
> mainwindow.cpp:2769:11: error: ‘class Table’ has no member named
> ‘set_margin’; did you mean ‘set_halign’?
>       table.set_margin(5);
>             ^~~~~~~~~~
>             set_halign

If you look at the mentioned locations of those errors in the source files you 
will see there are the same GTK version checks as previously described. 
Adjusting them in the same way should do the trick.

You are a Gentoo user, you can do that! :)

CU
Christian

Re: [Linuxsampler-devel] svn gigedit and gtkmm-3.24.0 compilation issue

[Miroslav Š. <for...@fo...>]

hi again,

thanks for the clarification. i patched the file (patch attached) and 
the original errors are gone, but now i get these:

mainwindow.cpp: In constructor ‘PropDialog::PropDialog()’:
mainwindow.cpp:2769:11: error: ‘class Table’ has no member named 
‘set_margin’; did you mean ‘set_halign’?
      table.set_margin(5);
            ^~~~~~~~~~
            set_halign
mainwindow.cpp:2777:15: error: ‘HButtonBox’ {aka ‘class 
Gtk::HButtonBox’} has no member named ‘set_margin’; did you mean 
‘set_halign’?
      buttonBox.set_margin(5);
                ^~~~~~~~~~
                set_halign
mainwindow.cpp: In constructor ‘InstrumentProps::InstrumentProps()’:
mainwindow.cpp:2929:11: error: ‘class Table’ has no member named 
‘set_margin’; did you mean ‘set_halign’?
      table.set_margin(5);
            ^~~~~~~~~~
            set_halign
mainwindow.cpp:2938:15: error: ‘HButtonBox’ {aka ‘class 
Gtk::HButtonBox’} has no member named ‘set_margin’; did you mean 
‘set_halign’?
      buttonBox.set_margin(5);
                ^~~~~~~~~~
                set_halign
mainwindow.cpp: In member function ‘void 
MainWindow::select_instrument(gig::Instrument*)’:
mainwindow.cpp:3457:49: error: ‘Gtk::TreeNodeChildren::value_type’ {aka 
‘class Gtk::TreeRow’} has no member named ‘get_iter’; did you mean 
‘get_stamp’?
              auto iterSel = model->children()[i].get_iter();
                                                  ^~~~~~~~
                                                  get_stamp
mainwindow.cpp: In member function ‘bool 
MainWindow::select_dimension_region(gig::DimensionRegion*)’:
mainwindow.cpp:3487:49: error: ‘Gtk::TreeNodeChildren::value_type’ {aka 
‘class Gtk::TreeRow’} has no member named ‘get_iter’; did you mean 
‘get_stamp’?
              auto iterSel = model->children()[i].get_iter();
                                                  ^~~~~~~~
                                                  get_stamp
mainwindow.cpp: In member function ‘void 
MainWindow::select_sample(gig::Sample*)’:
mainwindow.cpp:3523:55: error: ‘Gtk::TreeNodeChildren::value_type’ {aka 
‘class Gtk::TreeRow’} has no member named ‘get_iter’; did you mean 
‘get_stamp’?
                  auto iterSel = rowGroup.children()[s].get_iter();
                                                        ^~~~~~~~
                                                        get_stamp

what else i might do to make it compile? :-) i have no idea about the 
cause as i know nothing about gtk :-)

miroslav


Dne 2019-01-01 16:47, Christian Schoenebeck napsal:
> On Tuesday, 1. Januar 2019 13:24:31 CET Miroslav Šulc wrote:
>> hi guys,
>> 
>> happy new year! :-)
> 
> Hi and happy new year everyone!
> 
>> yesterday i found some time to find out why svn gigedit does not 
>> compile
>> on my gentoo linux system anymore. i have found that it compiles fine
>> with gtkmm-3.22.2 but it fails with gtkmm-3.24.0. it begins with the
>> following errors and some more follow:
> 
> Actually we put a lot of work so that gigedit compiles with a huge span 
> of gtk
> versions, ranging from ancient gtk 2.x up to latest gtk 4.x development
> version.
> 
> The problem with 2.24.x seems, which I just realized, that the Gtk team 
> have
> changed their general release policy couple months ago. Originally the 
> last
> official release of the gtk 3.x branch was announced to be 3.22.x, 
> everything
> higher was supposed to be development versions for upcoming gtk 4:
> 
> https://blog.gtk.org/2018/06/23/a-gtk-3-update/
> 
> So current gigedit code assumes 3.24.x to be already Gtk 4 API and 
> different
> major Gtk API versions (unlike with Qt) are in general completely 
> incompatible
> with each other.
> 
> I currently don't have gtk 2.24.x installed here, but it should be 
> relatively
> easy to fix. All the gtk version (in)compatiblity issues are handled in 
> source
> file src/gigedit/compat.h. You find a bunch of gtk version checks 
> there, reach
> out for ones that look like this:
> 
> GTK_MAJOR_VERSION == 3 && GTKMM_MINOR_VERSION > 22
> 
> and change them accordingly to
> 
> GTK_MAJOR_VERSION == 3 && GTKMM_MINOR_VERSION > 24
> 
> If you got it working there, do others a favour and send us your patch 
> please!
> 
> CU
> Christian
> 
> 
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] svn gigedit and gtkmm-3.24.0 compilation issue

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

On Tuesday, 1. Januar 2019 13:24:31 CET Miroslav Šulc wrote:
> hi guys,
> 
> happy new year! :-)

Hi and happy new year everyone!

> yesterday i found some time to find out why svn gigedit does not compile
> on my gentoo linux system anymore. i have found that it compiles fine
> with gtkmm-3.22.2 but it fails with gtkmm-3.24.0. it begins with the
> following errors and some more follow:

Actually we put a lot of work so that gigedit compiles with a huge span of gtk 
versions, ranging from ancient gtk 2.x up to latest gtk 4.x development 
version.

The problem with 2.24.x seems, which I just realized, that the Gtk team have 
changed their general release policy couple months ago. Originally the last 
official release of the gtk 3.x branch was announced to be 3.22.x, everything 
higher was supposed to be development versions for upcoming gtk 4:

https://blog.gtk.org/2018/06/23/a-gtk-3-update/

So current gigedit code assumes 3.24.x to be already Gtk 4 API and different 
major Gtk API versions (unlike with Qt) are in general completely incompatible 
with each other.

I currently don't have gtk 2.24.x installed here, but it should be relatively 
easy to fix. All the gtk version (in)compatiblity issues are handled in source 
file src/gigedit/compat.h. You find a bunch of gtk version checks there, reach 
out for ones that look like this:

GTK_MAJOR_VERSION == 3 && GTKMM_MINOR_VERSION > 22

and change them accordingly to

GTK_MAJOR_VERSION == 3 && GTKMM_MINOR_VERSION > 24

If you got it working there, do others a favour and send us your patch please!

CU
Christian

[Linuxsampler-devel] svn gigedit and gtkmm-3.24.0 compilation issue

[Miroslav Š. <for...@fo...>]

hi guys,

happy new year! :-)

yesterday i found some time to find out why svn gigedit does not compile 
on my gentoo linux system anymore. i have found that it compiles fine 
with gtkmm-3.22.2 but it fails with gtkmm-3.24.0. it begins with the 
following errors and some more follow:

In file included from builtinpix.cpp:2:
../compat.h: In constructor ‘HBox::HBox()’:
../compat.h:140:41: error: ‘HORIZONTAL’ is not a member of 
‘Gtk::Orientation’
      HBox() : Gtk::Box(Gtk::Orientation::HORIZONTAL) {}
                                          ^~~~~~~~~~
../compat.h: In constructor ‘VBox::VBox()’:
../compat.h:145:41: error: ‘VERTICAL’ is not a member of 
‘Gtk::Orientation’
      VBox() : Gtk::Box(Gtk::Orientation::VERTICAL) {}
                                          ^~~~~~~~
../compat.h: In constructor ‘HButtonBox::HButtonBox()’:
../compat.h:150:53: error: ‘HORIZONTAL’ is not a member of 
‘Gtk::Orientation’
      HButtonBox() : Gtk::ButtonBox(Gtk::Orientation::HORIZONTAL) {}
                                                      ^~~~~~~~~~
../compat.h: In constructor ‘HScale::HScale()’:
../compat.h:155:45: error: ‘HORIZONTAL’ is not a member of 
‘Gtk::Orientation’
      HScale() : Gtk::Scale(Gtk::Orientation::HORIZONTAL) {}
                                              ^~~~~~~~~~
../compat.h: In constructor ‘HScale::HScale(const 
Glib::RefPtr<Gtk::Adjustment>&)’:
../compat.h:156:104: error: ‘HORIZONTAL’ is not a member of 
‘Gtk::Orientation’
      HScale(const Glib::RefPtr<Gtk::Adjustment>& adjustment) : 
Gtk::Scale(adjustment, Gtk::Orientation::HORIZONTAL) {}
                                                                          
                                ^~~~~~~~~~

i wanted to file a bug in the bugzilla but i don't have account and 
cannot create one :-)

best regards.

miroslav

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

[Ivan M. <iv...@ma...>]

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.

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

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

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

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

[Ivan M. <iv...@ma...>]

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

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

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

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

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

[Ivan M. <iv...@ma...>]

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

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

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

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

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

[Ivan M. <iv...@ma...>]

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

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

[Jaime T <eno...@gm...>]

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

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

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

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

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

[Ivan M. <iv...@ma...>]

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

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

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

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

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

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

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

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

[Ivan M. <iv...@ma...>]

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

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

[Ivan M. <iv...@ma...>]

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

Re: [Linuxsampler-devel] Sustain release velocity & Gigastudio 4

[Ivan M. <iv...@ma...>]

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