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

Re: [Linuxsampler-devel] "GET" LSCP commands to linuxsampler sometimes don't return data

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

On Dienstag, 21. Dezember 2021 17:42:29 CET Andrew C wrote:
> Hi Christian,
> 
> Unfortunately no, I wasn't running a command in parallel to the GET
> command, all my instruments had already loaded by the time I tried the GET
> command.
> The LSCP shell/CLI utility works absolutely fine every time I send such a
> GET command, so perhaps it's my netcatting that's the issue here for some
> reason. Not sure if there would be more scriptable methods of reliably
> getting the data from Linuxsampler.

Ok, then you might just try some of the numerous other netcat derivates. 
Altough it sounds a bit strange that you got a much different latency with the 
LSCP shell than with nc.

As this is really a simple text based network protocol, there are endless of 
other possibilities, like writing a simple Python script or whatever.

> Also, on the note of using the lscp CLI/netcat commands to Linuxsampler for
> the instrument editor, it seems it doesn't work on my end:
> lscp=# EDIT CHANNEL INSTRUMENT 1
> ERR:0:There is no instrument editor capable to handle this instrument
> lscp=# EDIT CHANNEL INSTRUMENT 0
> ERR:0:There is no instrument editor capable to handle this instrument
> 
> Both files were loaded using the GIG engine and gigedit/Linuxsampler are
> installed in /usr/local.. Perhaps my PATH or ldconfig needs updating?

When linuxsampler is launched, you see a bunch of information, which also 
includes the following line:

	Registered instrument editors: 'gigedit'

If "gigedit" is missing in that line, then because the sampler did not find 
gigedit's plugin in the sampler's plugin directory. You can change the 
sampler's default plugin path at compile time:

	./configure --enable-plugin-dir=/some/where

As well as overriding it by environment variable before launching 
linuxsampler. From "man linuxsampler":

ENVIRONMENT VARIABLES
       LINUXSAMPLER_PLUGIN_DIR
              Allows to override the directory where LinuxSampler shall look 
              for instrument editor plugins.

Note, there is also --exec-after-init BTW.

CU
Christian

Re: [Linuxsampler-devel] JSampler java classes bugfixes?

[Grigor I. <gr....@gm...>]

Hi Andrew,
You should be able to launch JSampler with latest JRE using the
following command:

java --add-exports java.desktop/sun.swing.plaf.synth=ALL-UNNAMED -jar
/path/to/Fantasia-0.9.jar

There might also be other module permission/access issues, which
should be easy to fix by using additional --add-exports and
--add-opens options, if needed.

Unfortunately, I don't have spare time for free projects anymore and I
don't think that I'll be able to find time to work on JSampler in near
future.

Regards,
Grigor.

On Mon, Dec 20, 2021 at 11:53 AM Andrew C <cou...@gm...> wrote:
>
> Hi all,
>
> I'm running into some critical errors with openJDK/JRE versions 16/18 and trying to run JSampler. It appears there are some older classes that are no longer supported in these versions or perhaps need a bit more wriggling to accommodate the JSampler code?
>
> Exception in thread "AWT-EventQueue-0" java.lang.IllegalAccessError: class
> org.jsampler.view.fantasia.basic.PixmapPane (in unnamed module @0x248d4f4a)
> cannot access class sun.swing.plaf.synth.Paint9Painter (in module java.des
> ktop) because module java.desktop does not export sun.swing.plaf.synth to u
> nnamed module @0x248d4f4a
>
> I know this is/was(?) Grishata's project and I lack the knowledge to even begin trying to fix this up, but was wondering if anyone else has encountered this and if there are workarounds for it?
>
> The alternative, if I cannot get it working would have to be diving into sending LSCP commands to Linuxsampler via Netcat. That should be fun! ;)
>
> A question for Christian, but is it possible through LSCP to tell Linuxsampler to open gigedit "Live" on an instrument, so as to edit in real-time, or was that a special function of JSampler?
>
> Cheers,
>
> Andrew.
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] JSampler java classes bugfixes?

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

On Dienstag, 21. Dezember 2021 17:36:24 CET Andrew C wrote:
> My bad, I had forgotten about QSampler. I'll try that out instead and
> perhaps hunt down an older Java SDK version if possible.
> 
> Cheers,
> Andrew.

