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

Re: [Linuxsampler-devel] Can't Launch Linux Sampler in Windows 10

[Andreas P. <and...@ou...>]

Glen Berry wrote:
> When I try to launch the standalone Linux Sampler, I get an error
> message that says liblinuxsampler-5.dll cannot be found.
> 
> When I try to launch GigEdit, I get an error message that says
> libgigedit-4.dll cannot be found.

Thanks for the report. We forgot to update the Windows installer after
the 2.1.0 release. It should be fixed now, in the "20171203" version.

> Also, when I tried to visit your website's bulletin board, I was met
> with an SQL error message, and it refused to connect me to the bulletin
> board.

OK, should also be fixed now.

/Andreas

Re: [Linuxsampler-devel] Can't Launch Linux Sampler in Windows 10

[Glen B. <gl...@gl...>]

Ok. I just tried that. I also renamed libgigedit-3.dll to 
libgigedit-4.dll. It seems to be working so far.  :)

Thanks!


On 12/2/2017 4:37 PM, Chris Pugh wrote:
> They appear to be missing, or simply not renamed ?
> I got round it by checking the LinuxSampler > 64  directory, and doing
> just that..
>
> changing libgig-7.dll to libgig-8.dll,  and liblinuxsampler-4.dll to
> liblinuxsampler-5.dll  !
>
> ..and away, she goes!  ;o)
>
> HTH.
>
>
> Chris.
>
>   ;o)
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>

Re: [Linuxsampler-devel] Can't Launch Linux Sampler in Windows 10

[Chris P. <gli...@gm...>]

On 2 December 2017 at 20:14, Glen Berry <gl...@gl...> wrote:
> I just installed the very latest version of Linux Sampler, but I can't get
> it to run. Both the 32 and 64 bit plugins refuse to load into my Tracktion
> DAW. (Tracktion finds them, but can't load them.)
>
> When I try to launch the standalone Linux Sampler, I get an error message
> that says liblinuxsampler-5.dll cannot be found.
>
> When I try to launch GigEdit, I get an error message that says
> libgigedit-4.dll cannot be found.
>
> Also, when I tried to visit your website's bulletin board, I was met with an
> SQL error message, and it refused to connect me to the bulletin board.
>
> For reference, I'm using 64-bit Windows 10. I downloaded the very latest
> compiled binaries from your site, and installed them with the default
> settings.
>
> Can anyone help me get this fixed?
>
> Thank you,
> Glen Berry

They appear to be missing, or simply not renamed ?

I got round it by checking the LinuxSampler > 64  directory, and doing
just that..

changing libgig-7.dll to libgig-8.dll,  and liblinuxsampler-4.dll to
liblinuxsampler-5.dll  !

..and away, she goes!  ;o)

HTH.


Chris.

 ;o)

[Linuxsampler-devel] Can't Launch Linux Sampler in Windows 10

[Glen B. <gl...@gl...>]

