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

Re: [Linuxsampler-devel] Experimental sfz polyphony and note_polyphony opcode support

[Jacek R. <j....@gm...>]

niedz., 24 lut 2019 o 18:38 Christian Schoenebeck <
sch...@li...> napisał(a):
> Mja, the thing is that src/engines/sfz/EngineChannel.cpp is usually not
the
> right place for doing such core engine event handling that you attempt
with
> your patch. The source files dediciated for the individual formats
(gig/sf2/
> sfz) only cover the most minimalistic stuff required specifically only
for the
> individual format itself, all the rest is shared, common code available
to all
> engines, so when a new feature is added for one engine that it could still
> easily be adopted by all other engines as well (like it usually always
happens
> after some time).

I agree. I've decided to try inside EngineChannel, because it contained
required data (list of all playing voices) ordered by midi key.

> But first things first. If I understand it correctly, you are already
aware that
> there is already a feature for all our engines/formats which is called
> "exclusive groups" or "key groups", right? This feature allows to assign
> individual keys on a keyboard to individual "key groups", and within one
key
> group there is always only 1 note intended to be active at a time, so if
you
> trigger a key being member of a key group and there is already another
note
> active of that same key group, then the previous note of that group will
> automatically be released. So that's a feature typically required for drum
> kits.

I'm using this feature to mute cymbals, but in sfz with off_by opcode user
can specify only one key, and it's implemented correctly in linuxsampler.
It can accurately emulate drum kit pieces, except for mutable cymbals. If
you specify a separate key to mute a cymbal it doesn't mute its consecutive
hits leading to unnatural sound buildup.

> Having said, your intention is to extend this existing feature for
optionally
> raising the amount of active notes in a key group to another higher value
than
> just 1, is that correct?

Yes, it's correct. With sfz 2 format opcodes
http://www.sfzformat.com/index.php?title=Polyphony
http://www.sfzformat.com/index.php?title=Note_polyphony
I can specify a mute key for a group with off_by opcode and decrease
unnatural sound buildup with polyphony.

My configuration is based on
http://www.sfzformat.com/index.php?title=Cymbal_muting but even more
sophisticated with many velocity layers and round robin hits.

Regards
Jacek Roszkowski

Re: [Linuxsampler-devel] Support for 32-bit sample format

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

On Sonntag, 24. Februar 2019 17:29:24 CET Jacek Roszkowski wrote:
> > In recent versions of ALSA dmix should be enabled by default, and that
> > automatically handles all required conversions (bit depth, sample rate,
> > channels) if the sound card does not support conversion on its own.
> 
> It is enabled indeed and linuxsampler made a fallback with following
> message:
> 
> Warning: your soundcard doesn't support chosen hardware parameters;
> trying to compensate support lack with plughw...
> 
> I'm looking for lowest possible latency. With FRAGMENTSIZE=48 I'm
> getting sound artifacts with dmix and smooth playback with my patch.
> That's the only reason.

Ah I see, so the automatic format conversion of ALSA does work for you, 
however dmix just causes dropouts with your low latency settings. Interesting 
that dmix does that, because usually the conversion is rather cheap.

I wonder if its really dmix being the problem. Maybe you are already very 
close to the edge with your latency setting and current OS configuration and 
dmix is just the last tip on the scales to trigger the droput.

And with your 32 bit patch you are always running rock solid 1ms latency 
without any drop outs ever?

CU
Christian

Re: [Linuxsampler-devel] Experimental sfz polyphony and note_polyphony opcode support

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

On Sonntag, 24. Februar 2019 17:30:15 CET Jacek Roszkowski wrote:
> I'm sorry. I forgot to include the attachment file. Now I've also
> found out that it compiles only with developer mode enabled. Otherwise
> it fails, because the required interface is not public:
> 
> EngineChannel.cpp:250:52: error: ‘void
> LinuxSampler::AbstractVoice::EnterReleaseStage()’ is protected within
> this context
>                          itVoice->EnterReleaseStage();

Mja, the thing is that src/engines/sfz/EngineChannel.cpp is usually not the 
right place for doing such core engine event handling that you attempt with 
your patch. The source files dediciated for the individual formats (gig/sf2/
sfz) only cover the most minimalistic stuff required specifically only for the 
individual format itself, all the rest is shared, common code available to all 
engines, so when a new feature is added for one engine that it could still 
easily be adopted by all other engines as well (like it usually always happens 
after some time).

