Menu
▾
▴
linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(27) |
Nov
(120) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(65) |
Feb
(2) |
Mar
(53) |
Apr
(15) |
May
|
Jun
(19) |
Jul
(8) |
Aug
(35) |
Sep
(17) |
Oct
(70) |
Nov
(87) |
Dec
(94) |
| 2004 |
Jan
(133) |
Feb
(28) |
Mar
(45) |
Apr
(30) |
May
(113) |
Jun
(132) |
Jul
(33) |
Aug
(29) |
Sep
(26) |
Oct
(11) |
Nov
(21) |
Dec
(60) |
| 2005 |
Jan
(108) |
Feb
(153) |
Mar
(108) |
Apr
(44) |
May
(72) |
Jun
(90) |
Jul
(99) |
Aug
(67) |
Sep
(117) |
Oct
(38) |
Nov
(40) |
Dec
(27) |
| 2006 |
Jan
(16) |
Feb
(18) |
Mar
(21) |
Apr
(71) |
May
(26) |
Jun
(48) |
Jul
(27) |
Aug
(40) |
Sep
(20) |
Oct
(118) |
Nov
(69) |
Dec
(35) |
| 2007 |
Jan
(76) |
Feb
(98) |
Mar
(26) |
Apr
(126) |
May
(94) |
Jun
(46) |
Jul
(9) |
Aug
(89) |
Sep
(18) |
Oct
(27) |
Nov
|
Dec
(49) |
| 2008 |
Jan
(117) |
Feb
(40) |
Mar
(18) |
Apr
(30) |
May
(40) |
Jun
(10) |
Jul
(30) |
Aug
(13) |
Sep
(29) |
Oct
(23) |
Nov
(22) |
Dec
(35) |
| 2009 |
Jan
(19) |
Feb
(39) |
Mar
(17) |
Apr
(2) |
May
(6) |
Jun
(6) |
Jul
(8) |
Aug
(11) |
Sep
(1) |
Oct
(46) |
Nov
(13) |
Dec
(5) |
| 2010 |
Jan
(21) |
Feb
(3) |
Mar
(2) |
Apr
(7) |
May
(1) |
Jun
(26) |
Jul
(3) |
Aug
(10) |
Sep
(13) |
Oct
(35) |
Nov
(10) |
Dec
(17) |
| 2011 |
Jan
(26) |
Feb
(27) |
Mar
(14) |
Apr
(32) |
May
(8) |
Jun
(11) |
Jul
(4) |
Aug
(7) |
Sep
(27) |
Oct
(25) |
Nov
(7) |
Dec
(2) |
| 2012 |
Jan
(20) |
Feb
(17) |
Mar
(59) |
Apr
(31) |
May
|
Jun
(6) |
Jul
(7) |
Aug
(10) |
Sep
(11) |
Oct
(2) |
Nov
(4) |
Dec
(17) |
| 2013 |
Jan
(17) |
Feb
(2) |
Mar
(3) |
Apr
(4) |
May
(8) |
Jun
(3) |
Jul
(2) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
| 2014 |
Jan
(6) |
Feb
(26) |
Mar
(12) |
Apr
(14) |
May
(8) |
Jun
(7) |
Jul
(6) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(9) |
Feb
(5) |
Mar
(4) |
Apr
(9) |
May
(3) |
Jun
(2) |
Jul
(4) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(3) |
| 2016 |
Jan
(2) |
Feb
(4) |
Mar
(5) |
Apr
(4) |
May
(14) |
Jun
(31) |
Jul
(18) |
Aug
|
Sep
(10) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
(39) |
Feb
(5) |
Mar
(2) |
Apr
|
May
(52) |
Jun
(11) |
Jul
(36) |
Aug
(1) |
Sep
(7) |
Oct
(4) |
Nov
(10) |
Dec
(8) |
| 2018 |
Jan
(3) |
Feb
(4) |
Mar
|
Apr
(8) |
May
(28) |
Jun
(11) |
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(25) |
| 2019 |
Jan
(12) |
Feb
(50) |
Mar
(14) |
Apr
(3) |
May
(8) |
Jun
(17) |
Jul
(10) |
Aug
(2) |
Sep
(21) |
Oct
(10) |
Nov
|
Dec
(28) |
| 2020 |
Jan
(4) |
Feb
(10) |
Mar
(7) |
Apr
(16) |
May
(10) |
Jun
(7) |
Jul
(2) |
Aug
(5) |
Sep
(3) |
Oct
(3) |
Nov
(2) |
Dec
(1) |
| 2021 |
Jan
|
Feb
(5) |
Mar
(13) |
Apr
(13) |
May
(7) |
Jun
|
Jul
(1) |
Aug
(11) |
Sep
(12) |
Oct
(7) |
Nov
(26) |
Dec
(41) |
| 2022 |
Jan
(23) |
Feb
|
Mar
(8) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(1) |
Dec
(1) |
| 2023 |
Jan
|
Feb
(5) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(11) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
| 2024 |
Jan
(2) |
Feb
(4) |
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(10) |
Dec
|
| 2025 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(17) |
Jul
(1) |
Aug
(4) |
Sep
(7) |
Oct
(1) |
Nov
|
Dec
|
|
From: Christian S. <sch...@li...> - 2021-11-12 13:40:19
|
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 |
|
From: Kolja K. <ko...@fr...> - 2021-11-12 11:16:02
|
> 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 |
|
From: Christian S. <sch...@li...> - 2021-11-11 15:41:26
|
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 |
|
From: Kolja K. <ko...@fr...> - 2021-11-11 09:42:38
|
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
|
|
From: Kolja K. <ko...@fr...> - 2021-11-09 13:28:11
|
> 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 |
|
From: Christian S. <sch...@li...> - 2021-11-08 22:58:16
|
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 |
|
From: Kolja K. <ko...@fr...> - 2021-11-08 21:44:43
|
> 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 |
|
From: Christian S. <sch...@li...> - 2021-11-08 20:24:11
|
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 |
|
From: Kolja K. <ko...@fr...> - 2021-11-08 19:15:01
|
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 |
|
From: Christian S. <sch...@li...> - 2021-11-04 19:20:13
|
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 |
|
From: Sawyer B. <saw...@gm...> - 2021-11-04 16:44:01
|
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 > |
|
From: Christian S. <sch...@li...> - 2021-11-04 14:59:09
|
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 |
|
From: Sawyer B. <saw...@gm...> - 2021-11-02 23:48:59
|
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 |
|
From: Kolja K. <ko...@fr...> - 2021-10-12 11:43:05
|
Hi Jan, no, it doesn't, it just creates them. But there is gigedit (see https://linuxsampler.org/) for that. Actually, I use gigedit to evaluate the created gigs. You can also create new gigs with gigedit, but when dealing with a large number of samples, this can be cumbersome... Cheers, Kolja Am Dienstag, dem 12.10.2021 um 13:15 +0200 schrieb Jan Flikweert: > Hi all, > > The name of the program suggests it creates gig files from samples. > Does it edit gig files? > > Kind regards, > > Jan Flikweert > > -----Original Message----- > From: Kolja Koch [mailto:ko...@fr...] > Sent: dinsdag 12 oktober 2021 11:43 > To: lin...@li... > Subject: Re: [Linuxsampler-devel] gigCreator > > Great! > > Thanks for sharing! > Likewise! :) A lot! > Actually it's fun writing that. > The next level I'm currently working on will be that the user can > define it's own specifiers for available dimensions like random, > sustain pedal, etc. > The new datamodel behind that is then flexible enough to reflect that. > When that is done, I might add direct import-functions from other > sampler-types (sfz would be the first I'd try), though I know that > linuxsampler can directly play those... > > Cheers, > Kolja > > Am Samstag, dem 09.10.2021 um 16:01 +0200 schrieb Christian > Schoenebeck: > > Ok, I just added a link to the gigcreator gitlab project to the news > > section. > > Hope it's okay: > > > > https://linuxsampler.org > > > > Thanks for sharing! > > > > CU > > Christian > > > > On Donnerstag, 7. Oktober 2021 19:48:09 CEST Kolja Koch wrote: > > > Hey Christian, > > > > > > that would be nice, yes, thanks! :) > > > > > > Cheers, > > > Kolja > > > > > > Am Mittwoch, dem 06.10.2021 um 15:30 +0200 schrieb Christian > > > > > > Schoenebeck: > > > > On Mittwoch, 6. Oktober 2021 11:51:37 CEST Kolja Koch wrote: > > > > > Hello all, > > > > > > > > > > I managed to get the 'gigCreator' online on gitlab: > > > > > https://gitlab.com/koljakoch/gigcreator > > > > > > > > > > 'A tool written in C++ for generating GIGA-Sampler files out of > > > > > a > > > > > bunch > > > > > of wav-files.' > > > > > > > > > > > > > > > It is now not using wav2gig anymore, I implemented the gig- > > > > > creation > > > > > using libgig directly into this (used some code of wav2gig, > > > > > though). > > > > > > > > If you want I can add an entry to the news section of the ls.org > > > > website's > > > > front page for linking it. > > > > > > > > CU > > > > Christian > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Linuxsampler-devel mailing list > > > > Lin...@li... > > > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > > > _______________________________________________ > > > Linuxsampler-devel mailing list > > > Lin...@li... > > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > > > > > > > > > > > _______________________________________________ > > Linuxsampler-devel mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > |
|
From: Jan F. <fl...@ze...> - 2021-10-12 11:15:34
|
Hi all, The name of the program suggests it creates gig files from samples. Does it edit gig files? Kind regards, Jan Flikweert -----Original Message----- From: Kolja Koch [mailto:ko...@fr...] Sent: dinsdag 12 oktober 2021 11:43 To: lin...@li... Subject: Re: [Linuxsampler-devel] gigCreator Great! > Thanks for sharing! Likewise! :) A lot! Actually it's fun writing that. The next level I'm currently working on will be that the user can define it's own specifiers for available dimensions like random, sustain pedal, etc. The new datamodel behind that is then flexible enough to reflect that. When that is done, I might add direct import-functions from other sampler-types (sfz would be the first I'd try), though I know that linuxsampler can directly play those... Cheers, Kolja Am Samstag, dem 09.10.2021 um 16:01 +0200 schrieb Christian Schoenebeck: > Ok, I just added a link to the gigcreator gitlab project to the news > section. > Hope it's okay: > > https://linuxsampler.org > > Thanks for sharing! > > CU > Christian > > On Donnerstag, 7. Oktober 2021 19:48:09 CEST Kolja Koch wrote: > > Hey Christian, > > > > that would be nice, yes, thanks! :) > > > > Cheers, > > Kolja > > > > Am Mittwoch, dem 06.10.2021 um 15:30 +0200 schrieb Christian > > > > Schoenebeck: > > > On Mittwoch, 6. Oktober 2021 11:51:37 CEST Kolja Koch wrote: > > > > Hello all, > > > > > > > > I managed to get the 'gigCreator' online on gitlab: > > > > https://gitlab.com/koljakoch/gigcreator > > > > > > > > 'A tool written in C++ for generating GIGA-Sampler files out of > > > > a > > > > bunch > > > > of wav-files.' > > > > > > > > > > > > It is now not using wav2gig anymore, I implemented the gig- > > > > creation > > > > using libgig directly into this (used some code of wav2gig, > > > > though). > > > > > > If you want I can add an entry to the news section of the ls.org > > > website's > > > front page for linking it. > > > > > > CU > > > Christian > > > > > > > > > > > > > > > _______________________________________________ > > > Linuxsampler-devel mailing list > > > Lin...@li... > > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > _______________________________________________ > > Linuxsampler-devel mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > > > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel _______________________________________________ Linuxsampler-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Kolja K. <ko...@fr...> - 2021-10-12 09:42:03
|
Great! > Thanks for sharing! Likewise! :) A lot! Actually it's fun writing that. The next level I'm currently working on will be that the user can define it's own specifiers for available dimensions like random, sustain pedal, etc. The new datamodel behind that is then flexible enough to reflect that. When that is done, I might add direct import-functions from other sampler-types (sfz would be the first I'd try), though I know that linuxsampler can directly play those... Cheers, Kolja Am Samstag, dem 09.10.2021 um 16:01 +0200 schrieb Christian Schoenebeck: > Ok, I just added a link to the gigcreator gitlab project to the news > section. > Hope it's okay: > > https://linuxsampler.org > > Thanks for sharing! > > CU > Christian > > On Donnerstag, 7. Oktober 2021 19:48:09 CEST Kolja Koch wrote: > > Hey Christian, > > > > that would be nice, yes, thanks! :) > > > > Cheers, > > Kolja > > > > Am Mittwoch, dem 06.10.2021 um 15:30 +0200 schrieb Christian > > > > Schoenebeck: > > > On Mittwoch, 6. Oktober 2021 11:51:37 CEST Kolja Koch wrote: > > > > Hello all, > > > > > > > > I managed to get the 'gigCreator' online on gitlab: > > > > https://gitlab.com/koljakoch/gigcreator > > > > > > > > 'A tool written in C++ for generating GIGA-Sampler files out of > > > > a > > > > bunch > > > > of wav-files.' > > > > > > > > > > > > It is now not using wav2gig anymore, I implemented the gig- > > > > creation > > > > using libgig directly into this (used some code of wav2gig, > > > > though). > > > > > > If you want I can add an entry to the news section of the ls.org > > > website's > > > front page for linking it. > > > > > > CU > > > Christian > > > > > > > > > > > > > > > _______________________________________________ > > > Linuxsampler-devel mailing list > > > Lin...@li... > > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > _______________________________________________ > > Linuxsampler-devel mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > > > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Christian S. <sch...@li...> - 2021-10-09 14:01:32
|
Ok, I just added a link to the gigcreator gitlab project to the news section. Hope it's okay: https://linuxsampler.org Thanks for sharing! CU Christian On Donnerstag, 7. Oktober 2021 19:48:09 CEST Kolja Koch wrote: > Hey Christian, > > that would be nice, yes, thanks! :) > > Cheers, > Kolja > > Am Mittwoch, dem 06.10.2021 um 15:30 +0200 schrieb Christian > > Schoenebeck: > > On Mittwoch, 6. Oktober 2021 11:51:37 CEST Kolja Koch wrote: > > > Hello all, > > > > > > I managed to get the 'gigCreator' online on gitlab: > > > https://gitlab.com/koljakoch/gigcreator > > > > > > 'A tool written in C++ for generating GIGA-Sampler files out of a > > > bunch > > > of wav-files.' > > > > > > > > > It is now not using wav2gig anymore, I implemented the gig-creation > > > using libgig directly into this (used some code of wav2gig, > > > though). > > > > If you want I can add an entry to the news section of the ls.org > > website's > > front page for linking it. > > > > CU > > Christian > > > > > > > > > > _______________________________________________ > > Linuxsampler-devel mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Kolja K. <ko...@fr...> - 2021-10-07 17:47:23
|
Hey Christian, that would be nice, yes, thanks! :) Cheers, Kolja Am Mittwoch, dem 06.10.2021 um 15:30 +0200 schrieb Christian Schoenebeck: > On Mittwoch, 6. Oktober 2021 11:51:37 CEST Kolja Koch wrote: > > Hello all, > > > > I managed to get the 'gigCreator' online on gitlab: > > https://gitlab.com/koljakoch/gigcreator > > > > 'A tool written in C++ for generating GIGA-Sampler files out of a > > bunch > > of wav-files.' > > > > > > It is now not using wav2gig anymore, I implemented the gig-creation > > using libgig directly into this (used some code of wav2gig, > > though). > > If you want I can add an entry to the news section of the ls.org > website's > front page for linking it. > > CU > Christian > > > > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Christian S. <sch...@li...> - 2021-10-06 13:30:59
|
On Mittwoch, 6. Oktober 2021 11:51:37 CEST Kolja Koch wrote: > Hello all, > > I managed to get the 'gigCreator' online on gitlab: > https://gitlab.com/koljakoch/gigcreator > > 'A tool written in C++ for generating GIGA-Sampler files out of a bunch > of wav-files.' > > > It is now not using wav2gig anymore, I implemented the gig-creation > using libgig directly into this (used some code of wav2gig, though). If you want I can add an entry to the news section of the ls.org website's front page for linking it. CU Christian |
|
From: Kolja K. <ko...@fr...> - 2021-10-06 09:50:52
|
Hello all, I managed to get the 'gigCreator' online on gitlab: https://gitlab.com/koljakoch/gigcreator 'A tool written in C++ for generating GIGA-Sampler files out of a bunch of wav-files.' It is now not using wav2gig anymore, I implemented the gig-creation using libgig directly into this (used some code of wav2gig, though). Features: - scan and use information like e.g. midi-note-number from wav-files or enter them in the filename-scan-pattern. - multiple instruments per gig - merge two mono-files into one stereo-sample (if the corresponding pattern-specifier is given) - samples are grouped by instruments in gig file - preview of gig-files to be created The gui is based on wxwidgets. Anyone who would like to test it is very much welcome, any effort and feedback is appreciated!! This is my first contribution, so bear with me... ;) I will do some more testing with more different files (e.g. 24bit and velocity layers). > Well, there must be some note/velocity numbers info somewhere, either > in the > wav file (content) itself, or as part of the file name. For other use > cases > more options would need to be added to wav2gig, like a default value > for > velocity, note, ... if there is no match. > Currently, the tool works even when no velocity is given, but surely either note or velocity is mandatory. Cheers, Kolja > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Christian S. <sch...@li...> - 2021-09-29 10:59:14
|
On Mittwoch, 29. September 2021 04:37:37 CEST Doug Gray wrote: > Managed to get the code compiled. > Perl is installed however the XML::Parser module called up in the > generate_lscp_shell_reference.pl script line 15. > After installing this module and re-running the script directly the build > proceeded until RTMath.cpp. > I am compiling this on a Raspberry PI 4 - ARM processor obviously, the > attached patch as I used the first time I compiled the code some months ago > was required. I had thought it may have by now been applied in the current > source: > > cd src/common/ > cp atomic.h atomic.h.org > cp RTMath.cpp RTMath.cpp.org > patch -p2 <../../linuxsampler-armv7l.patch > > One issue I do have is an error signing the package, this has not been an > issue with the packages but I'd like to know how to fix it perhaps using my > own gpg key. (I have obscured your email address here): > > signfile linuxsampler_2.2.0_armhf.buildinfo > gpg: skipped "Christian Schoenebeck <....@users.sourceforge.net>": No > secret key > gpg: dpkg-sign.0v6yB9ud/linuxsampler_2.2.0_armhf.buildinfo: clear-sign > failed: No secret key That's the same with any Debian package, so it is not specifically an LS issue: This is controlled via the debian/changelog file. Just add your own changelog block on top of that debian/changelog file content (or even more simple: replace my email address at the top most entry) with your own email address and make sure you have setup some gpg key associated with your local gpg wallet. CU Christian |
|
From: Doug G. <dou...@gm...> - 2021-09-29 02:37:56
|
Managed to get the code compiled. Perl is installed however the XML::Parser module called up in the generate_lscp_shell_reference.pl script line 15. After installing this module and re-running the script directly the build proceeded until RTMath.cpp. I am compiling this on a Raspberry PI 4 - ARM processor obviously, the attached patch as I used the first time I compiled the code some months ago was required. I had thought it may have by now been applied in the current source: cd src/common/ cp atomic.h atomic.h.org cp RTMath.cpp RTMath.cpp.org patch -p2 <../../linuxsampler-armv7l.patch One issue I do have is an error signing the package, this has not been an issue with the packages but I'd like to know how to fix it perhaps using my own gpg key. (I have obscured your email address here): signfile linuxsampler_2.2.0_armhf.buildinfo gpg: skipped "Christian Schoenebeck <....@users.sourceforge.net>": No secret key gpg: dpkg-sign.0v6yB9ud/linuxsampler_2.2.0_armhf.buildinfo: clear-sign failed: No secret key Thanks for the help, doubtless I will have further questions. Doug On Tue, 28 Sept 2021 at 22:48, Christian Schoenebeck < sch...@li...> wrote: > On Dienstag, 28. September 2021 14:33:11 CEST Doug Gray wrote: > > Thanks for the help. Flex was not installed, fixed that and ran 'make > > parser'. > > I'm building deb packages BTW, the compile got much further until this > > error -see below. More files to generate? > > > > /bin/bash ../../libtool --tag=CXX --mode=compile > arm-linux-gnueabihf-g++ > > -std=gnu++14 -DHAVE_CONFIG_H -I. -I../.. -I/usr/include/libgig > > -Wreturn-type -ffast-math -g -O2 -pthread -MT lscp_shell_reference.lo > -MD > > -MP -MF $depbase.Tpo -c -o lscp_shell_reference.lo > lscp_shell_reference.cpp > > &&\ > > mv -f $depbase.Tpo $depbase.Plo > > libtool: compile: arm-linux-gnueabihf-g++ -std=gnu++14 -DHAVE_CONFIG_H > -I. > > -I../.. -I/usr/include/libgig -Wreturn-type -ffast-math -g -O2 -pthread > -MT > > lscp_shell_reference.lo -MD -MP -MF .deps/lscp_shell_reference.Tpo -c > > lscp_shell_reference.cpp -fPIC -DPIC -o .libs/lscp_shell_reference.o > > arm-linux-gnueabihf-g++: error: lscp_shell_reference.cpp: No such file or > > directory > > lscp_shell_reference.cpp "should" be auto generated by "make parser" as > well, > which actually triggers execution of scripts/ > generate_lscp_shell_reference.pl > > You do have Perl installed, right? Because that's the only dependency I > can > see for this script. But Perl is usually available on any base > installation. > > You can try to run the script manually and see what happens: > > cd scripts > ./generate_lscp_shell_reference.pl > > CU > Christian > > > > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > |
|
From: Christian S. <sch...@li...> - 2021-09-28 12:48:04
|
On Dienstag, 28. September 2021 14:33:11 CEST Doug Gray wrote: > Thanks for the help. Flex was not installed, fixed that and ran 'make > parser'. > I'm building deb packages BTW, the compile got much further until this > error -see below. More files to generate? > > /bin/bash ../../libtool --tag=CXX --mode=compile arm-linux-gnueabihf-g++ > -std=gnu++14 -DHAVE_CONFIG_H -I. -I../.. -I/usr/include/libgig > -Wreturn-type -ffast-math -g -O2 -pthread -MT lscp_shell_reference.lo -MD > -MP -MF $depbase.Tpo -c -o lscp_shell_reference.lo lscp_shell_reference.cpp > &&\ > mv -f $depbase.Tpo $depbase.Plo > libtool: compile: arm-linux-gnueabihf-g++ -std=gnu++14 -DHAVE_CONFIG_H -I. > -I../.. -I/usr/include/libgig -Wreturn-type -ffast-math -g -O2 -pthread -MT > lscp_shell_reference.lo -MD -MP -MF .deps/lscp_shell_reference.Tpo -c > lscp_shell_reference.cpp -fPIC -DPIC -o .libs/lscp_shell_reference.o > arm-linux-gnueabihf-g++: error: lscp_shell_reference.cpp: No such file or > directory lscp_shell_reference.cpp "should" be auto generated by "make parser" as well, which actually triggers execution of scripts/generate_lscp_shell_reference.pl You do have Perl installed, right? Because that's the only dependency I can see for this script. But Perl is usually available on any base installation. You can try to run the script manually and see what happens: cd scripts ./generate_lscp_shell_reference.pl CU Christian |
|
From: Doug G. <dou...@gm...> - 2021-09-28 12:33:29
|
Thanks for the help. Flex was not installed, fixed that and ran 'make parser'. I'm building deb packages BTW, the compile got much further until this error -see below. More files to generate? /bin/bash ../../libtool --tag=CXX --mode=compile arm-linux-gnueabihf-g++ -std=gnu++14 -DHAVE_CONFIG_H -I. -I../.. -I/usr/include/libgig -Wreturn-type -ffast-math -g -O2 -pthread -MT lscp_shell_reference.lo -MD -MP -MF $depbase.Tpo -c -o lscp_shell_reference.lo lscp_shell_reference.cpp &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: arm-linux-gnueabihf-g++ -std=gnu++14 -DHAVE_CONFIG_H -I. -I../.. -I/usr/include/libgig -Wreturn-type -ffast-math -g -O2 -pthread -MT lscp_shell_reference.lo -MD -MP -MF .deps/lscp_shell_reference.Tpo -c lscp_shell_reference.cpp -fPIC -DPIC -o .libs/lscp_shell_reference.o arm-linux-gnueabihf-g++: error: lscp_shell_reference.cpp: No such file or directory arm-linux-gnueabihf-g++: fatal error: no input files compilation terminated. make[4]: *** [Makefile:459: lscp_shell_reference.lo] Error 1 make[4]: Leaving directory '/home/pi/lssvn/linuxsampler/src/network' TIA, Doug On Tue, 28 Sept 2021 at 21:27, Christian Schoenebeck < sch...@li...> wrote: > On Dienstag, 28. September 2021 07:38:22 CEST Doug Gray wrote: > > Apologies for what may be a trivial question but I am un-accustomed to > > compiling the source but I have an error I'm not sure how to fix, see as > > follows. Note: This code was checked out today. > > Make sure you have bison and flex installed, then force the parsers to be > regenerated: > > make parser > > And then you should be able to compile again as usual: > > make -j16 > > (the -jN switch is for multi core compiling, i.e. to speedup compilation) > > > # Add here commands to compile the package. > > /usr/bin/make > > make[1]: Entering directory '/home/pi/lssvn/linuxsampler' > > /usr/bin/make all-recursive > > make[2]: Entering directory '/home/pi/lssvn/linuxsampler' > > Making all in man > > make[3]: Entering directory '/home/pi/lssvn/linuxsampler/man' > > make[3]: Nothing to be done for 'all'. > > make[3]: Leaving directory '/home/pi/lssvn/linuxsampler/man' > > Making all in src > > make[3]: Entering directory '/home/pi/lssvn/linuxsampler/src' > > Making all in scriptvm > > make[4]: Entering directory '/home/pi/lssvn/linuxsampler/src/scriptvm' > > make[4]: *** No rule to make target 'parser.h', needed by 'all'. Stop. > > > > I have looked but cannot see the solution. > > > > Also, to update the svn image I presume the command would be: > > svn up https://svn.linuxsampler.org/svn/linuxsampler/trunk linuxsampler > > Correct? > > No. Apparently you already have some old svn version there, so it is: > > cd /home/pi/lssvn > svn up > > Otherwise if you need to get a completely new copy from svn from scratch: > > svn co https://svn.linuxsampler.org/svn/linuxsampler/trunk linuxsampler > > CU > Christian > > > > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > |
|
From: Christian S. <sch...@li...> - 2021-09-28 11:26:48
|
On Dienstag, 28. September 2021 07:38:22 CEST Doug Gray wrote: > Apologies for what may be a trivial question but I am un-accustomed to > compiling the source but I have an error I'm not sure how to fix, see as > follows. Note: This code was checked out today. Make sure you have bison and flex installed, then force the parsers to be regenerated: make parser And then you should be able to compile again as usual: make -j16 (the -jN switch is for multi core compiling, i.e. to speedup compilation) > # Add here commands to compile the package. > /usr/bin/make > make[1]: Entering directory '/home/pi/lssvn/linuxsampler' > /usr/bin/make all-recursive > make[2]: Entering directory '/home/pi/lssvn/linuxsampler' > Making all in man > make[3]: Entering directory '/home/pi/lssvn/linuxsampler/man' > make[3]: Nothing to be done for 'all'. > make[3]: Leaving directory '/home/pi/lssvn/linuxsampler/man' > Making all in src > make[3]: Entering directory '/home/pi/lssvn/linuxsampler/src' > Making all in scriptvm > make[4]: Entering directory '/home/pi/lssvn/linuxsampler/src/scriptvm' > make[4]: *** No rule to make target 'parser.h', needed by 'all'. Stop. > > I have looked but cannot see the solution. > > Also, to update the svn image I presume the command would be: > svn up https://svn.linuxsampler.org/svn/linuxsampler/trunk linuxsampler > Correct? No. Apparently you already have some old svn version there, so it is: cd /home/pi/lssvn svn up Otherwise if you need to get a completely new copy from svn from scratch: svn co https://svn.linuxsampler.org/svn/linuxsampler/trunk linuxsampler CU Christian |
161 messages has been excluded from this view by a project administrator.
