linuxsampler-devel

[Linuxsampler-devel] docs

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

Some news: I thought it's time to write some decent documentation about the 
new instrument script feature. This is an introduction to the NKSP language 
itself:

	http://doc.linuxsampler.org/Instrument_Scripts/NKSP_Language/

And this is the reference documentation, covering all built-in functions, 
built-in variables and constants, etc.:

	http://doc.linuxsampler.org/Instrument_Scripts/NKSP_Language/Reference/

There is also a short explanation how to stick scripts to your .gig files:

	http://doc.linuxsampler.org/Gigedit/Managing_Scripts/

Along with those new articles, I also wrote a new online documentation 
software system which this new site is using to make writing and maintaining 
documentation as simple and easy as possible, while still preserving all the 
powerful abilities of HTML & co (if really required in some cases). And guess 
what, there is even already an article about it: ;-)

	http://doc.linuxsampler.org/Writing_Docs/

My plan is to move our (meanwhile completely outdated) manuals and tutorials 
to this dedicated new site. Anybody interested to help writing some 
documentation is very much invited!

I still have some hope, that somebody might put its hands on creating the 
first publicly available documentation for the SFZ(2) file format.

CU
Christian

Re: [Linuxsampler-devel] docs

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

The display format is really good, and pleasant to read, this is really good work.

Now It's a good reason to try to script the Hihat behaviour i need (and was only made workable with some tricky midi treatment before the sampler).
But i may lack some timing tools (i need a sort of enveloppe tool)... Is there a way so i could make a arithmetic operation every 10ms for example ?

Raphaël 

Le 29 avr. 2015 à 15:11, Christian Schoenebeck <sch...@li...> a écrit :

> Some news: I thought it's time to write some decent documentation about the 
> new instrument script feature. This is an introduction to the NKSP language 
> itself:
> 
> 	http://doc.linuxsampler.org/Instrument_Scripts/NKSP_Language/
> 
> And this is the reference documentation, covering all built-in functions, 
> built-in variables and constants, etc.:
> 
> 	http://doc.linuxsampler.org/Instrument_Scripts/NKSP_Language/Reference/
> 
> There is also a short explanation how to stick scripts to your .gig files:
> 
> 	http://doc.linuxsampler.org/Gigedit/Managing_Scripts/
> 
> Along with those new articles, I also wrote a new online documentation 
> software system which this new site is using to make writing and maintaining 
> documentation as simple and easy as possible, while still preserving all the 
> powerful abilities of HTML & co (if really required in some cases). And guess 
> what, there is even already an article about it: ;-)
> 
> 	http://doc.linuxsampler.org/Writing_Docs/
> 
> My plan is to move our (meanwhile completely outdated) manuals and tutorials 
> to this dedicated new site. Anybody interested to help writing some 
> documentation is very much invited!
> 
> I still have some hope, that somebody might put its hands on creating the 
> first publicly available documentation for the SFZ(2) file format.
> 
> CU
> Christian
> 
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud 
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] docs

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

On Wednesday 29 April 2015 22:21:09 Raphaël Mouneyres wrote:
> The display format is really good, and pleasant to read, this is really
> good work.

Thanks!

> Now It's a good reason to try to script the Hihat behaviour i need (and was
> only made workable with some tricky midi treatment before the sampler).
> But i may lack some timing tools (i need a sort of enveloppe tool)... Is
> there a way so i could make a arithmetic operation every 10ms for example
> ?

You "could" write a note event handler and use the wait() function:

http://doc.linuxsampler.org/Instrument_Scripts/NKSP_Language/Reference/wait_function/

and then update all required synthesis parameters directly in a while loop.
I said "could" because I did not have time yet to fully implement the wait() 
function. As the document states, a wait() call currently ignores the 
parameter passed to it, because the required scheduling code is yet missing. 
Instead the script is always resumed in the next audio period.

But since the wait() function is one of the most fundamental functions for 
writing useful scripts, this is probably one of the next things I'm going to 
do. So stay tuned!

Best regards,
Christian Schoenebeck

Re: [Linuxsampler-devel] docs

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

Le 30 avr. 2015 à 11:01, Christian Schoenebeck <sch...@li...> a écrit :

> On Wednesday 29 April 2015 22:21:09 Raphaël Mouneyres wrote:
>> The display format is really good, and pleasant to read, this is really
>> good work.
> 
> Thanks!
> 
>> Now It's a good reason to try to script the Hihat behaviour i need (and was
>> only made workable with some tricky midi treatment before the sampler).
>> But i may lack some timing tools (i need a sort of enveloppe tool)... Is
>> there a way so i could make a arithmetic operation every 10ms for example
>> ?
> 
> You "could" write a note event handler and use the wait() function:
> 
> http://doc.linuxsampler.org/Instrument_Scripts/NKSP_Language/Reference/wait_function/
> 
> and then update all required synthesis parameters directly in a while loop.
> I said "could" because I did not have time yet to fully implement the wait() 
> function. As the document states, a wait() call currently ignores the 
> parameter passed to it, because the required scheduling code is yet missing. 
> Instead the script is always resumed in the next audio period.
> 
> But since the wait() function is one of the most fundamental functions for 
> writing useful scripts, this is probably one of the next things I'm going to 
> do. So stay tuned!
> 
> Best regards,
> Christian Schoenebeck

So this could still be tested with a uncontrollable but fixed wait time (audio period).
I'll let you know how it goes when I put my hand in the code.

Raphaël

Re: [Linuxsampler-devel] docs

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

