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

Re: [Linuxsampler-devel] SVN Gigedit compile errors on Ubuntu Studio 21.04

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

On Freitag, 17. Dezember 2021 10:37:54 CET Andrew C wrote:
> My bad here. I was mixing GTK versions.. Had installed libgtk2.4-dev, when
> I should've installed libgtk-3.0-dev. Gigedit (latest svn) compiles
> absolutely fine now.
> 
> This thread also sheds light on the issue:
> https://bb.linuxsampler.org/viewtopic.php?t=3379

Yes, unfortunately it is not the first time somebody ended up with an 
incompatible set of glib(mm)/gtk(mm) dev package combinations being installed 
and getting compiler errors like these.

As you might imagine, that's not something all Gtk apps out there should be 
obliged to verify by themselves individually. We already have more than enough 
work to support all kinds of Gtk(mm) versions out there. It is not realistic 
that we would even start trying to deal with all possible linear combinations 
of all those individual libs' versions.

If a header file of lib x depends on a certain mininum version of header files 
of lib y, then it should also check for that version and bark with an 
human=end-user readable message like:

   gtkmm 3.10.1 requires at least glibmm 2.50.0, found 2.10.1 though

All those libs already define macros with their exact versions with scheme:

	<LIBNAME>_MAJOR_VERSION
	<LIBNAME>_MINOR_VERSION
	<LIBNAME>_MICRO_VERSION

and they all know which minimum version of another lib they need (or should 
know). So that would not be hard to add such kind of check to their header 
files to stop such tedious issues.

Maybe you find some time to report or for sending patches to them.

CU
Christian

Re: [Linuxsampler-devel] SVN Gigedit compile errors on Ubuntu Studio 21.04

[Andrew C <cou...@gm...>]

My bad here. I was mixing GTK versions.. Had installed libgtk2.4-dev, when
I should've installed libgtk-3.0-dev. Gigedit (latest svn) compiles
absolutely fine now.

This thread also sheds light on the issue:
https://bb.linuxsampler.org/viewtopic.php?t=3379

Andrew.

On Fri, Dec 17, 2021 at 9:06 AM Andrew C <cou...@gm...> wrote:

> Hi, it's me again :)
>
> Getting a compile error with the latest svn version of gigedit on Ubuntu
> Studio 21.04:
>
> In file included from /usr/include/glib-2.0/glib/galloca.h:32,
>                 from /usr/include/glib-2.0/glib.h:30,
>                 from /usr/include/glibmm-2.4/glibmm/unicode.h:23,
>                 from /usr/include/glibmm-2.4/glibmm/ustring.h:21,
>                 from /usr/include/gtkmm-2.4/gtkmm/label.h:7,
>                 from wrapLabel.hh:28,
>                 from wrapLabel.cc:25:
> /usr/include/glib-2.0/glib/gtypes.h:545:26: note: declared here
>  545 | typedef struct _GTimeVal GTimeVal
> GLIB_DEPRECATED_TYPE_IN_2_62_FOR(GDateTime);
>      |                          ^~~~~~~~
> wrapLabel.cc: In constructor ‘view::WrapLabel::WrapLabel(const
> Glib::ustring&)’:
> wrapLabel.cc:69:44: error: ‘WORD_CHAR’ is not a member of ‘Pango::WrapMode’
>
>   69 |    get_layout()->set_wrap(Pango::WrapMode::WORD_CHAR);
>      |                                            ^~~~~~~~~
> make[4]: *** [Makefile:874: libgigedit_la-wrapLabel.lo] Error 1
> make[4]: Leaving directory
> '/home/ubuntu-studio/Downloads/svn/gigedit/src/gigedit'
> make[3]: *** [Makefile:935: all-recursive] Error 1
> make[3]: Leaving directory
> '/home/ubuntu-studio/Downloads/svn/gigedit/src/gigedit'
> make[2]: *** [Makefile:418: all-recursive] Error 1
> make[2]: Leaving directory '/home/ubuntu-studio/Downloads/svn/gigedit/src'
> make[1]: *** [Makefile:468: all-recursive] Error 1
> make[1]: Leaving directory '/home/ubuntu-studio/Downloads/svn/gigedit'
> make: *** [Makefile:398: all] Error 2
>
> Looking at this error, I realise this might be a GTK Library problem,
> rather than specific to Gigedit itself!
>
> On a related note, the latest official release of the Linuxsampler source
> has a compile error, but the latest svn compiles fine (think I may have
> reported that one?)
>
> I'm also seeing alot of "deprecated" due to -Wdeprecated-warning from
> c++11 by default in building libgig/linuxsampler/gigedit from svn.
>
> Thanks,
> Andrew.
>

[Linuxsampler-devel] SVN Gigedit compile errors on Ubuntu Studio 21.04

[Andrew C <cou...@gm...>]

Hi, it's me again :)

Getting a compile error with the latest svn version of gigedit on Ubuntu
Studio 21.04:

In file included from /usr/include/glib-2.0/glib/galloca.h:32,
                from /usr/include/glib-2.0/glib.h:30,
                from /usr/include/glibmm-2.4/glibmm/unicode.h:23,
                from /usr/include/glibmm-2.4/glibmm/ustring.h:21,
                from /usr/include/gtkmm-2.4/gtkmm/label.h:7,
                from wrapLabel.hh:28,
                from wrapLabel.cc:25:
/usr/include/glib-2.0/glib/gtypes.h:545:26: note: declared here
 545 | typedef struct _GTimeVal GTimeVal
GLIB_DEPRECATED_TYPE_IN_2_62_FOR(GDateTime);
     |                          ^~~~~~~~
wrapLabel.cc: In constructor ‘view::WrapLabel::WrapLabel(const
Glib::ustring&)’:
wrapLabel.cc:69:44: error: ‘WORD_CHAR’ is not a member of ‘Pango::WrapMode’
  69 |    get_layout()->set_wrap(Pango::WrapMode::WORD_CHAR);
     |                                            ^~~~~~~~~
make[4]: *** [Makefile:874: libgigedit_la-wrapLabel.lo] Error 1
make[4]: Leaving directory
'/home/ubuntu-studio/Downloads/svn/gigedit/src/gigedit'
make[3]: *** [Makefile:935: all-recursive] Error 1
make[3]: Leaving directory
'/home/ubuntu-studio/Downloads/svn/gigedit/src/gigedit'
make[2]: *** [Makefile:418: all-recursive] Error 1
make[2]: Leaving directory '/home/ubuntu-studio/Downloads/svn/gigedit/src'
make[1]: *** [Makefile:468: all-recursive] Error 1
make[1]: Leaving directory '/home/ubuntu-studio/Downloads/svn/gigedit'
make: *** [Makefile:398: all] Error 2

Looking at this error, I realise this might be a GTK Library problem,
rather than specific to Gigedit itself!

On a related note, the latest official release of the Linuxsampler source
has a compile error, but the latest svn compiles fine (think I may have
reported that one?)

I'm also seeing alot of "deprecated" due to -Wdeprecated-warning from c++11
by default in building libgig/linuxsampler/gigedit from svn.

Thanks,
Andrew.

