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

[Linuxsampler-devel] U subcribe me please

[dougham.ca <dou...@sb...>]

    




Sent from my Samsung Galaxy Tab® S

[Linuxsampler-devel] svn server attack

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

Hi guys,

on March 2nd we had an attack on our svn server. Due to that we took most 
services temporarily offline on March 3rd to protect people from accessing any 
potentially compromised material and to prevent further damage.

After investigating this incident we came to the conclusion that the attack 
and its damage was fortunately quite limited. We rolled back the system, 
closed the exploited security hole and finally brought all services back 
online today.

In case you accessed any source files from our svn server between March 2nd 
and March 3rd, we encourage you to delete the entire source directory and make 
a fresh svn checkout. The svn server is now back at a clean state.

Additionally, several old svn user accounts have been disabled for now. In 
case you haven't been active for a while and your svn user account doesn't 
work anymore, just contact me or Andreas and you will get your account
re-enabled with a new password.

CU
Christian

[Linuxsampler-devel] Linux sampler commercial license

[Balogh M. <spi...@ya...>]

Dear developers, 

I am writing on behalf a company that would like to build a commercial product based on LinuxSampler. I didn't know exactly who is responsible for this so I kindly ask anyone reading this and being able to discuss further on licensing to contact me by email or to forward me to the proper person.

Thank you!

[Linuxsampler-devel] Linux Audio Conference 2017: LAC2017 extended deadline for all submissions February 28

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

Hi all,

in case someone is still interested in handing in a paper, presentations or
other material :-).

Greetings,
Frank


======================================================

Extension of the deadline for all submissions to Tuesday 28 February 2017, 23:59 GMT+1 (Saint-Etienne time)

Linux Audio Conference LAC2017. 
18-21 May, 2017 - Saint-Etienne, France

https://lac2017.univ-st-etienne.fr


========== Special INFORMATION =========================

========== Paul DAVIS special guest during LAC2017 ===========
Mr. Paul Davis will introduce the LAC2017 conference in Saint-Etienne.

================ Important Dates =========================

Extended deadline for submissions: February 28, 2017
Acceptance notification: March 25, 2017
Final deadline for ‘camera ready’ paper: April 15, 2017
Author registration deadline: April 20, 2017


Urgent questions: la...@li... 
More info on the conference website (updated frequently): https://lac2017.univ-st-etienne.fr


Organising team:
• CIEREC (Centre Interdisciplinaire d’Étude et de Recherche sur l’Expression Contemporaine)
• Music Department of Jean Monnet University (UJM)
• GRAME (National Center for Musical Creation)
• Random-Lab, Center for Open Researches in Art, Design and New Media at ESADSE (Art School of Saint-Etienne)
• Associations « Le son des choses » (Acousmatic Music).


Best regards, 

Laurent Pottier


--
********************************************
Université Jean Monnet
CIEREC - EA3068
35, rue du 11 novembre
42023 Saint-Etienne Cedex 02 - France
port. : +33(0)6 21 66 28 76
tel : +33(0)4 77 42 16 61
fax : +33(0)4 77 42 16 84

lau...@un...
********************************************

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

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

On Sunday, February 05, 2017 11:29:04 Frank Neumann wrote:
> > Frank, I just committed this little patch to SVN which should fix this
> > issue for you.
> 
> Confirmed! Tried it just now, clean playback of that kick drum sample for
> several minutes now. I'm happy, thank you so much! :-)

No problem!

> > I got no response from Grigor or Andreas about this issue, so I will
> > probably address the other potential cases (where this misbehavior might
> > occur as well) of the SFZ format in some way in the next couple days.
> > Requires a bunch of changes in the SFZ engine.
> 
> Thanks, very much appreciated. I have not noticed any other places with
> similar issues, but then again my test scenario (including the .sfz files
> themselves) was very limited and simple until now.

Right, it works for you now because your sfz files seem to be very simple. The 
other cases where one can still encounter this issue, occur when defining some 
modulators in the sfz file which shall become active with a delay after a 
certain amount of time. But I'm on those issues as well, so they should be 
fixed soon.