I just installed the very latest version of Linux Sampler, but I can't 
get it to run. Both the 32 and 64 bit plugins refuse to load into my 
Tracktion DAW. (Tracktion finds them, but can't load them.)

When I try to launch the standalone Linux Sampler, I get an error 
message that says liblinuxsampler-5.dll cannot be found.

When I try to launch GigEdit, I get an error message that says 
libgigedit-4.dll cannot be found.

Also, when I tried to visit your website's bulletin board, I was met 
with an SQL error message, and it refused to connect me to the bulletin 
board.

For reference, I'm using 64-bit Windows 10. I downloaded the very latest 
compiled binaries from your site, and installed them with the default 
settings.

Can anyone help me get this fixed?

Thank you,
Glen Berry

[Linuxsampler-devel] LinuxSampler 2.1.0 released

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

Two years have passed, but finally there is a new release:

        - LinuxSampler 2.1.0
        - Gigedit 1.1.0
        - libgig 4.1.0

Check out the release notes to see what's new:

        http://doc.linuxsampler.org/Release_Notes/LinuxSampler_2_1_0/

CU
Christian

[Linuxsampler-devel] Different velocity curves for volume and timbre

[Mauricio K. <mk...@ya...>]

Is it possible to configure diferent velocity curvesfor ´volume´ and ´timbre´ without editing the sample library?
I know that sfz files are text files, and is possible tocreate different ´versions´ of some instrument using the same audio samples. But I think that these curves could beedited in UI, so any user could change it, even those withoutany technical knowledge.
What do you think about this idea?

Thanks in advance.
Maurício Kanada

Re: [Linuxsampler-devel] EGs

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

You are talking about SFZ? Because for the gig format I think I already 
addressed this overall issue appropriately like I already described in this 
thread.

CU
Christian

On Mittwoch, 8. November 2017 00:17:50 CET S. Christian Collins wrote:
> I realize I'm a bit late on this particular topic, but I think a good,
> universal solution to this problem would be to set a minimum duration
> for all notes. For example, if the minimum duration is set to 20
> milliseconds, then a note duration of between 0 and 20 ms would always
> play as 20 ms. This would prevent the scenario where notes with short
> but nonzero attack values go to release stage before the note has
> reached the desired volume, and sounds that have attack phases longer
> than 20 ms (pads, cymbal rolls, sound effects that fade in) would still
> properly respond to keypress duration. This would at least be in line
> with how I'd expect a synth/sampler to behave. For other behaviors, we
> have "one shot" mode.

Re: [Linuxsampler-devel] EGs

[S. C. C. <s_c...@ho...>]

I realize I'm a bit late on this particular topic, but I think a good, 
universal solution to this problem would be to set a minimum duration 
for all notes. For example, if the minimum duration is set to 20 
milliseconds, then a note duration of between 0 and 20 ms would always 
play as 20 ms. This would prevent the scenario where notes with short 
but nonzero attack values go to release stage before the note has 
reached the desired volume, and sounds that have attack phases longer 
than 20 ms (pads, cymbal rolls, sound effects that fade in) would still 
properly respond to keypress duration. This would at least be in line 
with how I'd expect a synth/sampler to behave. For other behaviors, we 
have "one shot" mode.

-~Chris


On 07/23/2017 02:37 PM, Christian Schoenebeck wrote:
> On Wednesday, July 19, 2017 13:13:26 Christian Schoenebeck wrote:
>> I see, you are right, that behavior regarding attack and decay came from
>> your side. Then I am going to make that configurable as another LS
>> extension to the gig format and leave the current behavior as default
>> behavior.
>>
>> In the end I will add 3 additional check boxes to gigedit which allow to
>> select for 1.) "attack" stage, 2.) "attack hold" stage and 3.) "decay" stage
>> whether the respective stage should be played entirely to its end on
>> note-off. That checkbox trio will be available for all 3 EGs separately
>> (amp EG, pitch EG, filter EG) as individual configuration.
> Ok, I just committed changes for those EG behavior changes to libgig,
> linuxsampler and gigedit.
>
> In gigedit there are now 5 additional checkboxes for EG1, as well as for EG2,
> which allow to configure (on dimregion level) individually whether Attack,
> Attack Hold, Decay 1, Decay 2 and Release may be cancelled.
>
> The previous EG state machine behavior is preserved as default value for those
> settings on libgig level. Which means those 5 checkboxes are all enabled by
> default.
>
> Since EG3 just has one stage (decay) it does not have any options.
>
> On libgig level a linuxsampler specific RIFF chunk is added as extension to
> the gig file format for those new EG options. However that chunk will only be
> added to the gig file if the user changed the settings differing from the
> default values.
>
> I hope I did not break anything. If I did, let me know!
>
> CU
> Christian
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] gig file integrity check fails for original (nemsys) gigapiano and other instruments

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

On Freitag, 3. November 2017 13:34:34 CET Jaime T wrote:
> Damaged Sample 201) "058v3ub" expectedCRC=ffffffff calculatedCRC=8ce5c64c
> Damaged Sample 202) "058v3db" expectedCRC=ffffffff calculatedCRC=2c60b335
> Damaged Sample 203) "058" expectedCRC=ffffffff calculatedCRC=86cd6610
> Damaged Sample 204) "058" expectedCRC=ffffffff calculatedCRC=f1ab313c
> 
> I'll be the first to admit that I don't fully understand what is going
> on here, but I have a funny feeling that something isn't quite as it
> should be.

