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

[Linuxsampler-devel] Experimenting with sinc-based resampling

[JP C. <jp...@ci...>]

Hi, lately I've stumbled upon an old article that sings praise of
Akai S1000 samplers and the resampling algorithm it used.
This piqued my curiosity and inspired me to try implementing a sinc
resampler into LS for comparison.

I attach my code to the message, as patch against svn trunk.
Link to the article: http://martin78.com/samplers/akai-s1000-s1100/

-- some implementation notes:
* this is a N-point sinc resampler, where N is defined in code by
  parameter SINC_NPTOTAL=SINC_NPBEFORE+SINC_NPAFTER
* code uses optimization to reduce the number of trig operations/sample
  from N sin() to 1 sin() + 1 cos()

As default I have used parameters NPBEFORE=1 NPAFTER=7, the number of
past and future samples used respectively.
This happens in some situations, with some samples of my set, to crash
LS with segfault, presumably because of out-of-bounds access by
getSample().

The question is: where in LS is defined how many past/future samples are
available to the resampling?
I note LS already has linear and cubic which require 2 and 4. How
to control this number? Akai S1000 supposedly has N=8, but I'd like to
also to try larger lengths.

Re: [Linuxsampler-devel] linuxsampler-2.0.0 complile problems

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

On Saturday 26 March 2016 20:28:29 Florian Berger wrote:
> On 25.03.2016 10:24, Christian Schoenebeck wrote:
> > Make sure you have bison installed, then try "make parser" from the
> > source's top level directory.
> 
> That fixed it, thanks.
> 
> Out of curiosity - why did I have to run this manually? Why doesn't the
> build script take care of this?

It "usually" does.

Try adding i.e. some white space character in any of the .y source files, then 
do "make" and the build scripts should automatically execute bison to 
regenerate the respective parser (.y -> .cpp).

CU
Christian

Re: [Linuxsampler-devel] linuxsampler-2.0.0 complile problems

[Florian B. <li...@fl...>]

Hi,

On 25.03.2016 10:24, Christian Schoenebeck wrote:
> Make sure you have bison installed, then try "make parser" from the
> source's top level directory.

That fixed it, thanks.

Out of curiosity - why did I have to run this manually? Why doesn't the
build script take care of this?

Thanks,

Florian

Re: [Linuxsampler-devel] linuxsampler-2.0.0 complile problems

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

On Friday 25 March 2016 10:02:38 Florian Berger wrote:
> "'yyprhs' was not declared in this scope" looks like a parsing error.
> Either my build environment is outdated, or there is something wrong in
> the source. :-)

Make sure you have bison installed, then try "make parser" from the source's 
top level directory. If that does not fix it, then please post your precise 
bison version.

CU
Christian

[Linuxsampler-devel] linuxsampler-2.0.0 complile problems

[Florian B. <li...@fl...>]

Hi,

as bb.linuxsampler.org registration currently states "SORRY REGISTRATION
TEMPORARILY DISABLED", I'll just ask here:

Attempting to compile the stable linuxsampler 2.0.0, I get:

Making all in network
make[3]: Entering directory
`/home/florian/temp/linuxsampler-2.0.0/src/network'
depbase=`echo lscpparser.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H
-I. -I../..   -I/usr/include/libgig    -Wreturn-type -ffast-math
-march=i686 -g -O2 -pthread -MT lscpparser.lo -MD -MP -MF $depbase.Tpo
-c -o lscpparser.lo lscpparser.cpp &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include/libgig
-Wreturn-type -ffast-math -march=i686 -g -O2 -pthread -MT lscpparser.lo
-MD -MP -MF .deps/lscpparser.Tpo -c lscpparser.cpp  -fPIC -DPIC -o
.libs/lscpparser.o
lscp.y: In function 'bool _isRuleTerminalSymbol(int)':
lscp.y:1380:18: error: 'yyprhs' was not declared in this scope
     for (int i = yyprhs[rule]; yyrhs[i] != -1; ++i)
                  ^
lscp.y:1380:32: error: 'yyrhs' was not declared in this scope
     for (int i = yyprhs[rule]; yyrhs[i] != -1; ++i)
                                ^
make[3]: *** [lscpparser.lo] Error 1

"'yyprhs' was not declared in this scope" looks like a parsing error.
Either my build environment is outdated, or there is something wrong in
the source. :-)

How can I go about fixing this?

I'll happily supply any required detail.

Thanks,

Florian

[Linuxsampler-devel] (no subject)

[<kf...@ko...>]

Hi,

