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

Re: [Linuxsampler-devel] [linuxsampler-devel] Scripting keyswitches in NKSP

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

Hi Christian,

Many thanks for that indepth explanation.

gig_set_dim_zone was my next area to investigate, but I had forgotten you
could do things like $newnote := play_note.

My test script looks like this now and it works, selecting the specific
dimension (i'm not sure if "ignore_event" is necessary):

on init
declare $newnote
end on

on note

ignore_event

$newnote := play_note($EVENT_NOTE, $EVENT_VELOCITY, -1, -2)
gig_set_dim_zone($newnote, $GIG_DIM_SMARTMIDI, 6)

end on

Originally I was doing the following and not understanding why it didn't
work:

gig_set_dim_zone($newnote, $GIG_DIM_SMARTMIDI, 6)
play_note($EVENT_NOTE, $EVENT_VELOCITY, -1, -2)

Thanks again,

Andrew.

Re: [Linuxsampler-devel] [linuxsampler-devel] Scripting keyswitches in NKSP

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

On Donnerstag, 27. Juni 2019 12:34:52 CEST Christian Schoenebeck wrote:
> to check for a certain key currently being pressed down and then switch to
> the desired dimension zone of the smart midi dimension:
> 
> 	gig_set_dim_zone($newNote, $GIG_DIM_SMART_MIDI, 2)
> 
> where the last argument stands for the precise dimension region zone you
> want to switch to.

Actually when I thought more about it, the following should actually be 
sufficient for your case:

on note
	...
	gig_set_dim_zone($EVENT_ID, $GIG_DIM_KEYBOARD, 2)
end note

Because gig_set_dim_zone() should actually always override the sampler's 
built-in dimension region selection. So the script's selection should always 
have precedence.

$EVENT_ID is a built-in variable for the current event type, in the note event 
handler that's the note-on event.

CU
Christian

Re: [Linuxsampler-devel] [linuxsampler-devel] Scripting keyswitches in NKSP

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

On Donnerstag, 27. Juni 2019 10:36:54 CEST Andrew C wrote:
> Am I SOL on scripting MIDI notes that can affect keyswitch areas of the
> keyboard?
> While I thought set_gig_dimension would point me in the right direction,
> but it does not seem to have any bearing on the keyswitch dimension.

These are two different things:

The keyswitch dimension is the standard solution that requires no scripting at 
all. So with that solution you just a) add a "keyboard" dimension with gigedit 
and b) define the keyswitching range with gigedit (low and high note of the 
keyswitching range. That's it.

If you want to implement keyswitchting by script instead, i.e. because you 
want a more fine graded keyswitching behaviour than the standard built-in one 
described above, then don't use the "keyboard" dimension. In fact when doing 
such things by script then I recommend you to pick a dimension type which 
would not trigger implied actions by the sampler. Because if you pick e.g. the 
"modulation wheel" dimension, then of course the sampler would switch 
dimensions if you rotate the modulation wheel, likewise if you pick the 
"keyboard" dimension the sampler would switch dimension when the keys of the 
instrument's keyswitch range are triggered.

In the NKSP instrument scripting examples that you find online, e.g. on the old 
LS  2.0 release notes:
http://doc.linuxsampler.org/Release_Notes/LinuxSampler_2_0_0/
I commonly used the "smartmidi" dimension instead for the purpose of switching 
the dimension regions by scripts, because that dimension type is not switched 
automatically by the sampler unless you have created iMIDI rules. [ Probably a 
more cleaner solution would be if we introduce some dedicated, new dimension 
type in the gig format for scripting purposes instead. ]. So with scripting 
you would e.g.. use

	if (%KEY_DOWN[28])

to check for a certain key currently being pressed down and then switch to the 
desired dimension zone of the smart midi dimension:

	gig_set_dim_zone($newNote, $GIG_DIM_SMART_MIDI, 2)

where the last argument stands for the precise dimension region zone you want 
to switch to.

About change_note() and set_event_par() not having any affect on the built-in 
"keyboard" dimension: that is not a bug, that's intended behaviour. These 
functions are intended to modify voice parameters, they are not really 
intended as MIDI filters. For MIDI event filtering KSP has a separate event 
handler which is currently not implemented in LS yet.

What you could also do though in the "on note" event handler you could use the 
ignore_event() function to drop the respective MIDI note on event, and then 
immediately call play_note() instead and pass the return value of the latter 
to git_set_dim_zone() and switch to the desired dimension zone.

CU
Christian

[Linuxsampler-devel] [linuxsampler-devel] Scripting keyswitches in NKSP

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

Hi all,

Been reading through the NKSP documentation again and trying to undeerstand
how to trigger keyswitches from a script.

All I can find are play_note, change_note and set_par_event

play_note says:
almost like generating a new MIDI note-on event programmatically, with the
difference though ... no MIDI specific note-on handling be done (i.e. it
will have no effect on key switching or on the status of built-in array
variable %KEY_DOWN[]).

change_note says:
MIDI processing tasks of the sampler like exclusive groups (a.k.a. key
groups), key based round robin and all other common MIDI processing tasks
are not affected by this function at all.

and set_par_event's midi note function says (I think?) that it's
functionally identical to change_note

Am I SOL on scripting MIDI notes that can affect keyswitch areas of the
keyboard?
While I thought set_gig_dimension would point me in the right direction,
but it does not seem to have any bearing on the keyswitch dimension.

Thanks,

Andrew.

Re: [Linuxsampler-devel] [linuxsampler-devel] Crossfade bug workaround

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

On Mittwoch, 26. Juni 2019 10:35:27 CEST Andrew C wrote:
> Dunno if this is a bug or a feature, but I've figured out a reliable and
> reproducible way to get around the crossfade weirdness in gigedit.
> 
> The problem is if you have a single dimension selected and start trying to
> move the crossfade-in start, crossfade-in end, etc sliders, they all reset
> back to 0.

Hmm, sounds like a bug. :)

CU
Christian

Re: [Linuxsampler-devel] [linuxsampler-devel] Replace all samples

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

On Mittwoch, 26. Juni 2019 10:28:34 CEST Andrew C wrote:
> Hi all,
> 
> If I extract all wav files from a gig file for external audio processing,
> then use the "replace all samples", will the imported/replaced samples
> stayed mapped to their respective regions?

Yes, that's the purpose of that function: just replacing the raw sample data 
with new sample data without touching the instruments at all. So this feature 
is merely intended to fix issues with samples.