Maybe it is time to mark JSampler as orphaned (e.g. on the website) to make it 
more clear that nobody has been working on it for 10 years. If it no longer 
runs with a recent Java SDK version, then it is probably time to reflect the 
facts.

CU
Christian

Re: [Linuxsampler-devel] "GET" LSCP commands to linuxsampler sometimes don't return data

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

Hi Christian,

Unfortunately no, I wasn't running a command in parallel to the GET
command, all my instruments had already loaded by the time I tried the GET
command.
The LSCP shell/CLI utility works absolutely fine every time I send such a
GET command, so perhaps it's my netcatting that's the issue here for some
reason. Not sure if there would be more scriptable methods of reliably
getting the data from Linuxsampler.

Also, on the note of using the lscp CLI/netcat commands to Linuxsampler for
the instrument editor, it seems it doesn't work on my end:
lscp=# EDIT CHANNEL INSTRUMENT 1
ERR:0:There is no instrument editor capable to handle this instrument
lscp=# EDIT CHANNEL INSTRUMENT 0
ERR:0:There is no instrument editor capable to handle this instrument

Both files were loaded using the GIG engine and gigedit/Linuxsampler are
installed in /usr/local.. Perhaps my PATH or ldconfig needs updating?

Many thanks,

Andrew.


On Tue, Dec 21, 2021 at 4:31 PM Christian Schoenebeck <
sch...@li...> wrote:

> On Dienstag, 21. Dezember 2021 15:46:17 CET Andrew C wrote:
> > Hi,
> >
> > I'm hacking together a quick-and-dirty bash script for
> controlling/setting
> > up audio/midi interfaces in Linuxsampler by sending LSCP commands.
> >
> > Sending the commands seems absolutely fine, but using the 'GET' commands
> to
> > recieve data from Linuxsampler, for example info about a sampler channel,
> > don't appear to return data consistently or "in time"?
> >
> > Command I'm using:
> > echo "GET CHANNEL INFO 1" | nc -q 1 -t localhost 8888
> >
> > Sometimes it'll return the channel info immediately, other times
> > Linuxsampler returns nothing at all, though the connection is established
> > and terminated.
>
> I guess you were sending another LSCP command in parallel while that
> happened,
> e.g. loading an instrument in foreground.
>
> The LSCP server is currently single-threaded:
>
> http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/linuxsampler/trunk/src/network/lscpserver.h?revision=2534&view=markup
>
> So the LSCP server only executes one command at a time, which explains why
> your "GET CHANNEL INFO" sometimes takes a moment before completing. So far
> this was not an issue for anybody, at least nobody complained FWIW in all
> these years.
>
> In the meantime you might just load your instruments in the background for
> not
> blocking the LSCP server for too long.
>
> BTW we also have a dedicated command line utility that might be a bit more
> convenient to play around with LSCP:
> http://doc.linuxsampler.org/Release_Notes/LinuxSampler_2_0_0/#lscp_shell
>
> > Thanks,
> >
> > Andrew.
>
>
>
>
>
>
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] JSampler java classes bugfixes?

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

My bad, I had forgotten about QSampler. I'll try that out instead and
perhaps hunt down an older Java SDK version if possible.

Cheers,
Andrew.

On Tue, Dec 21, 2021 at 4:23 PM Christian Schoenebeck <
sch...@li...> wrote:

> On Montag, 20. Dezember 2021 10:52:50 CET Andrew C wrote:
> > Hi all,
>
> Hi,
>
> > I'm running into some critical errors with openJDK/JRE versions 16/18 and
> > trying to run JSampler. It appears there are some older classes that are
> no
> > longer supported in these versions or perhaps need a bit more wriggling
> to
> > accommodate the JSampler code?
> >
> > Exception in thread "AWT-EventQueue-0" java.lang.IllegalAccessError:
> class
> > org.jsampler.view.fantasia.basic.PixmapPane (in unnamed module
> @0x248d4f4a)
> > cannot access class sun.swing.plaf.synth.Paint9Painter (in module
> java.des
> > ktop) because module java.desktop does not export sun.swing.plaf.synth
> to u
> > nnamed module @0x248d4f4a
> >
> > I know this is/was(?) Grishata's project and I lack the knowledge to even
> > begin trying to fix this up, but was wondering if anyone else has
> > encountered this and if there are workarounds for it?
>
> Yes, one of the following, but probably not an answer that you like:
>
> - Use QSampler instead of JSampler.
>
> or
>
> - Use an older Java SDK.
>
> or
>
> - Try fixing the issue in JSampler's source code.
>
> When you look at the Subversion repository [1] you will see that the last
> change on JSampler was almost 10 years ago. It is almost a miracle that it
> still worked for such a long time without any maintenance changes.
>
> [1]
> http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/jsampler/trunk/?view=log
>
> > The alternative, if I cannot get it working would have to be diving into
> > sending LSCP commands to Linuxsampler via Netcat. That should be fun! ;)
>
> Or you just use QSampler, setup your session with mouse as usual, and if
> you
> still want to use LSCP from the command line you can just save your session
> with QSampler which saves it as LSCP file. So you would have an easy
> starting
> point from there.
>
> > A question for Christian, but is it possible through LSCP to tell
> > Linuxsampler to open gigedit "Live" on an instrument, so as to edit in
> > real-time, or was that a special function of JSampler?
>
> Sure! Both JSampler and QSampler control the sampler via LSCP. So
> everything
> they do, you can do as well. In this case it is
>
>         EDIT CHANNEL INSTRUMENT <sampler-channel>
>
>
> http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html#rfc.section.6.9.1
>
> >
> > Cheers,
> >
> > Andrew.
>
>
>
>
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] "GET" LSCP commands to linuxsampler sometimes don't return data

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

On Dienstag, 21. Dezember 2021 15:46:17 CET Andrew C wrote:
> Hi,
> 
> I'm hacking together a quick-and-dirty bash script for controlling/setting
> up audio/midi interfaces in Linuxsampler by sending LSCP commands.
> 
> Sending the commands seems absolutely fine, but using the 'GET' commands to
> recieve data from Linuxsampler, for example info about a sampler channel,
> don't appear to return data consistently or "in time"?
> 
> Command I'm using:
> echo "GET CHANNEL INFO 1" | nc -q 1 -t localhost 8888
> 
> Sometimes it'll return the channel info immediately, other times
> Linuxsampler returns nothing at all, though the connection is established
> and terminated.

I guess you were sending another LSCP command in parallel while that happened,
e.g. loading an instrument in foreground.

The LSCP server is currently single-threaded:
http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/linuxsampler/trunk/src/network/lscpserver.h?revision=2534&view=markup

So the LSCP server only executes one command at a time, which explains why
your "GET CHANNEL INFO" sometimes takes a moment before completing. So far 
this was not an issue for anybody, at least nobody complained FWIW in all
these years.

In the meantime you might just load your instruments in the background for not
blocking the LSCP server for too long.

BTW we also have a dedicated command line utility that might be a bit more
convenient to play around with LSCP:
http://doc.linuxsampler.org/Release_Notes/LinuxSampler_2_0_0/#lscp_shell

> Thanks,
> 
> Andrew.

Re: [Linuxsampler-devel] JSampler java classes bugfixes?

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

On Montag, 20. Dezember 2021 10:52:50 CET Andrew C wrote:
> Hi all,

Hi,

> I'm running into some critical errors with openJDK/JRE versions 16/18 and
> trying to run JSampler. It appears there are some older classes that are no
> longer supported in these versions or perhaps need a bit more wriggling to
> accommodate the JSampler code?
> 
> Exception in thread "AWT-EventQueue-0" java.lang.IllegalAccessError: class
> org.jsampler.view.fantasia.basic.PixmapPane (in unnamed module @0x248d4f4a)
> cannot access class sun.swing.plaf.synth.Paint9Painter (in module java.des
> ktop) because module java.desktop does not export sun.swing.plaf.synth to u
> nnamed module @0x248d4f4a
> 
> I know this is/was(?) Grishata's project and I lack the knowledge to even
> begin trying to fix this up, but was wondering if anyone else has
> encountered this and if there are workarounds for it?

Yes, one of the following, but probably not an answer that you like:

- Use QSampler instead of JSampler.

or

- Use an older Java SDK.

or

- Try fixing the issue in JSampler's source code.