Using the SFZ engine, I was surprised that the `off_by` and `group`
opcodes don't seem to have any effect if the "muting" and "muted" events
occur on the same key, even if they relate to separate regions (differing
by velocity, channel, etc.). It seems like it would be very useful to be
able to mute events on the same key.

I note that in 2012 a one-line patch was suggested that lifts this
restriction:

    +++ linuxsampler/src/engines/sfz/Voice.cpp
    - itEvent->Param.Note.Key != MIDIKey) {
    + itEvent->Param.Note.Key) {

https://sourceforge.net/p/linuxsampler/mailman/message/29191998/

I was wondering, is the current behaviour defined by some official SFZ
specification document, team policy, or something else? It would be great
to at least have the option to change this behaviour.

Thanks,

KF.

Re: [Linuxsampler-devel] New sample engine (and editor too)

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

On Saturday 13 February 2016 16:53:29 Mauricio Kanada wrote:
> I was thinking in a new sample format based on spectrum and not on
> waveform. The idea is create samples that sounds good without the need of
> thousands of samples. Imagine a piano library with only 5 velocity layers
> stored in spectra format (maybe in mdct format) and the engine blend the
> spectrum at run time. Casio has this technology and name it as
> 'Multi-Dimensional Morphing'. Kontakt name it as AET (Authentic Expression
> Technology), but as I know, it is at edition time, not at runtime.

Well, this idea is not new and is already used in products for years. It was 
also discussed here couple years ago when we started to work on additional 
sampler engines/formats. Keep in mind that performing things in the frequency 
domain can be quite expensive. That's why it is mostly still more effective 
overall (for the musician) to play with a huge set of samples in the signal 
domain instead.

And yes, sure would be nice to have, however so far simply nobody has yet 
started working on this with LinuxSampler. Since this is essentially a spare 
time project for all of us, it is all a matter of personal priorities.

CU
Christian

[Linuxsampler-devel] New sample engine (and editor too)

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

Hello developers.

I was thinking in a new sample format based on spectrum and not on waveform. The idea is create samples that sounds good without the need of thousands of samples.
Imagine a piano library with only 5 velocity layers stored in spectra format (maybe in mdct format) and the engine blend the spectrum at run time. Casio has this technology and name it as 'Multi-Dimensional Morphing'. Kontakt name it as AET (Authentic Expression Technology), but as I know, it is at edition time, not at runtime.

Now, imagine that this technology can be used not only to piano libraries, but for any type of sound.
I think that this technology can be groundbreaking in the samplers market. With good editor + script toolset, anyone can create your own 'instrument model'.

What do you think about?

Thanks

Maurício Kanada

[Linuxsampler-devel] dh_install: liblinuxsampler missing files (debian/tmp/usr/lib/lv2/linuxsampler*)

[Frank S. <fra...@ce...>]

Hello,

I found a lot of these "missing files" messages solved by installing missing dependency packages.

Here I'm lost - I cannot install linuxsampler because linuxsampler is missing.

This seems to happen somewhere (somewhen) near the very end of the build process.
So every help would be very apreciated.

Cheers
Frank

Re: [Linuxsampler-devel] SFZ 2.0 Headers and Macros Patch

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

Hi Andreas,

Great!

Thanks for all your work on LinuxSampler.

- Alby M.

On Wed, Jan 6, 2016 at 3:04 AM Andreas Persson <and...@ou...>
wrote:

> Alby M. wrote:
> > Hi Christian,
> >
> > Great! Looking forward to hearing from you.
> >
> > - Alby
>
> Hello! I've reviewed the patch and committed it to svn. Nice work! Sorry
> for taking so long.
>
> /Andreas
>
> >
> > On Thu, Dec 17, 2015 at 5:55 AM Christian Schoenebeck
> > <sch...@li... <mailto:sch...@li...>>
> wrote:
> >
> >     On Tuesday 15 December 2015 22:11:44 Alby M. wrote:
> >     > The mailing list is having trouble with the size of the patch
> >     (~35kB), so
> >     > here it is in my Dropbox:
> >     >
> >
> https://www.dropbox.com/s/2ksct5d0h1s3lxy/headers-macros-patch.patch?dl=0
> >     >
> >     > If you just want the new `sfz.cpp` and `sfz.h`, I can send those
> too.
> >
> >     Hi Alby,
> >
> >     I am currently on the road. I will check your patch when I am back
> >     in about a
> >     week.
> >
> >     If anybody else got the chance to check and apply Alby's patch to
> >     SVN in the
> >     meantime, very much appreciated!
> >
> >     CU
> >     Christian
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > 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] SFZ 2.0 Headers and Macros Patch

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