Note however that this also means that it won't even touch the loop parameters 
by default stored in the instruments, nor the sample playback start positions, 
nor the sample's root note stored in the instruments.

The samples' major parameters like loop points, root note (a.k.a. unity note), 
fine tuning are stored in the gig format on 2 levels:

1. directly on the samples: You can see them as kind of default parameters for 
the sample which are only used when assignign (or re-assigning) a sample to 
dimension regions of an instrument. So these parameters on sample level are 
never accessed directly by either LS or GSt at playback runtime.

2. on the individual dimension regions of the instruments: These are the 
actual parameters being accessed by the samplers at playback runtime. The 
purpose is that you may adjust the original sample's loop points, root note, 
fine tuning for instruments compared to its original parameters stored with the 
sample. Furthermore you may even adjust them for individual dimension regions, 
e.g. slightlty different playback start positions or slight different loop 
positions on round robin dimension, etc.

Note that in the edit menu of gigedit there are checkbox options whether the 
sample's original parameters shall be assigned to the dimension regions when 
assigning a sample to dimension regions by drag & drop.

CU
Christian

[Linuxsampler-devel] [linuxsampler-devel] Crossfade bug workaround

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

Hi again all.

Dunno if this is a bug or a feature, but I've figured out a reliable and
reproducible way to get around the crossfade weirdness in gigedit.

The problem is if you have a single dimension selected and start trying to
move the crossfade-in start, crossfade-in end, etc sliders, they all reset
back to 0.

The solution I've found is to first select the "All dimensions" tickbox at
the bottom and move a slider. This makes the blue crossfade lines visible
and the crossfade settings stay.

After this, you can simply untick the "all dimensions" box and edit each
individual crossfades like normal without the crossfades settings
disappearing.

Hope this helps somebody,

Andrew.

[Linuxsampler-devel] [linuxsampler-devel] Replace all samples

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

Hi all,

If I extract all wav files from a gig file for external audio processing,
then use the "replace all samples", will the imported/replaced samples
stayed mapped to their respective regions?

Thanks,

Andrew.

[Linuxsampler-devel] [linuxsampler-devel] Looking to sponsor gigedit crossfade dialog functionality.

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

Hi all,

I'd be pretty interested in donating some money towards the development of
working crossfade dialog boxes in gigedit. If anyone would like to take me
up on the offer, please contact off-list.

I'd be willing to put 200 euro towards development of the feature, as
getting the dynamic crossfade feature working in gigedit properly would aid
me greatly due to my own playing technique and the midi controller I
currently use, and for creating custom gig files.

Thanks,

Andrew.

Re: [Linuxsampler-devel] GTKMM version for gigedit

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

Think I mentioned it up there, I'm running Void Linux and still getting to
grips with it's package management + running from a minimal install
environment (getting the dev environment set up and working was half the
battle, as seen above).

Thanks!

Andrew.


On Fri, Jun 7, 2019 at 8:03 PM Christian Schoenebeck <
sch...@li...> wrote:

> You haven't mentioned which distro you are using. But usually you can
> avoid a
> huge bunch of hassle (which you obviously had) by just taking the
> packaging
> scripts for your specific distro instead of compiling and installing
> everything
> manually like you did.
>
> For instance if you compile packages for Debian with
>
>         dpkg-buildpackage -b
>
> Then it already tells you which development packages you might need to
> install, it takes care about the correct library dependencies, the correct
> installation directories, approprirate configure script arguments and much
> more. Plus your installation would be much cleaner and easier to upgrade
> later
> on.
>
> CU
> Christian
>
> On Freitag, 7. Juni 2019 12:07:10 CEST Andrew C wrote:
> > Last message in this thread.
> > Got gigedit running after a little poking and prodding.
> >
> > I was wary of the GTK version and I had chosen the gtkmm 2.24 package,
> not
> > the 3.24 package.
> > Obviously this caused gigedit to try and load the gtkmm 2.24 library and
> > gtk3, hence my issues.
> >
> > Uninstalled gtkmm2.24 and then install gtkmm3.24. I recompiled and
> finally
> > I got gigedit running.
> >
> > Andrew.
> >
> > On Thu, Jun 6, 2019 at 7:11 PM Andrew C <cou...@gm...> wrote:
> > > Hi Christian,
> > >
> > > I think the latest commit to libgig fixed it (though I didn't see a
> > > changelog on the website). So I have successfully compiled and
> installed
> > > libgig.
> > >
> > > Now, onto Linuxsampler.
> > > First issue, can't find libgig. A misconfiguration on my end? Had to do
> > > "export PKG_CONFIG_PATH=/usr/local/lib/pkg-config:$PKG_CONFIG_PATH" and
> > > configure ran fine.
> > > Second issue, cannot find parser.h. Easy.. I just did a "make parser".
> > > Third roadblock: "g++ error: lscp_shell_reference.cpp: No such file or
> > > directory. g++: fatal error: no input files". Needed to install
> > > perl-XML-parser.
> > >
> > > Configuration and compilation of gigedit went without a hitch (just
> needed
> > > to install intltool and gtkmm 2.24).
> > >
> > > I'll admit, these issues were more due to my system than the code.
> > > Hopefully someone will find this info useful at some point in the
> future.
> > >
> > > Last issue I've got that I'll need to look at over the weekend is when
> I
> > > try and run gigedit: "GTK+ 2.x symbols detected. Using GTK+ 2.x and
> GTK+3
> > > in the same process is not supported."
> > >
> > > Thanks,
> > >
> > > Andrew.
> > >
> > > On Wed, Jun 5, 2019 at 11:26 AM Andrew C <cou...@gm...>
> wrote:
> > >> Hi Christian,
> > >>
> > >> No, these were the latest SVN sources with a re-generated configure
> > >> script from make -f Makefile.svn
> > >>
> > >> Thanks,
> > >>
> > >> Andrew.
> > >>
> > >> On Wed, Jun 5, 2019 at 10:14 AM Christian Schoenebeck <
> > >>
> > >> sch...@li...> wrote:
> > >>> On Mittwoch, 5. Juni 2019 08:38:10 CEST Andrew C wrote:
> > >>> > Thanks for the quick response. I've started the compilation on Void
> > >>>
> > >>> from
> > >>>
> > >>> > the latest svn versions, but I'm running into trouble already with
> the
> > >>> > ./configure for libgig:
> > >>> >
> > >>> > checking whether the g++ linker (/bin/ld -m elf_x86_64) supports
> > >>> > shared
> > >>> > libraries... yes
> > >>> > checking dynamic linker characteristics... (cached) GNU/Linux ld.so
> > >>> > checking how to hardcode library paths into programs... immediate
> > >>> > checking whether byte ordering is bigendian... no
> > >>> > ./configure: 15609: ./configure: Syntax error: word unexpected
> > >>>
> > >>> (expecting
> > >>>
> > >>> > ")")
> > >>>
> > >>> Try to regenerate the configure script:
> > >>>         make -f Makefile.svn
> > >>>         ./configure
> > >>>         make
> > >>>
> > >>> Were these tarball sources with pregenerated configure script?
> > >>>
> > >>> CU
> > >>> Christian
>
>
>