Looks strange to me. First of all, check if you are really running gigdump 
with the latest version of lilbgig:

	gigdump -v

which should look like this:

	gigdump revision 3330
	using libgig 4.0.0.svn33

Because sometimes people still have an old version of libgig under i.e.
/usr/local which might conflict with another installation directory.

Then try to rebuild the checksum table a 2nd time. Because your output said 
that it needed to rebuild the file structure, which is not very common. So 
maybe after rebuilding the checksum the 2nd time it might work in your case.

If not, then you might also try to open the file with gigedit and then use 
"Save as ..." and save it under a new file name. Make sure you are using the 
latest version of gigedit and libgig there as well (shown in gigedit's About 
box).

> Would there be any value in me trying the same operations with the
> Artvista Malmsjo Acoustic Grand and the Tascam BG
> (Biggagigga/Purgatory Creek) Rhodes gigs, or should I just log a bug?

Uhm, I think it would require you like 5 seconds to find that out. ;-)

CU
Christian

Re: [Linuxsampler-devel] gig file integrity check fails for original (nemsys) gigapiano and other instruments

[Jaime T <eno...@gm...>]

On 3 November 2017 at 10:34, Christian Schoenebeck
<sch...@li...> wrote:
> In that case you would need to check the samples manually first and then use
>         gigdump --rebuild-checksums foo.gig
> to rebuild the entire checksum tale.

Ok. I'm not too sure exactly what I need to do to "check the samples
manually" (the gigapiano, malmsjo grand and tascam rhodes instruments
have always sounded ok to me when I have played them) so I've tried
out the "rebuild checksums" operation:

$ gigdump --rebuild-checksums gigapiano.gig
Recalculating checksums of all samples ... OK
WARNING: File structure change required, rebuilding entire file now ...
DONE
NOTE: Since the entire file was rebuilt, you may need to manually
check all samples in this particular case now!
$

Just to make sure that gigdump is now happy with the gig file
structure, I've run the "verify" operation against the "newly-built"
gigapiano:

$ gigdump --verify gigapiano.gig
Verifying sample checksum table ... OK
Verifying samples ... 204 of 204 Samples DAMAGED:
Damaged Sample 1) "021b" expectedCRC=ffffffff calculatedCRC=d510065f
Damaged Sample 2) "026b" expectedCRC=ffffffff calculatedCRC=65ff15d7
Damaged Sample 3) "031" expectedCRC=ffffffff calculatedCRC=11c75bec
Damaged Sample 4) "036b" expectedCRC=ffffffff calculatedCRC=257d468d
Damaged Sample 5) "040b" expectedCRC=ffffffff calculatedCRC=860d3c20
...
(lines 6-200 removed from this email for the sake of brevity)
...
Damaged Sample 201) "058v3ub" expectedCRC=ffffffff calculatedCRC=8ce5c64c
Damaged Sample 202) "058v3db" expectedCRC=ffffffff calculatedCRC=2c60b335
Damaged Sample 203) "058" expectedCRC=ffffffff calculatedCRC=86cd6610
Damaged Sample 204) "058" expectedCRC=ffffffff calculatedCRC=f1ab313c

I'll be the first to admit that I don't fully understand what is going
on here, but I have a funny feeling that something isn't quite as it
should be.

Would there be any value in me trying the same operations with the
Artvista Malmsjo Acoustic Grand and the Tascam BG
(Biggagigga/Purgatory Creek) Rhodes gigs, or should I just log a bug?

Re: [Linuxsampler-devel] gig file integrity check fails for original (nemsys) gigapiano and other instruments

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

On Freitag, 3. November 2017 09:33:08 CET Jaime T wrote:
> $ gigdump --verify gigapiano.gig
> Verifying sample checksum table ... DAMAGED
> You may use --rebuild-checksums to repair the sample checksum table.
> $
> 
> I haven't dived into the source, but I'm assuming that gigdump will
> only print the expected and actual checksums if it finds what it
> thinks is a "meaningful" checksum table (which perhaps it hasn't done
> in my case!)