On Thursday 30 April 2015 13:12:12 Raphaël Mouneyres wrote:
> So this could still be tested with a uncontrollable but fixed wait time
> (audio period). I'll let you know how it goes when I put my hand in the
> code.

One thing I haven't decided yet is the precise function prototype of the 
functions that can alter the synthesis parameters directly. For example to 
change the current volume of an active note, Kontakt has this KSP function:

	change_vol(note-id, volume, relative)

- "note-id" is the event ID of the precise note (voice) you want to change its 
   volume of.
- "volume" is the new volume value of the note (voice) in millidecibel
- "relative" is special thing: if you pass 0, then the note's volume will be 
   simply overwritten, if you pass 1 then your new volume will be applied 
  "relative" to the notes's current volume value.

Now that last mentioned parameter probably outlines, that their function 
prototype is a bit suboptimal. Because first of all, what is "relative"? Does 
it "add" *or* "multply" the new volume value against the current value? Then 
the next thing is, this "relative" behavior is just meant to be applied to the 
value that *you* might have set before with a previous call of change_vol(). 
This "relative" option has *no* impact on other volume modifiers, like volume 
LFOs, volume envelopes, etc. So what do we want to do with the current volume 
changed by those mentioned other sources (LFO,EG,...)?

	- Should this function simply override them completely and thus 
	  effectively disable those other volume control sources?
	- Should it rather add its value to the volume levels of the other 
	  sources instead?
	- Should it rather multiply its value against the volume levels of the 
	  other sources instead?

Probably we rather want the script author to decide this, and then we need to 
add more options for the change_vol() function. Comments appreciated.

CU
Christian

Re: [Linuxsampler-devel] docs

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

> One thing I haven't decided yet is the precise function prototype of the 
> functions that can alter the synthesis parameters directly. For example to 
> change the current volume of an active note, Kontakt has this KSP function:
> 
> 	change_vol(note-id, volume, relative)
> 
> - "note-id" is the event ID of the precise note (voice) you want to change its 
>   volume of.
> - "volume" is the new volume value of the note (voice) in millidecibel
> - "relative" is special thing: if you pass 0, then the note's volume will be 
>   simply overwritten, if you pass 1 then your new volume will be applied 
>  "relative" to the notes's current volume value.
> 
> Now that last mentioned parameter probably outlines, that their function 
> prototype is a bit suboptimal. Because first of all, what is "relative"? Does 
> it "add" *or* "multply" the new volume value against the current value? Then 
> the next thing is, this "relative" behavior is just meant to be applied to the 
> value that *you* might have set before with a previous call of change_vol(). 
> This "relative" option has *no* impact on other volume modifiers, like volume 
> LFOs, volume envelopes, etc. So what do we want to do with the current volume 
> changed by those mentioned other sources (LFO,EG,...)?

I think (not verified) their relative mode is similar to the one found in the midibox diy project.
They have a good explanation of different "pot behaviour", and the 4 modes are quite exhaustive : Normal/Snap/Relative/Parallax

Quote : "Relative Mode: When you adjust a knob in Relative Mode, the parameter is affected immediately but not absolutely. In other words, the parameter change from the original value to the new value now reflects precisely the amount you adjusted the given knob. ie if the knob value is +30, and when you switch over, the value is now +50, the knob continues on as if it were at the parameter-set +50 position, so when you turn the knob (even though the knob physically is at +30) the next parameter value will be +51 (even though the knob is at +31). Obvoiusly, the downside is that in an unfavorable configuration - the worst case scenario being a maximum parameter value and a knob position at the minimum value - you do not have the full control range of the knob at your disposal. To counteract this situation, you have to turn the knob in the opposite direction to adjust the physical knob position so that it is equivalent to the actual parameter value (ie. turn the knob up to maximum, which will sync it with the maximum parameter value)."

In linuxsampler the received midi data replaces the knob position in the above text.
You can read complete explanations of modes here : http://www.ucapps.de/midibox_tutorial.html
Now, I'm not sure if these modes could apply to a software without GUI, as the user wouldn't have visual feedback to explain why the controlled parameter doesn't have the value sent by midi (unless he's aware to have explicitly set himself the mode, or having some debug/log information; which can be ok for a self written patch, but not so sure with a downloaded one)

> 
> 	- Should this function simply override them completely and thus 
> 	  effectively disable those other volume control sources?
> 	- Should it rather add its value to the volume levels of the other 
> 	  sources instead?
> 	- Should it rather multiply its value against the volume levels of the 
> 	  other sources instead?
> 
> Probably we rather want the script author to decide this, and then we need to 
> add more options for the change_vol() function. Comments appreciated.
> 
> CU
> Christian


Raphaël Mouneyres
06 89 85 58 81

Re: [Linuxsampler-devel] docs

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

On Monday 11 May 2015 09:51:32 you wrote:
> In linuxsampler the received midi data replaces the knob position in the
> above text. You can read complete explanations of modes here :
> http://www.ucapps.de/midibox_tutorial.html Now, I'm not sure if these
> modes could apply to a software without GUI, as the user wouldn't have
> visual feedback to explain why the controlled parameter doesn't have the
> value sent by midi (unless he's aware to have explicitly set himself the
> mode, or having some debug/log information; which can be ok for a self
> written patch, but not so sure with a downloaded one)

That's the point. This "relative" parameter makes sense for an endless rotary 
encoder knob, but not really for scripting stuff. But maybe its because 
Kontakt supports also UI stuff with scripts. So that "relative" parameter was 
probably added to allow easy binding of some UI knob.

I guess I will preserve just that relative parameter for now as is. And maybe 
I add other parameters/alternative flags later on.

I'm currently working on the scheduler BTW.

CU
Christian