But first things first. If I understand it correctly, you are already aware that 
there is already a feature for all our engines/formats which is called 
"exclusive groups" or "key groups", right? This feature allows to assign 
individual keys on a keyboard to individual "key groups", and within one key 
group there is always only 1 note intended to be active at a time, so if you 
trigger a key being member of a key group and there is already another note 
active of that same key group, then the previous note of that group will 
automatically be released. So that's a feature typically required for drum 
kits.

Having said, your intention is to extend this existing feature for optionally 
raising the amount of active notes in a key group to another higher value than 
just 1, is that correct?

CU
Christian

Re: [Linuxsampler-devel] Experimental sfz polyphony and note_polyphony opcode support

[Jacek R. <j....@gm...>]

It seems that I'm also not familiar with mailing lists. Excuse me for
writing replies to your personal e-mail. I've sent them once more to
the list.

Regards
Jacek Roszkowski

Re: [Linuxsampler-devel] Experimental sfz polyphony and note_polyphony opcode support

[Jacek R. <j....@gm...>]

niedz., 24 lut 2019 o 16:46 Christian Schoenebeck
<sch...@li...> napisał(a):
> Please do me a favour, if you want something to be applied on our side, then
> please provide either a patch or link to an appropriate patch against our SVN
> trunk with exactly the changes you want to be applied.

I'm sorry. I forgot to include the attachment file. Now I've also
found out that it compiles only with developer mode enabled. Otherwise
it fails, because the required interface is not public:

EngineChannel.cpp:250:52: error: ‘void
LinuxSampler::AbstractVoice::EnterReleaseStage()’ is protected within
this context
                         itVoice->EnterReleaseStage();

Re: [Linuxsampler-devel] Support for 32-bit sample format

[Jacek R. <j....@gm...>]

niedz., 24 lut 2019 o 16:41 Christian Schoenebeck
<sch...@li...> napisał(a):

> In recent versions of ALSA dmix should be enabled by default, and that
> automatically handles all required conversions (bit depth, sample rate,
> channels) if the sound card does not support conversion on its own.

It is enabled indeed and linuxsampler made a fallback with following message:

Warning: your soundcard doesn't support chosen hardware parameters;
trying to compensate support lack with plughw...

I'm looking for lowest possible latency. With FRAGMENTSIZE=48 I'm
getting sound artifacts with dmix and smooth playback with my patch.
That's the only reason.

> Are you using analogue or digital outputs of your breakout box?

I'm using analog outputs.

Best regards
Jacek Roszkowski

Re: [Linuxsampler-devel] Experimental sfz polyphony and note_polyphony opcode support

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

On Sonntag, 24. Februar 2019 16:22:11 CET Jacek Roszkowski wrote:
> I needed more control over my samples with polyphony and
> note_polyphony opcodes. I'm not familiar with linuxsampler internals,
> but I've managed to create this patch to add support for those. It
> works for me on Raspberry Pi.

Please do me a favour, if you want something to be applied on our side, then 
please provide either a patch or link to an appropriate patch against our SVN 
trunk with exactly the changes you want to be applied.

CU
Christian

Re: [Linuxsampler-devel] Support for 32-bit sample format

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

On Sonntag, 24. Februar 2019 16:11:30 CET Jacek Roszkowski wrote:
> I'm trying to run linuxsampler on Raspberry Pi as a low latency drum
> module with my audio interface (NI Komplete Audio 6). Unfortunately,
> the ALSA driver supports only S32_LE sample format. I've made some
> changes to the code and it works for me, so I want to share it here.
> Maybe it's going to make it into the trunk :)

In recent versions of ALSA dmix should be enabled by default, and that 
automatically handles all required conversions (bit depth, sample rate, 
channels) if the sound card does not support conversion on its own.

Are you using analogue or digital outputs of your breakout box?

CU
Christian

[Linuxsampler-devel] Experimental sfz polyphony and note_polyphony opcode support

[Jacek R. <j....@gm...>]

Hi.

I needed more control over my samples with polyphony and
note_polyphony opcodes. I'm not familiar with linuxsampler internals,
but I've managed to create this patch to add support for those. It
works for me on Raspberry Pi.