Ah I see. When even the checksum table itself is damaged, then gigdump will 
not print you the checksums of the individual samples at all.

In that case you would need to check the samples manually first and then use

	gigdump --rebuild-checksums foo.gig

to rebuild the entire checksum tale.

CU
Christian

Re: [Linuxsampler-devel] gig file integrity check fails for original (nemsys) gigapiano and other instruments

[Jaime T <eno...@gm...>]

On 1 November 2017 at 19:31, Christian Schoenebeck
<sch...@li...> wrote:
> If the integrity check for a sample failed, gigdump prints you both the
> expected checksum, as well as the actual checksum it calculated. Compare the

Hi Christian.

I'm using subversion revision 3363 (on a "fresh" debian stretch), and
I'm not seeing the output that you have described. Here's the whole
output:

$ gigdump --verify gigapiano.gig
Verifying sample checksum table ... DAMAGED
You may use --rebuild-checksums to repair the sample checksum table.
$

I haven't dived into the source, but I'm assuming that gigdump will
only print the expected and actual checksums if it finds what it
thinks is a "meaningful" checksum table (which perhaps it hasn't done
in my case!)

With best wishes, Jaime

Re: [Linuxsampler-devel] gig file integrity check fails for original (nemsys) gigapiano and other instruments

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

On Mittwoch, 1. November 2017 13:16:58 CET Jaime T wrote:
> Tascam BG (Biggagigga/Purgatory Creek) Rhodes (md5sum: 0fa5...):
> Verifying sample checksum table ... DAMAGED
> 
> Could anyone please give me an idea of what is causing this? I can
> provide any diagnostic info required and/or I can upload these to
> cloud-storage if needed.

If the integrity check for a sample failed, gigdump prints you both the 
expected checksum, as well as the actual checksum it calculated. Compare the 
two checksums printed on the screen. If they simply look mirrored like:

	"aabbccdd" vs "ddccbbaa"

then simply ignore this error. That was a bug in libgig before and your 
samples are fine. And in that case you can simply run

	gigdump --rebuild-checksums foo.gig

to get rid of this false error in the file.

If however the two printed checksums look completely different, then your 
samples "may be" damaged. But again, there was a bug in libgig before where 
not all sample checksums were updated after making certain modifications with 
libgig (i.e. using gigedit) before. So in that case you might need to check 
the individual samples manually (i.e. with your ear), because there might be 
potentially noise, clicks or something like that. And again if all sounds fine 
run

	gigdump --rebuild-checksums foo.gig

See also

	man gigdump

About one year ago, when I accidentally damaged one of my gig files and 
actually started using this feature, I actually found out that there were 
several bugs regarding those checksums, editing and integrity check for many 
years without anybody noticing it. I fixed them, so it should work fine now.

CU
Christian

[Linuxsampler-devel] gig file integrity check fails for original (nemsys) gigapiano and other instruments

[Jaime T <eno...@gm...>]

Hi all.

I use linuxsampler with various pianos, and I thought I'd try out the
gig file integrity check offered by gigdump (using a very recent
self-compile from subversion). I was surprised to find the following
results:

Tascam's "original" nemesys gigapiano (.gig md5sum: 0175...):
Verifying sample checksum table ... DAMAGED

Artvista's Malmsjo Acoustic Grand (.gig md5sum: 886b...):
Verifying sample checksum table ... DAMAGED

Tascam BG (Biggagigga/Purgatory Creek) Rhodes (md5sum: 0fa5...):
Verifying sample checksum table ... DAMAGED

Could anyone please give me an idea of what is causing this? I can
provide any diagnostic info required and/or I can upload these to
cloud-storage if needed.

Many thanks, Jaime

Re: [Linuxsampler-devel] LinuxSampler's libraries compilation on Debian Stretch

[Nicola P. <nic...@gm...>]