Re: [Linuxsampler-devel] GTKMM version for gigedit

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

You haven't mentioned which distro you are using. But usually you can avoid a 
huge bunch of hassle (which you obviously had) by just taking the packaging 
scripts for your specific distro instead of compiling and installing everything 
manually like you did.

For instance if you compile packages for Debian with

	dpkg-buildpackage -b

Then it already tells you which development packages you might need to 
install, it takes care about the correct library dependencies, the correct 
installation directories, approprirate configure script arguments and much 
more. Plus your installation would be much cleaner and easier to upgrade later 
on.

CU
Christian

On Freitag, 7. Juni 2019 12:07:10 CEST Andrew C wrote:
> Last message in this thread.
> Got gigedit running after a little poking and prodding.
> 
> I was wary of the GTK version and I had chosen the gtkmm 2.24 package, not
> the 3.24 package.
> Obviously this caused gigedit to try and load the gtkmm 2.24 library and
> gtk3, hence my issues.
> 
> Uninstalled gtkmm2.24 and then install gtkmm3.24. I recompiled and finally
> I got gigedit running.
> 
> Andrew.
> 
> On Thu, Jun 6, 2019 at 7:11 PM Andrew C <cou...@gm...> wrote:
> > Hi Christian,
> > 
> > I think the latest commit to libgig fixed it (though I didn't see a
> > changelog on the website). So I have successfully compiled and installed
> > libgig.
> > 
> > Now, onto Linuxsampler.
> > First issue, can't find libgig. A misconfiguration on my end? Had to do
> > "export PKG_CONFIG_PATH=/usr/local/lib/pkg-config:$PKG_CONFIG_PATH" and
> > configure ran fine.
> > Second issue, cannot find parser.h. Easy.. I just did a "make parser".
> > Third roadblock: "g++ error: lscp_shell_reference.cpp: No such file or
> > directory. g++: fatal error: no input files". Needed to install
> > perl-XML-parser.
> > 
> > Configuration and compilation of gigedit went without a hitch (just needed
> > to install intltool and gtkmm 2.24).
> > 
> > I'll admit, these issues were more due to my system than the code.
> > Hopefully someone will find this info useful at some point in the future.
> > 
> > Last issue I've got that I'll need to look at over the weekend is when I
> > try and run gigedit: "GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+3
> > in the same process is not supported."
> > 
> > Thanks,
> > 
> > Andrew.
> > 
> > On Wed, Jun 5, 2019 at 11:26 AM Andrew C <cou...@gm...> wrote:
> >> Hi Christian,
> >> 
> >> No, these were the latest SVN sources with a re-generated configure
> >> script from make -f Makefile.svn
> >> 
> >> Thanks,
> >> 
> >> Andrew.
> >> 
> >> On Wed, Jun 5, 2019 at 10:14 AM Christian Schoenebeck <
> >> 
> >> sch...@li...> wrote:
> >>> On Mittwoch, 5. Juni 2019 08:38:10 CEST Andrew C wrote:
> >>> > Thanks for the quick response. I've started the compilation on Void
> >>> 
> >>> from
> >>> 
> >>> > the latest svn versions, but I'm running into trouble already with the
> >>> > ./configure for libgig:
> >>> > 
> >>> > checking whether the g++ linker (/bin/ld -m elf_x86_64) supports
> >>> > shared
> >>> > libraries... yes
> >>> > checking dynamic linker characteristics... (cached) GNU/Linux ld.so
> >>> > checking how to hardcode library paths into programs... immediate
> >>> > checking whether byte ordering is bigendian... no
> >>> > ./configure: 15609: ./configure: Syntax error: word unexpected
> >>> 
> >>> (expecting
> >>> 
> >>> > ")")
> >>> 
> >>> Try to regenerate the configure script:
> >>>         make -f Makefile.svn
> >>>         ./configure
> >>>         make
> >>> 
> >>> Were these tarball sources with pregenerated configure script?
> >>> 
> >>> CU
> >>> Christian

Re: [Linuxsampler-devel] GTKMM version for gigedit

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

Last message in this thread.
Got gigedit running after a little poking and prodding.

I was wary of the GTK version and I had chosen the gtkmm 2.24 package, not
the 3.24 package.
Obviously this caused gigedit to try and load the gtkmm 2.24 library and
gtk3, hence my issues.

Uninstalled gtkmm2.24 and then install gtkmm3.24. I recompiled and finally
I got gigedit running.

Andrew.

On Thu, Jun 6, 2019 at 7:11 PM Andrew C <cou...@gm...> wrote:

> Hi Christian,
>
> I think the latest commit to libgig fixed it (though I didn't see a
> changelog on the website). So I have successfully compiled and installed
> libgig.
>
> Now, onto Linuxsampler.
> First issue, can't find libgig. A misconfiguration on my end? Had to do
> "export PKG_CONFIG_PATH=/usr/local/lib/pkg-config:$PKG_CONFIG_PATH" and
> configure ran fine.
> Second issue, cannot find parser.h. Easy.. I just did a "make parser".
> Third roadblock: "g++ error: lscp_shell_reference.cpp: No such file or
> directory. g++: fatal error: no input files". Needed to install
> perl-XML-parser.
>
> Configuration and compilation of gigedit went without a hitch (just needed
> to install intltool and gtkmm 2.24).
>
> I'll admit, these issues were more due to my system than the code.
> Hopefully someone will find this info useful at some point in the future.
>
> Last issue I've got that I'll need to look at over the weekend is when I
> try and run gigedit: "GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+3
> in the same process is not supported."
>
> Thanks,
>
> Andrew.
>
> On Wed, Jun 5, 2019 at 11:26 AM Andrew C <cou...@gm...> wrote:
>
>> Hi Christian,
>>
>> No, these were the latest SVN sources with a re-generated configure
>> script from make -f Makefile.svn
>>
>> Thanks,
>>
>> Andrew.
>>
>> On Wed, Jun 5, 2019 at 10:14 AM Christian Schoenebeck <
>> sch...@li...> wrote:
>>
>>> On Mittwoch, 5. Juni 2019 08:38:10 CEST Andrew C wrote:
>>> > Thanks for the quick response. I've started the compilation on Void
>>> from
>>> > the latest svn versions, but I'm running into trouble already with the
>>> > ./configure for libgig:
>>> >
>>> > checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
>>> > libraries... yes
>>> > checking dynamic linker characteristics... (cached) GNU/Linux ld.so
>>> > checking how to hardcode library paths into programs... immediate
>>> > checking whether byte ordering is bigendian... no
>>> > ./configure: 15609: ./configure: Syntax error: word unexpected
>>> (expecting
>>> > ")")
>>>
>>> Try to regenerate the configure script:
>>>
>>>         make -f Makefile.svn
>>>         ./configure
>>>         make
>>>
>>> Were these tarball sources with pregenerated configure script?
>>>
>>> CU
>>> Christian
>>>
>>