Re: [Linuxsampler-devel] akaiextract loop start <-> loop end

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

On Dienstag, 16. November 2021 19:38:44 CET Kolja Koch wrote:
> > Looks like data corruption to me. Akai sounds are decades old. On what
> > medium did you have that Akai sound stored on; HD, burned vs. pressed
> > CDROM?
> The sounds come from an AKAI-image with looped brass-sounds. I don't really
> use these, just for testing purpose. It took me a while to see that the
> issues I had were not in my gig-creation, but in those wav-files instead...
> I managed to use some other wav-files containing loop information, those
> work as expected.

In all these years there were only a hand full of people that still wanted to 
access their old Akai sounds, because you would barely find a sound library in 
Akai format that would sound good enough even for standards 20 years ago.

I also still own numerous Akai CDs and Akai hardware sampler, but I haven't 
touched them in years. I once had plans to add support for S5000/S6000 format 
as well, but figured who would need that apart from nostalgic look backs.

> Since I don't own any other means of testing the AKAI-image, I cannot tell,
> how they would 'originally' sound when looped.

Like I said: you can visually see where the loop points are supposed to be, 
without even listening to them. When you open the wave in a wave editor you 
should easily be able to see two sections in the wave form that look 
identical.

Exceptions are typically synthetic sounds, e.g. sampled FM synths, as well as 
a bunch of thin analague synth sounds which have an almost static wave form 
throughout the entire sample, but natural sounds (like your brass sounds) 
typically have a high variance in their wave form, so those almost identical 
two loop sections of the two loop points visually pop out.

> Data corruption could theoretically be, though I didn't notice any other
> problems with those files,  only loop-start and -end and, consistent for
> all files I tested, those values would, theoretically, make sense when
> swapped.

Bit rot are very seldom bit flips that appear over years. It is not like that 
you would have several bit flips in a row or somewhere nearby. The next bit 
flip is usually various MBs or even GBs away. So data degradation in general 
is a very subtle and slow phenomenon, especially on uncompressed data like 
this one.

At most you might hear a pop sound somewhere in any of the samples. I 
encountered corrupt samples with such pop symptoms numerous times in the past, 
but it took me a while to actually realize, i.e. hear those issues back then. 
So there were good reasons why I revived the CRC32 checksum feature in the gig 
format and our tools, as it is not realistic to (re)verify sound libs by ears. 
These features will be extended in Gigedit was well.

> I don't know the details of how the data is stored in that filesystem but

Well, you know on which medium you have stored them on. I bet you have stored 
them as Akai image files on some ancient mechanical HD, which in turn would 
certainly have an ancient Linux or Windows file system, i.e. without self-
healing features.

If you even have it stored on a native Akai HD, same thing: all their 
filesystems were way more primitive. No self-healing.

> would assume it to be a very specific data corruption. Anyway, as I said,
> besides for testing my software I don't use these files, so that would have
> been more of an academic interest to me.

Exactly, same applies to all Akai owners I guess. :)

> > In general I highly recommend to use a modern filesystem (e.g. btrfs, ZFS)
> > nowadays with appropriate self-healing feature to prevent things like bit
> > rotting [1], especially for long-term storage.
> 
> Thanks for the advice, I will definitely keep that in mind!
> 
> 
> Cheers,
> Kolja

CU
Christian

Re: [Linuxsampler-devel] akaiextract loop start <-> loop end

[Kolja K. <ko...@fr...>]

> 
> Looks like data corruption to me. Akai sounds are decades old. On what medium 
> did you have that Akai sound stored on; HD, burned vs. pressed CDROM?
> 
The sounds come from an AKAI-image with looped brass-sounds. I don't really use these, just for testing purpose.
It took me a while to see that the issues I had were not in my gig-creation, but in those wav-files instead...
I managed to use some other wav-files containing loop information, those work as expected.

Since I don't own any other means of testing the AKAI-image, I cannot tell, how they would 'originally' sound when looped.

Data corruption could theoretically be, though I didn't notice any other problems with those files, 
only loop-start and -end and, consistent for all files I tested, those values would, theoretically,
make sense when swapped.
I don't know the details of how the data is stored in that filesystem but would assume it to be a very specific data corruption.
Anyway, as I said, besides for testing my software I don't use these files, so that would have been more of an academic interest to me.

> In general I highly recommend to use a modern filesystem (e.g. btrfs, ZFS) 
> nowadays with appropriate self-healing feature to prevent things like bit 
> rotting [1], especially for long-term storage.

Thanks for the advice, I will definitely keep that in mind!


Cheers,
Kolja

Re: [Linuxsampler-devel] akaiextract loop start <-> loop end

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

On Montag, 15. November 2021 15:46:27 CET Kolja Koch wrote:
> Hi,
> while working with some wav-files extracted by akaiextract, I noticed that
> the information for loop-start and loop-end stored in the sfinst of the
> wav-files seem to be in swapped order. Example:
> 
> MIDIUnityNote: 41
> Channels: 1
> SamplesPerSecond: 44100
> BitDepth: 16
> FrameSize: 2
> Frames: 176565
> MIDIUnityNote: 41
> FineTune: 0
> Loops: yes
> LoopType: 0
> LoopStart: 175036
> LoopEnd: 113915
> LoopPlayCount: 0
> LoopSize: -61120
> 
> LoopStart is higher then LoopEnd, thus LoopSize is calculated wrong.

Looks like data corruption to me. Akai sounds are decades old. On what medium 
did you have that Akai sound stored on; HD, burned vs. pressed CDROM?

In general I highly recommend to use a modern filesystem (e.g. btrfs, ZFS) 
nowadays with appropriate self-healing feature to prevent things like bit 
rotting [1], especially for long-term storage.

[1] https://en.wikipedia.org/wiki/Data_degradation

> I didn't see this in any other looped sample I worked with yet (e.g. when
> extracted from a working gig-file using gigextract).
> 
> Has anyone else seen this?
> 
> When swapping those numbers, the loop plays, though glitches appear.

Usually you can simply open the wave in a sample editor and literally see 
where the loop points are, especially with such small samples as in the Akai 
format.

CU
Christian

[Linuxsampler-devel] akaiextract loop start <-> loop end

[Kolja K. <ko...@fr...>]

Hi,
while working with some wav-files extracted by akaiextract, I noticed that the information for loop-start and loop-end stored in the sfinst of the wav-files seem to be in swapped order.
Example:

MIDIUnityNote: 41
Channels: 1
SamplesPerSecond: 44100
BitDepth: 16
FrameSize: 2
Frames: 176565
MIDIUnityNote: 41
FineTune: 0
Loops: yes
LoopType: 0
LoopStart: 175036
LoopEnd: 113915
LoopPlayCount: 0
LoopSize: -61120

LoopStart is higher then LoopEnd, thus LoopSize is calculated wrong.

I didn't see this in any other looped sample I worked with yet (e.g. when extracted from a working gig-file using gigextract).

Has anyone else seen this?

When swapping those numbers, the loop plays, though glitches appear.

Cheers,
Kolja

Re: [Linuxsampler-devel] gigedit crashes when creating ne gig-file. pango/gtkmm3?