Il 12/10/2017 16:53, Christian Schoenebeck ha scritto:
> On Montag, 9. Oktober 2017 13:25:25 CEST Nicola Pandini wrote:
>> Thank you Christian!
>> I successfully compiled libgig, but I'm still having issues compiling
>> linuxsampler. I attached the log of my last attempt with rev 3353.
> Fixed (SVN r3354).

All apps and libs compiled flawlessy now, kudos to you, Christian :-)

-- 
Nicola

Re: [Linuxsampler-devel] LinuxSampler's libraries compilation on Debian Stretch

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

On Montag, 9. Oktober 2017 13:25:25 CEST Nicola Pandini wrote:
> Thank you Christian!
> I successfully compiled libgig, but I'm still having issues compiling
> linuxsampler. I attached the log of my last attempt with rev 3353.

Fixed (SVN r3354).

CU
Christian

Re: [Linuxsampler-devel] LinuxSampler's libraries compilation on Debian Stretch

[Nicola P. <nic...@gm...>]

Il 07/10/2017 20:18, Christian Schoenebeck ha scritto:
> On Thursday, September 14, 2017 4:51:29 PM CEST Christian Schoenebeck wrote:
>> On Wednesday, September 13, 2017 16:27:47 Nicola Pandini wrote:
>>> Hi,
>>>
>>> I'mencountering errors trying to compile linuxsampler and related
>>> libraries under Debian Stretch.
>>> I've followed the "LinuxSampler for Debian" guide (dpkg-buildpackage
>>> -rfakeroot -b).
>> You are too fast for me. I haven't upgraded to Debian 9 yet.
> I just committed some fixes for Debian 9 "Stretch". All debs build flawlessly on
> Debian 9 now.

Thank you Christian!
I successfully compiled libgig, but I'm still having issues compiling 
linuxsampler. I attached the log of my last attempt with rev 3353.

-- 
Nicola

Re: [Linuxsampler-devel] LinuxSampler's libraries compilation on Debian Stretch

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

On Thursday, September 14, 2017 4:51:29 PM CEST Christian Schoenebeck wrote:
> On Wednesday, September 13, 2017 16:27:47 Nicola Pandini wrote:
> > Hi,
> > 
> > I'mencountering errors trying to compile linuxsampler and related
> > libraries under Debian Stretch.
> > I've followed the "LinuxSampler for Debian" guide (dpkg-buildpackage
> > -rfakeroot -b).
> 
> You are too fast for me. I haven't upgraded to Debian 9 yet.

I just committed some fixes for Debian 9 "Stretch". All debs build flawlessly on 
Debian 9 now.

CU
Christian

Re: [Linuxsampler-devel] Problem compiling for RBPi3

[Jofemodo <fer...@zy...>]

Hi! I've no received any answer about this subject yet ...

RaspBerry Pi, aswell as other ARM platforms, should be supported by
LinuxSampler out the box. It's a pitty they're not supported, and only
for a few lines of code.

LinuxSampler is a wonderful piece of software that can be really useful
for many Open Source DIY projects. This projects normally use ARM
platforms (RBPi and others) as a base ...

Thanks a lot!


El 06/09/17 a las 14:27, Jofemodo escribió:
> 
> We have this patch that fix the problem:
> 
> https://github.com/steveb/rpi_linuxsampler_patch.git
> 
> Thanks,
> 
> 
> El 06/09/17 a las 14:05, Jofemodo escribió:
>>
>> Hello!
>>
>> When compiling for RBPi3 i get this error:
>>
>> bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H
>> -I. -I../..    -Wreturn-type -ffast-math  -mcpu=cortex-a53
>> -mfpu=neon-fp-armv8 -mneon-for-64bits -mfloat-abi=hard
>> -mvectorize-with-neon-quad -pthread -MT Thread.lo -MD -MP -MF
>> $depbase.Tpo -c -o Thread.lo Thread.cpp &&\
>> mv -f $depbase.Tpo $depbase.Plo
>> RTMath.cpp:77:8: error: #error "Sorry, LinuxSampler lacks time stamp
>> code for your system."
>>      #  error "Sorry, LinuxSampler lacks time stamp code for your system."
>>         ^
>> RTMath.cpp:78:8: error: #error "Please report this error and the CPU you
>> are using to the LinuxSampler developers mailing list!"
>>      #  error "Please report this error and the CPU you are using to the
>> LinuxSampler developers mailing list!"
>>         ^
>>
>> I'm compiling for Raspberry Pi 3 (ARM architecture), in a up-to-date
>> Raspbian Jessie distribution.
>>
>> Thanks!
>>
> 
> 


