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

Re: [Linuxsampler-devel] "GET" LSCP commands to linuxsampler sometimes don't return data

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

Hi Christian,

Ah ok, that was my issue with the instrument editor not opening after all!

I might be missing something, but once the plugins are closed and that
destructor code is run (i.e a RESET is sent), how can linuxsampler open
them up again?
At that point, sending the LSCP commands to create a new audio interface,
load a gig file and open it for editing  again gives the 'cannot find
instrument editor' message.

Thanks,

Andrew.


On Thu, Dec 30, 2021 at 6:03 PM Christian Schoenebeck <
sch...@li...> wrote:

> On Dienstag, 28. Dezember 2021 11:21:28 CET Andrew C wrote:
> > This is the output when I, shall we say, non-interactively (i.e netcat)
> > send a command to Linuxsampler:
> >
> > Data type is libgig and data version is 4.3.0.svn34
> > Trying to find an available editor.
> > Loading instrument editor plugins...Successfully loaded:
> > /usr/local/lib/linuxsampler/plugins/libgigeditlinuxsamplerplugin.so
> > OK
> > InnerFactories.begin.
> > Returning available editors result.
> > Instrument plugin is
> > Searching for matching editors now...
> > Trying to find an editor that can support: libgig and 4.3.0.svn34
> > Trying to find an available editor.
> > Loading instrument editor plugins...Successfully loaded:
> > /usr/local/lib/linuxsampler/plugins/libgigeditlinuxsamplerplugin.so
> > OK
> > InnerFactories.begin.
> > Returning available editors result.
> > Registered instrument editors again:
> > Searched finished for matching editors...
> > vEditors looks empty. What about available editors string?Trying to find
> an
> > available editor.
> > Loading instrument editor plugins...Successfully loaded:
> > /usr/local/lib/linuxsampler/plugins/libgigeditlinuxsamplerplugin.so
> > OK
> > InnerFactories.begin.
> > Returning available editors result.
> > ERROR: There is not any instrument editor registered to the sampler!
> >
> >
> > It looks like the iterating through the previously registered editors
> gets
> > "forgotten" or otherwise the 'InnerFactories.begin()' loop is empty in
> the
> > 'non-interactive' example..
> > Phew.. That's enough wall of text then!
>
> Are you requesting a sampler reset per LSCP comand via netcat somewhere in
> between? Because a sampler reset request will reset really everything,
> i.e.
> the sampler would also call
>
> src/Sampler.cpp:
>         void Sampler::Reset() {
>                 ...
>                 InstrumentEditorFactory::ClosePlugins();
>                 ...
>         }
>
> And ClosePlugin() closes all open plugin DLLs. Once the instrument editor
> DLL
> is unloaded from memory, the following destructor code is executed
> automatically:
>
> src/plugins/InstrumentEditorFactory.h:
>         ~InnerFactoryRegistrator() {
>                 InnerFactoryTemplate<PluginClass_T> innerFactory;
>                         InstrumentEditor* pEditor = innerFactory.Create();
>                         if (InnerFactories.count(pEditor->Name())) {
>                                 InnerFactory* pZombie =
>                                         InnerFactories[pEditor->Name()];
>                                 InnerFactories.erase(pEditor->Name());
>                                 if (pZombie) delete pZombie;
>                         }
>                         innerFactory.Destroy(pEditor);
>         }
>
> CU
> Christian
>
>
>
>
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] midi message fantasia note off

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

I changed the behaviour for both the SFZ engine and gig engine to distinguish 
by note-off velocity being exactly zero for now:
http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4020

That should fix expected release trigger behaviour for both keyboards with and 
without key release sensors appropriately.

If it turns out that some MIDI keyboards with release sensors do send note-off 
velocity zero (which I doubt), then this behaviour can still be changed to 
some more complicated MIDI-learn mechanism.

BTW the original MIDI v1 specs say keyboards that do not support note-off 
velocity should send 64 as note-off velocity value. Probably one of the very 
few mistakes made in the ancient MIDI specs, at least IMO. I haven't looked 
into latest MIDI v2 specs yet. I noticed though there was some voting process 
on a note-off related change on midi.org, that thread on midi.org is password 
protected though, so no idea what this was exactly about.

CU
Christian

On Montag, 3. Januar 2022 19:29:58 CET Raphaël Mouneyres wrote:
> thanks for the tests, it makes sense from a firmware perspective to set
> 0x01 as a minimum.
> 
> I'll try to have a look at how another keyboard reacts when I have one
> at hand, probably during this week or next one, and I'll report back.
> 
> Raphaël
> 
> Le 03/01/2022 à 02:58, Doug Gray a écrit :
> > I have run a test on the SL-88, the lowest reported release velocity seems
> > to be 0x01.  I have tried to release keys as gently as I can but have not
> > yet seen a release velocity of zero.  It’s easy to hit the 0x01 so I’m
> > quite confident it is the lowest possible value. This was not what I
> > expected but makes good sense.
> > Doug Gray
> > 
> > 
> > Sent from my iPhone
> > 
> >> On 3 Jan 2022, at 4:19 am, Jerash music <rmo...@gm...> wrote:
> >> 
> >> 
> >> 
> >>> Le 2 janv. 2022 à 14:53, Christian Schoenebeck 
<sch...@li...> a écrit :
> >>>> On Sonntag, 2. Januar 2022 14:42:55 CET Jerash music wrote:
> >>>> Having worked with (and repairing) many midi keyboard controllers, I
> >>>> can say that release velocity is not very common. Mainly available on
> >>>> high range keyboard, often with weighted keys, piano style.
> >>>> 
> >>>> Keyboard rubbers with triple sensors offer greater  definition so to
> >>>> have
> >>>> the release velocity, but it can be implemented in the device firmware
> >>>> or
> >>>> not, at manufacturer’s choice. Keyboard rubber with double sensor could
> >>>> also do release velocity, but may miss some when the key is not fully
> >>>> pressed before actual release. Here, again, the sent message depends on
> >>>> firmware implementation.
> >>>> 
> >>>>> I suggest that that should only be the case when note  off velocity is
> >>>>> actually zero.
> >>>> 
> >>>> I do agree with this, it totally makes sense to me.
> >>>> 
> >>>> My 2 cents,
> >>>> Raphaël
> >>> 
> >>> Ok, but the core question still is: can we expect keyboards *with*
> >>> note-off
> >>> velocity sensors to *never* send note-off velocity zero?
> >> 
> >> Mmm, …yes it may be possible.
> >> it may be possible to send a zero release velocity if the firmware
> >> calculates a release velocity and includes a « timeout » for the maximum
> >> release time, and then decides that timed out values are zero. But I
> >> have not expressly tested it, and each manufacturer could have his own
> >> vision.
> >> 
> >> I’ve been explained by Yamaha that the three contact rubbers are
> >> especially useful for retriggering calculation of half pressed keys, but
> >> they did not talk about release velocity calculation. Maybe Doug Gray
> >> could try the following on his SL88 : « Release the key as slow as
> >> possible in about 4 seconds » to try to reach the minimum release
> >> velocity value. As the keyboard rubber has three contacts, it could
> >> potentially send a zero release velocity if you reach a timeout between
> >> two contacts releases. I’m not sure if it is humanly possible to reach
> >> this potential timeout, as the contact points are really really close.
> >> The real duration of this timeout is not documented so needs testing.
> >> 
> >> Raphaël
> >> 
> >> _______________________________________________
> >> Linuxsampler-devel mailing list
> >> Lin...@li...
> >> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> > 
> > _______________________________________________
> > Linuxsampler-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] midi message fantasia note off

