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

Re: [Linuxsampler-devel] import instruments from directory broken?

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

On Wednesday, January 11, 2017 22:52:54 Andrew Dabrowski wrote:
> OK, I'm on Arch linux and I just replaced linuxsampler by linuxsampler-svn.
> 
> I see that that the suggested fix is in the svn code already.
> 
> But I still have the same problem, whether I use jsampler or the command
> line I can't get linuxsampler to add anything to the instruments db.

The mentioned instruments DB fix which is already applied to the SVN version, 
addressed undefined behavior when accessing the instruments data base. That 
bug caused things like corrupt database and crashes.

However I guess your issue is something else: you are trying to scan a 
directory with sfz files, right?

CU
Christian

Re: [Linuxsampler-devel] import instruments from directory broken?

[Andrew D. <ajd...@bl...>]

OK, I'm on Arch linux and I just replaced linuxsampler by linuxsampler-svn.

I see that that the suggested fix is in the svn code already.

But I still have the same problem, whether I use jsampler or the command 
line I can't get linuxsampler to add anything to the instruments db.



On 01/11/2017 02:14 AM, Robert Schneider wrote:
> Hi Andrew,
>
> is that the same issue that I posted in the linuxsampler forum 
> http://bb.linuxsampler.org/viewtopic.php?f=6&t=3352&sid=94125c1e809888e5e4f69de90040fc07
>
> There is a fix for it in the reply dated 16.10.2016 16:36
> InstrumentsDb.cpp#1654:
> int res = sqlite3_bind_text(pStmt, Index, Text.c_str(), -1, 
> SQLITE_TRANSIENT);
>
> It was acknowledged to be the proper fix. Wonder that it hasn't made 
> it into the code yet.
>
> Regards
> On 10.01.2017 19:41, Andrew Dabrowski wrote:
>> I'm brand new to linuxsampler and was disappointed to find that the 
>> import-from-directory function for instruments doesn't seem to work.  
>> Is this a known issue?  Is there a workaround?
>>
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>>
>>
>> _______________________________________________
>> Linuxsampler-devel mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>
> -- 
> Robert Schneider
> Am Rebhuhnfeld 6
> 85241 Ampermoching
> Fon: +49 8139 92850
> Mobile: +49 176 3892 7669
> Ema...@ar...

Re: [Linuxsampler-devel] import instruments from directory broken?

[Andrew D. <ajd...@bl...>]

Yes, I think that's the same bug, thanks for the clue.  I'll get the 
source code and try the fix suggested.


On 01/11/2017 02:14 AM, Robert Schneider wrote:
> Hi Andrew,
>
> is that the same issue that I posted in the linuxsampler forum 
> http://bb.linuxsampler.org/viewtopic.php?f=6&t=3352&sid=94125c1e809888e5e4f69de90040fc07
>
> There is a fix for it in the reply dated 16.10.2016 16:36
> InstrumentsDb.cpp#1654:
> int res = sqlite3_bind_text(pStmt, Index, Text.c_str(), -1, 
> SQLITE_TRANSIENT);
>
> It was acknowledged to be the proper fix. Wonder that it hasn't made 
> it into the code yet.
>
> Regards
> On 10.01.2017 19:41, Andrew Dabrowski wrote:
>> I'm brand new to linuxsampler and was disappointed to find that the 
>> import-from-directory function for instruments doesn't seem to work.  
>> Is this a known issue?  Is there a workaround?
>>
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today.http://sdm.link/xeonphi
>>
>>
>> _______________________________________________
>> Linuxsampler-devel mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
>
> -- 
> Robert Schneider
> Am Rebhuhnfeld 6
> 85241 Ampermoching
> Fon: +49 8139 92850
> Mobile: +49 176 3892 7669
> Ema...@ar...

Re: [Linuxsampler-devel] import instruments from directory broken?

[Andrew D. <ajd...@bl...>]

Yes, import-from-dir into the instruments db.  I tried doing it both 
through jsampler and by telneting and using the command line.  Neither 
produced any error but neither added any instruments into the db.


On 01/11/2017 07:15 AM, Christian Schoenebeck wrote:
> On Tuesday, January 10, 2017 13:41:10 Andrew Dabrowski wrote:
>> I'm brand new to linuxsampler and was disappointed to find that the
>> import-from-directory function for instruments doesn't seem to work.  Is
>> this a known issue?  Is there a workaround?
> What exactly are you talking about? Do you mean the instruments DB? And what
> are you using for that attempt, Fantasia? Command line?
>
> CU
> Christian
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

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

On Wednesday, January 11, 2017 19:42:56 Frank Neumann wrote:
> > It needs to be debugged, for example by commenting out various synthesis
> > components to narrow down the source of this issue.
> 
> You can use me as your guinea pig - just give me a hint how and where I can
> comment/disable	them.

First of all, I would force a constant velocity value being used by the 
sampler, as provided by the attached hack. That way you can forget about all 
MIDI input issues for now and just concentrate on the actual bug.