-- 
José Fernando Moyano Dominguez
 + Email: fer...@zy...
 + Teléfono: +34 625 642 820
----------------------------------------------------------------------
Zynthian: the Open Synth Platform
 + Web: http://zynthian.org
 + Blog: http://blog.zynthian.org
----------------------------------------------------------------------

Re: [Linuxsampler-devel] LinuxSampler's libraries compilation on Debian Stretch

[Nicola P. <nic...@gm...>]

Hi,
I'm trying to compile linuxsampler & co. with the classic ./configure + 
make + sudo make install combination.
I never do that (with linuxsampler), so I ask you if I'm doing right:

# libgig
make -f Makefile.svn $*
CXXFLAGS="-O3 -msse -march=core2 -mfpmath=sse -ffast-math 
-fomit-frame-pointer -funroll-loops" ./configure --prefix=/usr 
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
make
sudo make install

# linuxsampler
make -f Makefile.svn $*
CXXFLAGS="-O3 -msse -march=core2 -mfpmath=sse -ffast-math 
-fomit-frame-pointer -funroll-loops" ./configure --prefix=/usr 
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
make
sudo make install

# liblscp
make -f Makefile.git $*
CXXFLAGS="-O3 -msse -march=core2 -mfpmath=sse -ffast-math 
-fomit-frame-pointer -funroll-loops" ./configure --prefix=/usr 
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
make
sudo make install

Is it right? "make -f Makefile.svn $*" Is the right method to generate 
.config file?

     thanks

Il 15/09/2017 10:23, Nicola Pandini ha scritto:
> Il 14/09/2017 16:51, Christian Schoenebeck ha scritto:
>> On Wednesday, September 13, 2017 16:27:47 Nicola Pandini wrote:
>>> Hi,
>>>
>>> I'mencountering errors trying to compile linuxsampler and related
>>> libraries under Debian Stretch.
>>> I've followed the "LinuxSampler for Debian" guide (dpkg-buildpackage
>>> -rfakeroot -b).
>> You are too fast for me. I haven't upgraded to Debian 9 yet.
> :-) I'm just testing. I will use a fresh Debian Stretch installation, 
> so I'm checking if all my vital software will work.
>
>
>>> Libgig does not compile, saying:
>>>> dpkg-gencontrol: error: Depends field of package libgig-dev: obsolete
>>>> substitution variable ${Source-Version}
>>>> dh_gencontrol: dpkg-gencontrol -plibgig-dev -ldebian/changelog
>>>> -Tdebian/libgig-dev.substvars -Pdebian/libgig-dev returned exit code 255
>>>> debian/rules:76: recipe for target 'binary-arch' failed
>>>> make: *** [binary-arch] Error 2
>>>> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
>>>> status 2
>>> Liblscp:
>>>> debian/rules:45: recipe for target 'clean' failed
>>>> make: *** [clean] Error 25
>>>> dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit
>>>> status 2
>>> I can't say if linuxsampler, qsampler and gigedit would compile, because
>>> of unmet depenencies.
>>> Can you give me a hint? Thanks!
>>  From the snippets you posted its hard to tell what's wrong. The actual errors
>> are certainly earlier.
> I've attached the full compilation logs of both libgig and liblscp.
>
>
>> However if the Debian packaging script complains about unmet build
>> dependencies, then it should also output which build dependencies are not met.
>> Like with all major Debian releases the respective Debian packages required to
>> be installed prior to compiling the LS packages might have slightly been
>> renamed.
>
> Before I started compiling, I did an apt-get build-dep of all the 
> linuxsampler's libraries, in order to install all the dependencies.
> I don't know if linuxsampler and liblinuxsampler will compile simply 
> because it asks for libgig to be installed :-)
>
>
>
> -- 
> Nicola