CU
Christian

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

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

Hi Christian and all,

> On Monday, January 23, 2017 17:04:34 Christian Schoenebeck wrote:
> > Index: src/engines/common/SignalUnit.cpp
> > ===================================================================
> > --- src/engines/common/SignalUnit.cpp	(revision 3099)
> > +++ src/engines/common/SignalUnit.cpp	(working copy)
> > @@ -25,6 +25,6 @@
> > 
> >  namespace LinuxSampler {
> >      bool SignalUnit::DelayStage() {
> > -        return (DelayTrigger() >= pRack->GetCurrentStep());
> > +        return (DelayTrigger() > pRack->GetCurrentStep());
> >      }
> >  } // namespace LinuxSampler
> 
> Frank, I just committed this little patch to SVN which should fix this issue 
> for you.

Confirmed! Tried it just now, clean playback of that kick drum sample for
several minutes now. I'm happy, thank you so much! :-)

> I got no response from Grigor or Andreas about this issue, so I will probably 
> address the other potential cases (where this misbehavior might occur as well) 
> of the SFZ format in some way in the next couple days. Requires a bunch of 
> changes in the SFZ engine.

Thanks, very much appreciated. I have not noticed any other places with
similar issues, but then again my test scenario (including the .sfz files
themselves) was very limited and simple until now.

Greetings,
Frank

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

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

On Monday, January 23, 2017 17:04:34 Christian Schoenebeck wrote:
> Index: src/engines/common/SignalUnit.cpp
> ===================================================================
> --- src/engines/common/SignalUnit.cpp	(revision 3099)
> +++ src/engines/common/SignalUnit.cpp	(working copy)
> @@ -25,6 +25,6 @@
> 
>  namespace LinuxSampler {
>      bool SignalUnit::DelayStage() {
> -        return (DelayTrigger() >= pRack->GetCurrentStep());
> +        return (DelayTrigger() > pRack->GetCurrentStep());
>      }
>  } // namespace LinuxSampler

Frank, I just committed this little patch to SVN which should fix this issue 
for you.

I got no response from Grigor or Andreas about this issue, so I will probably 
address the other potential cases (where this misbehavior might occur as well) 
of the SFZ format in some way in the next couple days. Requires a bunch of 
changes in the SFZ engine.

CU
Christian

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

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

On Monday, January 23, 2017 00:32:40 Frank Neumann wrote:
> Just summarizing, for clarity sake: With these 2 changes applied, the issue
> is gone (of course this is not a fix yet):

@Grigor, @Andreas: are you still around on this list? Maybe you can comment as 
well, because I am not very familiar with the SignalUnitRack stuff of the SFZ 
engine.

I had a look at this issue described by Frank. It is a bug in the 
SignalUnitRack handling. In very short, the following would fix the issue 
Frank encountered with his SFZ file:


Index: src/engines/common/SignalUnit.cpp
===================================================================
--- src/engines/common/SignalUnit.cpp	(revision 3099)
+++ src/engines/common/SignalUnit.cpp	(working copy)
@@ -25,6 +25,6 @@
 
 namespace LinuxSampler {
     bool SignalUnit::DelayStage() {
-        return (DelayTrigger() >= pRack->GetCurrentStep());
+        return (DelayTrigger() > pRack->GetCurrentStep());
     }
 } // namespace LinuxSampler


But, and there is a big "but", that short patch would just cure the symptom in 
Frank's particular case, as far as I can see it, the bug would still be 
triggered in other scenarios (more complex SFZ files) though. So here is a 
more detailed description about this issue:

The SFZ engine is calling:

	pSignalUnitRack->GetEndpointUnit()->GetVolume()

inside of method AbstractVoice::Synthesize() to get the current volume factor 
to be applied for the voice in the current audio (sub)fragment. Since Frank's 
sfz file is very simple (no volume modulators), that GetVolume() call would 
always return 1.0f (neutral volume factor), except of one case: at the very 
beginning of the life time of each voice (that is when pVoice->Pos == 0.0) 
that GetVolume() call returns 0.0f instead. And that is wrong.

