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

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

Re: [Linuxsampler-devel] Linuxsampler on pipewire

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

On Donnerstag, 4. November 2021 17:43:39 CET Sawyer Bergeron wrote:
> That does seem to be the case,
> 
> ldd (which qjackctl) | grep jack
> 
> > > libjack.so.0 => /usr/lib/pipewire-0.3/jack/libjack.so.0
> > 
> > (0x00007f3af17ae000)
> 
> ldd (which linuxsampler) | grep jack
> 
> > > libjack.so.0 => /usr/lib/libjack.so.0 (0x00007f603e3cc000)
> 
> This is rather strange. Those other applications aren't different from the
> ones that I ran directly on top of normal jack2, how is linuxsampler doing
> library discovery here?
> I'm reasonably confident there isn't any compile time pipewire-specific
> stuff, since when switching from jack to pipewire I didn't have to
> reinstall any of these packages. I'm using the pipewire-jack-dropin package
> that gives extra config args to ld:
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pipewire-dropin

I haven't looked into pipewire before. But from what I see (not verified) they 
solved it like this: JACK client apps are supposed to link against the 
pipewire version of the JACK client lib (i.e. /usr/lib/pipewire-0.3/jack/
libjack.so.0) instead of the official JACK client lib (i.e. /usr/lib/
libjack.so.0).

And yes, pipewire-jack-dropin apparently is intended to make this working for 
existing JACK clients as well without recompiling them, by installing a config 
file to /etc/ld.so.conf.d/ which in turn would override/remap the linker path 
to the JACK client lib.

But your other apps are apparently not using that ld.so.conf.d mechanism which 
ldd output proofs. They are directly linked to pipewire's lib instead. So 
chances are that something with your pipewire-jack-dropin is incorrect. It may 
be a path has simply changed for instance (e.g. there is pipewire version 
number in the path).

So you either figure out what's wrong with the ld.so.conf.d file, or you 
recompile LS and replace in configure.ac the line

	PKG_CHECK_MODULES(JACK, jack, have_jack=1, have_jack=0)

to search and link against pipewire's lib directly at compile time instead.

You might also check what other audio apps are doing at compile time. Probably 
they already changed their configure script to search for both, the official 
JACK and pipewire's JACK and pick automatically either one available at 
compile time.

CU
Christian

Re: [Linuxsampler-devel] Linuxsampler on pipewire

[Sawyer B. <saw...@gm...>]

That does seem to be the case,

ldd (which qjackctl) | grep jack
> > libjack.so.0 => /usr/lib/pipewire-0.3/jack/libjack.so.0
> (0x00007f3af17ae000)
>

ldd (which linuxsampler) | grep jack
> > libjack.so.0 => /usr/lib/libjack.so.0 (0x00007f603e3cc000)
>

This is rather strange. Those other applications aren't different from the
ones that I ran directly on top of normal jack2, how is linuxsampler doing
library discovery here?
I'm reasonably confident there isn't any compile time pipewire-specific
stuff, since when switching from jack to pipewire I didn't have to
reinstall any of these packages. I'm using the pipewire-jack-dropin package
that gives extra config args to ld:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pipewire-dropin

Thanks,
Sawyer Bergeron
saw...@gm...


On Thu, Nov 4, 2021 at 10:59 AM Christian Schoenebeck <
sch...@li...> wrote:

> On Mittwoch, 3. November 2021 00:48:40 CET Sawyer Bergeron wrote:
> > Hi All,
> >
> > I'm trying to get linuxsampler running on top of pipewire using
> > pipewire-jack. When creating a channel in qsampler I get the following
> > output from linuxsampler:
> >
> > ```
> >
> > > LinuxSampler 2.2.0
> > > Copyright (C) 2003,2004 by Benno Senoner and Christian Schoenebeck
> > > Copyright (C) 2005-2021 Christian Schoenebeck
> > > Binary built: Jun  3 2021
> > > Detected features: MMX SSE SSE2
> > > Automatic Stacktrace: Off
> > > Creating Sampler...OK
> > > Registered sampler engines: 'GIG','SF2','SFZ'
> > > Registered MIDI input drivers: ALSA,JACK
> > > Registered audio output drivers: ALSA,JACK
> > > Loading instrument editor plugins...OK
> > > Registered instrument editors: 'gigedit'
> > > Registered internal effect systems: LADSPA
> > > Registered internal effects: 467
> > > Starting LSCP network server (0.0.0.0:8888)...Thread: WARNING, can't
> > > mlockall() memory!
> > > OK
> > > LinuxSampler initialization completed. :-)
> > >
> > > LSCPServer: Client connection established on socket:8.
> > > LSCPServer: Client connection established on socket:9.
> > > Cannot connect to server socket err = No such file or directory
> > > Cannot connect to server request channel
> > > Automatic start of JACK server is disabled at configure time
> > > jack server is not running or cannot be started
> > > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1,
> skipping
> > > unlock
> > > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1,
> skipping
> > > unlock
> > > Cannot connect to server socket err = No such file or directory
> > > Cannot connect to server request channel
> > > Automatic start of JACK server is disabled at configure time
> > > jack server is not running or cannot be started
> > > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1,
> skipping
> > > unlock
> > > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1,
> skipping
> > > unlock
> > > Seems Jack server is not running.
> > > Thread: WARNING, can't assign realtime scheduling to thread!
> > > Thread: WARNING, can't mlockall() memory!
> > > No audio output device connected to sampler channel
> >
> > ```
> >
> > Some other jack applications (ardour, qjackctl) all seem to happily run
> > here so I'm pretty sure pipewire-jack is at least running properly. Are
> > there any workarounds known of for this?
> >
> > Thanks in advance for any info, let me know if any further output would
> be
> > helpful.
> >
> > --Sawyer
>
> Looks like this is about this topic:
> https://bb.linuxsampler.org/viewtopic.php?f=6&t=19964
>
> So you are saying it does work with other JACK client apps, but it does
> not
> work with LS being a JACK client.
>
> Please check against which precise JACK libs those apps are linked to on
> your
> system, which you can easily do by using 'ldd'. Because from what I can
> see,
> it looks like the working ones are compiled against a pipewire jack client
> lib, whereas LS was maybe linked against the "real" / official JACK
> server's
> client lib.
>
> CU
> Christian
>
>
>
>
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] Linuxsampler on pipewire

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