-- 
Nicola

Re: [Linuxsampler-devel] LinuxSampler's libraries compilation on Debian Stretch

[Nicola P. <nic...@gm...>]

Il 14/09/2017 16:51, Christian Schoenebeck ha scritto:
> On Wednesday, September 13, 2017 16:27:47 Nicola Pandini wrote:
>> Hi,
>>
>> I'mencountering errors trying to compile linuxsampler and related
>> libraries under Debian Stretch.
>> I've followed the "LinuxSampler for Debian" guide (dpkg-buildpackage
>> -rfakeroot -b).
> You are too fast for me. I haven't upgraded to Debian 9 yet.
:-) I'm just testing. I will use a fresh Debian Stretch installation, so 
I'm checking if all my vital software will work.


>
>> Libgig does not compile, saying:
>>> dpkg-gencontrol: error: Depends field of package libgig-dev: obsolete
>>> substitution variable ${Source-Version}
>>> dh_gencontrol: dpkg-gencontrol -plibgig-dev -ldebian/changelog
>>> -Tdebian/libgig-dev.substvars -Pdebian/libgig-dev returned exit code 255
>>> debian/rules:76: recipe for target 'binary-arch' failed
>>> make: *** [binary-arch] Error 2
>>> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
>>> status 2
>> Liblscp:
>>> debian/rules:45: recipe for target 'clean' failed
>>> make: *** [clean] Error 25
>>> dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit
>>> status 2
>> I can't say if linuxsampler, qsampler and gigedit would compile, because
>> of unmet depenencies.
>> Can you give me a hint? Thanks!
>  From the snippets you posted its hard to tell what's wrong. The actual errors
> are certainly earlier.
I've attached the full compilation logs of both libgig and liblscp.


>
> However if the Debian packaging script complains about unmet build
> dependencies, then it should also output which build dependencies are not met.
> Like with all major Debian releases the respective Debian packages required to
> be installed prior to compiling the LS packages might have slightly been
> renamed.

Before I started compiling, I did an apt-get build-dep of all the 
linuxsampler's libraries, in order to install all the dependencies.
I don't know if linuxsampler and liblinuxsampler will compile simply 
because it asks for libgig to be installed :-)



-- 
Nicola

Re: [Linuxsampler-devel] LinuxSampler's libraries compilation on Debian Stretch

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

On Wednesday, September 13, 2017 16:27:47 Nicola Pandini wrote:
> Hi,
> 
> I'mencountering errors trying to compile linuxsampler and related
> libraries under Debian Stretch.
> I've followed the "LinuxSampler for Debian" guide (dpkg-buildpackage
> -rfakeroot -b).

You are too fast for me. I haven't upgraded to Debian 9 yet.

> Libgig does not compile, saying:
> > dpkg-gencontrol: error: Depends field of package libgig-dev: obsolete
> > substitution variable ${Source-Version}
> > dh_gencontrol: dpkg-gencontrol -plibgig-dev -ldebian/changelog
> > -Tdebian/libgig-dev.substvars -Pdebian/libgig-dev returned exit code 255
> > debian/rules:76: recipe for target 'binary-arch' failed
> > make: *** [binary-arch] Error 2
> > dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
> > status 2
> 
> Liblscp:
> > debian/rules:45: recipe for target 'clean' failed
> > make: *** [clean] Error 25
> > dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit
> > status 2
> 
> I can't say if linuxsampler, qsampler and gigedit would compile, because
> of unmet depenencies.
> Can you give me a hint? Thanks!

>From the snippets you posted its hard to tell what's wrong. The actual errors 
are certainly earlier.

However if the Debian packaging script complains about unmet build 
dependencies, then it should also output which build dependencies are not met. 
Like with all major Debian releases the respective Debian packages required to 
be installed prior to compiling the LS packages might have slightly been 
renamed.

CU
Christian

[Linuxsampler-devel] LinuxSampler's libraries compilation on Debian Stretch

[Nicola P. <nic...@gm...>]

Hi,