GetVolume() does return 0.0f at the very beginning of a voice's life time, 
because EndPointUnit::GetVolume() calls
suVolEG.GetLevel() [SfzSignalUnitRack.cpp, line 617], which is implemented 
like this [SfzSignalUnitRack.h, line 165]:

	virtual float GetLevel() { return DelayStage() ? 0 : EG.getLevel(); }

Now in Frank's case, it is simply a bug to assume that it would be in a delay 
stage at the beginning of the voice's life time and the short patch above 
would fix it. But apart from Frank's case, simply returning 0 here looks odd 
to me.

As I said, I am not familiar with the SignalUnitRack code base, but 
intuitively I would rather expect the GetLevel() implementation either

a) to always return EG.getLevel() (even in delay stage) or

b) to return an "identity element" in delay stage instead, which depends on 
whether that result is going to be used in a mathematical add operation (in 
which case the identity element is 0) or rather in a mathematical multiply 
operation (in which case the identity element is 1).

Thoughts? Am I missing something?

CU
Christian

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

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

Hi once more,

> However - finally *some* good news for the weekend :-). When I disable the
> whole CONFIG_INTERPOLATE_VOLUME block in AbstractVoice.cpp (I simply replaced
> line 231,
> 
> #ifdef CONFIG_INTERPOLATE_VOLUME
> 
> with 
> 
> #if 0
> )
> 
> THEN, the issue is gone and the kick sound comes through correctly each time
> (listened for some 2 minutes now).
> 
> Furthermore, if I reduce the "if(pSignalUnitRack...)" code in there a little,
> the issue also remains gone:
> 
> 242c242,244
> <                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pEG1->getLevel();
> ---
> >                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume ;
> > //                finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pEG1->getLevel();
> > 
> 244c246,248
> <                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
> ---
> >                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume ;
> > //                finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
> > 
> 
> So then, it's somewhere in the pEG1 or pSignalUnitRack handling. A small step ahead :-).

Just summarizing, for clarity sake: With these 2 changes applied, the issue
is gone (of course this is not a fix yet):

--- src/engines/common/AbstractVoice.cpp.orig   2017-01-15 13:08:46.174155350 +0100
+++ src/engines/common/AbstractVoice.cpp        2017-01-23 00:31:28.283565968 +0100
@@ -241,7 +241,8 @@
             if (pSignalUnitRack == NULL) {
                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pEG1->getLevel();
             } else {
-                finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
+                finalVolume = pEngineChannel->MidiVolume * crossfadeVolume ;
+//                finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
             }
 
             finalSynthesisParameters.fFinalVolumeLeft  = finalVolume * VolumeLeft  * PanLeftSmoother.render();
@@ -526,9 +527,9 @@
                 }*/
                 // TODO: ^^^
 
-                fFinalVolume   *= pSignalUnitRack->GetEndpointUnit()->GetVolume();
-                fFinalCutoff    = pSignalUnitRack->GetEndpointUnit()->CalculateFilterCutoff(fFinalCutoff);
-                fFinalResonance = pSignalUnitRack->GetEndpointUnit()->CalculateResonance(fFinalResonance);
+//                fFinalVolume   *= pSignalUnitRack->GetEndpointUnit()->GetVolume();
+//                fFinalCutoff    = pSignalUnitRack->GetEndpointUnit()->CalculateFilterCutoff(fFinalCutoff);
+//                fFinalResonance = pSignalUnitRack->GetEndpointUnit()->CalculateResonance(fFinalResonance);
                 
                 finalSynthesisParameters.fFinalPitch =
                     pSignalUnitRack->GetEndpointUnit()->CalculatePitch(finalSynthesisParameters.fFinalPitch);

Greetings,
Frank

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

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

Hi again,

> > Ok, so the bug existed already before the last tarball release.
> > 
> > > "I'll be back" when I have news :-).
> > 
> > I probably have some suspicion. Which audio driver are you using? JACK? ALSA? 
> > CoreAudio?
> 
> I have conducted all tests so far with the JACK driver; I tested just now with
> the ALSA audio driver, but the problem is the same.
> 
> I'll next see if an older laptop I have here (running a 32bit LinuxMint
> distribution) also shows the issue - maybe I have a 64bit problem.