[Raphaël M. <rmo...@gm...>]

thanks for the tests, it makes sense from a firmware perspective to set 
0x01 as a minimum.

I'll try to have a look at how another keyboard reacts when I have one 
at hand, probably during this week or next one, and I'll report back.

Raphaël

Le 03/01/2022 à 02:58, Doug Gray a écrit :
> I have run a test on the SL-88, the lowest reported release velocity seems to be 0x01.  I have tried to release keys as gently as I can but have not yet seen a release velocity of zero.  It’s easy to hit the 0x01 so I’m quite confident it is the lowest possible value.
> This was not what I expected but makes good sense.
> Doug Gray
>
>
> Sent from my iPhone
>
>> On 3 Jan 2022, at 4:19 am, Jerash music <rmo...@gm...> wrote:
>>
>> 
>>
>>> Le 2 janv. 2022 à 14:53, Christian Schoenebeck <sch...@li...> a écrit :
>>>
>>>> On Sonntag, 2. Januar 2022 14:42:55 CET Jerash music wrote:
>>>> Having worked with (and repairing) many midi keyboard controllers, I can say
>>>> that release velocity is not very common. Mainly available on high range
>>>> keyboard, often with weighted keys, piano style.
>>>>
>>>> Keyboard rubbers with triple sensors offer greater  definition so to have
>>>> the release velocity, but it can be implemented in the device firmware or
>>>> not, at manufacturer’s choice. Keyboard rubber with double sensor could
>>>> also do release velocity, but may miss some when the key is not fully
>>>> pressed before actual release. Here, again, the sent message depends on
>>>> firmware implementation.
>>>>> I suggest that that should only be the case when note  off velocity is
>>>>> actually zero.
>>>> I do agree with this, it totally makes sense to me.
>>>>
>>>> My 2 cents,
>>>> Raphaël
>>> Ok, but the core question still is: can we expect keyboards *with* note-off
>>> velocity sensors to *never* send note-off velocity zero?
>> Mmm, …yes it may be possible.
>> it may be possible to send a zero release velocity if the firmware calculates a release velocity and includes a « timeout » for the maximum release time, and then decides that timed out values are zero.
>> But I have not expressly tested it, and each manufacturer could have his own vision.
>>
>> I’ve been explained by Yamaha that the three contact rubbers are especially useful for retriggering calculation of half pressed keys, but they did not talk about release velocity calculation.
>> Maybe Doug Gray could try the following on his SL88 : « Release the key as slow as possible in about 4 seconds » to try to reach the minimum release velocity value.
>> As the keyboard rubber has three contacts, it could potentially send a zero release velocity if you reach a timeout between two contacts releases. I’m not sure if it is humanly possible to reach this potential timeout, as the contact points are really really close. The real duration of this timeout is not documented so needs testing.
>>
>> Raphaël
>>
>> _______________________________________________
>> Linuxsampler-devel mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

-- 
Raphaël

[Linuxsampler-devel] SFZ: auto reload .sfz file

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

For the SFZ users out there; experimental support for automatic reloading of 
modified .sfz files:

http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4019

It works as simple as you might imagine:

1. Load an .sfz file as usual into LinuxSampler.

2. Open the .sfz file with an editor of your choice (a text editor, something 
   more fancy specifically for SFZ, doesn't matter).

3. Change something in the sfz file.

4. Hit "Save" in the editor.

The sampler will automatically reload the SFZ instrument at this point.

CU
Christian

Re: [Linuxsampler-devel] midi message fantasia note off

[Doug G. <dou...@gm...>]

I have run a test on the SL-88, the lowest reported release velocity seems to be 0x01.  I have tried to release keys as gently as I can but have not yet seen a release velocity of zero.  It’s easy to hit the 0x01 so I’m quite confident it is the lowest possible value.
This was not what I expected but makes good sense.
Doug Gray


Sent from my iPhone

> On 3 Jan 2022, at 4:19 am, Jerash music <rmo...@gm...> wrote:
> 
> 
> 
>> Le 2 janv. 2022 à 14:53, Christian Schoenebeck <sch...@li...> a écrit :
>> 
>>> On Sonntag, 2. Januar 2022 14:42:55 CET Jerash music wrote:
>>> Having worked with (and repairing) many midi keyboard controllers, I can say
>>> that release velocity is not very common. Mainly available on high range
>>> keyboard, often with weighted keys, piano style.
>>> 
>>> Keyboard rubbers with triple sensors offer greater  definition so to have
>>> the release velocity, but it can be implemented in the device firmware or
>>> not, at manufacturer’s choice. Keyboard rubber with double sensor could
>>> also do release velocity, but may miss some when the key is not fully
>>> pressed before actual release. Here, again, the sent message depends on
>>> firmware implementation.
>>>> I suggest that that should only be the case when note  off velocity is
>>>> actually zero.
>>> I do agree with this, it totally makes sense to me.
>>> 
>>> My 2 cents,
>>> Raphaël
>> 
>> Ok, but the core question still is: can we expect keyboards *with* note-off 
>> velocity sensors to *never* send note-off velocity zero?
> 
> Mmm, …yes it may be possible.
> it may be possible to send a zero release velocity if the firmware calculates a release velocity and includes a « timeout » for the maximum release time, and then decides that timed out values are zero.
> But I have not expressly tested it, and each manufacturer could have his own vision.
> 
> I’ve been explained by Yamaha that the three contact rubbers are especially useful for retriggering calculation of half pressed keys, but they did not talk about release velocity calculation.
> Maybe Doug Gray could try the following on his SL88 : « Release the key as slow as possible in about 4 seconds » to try to reach the minimum release velocity value.
> As the keyboard rubber has three contacts, it could potentially send a zero release velocity if you reach a timeout between two contacts releases. I’m not sure if it is humanly possible to reach this potential timeout, as the contact points are really really close. The real duration of this timeout is not documented so needs testing. 
> 
> Raphaël
> 
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] midi message fantasia note off

[Jerash m. <rmo...@gm...>]

> Le 2 janv. 2022 à 14:53, Christian Schoenebeck <sch...@li...> a écrit :
> 
> On Sonntag, 2. Januar 2022 14:42:55 CET Jerash music wrote:
>> Having worked with (and repairing) many midi keyboard controllers, I can say
>> that release velocity is not very common. Mainly available on high range
>> keyboard, often with weighted keys, piano style.
>> 
>> Keyboard rubbers with triple sensors offer greater  definition so to have
>> the release velocity, but it can be implemented in the device firmware or
>> not, at manufacturer’s choice. Keyboard rubber with double sensor could
>> also do release velocity, but may miss some when the key is not fully
>> pressed before actual release. Here, again, the sent message depends on
>> firmware implementation.
>>> I suggest that that should only be the case when note  off velocity is
>>> actually zero.
>> I do agree with this, it totally makes sense to me.
>> 
>> My 2 cents,
>> Raphaël
> 
> Ok, but the core question still is: can we expect keyboards *with* note-off 
> velocity sensors to *never* send note-off velocity zero?