Re: [Linuxsampler-devel] GTKMM version for gigedit

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

Hi Christian,

I think the latest commit to libgig fixed it (though I didn't see a
changelog on the website). So I have successfully compiled and installed
libgig.

Now, onto Linuxsampler.
First issue, can't find libgig. A misconfiguration on my end? Had to do
"export PKG_CONFIG_PATH=/usr/local/lib/pkg-config:$PKG_CONFIG_PATH" and
configure ran fine.
Second issue, cannot find parser.h. Easy.. I just did a "make parser".
Third roadblock: "g++ error: lscp_shell_reference.cpp: No such file or
directory. g++: fatal error: no input files". Needed to install
perl-XML-parser.

Configuration and compilation of gigedit went without a hitch (just needed
to install intltool and gtkmm 2.24).

I'll admit, these issues were more due to my system than the code.
Hopefully someone will find this info useful at some point in the future.

Last issue I've got that I'll need to look at over the weekend is when I
try and run gigedit: "GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+3
in the same process is not supported."

Thanks,

Andrew.

On Wed, Jun 5, 2019 at 11:26 AM Andrew C <cou...@gm...> wrote:

> Hi Christian,
>
> No, these were the latest SVN sources with a re-generated configure script
> from make -f Makefile.svn
>
> Thanks,
>
> Andrew.
>
> On Wed, Jun 5, 2019 at 10:14 AM Christian Schoenebeck <
> sch...@li...> wrote:
>
>> On Mittwoch, 5. Juni 2019 08:38:10 CEST Andrew C wrote:
>> > Thanks for the quick response. I've started the compilation on Void from
>> > the latest svn versions, but I'm running into trouble already with the
>> > ./configure for libgig:
>> >
>> > checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
>> > libraries... yes
>> > checking dynamic linker characteristics... (cached) GNU/Linux ld.so
>> > checking how to hardcode library paths into programs... immediate
>> > checking whether byte ordering is bigendian... no
>> > ./configure: 15609: ./configure: Syntax error: word unexpected
>> (expecting
>> > ")")
>>
>> Try to regenerate the configure script:
>>
>>         make -f Makefile.svn
>>         ./configure
>>         make
>>
>> Were these tarball sources with pregenerated configure script?
>>
>> CU
>> Christian
>>
>

Re: [Linuxsampler-devel] GTKMM version for gigedit

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

Hi Christian,

No, these were the latest SVN sources with a re-generated configure script
from make -f Makefile.svn

Thanks,

Andrew.

On Wed, Jun 5, 2019 at 10:14 AM Christian Schoenebeck <
sch...@li...> wrote:

> On Mittwoch, 5. Juni 2019 08:38:10 CEST Andrew C wrote:
> > Thanks for the quick response. I've started the compilation on Void from
> > the latest svn versions, but I'm running into trouble already with the
> > ./configure for libgig:
> >
> > checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
> > libraries... yes
> > checking dynamic linker characteristics... (cached) GNU/Linux ld.so
> > checking how to hardcode library paths into programs... immediate
> > checking whether byte ordering is bigendian... no
> > ./configure: 15609: ./configure: Syntax error: word unexpected (expecting
> > ")")
>
> Try to regenerate the configure script:
>
>         make -f Makefile.svn
>         ./configure
>         make
>
> Were these tarball sources with pregenerated configure script?
>
> CU
> Christian
>

Re: [Linuxsampler-devel] GTKMM version for gigedit

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

On Mittwoch, 5. Juni 2019 08:38:10 CEST Andrew C wrote:
> Thanks for the quick response. I've started the compilation on Void from
> the latest svn versions, but I'm running into trouble already with the
> ./configure for libgig:
> 
> checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
> libraries... yes
> checking dynamic linker characteristics... (cached) GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> checking whether byte ordering is bigendian... no
> ./configure: 15609: ./configure: Syntax error: word unexpected (expecting
> ")")

Try to regenerate the configure script:

	make -f Makefile.svn
	./configure
	make

Were these tarball sources with pregenerated configure script?

CU
Christian

Re: [Linuxsampler-devel] GTKMM version for gigedit

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

Hi Christian,

Thanks for the quick response. I've started the compilation on Void from
the latest svn versions, but I'm running into trouble already with the
./configure for libgig:

checking whether the g++ linker (/bin/ld -m elf_x86_64) supports shared
libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether byte ordering is bigendian... no
./configure: 15609: ./configure: Syntax error: word unexpected (expecting
")")


Bash version is:

bash --version
GNU bash, version 5.0.7(1)-release (x86_64-unknown-linux-gnu)

Thanks,

Andrew.

Re: [Linuxsampler-devel] GTKMM version for gigedit

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

On Donnerstag, 30. Mai 2019 14:13:18 CEST Andrew C wrote:
> Hi all,

Hi Andrew.

> It's me again!
> Just wanted to know what version of GTKMM is required for compiling gigedit?
> 
> I'm planning on doing a Linuxsampler build on Void Linux (will be using
> this as my "workhorse" distro) this weekend, hopefully it'll be relatively
> painless.
> The Void Linux repos have gtkmm 3.x and 2.x available.

gigedit supports gtk(mm) 2.x and 3.x. So that's completely up to you which one 
to pick. There should not be any problem with one of these.