Alby M. wrote:
> Hi Christian,
> 
> Great! Looking forward to hearing from you.
> 
> - Alby

Hello! I've reviewed the patch and committed it to svn. Nice work! Sorry
for taking so long.

/Andreas

> 
> On Thu, Dec 17, 2015 at 5:55 AM Christian Schoenebeck
> <sch...@li... <mailto:sch...@li...>> wrote:
> 
>     On Tuesday 15 December 2015 22:11:44 Alby M. wrote:
>     > The mailing list is having trouble with the size of the patch
>     (~35kB), so
>     > here it is in my Dropbox:
>     >
>     https://www.dropbox.com/s/2ksct5d0h1s3lxy/headers-macros-patch.patch?dl=0
>     >
>     > If you just want the new `sfz.cpp` and `sfz.h`, I can send those too.
> 
>     Hi Alby,
> 
>     I am currently on the road. I will check your patch when I am back
>     in about a
>     week.
> 
>     If anybody else got the chance to check and apply Alby's patch to
>     SVN in the
>     meantime, very much appreciated!
> 
>     CU
>     Christian
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 

Re: [Linuxsampler-devel] SFZ 2.0 Headers and Macros Patch

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

Hi Christian,

Great! Looking forward to hearing from you.

- Alby

On Thu, Dec 17, 2015 at 5:55 AM Christian Schoenebeck <
sch...@li...> wrote:

> On Tuesday 15 December 2015 22:11:44 Alby M. wrote:
> > The mailing list is having trouble with the size of the patch (~35kB), so
> > here it is in my Dropbox:
> >
> https://www.dropbox.com/s/2ksct5d0h1s3lxy/headers-macros-patch.patch?dl=0
> >
> > If you just want the new `sfz.cpp` and `sfz.h`, I can send those too.
>
> Hi Alby,
>
> I am currently on the road. I will check your patch when I am back in
> about a
> week.
>
> If anybody else got the chance to check and apply Alby's patch to SVN in
> the
> meantime, very much appreciated!
>
> CU
> Christian
>

Re: [Linuxsampler-devel] SFZ 2.0 Headers and Macros Patch

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

On Tuesday 15 December 2015 22:11:44 Alby M. wrote:
> The mailing list is having trouble with the size of the patch (~35kB), so
> here it is in my Dropbox:
> https://www.dropbox.com/s/2ksct5d0h1s3lxy/headers-macros-patch.patch?dl=0
> 
> If you just want the new `sfz.cpp` and `sfz.h`, I can send those too.

Hi Alby,

I am currently on the road. I will check your patch when I am back in about a 
week.

If anybody else got the chance to check and apply Alby's patch to SVN in the 
meantime, very much appreciated!

CU
Christian

[Linuxsampler-devel] SFZ 2.0 Headers and Macros Patch

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

(Note: I sent this into the list once before, but it got caught up in some
strange moderation review queue because of the size of the attachments. If
a second version of this shows up at some point, sorry!)

Hi All,

I've been planning on using LinuxSampler for some music production
projects, and discovered that support for some simple features (not audio
synthesis related) of the SFZ format was missing. Specifically, support for
the SFZ 2.0 headers (`<global>`, and the ARIA specific `<master>`) and
`#define`d macros was lacking, so I've put together a small patch to
"libsfz" (sfz.cpp and sfz.h).

`<master>` is docuemnted here:
http://plogue.com/phpBB3/viewtopic.php?f=14&t=4389&sid=7b41e5de2121982e95e5781cebd7a77e

I couldn't find any actual documentation of the SFZ format's parsing rules,
so this whole thing is based on some assumptions I made that seemed
reasonable:
  - Each header lasts until the next header of equal or higher level. E.g.,
a <master> lasts until the next <master> or <global>.
  - Multiple <global>s are fine. It was easier not to add any special
cases, and it's not like this would brake anything that just uses one
<global>.
  - Macro names must start with `$`, and can contain alphanumerics and
underscores.
  - Macro values can contain alphanumerics, spaces, underscores, periods,
and forward and backward slashes. I'm not quite sure, but this seemed
sensible. If not, it's always possible for the macro value to be anything
until end of line, but that seemed like it might throw the rest of the
parsing code too much.
  - Macros can be used anywhere in an opcode value, and can be used for CCs
in `cc` and `_oncc` opcodes.
  - Multiple macros can occur in one opcode value.
  - When used in a value, a macro's name is assumed to go from (and
including) the `$` to the first character that is invalid in a macro name.
For example, in `default_path=$sample_dir/Drums`, the macro name is assumed
to be `$sample_dir`.