[Kolja K. <ko...@fr...>]

> So there is not any of our code actually involved in the crash, at least not 
> directly. Could be related to this:
> 
> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1898082
> 
> libglimm was trying to log some message by calling g_log(), and the latter 
> eventually crashed. That's very odd, but it does not look like the bug was 
> anywhere on our side. It appears this is rather a (relatively) new bug in 
> either libglibmm or glib. Would require to recompile those with debugging 
> turned on to learn more.

Ok, thanks for investigating that so far! I took a quick look into that.
It currently seems like a dead end for me, since I don't want to fiddle too much with those right now.
I'll eventually investigate that issue later on.

> There is also "gigdump --verify foo.gig" from the command line BTW
> (man gigdump).

Thanks again for pointing that out! By using that, I identified some problems with my gig-files that seem to be related to merging mono into stereo-samples.
I guess, I'll have to look a little bit deeper into your gig2stereo-code and implement some of your checks and methods from there...

Cheers,
Kolja

Re: [Linuxsampler-devel] gigedit crashes when creating ne gig-file. pango/gtkmm3?

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

On Sonntag, 14. November 2021 20:56:49 CET Kolja Koch wrote:
> Ran gigedit using gdb, loaded one sample, assigned it to one region and
> saved the gig. It crashed. I then saved the attached
> 'gigedit_trace_all_debug_on_2021_11_14.log'
> 
> Looks quite like the other one to me...
> 
> Next, I recompiled gigedit manually with
> CXXFLAGS="-O0 -g3" ./configure && make
> 
> and ran
> libtool --mode=execute gdb --arg src/gigedit/gigedit
> 
> After the crash, I typed
> bt
> 
> and got:
> 
> #0  0x00007ffff631c200 in g_log_structured_array () at
> /usr/lib/libglib-2.0.so.0 #1  0x00007ffff631c4c6 in g_log_default_handler
> () at /usr/lib/libglib-2.0.so.0 #2  0x00007ffff631d8fd in g_logv () at
> /usr/lib/libglib-2.0.so.0
> #3  0x00007ffff631dc00 in g_log () at /usr/lib/libglib-2.0.so.0
> #4  0x00007ffff720ba4a in  () at /usr/lib/libglibmm-2.4.so.1
> #5  0x00007ffff720bce8 in  () at /usr/lib/libglibmm-2.4.so.1
> #6  0x00007ffff722655c in Glib::IOSource::dispatch(sigc::slot_base*) () at
> /usr/lib/libglibmm-2.4.so.1 #7  0x00007ffff721f7d7 in
> Glib::Source::dispatch_vfunc(_GSource*, int (*)(void*), void*) () at
> /usr/lib/libglibmm-2.4.so.1 #8  0x00007ffff63153e5 in
> g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #9 
> 0x00007ffff6369799 in  () at /usr/lib/libglib-2.0.so.0
> #10 0x00007ffff6314a63 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
> #11 0x00007ffff6bcd88f in gtk_main () at /usr/lib/libgtk-3.so.0
> #12 0x00007ffff7e527ee in GigEdit::run(int, char**)
> (this=this@entry=0x7fffffffe330, argc=<optimized out>, argc@entry=1,
> argv=<optimized out>, argv@entry=0x7fffffffe538) at gigedit.cpp:416
> #13 0x0000555555555084 in main(int, char**) (argc=1, argv=0x7fffffffe538) at
> main.cpp:53

So there is not any of our code actually involved in the crash, at least not 
directly. Could be related to this:

https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1898082

libglimm was trying to log some message by calling g_log(), and the latter 
eventually crashed. That's very odd, but it does not look like the bug was 
anywhere on our side. It appears this is rather a (relatively) new bug in 
either libglibmm or glib. Would require to recompile those with debugging 
turned on to learn more.

CU
Christian

Re: [Linuxsampler-devel] pango/gtkmm3?

[Kolja K. <ko...@fr...>]

> 
> Ok, I hope I nailed this issue now with latest commit:
> http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4000
> 
> 
Uuuh, so we work in parallel! :)
Cool, I just tested it by installing gigedit-svn without any changes to the package: It worked like a charm!
Great, thanks a lot! :)

Cheers,
kolja

Re: [Linuxsampler-devel] gigedit crashes when creating ne gig-file. pango/gtkmm3?

[Kolja K. <ko...@fr...>]

> You need to compile libgig and gigedit with debugging symbols turned on for 
> the backtrace to contain the required information like function name, source 
> file line number, function arguments passed, etc.:
> 
>         https://bugs.linuxsampler.org/
> 
> If you are installing libgig by some distro/package script then also make sure 
> it does not 'strip' the binaries, otherwise it renders the backtrace output 
> useless again.
> 
I (thought I) did that, but only with debug-symbols for gigedit.

Now I did the following:
- Uninstalled libgig, gigedit, linuxsampler
- reinstalled them using the svn-versions from Archlinux AUR:
	- added 'options=(debug !strip)' to all of them, as of https://wiki.archlinux.org/title/Debugging
	- libgig: https://aur.archlinux.org/packages/libgig-svn/
	- linuxsampler: https://aur.archlinux.org/packages/linuxsampler-svn/
		- removed dependencies for Steinberg's VST-SDK (link to http://www.steinberg.net/sdk_downloads/vstsdk366_27_06_2016_build_61.zip seems to be dead, I don't use that anyway)
	- gigedit: https://aur.archlinux.org/packages/gigedit-svn/
		- applied the already mentioned patches

Ran gigedit using gdb, loaded one sample, assigned it to one region and saved the gig. It crashed. I then saved the attached 'gigedit_trace_all_debug_on_2021_11_14.log'

Looks quite like the other one to me...

Next, I recompiled gigedit manually with 
CXXFLAGS="-O0 -g3" ./configure && make

and ran 
libtool --mode=execute gdb --arg src/gigedit/gigedit

After the crash, I typed 
bt

and got:

#0  0x00007ffff631c200 in g_log_structured_array () at /usr/lib/libglib-2.0.so.0
#1  0x00007ffff631c4c6 in g_log_default_handler () at /usr/lib/libglib-2.0.so.0
#2  0x00007ffff631d8fd in g_logv () at /usr/lib/libglib-2.0.so.0
#3  0x00007ffff631dc00 in g_log () at /usr/lib/libglib-2.0.so.0
#4  0x00007ffff720ba4a in  () at /usr/lib/libglibmm-2.4.so.1
#5  0x00007ffff720bce8 in  () at /usr/lib/libglibmm-2.4.so.1
#6  0x00007ffff722655c in Glib::IOSource::dispatch(sigc::slot_base*) () at /usr/lib/libglibmm-2.4.so.1
#7  0x00007ffff721f7d7 in Glib::Source::dispatch_vfunc(_GSource*, int (*)(void*), void*) () at /usr/lib/libglibmm-2.4.so.1
#8  0x00007ffff63153e5 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#9  0x00007ffff6369799 in  () at /usr/lib/libglib-2.0.so.0
#10 0x00007ffff6314a63 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#11 0x00007ffff6bcd88f in gtk_main () at /usr/lib/libgtk-3.so.0
#12 0x00007ffff7e527ee in GigEdit::run(int, char**) (this=this@entry=0x7fffffffe330, argc=<optimized out>, argc@entry=1, argv=<optimized out>, 
    argv@entry=0x7fffffffe538) at gigedit.cpp:416