Just don't use the gtk(mm) 4.x development branch. 4.x should compile with 
gigedit, but behaviour is broken and fundamental features are missing. Chances 
are that gtk(mm) 4.x will never be supported by gigedit due to features being 
removed without replacement in gtk(mm) 4.x.

Please note gtk versions > 3.24 is not Gtk 3, but actually already the Gtk 4 
development branch version. So take care about that when you pick a package.

CU
Christian

[Linuxsampler-devel] GTKMM version for gigedit

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

Hi all,

It's me again!
Just wanted to know what version of GTKMM is required for compiling gigedit?

I'm planning on doing a Linuxsampler build on Void Linux (will be using
this as my "workhorse" distro) this weekend, hopefully it'll be relatively
painless.
The Void Linux repos have gtkmm 3.x and 2.x available.

Andrew.

Re: [Linuxsampler-devel] Using LinuxSampler as plugin on Windows

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

On Freitag, 24. Mai 2019 15:53:08 CEST David Bolton wrote:
> IMO the best solution on long term would be Ardour running VST plugins in
> 
> > their own process, instead of loading VST plugins directly into the Ardour
> > process.
> 
> I will pass this information along to Ardour via my original post:
> https://discourse.ardour.org/t/linuxsampler-under-windows/89908/12

Yes, I see, expected old answer from their side on this issue.

We are in 2019, and process separation for audio plugin scales well even on 
iOS (which even wraps that into a virtualized container). I mean these days 
even nested virtualization starts to be come a topic, which is far more 
expensive than just process separation.

The thing that they probably don't see is that process separation for plugins 
is usually done by using *one* process for all instances of one particular 
plugin. So both resource consumption, as well as the required amount of 
context switches is far less than the typical performance calculation that I 
read from Ardour developers several times before. It usually requires 2 
context switches per period for all instances of one plugin, no matter how 
many tracks you have on DAW side, because a plugin like LS is not an insert 
effect.

And the argument that process separation was even unprofessional is not 
rational. Logic supports _optional_ process separation for AU plugins on macOS 
already. If you add this feature as optional setting per plugin then nobody 
gets hurt. But I don't expect their opinion to change on this issue any time 
soon.

Potential library conflicts is an issue when only supporting in-process 
plugins, which I don't expect to become less of a problem in future. Just take 
the Gtk libs as an example: Gtk currently consists of around 24 separate 
libraries, many of them are not even designed for static linking. They are 
loading modules for core functionalities at runtime (plus various resources 
with absolute pathes) which cannot be linked statically with stock gtk, at 
least not without heavily patching them (and heavy continuous maintenance of 
the gtk libs on our side).

Another fact is: plugins may crash; some(times) more, some(times) less. From 
usability point of view it is just contempoary to accept that this may indeed 
happen, and that this should not tear down the entire DAW (like it is 
inevitable with in-process plugins), only the causing plugin should crash, and 
the user should get a clear error message by the DAW which plugin crashed, and 
asking the user whether the plugin shall be reloaded.

> Thank you. The new version of qsampler opens without errors. I had a little
> trouble with setting up the audio device. Qsampler didn't explain why
> (except messages like "AudioOutputDeviceAsio (errno=100)" and "
> lscp_get_audio_device_info:
> DESCRIPTION (errno=0)").However when I opened JSampler it triggered a more
> instructive error message from linuxsampler: "AudioOutputDeviceAsio: Can't
> find any ASIO-capable sound card. Make sure you have an ASIO driver
> installed for your sound device. If you are using a consumer sound card
> that does not provide an ASIO driver to be installed, then consider
> installing an alternative like ASIO4ALL."

I hooked off from Windows years ago, and the current ASIO driver on LS side 
are more than 10 years old. So yes, there are certainly things to be improved 
on that driver. Probably there is even a better alternative than ASIO4ALL 
nowadays. Maybe people still working on Windows know more on that.

> > > If I open JSampler, it complains about not being able to find javaw.exe
> > > When it opens I get the following error
> > > message: "Connecting to LinuxSampler: Can't establish connection"
> > 
> > No idea about that one. I have to add, I am actually no longer using
> > Windows
> > for several years, same applies to Java.
> 
> These errors have gone away now.

I assume that's because you changed the PATH variable by using Windows' system 
settings graphical user interface, which requires a reboot for the PATH 
variable change to become effective. Next time you can also set the PATH 
variable immediately without rebooting from the terminal by doing:

	SET PATH=%PATH%;C:\yournewpath

That way you can experiment with PATH issues more effectively.

> In the meantime I have another sampler working on Windows, but I'm happy to
> continue testing if needed.

No problem!

As you can see, the Windows version of LS should probably receive better 
maintenance. However since I am not using Windows anymore, it is not my 
personal focus. I mean I try to fix reported issues wherever I can, but beyond 
minor changes (like the missing Qt5Network DLL discussed here) it usually 
requires testing on Windows of course as well, so ... :)

CU
Christian

Re: [Linuxsampler-devel] Using LinuxSampler as plugin on Windows

[David B. <dav...@gm...>]

Christian,

Thank you for your detailed response.

IMO the best solution on long term would be Ardour running VST plugins in
> their own process, instead of loading VST plugins directly into the Ardour
> process.
>

I will pass this information along to Ardour via my original post:
https://discourse.ardour.org/t/linuxsampler-under-windows/89908/12


> > Starting LSCP network server (0.0.0.0:8888)...LSCPServer: Could not bind
> > server socket, retrying for 180 seconds...gave up!
>

Rebooting fixed the issue as you suggested.


> > qsampler.exe - System Error
>
> I just fixed that in our Windows installer scripts. So when you download
> the
> latest installer, that error should be gone now.
>