I did the best I could to follow the coding conventions of libsfz (braces
on next line, space before parens, etc.).

The mailing list is having trouble with the size of the patch (~35kB), so
here it is in my Dropbox:
https://www.dropbox.com/s/2ksct5d0h1s3lxy/headers-macros-patch.patch?dl=0

If you just want the new `sfz.cpp` and `sfz.h`, I can send those too.

You can also test this using the Free Sounds for ARIA Engine pack (
http://ariaengine.com/forums/index.php?p=/discussion/5783/free-sounds-for-aria-engine/p1).
You have to add something like `#define $sample_dir ../../Samples` though.
The ones that use mostly supported features seem to work pretty well, and
these are some of the most complex SFZs I've seen.

Thanks for all of your work on LinuxSampler!

Sincerely,
Alby

[Linuxsampler-devel] RTmath compile error.

[Jonathan R. <jro...@ya...>]

Hi all,
I'm trying to compile linuxsampler on a orangepi with allwinner H3 processor.I got this error during compile:
RTMath.cpp:75:8: error: #error "Sorry, LinuxSampler lacks time stamp code for your system."
     #  error "Sorry, LinuxSampler lacks time stamp code for your system."
        ^
RTMath.cpp:76:8: error: #error "Please report this error and the CPU you are using to the LinuxSampler developers mailing list!"


This is my  /proc/cpuinfo
Processor       : ARMv7 Processor rev 5 (v7l)
processor       : 0
BogoMIPS        : 1920.00

processor       : 1
BogoMIPS        : 1920.00

processor       : 2
BogoMIPS        : 1920.00

processor       : 3
BogoMIPS        : 1920.00

Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xc07
CPU revision    : 5

Hardware        : sun8i
Revision        : 0000
Serial          : 4400503404145823014e
Anny suggestions on how to solve this problem?
Thanks for helping.
Best regards,Mrroland.

Re: [Linuxsampler-devel] Problem building package linuxsampler 2.0.0 (2832)

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

On Friday 31 July 2015 01:23:30 you wrote:
> Thanks, I also needed to install the lv2-dev package. I suppose these
> dependencies are new but not checked upon configuring. Linuxsampler

The dependencies are old, and they are checked by the configure script as 
optional dependencies for a long time.

What changed is the behavior of the Debian packaging scripts. The 
debian/PACKAGENAME.install files are in general used to declare which files 
should make it into the .deb package and to which directory on the target 
system they shall be unpacked to. On previous Debian versions files listed 
there which did not exist were simply ignored, now the packaging script aborts 
on such cases.

I couldn't figure out yet whether Debian now also allows to add optional files 
there in some way, maybe with some prefix keyword in debian/*.install, or as 
parameter to some of the dh_ calls in debian/rules.

> compiled and installed successfully now! But I ran into a new problem when
> compiling the current qsampler package:
> 
[snip]
> Makefile install make[3]: Entering directory
> `/home/tom/lsampler/qsampler/src'
> mkdir: cannot create directory ‘/usr/src/packages’: Permission denied

Your user running dpkg-buildpackage has no write permission on 
/usr/src/packages, a directory created by you manually. Just change the 
permissions on that directory and it will work.

> Full log here: https://pastee.org/qqs26 (dpkg-buildpackage -rfakeroot -b)
> 
> So dpkg-buildpackage had first complained that a few qt dependencies were
> missing so I installed them, though still it gives me this error and fails
> to create the package.
> 
> The "permission denied" error is because it's trying to run mkdir under
> /usr/, right? And since I'm not running dpkg-buildpackage as root, it's
> failing. I'm not sure I should run it as root, as it already set the
> -rfakeroot parameter. Well I'm hoping you can tell me what's going on or
> how to work around this problem.

No need to run it as root, fakeroot is just fine. Just fix the write 
permissions for the running user, that's it.

CU
Christian

Re: [Linuxsampler-devel] Problem building package linuxsampler 2.0.0 (2832)

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

On Thursday 30 July 2015 00:49:36 to...@ci... wrote:
> Now I'm trying to compile Linuxsampler 2.0.0 (2832), but running into a
> problem when running "dpkg-buildpackage -rfakeroot -b" Here's a snip from
> where it fails:
> 
> dh_testdir
> dh_testroot
> dh_install -a --list-missing
> dh_install: liblinuxsampler missing files (debian/tmp/usr/lib/dssi/*),
> aborting make: *** [binary-arch] Error 2

apt-get install dssi-dev

CU
Christian

[Linuxsampler-devel] Problem building package linuxsampler 2.0.0 (2832)

[<to...@ci...>]

Hello,

I've successfully compiled libgig 4.0.0 following the Debian instructions (I had successfully compiled and installed all packages from the previous 2009 release). I've uninstalled previous packages before installing the current "libgig7_4.0.0-1_amd64.deb" package, which is the name of the current release.

Now I'm trying to compile Linuxsampler 2.0.0 (2832), but running into a problem when running "dpkg-buildpackage -rfakeroot -b"
Here's a snip from where it fails:

dh_testdir
dh_testroot
dh_install -a --list-missing
dh_install: liblinuxsampler missing files (debian/tmp/usr/lib/dssi/*), aborting
make: *** [binary-arch] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2


Here's the full dpkg-buildpackage log:
https://pastee.org/3m8t5

I'm running Linux Mint 17 KDE. How should I go about solving this problem? 
Tom

[Linuxsampler-devel] LinuxSampler 2.0.0 released

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

It's been a long time, I know, but finally there is a new release:

	- LinuxSampler 2.0.0
	- Gigedit 1.0.0
	- QSampler 0.3.1
	- libgig 4.0.0

Six years of development, a load of things changed, so many that there is a 
detailed review of what's new with LinuxSampler and friends. Check it out:

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

CU
Christian

P.S. This is a late announcement due to SourceForge's recent millennium down 
time.

Re: [Linuxsampler-devel] Linuxsampler not registering JACK devices

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

On Friday 26 June 2015 17:42:23 to...@ci... wrote:
> I've checked the installed packages, and JACK is installed as jackd2. I did
> not compile jack myself, it was installed from the package manager.
> Additionally there is no jack.pc file on my file system. Of course, after
> installing the newly compiled package, there was no JACK support either.
> From the LS log:

jack.pc and all C header files (i.e jack.h) are not included with the regular 
"jack" package, but with a separate "libjack-dev" package. The exact -dev 
package name may vary from distribution to distribution. Use:

	apt-cache search --names-only jack

to get a list with all packages having "jack" in its name. Then install the 
right package with

	apt-get install PACKAGE_NAME

CU
Christian

[Linuxsampler-devel] Linuxsampler not registering JACK devices

[<to...@ci...>]

Hello,

I'm running Linux Mint 17, which is based off Ubuntu. My goal is to set up Linuxsampler as a piano sequencer for my MIDI Casio keyboard.

I've followed the instructions on pulling and compiling the LS sources from subversion, built Debian packages from them and installed them, and everything seems to be in order. I've also installed and, to my knowledge, correctly configured qjackctl.

Unfortunately, when adding a new device from Qsampler I could only choose ALSA drivers, not JACK ones. There was no JACK drivers option in the drop-down list in the Devices dialog. Browsing the bulleting boards (which, by the way, have registration disabled so I couldn't post there as I don't have a forum account) I found out LS wasn't compiled with Jack support, because I didn't have the jack package installed at the time of compilation.

So I went back and recompiled LS but it seems it didn't do as expected (snip from config.log):

configure:17712: checking for JACK
configure:17719: $PKG_CONFIG --exists --print-errors "jack"
Package jack was not found in the pkg-config search path.
Perhaps you should add the directory containing `jack.pc'
to the PKG_CONFIG_PATH environment variable
No package 'jack' found
configure:17722: $? = 1
configure:17736: $PKG_CONFIG --exists --print-errors "jack"
Package jack was not found in the pkg-config search path.
Perhaps you should add the directory containing `jack.pc'
to the PKG_CONFIG_PATH environment variable
No package 'jack' found
configure:17739: $? = 1
configure:17753: result: no
No package 'jack' found


I've checked the installed packages, and JACK is installed as jackd2. I did not compile jack myself, it was installed from the package manager. Additionally there is no jack.pc file on my file system. Of course, after installing the newly compiled package, there was no JACK support either. From the LS log:

Registered MIDI input drivers: ALSA
Registered audio output drivers: ALSA


How should I go about solving this issue? With regards,

Tom

[Linuxsampler-devel] [OSX problem] daily builds not working on yosemite

[vic h. <xel...@ho...>]

Hey all,
I try to install linux sampler on a yosemite system, and it doesn't work ; the message diplayed after i launch teh installer is "Wrong MacOSX version - You need at least Mac OSX 10.5.0 to install this software".
So is LinuxSampler not working on yosemite yet ? Or just not compiled for it ? Or is that a matter of activating a flag somewhere...
Sorry to disturb you with a question about osx ;)
 		 	   		  

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

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 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