#13 0x0000555555555084 in main(int, char**) (argc=1, argv=0x7fffffffe538) at main.cpp:53


Cheers,
Kolja

Re: [Linuxsampler-devel] gigedit crashes when creating ne gig-file. pango/gtkmm3?

[Kolja K. <ko...@fr...>]

> You need to compile libgig and gigedit with debugging symbols turned on for 
> the backtrace to contain the required information like function name, source 
> file line number, function arguments passed, etc.:
> 
>         https://bugs.linuxsampler.org/
> 
> If you are installing libgig by some distro/package script then also make sure 
> it does not 'strip' the binaries, otherwise it renders the backtrace output 
> useless again.
> 
I (thought I) did that, but only with debug-symbols for gigedit.

Now I did the following:
- Uninstalled libgig, gigedit, linuxsampler
- reinstalled them using the svn-versions from Archlinux AUR:
	- added 'options=(debug !strip)' to all of them, as of https://wiki.archlinux.org/title/Debugging
	- libgig: https://aur.archlinux.org/packages/libgig-svn/
	- linuxsampler: https://aur.archlinux.org/packages/linuxsampler-svn/
		- removed dependencies for Steinberg's VST-SDK (link to http://www.steinberg.net/sdk_downloads/vstsdk366_27_06_2016_build_61.zip seems to be dead, I don't use that anyway)
	- gigedit: https://aur.archlinux.org/packages/gigedit-svn/
		- applied the already mentioned patches

Ran gigedit using gdb, loaded one sample, assigned it to one region and saved the gig. It crashed. I then saved the attached 'gigedit_trace_all_debug_on_2021_11_14.log'

Looks quite like the other one to me...

Next thing I'll do is compile libgig and gigedit as mentioned in your link above.

Cheers,
Kolja

Re: [Linuxsampler-devel] pango/gtkmm3?

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

On Sonntag, 14. November 2021 18:09:00 CET Kolja Koch wrote:
> > All those things are not likely being related with the crash you got
> > though.
> Ok, so I'll split this up into two separated mails then...
> 
> > The other patch gigedit-1.2.0-redeclare.patch tries to address the
> > compilation error that you get, but it does not really do that correctly.
> > It should rather be addressed in compat.h here instead:
> > 
> > #ifndef HAS_PANGOMM_CPP11_ENUMS
> >    // new enums introduced in unstable pangomm 2.41.3, but not in stable
> > 2.42 # if PANGOMM_MAJOR_VERSION > 2 || (PANGOMM_MAJOR_VERSION == 2 &&
> > ((PANGOMM_MINOR_VERSION == 41 && PANGOMM_MICRO_VERSION >= 3) ||
> > PANGOMM_MINOR_VERSION > 42))
> > #  define HAS_PANGOMM_CPP11_ENUMS 1
> > # else
> > #  define HAS_PANGOMM_CPP11_ENUMS 0
> > # endif
> > #endif
> > 
> > What is the exact pangomm version reported to be installed there? Because
> > that pangomm version issue was indeed always a bit fishy. As you can see
> > from the compat.h comment above, they had a weird version scheme (stable
> > vs. unstable pangomm, new features branch vs. maintenance branch). So
> > that's something I should fix here more cleanly on our side.
> 
> My package-manager states:
> 
> Name            : pangomm
> Version         : 2.46.1-2
> Description     : C++ bindings for Pango
> Architecture    : x86_64
> URL             : https://www.gtkmm.org/
> Licenses        : LGPL
> Groups          : None
> Provides        : libpangomm-1.4.so=1-64
> 
> Does this help you?

Ok, I hope I nailed this issue now with latest commit:
http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4000

> I reinstalled gigedit from svn using the patch, that does seem to work,
> though it still crashes when trying to save after inserting a single
> sample. I'll follow up on that in a separate mail.

Yeah, completely unrelated things. This enum issue did definitely not cause 
the crash you got there.

CU
Christian

Re: [Linuxsampler-devel] gigedit crashes when creating ne gig-file. pango/gtkmm3?

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

On Sonntag, 14. November 2021 18:50:13 CET Kolja Koch wrote:
> > There is also "gigdump --verify foo.gig" from the command line BTW
> > (man gigdump).
> 
> Good to know, thanks!
> 
> > > > You could start by providing the questioned info, plus a backtrace of
> > > > the
> > > > crash.
> 
> I've never done that before. Is the attached trace.log what you mean?
> I really can't tell if this is useful to anyone...
> 
> Cheers,
> Kolja

You need to compile libgig and gigedit with debugging symbols turned on for 
the backtrace to contain the required information like function name, source 
file line number, function arguments passed, etc.:

	https://bugs.linuxsampler.org/

If you are installing libgig by some distro/package script then also make sure 
it does not 'strip' the binaries, otherwise it renders the backtrace output 
useless again.

CU
Christian

Re: [Linuxsampler-devel] gigedit crashes when creating ne gig-file. pango/gtkmm3?

[Kolja K. <ko...@fr...>]

> 
> There is also "gigdump --verify foo.gig" from the command line BTW
> (man gigdump).
> 
Good to know, thanks!
> 
> > > You could start by providing the questioned info, plus a backtrace of the
> > > crash.
> > 
I've never done that before. Is the attached trace.log what you mean?
I really can't tell if this is useful to anyone...

Cheers,
Kolja

Re: [Linuxsampler-devel] pango/gtkmm3?

[Kolja K. <ko...@fr...>]

> All those things are not likely being related with the crash you got though.
Ok, so I'll split this up into two separated mails then...

> The other patch gigedit-1.2.0-redeclare.patch tries to address the compilation 
> error that you get, but it does not really do that correctly. It should rather 
> be addressed in compat.h here instead:
> 
> #ifndef HAS_PANGOMM_CPP11_ENUMS
>    // new enums introduced in unstable pangomm 2.41.3, but not in stable 2.42
> # if PANGOMM_MAJOR_VERSION > 2 || (PANGOMM_MAJOR_VERSION == 2 && 
> ((PANGOMM_MINOR_VERSION == 41 && PANGOMM_MICRO_VERSION >= 3) || 
> PANGOMM_MINOR_VERSION > 42))
> #  define HAS_PANGOMM_CPP11_ENUMS 1
> # else
> #  define HAS_PANGOMM_CPP11_ENUMS 0
> # endif
> #endif
> 
> What is the exact pangomm version reported to be installed there? Because that 
> pangomm version issue was indeed always a bit fishy. As you can see from the 
> compat.h comment above, they had a weird version scheme (stable vs. unstable 
> pangomm, new features branch vs. maintenance branch). So that's something I 
> should fix here more cleanly on our side.

My package-manager states:

Name            : pangomm
Version         : 2.46.1-2
Description     : C++ bindings for Pango
Architecture    : x86_64
URL             : https://www.gtkmm.org/
Licenses        : LGPL
Groups          : None
Provides        : libpangomm-1.4.so=1-64

Does this help you?
I reinstalled gigedit from svn using the patch, that does seem to work, though it still crashes when trying to save after inserting a single sample.
I'll follow up on that in a separate mail.

Cheers,
Kolja

Re: [Linuxsampler-devel] gigedit crashes when creating ne gig-file. pango/gtkmm3?

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

On Freitag, 12. November 2021 12:17:16 CET Kolja Koch wrote:
> > Which makes me wonder why I don't get these GTK compiler errors with the
> > same gtk(mm) 3.24.5 version. Are you sure you are compiling against the
> > header files of exactly *that* gtk version and not probably against
> > header files of gtk(mm) 4.x? Because gtk4 is not supported, gtk2 and gtk3
> > are though.
> Looks like gtkmm-3.0 to me:
> 
> configure:20453: g++ -std=gnu++11 -c -g -O2 -I/usr/include/gtkmm-3.0
> -I/usr/lib/gtkmm-3.0/include -I/usr/include/giomm-2.4
> -I/usr/lib/giomm-2.4/include -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid
> -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include
> -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include
> -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz
> -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/fribidi
> -I/usr/include/cairo -I/usr/include/lzo -I/usr/include/pixman-1
> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0
> -I/usr/include/cloudproviders -I/usr/include/atk-1.0
> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/dbus-1.0
> -I/usr/lib/dbus-1.0/include -I/usr/include/at-spi-2.0
> -I/usr/include/cairomm-1.0 -I/usr/lib/cairomm-1.0/include
> -I/usr/include/pangomm-1.4 -I/usr/lib/pangomm-1.4/include
> -I/usr/include/atkmm-1.6 -I/usr/lib/atkmm-1.6/include
> -I/usr/include/gtk-3.0/unix-print -I/usr/include/gdkmm-3.0
> -I/usr/lib/gdkmm-3.0/include -pthread   conftest.cpp >&5
> 
> 
> GTKMM_LIBS='-lgtkmm-3.0 -latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lgtk-3 -lgdk-3
> -lz -latk-1.0 -lcairo-gobject -lgio-2.0 -lpangomm-1.4 -lglibmm-2.4
> -lcairomm-1.0 -lsigc-2.0 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lcairo
> -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 '
> 
> GTK_CFLAGS='-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/harfbuzz
> -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount
> -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo
> -I/usr/include/lzo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0
> -I/usr/include/gio-unix-2.0 -I/usr/include/cloudproviders
> -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0
> -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include
> -I/usr/include/at-spi-2.0 -pthread '
> 
> Or am I missing something?
> I'm a little bit confused that it states gtkmm-3.0, although my
> package-management states gtkmm3 version 3.24.5-2

Ok, that's probably fine, i.e. it was presumably Gtk 3.24.5 as you said 
before. It is normal for the gtkmm header files being placed into a "gktm-3.0" 
directory. That seems to be consistent among distros.

> > What compiler and compiler version (see config.log file)?
> 
> g++ (GCC) 11.1.0

Ok, then probably not an issue in this case, but good to know.

> > > I managed to install gigedit by applying two patches:
> > > 
> > > gigedit-1.2.0-libdir.patch
> > > gigedit-1.2.0-redeclare.patch
> > > 
> > > but have no clue, what exactly it is they're doing....
> > 
> > Me neither. You are only posting patch names, but not the URL where you
> > got
> > them from.
> 
> Since installing gigedit-svn from archlinux' AUR didn't work, I looked into
> the PKGBUILD of the 'official' package 
> https://archlinux.org/packages/community/x86_64/gigedit/
> Here's the link to the corresponding github-directory including the patches:
> https://github.com/archlinux/svntogit-community/tree/packages/gigedit/trunk
> 
> The PKGBUILD states:
> 
> # install shared object to global namespace, so no ld.so.conf is required
> patch -Np1 -i ../"${pkgname}-1.2.0-libdir.patch"
> # do not extend the pango namespace (breaks the build)
> patch -Np1 -i ../"${pkgname}-1.2.0-redeclare.patch"