Mmm, …yes it may be possible.
it may be possible to send a zero release velocity if the firmware calculates a release velocity and includes a « timeout » for the maximum release time, and then decides that timed out values are zero.
But I have not expressly tested it, and each manufacturer could have his own vision.

I’ve been explained by Yamaha that the three contact rubbers are especially useful for retriggering calculation of half pressed keys, but they did not talk about release velocity calculation.
Maybe Doug Gray could try the following on his SL88 : « Release the key as slow as possible in about 4 seconds » to try to reach the minimum release velocity value.
As the keyboard rubber has three contacts, it could potentially send a zero release velocity if you reach a timeout between two contacts releases. I’m not sure if it is humanly possible to reach this potential timeout, as the contact points are really really close. The real duration of this timeout is not documented so needs testing. 

Raphaël

Re: [Linuxsampler-devel] midi message fantasia note off

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

On Sonntag, 2. Januar 2022 14:42:55 CET Jerash music wrote:
> Having worked with (and repairing) many midi keyboard controllers, I can say
> that release velocity is not very common. Mainly available on high range
> keyboard, often with weighted keys, piano style.
> 
> Keyboard rubbers with triple sensors offer greater  definition so to have
> the release velocity, but it can be implemented in the device firmware or
> not, at manufacturer’s choice. Keyboard rubber with double sensor could
> also do release velocity, but may miss some when the key is not fully
> pressed before actual release. Here, again, the sent message depends on
> firmware implementation.
> >I suggest that that should only be the case when note  off velocity is
> >actually zero.
> I do agree with this, it totally makes sense to me.
> 
> My 2 cents,
> Raphaël

Ok, but the core question still is: can we expect keyboards *with* note-off 
velocity sensors to *never* send note-off velocity zero?

CU
Christian

Re: [Linuxsampler-devel] midi message fantasia note off

[Jerash m. <rmo...@gm...>]

Having worked with (and repairing) many midi keyboard controllers, I can say that release velocity is not very common. Mainly available on high range keyboard, often with weighted keys, piano style.

Keyboard rubbers with triple sensors offer greater  definition so to have the release velocity, but it can be implemented in the device firmware or not, at manufacturer’s choice.
Keyboard rubber with double sensor could also do release velocity, but may miss some when the key is not fully pressed before actual release. Here, again, the sent message depends on firmware implementation.

>I suggest that that should only be the case when note  off velocity is actually zero.
I do agree with this, it totally makes sense to me.

My 2 cents,
Raphaël


> Le 2 janv. 2022 à 13:00, Doug Gray <dou...@gm...> a écrit :
> 
> For the record my Studiologic SL88 keyboard controller does send note off with a measured velocity value.  I have verified this myself since the sfz file I am using has key off sounds.  This velocity is measured at key release.
> I see the documentation states that the note on velocity is reused for note off but I suggest that that should only be the case when note  off velocity is actually zero.
> I don’t think it is likely at least for triple sensor  that ‘most midi controllers’ send zero velocity note-off. It would be good to verify this.
> 
> Doug Gray
> 
>> On 2 Jan 2022, at 6:28 pm, Jan Flikweert <fl...@ze...> wrote:
>> 
>> JanFl. Wrote:" Thank you very much for this solution and the things I
>> learned. It works."
>> 
>> The solution does not work for gig files.
>> 
>> The funny thing is that gig files can also play a release sample after aloop
>> from a sample. The dimension is called releasetrigger. One dimension has a
>> normal loop and the release sample has no loop.
>> 
>> Kind regards,
>> 
>> 
>> Jan Fl.
>> 
>> 
>> 
>> _______________________________________________
>> Linuxsampler-devel mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 
> 
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] midi message fantasia note off

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

Mja, that behaviour could likewise easily be adjusted for the gig engine as I 
did for the sfz engine this week. From the sfz docs I see, people seem to 
expect that the note-on velocity is always used instead of the note-off 
velocity? Hence I just changed that exactly this way for the sfz engine this 
week.

For the gig engine: I agree with Dough here, if you have a keyboard that 
supports note-off velocity, you want to use it. But the fact that most MIDI 
keyboards just send note-off velocity zero still applies. So this must 
coexist.

Doug, does your keyboard *ever* send a note-off with velocity zero? If it does 
not, then simply checking for velocity zero might indeed be the way to go. 
Maybe even for the sfy engine, too?

CU
Christian

On Sonntag, 2. Januar 2022 13:00:28 CET Doug Gray wrote:
> For the record my Studiologic SL88 keyboard controller does send note off
> with a measured velocity value.  I have verified this myself since the sfz
> file I am using has key off sounds.  This velocity is measured at key
> release. I see the documentation states that the note on velocity is reused
> for note off but I suggest that that should only be the case when note  off
> velocity is actually zero. I don’t think it is likely at least for triple
> sensor  that ‘most midi controllers’ send zero velocity note-off. It would
> be good to verify this.
> 
> Doug Gray
> 
> > On 2 Jan 2022, at 6:28 pm, Jan Flikweert <fl...@ze...> wrote:
> > 
> > JanFl. Wrote:" Thank you very much for this solution and the things I
> > learned. It works."
> > 
> > The solution does not work for gig files.
> > 
> > The funny thing is that gig files can also play a release sample after
> > aloop from a sample. The dimension is called releasetrigger. One
> > dimension has a normal loop and the release sample has no loop.
> > 
> > Kind regards,
> > 
> > 
> > Jan Fl.
> > 
> > 
> > 
> > _______________________________________________
> > Linuxsampler-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] midi message fantasia note off

[Doug G. <dou...@gm...>]

For the record my Studiologic SL88 keyboard controller does send note off with a measured velocity value.  I have verified this myself since the sfz file I am using has key off sounds.  This velocity is measured at key release.
I see the documentation states that the note on velocity is reused for note off but I suggest that that should only be the case when note  off velocity is actually zero.
I don’t think it is likely at least for triple sensor  that ‘most midi controllers’ send zero velocity note-off. It would be good to verify this.

Doug Gray

> On 2 Jan 2022, at 6:28 pm, Jan Flikweert <fl...@ze...> wrote:
> 
> JanFl. Wrote:" Thank you very much for this solution and the things I
> learned. It works."
> 
> The solution does not work for gig files.
> 
> The funny thing is that gig files can also play a release sample after aloop
> from a sample. The dimension is called releasetrigger. One dimension has a
> normal loop and the release sample has no loop.
> 
> Kind regards,
> 
> 
> Jan Fl.
> 
> 
> 
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] midi message fantasia note off

[Jan F. <fl...@ze...>]

JanFl. Wrote:" Thank you very much for this solution and the things I
learned. It works."

The solution does not work for gig files.

The funny thing is that gig files can also play a release sample after aloop
from a sample. The dimension is called releasetrigger. One dimension has a
normal loop and the release sample has no loop.

Kind regards,


Jan Fl.

Re: [Linuxsampler-devel] midi message fantasia note off

[Jan F. <fl...@ze...>]

CU wrote:
Fixed. Works now as expected:
http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4013