It's hosted on github as well:
https://github.com/jarosz/linuxsampler-linuxsampler/tree/polyphony

Best regards
Jacek Roszkowski

[Linuxsampler-devel] Support for 32-bit sample format

[Jacek R. <j....@gm...>]

Hi.

I'm trying to run linuxsampler on Raspberry Pi as a low latency drum
module with my audio interface (NI Komplete Audio 6). Unfortunately,
the ALSA driver supports only S32_LE sample format. I've made some
changes to the code and it works for me, so I want to share it here.
Maybe it's going to make it into the trunk :)

It's also hosted on github: https://github.com/jarosz/linuxsampler-linuxsampler.

Best regards
Jacek Roszkowski

Re: [Linuxsampler-devel] Multi-part load and save

[Ivan M. <iv...@ma...>]

On 23/02/2019 15:45, Christian Schoenebeck wrote:
> Ok, committed the fixes (SVN r3483).
>
> I also added test cases against those helper functions:
>
> 	cd src/testcases/
> 	g++ HelperTest.cpp
> 	./a.out
Many thanks Christian.
> CU
> Christian

All the best,
Ivan

Re: [Linuxsampler-devel] Multi-part load and save

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

On Samstag, 23. Februar 2019 00:58:46 CET Christian Schoenebeck wrote:
> > I've attached a patch containing a few small corrections to the changes
> > you made when integrating my patch.
> 
> Oops, sorry and thanks! There are still some issues with the helper
> functions with certain paths. I grab some sleep and then I fix the rest of
> the helper function issues during the day.

Ok, committed the fixes (SVN r3483).

I also added test cases against those helper functions:

	cd src/testcases/
	g++ HelperTest.cpp
	./a.out

CU
Christian

Re: [Linuxsampler-devel] Multi-part load and save

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

On Freitag, 22. Februar 2019 22:26:18 CET Ivan Maguidhir wrote:
> On 21/02/2019 17:23, Christian Schoenebeck wrote:
> > I can't say. I just googled "gx99 file" and I see various independent
> > source that this file was about "GigaPulse settings". One of them is a
> > PDF from> 
> > Tascam, quote:
> > 	"If convolution encoded instrument is copied onto  a  GS3 system  without
> > 	
> > 	 its  associated .gx99  file,  a  “No  Banks  Found”  error  message 
> > 	 will
> > 	 be displayed  upon  loading  the  instrument.  Always be sure to keep
> > 	
> > 	.gx99 files together with their .gig files."
> 
> Yeah, there is very little information on them. I'll try creating some
> gig libraries which result in a .gx99 file being created using the GSt3
> editor to see what different outputs I get. I don't know how to create
> instruments from scratch yet though, so I have a bit of studying to do!

First steps on that are the hardest ones. If you got questions, just ask.

> I've attached a patch containing a few small corrections to the changes
> you made when integrating my patch.

Oops, sorry and thanks! There are still some issues with the helper functions 
with certain paths. I grab some sleep and then I fix the rest of the helper 
function issues during the day.

CU
Christian

Re: [Linuxsampler-devel] Multi-part load and save

[Ivan M. <iv...@ma...>]

On 21/02/2019 17:23, Christian Schoenebeck wrote:
> I can't say. I just googled "gx99 file" and I see various independent source
> that this file was about "GigaPulse settings". One of them is a PDF from
> Tascam, quote:
>
> 	"If convolution encoded instrument is copied onto  a  GS3 system  without
> 	 its  associated .gx99  file,  a  “No  Banks  Found”  error  message  will
> 	 be displayed  upon  loading  the  instrument.  Always be sure to keep
> 	.gx99 files together with their .gig files."

Yeah, there is very little information on them. I'll try creating some 
gig libraries which result in a .gx99 file being created using the GSt3 
editor to see what different outputs I get. I don't know how to create 
instruments from scratch yet though, so I have a bit of studying to do!

I've attached a patch containing a few small corrections to the changes 
you made when integrating my patch.

> CU
> Christian
>
All the best,
Ivan

Re: [Linuxsampler-devel] Multi-part load and save

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