When you look at the Subversion repository [1] you will see that the last
change on JSampler was almost 10 years ago. It is almost a miracle that it
still worked for such a long time without any maintenance changes.

[1] http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/jsampler/trunk/?view=log

> The alternative, if I cannot get it working would have to be diving into
> sending LSCP commands to Linuxsampler via Netcat. That should be fun! ;)

Or you just use QSampler, setup your session with mouse as usual, and if you
still want to use LSCP from the command line you can just save your session
with QSampler which saves it as LSCP file. So you would have an easy starting
point from there.

> A question for Christian, but is it possible through LSCP to tell
> Linuxsampler to open gigedit "Live" on an instrument, so as to edit in
> real-time, or was that a special function of JSampler?

Sure! Both JSampler and QSampler control the sampler via LSCP. So everything
they do, you can do as well. In this case it is

	EDIT CHANNEL INSTRUMENT <sampler-channel>

http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html#rfc.section.6.9.1

> 
> Cheers,
> 
> Andrew.

[Linuxsampler-devel] "GET" LSCP commands to linuxsampler sometimes don't return data

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

Hi,

I'm hacking together a quick-and-dirty bash script for controlling/setting
up audio/midi interfaces in Linuxsampler by sending LSCP commands.

Sending the commands seems absolutely fine, but using the 'GET' commands to
recieve data from Linuxsampler, for example info about a sampler channel,
don't appear to return data consistently or "in time"?

Command I'm using:
echo "GET CHANNEL INFO 1" | nc -q 1 -t localhost 8888

Sometimes it'll return the channel info immediately, other times
Linuxsampler returns nothing at all, though the connection is established
and terminated.

Thanks,

Andrew.

[Linuxsampler-devel] JSampler java classes bugfixes?

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

Hi all,

I'm running into some critical errors with openJDK/JRE versions 16/18 and
trying to run JSampler. It appears there are some older classes that are no
longer supported in these versions or perhaps need a bit more wriggling to
accommodate the JSampler code?

Exception in thread "AWT-EventQueue-0" java.lang.IllegalAccessError: class
org.jsampler.view.fantasia.basic.PixmapPane (in unnamed module @0x248d4f4a)
cannot access class sun.swing.plaf.synth.Paint9Painter (in module java.des
ktop) because module java.desktop does not export sun.swing.plaf.synth to u
nnamed module @0x248d4f4a

I know this is/was(?) Grishata's project and I lack the knowledge to even
begin trying to fix this up, but was wondering if anyone else has
encountered this and if there are workarounds for it?

The alternative, if I cannot get it working would have to be diving into
sending LSCP commands to Linuxsampler via Netcat. That should be fun! ;)

A question for Christian, but is it possible through LSCP to tell
Linuxsampler to open gigedit "Live" on an instrument, so as to edit in
real-time, or was that a special function of JSampler?

Cheers,

Andrew.

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

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

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

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

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

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

   gtkmm 3.10.1 requires at least glibmm 2.50.0, found 2.10.1 though

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

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

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

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

CU
Christian

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

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

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

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

Andrew.

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

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

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

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

Hi, it's me again :)

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

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

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

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

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

Thanks,
Andrew.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CU
Christian

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

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

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

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

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

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

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


Cheers,
Kolja

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

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

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

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

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

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

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

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

CU
Christian

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

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

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

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

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

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

Has anyone else seen this?

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

Cheers,
Kolja

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

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

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

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

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

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

Cheers,
Kolja

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

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

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

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

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

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

CU
Christian

Re: [Linuxsampler-devel] pango/gtkmm3?

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

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

Cheers,
kolja

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

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

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

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

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

Looks quite like the other one to me...

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

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

After the crash, I typed 
bt

and got:

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


Cheers,
Kolja

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

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

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

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

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

Looks quite like the other one to me...

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

Cheers,
Kolja

Re: [Linuxsampler-devel] pango/gtkmm3?

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

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

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

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

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

CU
Christian

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

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

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

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

	https://bugs.linuxsampler.org/

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

CU
Christian

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

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

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

Cheers,
Kolja

Re: [Linuxsampler-devel] pango/gtkmm3?

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

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

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

My package-manager states:

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

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

Cheers,
Kolja