The order of the regions in the sfz file does not matter for LS BTW. I just 
saw before that it does for other players.

CU
Christian
--------------
Thank you very much for this solution and the things I learned. It works.

Kind regards,

Jan Flikweert

Re: [Linuxsampler-devel] midi message fantasia note off

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

On Donnerstag, 30. Dezember 2021 22:04:37 CET you wrote:
> Hi,
> 
> I tried flipping the order of those regions. That did not work.
> 
> Kind regards,

Fixed. Works now as expected:
http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4013

The order of the regions in the sfz file does not matter for LS BTW. I just 
saw before that it does for other players.

CU
Christian

Re: [Linuxsampler-devel] midi message fantasia note off

[Jan F. <fl...@ze...>]

Hi,

I tried flipping the order of those regions. That did not work.

Kind regards,

Jan Flikweert
--------------------
CU Wrote:
Have you tried flipping the order of those two regions, i.e. release trigger

region after attack region?

CU
Christian

Re: [Linuxsampler-devel] midi message fantasia note off

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

On Mittwoch, 29. Dezember 2021 21:59:13 CET Jan Flikweert wrote:
> Christian,
> 
> Thanks for your explanation. I conclude that it is only needed to set notes
> on/off. Stops do not need on/off. If you do not need a instrument, do not
> sent notes to it.
> 
> The next file sample-release-060-C.wav contains a sinus tone 220 hz. The
> file sample-Default-060-C.wav a normal principal.
> 
> Using Fantasia / Linuxsampler works well.
> jOrgan / Linuxsampler does not work for the release part (only note on/off!)
> jOrgan / sForzando works correct
> 
> sForzando is not advisable because it cannot handle large organs.
> Linuxsampler provides for me a beautiful organ with 150 instruments/stops.
> Of course they are not needed all at one time, but LS can handle them, load
> them.
> 
> Kind regards,
> 
> Jan Flikweert
> 
> -------------------------------------
> Test.sfz
> <group>
> lokey=36
> hikey=96
> 
> <region>
> sample=release-060-C.wav
> trigger=release
> loop_mode=one_shot
> 
> <region>
> sample=Default-060-C.wav
> loop_mode=loop_sustain
> loop_start=97041
> loop_end=163161
> -------------------------------------------

Have you tried flipping the order of those two regions, i.e. release trigger 
region after attack region?

CU
Christian

Re: [Linuxsampler-devel] "GET" LSCP commands to linuxsampler sometimes don't return data

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

On Dienstag, 28. Dezember 2021 11:21:28 CET Andrew C wrote:
> This is the output when I, shall we say, non-interactively (i.e netcat)
> send a command to Linuxsampler:
> 
> Data type is libgig and data version is 4.3.0.svn34
> Trying to find an available editor.
> Loading instrument editor plugins...Successfully loaded:
> /usr/local/lib/linuxsampler/plugins/libgigeditlinuxsamplerplugin.so
> OK
> InnerFactories.begin.
> Returning available editors result.
> Instrument plugin is
> Searching for matching editors now...
> Trying to find an editor that can support: libgig and 4.3.0.svn34
> Trying to find an available editor.
> Loading instrument editor plugins...Successfully loaded:
> /usr/local/lib/linuxsampler/plugins/libgigeditlinuxsamplerplugin.so
> OK
> InnerFactories.begin.
> Returning available editors result.
> Registered instrument editors again:
> Searched finished for matching editors...
> vEditors looks empty. What about available editors string?Trying to find an
> available editor.
> Loading instrument editor plugins...Successfully loaded:
> /usr/local/lib/linuxsampler/plugins/libgigeditlinuxsamplerplugin.so
> OK
> InnerFactories.begin.
> Returning available editors result.
> ERROR: There is not any instrument editor registered to the sampler!
> 
> 
> It looks like the iterating through the previously registered editors gets
> "forgotten" or otherwise the 'InnerFactories.begin()' loop is empty in the
> 'non-interactive' example..
> Phew.. That's enough wall of text then!

Are you requesting a sampler reset per LSCP comand via netcat somewhere in 
between? Because a sampler reset request will reset really everything, i.e. 
the sampler would also call

src/Sampler.cpp:
	void Sampler::Reset() {
		...
		InstrumentEditorFactory::ClosePlugins();
		...
	}

And ClosePlugin() closes all open plugin DLLs. Once the instrument editor DLL 
is unloaded from memory, the following destructor code is executed 
automatically:

src/plugins/InstrumentEditorFactory.h:
	~InnerFactoryRegistrator() {
		InnerFactoryTemplate<PluginClass_T> innerFactory;
			InstrumentEditor* pEditor = innerFactory.Create();
			if (InnerFactories.count(pEditor->Name())) {
				InnerFactory* pZombie =
					InnerFactories[pEditor->Name()];
				InnerFactories.erase(pEditor->Name());
				if (pZombie) delete pZombie;
			}
			innerFactory.Destroy(pEditor);
	}

CU
Christian

Re: [Linuxsampler-devel] midi message fantasia note off

[Jan F. <fl...@ze...>]

Christian,

Thanks for your explanation. I conclude that it is only needed to set notes
on/off. Stops do not need on/off. If you do not need a instrument, do not
sent notes to it.

The next file sample-release-060-C.wav contains a sinus tone 220 hz. The
file sample-Default-060-C.wav a normal principal.

Using Fantasia / Linuxsampler works well.
jOrgan / Linuxsampler does not work for the release part (only note on/off!)
jOrgan / sForzando works correct

sForzando is not advisable because it cannot handle large organs.
Linuxsampler provides for me a beautiful organ with 150 instruments/stops.
Of course they are not needed all at one time, but LS can handle them, load
them.

Kind regards,

Jan Flikweert

-------------------------------------
Test.sfz
<group>
lokey=36
hikey=96

<region>
sample=release-060-C.wav
trigger=release
loop_mode=one_shot

<region>
sample=Default-060-C.wav
loop_mode=loop_sustain
loop_start=97041
loop_end=163161
-------------------------------------------

Kind regards,


Jan Flikweert

-----Original Message-----
From: Christian Schoenebeck [mailto:sch...@li...] 
Sent: woensdag 29 december 2021 18:44
To: lin...@li...
Subject: Re: [Linuxsampler-devel] midi message fantasia note off

On Dienstag, 28. Dezember 2021 08:01:06 CET Jan Flikweert wrote:
> Christian,
> 
> Probably more clear I translated the midi messages I send from jOrgan to
> LSCP:
> 
> Note on:
> 
> "SEND CHANNEL MIDI_DATA NOTE_ON 0 60 127"
> 
> Note off:
> 
> "SEND CHANNEL MIDI_DATA NOTE_OFF 0 60 0"

That's a note-off, hence release triggered samples *are* played at this
point.

> Instrument/Stop on:
> 
> "SEND CHANNEL MIDI_DATA CC 0 7 127"

That means "set channel volume to maximum". No release sample played.

> Instrument/Stop off:
> 
> "SEND CHANNEL MIDI_DATA CC 0 1 0"

That means "set Modulation Wheel to minimum". No release sample played.

> "SEND CHANNEL MIDI_DATA CC 0 7 0"