Then your playground will be src/engines/common/AbstractVoice.cpp. You find a 
method there called AbstractVoice::Synthesize(). That's actually the heart of 
it all. Disable synthesis components there (i.e. EQ, EGs, filter, etc.) until 
the issue disappears.

CU
Christian

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Alby M. <alb...@gm...>]

Hi Frank,

I've attached zoomed-in images of the transients of the first and fifth
hits. I still don't see any difference.

 - A

On Wed, Jan 11, 2017 at 12:49 PM Frank Neumann <bea...@we...> wrote:

>
> Hi Alby,
>
> > I'm unable to reproduce this using Ardour, QSampler, and LinuxSampler
> 2.0.0
> > (built from source). Using the attached SFZ file I get no audible or
> > visible differences. I've attached an image of three hits from the
> > recording.
>
> Hm..interesting. Could you zoom in onto the onset (roughly the first 50ms)
> of
> each beat? The "big picture" doesn't really show the effect I am seeing,
> you
> have to look a lot closer.
>
> > Frank, could you be using a different version of LinuxSampler?
>
> Mine says 2.0.0.svn31; I don't know how to retrieve the Subversion version
> from the binary, though.
>
> Greetings,
> Frank
>
>
> > On Wed, Jan 11, 2017 at 11:46 AM Frank Neumann <bea...@we...> wrote:
> >
> > >
> > > Hi Christian,
> > >
> > > > > - Why is the playback not giving constantly the same audio output?
> > > Could
> > > > > this actually be a bug?
> > > >
> > > > Yes, it seems to be a bug in the SFZ engine.
> > > >
> > > > > - If there is some kind of AMP envelope automatically applied upon
> > > each and
> > > > >   every sample playback (perhaps to avoid the "onset clicks"?), how
> > > can I
> > > > > disable it to be sure my original sample's playback is
> authentically
> > > > > reproduced?
> > > >
> > > > It needs to be debugged, for example by commenting out various
> synthesis
> > > > components to narrow down the source of this issue.
> > >
> > > You can use me as your guinea pig - just give me a hint how and where
> I can
> > > comment/disable them.
> > >
> > > Thanks,
> > > Frank
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > Developer Access Program for Intel Xeon Phi Processors
> > > Access to Intel Xeon Phi processor-based developer platforms.
> > > With one year of Intel Parallel Studio XE.
> > > Training and support from Colfax.
> > > Order your platform today. http://sdm.link/xeonphi
> > > _______________________________________________
> > > Linuxsampler-devel mailing list
> > > Lin...@li...
> > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> > >
>

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi Alby,

> I'm unable to reproduce this using Ardour, QSampler, and LinuxSampler 2.0.0
> (built from source). Using the attached SFZ file I get no audible or
> visible differences. I've attached an image of three hits from the
> recording.

Hm..interesting. Could you zoom in onto the onset (roughly the first 50ms) of
each beat? The "big picture" doesn't really show the effect I am seeing, you
have to look a lot closer.

> Frank, could you be using a different version of LinuxSampler?

Mine says 2.0.0.svn31; I don't know how to retrieve the Subversion version
from the binary, though.

Greetings,
Frank


> On Wed, Jan 11, 2017 at 11:46 AM Frank Neumann <bea...@we...> wrote:
> 
> >
> > Hi Christian,
> >
> > > > - Why is the playback not giving constantly the same audio output?
> > Could
> > > > this actually be a bug?
> > >
> > > Yes, it seems to be a bug in the SFZ engine.
> > >
> > > > - If there is some kind of AMP envelope automatically applied upon
> > each and
> > > >   every sample playback (perhaps to avoid the "onset clicks"?), how
> > can I
> > > > disable it to be sure my original sample's playback is authentically
> > > > reproduced?
> > >
> > > It needs to be debugged, for example by commenting out various synthesis
> > > components to narrow down the source of this issue.
> >
> > You can use me as your guinea pig - just give me a hint how and where I can
> > comment/disable them.
> >
> > Thanks,
> > Frank
> >
> >
> > ------------------------------------------------------------------------------
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi
> > _______________________________________________
> > Linuxsampler-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> >

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Alby M. <alb...@gm...>]

Hi all,

I'm unable to reproduce this using Ardour, QSampler, and LinuxSampler 2.0.0
(built from source). Using the attached SFZ file I get no audible or
visible differences. I've attached an image of three hits from the
recording.

Frank, could you be using a different version of LinuxSampler?

 - A

On Wed, Jan 11, 2017 at 11:46 AM Frank Neumann <bea...@we...> wrote:

>
> Hi Christian,
>
> > > - Why is the playback not giving constantly the same audio output?
> Could
> > > this actually be a bug?
> >
> > Yes, it seems to be a bug in the SFZ engine.
> >
> > > - If there is some kind of AMP envelope automatically applied upon
> each and
> > >   every sample playback (perhaps to avoid the "onset clicks"?), how
> can I
> > > disable it to be sure my original sample's playback is authentically
> > > reproduced?
> >
> > It needs to be debugged, for example by commenting out various synthesis
> > components to narrow down the source of this issue.
>
> You can use me as your guinea pig - just give me a hint how and where I can
> comment/disable them.
>
> Thanks,
> Frank
>
>
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi Christian,