So gigedit-1.2.0-libdir.patch just changes the installation directory for 
gigedit. Some distros want to have certain libs installed like this:

	/usr/lib/libname-version/*.so

and others like this:

	/usr/lib/*.so

And that patch changes it to the latter. Should not be an issue.

The other patch gigedit-1.2.0-redeclare.patch tries to address the compilation 
error that you get, but it does not really do that correctly. It should rather 
be addressed in compat.h here instead:

#ifndef HAS_PANGOMM_CPP11_ENUMS
   // new enums introduced in unstable pangomm 2.41.3, but not in stable 2.42
# if PANGOMM_MAJOR_VERSION > 2 || (PANGOMM_MAJOR_VERSION == 2 && 
((PANGOMM_MINOR_VERSION == 41 && PANGOMM_MICRO_VERSION >= 3) || 
PANGOMM_MINOR_VERSION > 42))
#  define HAS_PANGOMM_CPP11_ENUMS 1
# else
#  define HAS_PANGOMM_CPP11_ENUMS 0
# endif
#endif

What is the exact pangomm version reported to be installed there? Because that 
pangomm version issue was indeed always a bit fishy. As you can see from the 
compat.h comment above, they had a weird version scheme (stable vs. unstable 
pangomm, new features branch vs. maintenance branch). So that's something I 
should fix here more cleanly on our side.

All those things are not likely being related with the crash you got though.

> > The CRC-32 checksum of each sample in a .gig file are generated/updated
> > only at the end of the .gig file saving process. So it is normal that new
> > samples first have a CRC initialized with ffffffff at first.
> 
> Ah, ok!

There is also "gigdump --verify foo.gig" from the command line BTW
(man gigdump).

> > > Are those issues related to each other?
> > > - My guess is no.
> > > Does anybody has an idea, what the root-cause might be?
> > 
> > As my telepathic abilities are just sub average, and my valueable crystal
> > ball has never been handed back to me, I fear you would need to provide
> > more info that a mortal person would be able to decode.
> 
> That's a shame! Maybe, you should have asked the crystal ball, before giving
> it away, if you will ever get it back? ;)

Yes, I clearly failed as a user.

> > You could start by providing the questioned info, plus a backtrace of the
> > crash.
> 
> I will try to gather some more information next week and follow up on this.
> Thanks and have a nice weekend!

Sure, thanks, have a good one!

CU
Christian

Re: [Linuxsampler-devel] gigedit crashes when creating ne gig-file. pango/gtkmm3?

[Kolja K. <ko...@fr...>]

> Which makes me wonder why I don't get these GTK compiler errors with the same 
> gtk(mm) 3.24.5 version. Are you sure you are compiling against the header 
> files of exactly *that* gtk version and not probably against header files of 
> gtk(mm) 4.x? Because gtk4 is not supported, gtk2 and gtk3 are though.
Looks like gtkmm-3.0 to me:

configure:20453: g++ -std=gnu++11 -c -g -O2 -I/usr/include/gtkmm-3.0 -I/usr/lib/gtkmm-3.0/include -I/usr/include/giomm-2.4 -I/usr/lib/giomm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/lzo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cloudproviders -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/at-spi-2.0 -I/usr/include/cairomm-1.0 -I/usr/lib/cairomm-1.0/include -I/usr/include/pangomm-1.4 -I/usr/lib/pangomm-1.4/include -I/usr/include/atkmm-1.6 -I/usr/lib/atkmm-1.6/include -I/usr/include/gtk-3.0/unix-print -I/usr/include/gdkmm-3.0 -I/usr/lib/gdkmm-3.0/include -pthread   conftest.cpp >&5


GTKMM_LIBS='-lgtkmm-3.0 -latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lgtk-3 -lgdk-3 -lz -latk-1.0 -lcairo-gobject -lgio-2.0 -lpangomm-1.4 -lglibmm-2.4 -lcairomm-1.0 -lsigc-2.0 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lcairo -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 '

GTK_CFLAGS='-I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/lzo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cloudproviders -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/at-spi-2.0 -pthread '

Or am I missing something?
I'm a little bit confused that it states gtkmm-3.0, although my package-management states gtkmm3 version 3.24.5-2

> What compiler and compiler version (see config.log file)?
g++ (GCC) 11.1.0

> > I managed to install gigedit by applying two patches:
> > 
> > gigedit-1.2.0-libdir.patch
> > gigedit-1.2.0-redeclare.patch
> > 
> > but have no clue, what exactly it is they're doing....
> 
> Me neither. You are only posting patch names, but not the URL where you got 
> them from.
Since installing gigedit-svn from archlinux' AUR didn't work, I looked into the PKGBUILD of the 'official' package 
https://archlinux.org/packages/community/x86_64/gigedit/
Here's the link to the corresponding github-directory including the patches:
https://github.com/archlinux/svntogit-community/tree/packages/gigedit/trunk

The PKGBUILD states:

# install shared object to global namespace, so no ld.so.conf is required
patch -Np1 -i ../"${pkgname}-1.2.0-libdir.patch"
# do not extend the pango namespace (breaks the build)
patch -Np1 -i ../"${pkgname}-1.2.0-redeclare.patch"


> The CRC-32 checksum of each sample in a .gig file are generated/updated only
> at the end of the .gig file saving process. So it is normal that new samples 
> first have a CRC initialized with ffffffff at first. 
Ah, ok!

> > Are those issues related to each other?
> > - My guess is no.
> > Does anybody has an idea, what the root-cause might be?
> 
> As my telepathic abilities are just sub average, and my valueable crystal ball 
> has never been handed back to me, I fear you would need to provide more info 
> that a mortal person would be able to decode.
That's a shame! Maybe, you should have asked the crystal ball, before giving it away, if you will ever get it back? ;)

> You could start by providing the questioned info, plus a backtrace of the 
> crash.

I will try to gather some more information next week and follow up on this.
Thanks and have a nice weekend!

Cheers,
Kolja

Re: [Linuxsampler-devel] gigedit crashes when creating ne gig-file. pango/gtkmm3?

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

On Donnerstag, 11. November 2021 10:44:01 CET Kolja Koch wrote:
> Hi all,
> 
> while testing some newly created gig-files I ran into some problems with
> gigedit. I think, this might have something to do with my installation of
> it.
> 
> When trying to install tha latest gegedit version (1.2.0), running
> ./configure
> runs alright, but then make will give:
> 
> In file included from builtinpix.cpp:2:
> ../compat.h:194:21: error: ‘const Pango::Alignment Pango::ALIGN_LEFT’
> redeclared as different kind of entity 194 |     const Alignment ALIGN_LEFT
> = Alignment::LEFT;
> 
>       |                     ^~~~~~~~~~
> 
> In file included from /usr/include/gtkmm-3.0/gtkmm/widget.h:32,
>                  from /usr/include/gtkmm-3.0/gtkmm/container.h:28,
>                  from /usr/include/gtkmm-3.0/gtkmm/box.h:27,
>                  from /usr/include/gtkmm-3.0/gtkmm/buttonbox.h:27,
>                  from ../compat.h:134,
>                  from builtinpix.cpp:2:
> /usr/include/pangomm-1.4/pangomm/layout.h:77:3: note: previous declaration
> ‘Pango::Alignment Pango::ALIGN_LEFT’ 77 |   ALIGN_LEFT,
> 
>       |   ^~~~~~~~~~
> 
> In file included from builtinpix.cpp:2:
> ../compat.h:194:45: error: ‘LEFT’ is not a member of ‘Pango::Alignment’
>   194 |     const Alignment ALIGN_LEFT = Alignment::LEFT;
> 
>       |                                             ^~~~
> 
> ../compat.h:195:21: error: ‘const Pango::Alignment Pango::ALIGN_CENTER’
> redeclared as different kind of entity 195 |     const Alignment
> ALIGN_CENTER = Alignment::CENTER;
> 
>       |                     ^~~~~~~~~~~~
> 
> In file included from /usr/include/gtkmm-3.0/gtkmm/widget.h:32,
>                  from /usr/include/gtkmm-3.0/gtkmm/container.h:28,
>                  from /usr/include/gtkmm-3.0/gtkmm/box.h:27,
>                  from /usr/include/gtkmm-3.0/gtkmm/buttonbox.h:27,
>                  from ../compat.h:134,
>                  from builtinpix.cpp:2:
> /usr/include/pangomm-1.4/pangomm/layout.h:78:3: note: previous declaration
> ‘Pango::Alignment Pango::ALIGN_CENTER’ 78 |   ALIGN_CENTER,
> 
>       |   ^~~~~~~~~~~~
> 
> In file included from builtinpix.cpp:2:
> ../compat.h:195:47: error: ‘CENTER’ is not a member of ‘Pango::Alignment’
>   195 |     const Alignment ALIGN_CENTER = Alignment::CENTER;
> 
>       |                                               ^~~~~~
> 
> ../compat.h:196:21: error: ‘const Pango::Alignment Pango::ALIGN_RIGHT’
> redeclared as different kind of entity 196 |     const Alignment
> ALIGN_RIGHT = Alignment::RIGHT;
> 
>       |                     ^~~~~~~~~~~
> 
> In file included from /usr/include/gtkmm-3.0/gtkmm/widget.h:32,
>                  from /usr/include/gtkmm-3.0/gtkmm/container.h:28,
>                  from /usr/include/gtkmm-3.0/gtkmm/box.h:27,
>                  from /usr/include/gtkmm-3.0/gtkmm/buttonbox.h:27,
>                  from ../compat.h:134,
>                  from builtinpix.cpp:2:
> /usr/include/pangomm-1.4/pangomm/layout.h:79:3: note: previous declaration
> ‘Pango::Alignment Pango::ALIGN_RIGHT’ 79 |   ALIGN_RIGHT
> 
>       |   ^~~~~~~~~~~
> 
> In file included from builtinpix.cpp:2:
> ../compat.h:196:46: error: ‘RIGHT’ is not a member of ‘Pango::Alignment’
>   196 |     const Alignment ALIGN_RIGHT = Alignment::RIGHT;
> 
> 
> 
> I'm on archlinux using
> gtkmm3 version 3.24.5-2
> and libgig from svn.

Which makes me wonder why I don't get these GTK compiler errors with the same 
gtk(mm) 3.24.5 version. Are you sure you are compiling against the header 
files of exactly *that* gtk version and not probably against header files of 
gtk(mm) 4.x? Because gtk4 is not supported, gtk2 and gtk3 are though.

What compiler and compiler version (see config.log file)?

> I managed to install gigedit by applying two patches:
> 
> gigedit-1.2.0-libdir.patch
> gigedit-1.2.0-redeclare.patch
> 
> but have no clue, what exactly it is they're doing....

Me neither. You are only posting patch names, but not the URL where you got 
them from.

> So far, so good.
> But when trying to create a new gig -file with a sample and save it, gigedit
> will crash with:
> 
> ** (gigedit:23922): ERROR **: 09:46:52.773:
> unhandled exception (type unknown) in signal handler
> 
> A gig-file is created though and I can load that into linuxsampler, but it
> wont play. Opening it in gigedit again will show
> Wav Data CRC-32: ffffffff
> so my guess is, the crash appears when trying to save the sample data.
> 
> I again created a new gig-file and found that, when importing the sample and
> assigning it to a region, it will already show Wav Data CRC-32: ffffffff
> in gigedit before saving it.

The CRC-32 checksum of each sample in a .gig file are generated/updated only 
at the end of the .gig file saving process. So it is normal that new samples 
first have a CRC initialized with ffffffff at first. 

> This behavior is confirmed with different samples. 
> 
> Saving an already existing gig-file after changing it in gigedit however
> seems to work.
> 
> 
> Are those issues related to each other?
> - My guess is no.
> Does anybody has an idea, what the root-cause might be?

As my telepathic abilities are just sub average, and my valueable crystal ball 
has never been handed back to me, I fear you would need to provide more info 
that a mortal person would be able to decode.

You could start by providing the questioned info, plus a backtrace of the 
crash.

> 
> 
> Cheers,
> Kolja

CU
Christian

[Linuxsampler-devel] gigedit crashes when creating ne gig-file. pango/gtkmm3?

[Kolja K. <ko...@fr...>]

Hi all,

while testing some newly created gig-files I ran into some problems with gigedit. I think, this might have something to do with my installation of it.

When trying to install tha latest gegedit version (1.2.0), running
./configure
runs alright, but then make will give: 

In file included from builtinpix.cpp:2:
../compat.h:194:21: error: ‘const Pango::Alignment Pango::ALIGN_LEFT’ redeclared as different kind of entity
  194 |     const Alignment ALIGN_LEFT = Alignment::LEFT;
      |                     ^~~~~~~~~~
In file included from /usr/include/gtkmm-3.0/gtkmm/widget.h:32,
                 from /usr/include/gtkmm-3.0/gtkmm/container.h:28,
                 from /usr/include/gtkmm-3.0/gtkmm/box.h:27,
                 from /usr/include/gtkmm-3.0/gtkmm/buttonbox.h:27,
                 from ../compat.h:134,
                 from builtinpix.cpp:2:
/usr/include/pangomm-1.4/pangomm/layout.h:77:3: note: previous declaration ‘Pango::Alignment Pango::ALIGN_LEFT’
   77 |   ALIGN_LEFT,
      |   ^~~~~~~~~~
In file included from builtinpix.cpp:2:
../compat.h:194:45: error: ‘LEFT’ is not a member of ‘Pango::Alignment’
  194 |     const Alignment ALIGN_LEFT = Alignment::LEFT;
      |                                             ^~~~
../compat.h:195:21: error: ‘const Pango::Alignment Pango::ALIGN_CENTER’ redeclared as different kind of entity
  195 |     const Alignment ALIGN_CENTER = Alignment::CENTER;
      |                     ^~~~~~~~~~~~
In file included from /usr/include/gtkmm-3.0/gtkmm/widget.h:32,
                 from /usr/include/gtkmm-3.0/gtkmm/container.h:28,
                 from /usr/include/gtkmm-3.0/gtkmm/box.h:27,
                 from /usr/include/gtkmm-3.0/gtkmm/buttonbox.h:27,
                 from ../compat.h:134,
                 from builtinpix.cpp:2:
/usr/include/pangomm-1.4/pangomm/layout.h:78:3: note: previous declaration ‘Pango::Alignment Pango::ALIGN_CENTER’
   78 |   ALIGN_CENTER,
      |   ^~~~~~~~~~~~
In file included from builtinpix.cpp:2:
../compat.h:195:47: error: ‘CENTER’ is not a member of ‘Pango::Alignment’
  195 |     const Alignment ALIGN_CENTER = Alignment::CENTER;
      |                                               ^~~~~~
../compat.h:196:21: error: ‘const Pango::Alignment Pango::ALIGN_RIGHT’ redeclared as different kind of entity
  196 |     const Alignment ALIGN_RIGHT = Alignment::RIGHT;
      |                     ^~~~~~~~~~~
In file included from /usr/include/gtkmm-3.0/gtkmm/widget.h:32,
                 from /usr/include/gtkmm-3.0/gtkmm/container.h:28,
                 from /usr/include/gtkmm-3.0/gtkmm/box.h:27,
                 from /usr/include/gtkmm-3.0/gtkmm/buttonbox.h:27,
                 from ../compat.h:134,
                 from builtinpix.cpp:2:
/usr/include/pangomm-1.4/pangomm/layout.h:79:3: note: previous declaration ‘Pango::Alignment Pango::ALIGN_RIGHT’
   79 |   ALIGN_RIGHT
      |   ^~~~~~~~~~~
In file included from builtinpix.cpp:2:
../compat.h:196:46: error: ‘RIGHT’ is not a member of ‘Pango::Alignment’
  196 |     const Alignment ALIGN_RIGHT = Alignment::RIGHT;



I'm on archlinux using
gtkmm3 version 3.24.5-2
and libgig from svn.

I managed to install gigedit by applying two patches:

gigedit-1.2.0-libdir.patch
gigedit-1.2.0-redeclare.patch

but have no clue, what exactly it is they're doing....

So far, so good.
But when trying to create a new gig -file with a sample and save it, gigedit will crash with:

** (gigedit:23922): ERROR **: 09:46:52.773: 
unhandled exception (type unknown) in signal handler

A gig-file is created though and I can load that into linuxsampler, but it wont play.
Opening it in gigedit again will show
Wav Data CRC-32: ffffffff
so my guess is, the crash appears when trying to save the sample data.

I again created a new gig-file and found that, when importing the sample and assigning it to a region, it will already show
Wav Data CRC-32: ffffffff
in gigedit before saving it.

This behavior is confirmed with different samples. 

Saving an already existing gig-file after changing it in gigedit however seems to work.


Are those issues related to each other?
- My guess is no.
Does anybody has an idea, what the root-cause might be?


Cheers,
Kolja

Re: [Linuxsampler-devel] linuxsampler to support 32 bit samples?

[Kolja K. <ko...@fr...>]

> It is not a talent to remember your own code. ;-)
I do have to object here: Remembering where to find a specific fragment
in thousands lines of code may indeed look like a talent to someone,
who can't even remember where his car key is, until he finds it in his
left hand... ;)

> Yeah, you only wrote part of the sample data, because the Write()
> method is
> ignorant as well. It simply assumes 16 bit in this case without
> complaining:
> 
> http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/gig.cpp?revision=3979&view=markup#l1329
Ah, I see.




> There is one clear difference between the gig engine and sfz engine
> in LS: the
> gig engine is much more efficient. I have seen a report on the ML by
> somebody
> who wrote he easily got CPU saturation with the sfz engine, unlike
> with gig
> and same patches. However he was not motivated enough to deliver
> useful
> profiling data so I could identify the issue.
> 
> In the end I am just maintaining the sfz engine, but I am personally
> not using
> it. So if people don't care enough there, then I don't either.
Fair enough!
I have no clue, how those sampler engines really compare regarding
playback-performance but always felt like using Gigasampler would be
the better choice. That's why I started programming my tool in a way
that it might be expanded to convert e.g. sfz to gig. That's something
I have on my list after my next release, since I want it to make myself
a 'true' replica of the Ivy-Piano sfz and some of its articulations are
not represented in the individual filenames.


> No problem, no hurry.
:) This sounds like an alternative version of 'No woman, no cry'... ;)

Cheers,
Kolja

Re: [Linuxsampler-devel] linuxsampler to support 32 bit samples?

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

On Montag, 8. November 2021 22:45:57 CET Kolja Koch wrote:
> > Actually libgig only supports samples up to 24 bit:
> > http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/gig.cpp?re
> > vision=3979&view=markup#l467
> > 
> > The disk streaming Read() method is currently quite ignorant and only
> > knows
> > about 16 bit or 24 bit:
> > http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/gig.cpp?re
> > vision=3979&view=markup#l1118
> Ah, ok, thanks for the clarification!
> I'm really amazed, how quick you respond and give the corresponding
> links! You seem to know your code well! :)

It is not a talent to remember your own code. ;-)

> Funny enough, I didn't notice any problems when saving the gig-file's
> samples with 32 bit using the gig_sample->write method.
> But since I have no way of testing the gig-file, I couldn't examine the
> result...

Yeah, you only wrote part of the sample data, because the Write() method is
ignorant as well. It simply assumes 16 bit in this case without complaining:

http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/gig.cpp?revision=3979&view=markup#l1329

> > It is actually the other way around: the sampler already uses 32 bit
> > internally for many years. So it is more the file format loading libs
> > like
> > libgig for .gig files or libsndfile for SFZ that would need to be
> > extended.
> 
> If I understand you correctly, libsndfile cuts 32 bit to 24 bit.?
> So since the wav-files I used come from an SFZ-container, there would
> currently be no difference between the gig and the SFZ anyway, I guess.

No I did not mean that, and actually apparently I was wrong in the first place
here, because I realized libsndfile does support 32 bit for a bunch of
formats:

https://github.com/libsndfile/libsndfile/blob/f1495b4bcc4f7f0fedb10119e6b5b5b2f1946d4b/include/sndfile.h.in#L81

For .wav you won't have much trouble here, it supports 32 bit signed, and if
you want you could even use 64 bit floating point with .wav files:

https://github.com/libsndfile/libsndfile/blob/f1495b4bcc4f7f0fedb10119e6b5b5b2f1946d4b/src/wav.c#L794

But that can naturally only be said on a per subformat basis, for instance for
flac libsndfile only supports up to 24 bit signed, because the flac codec does
not support 32 bit signed:

https://github.com/libsndfile/libsndfile/blob/f1495b4bcc4f7f0fedb10119e6b5b5b2f1946d4b/src/flac.c#L791

There is one clear difference between the gig engine and sfz engine in LS: the
gig engine is much more efficient. I have seen a report on the ML by somebody
who wrote he easily got CPU saturation with the sfz engine, unlike with gig
and same patches. However he was not motivated enough to deliver useful
profiling data so I could identify the issue.

In the end I am just maintaining the sfz engine, but I am personally not using
it. So if people don't care enough there, then I don't either.

> I currently don't feel up to looking into those codes deeply to see if
> I can help extending them. Maybe later.

No problem, no hurry.

> Thanks again!
> Cheers,
> Kolja

CU
Christian

Re: [Linuxsampler-devel] linuxsampler to support 32 bit samples?

[Kolja K. <ko...@fr...>]

> Actually libgig only supports samples up to 24 bit:
> http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/gig.cpp?revision=3979&view=markup#l467
> 
> The disk streaming Read() method is currently quite ignorant and only
> knows
> about 16 bit or 24 bit:
> http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/gig.cpp?revision=3979&view=markup#l1118
> 

Ah, ok, thanks for the clarification!
I'm really amazed, how quick you respond and give the corresponding
links! You seem to know your code well! :)

Funny enough, I didn't notice any problems when saving the gig-file's
samples with 32 bit using the gig_sample->write method.
But since I have no way of testing the gig-file, I couldn't examine the
result...

> It is actually the other way around: the sampler already uses 32 bit
> internally for many years. So it is more the file format loading libs
> like
> libgig for .gig files or libsndfile for SFZ that would need to be
> extended.

If I understand you correctly, libsndfile cuts 32 bit to 24 bit.?
So since the wav-files I used come from an SFZ-container, there would
currently be no difference between the gig and the SFZ anyway, I guess.

I currently don't feel up to looking into those codes deeply to see if
I can help extending them. Maybe later.

Thanks again!
Cheers,
Kolja

Re: [Linuxsampler-devel] linuxsampler to support 32 bit samples?

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

On Montag, 8. November 2021 20:16:13 CET Kolja Koch wrote:
> Hello all,

Hi,

> while working on the next release of gigcreator (which, as a sidenote,
> will support all available dimensions) , I just learned that libgig
> already supports 32 bit samples. I'm able to create gig-files with
> those kind of samples (Ivy-Piano) alright, but linuxsampler won't load
> them.

Actually libgig only supports samples up to 24 bit:
http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/gig.cpp?revision=3979&view=markup#l467

The disk streaming Read() method is currently quite ignorant and only knows
about 16 bit or 24 bit:
http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/gig.cpp?revision=3979&view=markup#l1118

> So my question is: Are there any plans to make linuxsampler support 32
> bit samples?

It is actually the other way around: the sampler already uses 32 bit
internally for many years. So it is more the file format loading libs like
libgig for .gig files or libsndfile for SFZ that would need to be extended.

CU
Christian

[Linuxsampler-devel] linuxsampler to support 32 bit samples?

[Kolja K. <ko...@fr...>]

Hello all,

while working on the next release of gigcreator (which, as a sidenote,
will support all available dimensions) , I just learned that libgig
already supports 32 bit samples. I'm able to create gig-files with
those kind of samples (Ivy-Piano) alright, but linuxsampler won't load
them.
So my question is: Are there any plans to make linuxsampler support 32
bit samples?

Cheers,
Kolja