On Mittwoch, 20. Februar 2019 20:27:53 CET Ivan Maguidhir wrote:
> Further to my message earlier, I had a look at two libraries I have
> containing .gx99 files again and in both .gig files the 'doxf' chunk's
> string contains the filename of the .gx99 file. Which disproves my
> theory about it being an impulse name. In some other libraries I have it
> contains the name of a file which no longer exists (the original gig
> filename before being renamed probably). So I think my initial
> assumption that the string is unused is correct.

I can't say. I just googled "gx99 file" and I see various independent source 
that this file was about "GigaPulse settings". One of them is a PDF from 
Tascam, quote:

	"If convolution encoded instrument is copied onto  a  GS3 system  without  
	 its  associated .gx99  file,  a  “No  Banks  Found”  error  message  will  
	 be displayed  upon  loading  the  instrument.  Always be sure to keep 
	.gx99 files together with their .gig files."

CU
Christian

Re: [Linuxsampler-devel] Multi-part load and save

[Ivan M. <iv...@ma...>]

On 20/02/2019 16:57, Christian Schoenebeck wrote:
> Also note in DLS.cpp, where it is now automatically creating the 'doxf' chunk
> if missing, I was assuming a chunk size of 148 bytes. Is that correct?
>
> And I also figured out now what this ominous ".gx99" file is about: that's for
> writing convolution effect data (a.k.a. GigaPulse). So now that makes more
> sense why that is always handled separately as .gx99.

Hi Christian,

Further to my message earlier, I had a look at two libraries I have 
containing .gx99 files again and in both .gig files the 'doxf' chunk's 
string contains the filename of the .gx99 file. Which disproves my 
theory about it being an impulse name. In some other libraries I have it 
contains the name of a file which no longer exists (the original gig 
filename before being renamed probably). So I think my initial 
assumption that the string is unused is correct.

All the best,
Ivan

Re: [Linuxsampler-devel] msvc patch

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

On Dienstag, 19. Februar 2019 20:22:42 CET Christian Schoenebeck wrote:
> On Montag, 18. Februar 2019 16:09:11 CET justnope wrote:
> > This is the final version. I did several tests and they all seem to work.
> > 
> > If you remove the MSVC check in CMakeLists.txt it will also compile the
> > library and some tools in linux.
> 
> I'm currently processing Ivan's patch, but I am optimistic to have both
> patches committed in the next two days.

I just committed your MSVC changes (SVN r3476).

Thanks for your patch!

CU
Christian

Re: [Linuxsampler-devel] Multi-part load and save

[Ivan M. <iv...@ma...>]

On 20/02/2019 16:57, Christian Schoenebeck wrote:
> Ok, I just committed the libgig changes for writing gig extension files (SVN
> r3474). Please review and test them, because most nostably I do not have any
> gigs with extension files so I cannot test it, and I am also missing some
> knowledge about the new chunks (see below).
No problem. I'll do this this evening.
> Also note in DLS.cpp, where it is now automatically creating the 'doxf' chunk
> if missing, I was assuming a chunk size of 148 bytes. Is that correct?
Yes that's exactly right. 4 byte int containing '99', string zero padded 
to 128 bytes and 16 byte dlsid.
> And I also figured out now what this ominous ".gx99" file is about: that's for
> writing convolution effect data (a.k.a. GigaPulse). So now that makes more
> sense why that is always handled separately as .gx99.
That's great! I think this means that the string in the 'doxf' chunk 
might actually be an impulse name. I wonder also if the .gx99 file is 
just a RIFF file with a .gsi (Gigastudio Impulse) file embedded in it? I 
have several of both of these types of file to hand so I'll try to 
figure out if this is the case. It would be nice to know the .gsi file 
structure also in order to add reverb at some point in the future.
> So I would suggest simply adding two checkboxes to gigedit's file format
> dialog:
>
> 	- "Large File Support" (default on)
> 	- "GigaStudio Legacy Extension Files" (default off)
>
That makes sense. I'll do that.
> Thanks for your patch Ivan!

You're more than welcome!

> CU
> Christian
>
All the best,
Ivan

Re: [Linuxsampler-devel] Multi-part load and save

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

On Mittwoch, 20. Februar 2019 16:38:31 CET Ivan Maguidhir wrote:
> On 20/02/2019 12:36, Christian Schoenebeck wrote:
> > Please share your design ideas before implementing anything to avoid
> > substantial code rewrites later on.
> 
> Sorry about that. I will in future.