Thank you. The new version of qsampler opens without errors. I had a little
trouble with setting up the audio device. Qsampler didn't explain why
(except messages like "AudioOutputDeviceAsio (errno=100)" and "
lscp_get_audio_device_info:
DESCRIPTION (errno=0)").However when I opened JSampler it triggered a more
instructive error message from linuxsampler: "AudioOutputDeviceAsio: Can't
find any ASIO-capable sound card. Make sure you have an ASIO driver
installed for your sound device. If you are using a consumer sound card
that does not provide an ASIO driver to be installed, then consider
installing an alternative like ASIO4ALL."

I installed ASIO4ALL and it appeared to work well with LinuxSampler (I
could loads the instrument samples and qsampler reacted to MIDI signals
(with the green flashing light). Maybe there's a problem with ASIO4ALL and
my sound card or setup.  I tried rebooting, but still no sound. I can try
on a different machine later.


> > If I open JSampler, it complains about not being able to find javaw.exe
> > When it opens I get the following error
> > message: "Connecting to LinuxSampler: Can't establish connection"
>
> No idea about that one. I have to add, I am actually no longer using
> Windows
> for several years, same applies to Java.
>

These errors have gone away now.

In the meantime I have another sampler working on Windows, but I'm happy to
continue testing if needed.

David

Re: [Linuxsampler-devel] Using LinuxSampler as plugin on Windows

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

On Donnerstag, 23. Mai 2019 14:06:51 CEST David Bolton wrote:
> Here's the messages I get when I launch linuxsampler.exe from the command
> line:
> 
> C:\Program Files\LinuxSampler\64>linuxsampler.exe
> LinuxSampler 2.1.0.svn8
> Copyright (C) 2003,2004 by Benno Senoner and Christian Schoenebeck
> Copyright (C) 2005-2019 Christian Schoenebeck
> Binary built: Mar 11 2019
> Detected features: MMX SSE SSE2
> Automatic Stacktrace: Off
> Creating Sampler...OK

So like I expcted, the stand-alone app runs there. Then the problem you have 
with the LS VST not launching in Ardour is indeed very likely caused by a 
conflicting libstdc++ version.

Background: we are currently still using GCC as compiler on our build server 
for compiling the daily snapshot installers for Windows. And I am pretty sure 
your Ardour binary was compiled with clang. The two compilers use their own 
implementation of libstdc++, and both cannot be loaded into one process at the 
same time.

Like already suggested in the Ardour forum, one workaround would be if we 
statically link libstdc++ into our binaries (instead of letting our binaries 
load libstdc++ dynamically as DLL on startup like it is now). But that is 
tricky and may introduce new problems, since all libs used must then use our 
statically linked libstdc++ instead.

Another option would be if we just switch to clang for compiling the Windows 
installer. But then it would cause other DAWs getting the same VST issue if 
they were compiled with GCC instead.

IMO the best solution on long term would be Ardour running VST plugins in 
their own process, instead of loading VST plugins directly into the Ardour 
process. That way libs loaded by VST plugins would no longer conflict with libs 
of other plugins or host app (i.e. Ardour).  Because even if we do some of the 
workarounds mentioned above, the next issue would already be ahead: e.g. if 
you want to edit a gig file currently being played back as VST instrument in 
Ardour, then our gigedit instrument editor would try to load Gtk3 libs, and 
Ardour already loaded Gtk2 libs, hence gigedit would never show up on your 
screen.

I know the opinion of Ardour developers is that running plugins in their own 
process would be inefficient due to expensive context switches, but other DAW 
apps like Logic already switched to that new model and performance seems to be 
Ok nowadays. In the end this could also become an optional setting per plugin 
on Ardour side.

Opinions?

> Starting LSCP network server (0.0.0.0:8888)...LSCPServer: Could not bind
> server socket, retrying for 180 seconds...gave up!

That error is probably because the LSCP server crashed with your VST plugin. 
Rebooting should fix that issue.

> If try to open the qsampler.exe stand-alone app, I get the following error:
> 
> ---------------------------
> qsampler.exe - System Error
> ---------------------------
> The code execution cannot proceed because Qt5Network.dll was not found.
> Reinstalling the program may fix this problem.

I just fixed that in our Windows installer scripts. So when you download the 
latest installer, that error should be gone now.

> If I open JSampler, it complains about not being able to find javaw.exe
> (even though I added the javaw.exe folder to the Windows path variable and
> restarted the computer). However, I can manually browse to javaw.exe at
> each start up and JSampler opens. When it opens I get the following error
> message: "Connecting to LinuxSampler: Can't establish connection"

No idea about that one. I have to add, I am actually no longer using Windows 
for several years, same applies to Java.

CU
Christian

Re: [Linuxsampler-devel] Using LinuxSampler as plugin on Windows

[David B. <dav...@gm...>]

Christian,

Thank you for your reply.

Here's the messages I get when I launch linuxsampler.exe from the command
line:

C:\Program Files\LinuxSampler\64>linuxsampler.exe
LinuxSampler 2.1.0.svn8
Copyright (C) 2003,2004 by Benno Senoner and Christian Schoenebeck
Copyright (C) 2005-2019 Christian Schoenebeck
Binary built: Mar 11 2019
Detected features: MMX SSE SSE2
Automatic Stacktrace: Off
Creating Sampler...OK
Registered sampler engines: 'GIG','SF2','SFZ'
Registered MIDI input drivers: MME
Registered audio output drivers: ASIO
Loading instrument editor plugins...OK
Registered instrument editors: 'gigedit'
Registered internal effect systems: LADSPA
Could not scan LADSPA effects: library path 'C:\Program Files\ladspa'
doesn't exist
Registered internal effects: 0
Starting LSCP network server (0.0.0.0:8888)...LSCPServer: Could not bind
server socket, retrying for 180 seconds...gave up!

If try to open the qsampler.exe stand-alone app, I get the following error:

---------------------------
qsampler.exe - System Error
---------------------------
The code execution cannot proceed because Qt5Network.dll was not found.
Reinstalling the program may fix this problem.
---------------------------
OK
---------------------------

(reinstalling the program didn't fix the issue).

If I open JSampler, it complains about not being able to find javaw.exe
(even though I added the javaw.exe folder to the Windows path variable and
restarted the computer). However, I can manually browse to javaw.exe at
each start up and JSampler opens. When it opens I get the following error
message: "Connecting to LinuxSampler: Can't establish connection"

David




On Thu, May 23, 2019 at 10:51 AM Christian Schoenebeck <
sch...@li...> wrote:

> On Dienstag, 21. Mai 2019 13:02:14 CEST David Bolton wrote:
> > I'm having trouble getting LinuxSampler to run as a plugin within Ardour
> on
> > Windows 10.
> >
> > Here's the error message as reported by Ardour:
> > The procedure entry point *ZNSt13runtime_errorC2ERKS* could not be
> located
> > in the dynamic link library C:\Program
> > Files\Steinberg\VstPlugins\LinuxSampler64.dll.
>
> Looks like a version conflict of the C++ stdlib (i.e. clang's stdlib
> already
> been loaded by Ardour vs. GNU's stdlib attempted to be loaded by the LS
> VST
> plugin later on).
>
> Does the LS stand-alone app run?
>
> CU
> Christian
>

Re: [Linuxsampler-devel] Using LinuxSampler as plugin on Windows

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

On Dienstag, 21. Mai 2019 13:02:14 CEST David Bolton wrote:
> I'm having trouble getting LinuxSampler to run as a plugin within Ardour on
> Windows 10.
> 
> Here's the error message as reported by Ardour:
> The procedure entry point *ZNSt13runtime_errorC2ERKS* could not be located
> in the dynamic link library C:\Program
> Files\Steinberg\VstPlugins\LinuxSampler64.dll.

Looks like a version conflict of the C++ stdlib (i.e. clang's stdlib already 
been loaded by Ardour vs. GNU's stdlib attempted to be loaded by the LS VST 
plugin later on).

Does the LS stand-alone app run?

CU
Christian

[Linuxsampler-devel] Using LinuxSampler as plugin on Windows

[David B. <dav...@gm...>]

I'm having trouble getting LinuxSampler to run as a plugin within Ardour on
Windows 10.

Here's the error message as reported by Ardour:
The procedure entry point *ZNSt13runtime_errorC2ERKS* could not be located
in the dynamic link library C:\Program
Files\Steinberg\VstPlugins\LinuxSampler64.dll.

I posted initially in the Ardour forum.
https://discourse.ardour.org/t/linuxsampler-under-windows/89908/13. They
said, "looks like the VST was not statically linked and/or depends on
libraries not present on your system" and suggested reporting to the
LinuxSampler developers.

Happy to run tests as needed.

David

[Linuxsampler-devel] [ANN] The QStuff* Spring Break'19 release batch #1

[Rui N. C. <rn...@rn...>]

Cheers!

Interesting times we're living in...

The first batch to the so called Qstuff* Spring Break'19 is now being
delivered as fully complementary as post-LAC2019 [21] frenzy ;)

And in this batch, we have:
*  QjackCtl 0.5.7 [1]
*  Qsynth 0.5.6 [2]
*  Qsampler 0.5.5 [3]
*  QXGEdit 0.5.4 [4]
*  QmidiCtl 0.5.4 [5]
*  QmidiNet 0.5.4 [6]

All the boring (to death) details, below...


** QjackCtl - JACK Audio Connection Kit Qt GUI Interface [1] **

  QjackCtl 0.5.7 (spring-break'19) is out!

QjackCtl is a(n ageing yet modern, not so 'simple' anymore) Qt [7]
application to control the JACK [8] sound server, for the Linux Audio
[12] infrastructure.

Website:
  https://qjackctl.sourceforge.io
  http://qjackctl.sourceforge.net

Project page:
  http://sourceforge.net/projects/qjackctl

Downloads:
  http://sourceforge.net/projects/qjackctl/files
- source tarball:
  http://download.sf.net/qjackctl/qjackctl-0.5.7.tar.gz
- source package:
  http://download.sf.net/qjackctl/qjackctl-0.5.7-36.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qjackctl/qjackctl-0.5.7-36.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  http://download.sf.net/qjackctl/qjackctl-0.5.7-9.x86_64.AppImage

Git repos:
  https://git.code.sf.net/p/qjackctl/code
  https://github.com/rncbc/qjackctl.git
  https://gitlab.com/rncbc/qjackctl.git
  https://bitbucket.com/rncbc/qjackctl.git

Change-log:
- Graph node and port title renaming and nodes position move changes are
now undo/redo-able.
- Graph client and port title in-place renaming is now integrated to
native aliases and JACK metadata (aka. pretty-names).
- Refactored all native client/port name aliases.
- Re-defined all main application UNIX signal handling.


** Qsynth - A fluidsynth Qt GUI Interface [2] **

  Qsynth 0.5.6 (spring-break'19) is out!

Qsynth is a FluidSynth [10] GUI front-end application written in C++
around the Qt framework [7] using Qt Designer.

Website:
  https://qsynth.sourceforge.io
  http://qsynth.sourceforge.net

Project page:
  http://sourceforge.net/projects/qsynth

Downloads:
  http://sourceforge.net/projects/qsynth/files
- source tarball:
  http://download.sf.net/qsynth/qsynth-0.5.6.tar.gz
- source package:
  http://download.sf.net/qsynth/qsynth-0.5.6-17.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qsynth/qsynth-0.5.6-17.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  http://download.sf.net/qsynth/qsynth-0.5.6-9.x86_64.AppImage

Git repos:
  https://git.code.sf.net/p/qsynth/code
  https://github.com/rncbc/qsynth.git
  https://gitlab.com/rncbc/qsynth.git
  https://bitbucket.com/rncbc/qsynth.git

Change-log:
- Re-defined all main application UNIX signal handling.


** Qsampler - A LinuxSampler Qt GUI Interface [3] **

  Qsampler 0.5.5 (spring-break'19) is out!

Qsampler is a LinuxSampler [11] GUI front-end application written in C++
around the Qt framework [7] using Qt Designer.

Website:
  https://qsampler.sourceforge.io
  http://qsampler.sourceforge.net

Project page:
  http://sourceforge.net/projects/qsampler

Downloads:
  http://sourceforge.net/projects/qsampler/files
- source tarballs:
  http://download.sf.net/qsampler/qsampler-0.5.5.tar.gz
- source package:
  http://download.sf.net/qsampler/qsampler-0.5.5-29.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qsampler/qsampler-0.5.5-29.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  http://download.sf.net/qsampler/qsampler-0.5.5-9.x86_64.AppImage

Git repos:
  https://git.code.sf.net/p/qsampler/code
  https://github.com/rncbc/qsampler.git
  https://gitlab.com/rncbc/qsampler.git
  https://bitbucket.com/rncbc/qsampler.git

Change-log:
- Re-defined all main application UNIX signal handling.


** QXGEdit - A Qt XG Editor [4] **

  QXGEdit 0.5.4 (spring-break'19) is out!

QXGEdit is a live XG instrument editor, specialized on editing MIDI
System Exclusive files (.syx) for the Yamaha DB50XG [14] and thus
probably a baseline for many other XG devices.

Website:
  https://qxgedit.sourceforge.io
  http://qxgedit.sourceforge.net

Project page:
  http://sourceforge.net/projects/qxgedit

Downloads:
  http://sourceforge.net/projects/qxgedit/files
- source tarball:
  http://download.sf.net/qxgedit/qxgedit-0.5.4.tar.gz
- source package:
  http://download.sf.net/qxgedit/qxgedit-0.5.4-15.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qxgedit/qxgedit-0.5.4-15.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  http://download.sf.net/qxgedit/qxgedit-0.5.4-9.x86_64.AppImage

Git repos:
  https://git.code.sf.net/p/qxgedit/code
  https://github.com/rncbc/qxgedit.git
  https://gitlab.com/rncbc/qxgedit.git
  https://bitbucket.com/rncbc/qxgedit.git

Change-log:
- Re-defined all main application UNIX signal handling.


** QmidiCtl - A MIDI Remote Controller via UDP/IP Multicast [5] **

  QmidiCtl 0.5.4 (spring-break'19) is out!

QmidiCtl [5] is a MIDI remote controller application that sends MIDI
data over the network, using UDP/IP multicast. Inspired by multimidicast
[15] and designed to be compatible with ipMIDI [15] for Windows.
QmidiCtl [5] was long ago designed for the Maemo [17] enabled handheld
devices, namely the late Nokia N900 [18] and promoted to the Maemo
Package [18] repositories. Nevertheless, QmidiCtl [5] may still be found
effective as a regular desktop application and recently as an Android
application as well.

Website:
  https://qmidictl.sourceforge.io
  http://qmidictl.sourceforge.net

Project page:
  http://sourceforge.net/projects/qmidictl

Downloads:
  http://sourceforge.net/projects/qmidictl/files
- source tarball:
  http://download.sf.net/qmidictl/qmidictl-0.5.4.tar.gz
- source package:
  http://download.sf.net/qmidictl/qmidictl-0.5.4-16.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qmidictl/qmidictl-0.5.4-16.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  http://download.sf.net/qmidictl/qmidictl-0.5.4-9.x86_64.AppImage
- Android package:
  http://download.sf.net/qmidictl/qmidictl-0.5.4-9.apk
  https://play.google.com/store/apps/details?id=org.rncbc.qmidictl

Git repos:
  https://git.code.sf.net/p/qmidictl/code
  https://github.com/rncbc/qmidictl.git
  https://gitlab.com/rncbc/qmidictl.git
  https://bitbucket.com/rncbc/qmidictl.git

Change-log:
- Fix build on linux with musl (according to POSIX.1-2001, POSIX.1-2008;
PR#3 by Andreas Müller aka. schnitzeltony, thanks).
- HiDPI display screen support (Qt >= 5.6).


** QmidiNet - A MIDI Network Gateway via UDP/IP Multicast [6] **

  QmidiNet 0.5.4 (spring-break'19) is out!

QmidiNet is a MIDI network gateway application that sends and receives
MIDI data (ALSA-MIDI [9] and JACK-MIDI [8]) over the network, using
UDP/IP multicast. Inspired by multimidicast [15] and designed to be
compatible with ipMIDI [16] for Windows.

Website:
  https://qmidinet.sourceforge.io
  http://qmidinet.sourceforge.net

Project page:
  http://sourceforge.net/projects/qmidinet

Downloads:
  http://sourceforge.net/projects/qmidinet/files
- source tarball:
  http://download.sf.net/qmidinet/qmidinet-0.5.4.tar.gz
- source package:
  http://download.sf.net/qmidinet/qmidinet-0.5.4-17.rncbc.suse.src.rpm
- binary package:
  http://download.sf.net/qmidinet/qmidinet-0.5.4-17.rncbc.suse.x86_64.rpm
- AppImage [20] package:
  http://download.sf.net/qmidinet/qmidinet-0.5.4-9.x86_64.AppImage

Git repos:
  https://git.code.sf.net/p/qmidinet/code
  https://github.com/rncbc/qmidinet.git
  https://gitlab.com/rncbc/qmidinet.git
  https://bitbucket.com/rncbc/qmidinet.git

Change-log:
- Fix build on linux with musl (according to POSIX.1-2001, POSIX.1-2008;
PR#7 by Andreas Müller aka. schnitzeltony, thanks).


License:
  All of the Qstuff* are free, open-source Linux Audio [11] software,
distributed under the terms of the GNU General Public License (GPL)
version 2 or later [12].


References:

 [1] QjackCtl - A JACK Audio Connection Kit Qt GUI Interface
     https://qjackctl.sourceforge.io

 [2] Qsynth - A fluidsynth Qt GUI Interface
     https://qsynth.sourceforge.io

 [3] Qsampler - A LinuxSampler Qt GUI Interface
     https://qsampler.sourceforge.io

 [4] QXGEdit - A Qt XG Editor
     https://qxgedit.sourceforge.io

 [5] QmidiCtl - A MIDI Remote Controller via UDP/IP Multicast
     https://qmidictl.sourceforge.io

 [6] QmidiNet - A MIDI Network Gateway via UDP/IP Multicast
     https://qmidinet.sourceforge.io

 [7] Qt framework, C++ class library and tools for
     cross-platform application and UI development
     http://qt.io/

 [8] JACK Audio Connection Kit
     http://jackaudio.org

 [9] ALSA, Advanced Linux Sound Architecture
     http://www.alsa-project.org/

[10] FluidSynth - A SoundFont Synthesizer
     A real-time software synthesizer based on SoundFont 2 specifications
     http://www.fluidsynth.org

[11] LinuxSampler - The Linux Sampler Project
     A modular, streaming capable, realtime audio sampler
     http://www.linuxsampler.org

[12] Linux Audio consortium of libre software for audio-related work
     http://linuxaudio.org

[13] GPL - GNU General Public License
     http://www.gnu.org/copyleft/gpl.html

[14] Yamaha DB50XG
     http://www.soundonsound.com/sos/1996_articles/may96/yamahadb50xg.html

[15] multimidicast - sends and receives MIDI from ALSA sequencers over
network
     http://llg.cubic.org/tools/multimidicast

[16] ipMIDI - MIDI over Ethernet ports - send MIDI over your LAN
     http://nerds.de

[17] Maemo.org - Home of the Maemo community
     http://www.maemo.org

[18] Maemo.org Wiki - Nokia N900
     http://wiki.maemo.org/Nokia_N900

[19] Maemo.org - Downloads: QmidiCtl
     http://maemo.org/downloads/product/Maemo5/qmidictl

[20] AppImage, Linux apps that run anywhere
     http://appimage.org/

[21] LAC2019@CCRMA-Stanford, March 22–26 2019
     https://lac.linuxaudio.org/2019/


See also:
  https://www.rncbc.org/drupal/node/1996


Enjoy && Keep the fun!
--
rncbc aka Rui Nuno Capela