On Mittwoch, 3. November 2021 00:48:40 CET Sawyer Bergeron wrote:
> Hi All,
> 
> I'm trying to get linuxsampler running on top of pipewire using
> pipewire-jack. When creating a channel in qsampler I get the following
> output from linuxsampler:
> 
> ```
> 
> > LinuxSampler 2.2.0
> > Copyright (C) 2003,2004 by Benno Senoner and Christian Schoenebeck
> > Copyright (C) 2005-2021 Christian Schoenebeck
> > Binary built: Jun  3 2021
> > Detected features: MMX SSE SSE2
> > Automatic Stacktrace: Off
> > Creating Sampler...OK
> > Registered sampler engines: 'GIG','SF2','SFZ'
> > Registered MIDI input drivers: ALSA,JACK
> > Registered audio output drivers: ALSA,JACK
> > Loading instrument editor plugins...OK
> > Registered instrument editors: 'gigedit'
> > Registered internal effect systems: LADSPA
> > Registered internal effects: 467
> > Starting LSCP network server (0.0.0.0:8888)...Thread: WARNING, can't
> > mlockall() memory!
> > OK
> > LinuxSampler initialization completed. :-)
> > 
> > LSCPServer: Client connection established on socket:8.
> > LSCPServer: Client connection established on socket:9.
> > Cannot connect to server socket err = No such file or directory
> > Cannot connect to server request channel
> > Automatic start of JACK server is disabled at configure time
> > jack server is not running or cannot be started
> > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
> > unlock
> > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
> > unlock
> > Cannot connect to server socket err = No such file or directory
> > Cannot connect to server request channel
> > Automatic start of JACK server is disabled at configure time
> > jack server is not running or cannot be started
> > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
> > unlock
> > JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
> > unlock
> > Seems Jack server is not running.
> > Thread: WARNING, can't assign realtime scheduling to thread!
> > Thread: WARNING, can't mlockall() memory!
> > No audio output device connected to sampler channel
> 
> ```
> 
> Some other jack applications (ardour, qjackctl) all seem to happily run
> here so I'm pretty sure pipewire-jack is at least running properly. Are
> there any workarounds known of for this?
> 
> Thanks in advance for any info, let me know if any further output would be
> helpful.
> 
> --Sawyer

Looks like this is about this topic:
https://bb.linuxsampler.org/viewtopic.php?f=6&t=19964

So you are saying it does work with other JACK client apps, but it does not 
work with LS being a JACK client.

Please check against which precise JACK libs those apps are linked to on your 
system, which you can easily do by using 'ldd'. Because from what I can see, 
it looks like the working ones are compiled against a pipewire jack client 
lib, whereas LS was maybe linked against the "real" / official JACK server's 
client lib.

CU
Christian

[Linuxsampler-devel] Linuxsampler on pipewire

[Sawyer B. <saw...@gm...>]

Hi All,

I'm trying to get linuxsampler running on top of pipewire using
pipewire-jack. When creating a channel in qsampler I get the following
output from linuxsampler:

```

> LinuxSampler 2.2.0
> Copyright (C) 2003,2004 by Benno Senoner and Christian Schoenebeck
> Copyright (C) 2005-2021 Christian Schoenebeck
> Binary built: Jun  3 2021
> Detected features: MMX SSE SSE2
> Automatic Stacktrace: Off
> Creating Sampler...OK
> Registered sampler engines: 'GIG','SF2','SFZ'
> Registered MIDI input drivers: ALSA,JACK
> Registered audio output drivers: ALSA,JACK
> Loading instrument editor plugins...OK
> Registered instrument editors: 'gigedit'
> Registered internal effect systems: LADSPA
> Registered internal effects: 467
> Starting LSCP network server (0.0.0.0:8888)...Thread: WARNING, can't
> mlockall() memory!
> OK
> LinuxSampler initialization completed. :-)
>
> LSCPServer: Client connection established on socket:8.
> LSCPServer: Client connection established on socket:9.
> Cannot connect to server socket err = No such file or directory
> Cannot connect to server request channel
> Automatic start of JACK server is disabled at configure time
> jack server is not running or cannot be started
> JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
> unlock
> JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
> unlock
> Cannot connect to server socket err = No such file or directory
> Cannot connect to server request channel
> Automatic start of JACK server is disabled at configure time
> jack server is not running or cannot be started
> JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
> unlock
> JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping
> unlock
> Seems Jack server is not running.
> Thread: WARNING, can't assign realtime scheduling to thread!
> Thread: WARNING, can't mlockall() memory!
> No audio output device connected to sampler channel

```

Some other jack applications (ardour, qjackctl) all seem to happily run
here so I'm pretty sure pipewire-jack is at least running properly. Are
there any workarounds known of for this?

Thanks in advance for any info, let me know if any further output would be
helpful.

--Sawyer