That test again showed no difference from the behaviour on a 64-Bit LinuxMint
system (my regular desktop PC).

However - finally *some* good news for the weekend :-). When I disable the
whole CONFIG_INTERPOLATE_VOLUME block in AbstractVoice.cpp (I simply replaced
line 231,

#ifdef CONFIG_INTERPOLATE_VOLUME

with 

#if 0
)

THEN, the issue is gone and the kick sound comes through correctly each time
(listened for some 2 minutes now).

Furthermore, if I reduce the "if(pSignalUnitRack...)" code in there a little,
the issue also remains gone:

242c242,244
<                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pEG1->getLevel();
---
>                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume ;
> //                finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pEG1->getLevel();
> 
244c246,248
<                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
---
>                 finalVolume = pEngineChannel->MidiVolume * crossfadeVolume ;
> //                finalVolume = pEngineChannel->MidiVolume * crossfadeVolume * pSignalUnitRack->GetEndpointUnit()->GetVolume();
> 

So then, it's somewhere in the pEG1 or pSignalUnitRack handling. A small step ahead :-).

Greetings,
Frank

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

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

Hi Christian,

> On Saturday, January 21, 2017 10:08:23 Frank Neumann wrote:
> > I tried that revision, but the issue appears with that one as well for me
> > (original source code, none of my changes applied).
> 
> Ok, so the bug existed already before the last tarball release.
> 
> > "I'll be back" when I have news :-).
> 
> I probably have some suspicion. Which audio driver are you using? JACK? ALSA? 
> CoreAudio?

I have conducted all tests so far with the JACK driver; I tested just now with
the ALSA audio driver, but the problem is the same.

I'll next see if an older laptop I have here (running a 32bit LinuxMint
distribution) also shows the issue - maybe I have a 64bit problem.

Greetimgs,
Frank

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

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

On Saturday, January 21, 2017 16:53:54 lin...@ar... wrote:
> I tried to import SFZ, GIG and SF2 with the newest build but always get
> errors. Are there any known limitations as to what can be imported and what
> can not. Has anybody already successfully imported a significant amount of
> SFZ, SF2 or GIG?

The instruments DB feature was orphaned for quite a while. Accordingly there 
might still be bugs to fix. The only way to resolve this, is at least to 
describe and demonstrate the precise issues you encountered, or even better: 
providing a patch for fixing the problem.

CU
Christian

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

[<lin...@ar...>]

Hi,

I tried to import SFZ, GIG and SF2 with the newest build but always get errors. 
Are there any known limitations as to what can be imported and what can not. Has 
anybody already successfully imported a significant amount of SFZ, SF2 or GIG?

Regards,

Robert
On 17.01.2017 00:20, Christian Schoenebeck wrote:
> On Thursday, January 12, 2017 20:12:12 Christian Schoenebeck wrote:
>> When I find some time, I can add the missing scanner code for sfz files to
>> the instruments DB feature. It just needs couple lines of code as far as I
>> can see it right now.
> Hmm, those original "couple lines" propagated like rabbits, but it is finally
> done. Latest SVN version of LinuxSampler supports scanning .sfz and .sf2 files
> out of the box.
>
> Give it a try!
>
> 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


-- 
Robert Schneider
Am Rebhuhnfeld 6
85241 Ampermoching
Fon: +49 8139 92850
Mobile: +49 176 3892 7669
Email Rob...@ar...

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

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

On Saturday, January 21, 2017 10:08:23 Frank Neumann wrote:
> I tried that revision, but the issue appears with that one as well for me
> (original source code, none of my changes applied).

Ok, so the bug existed already before the last tarball release.

> "I'll be back" when I have news :-).

I probably have some suspicion. Which audio driver are you using? JACK? ALSA? 
CoreAudio?

CU
Christian

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

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

Hi Christian,

> > - To make sure I am not fooled by some issue with my sound card (M-Audio
> >   Audiophile 2496), I set up playback of the same file with qtractor and
> >   Rui's "drumkv1" LV2 plugin. That one delivers stable "correct" audio data,
> > so the problem really appear to stem from LinuxSampler itself.
> 
> No doubt about that. As I said before, it seems to be a bug on LS side.
> 
> Since Alby M. said he was unable to reproduce that issue with the official 
> tarball release LS 2.0.0, maybe you give that version a short try, just to see 
> if that bug had been accidentally introduced in the meantime:
> 
> 	svn update -r2789

I tried that revision, but the issue appears with that one as well for me (original
source code, none of my changes applied).

"I'll be back" when I have news :-).

Greetings,
Frank

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

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

On Friday, January 20, 2017 00:27:08 Frank Neumann wrote:
> - The only other interesting observation from today was to see what happens
> if I change the jackd buffer size. My standard buffer size here is 128
> frames, and with that there is roughly one correctly played sample in about
> 10 events.
>   If I increase the buffer size to 1024 frames, the issue is a lot more rare
> - I have to wait up to a minute to hear one correctly played sample. One
> the other side, reducing the buffer size to 64 frames creates more correct
> playbacks - roughly 1 out of 4.
>   Not sure if this brings us closer to the root cause, but still
> interesting.

Good to know.

> - To make sure I am not fooled by some issue with my sound card (M-Audio
>   Audiophile 2496), I set up playback of the same file with qtractor and
>   Rui's "drumkv1" LV2 plugin. That one delivers stable "correct" audio data,
> so the problem really appear to stem from LinuxSampler itself.

No doubt about that. As I said before, it seems to be a bug on LS side.

Since Alby M. said he was unable to reproduce that issue with the official 
tarball release LS 2.0.0, maybe you give that version a short try, just to see 
if that bug had been accidentally introduced in the meantime:

	svn update -r2789

CU
Christian

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

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

Hi Christian and all,

> > > > 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.
> 
> Any finding in the meantime Frank?

Hm...not a lot so far. Let me list:
- I hard-coded the velocity as per your suggestion, but that didn't change anything.
  I believe I can trust my sequencer software to produce stable velocity output :-).

- I disabled a couple of things in AbstraceVoice.cpp as you suggested (I have
  attached a diff against the current version of that file). Again, no change
  yet, this issue still appears.

- I noticed that - when comparing original sample playback against Linuxsampler's
  output - that LinuxSampler "gets it wrong most of the time" and only a minority
  of the events are playing back the sample correctly.
  The original sample has a pretty hard "click" at the beginning (I attached
  again a very close-up view of the first 50 or so frames of that sample as seen
  in Audacity, file "original_sample.png"), and it's this click I wanted to hear 
  reproduced by LinuxSampler. Most of the sounds it produces are a lot softer, 
  though, but I believe I stated that before.

- The only other interesting observation from today was to see what happens if
  I change the jackd buffer size. My standard buffer size here is 128 frames,
  and with that there is roughly one correctly played sample in about 10
  events.
  If I increase the buffer size to 1024 frames, the issue is a lot more rare -
  I have to wait up to a minute to hear one correctly played sample.
  One the other side, reducing the buffer size to 64 frames creates more correct
  playbacks - roughly 1 out of 4.
  Not sure if this brings us closer to the root cause, but still interesting.

- To make sure I am not fooled by some issue with my sound card (M-Audio
  Audiophile 2496), I set up playback of the same file with qtractor and 
  Rui's "drumkv1" LV2 plugin. That one delivers stable "correct" audio data,
  so the problem really appear to stem from LinuxSampler itself.

I'll continue fooling around with AbstraceVoice.cpp :-).

Greetings,
Frank

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

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

On Wednesday, January 11, 2017 20:59:10 Christian Schoenebeck wrote:
> 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.

Any finding in the meantime Frank?

CU
Christian

Re: [Linuxsampler-devel] SFZ set_ccN directive

[Giovanni S. <gio...@gm...>]