Ok, I just committed the libgig changes for writing gig extension files (SVN 
r3474). Please review and test them, because most nostably I do not have any 
gigs with extension files so I cannot test it, and I am also missing some 
knowledge about the new chunks (see below).

These were the adjustments I made regarding your patch:

1. Moved out all file path parsing code as helper functions, instead of doing 
   those string parsing tasks directly in the file saving / loading methods.

and more importantly:

2. I tried to generalize your code more in order to also allow to save gigs 
   with any different amount of extension files. So it is now also valid to 
   remove or add extension files without getting an exception when eventually 
   trying to save it.

But there is still some work to do for my changes in (2.) for becoming 
actually useful; most importantly when saving a gig file, the samples should 
automatically be (re)assigned over individual extension files and accordingly 
also the amount of extension files should automatically be increased or 
decreased accordingly. I have no plans in the next days or so to do that 
though. I will process the MSVC patch next.

Also note in DLS.cpp, where it is now automatically creating the 'doxf' chunk 
if missing, I was assuming a chunk size of 148 bytes. Is that correct?

And I also figured out now what this ominous ".gx99" file is about: that's for 
writing convolution effect data (a.k.a. GigaPulse). So now that makes more 
sense why that is always handled separately as .gx99.

> > For example looking at your screen shot, I don't think that setting a
> > maximum file size for extension files is necessary at all. I think the
> > GSt way of saving extension files (.gx01, .gx02, ... , .gx99) should only
> > be used for saving gig files intended to be compatible with the
> > GigaStudio software, and in that case the max. files size would be always
> > 2GB anyway.
> 
> The changes I've made to gigedit and libgig are only for creating
> Gigastudio compatible extension files. I included the max file size
> setting only because it's there in the GSt3 save dialog. As you

Ah, interesting, I see. Ok, then fine, I did not know that. My knowledge was 
that GigaStudio would always simply distribute over 2GB files when saving. I 
did not know there was an option to change the individual file size.

> correctly point out no one would really need to change this value. The
> default setting in the GSt3 editor is 2040. I think this is in
> mebibytes. My idea was to add/remove extension files as samples are
> being added/removed instead of doing all the work of splitting the .gig
> up during a File::Save().

So I would suggest simply adding two checkboxes to gigedit's file format 
dialog:

	- "Large File Support" (default on)
	- "GigaStudio Legacy Extension Files" (default off)

And if you want you can also preserve your individual file size setting of 
course. And when "GigaStudio Legacy Extension Files" is turned on, then "Large 
File Support" is automatically turned off and vice versa. So there would only 
be 3 possibilities:

	1. Large File On, Legacy Ext. Off
	2. Large File Off, Legacy Ext. Off
	3. Large File Off, Legacy Ext. On

And later on (not yet now), I would add a third checkbox e.g. "Next Gen. 
Extension Files (incompatible with GigaStudio)" with the more fancy way of 
modularizing parts of a gig file, like we discussed recently and hopefully will 
discuss in more detail soon.

> > Please also note that I am currently adjusting your previous libgig patch
> > for allowing to save also with a different amount of extension files. So
> > keep that in mind to avoid we two are working on the same thing. I expect
> > to commit these libgig changes in the next couple hours.
> 
> Many thanks for doing that.

Thanks for your patch Ivan!

CU
Christian

Re: [Linuxsampler-devel] Multi-part load and save

[Ivan M. <iv...@ma...>]

On 20/02/2019 12:36, Christian Schoenebeck wrote:
> Please share your design ideas before implementing anything to avoid
> substantial code rewrites later on.
Sorry about that. I will in future.
> For example looking at your screen shot, I don't think that setting a maximum
> file size for extension files is necessary at all. I think the GSt way of saving
> extension files (.gx01, .gx02, ... , .gx99) should only be used for saving gig
> files intended to be compatible with the GigaStudio software, and in that case
> the max. files size would be always 2GB anyway.

The changes I've made to gigedit and libgig are only for creating 
Gigastudio compatible extension files. I included the max file size 
setting only because it's there in the GSt3 save dialog. As you 
correctly point out no one would really need to change this value. The 
default setting in the GSt3 editor is 2040. I think this is in 
mebibytes. My idea was to add/remove extension files as samples are 
being added/removed instead of doing all the work of splitting the .gig 
up during a File::Save().