> > - Why is the playback not giving constantly the same audio output? Could
> > this actually be a bug?
> 
> Yes, it seems to be a bug in the SFZ engine.
> 
> > - If there is some kind of AMP envelope automatically applied upon each and
> >   every sample playback (perhaps to avoid the "onset clicks"?), how can I
> > disable it to be sure my original sample's playback is authentically
> > reproduced?
> 
> It needs to be debugged, for example by commenting out various synthesis 
> components to narrow down the source of this issue.

You can use me as your guinea pig - just give me a hint how and where I can
comment/disable	them.

Thanks,
Frank

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi Alby and all,

> That's strange. I'm not one of the LinuxSampler devs, so I can't say if
> there's an obvious cause for this in LinuxSampler itself, but those tests
> certainly remove any causes I can see in the SFZ file.
> 
> Your file doesn't contain any <group>s, <master>s, or <global>s, does it?

No, it's really just straight mappings.

What I am interested in - has anyone been able to reproduce this?

That is: Create a one-liner .sfz from the line I stated below, correct the
path to the .wav I had attached to an earlier mail of this thread, start up
Linuxsampler and arm a track with this .sfz, feed a constant (looped)
sequence of, say, quarter notes to it (10 beats should be enough), record
the audio output with e.g. jack_capture and inspect the .wav file in a wave
editor. The difference in the onset of the notes should become apparent pretty
soon as you zoom into the individual beats.

I want to make sure it's not me doing something stupid here - that has
happened before :-).

Thanks,
Frank