That means "set channel volume to minimum". No release sample played.

Release triggered samples are only played if *notes* are released, which is 
e.g. on note-off, sustain release CC, exclusive groups conflicts. That's the

expected behaviour, not a bug, and is consistent among all players, not just

LS.

If you turn the volume down to zero, the notes are still there. They
continue 
to play and still advance their playback positions accordingly. You just
can't 
hear them, but that's it.

If you want to play samples on CCs, you have to use CC triggered samples 
instead. That's supported on patch level both by SFZ and gig format. 
Additionally you can also write an NKSP script if you really want some fancy

behaviour that goes beyond of what the built-in patch CC triggered
mechanisms 
can do.

CU
Christian




_______________________________________________
Linuxsampler-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] midi message fantasia note off

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

On Dienstag, 28. Dezember 2021 08:01:06 CET Jan Flikweert wrote:
> Christian,
> 
> Probably more clear I translated the midi messages I send from jOrgan to
> LSCP:
> 
> Note on:
> 
> "SEND CHANNEL MIDI_DATA NOTE_ON 0 60 127"
> 
> Note off:
> 
> "SEND CHANNEL MIDI_DATA NOTE_OFF 0 60 0"

That's a note-off, hence release triggered samples *are* played at this point.

> Instrument/Stop on:
> 
> "SEND CHANNEL MIDI_DATA CC 0 7 127"

That means "set channel volume to maximum". No release sample played.

> Instrument/Stop off:
> 
> "SEND CHANNEL MIDI_DATA CC 0 1 0"

That means "set Modulation Wheel to minimum". No release sample played.

> "SEND CHANNEL MIDI_DATA CC 0 7 0"

That means "set channel volume to minimum". No release sample played.

Release triggered samples are only played if *notes* are released, which is 
e.g. on note-off, sustain release CC, exclusive groups conflicts. That's the 
expected behaviour, not a bug, and is consistent among all players, not just 
LS.

If you turn the volume down to zero, the notes are still there. They continue 
to play and still advance their playback positions accordingly. You just can't 
hear them, but that's it.

If you want to play samples on CCs, you have to use CC triggered samples 
instead. That's supported on patch level both by SFZ and gig format. 
Additionally you can also write an NKSP script if you really want some fancy 
behaviour that goes beyond of what the built-in patch CC triggered mechanisms 
can do.

CU
Christian

Re: [Linuxsampler-devel] linuxsampler 4010 build failed on loongarch64

[Quick K. <hep...@ya...>]

--- a/src/common/RTMath.cpp	2021-12-25 18:37:48.733719298 +0800
+++ b/src/common/RTMath.cpp	2021-12-25 21:54:21.914927577 +0800
@@ -73,6 +73,10 @@
     return t;
     #elif defined(__APPLE__)
     return (time_stamp_t) mach_absolute_time();
+    #elif defined(__loongarch64)
+    uint64_t t,tmpAAA;
+    __asm__ __volatile__ ("rdtime.d %0, %1":"=r"(t),"=r"(tmpAAA));
+    return time_stamp_t(t>>8);
     #else // we don't want to use a slow generic solution
     #  error "Sorry, LinuxSampler lacks time stamp code for your system."
     #  error "Please report this error and the CPU you are using to the LinuxSampler developers mailing list!"
--- a/linuxsampler/src/common/atomic.h	2021-12-29 04:22:34.535260312 +0800
+++ b/linuxsampler/src/common/atomic.h	2021-12-29 03:43:41.403752006 +0800
@@ -1186,6 +1186,63 @@
 #endif /* __ARCH_M68K_ATOMIC __ */
 
 #else
+#ifdef __loongarch64
+
+typedef struct { volatile int counter; } atomic_t;
+#define ATOMIC_INIT(i)	{ (i) }
+
+#define atomic_read(v)	((v)->counter)
+#define atomic_set(v,i)	(((v)->counter) = (i))
+
+static __inline__ void atomic_add(int i, volatile atomic_t *v)
+{
+ __asm__ __volatile__(
+ "amadd_db.w $zero, %1, %0"
+ :"+ZB" (v->counter)
+ :"r"(i)
+ :"memory");
+}
+
+static __inline__ void atomic_sub(int i, volatile atomic_t *v)
+{
+ __asm__ __volatile__(
+ "amadd_db.w $zero, %1, %0"
+ :"+ZB" (v->counter)
+ :"r"(-i)
+ :"memory");
+}
+
+#define atomic_inc(v) (atomic_add(1, (v)))
+#define atomic_dec(v) (atomic_sub(1, (v)))
+
+static __inline__ int haha(int i, volatile atomic_t *v)
+{
+ int result;
+ __asm__ __volatile__(
+ "amadd_db.w %1, %2, %0"
+ :"+ZB"(v->counter),"=&r"(result)
+ :"r"(-i)
+ :"memory");
+ return (result-i)==0;
+}
+#define atomic_dec_and_test(v) haha(1,(v))
+
+static inline int atomic_add_negative(int i, volatile atomic_t *v)
+{
+ int result;
+ __asm__ __volatile__(
+ "amadd_db.w %1, %2, %0"
+ :"+ZB"(v->counter),"=&r"(result)
+ :"r"(i)
+ :"memory");
+ return (result+i)<0;
+}
+
+#define mb() __asm__ __volatile__("dbar 0" : : : "memory")
+#define rmb() mb()
+#define wmb() mb()
+
+#else
 
 #warning libs/pbd has no implementation of strictly atomic operations for your hardware.
 
@@ -1231,6 +1288,7 @@
 }
 
 #  endif /* __NO_STRICT_ATOMIC */
+#  endif /* loongarch64 */
 #  endif /* m68k */
 #  endif /* mips */
 #  endif /* s390 */
@@ -1288,3 +1346,4 @@
 
 #endif /* linux */
 #endif /* __linuxsampler_atomic_h__ */
+

Re: [Linuxsampler-devel] "GET" LSCP commands to linuxsampler sometimes don't return data

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

Hi Christian,

Thanks a bunch for setting me on the right track with this. I can now see
that the engine is indeed successfully loading the instrument plugin, both
at startup and when an instrument editor is requested:
// load the DLL (the plugins should register themselfes automatically)
           void* pDLL = dlopen(sPath.c_str(), RTLD_NOW);
           if (pDLL) {
               LoadedDLLs.push_back(pDLL);
               fprintf (stderr, "Successfully loaded: %s\n", sPath.c_str()
);
            }
           else {
               std::cerr << "Failed to load instrument editor plugin: '"
                         << sPath << "', cause: " << dlerror() <<
std::endl;
           }
       }
       closedir(hDir);

This is the fprintf'ed bit of code + a force reload of the plugins for
testing I'm using in AvailableEditors to track what's happening:

std::vector<String> InstrumentEditorFactory::AvailableEditors() {
       // make sure plugins were loaded already
       bPluginsLoaded = false; //force reload them
       fprintf (stderr, "Trying to find an available editor.\n");
       LoadPlugins();
       // render result
       std::vector<String> result;
       std::map<String, InnerFactory*>::iterator iter =
InnerFactories.begin();
       fprintf (stderr, "iterate InnerFactories.begin.\n");
       for (; iter != InnerFactories.end(); iter++) {
           fprintf(stderr, "Iterating through editors..\n ");
           result.push_back(iter->first);
       }
       fprintf (stderr, "Returning available editors result.\n");

       return result;
   }