> For the more flexible approach (not intended to be compatible with GigaStudio)
> that we recently discussed, I do have other plans: for instance it would not
> use the .gxYY scheme at all, most notably because I want those extension files
> to have a) any name, not just the same base name as main gig file, and
> b) I want those extension files to be loadable from different directories than
> the main gig file in order to allow sharing individual extension files among
> multiple main gig files.
That sounds great.
> Please also note that I am currently adjusting your previous libgig patch for
> allowing to save also with a different amount of extension files. So keep that
> in mind to avoid we two are working on the same thing. I expect to commit
> these libgig changes in the next couple hours.
Many thanks for doing that.
> CU
> Christian

All the best,
Ivan

Re: [Linuxsampler-devel] Multi-part load and save

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

On Mittwoch, 20. Februar 2019 02:04:19 CET Ivan Maguidhir wrote:
> I should have a patch to allow the creation of extension files within a
> day or two. I think I have a solution already but I want to test it by
> creating a few instruments from scratch and trying them out in LS and
> GSt3. I've attached a screen grab of my changes to the gigedit file
> properties dialog.

Please share your design ideas before implementing anything to avoid 
substantial code rewrites later on.

For example looking at your screen shot, I don't think that setting a maximum 
file size for extension files is necessary at all. I think the GSt way of saving 
extension files (.gx01, .gx02, ... , .gx99) should only be used for saving gig 
files intended to be compatible with the GigaStudio software, and in that case 
the max. files size would be always 2GB anyway.

For the more flexible approach (not intended to be compatible with GigaStudio) 
that we recently discussed, I do have other plans: for instance it would not 
use the .gxYY scheme at all, most notably because I want those extension files 
to have a) any name, not just the same base name as main gig file, and
b) I want those extension files to be loadable from different directories than 
the main gig file in order to allow sharing individual extension files among 
multiple main gig files.

Please also note that I am currently adjusting your previous libgig patch for 
allowing to save also with a different amount of extension files. So keep that 
in mind to avoid we two are working on the same thing. I expect to commit 
these libgig changes in the next couple hours.

CU
Christian

Re: [Linuxsampler-devel] Multi-part load and save

[Ivan M. <iv...@ma...>]

Hi Christian

I should have a patch to allow the creation of extension files within a 
day or two. I think I have a solution already but I want to test it by 
creating a few instruments from scratch and trying them out in LS and 
GSt3. I've attached a screen grab of my changes to the gigedit file 
properties dialog.

All the best,
Ivan

Re: [Linuxsampler-devel] msvc patch

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

On Montag, 18. Februar 2019 16:09:11 CET justnope wrote:
> This is the final version. I did several tests and they all seem to work.
> 
> If you remove the MSVC check in CMakeLists.txt it will also compile the
> library and some tools in linux.

I'm currently processing Ivan's patch, but I am optimistic to have both 
patches committed in the next two days.

CU
Christian

Re: [Linuxsampler-devel] msvc patch

[justnope <spa...@te...>]

On 15/02/2019 16:00, justnope wrote:
> On 15/02/2019 15:15, Christian Schoenebeck wrote:
>> I suggest that I commit your msvc patch first, and then sure, if you 
>> like to
>> adapt the cmakes for other architectures, very much appreciated of 
>> course!
>>
>> So your previous patch sent to the list is the latest one, or should I 
>> wait
>> for an updated patch from your side?
> um... wait for a bit?
> I tried to integrate it in vcpkg and noticed some problems. I know, I 
> should've done this earlier!

This is the final version. I did several tests and they all seem to work.

If you remove the MSVC check in CMakeLists.txt it will also compile the 
library and some tools in linux.

Re: [Linuxsampler-devel] msvc patch

[justnope <spa...@te...>]

On 15/02/2019 15:15, Christian Schoenebeck wrote:
> I suggest that I commit your msvc patch first, and then sure, if you like to
> adapt the cmakes for other architectures, very much appreciated of course!
>
> So your previous patch sent to the list is the latest one, or should I wait
> for an updated patch from your side?
um... wait for a bit?
I tried to integrate it in vcpkg and noticed some problems. I know, I 
should've done this earlier!

They are minor changes. But once I'm done and you've released a new 
version, I can use vcpkg cmake magic to download the source tarball, 
extract, compile and easily include it in my projects.