> 
> On Tue, Jan 10, 2017 at 11:20 AM Frank Neumann <bea...@we...> wrote:
> 
> >
> > Hi Alby,
> >
> > thanks for your suggestions.
> >
> > > Is that the whole SFZ file? I can see two possible causes in that
> > snippet,
> >
> > The file is really a bit longer, but it contains just key assignments for
> > 17
> > more samples, on different keys. No LFO definitions or some such, if you
> > were
> > thinking of that. I now trimmed it down to really just that one line, same
> > results.
> >
> > > but there could be others if the file has other sections. The snippet
> > sets
> > > a rate for an LFO controlling pitch; while the depth of that modulation
> > > should be zero, it's possible that it defaults to something else and that
> > > that processing is responsible for the differences you hear. Another
> > > possibility is that the amplitude envelope has a non-zero attack time.
> > That
> > > can be fixed by adding `ampeg_attack=0`.
> >
> > I tried adding ampeg_attack=0 to that line in the .sfz, no effect.
> >
> > > Are all your input notes the same velocity?
> >
> > Yes; I was trusting my sequencer software, but now I also checked with
> > aseqdump. It's constant velocity across all events, in this case 64.
> >
> > > Do you get the same results using this?:
> > >
> > > <region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
> > > kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
> >
> > Compared to my original .sfz file entry, you are also removing the
> > "pitch_keycenter" variable which of course affects the sample playback
> > (I assume it's now played back 3 octaves deeper), but I guess you didn't
> > really want me to test that. I removed all other statements from that
> > .sfz line (amp_veltrack=71.653542 ampeg_decay=200.199997
> > ampeg_release=200.199997 pitchlfo_freq=5.000919), and tried again, but
> > still no difference.
> >
> > Greetings,
> > Frank
> >
> >
> > > On Mon, Jan 9, 2017 at 3:35 PM Frank Neumann <bea...@we...> wrote:
> > >
> > >
> > > Hi list,
> > >
> > > I was experimenting a bit with Linuxsampler and sequencer64 yesterday,
> > and
> > > found a little oddity (two, actually): I have loaded a .sfz with a
> > couple of
> > > synthetic drum samples into LinuxSampler (version LinuxSampler
> > 2.0.0.svn31)
> > > and send "4-to-the-floor" kick drum MIDI events to it via sequencer64
> > > (output
> > > device from LinuxSampler is JACK).
> > >
> > > Though the events are identical with regard to velocity etc, I can
> > clearly
> > > hear that the samples produced by LinuxSampler are varying slight every
> > now
> > > and
> > > then in their attack phase. There is roughly 1 "different" (harder, more
> > > direct) kick drum in every 8 or so events.
> > > This is NOT due to some round-robin scheme; there really is only one Kick
> > > drum
> > > .wav file assigned to this key.
> > > Also, I observed no JACK xruns while testing this.
> > >
> > > This is the corresponding line from the .sfz mapping this kick drum:
> > >
> > > <region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
> > > kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
> > > pitch_keycenter=36 amp_veltrack=71.653542 ampeg_decay=200.199997
> > > ampeg_release=200.199997 pitchlfo_freq=5.000919
> > >
> > > That original .wav file is also attached.
> > >
> > > I grabbed a short recording via jack_capture and looked at the resulting
> > > .wav
> > > in a wave editor; here I clearly see why the sounds really sound
> > different
> > > (see attached pictures: orig_wave.png is the original .wav file,
> > > "soft_wave.png"
> > > is one of the (frequent) samples with somewhat softer attack (is there
> > any
> > > AMP envelope applied to every sample at playback?) and "hard_wave.png" is
> > > one
> > > of the (more rare) sample playbacks with stronger reproduction of the
> > > original
> > > sample's attack phase.
> > >
> > > So, there are really two questions in this:
> > > - Why is the playback not giving constantly the same audio output? Could
> > > this
> > >   actually be a bug?
> > > - If there is some kind of AMP envelope automatically applied upon each
> > and
> > >   every sample playback (perhaps to avoid the "onset clicks"?), how can I
> > > disable
> > >   it to be sure my original sample's playback is authentically
> > reproduced?
> > >
> > > Thanks,
> > > Frank
> > >
> > ------------------------------------------------------------------------------
> > > Developer Access Program for Intel Xeon Phi Processors
> > > Access to Intel Xeon Phi processor-based developer platforms.
> > > With one year of Intel Parallel Studio XE.
> > > Training and support from Colfax.
> > > Order your platform today. http://sdm.link/xeonphi
> > > _______________________________________________
> > > Linuxsampler-devel mailing list
> > > Lin...@li...
> > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> >

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

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

On Monday, January 09, 2017 23:32:01 Frank Neumann wrote:
> So, there are really two questions in this:
> - Why is the playback not giving constantly the same audio output? Could
> this actually be a bug?

Yes, it seems to be a bug in the SFZ engine.

> - If there is some kind of AMP envelope automatically applied upon each and
>   every sample playback (perhaps to avoid the "onset clicks"?), how can I
> disable it to be sure my original sample's playback is authentically
> reproduced?

It needs to be debugged, for example by commenting out various synthesis 
components to narrow down the source of this issue.

CU
Christian

Re: [Linuxsampler-devel] import instruments from directory broken?

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

On Tuesday, January 10, 2017 13:41:10 Andrew Dabrowski wrote:
> I'm brand new to linuxsampler and was disappointed to find that the
> import-from-directory function for instruments doesn't seem to work.  Is
> this a known issue?  Is there a workaround?

What exactly are you talking about? Do you mean the instruments DB? And what 
are you using for that attempt, Fantasia? Command line?

CU
Christian

[Linuxsampler-devel] import instruments from directory broken?

[Andrew D. <ajd...@bl...>]

I'm brand new to linuxsampler and was disappointed to find that the 
import-from-directory function for instruments doesn't seem to work.  Is 
this a known issue?  Is there a workaround?

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Alby M. <alb...@gm...>]

Hi Frank,

That's strange. I'm not one of the LinuxSampler devs, so I can't say if
there's an obvious cause for this in LinuxSampler itself, but those tests
certainly remove any causes I can see in the SFZ file.

Your file doesn't contain any <group>s, <master>s, or <global>s, does it?

 - A.

On Tue, Jan 10, 2017 at 11:20 AM Frank Neumann <bea...@we...> wrote:

>
> Hi Alby,
>
> thanks for your suggestions.
>
> > Is that the whole SFZ file? I can see two possible causes in that
> snippet,
>
> The file is really a bit longer, but it contains just key assignments for
> 17
> more samples, on different keys. No LFO definitions or some such, if you
> were
> thinking of that. I now trimmed it down to really just that one line, same
> results.
>
> > but there could be others if the file has other sections. The snippet
> sets
> > a rate for an LFO controlling pitch; while the depth of that modulation
> > should be zero, it's possible that it defaults to something else and that
> > that processing is responsible for the differences you hear. Another
> > possibility is that the amplitude envelope has a non-zero attack time.
> That
> > can be fixed by adding `ampeg_attack=0`.
>
> I tried adding ampeg_attack=0 to that line in the .sfz, no effect.
>
> > Are all your input notes the same velocity?
>
> Yes; I was trusting my sequencer software, but now I also checked with
> aseqdump. It's constant velocity across all events, in this case 64.
>
> > Do you get the same results using this?:
> >
> > <region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
> > kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
>
> Compared to my original .sfz file entry, you are also removing the
> "pitch_keycenter" variable which of course affects the sample playback
> (I assume it's now played back 3 octaves deeper), but I guess you didn't
> really want me to test that. I removed all other statements from that
> .sfz line (amp_veltrack=71.653542 ampeg_decay=200.199997
> ampeg_release=200.199997 pitchlfo_freq=5.000919), and tried again, but
> still no difference.
>
> Greetings,
> Frank
>
>
> > On Mon, Jan 9, 2017 at 3:35 PM Frank Neumann <bea...@we...> wrote:
> >
> >
> > Hi list,
> >
> > I was experimenting a bit with Linuxsampler and sequencer64 yesterday,
> and
> > found a little oddity (two, actually): I have loaded a .sfz with a
> couple of
> > synthetic drum samples into LinuxSampler (version LinuxSampler
> 2.0.0.svn31)
> > and send "4-to-the-floor" kick drum MIDI events to it via sequencer64
> > (output
> > device from LinuxSampler is JACK).
> >
> > Though the events are identical with regard to velocity etc, I can
> clearly
> > hear that the samples produced by LinuxSampler are varying slight every
> now
> > and
> > then in their attack phase. There is roughly 1 "different" (harder, more
> > direct) kick drum in every 8 or so events.
> > This is NOT due to some round-robin scheme; there really is only one Kick
> > drum
> > .wav file assigned to this key.
> > Also, I observed no JACK xruns while testing this.
> >
> > This is the corresponding line from the .sfz mapping this kick drum:
> >
> > <region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
> > kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
> > pitch_keycenter=36 amp_veltrack=71.653542 ampeg_decay=200.199997
> > ampeg_release=200.199997 pitchlfo_freq=5.000919
> >
> > That original .wav file is also attached.
> >
> > I grabbed a short recording via jack_capture and looked at the resulting
> > .wav
> > in a wave editor; here I clearly see why the sounds really sound
> different
> > (see attached pictures: orig_wave.png is the original .wav file,
> > "soft_wave.png"
> > is one of the (frequent) samples with somewhat softer attack (is there
> any
> > AMP envelope applied to every sample at playback?) and "hard_wave.png" is
> > one
> > of the (more rare) sample playbacks with stronger reproduction of the
> > original
> > sample's attack phase.
> >
> > So, there are really two questions in this:
> > - Why is the playback not giving constantly the same audio output? Could
> > this
> >   actually be a bug?
> > - If there is some kind of AMP envelope automatically applied upon each
> and
> >   every sample playback (perhaps to avoid the "onset clicks"?), how can I
> > disable
> >   it to be sure my original sample's playback is authentically
> reproduced?
> >
> > Thanks,
> > Frank
> >
> ------------------------------------------------------------------------------
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi
> > _______________________________________________
> > Linuxsampler-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi Alby,

thanks for your suggestions.

> Is that the whole SFZ file? I can see two possible causes in that snippet,

The file is really a bit longer, but it contains just key assignments for 17
more samples, on different keys. No LFO definitions or some such, if you were
thinking of that. I now trimmed it down to really just that one line, same
results.

> but there could be others if the file has other sections. The snippet sets
> a rate for an LFO controlling pitch; while the depth of that modulation
> should be zero, it's possible that it defaults to something else and that
> that processing is responsible for the differences you hear. Another
> possibility is that the amplitude envelope has a non-zero attack time. That
> can be fixed by adding `ampeg_attack=0`.

I tried adding ampeg_attack=0 to that line in the .sfz, no effect.

> Are all your input notes the same velocity?

Yes; I was trusting my sequencer software, but now I also checked with
aseqdump. It's constant velocity across all events, in this case 64.

> Do you get the same results using this?:
> 
> <region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
> kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616

Compared to my original .sfz file entry, you are also removing the 
"pitch_keycenter" variable which of course affects the sample playback
(I assume it's now played back 3 octaves deeper), but I guess you didn't
really want me to test that. I removed all other statements from that
.sfz line (amp_veltrack=71.653542 ampeg_decay=200.199997
ampeg_release=200.199997 pitchlfo_freq=5.000919), and tried again, but
still no difference.

Greetings,
Frank


> On Mon, Jan 9, 2017 at 3:35 PM Frank Neumann <bea...@we...> wrote:
> 
> 
> Hi list,
> 
> I was experimenting a bit with Linuxsampler and sequencer64 yesterday, and
> found a little oddity (two, actually): I have loaded a .sfz with a couple of
> synthetic drum samples into LinuxSampler (version LinuxSampler 2.0.0.svn31)
> and send "4-to-the-floor" kick drum MIDI events to it via sequencer64
> (output
> device from LinuxSampler is JACK).
> 
> Though the events are identical with regard to velocity etc, I can clearly
> hear that the samples produced by LinuxSampler are varying slight every now
> and
> then in their attack phase. There is roughly 1 "different" (harder, more
> direct) kick drum in every 8 or so events.
> This is NOT due to some round-robin scheme; there really is only one Kick
> drum
> .wav file assigned to this key.
> Also, I observed no JACK xruns while testing this.
> 
> This is the corresponding line from the .sfz mapping this kick drum:
> 
> <region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
> kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
> pitch_keycenter=36 amp_veltrack=71.653542 ampeg_decay=200.199997
> ampeg_release=200.199997 pitchlfo_freq=5.000919
> 
> That original .wav file is also attached.
> 
> I grabbed a short recording via jack_capture and looked at the resulting
> .wav
> in a wave editor; here I clearly see why the sounds really sound different
> (see attached pictures: orig_wave.png is the original .wav file,
> "soft_wave.png"
> is one of the (frequent) samples with somewhat softer attack (is there any
> AMP envelope applied to every sample at playback?) and "hard_wave.png" is
> one
> of the (more rare) sample playbacks with stronger reproduction of the
> original
> sample's attack phase.
> 
> So, there are really two questions in this:
> - Why is the playback not giving constantly the same audio output? Could
> this
>   actually be a bug?
> - If there is some kind of AMP envelope automatically applied upon each and
>   every sample playback (perhaps to avoid the "onset clicks"?), how can I
> disable
>   it to be sure my original sample's playback is authentically reproduced?
> 
> Thanks,
> Frank
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

[Linuxsampler-devel] SFZ and RT instrument scripts

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

Hi guys!

Since most of you seem to be in favor of the sfz engine nowadays, I just added 
support for real-time instrument scripts to the sfz engine as well now. For 
that purpose I added a new sfz opcode "script". You can find out more about 
this new opcode here:

	http://doc.linuxsampler.org/Instrument_Scripts/#sfz

And since I was at it, you might notice that I also added an entirely new 
documentation section dedicated to the sfz file format:

	http://doc.linuxsampler.org/sfz/

Because as of to date there is unfortunately no single place on the net where 
you can find sufficient, detailed informations about the sfz format for free. 
Most sites just list i.e. opcodes, but without describing their intended 
behavior in detail (or at all).

Any volunteers on filling up informations about the sfz file format *very* 
*much* *appreciated* ! Keep in mind, the better this format becomes 
documented, the better we can implement it to behave as expected, and the more 
people will use it. You can find the sfz documentation's source files here:

	http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/doc/docbase/sfz/

Our site automatically generates syntax highlighting for sfz code, as well as 
cross references to mentioned sfz sections and sfz opcodes automatically for 
you. So our site already cuts away the major mechanical tasks when writing 
such documentation.

CU
Christian

Re: [Linuxsampler-devel] Identical MIDI events cause sound variations?

[Alby M. <alb...@gm...>]

Hi Frank,

Is that the whole SFZ file? I can see two possible causes in that snippet,
but there could be others if the file has other sections. The snippet sets
a rate for an LFO controlling pitch; while the depth of that modulation
should be zero, it's possible that it defaults to something else and that
that processing is responsible for the differences you hear. Another
possibility is that the amplitude envelope has a non-zero attack time. That
can be fixed by adding `ampeg_attack=0`.

Are all your input notes the same velocity?

Do you get the same results using this?:

<region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616

Best,
A.

On Mon, Jan 9, 2017 at 3:35 PM Frank Neumann <bea...@we...> wrote:


Hi list,

I was experimenting a bit with Linuxsampler and sequencer64 yesterday, and
found a little oddity (two, actually): I have loaded a .sfz with a couple of
synthetic drum samples into LinuxSampler (version LinuxSampler 2.0.0.svn31)
and send "4-to-the-floor" kick drum MIDI events to it via sequencer64
(output
device from LinuxSampler is JACK).

Though the events are identical with regard to velocity etc, I can clearly
hear that the samples produced by LinuxSampler are varying slight every now
and
then in their attack phase. There is roughly 1 "different" (harder, more
direct) kick drum in every 8 or so events.
This is NOT due to some round-robin scheme; there really is only one Kick
drum
.wav file assigned to this key.
Also, I observed no JACK xruns while testing this.

This is the corresponding line from the .sfz mapping this kick drum:

<region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep
kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616
pitch_keycenter=36 amp_veltrack=71.653542 ampeg_decay=200.199997
ampeg_release=200.199997 pitchlfo_freq=5.000919

That original .wav file is also attached.

I grabbed a short recording via jack_capture and looked at the resulting
.wav
in a wave editor; here I clearly see why the sounds really sound different
(see attached pictures: orig_wave.png is the original .wav file,
"soft_wave.png"
is one of the (frequent) samples with somewhat softer attack (is there any
AMP envelope applied to every sample at playback?) and "hard_wave.png" is
one
of the (more rare) sample playbacks with stronger reproduction of the
original
sample's attack phase.

So, there are really two questions in this:
- Why is the playback not giving constantly the same audio output? Could
this
  actually be a bug?
- If there is some kind of AMP envelope automatically applied upon each and
  every sample playback (perhaps to avoid the "onset clicks"?), how can I
disable
  it to be sure my original sample's playback is authentically reproduced?

Thanks,
Frank
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Linuxsampler-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

[Linuxsampler-devel] Identical MIDI events cause sound variations?

[Frank N. <bea...@we...>]

Hi list,

I was experimenting a bit with Linuxsampler and sequencer64 yesterday, and
found a little oddity (two, actually): I have loaded a .sfz with a couple of 
synthetic drum samples into LinuxSampler (version LinuxSampler 2.0.0.svn31) 
and send "4-to-the-floor" kick drum MIDI events to it via sequencer64 (output
device from LinuxSampler is JACK).

Though the events are identical with regard to velocity etc, I can clearly
hear that the samples produced by LinuxSampler are varying slight every now and
then in their attack phase. There is roughly 1 "different" (harder, more
direct) kick drum in every 8 or so events.
This is NOT due to some round-robin scheme; there really is only one Kick drum
.wav file assigned to this key.
Also, I observed no JACK xruns while testing this.

This is the corresponding line from the .sfz mapping this kick drum:

<region> sample=..\..\..\wa_drum_tools_01_deluxe\drum kits\deep sleep kit\dt01_kits_deepsleep_kick808.wav lokey=36 hikey=36 end=17616 pitch_keycenter=36 amp_veltrack=71.653542 ampeg_decay=200.199997 ampeg_release=200.199997 pitchlfo_freq=5.000919

That original .wav file is also attached.

I grabbed a short recording via jack_capture and looked at the resulting .wav
in a wave editor; here I clearly see why the sounds really sound different
(see attached pictures: orig_wave.png is the original .wav file, "soft_wave.png"
is one of the (frequent) samples with somewhat softer attack (is there any
AMP envelope applied to every sample at playback?) and "hard_wave.png" is one
of the (more rare) sample playbacks with stronger reproduction of the original
sample's attack phase.

So, there are really two questions in this:
- Why is the playback not giving constantly the same audio output? Could this
  actually be a bug?
- If there is some kind of AMP envelope automatically applied upon each and
  every sample playback (perhaps to avoid the "onset clicks"?), how can I disable
  it to be sure my original sample's playback is authentically reproduced?

Thanks,
Frank

[Linuxsampler-devel] MIDI controller issues - I need your help

[Shio G. Q. <qu...@ya...>]

To whom it may concern
I have not used a MIDI controller(s) before.
So I wonder if this can be done (please refer to the attached image [can this be done.png]).- Two(2) USB MIDI controller connected to the PC, one with 61 keys, one with many buttons.- The one with 61 keys controls which key to be played (like a manual on the organ).- The one with many buttons controls which kind of sound (trumpet? flute? string?) to be played (like stop knobs on the organ).
I suspect something like
[Alesis Q61 61-Key USB/MIDI Keyboard Controller] & [Novation Launchpad Mini MK2 Ableton Live Controller]may work.
May I know if Linuxsampler with JSampler Fantasia can do this?
Thanks

Re: [Linuxsampler-devel] Debian installation procedure

[Shio G. Q. <qu...@ya...>]

Dear Christian
Thanks for reply.
I am building a digital pipe organ. I have synthesized tone at 96000Hz, 32bit, 60-second loop.
(Even an "Advanced" license of Hauptwerk is NOT enough for me!)I have actually tested Linux Sampler, gigedit, JSampler Fantasia and on windows, 
everything works fine thus far, but I do not have any MIDI controller(s) yet.
So I wonder if this can be done (please refer to the attached image [can this be done.png]).- Two(2) USB MIDI controller connected to the PC, one with 61 keys, one with many buttons.- The one with 61 keys controls which key to be played (like a manual on the organ).- The one with many buttons controls which kind of sound (trumpet? flute? string?) to be played (like stop knobs on the organ).
I suspect something like
[Alesis Q61 61-Key USB/MIDI Keyboard Controller] & [Novation Launchpad Mini MK2 Ableton Live Controller]may work.
May I know if Linuxsampler with JSampler Fantasia can do this?
Thanks
ShioGai Quek


 

    On Friday, January 6, 2017 3:15 AM, Christian Schoenebeck <sch...@li...> wrote:
 

 On Wednesday, January 04, 2017 17:16:09 Shio Gai Quek wrote:
> I am completely new to linux sampler. I have tried debian before.
> 
> I saw an outdated
> websitehttp://davidbolton.info/articles/build_linuxsampler.html posting
> about installation of linux sampler on debian.

Here is another one (also quite old though):

    http://linuxsampler.org/debian.html

> Since the precomplied .deb files are now ready, may I know if this procedure
> shall works? (top-down)
> sudo dpkg -i libgig7_4.0.0-1_amd64.deb
> sudo dpkg -i gigtools_4.0.0-1_amd64.deb
> sudo dpkg -i libgig-dev_4.0.0-1_amd64.deb
> sudo dpkg -i gigedit_1.0.0-1_amd64.deb
> sudo dpkg -i liblinuxsampler_2.0.0-1_amd64.deb
> sudo dpkg -i liblinuxsampler-dev_2.0.0-1_amd64.deb  
> sudo dpkg -i linuxsampler_2.0.0-1_amd64.deb

Install gigedit last, because gigedit depends on liblinuxsampler.

> Moreover, do I need to download the .change files as well?

No, you just need the .deb files.

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] Debian installation procedure

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

On Wednesday, January 04, 2017 17:16:09 Shio Gai Quek wrote:
> I am completely new to linux sampler. I have tried debian before.
> 
> I saw an outdated
> websitehttp://davidbolton.info/articles/build_linuxsampler.html posting
> about installation of linux sampler on debian.

Here is another one (also quite old though):

	http://linuxsampler.org/debian.html

> Since the precomplied .deb files are now ready, may I know if this procedure
> shall works? (top-down)
> sudo dpkg -i libgig7_4.0.0-1_amd64.deb
> sudo dpkg -i gigtools_4.0.0-1_amd64.deb
> sudo dpkg -i libgig-dev_4.0.0-1_amd64.deb
> sudo dpkg -i gigedit_1.0.0-1_amd64.deb
> sudo dpkg -i liblinuxsampler_2.0.0-1_amd64.deb
> sudo dpkg -i liblinuxsampler-dev_2.0.0-1_amd64.deb   
> sudo dpkg -i linuxsampler_2.0.0-1_amd64.deb

Install gigedit last, because gigedit depends on liblinuxsampler.

> Moreover, do I need to download the .change files as well?

No, you just need the .deb files.

CU
Christian

[Linuxsampler-devel] Debian installation procedure

[Shio G. Q. <qu...@ya...>]

I am completely new to linux sampler. I have tried debian before.

I saw an outdated websitehttp://davidbolton.info/articles/build_linuxsampler.html
posting about installation of linux sampler on debian.
Since the precomplied .deb files are now ready, may I know if this procedure shall works?
(top-down)
sudo dpkg -i libgig7_4.0.0-1_amd64.deb
sudo dpkg -i gigtools_4.0.0-1_amd64.deb
sudo dpkg -i libgig-dev_4.0.0-1_amd64.deb
sudo dpkg -i gigedit_1.0.0-1_amd64.deb
sudo dpkg -i liblinuxsampler_2.0.0-1_amd64.deb
sudo dpkg -i liblinuxsampler-dev_2.0.0-1_amd64.deb    
sudo dpkg -i linuxsampler_2.0.0-1_amd64.deb
Moreover, do I need to download the .change files as well?
Thanks
quekshg

Re: [Linuxsampler-devel] RIP Windows 32 bit builds?

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

On Sunday, October 09, 2016 19:55:54 Andreas Persson wrote:
> Just so you know, I'm working on this now. My plan is to use prebuilt
> dll files from the msys2 project. This means I have to use a newer
> compiler than the one provided by Debian. The compiler is installed and
> used on the build server for win 32 bit, but I haven't finished the
> changes in the installer scripts yet.

That's timing. I was already starting to abandon the 32 bit Windows build by 
updating the Windows installer. So I guess I am not committing that. ;-)

Thanks for letting me know!

CU
Christian

Re: [Linuxsampler-devel] RIP Windows 32 bit builds?

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

Christian Schoenebeck wrote:
> On Monday, September 26, 2016 20:44:17 Christian Schoenebeck wrote:
>> On Monday, September 26, 2016 18:30:21 Andreas Persson wrote:
>>> I tried to copy the dll files from the build server
>>> (/usr/lib/gcc/i686-w64-mingw32/4.9-win32), and then linuxsampler.exe
>>> starts without errors, but neither gigedit nor qsampler work. I think we
>>> must find or build new versions of the Qt and gtkmm libs compatible with
>>> the newer gcc.
>>
>> I was actually currently trying another approach, I was playing on the
>> libgig-win32 target and added "-static-libgcc -static-libstdc++" and removed
>> "--disable-static". It builds fine but fails when it tries to link one of
>> the command line tools, because some of the static symbols are now tried to
>> be included to both the libgig DLLs as well as the command line
>> applications.
>>
>> I give up for today. Maybe tomorrow ...
> 
> I had a look at compiling a new GTKMM version for the 32-bit Windows build 
> server today, however GTKMM requires such a huge crap chain of library 
> dependencies that it would take ages to compile all of them. Total horror 
> show! Did I mention before how much I regret not having switched to Qt for 
> gigedit somewhere in the past? *grrrr*
> 
Just so you know, I'm working on this now. My plan is to use prebuilt
dll files from the msys2 project. This means I have to use a newer
compiler than the one provided by Debian. The compiler is installed and
used on the build server for win 32 bit, but I haven't finished the
changes in the installer scripts yet.

/Andreas

[Linuxsampler-devel] RIP Windows 32 bit builds?

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

On Monday, September 26, 2016 20:44:17 Christian Schoenebeck wrote:
> On Monday, September 26, 2016 18:30:21 Andreas Persson wrote:
> > I tried to copy the dll files from the build server
> > (/usr/lib/gcc/i686-w64-mingw32/4.9-win32), and then linuxsampler.exe
> > starts without errors, but neither gigedit nor qsampler work. I think we
> > must find or build new versions of the Qt and gtkmm libs compatible with
> > the newer gcc.
> 
> I was actually currently trying another approach, I was playing on the
> libgig-win32 target and added "-static-libgcc -static-libstdc++" and removed
> "--disable-static". It builds fine but fails when it tries to link one of
> the command line tools, because some of the static symbols are now tried to
> be included to both the libgig DLLs as well as the command line
> applications.
> 
> I give up for today. Maybe tomorrow ...

I had a look at compiling a new GTKMM version for the 32-bit Windows build 
server today, however GTKMM requires such a huge crap chain of library 
dependencies that it would take ages to compile all of them. Total horror 
show! Did I mention before how much I regret not having switched to Qt for 
gigedit somewhere in the past? *grrrr*

How about compltely dropping support for 32 bit Windows machines with our 
installer? I mean is anybody still using a 32 bit Windows machine actually? My 
guess is that there is almost nobody still using a 32 bit Windows system, and 
if so, then there are probably more useful things to spend my time on.

CU
Christian