Registered sampler engines: 'GIG','SF2','SFZ'
Registered MIDI input drivers: ALSA,JACK
Registered audio output drivers: ALSA,JACK
Trying to find an available editor.
Loading instrument editor plugins...Successfully loaded:
/usr/local/lib/linuxsampler/plugins/libgigeditlinuxsamplerplugin.so
OK
Iterating through editors..
Returning available editors result.
Registered instrument editors: 'gigedit'


This is the output when the instrument editor is successfully loaded
("interactively" using "EDIT CHANNEL INSTRUMENT 0" the LSCP shell):
Data type is libgig and data version is 4.3.0.svn34
Trying to find an available editor.
Loading instrument editor plugins...Successfully loaded:
/usr/local/lib/linuxsampler/plugins/libgigeditlinuxsamplerplugin.so
OK
InnerFactories.begin.
Iterating through editors..
Returning available editors result.
Instrument plugin is 'gigedit'
Searching for matching editors now...
Trying to find an editor that can support: libgig and 4.3.0.svn34
Found a matching editor. :)
Trying to find an available editor.
Loading instrument editor plugins...Successfully loaded:
/usr/local/lib/linuxsampler/plugins/libgigeditlinuxsamplerplugin.so
OK
InnerFactories.begin.
Iterating through editors..
Returning available editors result.
Registered instrument editors again: 'gigedit'
Searched finished for matching editors...
Found matching editor 'gigedit' for instrument
('/home/andrew/Desktop/Samples/1 Woodwinds/Dan Dean Solo Woodwinds/Dan Dean
Cl
arinet 5.1.gig', 0) having data structure ('libgig','4.3.0.svn34')
InstrumentEditor::Launch(instr=0x7f41b042b9d0,type=libgig,version=4.3.0.svn34)

This is the output when I, shall we say, non-interactively (i.e netcat)
send a command to Linuxsampler:

Data type is libgig and data version is 4.3.0.svn34
Trying to find an available editor.
Loading instrument editor plugins...Successfully loaded:
/usr/local/lib/linuxsampler/plugins/libgigeditlinuxsamplerplugin.so
OK
InnerFactories.begin.
Returning available editors result.
Instrument plugin is
Searching for matching editors now...
Trying to find an editor that can support: libgig and 4.3.0.svn34
Trying to find an available editor.
Loading instrument editor plugins...Successfully loaded:
/usr/local/lib/linuxsampler/plugins/libgigeditlinuxsamplerplugin.so
OK
InnerFactories.begin.
Returning available editors result.
Registered instrument editors again:
Searched finished for matching editors...
vEditors looks empty. What about available editors string?Trying to find an
available editor.
Loading instrument editor plugins...Successfully loaded:
/usr/local/lib/linuxsampler/plugins/libgigeditlinuxsamplerplugin.so
OK
InnerFactories.begin.
Returning available editors result.
ERROR: There is not any instrument editor registered to the sampler!


It looks like the iterating through the previously registered editors gets
"forgotten" or otherwise the 'InnerFactories.begin()' loop is empty in the
'non-interactive' example..
Phew.. That's enough wall of text then!

Cheers,

Andrew.




On Mon, Dec 27, 2021 at 2:41 PM Christian Schoenebeck <
sch...@li...> wrote:

> On Sonntag, 26. Dezember 2021 21:57:12 CET Andrew C wrote:
> > *Diff patch for debugging/illustration purposes:*
> >
> > Index: LS-DEBUG/src/engines/gig/InstrumentResourceManager.cpp
> > ===================================================================
> > --- LS-DEBUG/src/engines/gig/InstrumentResourceManager.cpp      (revision
> > 4010)
> > +++ LS-DEBUG/src/engines/gig/InstrumentResourceManager.cpp      (working
> > copy)
> > @@ -216,6 +216,8 @@
> >     InstrumentEditor*
> >
> InstrumentResourceManager::LaunchInstrumentEditor(LinuxSampler::EngineChanne
> > l* pEngineChannel, instrument_id_t ID,
> > void* pUserData) throw (InstrumentManagerException) {
> >         const String sDataType    = GetInstrumentDataStructureName(ID);
> >         const String sDataVersion =
> GetInstrumentDataStructureVersion(ID);
> > +       fprintf (stderr, "Data type is %s and data version is %s\n",
> > sDataType.c_str(), sDataVersion.c_str());
> > +       fprintf (stderr, "Instrument plugin is %s\n",
> > InstrumentEditorFactory::AvailableEditorsAsString().c_str());
>
> The output of this was an empty string there, which means the sampler did
> not
> load *any* plugin DLL at all.
>
> >         // find instrument editors capable to handle given instrument
> >         std::vector<String> vEditors =
> >             InstrumentEditorFactory::MatchingEditors(sDataType,
> > sDataVersion);
> > @@ -224,10 +226,16 @@
> >                 fprintf(stderr,
> >                     "ERROR: There is not any instrument editor registered
> > to the sampler!\n"
> >                     "[Cause: Make sure an instrument editor is installed
> to
> > the sampler's plugin dir (%s)]\n",
> > -
> InstrumentEditorFactory::PluginDirsAsString().c_str()
> > -                );
> > +
> >
> InstrumentEditorFactory::PluginDirsAsString().c_str());
> > +               if (InstrumentEditorFactory::FoundPlugins) {
> > +                 fprintf (stderr,
> > +                   "We found and registered plugins in %s at startup,
> but
> > currently available plugins are:%s \n",
> > +
> InstrumentEditorFactory::PluginDirsAsString().c_str(),
> > +
> >
> > InstrumentEditorFactory::AvailableEditorsAsString().c_str()
> >
> > +                  );
> > +                };
> >                 throw InstrumentManagerException(
> > -                    "There is not any instrument editor installed and
> > registered to the sampler"
> > +                    "netcat seems to cause issues."
> >                 );
>
> Has nothing to do with netcat.
>
> >             }
> >             fprintf(stderr,
> > Index: LS-DEBUG/src/plugins/InstrumentEditorFactory.cpp
> > ===================================================================
> > --- LS-DEBUG/src/plugins/InstrumentEditorFactory.cpp    (revision 4010)
> > +++ LS-DEBUG/src/plugins/InstrumentEditorFactory.cpp    (working copy)
> > @@ -44,6 +44,7 @@
> >     std::map<String, InstrumentEditorFactory::InnerFactory*>
> > InstrumentEditorFactory::InnerFactories;
> >
> >     bool InstrumentEditorFactory::bPluginsLoaded = false;
> > +    bool InstrumentEditorFactory::FoundPlugins = false;
> >
> >     std::list<void*> InstrumentEditorFactory::LoadedDLLs;
> >
> > @@ -287,6 +288,7 @@
> >         }
> >         closedir(hDir);
> >         #endif
> > +       InstrumentEditorFactory::FoundPlugins = true;
> >         return true;
> >     }
>
> Wrong assumption. At this point it just *tried* to load plugins. It does
> not
> mean it was able to actually load any plugin successfully.
>
> You should rather debug what happens in the loop above.
>
>   for (dirent* pEntry = readdir(hDir); pEntry; pEntry = readdir(hDir)) {
>     ...
>   }
>
> That loops iterares over all files found in the plugin dir and then tries
> to
> load every file that is actually a DLL file (i.e. filename ending with
> ".so").
>
> > Index: LS-DEBUG/src/plugins/InstrumentEditorFactory.h
> > ===================================================================
> > --- LS-DEBUG/src/plugins/InstrumentEditorFactory.h      (revision 4010)
> > +++ LS-DEBUG/src/plugins/InstrumentEditorFactory.h      (working copy)
> > @@ -98,6 +98,7 @@
> >         static String              PluginDirsAsString();
> >         static std::vector<String> AvailableEditors();
> >         static String              AvailableEditorsAsString();
> > +       static bool                FoundPlugins;
> >         static std::vector<String> MatchingEditors(String sTypeName,
> String
> > sTypeVersion);
> >         static void                LoadPlugins();
> >         static void                ClosePlugins();
>
>
>
>
>
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] midi message fantasia note off