I'mencountering errors trying to compile linuxsampler and related 
libraries under Debian Stretch.
I've followed the "LinuxSampler for Debian" guide (dpkg-buildpackage 
-rfakeroot -b).

Libgig does not compile, saying:
> dpkg-gencontrol: error: Depends field of package libgig-dev: obsolete 
> substitution variable ${Source-Version}
> dh_gencontrol: dpkg-gencontrol -plibgig-dev -ldebian/changelog 
> -Tdebian/libgig-dev.substvars -Pdebian/libgig-dev returned exit code 255
> debian/rules:76: recipe for target 'binary-arch' failed
> make: *** [binary-arch] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit 
> status 2

Liblscp:
> debian/rules:45: recipe for target 'clean' failed
> make: *** [clean] Error 25
> dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit 
> status 2

I can't say if linuxsampler, qsampler and gigedit would compile, because 
of unmet depenencies.
Can you give me a hint? Thanks!

-- 
Nicola

Re: [Linuxsampler-devel] Problem compiling for RBPi3

[Jofemodo <fer...@zy...>]

We have this patch that fix the problem:

https://github.com/steveb/rpi_linuxsampler_patch.git

Thanks,


El 06/09/17 a las 14:05, Jofemodo escribió:
> 
> Hello!
> 
> When compiling for RBPi3 i get this error:
> 
> bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H
> -I. -I../..    -Wreturn-type -ffast-math  -mcpu=cortex-a53
> -mfpu=neon-fp-armv8 -mneon-for-64bits -mfloat-abi=hard
> -mvectorize-with-neon-quad -pthread -MT Thread.lo -MD -MP -MF
> $depbase.Tpo -c -o Thread.lo Thread.cpp &&\
> mv -f $depbase.Tpo $depbase.Plo
> RTMath.cpp:77:8: error: #error "Sorry, LinuxSampler lacks time stamp
> code for your system."
>      #  error "Sorry, LinuxSampler lacks time stamp code for your system."
>         ^
> RTMath.cpp:78:8: error: #error "Please report this error and the CPU you
> are using to the LinuxSampler developers mailing list!"
>      #  error "Please report this error and the CPU you are using to the
> LinuxSampler developers mailing list!"
>         ^
> 
> I'm compiling for Raspberry Pi 3 (ARM architecture), in a up-to-date
> Raspbian Jessie distribution.
> 
> Thanks!
> 


-- 
José Fernando Moyano Dominguez
 + Email: fer...@zy...
 + Teléfono: +34 625 642 820
----------------------------------------------------------------------
Zynthian: the Open Synth Platform
 + Web: http://zynthian.org
 + Blog: http://blog.zynthian.org
----------------------------------------------------------------------

[Linuxsampler-devel] Problem compiling for RBPi3

[Jofemodo <fer...@zy...>]

Hello!

When compiling for RBPi3 i get this error:

bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H
-I. -I../..    -Wreturn-type -ffast-math  -mcpu=cortex-a53
-mfpu=neon-fp-armv8 -mneon-for-64bits -mfloat-abi=hard
-mvectorize-with-neon-quad -pthread -MT Thread.lo -MD -MP -MF
$depbase.Tpo -c -o Thread.lo Thread.cpp &&\
mv -f $depbase.Tpo $depbase.Plo
RTMath.cpp:77:8: error: #error "Sorry, LinuxSampler lacks time stamp
code for your system."
     #  error "Sorry, LinuxSampler lacks time stamp code for your system."
        ^
RTMath.cpp:78:8: error: #error "Please report this error and the CPU you
are using to the LinuxSampler developers mailing list!"
     #  error "Please report this error and the CPU you are using to the
LinuxSampler developers mailing list!"
        ^

I'm compiling for Raspberry Pi 3 (ARM architecture), in a up-to-date
Raspbian Jessie distribution.

Thanks!

-- 
José Fernando Moyano Dominguez
 + Email: fer...@zy...
 + Teléfono: +34 625 642 820
----------------------------------------------------------------------
Zynthian: the Open Synth Platform
 + Web: http://zynthian.org
 + Blog: http://blog.zynthian.org
----------------------------------------------------------------------