No, that was a first try.
when I wrote that patch, I firstly thought to create a copy of Controllers
Table, i didn't have any idea on how handle the set_ccN. After some
investigations I got the way and
where put the code but i forgotten to change the size..... last evening i
tried to switch between two different soundfonts and I experienced few
strange behaviors with my midi controller so this morning i fixed the size.

that's all.


On Wed, Jan 18, 2017 at 12:58 PM, Christian Schoenebeck <
sch...@li...> wrote:

> On Tuesday, January 17, 2017 20:11:30 Giovanni Senatore wrote:
> > hello guys,
> > since I'm using a SFZ soundfont that needs some CC settings (without no
> > sound can be played) that are set by set_cc directive in the control
> > header, yesterday I wrote a quick and simple patch for linuxsampler. It
> > seems to work
> > fine for me, I don't know if you want to test in some way, to implement
> > better or something else and then use in the official source tree.
>
> I will adjust it a bit, i.e. that only the CCs set in the sfz file are
> going
> to be actually set, then I will commit it later today. Thanks!
>
> I see that you allow to set CCs beyond the limit of 127 controllers. On
> engine
> side we use 128 and 129 for pitch bend and aftertouch. How are those
> mentioned
> to be set in the sfz standard?
>
> 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] SFZ set_ccN directive

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

On Tuesday, January 17, 2017 20:11:30 Giovanni Senatore wrote:
> hello guys,
> since I'm using a SFZ soundfont that needs some CC settings (without no
> sound can be played) that are set by set_cc directive in the control
> header, yesterday I wrote a quick and simple patch for linuxsampler. It
> seems to work
> fine for me, I don't know if you want to test in some way, to implement
> better or something else and then use in the official source tree.

I will adjust it a bit, i.e. that only the CCs set in the sfz file are going 
to be actually set, then I will commit it later today. Thanks!

I see that you allow to set CCs beyond the limit of 127 controllers. On engine 
side we use 128 and 129 for pitch bend and aftertouch. How are those mentioned 
to be set in the sfz standard?

CU
Christian

[Linuxsampler-devel] SFZ set_ccN directive

[Giovanni S. <gio...@gm...>]

hello guys,
since I'm using a SFZ soundfont that needs some CC settings (without no
sound can be played) that are set by set_cc directive in the control
header, yesterday I wrote a quick and simple patch for linuxsampler. It
seems to work
fine for me, I don't know if you want to test in some way, to implement
better or something else and then use in the official source tree.

Giovanni

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

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

On Thursday, January 12, 2017 20:12:12 Christian Schoenebeck wrote:
> When I find some time, I can add the missing scanner code for sfz files to
> the instruments DB feature. It just needs couple lines of code as far as I
> can see it right now.

Hmm, those original "couple lines" propagated like rabbits, but it is finally 
done. Latest SVN version of LinuxSampler supports scanning .sfz and .sf2 files 
out of the box.

Give it a try!

CU
Christian

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

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

On Thursday, January 12, 2017 13:30:21 Andrew Dabrowski wrote:
> Bingo, sfz files.  They're a problem?  I thought linuxsampler had
> advanced support for that format.

Yeah, it's actually quite simple: sfz files are currently completely ignored 
by the instruments DB. :)

Grigor originally wrote most of the instruments DB and the sfz engine. So I 
don't know why he did not add support for scanning sfz files as well for the 
instruments DB. One reason might be that sfz does not have any way to provide 
meta information (instrument type, genre, author, engineer, copyright, 
keywords, etc.) in contrast to other formats like Giga, DLS, ...

When I find some time, I can add the missing scanner code for sfz files to the 
instruments DB feature. It just needs couple lines of code as far as I can see 
it right now.

CU
Christian

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

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

Bingo, sfz files.  They're a problem?  I thought linuxsampler had 
advanced support for that format.

I hope I won't have to import the entire Virtual-Playing-Orchestra one 
file at a time.



On 01/12/2017 05:47 AM, Christian Schoenebeck wrote:
> 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
>
> ------------------------------------------------------------------------------
> 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] 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