[Jan F. <fl...@ze...>]

Christian,

 

Probably more clear I translated the midi messages I send from jOrgan to
LSCP:

 

Note on:

"SEND CHANNEL MIDI_DATA NOTE_ON 0 60 127"

Note off:

"SEND CHANNEL MIDI_DATA NOTE_OFF 0 60 0"

 

Instrument/Stop on:

"SEND CHANNEL MIDI_DATA CC 0 7 127"

 

Instrument/Stop off:

"SEND CHANNEL MIDI_DATA CC 0 1 0"

"SEND CHANNEL MIDI_DATA CC 0 7 0"

 

Kind regards,

 

Jan Flikweert

 

-----Original Message-----
From: Christian Schoenebeck [mailto:sch...@li...] 
Sent: maandag 27 december 2021 16:29
To: lin...@li...
Subject: Re: [Linuxsampler-devel] midi message fantasia note off

 

On Sonntag, 26. Dezember 2021 22:13:05 CET Jan Flikweert wrote:

> Hi,

> 

> I will explain my problem.

> 

> I am working with release samples/sfz.  This works good using fantasia.
Not

> good using jOrgan. jOrgan/Linuxsampler works very good, but without

> release.

 

JSampler and QSampler both control the sampler purely via network protocol

(called "LSCP"), in this case it is this LSCP command:

 

SEND CHANNEL MIDI_DATA <midi-msg> <sampler-chan> <arg1> <arg2>

 

http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html#rfc.section
.6.4.39

 

> I suppose it has to do with the note_off/note_on messages in

> jOrgan. Note on in jorgan is only set 144,set 36, set velocity. Note off
is

> set 128,set 36,.. and set 176,set 1, set 0 which is cc 1.

 

MIDI note-off is [1]:

1000nnnn 0kkkkkkk 0vvvvvvv

 

MIDI note-on is:

1001nnnn 0kkkkkkk 0vvvvvvv

 

MIDI control change is:

1011nnnn 0ccccccc 0vvvvvvv

 

Where

  nnnn is the MIDI channel number (0..15)

  kkkkkkk is the key/note number (0..127)

  ccccccc is the controller number (0..127)

  vvvvvvv is velocity (note-on / note-off) or

          the new controller value (0..127) (control change)

 

Note:

  - Note-On with velocity 0 means "note-off".

  - MIDI allows to omit the status byte on subsequent messages, which is

    called "running status". That's basically just a simple way of data

    compression [2].

 

[1]
https://www.midi.org/specifications-old/item/table-1-summary-of-midi-message

[2] http://midi.teragonaudio.com/tech/midispec/run.htm

  

CU

Christian

 

 

 

 

_______________________________________________

Linuxsampler-devel mailing list

Lin...@li...

https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] midi message fantasia note off

[Jan F. <fl...@ze...>]

Christian,

Thanks. Your explanation of binary midi is clear to me and is equal to the
decimal jOrgan midi.

jOrgan uses the LSCP protocol through localhost/8888 to send the .lscp file.
jOrgan uses midi protocol through an midiport to toggle note on/off and
toggle stops on/off. Fantasia/QSampler use LSCP protocol to toggle note
on/off and toggle stops on/off.

That works fine in jOrgan, but not using in SFZ trigger=release to play a
given release part of a sample.

Is this an error of Linuxsampler?
How to play a given release part of a sample GIG/SFZ through MIDI?

Kind regards,

Jan Flikweert
--------------------------

-----Original Message-----
From: Christian Schoenebeck [mailto:sch...@li...] 
Sent: maandag 27 december 2021 16:29
To: lin...@li...
Subject: Re: [Linuxsampler-devel] midi message fantasia note off

On Sonntag, 26. Dezember 2021 22:13:05 CET Jan Flikweert wrote:
> Hi,
> 
> I will explain my problem.
> 
> I am working with release samples/sfz.  This works good using fantasia.
Not
> good using jOrgan. jOrgan/Linuxsampler works very good, but without
> release.

JSampler and QSampler both control the sampler purely via network protocol
(called "LSCP"), in this case it is this LSCP command:

SEND CHANNEL MIDI_DATA <midi-msg> <sampler-chan> <arg1> <arg2>

http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html#rfc.section
.6.4.39

> I suppose it has to do with the note_off/note_on messages in
> jOrgan. Note on in jorgan is only set 144,set 36, set velocity. Note off
is
> set 128,set 36,.. and set 176,set 1, set 0 which is cc 1.

MIDI note-off is [1]:
1000nnnn 0kkkkkkk 0vvvvvvv

MIDI note-on is:
1001nnnn 0kkkkkkk 0vvvvvvv

MIDI control change is:
1011nnnn 0ccccccc 0vvvvvvv

Where
  nnnn is the MIDI channel number (0..15)
  kkkkkkk is the key/note number (0..127)
  ccccccc is the controller number (0..127)
  vvvvvvv is velocity (note-on / note-off) or
          the new controller value (0..127) (control change)

Note:
  - Note-On with velocity 0 means "note-off".
  - MIDI allows to omit the status byte on subsequent messages, which is
    called "running status". That's basically just a simple way of data
    compression [2].

[1]
https://www.midi.org/specifications-old/item/table-1-summary-of-midi-message
[2] http://midi.teragonaudio.com/tech/midispec/run.htm
  
CU
Christian




_______________________________________________
Linuxsampler-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] midi message fantasia note off

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

On Sonntag, 26. Dezember 2021 22:13:05 CET Jan Flikweert wrote:
> Hi,
> 
> I will explain my problem.
> 
> I am working with release samples/sfz.  This works good using fantasia. Not
> good using jOrgan. jOrgan/Linuxsampler works very good, but without
> release.

JSampler and QSampler both control the sampler purely via network protocol
(called "LSCP"), in this case it is this LSCP command:

SEND CHANNEL MIDI_DATA <midi-msg> <sampler-chan> <arg1> <arg2>

http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html#rfc.section.6.4.39

> I suppose it has to do with the note_off/note_on messages in
> jOrgan. Note on in jorgan is only set 144,set 36, set velocity. Note off is
> set 128,set 36,.. and set 176,set 1, set 0 which is cc 1.

MIDI note-off is [1]:
1000nnnn 0kkkkkkk 0vvvvvvv

MIDI note-on is:
1001nnnn 0kkkkkkk 0vvvvvvv

MIDI control change is:
1011nnnn 0ccccccc 0vvvvvvv

Where
  nnnn is the MIDI channel number (0..15)
  kkkkkkk is the key/note number (0..127)
  ccccccc is the controller number (0..127)
  vvvvvvv is velocity (note-on / note-off) or
          the new controller value (0..127) (control change)

Note:
  - Note-On with velocity 0 means "note-off".
  - MIDI allows to omit the status byte on subsequent messages, which is
    called "running status". That's basically just a simple way of data
    compression [2].

[1] https://www.midi.org/specifications-old/item/table-1-summary-of-midi-message
[2] http://midi.teragonaudio.com/tech/midispec/run.htm
  
CU
Christian

Re: [Linuxsampler-devel] "GET" LSCP commands to linuxsampler sometimes don't return data

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

On Sonntag, 26. Dezember 2021 21:57:12 CET Andrew C wrote:
> *Diff patch for debugging/illustration purposes:*
> 
> Index: LS-DEBUG/src/engines/gig/InstrumentResourceManager.cpp
> ===================================================================
> --- LS-DEBUG/src/engines/gig/InstrumentResourceManager.cpp      (revision
> 4010)
> +++ LS-DEBUG/src/engines/gig/InstrumentResourceManager.cpp      (working
> copy)
> @@ -216,6 +216,8 @@
>     InstrumentEditor*
> InstrumentResourceManager::LaunchInstrumentEditor(LinuxSampler::EngineChanne
> l* pEngineChannel, instrument_id_t ID,
> void* pUserData) throw (InstrumentManagerException) {
>         const String sDataType    = GetInstrumentDataStructureName(ID);
>         const String sDataVersion = GetInstrumentDataStructureVersion(ID);
> +       fprintf (stderr, "Data type is %s and data version is %s\n",
> sDataType.c_str(), sDataVersion.c_str());
> +       fprintf (stderr, "Instrument plugin is %s\n",
> InstrumentEditorFactory::AvailableEditorsAsString().c_str());

The output of this was an empty string there, which means the sampler did not 
load *any* plugin DLL at all.

>         // find instrument editors capable to handle given instrument
>         std::vector<String> vEditors =
>             InstrumentEditorFactory::MatchingEditors(sDataType,
> sDataVersion);
> @@ -224,10 +226,16 @@
>                 fprintf(stderr,
>                     "ERROR: There is not any instrument editor registered
> to the sampler!\n"
>                     "[Cause: Make sure an instrument editor is installed to
> the sampler's plugin dir (%s)]\n",
> -                    InstrumentEditorFactory::PluginDirsAsString().c_str()
> -                );
> +
>                    InstrumentEditorFactory::PluginDirsAsString().c_str());
> +               if (InstrumentEditorFactory::FoundPlugins) {
> +                 fprintf (stderr,
> +                   "We found and registered plugins in %s at startup, but
> currently available plugins are:%s \n",
> +                    InstrumentEditorFactory::PluginDirsAsString().c_str(),
> +
>                  
> InstrumentEditorFactory::AvailableEditorsAsString().c_str()
> 
> +                  );
> +                };
>                 throw InstrumentManagerException(
> -                    "There is not any instrument editor installed and
> registered to the sampler"
> +                    "netcat seems to cause issues."
>                 );

Has nothing to do with netcat.

>             }
>             fprintf(stderr,
> Index: LS-DEBUG/src/plugins/InstrumentEditorFactory.cpp
> ===================================================================
> --- LS-DEBUG/src/plugins/InstrumentEditorFactory.cpp    (revision 4010)
> +++ LS-DEBUG/src/plugins/InstrumentEditorFactory.cpp    (working copy)
> @@ -44,6 +44,7 @@
>     std::map<String, InstrumentEditorFactory::InnerFactory*>
> InstrumentEditorFactory::InnerFactories;
> 
>     bool InstrumentEditorFactory::bPluginsLoaded = false;
> +    bool InstrumentEditorFactory::FoundPlugins = false;
> 
>     std::list<void*> InstrumentEditorFactory::LoadedDLLs;
> 
> @@ -287,6 +288,7 @@
>         }
>         closedir(hDir);
>         #endif
> +       InstrumentEditorFactory::FoundPlugins = true;
>         return true;
>     }

Wrong assumption. At this point it just *tried* to load plugins. It does not 
mean it was able to actually load any plugin successfully.

You should rather debug what happens in the loop above.

  for (dirent* pEntry = readdir(hDir); pEntry; pEntry = readdir(hDir)) {
    ...
  }

That loops iterares over all files found in the plugin dir and then tries to 
load every file that is actually a DLL file (i.e. filename ending with ".so").

> Index: LS-DEBUG/src/plugins/InstrumentEditorFactory.h
> ===================================================================
> --- LS-DEBUG/src/plugins/InstrumentEditorFactory.h      (revision 4010)
> +++ LS-DEBUG/src/plugins/InstrumentEditorFactory.h      (working copy)
> @@ -98,6 +98,7 @@
>         static String              PluginDirsAsString();
>         static std::vector<String> AvailableEditors();
>         static String              AvailableEditorsAsString();
> +       static bool                FoundPlugins;
>         static std::vector<String> MatchingEditors(String sTypeName, String
> sTypeVersion);
>         static void                LoadPlugins();
>         static void                ClosePlugins();

Re: [Linuxsampler-devel] midi message fantasia note off

[Jan F. <fl...@ze...>]

Hi,

 

I will explain my problem.

 

I am working with release samples/sfz.  This works good using fantasia. Not good using jOrgan. jOrgan/Linuxsampler works very good, but without release. I suppose it has to do with the note_off/note_on messages in jOrgan. Note on in jorgan is only set 144,set 36, set velocity. Note off is set 128,set 36,.. and set 176,set 1, set 0 which is cc 1.

 

Kind regards,

 

Jan Flikweert

 

From: Andrew C [mailto:cou...@gm...] 
Sent: zondag 26 december 2021 17:48
To: Jan Flikweert
Cc: linuxsampler-devel
Subject: Re: [Linuxsampler-devel] midi message fantasia note off

 

Hi Jan,

 

I would imagine it's a simple enough NOTE_OFF event is all. Just to illustrate the code from jlscp's event/MidiDataEvent: 

 

ackage org.linuxsampler.lscp.event; 

/** 
* A semantic event which indicates that MIDI data has arrived. 
* @author Grigor Iliev 
*/ 
public class MidiDataEvent extends java.util.EventObject { 
       public static enum Type { 
               NOTE_ON  ("NOTE_ON"), 
               NOTE_OFF ("NOTE_OFF"), 
               CC       ("CC"); 



 

Andrew.

 

On Sun, Dec 26, 2021 at 11:58 AM Jan Flikweert <fl...@ze...> wrote:

Hi all,

 

Which midi messages does Fantasia send for a note-off event after releasing a key on the keyboard from its main screen?

 

I tried with midi-ox but that did not work.

 

Kind regards,

 

Jan Flikweert

_______________________________________________
Linuxsampler-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel