Menu
▾
▴
linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(27) |
Nov
(120) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(65) |
Feb
(2) |
Mar
(53) |
Apr
(15) |
May
|
Jun
(19) |
Jul
(8) |
Aug
(35) |
Sep
(17) |
Oct
(70) |
Nov
(87) |
Dec
(94) |
| 2004 |
Jan
(133) |
Feb
(28) |
Mar
(45) |
Apr
(30) |
May
(113) |
Jun
(132) |
Jul
(33) |
Aug
(29) |
Sep
(26) |
Oct
(11) |
Nov
(21) |
Dec
(60) |
| 2005 |
Jan
(108) |
Feb
(153) |
Mar
(108) |
Apr
(44) |
May
(72) |
Jun
(90) |
Jul
(99) |
Aug
(67) |
Sep
(117) |
Oct
(38) |
Nov
(40) |
Dec
(27) |
| 2006 |
Jan
(16) |
Feb
(18) |
Mar
(21) |
Apr
(71) |
May
(26) |
Jun
(48) |
Jul
(27) |
Aug
(40) |
Sep
(20) |
Oct
(118) |
Nov
(69) |
Dec
(35) |
| 2007 |
Jan
(76) |
Feb
(98) |
Mar
(26) |
Apr
(126) |
May
(94) |
Jun
(46) |
Jul
(9) |
Aug
(89) |
Sep
(18) |
Oct
(27) |
Nov
|
Dec
(49) |
| 2008 |
Jan
(117) |
Feb
(40) |
Mar
(18) |
Apr
(30) |
May
(40) |
Jun
(10) |
Jul
(30) |
Aug
(13) |
Sep
(29) |
Oct
(23) |
Nov
(22) |
Dec
(35) |
| 2009 |
Jan
(19) |
Feb
(39) |
Mar
(17) |
Apr
(2) |
May
(6) |
Jun
(6) |
Jul
(8) |
Aug
(11) |
Sep
(1) |
Oct
(46) |
Nov
(13) |
Dec
(5) |
| 2010 |
Jan
(21) |
Feb
(3) |
Mar
(2) |
Apr
(7) |
May
(1) |
Jun
(26) |
Jul
(3) |
Aug
(10) |
Sep
(13) |
Oct
(35) |
Nov
(10) |
Dec
(17) |
| 2011 |
Jan
(26) |
Feb
(27) |
Mar
(14) |
Apr
(32) |
May
(8) |
Jun
(11) |
Jul
(4) |
Aug
(7) |
Sep
(27) |
Oct
(25) |
Nov
(7) |
Dec
(2) |
| 2012 |
Jan
(20) |
Feb
(17) |
Mar
(59) |
Apr
(31) |
May
|
Jun
(6) |
Jul
(7) |
Aug
(10) |
Sep
(11) |
Oct
(2) |
Nov
(4) |
Dec
(17) |
| 2013 |
Jan
(17) |
Feb
(2) |
Mar
(3) |
Apr
(4) |
May
(8) |
Jun
(3) |
Jul
(2) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
| 2014 |
Jan
(6) |
Feb
(26) |
Mar
(12) |
Apr
(14) |
May
(8) |
Jun
(7) |
Jul
(6) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(9) |
Feb
(5) |
Mar
(4) |
Apr
(9) |
May
(3) |
Jun
(2) |
Jul
(4) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(3) |
| 2016 |
Jan
(2) |
Feb
(4) |
Mar
(5) |
Apr
(4) |
May
(14) |
Jun
(31) |
Jul
(18) |
Aug
|
Sep
(10) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
(39) |
Feb
(5) |
Mar
(2) |
Apr
|
May
(52) |
Jun
(11) |
Jul
(36) |
Aug
(1) |
Sep
(7) |
Oct
(4) |
Nov
(10) |
Dec
(8) |
| 2018 |
Jan
(3) |
Feb
(4) |
Mar
|
Apr
(8) |
May
(28) |
Jun
(11) |
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(25) |
| 2019 |
Jan
(12) |
Feb
(50) |
Mar
(14) |
Apr
(3) |
May
(8) |
Jun
(17) |
Jul
(10) |
Aug
(2) |
Sep
(21) |
Oct
(10) |
Nov
|
Dec
(28) |
| 2020 |
Jan
(4) |
Feb
(10) |
Mar
(7) |
Apr
(16) |
May
(10) |
Jun
(7) |
Jul
(2) |
Aug
(5) |
Sep
(3) |
Oct
(3) |
Nov
(2) |
Dec
(1) |
| 2021 |
Jan
|
Feb
(5) |
Mar
(13) |
Apr
(13) |
May
(7) |
Jun
|
Jul
(1) |
Aug
(11) |
Sep
(12) |
Oct
(7) |
Nov
(26) |
Dec
(41) |
| 2022 |
Jan
(23) |
Feb
|
Mar
(8) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(1) |
Dec
(1) |
| 2023 |
Jan
|
Feb
(5) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(11) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
| 2024 |
Jan
(2) |
Feb
(4) |
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(10) |
Dec
|
| 2025 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(17) |
Jul
(1) |
Aug
(4) |
Sep
(7) |
Oct
(1) |
Nov
(9) |
Dec
|
|
From: Nils T. <nil...@gm...> - 2015-01-15 23:13:10
|
Hi, because of bug #235 I'm trying to understand how the LV2 Plugin works. I'm a wannabe programmer but maybe I have found two things. 1. The function LV2_State_Status Restore() has the parameter flags in PluginLv2.h but rflags in .cpp. I think that's a typo?! Why is there actually a flags parameter when we want to retrieve it afterwards (or rflags when we don't use it). 2. LV2_State_Status Save() stores NS_LS "state-file" with flag LV2_STATE_IS_PORTABLE but http://lv2plug.in/doc/html/state_8h.html#afb5cc1033410d51fdcdbfdd09fc7d808 says "Portable values MUST NOT contain filenames." And two questions: 1. Why don't we store the absolute path? http://lv2plug.in/ns/ext/atom/#Path --> "effectively any Path sent to or received from a plugin instance MUST be absolute." 2. Why are the old MapPath and MakePath restored after saving and restoring the state? Best regards, Nils |
|
From: Benoît G. <ben...@gm...> - 2014-09-29 11:26:44
|
Index: RTMath.cpp
===================================================================
--- RTMath.cpp (revision 2676)
+++ RTMath.cpp (working copy)
@@ -22,6 +22,9 @@
***************************************************************************/
#include "RTMath.h"
+#if defined(__arm__)
+#include <time.h>
+#endif
static float CentsToFreqTable[CONFIG_MAX_PITCH * 1200 * 2 + 1]; // +-1200 cents per octave
@@ -71,6 +74,11 @@
return t;
#elif defined(__APPLE__)
return GetMachTime();
+ #elif defined(__arm__)
+ timespec tp;
+ clock_gettime(CLOCK_MONOTONIC, &tp);
+ return tp.tv_nsec;
+
#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!" |
|
From: raf <rmo...@gm...> - 2014-09-29 10:33:50
|
Hello, you can send the diff for the two files here, Christian should grab them one day. what project are you working on ? (i'm interstingly curious) Raphaël 06 89 85 58 81 http://www.jerashmusic.fr Le 26 sept. 2014 à 17:56, Benoît Guchet <ben...@gm...> a écrit : > Hi, > > I made a working fix for LinuxSampler to support ARM11 processors. > Only 2 files changed. > How could I submit it, so that somebody can review it and/or commit it? Here? On Bugzilla? > > Many thanks! > BG > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Benoît G. <ben...@gm...> - 2014-09-26 15:56:43
|
Hi, I made a working fix for LinuxSampler to support ARM11 processors. Only 2 files changed. How could I submit it, so that somebody can review it and/or commit it? Here? On Bugzilla? Many thanks! BG |
|
From: Christian S. <sch...@li...> - 2014-08-25 10:47:57
|
On Monday 25 August 2014 09:55:28 you wrote: > Hi Christian > thanx for your last answer, it did the tricks. > > Still I get some sounds problems which now correlated with this message > > >Disk stream not available in time > > Would you have any tips to avoid these ? Did you change the default settings for max. disk streams and max. voices? The default values for "max. voices" are 64 voices and for "max. disk streams" 90 disk streams. With those default values you can even use ancient and lame hardware without getting into the issue you pasted above, i.e. a 15 years old PC would work fine. Or is that some extremely weak ARM board or something you are using? CU Christian |
|
From: Christian S. <sch...@li...> - 2014-08-24 16:53:55
|
On Sunday 24 August 2014 03:01:12 dwe...@gm... wrote: > Hi all, > Using linuxsampler with alsa driver I encounter glitchs which I suppose > are related to buffer_size > but while trying to tune it with following > > >SET AUDIO_OUTPUT_DEVICE_PARAMETER 0 FRAGMENTSIZE=1024 > > LS answers > > >Device parameter is read only You can provide the fragment size when you create the ALSA audio device, like this: CREATE AUDIO_OUTPUT_DEVICE ALSA FRAGMENTSIZE=1024 CU Christian |
|
From: <dwe...@gm...> - 2014-08-24 01:01:21
|
Hi all, Using linuxsampler with alsa driver I encounter glitchs which I suppose are related to buffer_size but while trying to tune it with following >SET AUDIO_OUTPUT_DEVICE_PARAMETER 0 FRAGMENTSIZE=1024 LS answers >Device parameter is read only but this does not seems to be hardcoded in alsa drivers itself, as if I check $ cat /proc/asound/M66/pcm0p/sub0/* while running "aplay" I get the following $ format: S32_LE $ subformat: STD $ channels: 10 $ rate: 48000 (48000/1) $ period_size: 1024 $ buffer_size: 6553 but while running "linuxsampler" it goes back to smaller value and reported as "read only" $ format: S32_LE $ subformat: STD $ channels: 10 $ rate: 44100 (44100/1) $ period_size: 128 $ buffer_size: 256 So it should be possible some how to modify this parameter I suspect LS implementation of alsa API does not enables tuning of these parameters. Am I right ? If so would anyone would have any suggestion to fix this ? I run a debian with kernel 3.2.0-4-amd64, an MAUDIO 66, with LS svn source from 1st of June Thanx a tons for your help BTW linuxsampler rocks a lot, I can now play rhodes and grand piano on my Venom ... event if it glitches a bit :) |
|
From: Christian S. <sch...@li...> - 2014-08-15 13:39:20
|
On Wednesday 13 August 2014 21:23:51 Holger Marzen wrote: > However, I don't need any LADSPA plugins withing Linuxsampler and would > like to disable this part of Linuxsampler. But there is no > ./configure-option to disable it. Where should I start? There is in fact no configure parameter yet to disable LADSPA support explicitly. Seems not many needed it so far. So stick with the suggested quick and dirty patch, or if you want to fix it in configure.ac by yourself, your patch would be appreciated. CU Christian |
|
From: Holger M. <ho...@ma...> - 2014-08-13 20:40:06
|
I did a quick'n'dirty patch:
--- ./src/effects/LadspaEffect.cpp.orig 2014-08-13 22:37:11.623392733 +0200
+++ ./src/effects/LadspaEffect.cpp 2014-08-13 22:25:34.552406957 +0200
@@ -376,7 +376,8 @@
std::vector<EffectInfo*> v; // will be filled in callback function _foundLadspaDll()
char* pcLadspaPath = getenv("LADSPA_PATH");
- String ladspaDir = pcLadspaPath ? pcLadspaPath : defaultLadspaDir();
+ //String ladspaDir = pcLadspaPath ? pcLadspaPath : defaultLadspaDir();
+ String ladspaDir = ""; /* -hm- */
std::istringstream ss(ladspaDir);
std::string path;
|
|
From: Holger M. <ho...@ma...> - 2014-08-13 19:24:05
|
Hi all, I use linuxsampler built from source revision 2593. It works ok but when I select the sfz engine it spills out a lot of messages about one of the many LADSPA plugins. This could prevent Qtractor loading my session until Qtractor's author improved catching stdout messages. However, I don't need any LADSPA plugins withing Linuxsampler and would like to disable this part of Linuxsampler. But there is no ./configure-option to disable it. Where should I start? Regards Holger Linuxsamplers output when selecting the sfz engine: LinuxSampler 1.0.0.svn41 Copyright (C) 2003,2004 by Benno Senoner and Christian Schoenebeck Copyright (C) 2005-2014 Christian Schoenebeck Detected features: MMX SSE SSE2 Automatic Stacktrace: Off Creating Sampler...OK Registered sampler engines: 'GIG','SF2','SFZ' Registered MIDI input drivers: ALSA,JACK Registered audio output drivers: ALSA,JACK Loading instrument editor plugins...OK Registered instrument editors: 'gigedit' Registered internal effect systems: LADSPA Registered internal effects: 210 Starting LSCP network server (0.0.0.0:8888)...OK LinuxSampler initialization completed. :-) LSCPServer: Client connection established on socket:4. LSCPServer: Client connection established on socket:5. No audio output device connected to sampler channel ALSA lib pcm_hw.c:1401:(_snd_pcm_hw_open) Invalid value for card ALSA lib pcm_hw.c:1401:(_snd_pcm_hw_open) Invalid value for card libjackBufferSizeCallback(512) Thread: WARNING, can't assign realtime scheduling to thread! Starting disk thread...OK EQ support: no Stopping disk thread...OK Starting disk thread...OK Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. EQ support: Triple band parametric with shelves Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Instantiating LADSPA effect 'triplePara'. LADSPA effect 'triplePara' activated. Stopping disk thread...OK |
|
From: Christian S. <sch...@li...> - 2014-07-21 10:18:54
|
On Saturday 19 July 2014 20:51:08 Dan MacDonald wrote: > How complete is LS SF2 support? All that I've been able to see on the > website is that SF2 is partly supported and doesn't support articulations > yet. Yes, the SF2 engine is currently in a quite orphaned state. It was added by Grigor, but nobody actually worked on this engine/format for quite a while now. I am personally not so interested in working on it actively ATM, since the Giga and SFZ formats are much more powerful than SF2. > Should soundfont support be working well enough to have 8 or so instances > of the VST plugin all using a FluidR3 instrument, presuming a moderately > powerful, stable machine/OS to run it on is present or is SF2 support (as a > LinuxVST) still alpha? Consider it alpha. And since I currently don't see anybody working on it, I don't expect this to change in near future. CU Christian |
|
From: Dan M. <al...@gm...> - 2014-07-19 18:51:15
|
Hi Christian and LS devs How complete is LS SF2 support? All that I've been able to see on the website is that SF2 is partly supported and doesn't support articulations yet. I've been testing the standard FluidR3 soundfont that is in the Debuntu repos with LinuxSampler VST 1.0.0.svn41 (KXStudio package) under Ubuntu 12.04.4 and Tracktion 5.3.9 and I have so far managed to run 3 instances before the plugin starts to crash. I'm not sure the number of instances is relevant. Under qsampler, I'm seeing lots of this: sf2: initialFilterFc is above the maximum allowed value (max=13500): 65180 sf2: initialFilterFc is above the maximum allowed value (max=13500): 63452 sf2: sustainModEnv is below the minimum allowed value (min=0): -920 sf2: sustainVolEnv is below the minimum allowed value (min=0): -1000 sf2: freqModLfo is above the maximum allowed value (max=4500): 5200 sf2: sustainModEnv is below the minimum allowed value (min=0): -653 sf2: sustainVolEnv is below the minimum allowed value (min=0): -975 sf2: initialFilterFc is above the maximum allowed value (max=13500): 63848 sf2: pan is below the minimum allowed value (min=-500): -1000 sf2: pan is above the maximum allowed value (max=500): 1000 sf2: holdModEnv is above the maximum allowed value (max=5000): 8250 sf2: decayModEnv is above the maximum allowed value (max=8000): 12000 sf2: sustainModEnv is below the minimum allowed value (min=0): -842 sf2: initialFilterFc is above the maximum allowed value (max=13500): 65336 sf2: sustainModEnv is below the minimum allowed value (min=0): -40 sf2: initialFilterFc is above the maximum allowed value (max=13500): 65336 sf2: sustainModEnv is below the minimum allowed value (min=0): -40 sf2: attackVolEnv is above the maximum allowed value (max=8000): 9948 sf2: initialFilterFc is above the maximum allowed value (max=13500): 63848 sf2: delayVolEnv is above the maximum allowed value (max=5000): 6750 sf2: attackVolEnv is above the maximum allowed value (max=8000): 10350 sf2: initialFilterFc is above the maximum allowed value (max=13500): 64692 sf2: initialFilterFc is above the maximum allowed value (max=13500): 62750 sf2: delayModLfo is above the maximum allowed value (max=5000): 11262 sf2: sustainModEnv is below the minimum allowed value (min=0): -377 sf2: initialFilterFc is above the maximum allowed value (max=13500): 63393 sf2: initialFilterFc is above the maximum allowed value (max=13500): 63848 sf2: initialFilterFc is above the maximum allowed value (max=13500): 64404 sf2: delayVolEnv is above the maximum allowed value (max=5000): 11916 sf2: delayModEnv is above the maximum allowed value (max=5000): 12000 sf2: delayVolEnv is above the maximum allowed value (max=5000): 12000 sf2: initialFilterFc is above the maximum allowed value (max=13500): 65354 sf2: initialFilterFc is above the maximum allowed value (max=13500): 65150 and the occasional 19:21:22.188 Channel 1 lscp_set_channel_audio_device: The audio output device 'Plugin' cannot be dropped from this sampler channel! (errno=100) 19:21:22.191 Channel 1 lscp_set_channel_midi_device: The MIDI input port 'Plugin' cannot be altered on this sampler channel! (errno=100) 19:21:22.193 Channel 1 Instrument: "/usr/share/sounds/sf2/FluidR3_GM.sf2" (2). 19:21:22.195 Channel 1 MIDI map: 0. 19:21:22.197 Channel 1 Some channel settings could not be set. Sorry. 19:21:25.132 Channel 1 setup... I've yet to try the latest svn version but looking at the changelogs of the versions since I can't see anything relating to good ol' SF2 support. Should soundfont support be working well enough to have 8 or so instances of the VST plugin all using a FluidR3 instrument, presuming a moderately powerful, stable machine/OS to run it on is present or is SF2 support (as a LinuxVST) still alpha? : Thanks! Dan |
|
From: Christian S. <sch...@li...> - 2014-07-08 11:38:02
|
On Tuesday 08 July 2014 10:06:08 Nils Tonnätt wrote: > Thank you for your help! Should I use the same revision for libgig? I > see that there is instrument scripting at revision 2584. For all other ones you should be fine using latest SVN revision instead. Even though latest libgig versions add instrument scripting support as well, those changes in libgig are just executed when you explicitly use the instrument scripting feature. CU Christian |
|
From: Nils T. <nil...@gm...> - 2014-07-08 08:06:17
|
Thank you for your help! Should I use the same revision for libgig? I see that there is instrument scripting at revision 2584. -- Nils Am 04.07.2014 11:54, schrieb Christian Schoenebeck: > On Thursday 03 July 2014 14:30:13 Nils Tonnätt wrote: >> Hi, >> I wonder what the latest svn commit is with that I could expect a >> relative stable version of linuxsampler etc. >> Maybe some experts of the code could help me with that. > r2593 should be a good candidate. That's the last revision just before the > instrument script feature was integrated into the sampler engines. That new > feature required a lot of changes which currently needs to be ironed out. > > CU > Christian > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Christian S. <sch...@li...> - 2014-07-04 10:48:14
|
On Thursday 03 July 2014 14:30:13 Nils Tonnätt wrote: > Hi, > I wonder what the latest svn commit is with that I could expect a > relative stable version of linuxsampler etc. > Maybe some experts of the code could help me with that. r2593 should be a good candidate. That's the last revision just before the instrument script feature was integrated into the sampler engines. That new feature required a lot of changes which currently needs to be ironed out. CU Christian |
|
From: Nils T. <nil...@gm...> - 2014-07-03 12:30:22
|
Hi, I wonder what the latest svn commit is with that I could expect a relative stable version of linuxsampler etc. Maybe some experts of the code could help me with that. Best regards, Nils Tonnätt |
|
From: Holger M. <ho...@ma...> - 2014-06-27 12:57:24
|
On Fri, 27 Jun 2014, Christian Schoenebeck wrote:
> seq_* opcodes seems to define "round robin" selection for regions in the SFZ
> format. I just had a short look at current SFZ code, and as far as I could see
> it right now, round robin selection in the SFZ engine could indeed be buggy.
>
> bool Region::OnKey(const Query& q) [src/engines/sfz/sfz.cpp]
>
> is called by the SFZ engine on each region, when a new note was triggered, to
> check which region shall be used and played. However that method ATM assumes
> to be called only once and due to this increments the round robin counter at
> the end of its call. The SFZ engine however calls this in a while loop:
>
> while (::sfz::Region* region = q.next()) {
> [src/engines/sfz/Engine.cpp, line 110]
>
> which seems to cause the misbehavior you encountered. That is, that it falsely
> also triggers the 2nd region you have there at the same time.
I made a soundfont with 2 different (in frequency) samples, so I could
hear if both samples are played together instead alternating. It didn't
happen. They were never played together. So this bug candidate doesn't
seem to be one.
I investigated the sound font some more. The clicking sample was
different compared to the others: it lacked loop information in the
wav-header. Since there wasn't any loop_start/loop_end in the sfz-file
linuxsampler probably used the defaults 0/0. Could be a reason for the
occasional klicks.
Another "bug" in the soundfont could be the release sound:
ampeg_decay=37
loop_mode=one_shot
trigger=release
One_shot mode together with a very long decay could possibly lead to
voice-stealing, another possible source of occasional klicks.
TL;DR
-----
After fixing the soundfont I have now much better results.
|
|
From: Christian S. <sch...@li...> - 2014-06-27 10:52:07
|
On Thursday 26 June 2014 19:49:21 Holger Marzen wrote:
> I tested some more. The sfz-file begins with:
>
> <group>
> seq_length=2
> ampeg_decay=37
> ampeg_sustain=0.001
> ampeg_release=0.4
> loop_mode=loop_continuous
> <region>
> sample=1_E_a.wav
> lokey=0 hikey=28
> [...]
>
> I noticed that if I set seq_length=1 the clicks don't happen.
>
> The clicks only happen when
> - seq_length=2
> - the same note gets play twice, so that it cycles through the 2 samples
>
> Is this a known bug? Is there a workaround by changing some parms in the
> sfz-file?
I am not an SFZ expert, so maybe Andreas or Grigor can comment better on it.
seq_* opcodes seems to define "round robin" selection for regions in the SFZ
format. I just had a short look at current SFZ code, and as far as I could see
it right now, round robin selection in the SFZ engine could indeed be buggy.
bool Region::OnKey(const Query& q) [src/engines/sfz/sfz.cpp]
is called by the SFZ engine on each region, when a new note was triggered, to
check which region shall be used and played. However that method ATM assumes
to be called only once and due to this increments the round robin counter at
the end of its call. The SFZ engine however calls this in a while loop:
while (::sfz::Region* region = q.next()) {
[src/engines/sfz/Engine.cpp, line 110]
which seems to cause the misbehavior you encountered. That is, that it falsely
also triggers the 2nd region you have there at the same time.
So IMO the round robin counter should be incremented after that loop, but not
inside Region::OnKey().
CU
Christian
|
|
From: Holger M. <ho...@ma...> - 2014-06-26 17:49:33
|
Hi all, I tested some more. The sfz-file begins with: <group> seq_length=2 ampeg_decay=37 ampeg_sustain=0.001 ampeg_release=0.4 loop_mode=loop_continuous <region> sample=1_E_a.wav lokey=0 hikey=28 [...] I noticed that if I set seq_length=1 the clicks don't happen. The clicks only happen when - seq_length=2 - the same note gets play twice, so that it cycles through the 2 samples Is this a known bug? Is there a workaround by changing some parms in the sfz-file? ---------- Forwarded message ---------- Date: Thu, 26 Jun 2014 19:09:52 +0200 (CEST) From: Holger Marzen <ho...@ma...> To: lin...@li... Subject: Occasional clicks at the beginning of the played sample Xubuntu 12.04 LTS, Kernels 3.5, 3.15-lowlatency and 3.14.3 with realtime patch 16 GB RAM, Core i5, SSD (desktop and notebook computer) linuxsampler svn 2482 (I also tried a recent one yesterday but it crashed) sfz engine used jack used Tested with linuxsampler standalone, linuxsampler-dssi and linuxsampler-lv2 I experience occasional clicks at the beginning of played notes, about one every 10-20 seconds, varying in their strength. It doesn't depend of the soundcard used. It happens even with the dummy sound device when playing a MIDI track with Rosegarden or Qtractor. I managed to catch twice the same note/sample, one deformed with click, one clean: http://www.marzen.de/tmp/click.jpg This is another one with click. It can be seen in the waveform: http://www.marzen.de/tmp/click2.jpg It seems that some samples simply get lost. It happens on both of my computers. There are no problems with JACK processing other audio, at least no that I ever noticed. I run out of ideas. This is a big problem for me because with occasional klicks when using linuxsampler I can't use my sfz-soundfonts for high quality recording. Any ideas? |
|
From: Holger M. <ho...@ma...> - 2014-06-26 17:10:02
|
Xubuntu 12.04 LTS, Kernels 3.5, 3.15-lowlatency and 3.14.3 with realtime patch 16 GB RAM, Core i5, SSD (desktop and notebook computer) linuxsampler svn 2482 (I also tried a recent one yesterday but it crashed) sfz engine used jack used Tested with linuxsampler standalone, linuxsampler-dssi and linuxsampler-lv2 I experience occasional clicks at the beginning of played notes, about one every 10-20 seconds, varying in their strength. It doesn't depend of the soundcard used. It happens even with the dummy sound device when playing a MIDI track with Rosegarden or Qtractor. I managed to catch twice the same note/sample, one deformed with click, one clean: http://www.marzen.de/tmp/click.jpg This is another one with click. It can be seen in the waveform: http://www.marzen.de/tmp/click2.jpg It seems that some samples simply get lost. It happens on both of my computers. There are no problems with JACK processing other audio, at least no that I ever noticed. I run out of ideas. This is a big problem for me because with occasional klicks when using linuxsampler I can't use my sfz-soundfonts for high quality recording. Any ideas? |
|
From: Christian S. <sch...@li...> - 2014-06-12 18:22:07
|
Hi! Does anybody know whether Kontakt's script "event groups" are sampler global event groups, or rather separate for each sampler part? Background: Kontakt has 3 script instrument functions which allow to group events together and let certain commands be executed on such entire groups in one rush. set_event_mark() adds an event to an event group/list delete_event_mark() deletes an event from an event group/list by_mark() can be used to dereference the individual events of an group, to be passed to i.e. note_off() with a single call Any hints very much appreciated! CU Christian |
|
From: Dan M. <al...@gm...> - 2014-06-09 20:53:59
|
This sounds like its going to be cool as once it stabilizes and sfz support gets added. Thanks for the update Christian! On Mon, Jun 9, 2014 at 8:35 PM, Christian Schoenebeck < sch...@li...> wrote: > Hi there! > > Some progress on the real-time instrument script front: > > > http://download.linuxsampler.org/pix/screenshots/gigedit_script_3b.jpg > > The first instruments scripts are finally running with the gig format > sampler > engine. In the screenshot you see an example script with gigedit's new > script > editor which fires new notes (with different samples than the main notes > were) > if the player exceeds a certain channel aftertouch limit. > > Current state: > > - The script language: if you worked with Kontakt before, then you > should be familiar with this script language right away. If not, > you > can have a look at the source directory src/scriptvm/examples > for some > basic core language script examples. The language is really easy. > > - Scripting feature is currently only working with the gig format > yet. I > added a LinuxSampler specific extension to the original Gig file > format > for storing instrument scripts to .gig files by using gigedit. > Obviously if you store scripts to gig files, they will not load > with > the original GigaStudio 4 software of course. > > - Adding scripting to the SFZ engine is easy. Involves probably > only > adding 10 lines of code or so. It probably just requires a new > opcode > for referencing script files. Since I am no expert regarding the > SFZ > format, I wait for others to come up with comments how to extend > the > SFZ file format with a new opcode. Or maybe some company already > introduced a scripting opcode, no idea. > > - gigedit does not yet transfer scripts to the sampler in > live-mode. That > is, each time you alter a script with gigedit, you have to force > the > sampler to reload the instrument with the new version of the > script. > > - gigedit's script editor is yet very very primitive. It has some > basic > keyword syntax highlighting, but that's pretty much it. My plan > was to > hook the editor up with the sampler's internal script parser, so > that > i.e. parser warnings, parser errors, keywords, variables, > built-in > variables and built-in functions are always marked up in the > editor > correctly (similar like today's C++ IDEs are hooked up with > clang). > Updating this with the sampler parser could be done in real-time > while > typing, because it parses instrument scripts in few milliseconds. > > - Scripts are handled with the gig format now similar to samples. > That is > scripts are stored in file global space, and you can then > reference > individual scripts from gig instruments. You do that by right > clicking > on an instrument in gigedit's instrument tree tab, then select > "Edit > script slots..." and drag a script from the new script tree tab > to the > script slots window of the instrument. Note that even though you > can > already create more than one script slot per instrument, > LinuxSampler > will currently only execute the 1st script slot of each > instrument yet. > If you create more than one slot, the sampler will show you a > warning > on the console when you load the scripted instrument. > > - Script suspension: the ScriptVM engine suspends your script from > execution if you call the buit-in "wait()" function. This > function > takes one argument which defines the sleep time in microseconds. > However the latter is not yet implemented in the sampler. The > script > will simply be resumed in the next audio cycle for now. > > Then scripts should be suspended automatically by the sampler if > they > executed too long and would thus threaten the sampler's real-time > requirements. I haven't implemented that either yet. The > question is > how should that decision be made exactly? Counting ScriptVM > instructions? Comparing real time stamps? Having said that, be > careful > when you write while loops in your scripts. If you write an > endless > loop in you script without wait() call, the sampler will > currently > hang forever. > > - String type variables in scripts: all string type operations are > *NOT* > real-time safe ATM! Use string variables and operations like > string > concatenation, cast from int to string and message() function > calls > just for debugging purposes of your script. Otherwise you might > get > dropouts. You can use the preprocessor feature to switch your > scripts > from debug to normal mode. So if you pack your string variables > and > operations into appropriate preprocessor statements, you can > enable/disable all of them at any time by changing just one line. > > I wonder how Kontakt addresses strings. Whether they are > real-time > safe? Not sure if its worth it to address this issue at all. > > - Built-in script functions and variables: The plan is to > implement all > functions and variables regarding MIDI processing which you might > already know from the mentioned sampler. I am personally not > interested > in implementing the ui_* set of functions right now. > > I made some of the functions not as strict as in Kontakt. That > is, many > functions will accept a variable amount of arguments. For example > you can also use the play_note() function with only two > arguments. For > the remaining arguments, the sampler will simply used default > values > (if it makes sense, depends on the function of course). > > Additionally I started to add the first gig format specific > variables > and functions, which you can also find in the screenshot. They > are > required to deal with the special features of the gig format by > script. > > - ls_instr_script: This is a new command line tool. I basically > used it > for debugging the parser. You can pipe in instrument scripts > (or copy > paste it), it will parse them, show you any parser errors, > warnings in > ... now hold your breath ... *in* *color* ... wooow ;-). > > And if you are running the tool in "core" language mode, you can > even > execute the scripts from the command line. You might use this > probably > sometimes until i.e. gigedit script editor is hooked up with the > samplers script parser one day. Or maybe not ;-) Thats up to you. > > If it it's not yet clear to you already: this is *bloody* *bleeding* *edge* > yet. Backup your files, expect crashes, grab you life vest, etc. > > David, sorry that I decided for another route. But Andreas had already some > basic KSP Bison parser hanging around on his disk, so it was too tempting > to > pickup his Bison approach for this scripting feature. ;-) > > Questions, comments? > > CU > Christian > > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > |
|
From: Christian S. <sch...@li...> - 2014-06-09 20:30:05
|
Hi there! Some progress on the real-time instrument script front: http://download.linuxsampler.org/pix/screenshots/gigedit_script_3b.jpg The first instruments scripts are finally running with the gig format sampler engine. In the screenshot you see an example script with gigedit's new script editor which fires new notes (with different samples than the main notes were) if the player exceeds a certain channel aftertouch limit. Current state: - The script language: if you worked with Kontakt before, then you should be familiar with this script language right away. If not, you can have a look at the source directory src/scriptvm/examples for some basic core language script examples. The language is really easy. - Scripting feature is currently only working with the gig format yet. I added a LinuxSampler specific extension to the original Gig file format for storing instrument scripts to .gig files by using gigedit. Obviously if you store scripts to gig files, they will not load with the original GigaStudio 4 software of course. - Adding scripting to the SFZ engine is easy. Involves probably only adding 10 lines of code or so. It probably just requires a new opcode for referencing script files. Since I am no expert regarding the SFZ format, I wait for others to come up with comments how to extend the SFZ file format with a new opcode. Or maybe some company already introduced a scripting opcode, no idea. - gigedit does not yet transfer scripts to the sampler in live-mode. That is, each time you alter a script with gigedit, you have to force the sampler to reload the instrument with the new version of the script. - gigedit's script editor is yet very very primitive. It has some basic keyword syntax highlighting, but that's pretty much it. My plan was to hook the editor up with the sampler's internal script parser, so that i.e. parser warnings, parser errors, keywords, variables, built-in variables and built-in functions are always marked up in the editor correctly (similar like today's C++ IDEs are hooked up with clang). Updating this with the sampler parser could be done in real-time while typing, because it parses instrument scripts in few milliseconds. - Scripts are handled with the gig format now similar to samples. That is scripts are stored in file global space, and you can then reference individual scripts from gig instruments. You do that by right clicking on an instrument in gigedit's instrument tree tab, then select "Edit script slots..." and drag a script from the new script tree tab to the script slots window of the instrument. Note that even though you can already create more than one script slot per instrument, LinuxSampler will currently only execute the 1st script slot of each instrument yet. If you create more than one slot, the sampler will show you a warning on the console when you load the scripted instrument. - Script suspension: the ScriptVM engine suspends your script from execution if you call the buit-in "wait()" function. This function takes one argument which defines the sleep time in microseconds. However the latter is not yet implemented in the sampler. The script will simply be resumed in the next audio cycle for now. Then scripts should be suspended automatically by the sampler if they executed too long and would thus threaten the sampler's real-time requirements. I haven't implemented that either yet. The question is how should that decision be made exactly? Counting ScriptVM instructions? Comparing real time stamps? Having said that, be careful when you write while loops in your scripts. If you write an endless loop in you script without wait() call, the sampler will currently hang forever. - String type variables in scripts: all string type operations are *NOT* real-time safe ATM! Use string variables and operations like string concatenation, cast from int to string and message() function calls just for debugging purposes of your script. Otherwise you might get dropouts. You can use the preprocessor feature to switch your scripts from debug to normal mode. So if you pack your string variables and operations into appropriate preprocessor statements, you can enable/disable all of them at any time by changing just one line. I wonder how Kontakt addresses strings. Whether they are real-time safe? Not sure if its worth it to address this issue at all. - Built-in script functions and variables: The plan is to implement all functions and variables regarding MIDI processing which you might already know from the mentioned sampler. I am personally not interested in implementing the ui_* set of functions right now. I made some of the functions not as strict as in Kontakt. That is, many functions will accept a variable amount of arguments. For example you can also use the play_note() function with only two arguments. For the remaining arguments, the sampler will simply used default values (if it makes sense, depends on the function of course). Additionally I started to add the first gig format specific variables and functions, which you can also find in the screenshot. They are required to deal with the special features of the gig format by script. - ls_instr_script: This is a new command line tool. I basically used it for debugging the parser. You can pipe in instrument scripts (or copy paste it), it will parse them, show you any parser errors, warnings in ... now hold your breath ... *in* *color* ... wooow ;-). And if you are running the tool in "core" language mode, you can even execute the scripts from the command line. You might use this probably sometimes until i.e. gigedit script editor is hooked up with the samplers script parser one day. Or maybe not ;-) Thats up to you. If it it's not yet clear to you already: this is *bloody* *bleeding* *edge* yet. Backup your files, expect crashes, grab you life vest, etc. David, sorry that I decided for another route. But Andreas had already some basic KSP Bison parser hanging around on his disk, so it was too tempting to pickup his Bison approach for this scripting feature. ;-) Questions, comments? CU Christian |
|
From: Christian S. <sch...@li...> - 2014-05-23 19:06:07
|
On Friday 23 May 2014 10:54:50 David Olofson wrote: > > One thing I find suboptimal with KSP is that it is very focused on using > > function calls all over the place. > > Yeah, functions with umpteen arguments get old... Then again, I'm not > generally a big fan of overly verbose code either. Named arguments? An > editor that automatically shows the argument names of the function at > hand in the status bar or similar? Yeah, I also though about named arguments for function calls. But I decided to completely stick with Kontakt's KSP language now (plus some additional builtin functions we need), since I also haven't heard any complaints here about my suggestion to make it based on Kontakt's KSP language. I found the compatibility aspect much more important than personal opinions about the precise "look" of the script language. So I will start by implementing the MIDI processing part of the KSP language. The UI part of the language are not so important for me ATM, so I will skip them for now. > > In this case such a "polyphonic" variable is not shared, it is bound to > > the event which triggered the callback function. So no other instance of > > the same callback can modify variable $i in between, preventing you from > > any trouble. However from memory management point of view this case is a > > bit problematic. Because you have no information at parse time how many > > instances of the callback might be triggered in parallel. I am not sure > > what the best solution would be to implement this case (from memory > > management POV). Do you have a solid idea? > > This is where realtime programming gets real hairy... Again, it would > seem like the "easy" route was taken with KSP, and it's not truly > dynamic (that is, all structures, variables etc are allocated and > initialized as an instrument is loaded), except that the 'polyphonic' > keyword somehow sets up pools or arrays of "sufficient" size for > polyphonic action. Regarding memory management, I planned to do the same, that is allocating all data when the script is loaded. For the "polyphonic" variables I will probably allocate and stick the memory to the respective LS internal Event object. But also done at load time. For RT safety reasons I simply want to avoid any memory allocation while actually playing the instrument. > In hardware synths, there's usually a fixed number of voices, > traditionally because the voices were physically built into the > hardware, and in more recent designs, because of (relatively speaking) > very tight CPU power and memory budgets. In some cases (like the old > JV-1080), you can manually split the voice pool across parts to manage > voice stealing issues, but with a soft synth/sampler these days, you > can probably get away with just pre-allocating a few hundred voices, > with polyphonic variables and whatnot that goes with them, and be done > with it. I've noticed proprietary software synths and samplers still > tend to have hard limits on channels, voices etc, and this might be > the main reason for that... Yes. Memory allocation at runtime is always a threat to RT stability. LS is also allocating a fixed amount of voices. You can adjust that amount of voices of course at any time, but unless the user change the amount explicitly, they will be constant at a certain value. So memory allocation and its RT stability danger is one reason for that, and the other reason is of course that you have limited set of resources on you system (CPU power, HD speed, ..). So once that user defined voice limit is reached the voice stealing algorithm kicks in to keep the side effect of limited voices to a minimum. You might let the sampler auto detect some kind of maximum amount of voices, however sometimes you also want to leave some head room for other applications, which the sampler would not be able to understand on its own of course. > It has crossed my mind to hardwire TLSF or similar into EEL, but there > are downsides to a realtime memory manager when you don't really need > one, and existing realtime OSes and application often have their own > custom memory managers already, so it might be better to plug into > those. > > >> but that's basically how > >> to go about it; write an alternative compiler that issues bytecode for > >> an existing VM. A VM like this is basically just a high level virtual > >> CPU, and not really tied to any specific language. > > > > Probably, but in fact I would like to avoid opening the door for numerous > > flavors of high level script languages used in the sampler right now. > > Because it might create confusion among users when learning scripting > > with the sampler and/or by reading scripts of other people, if everybody > > is using a different language on top that is. So I would prefer to pick > > one single language flavor that should remain alone in this flavor (for > > quite some time at least). > > Yes... Choice is good - but most people don't know what to choose, or why. > :-D Well, the main use case for this script languages are not die hard coders, but rather sound designers. Many if not most of them are not too keen to deal with scripts at all, but expecting them to learn yet another language is probably too much expected. At least Kontakt's script language is well known to anybody who works with samplers and there are already plenty of easy to understand video tutorials, written howtos, free scripts on the net (and commercial script packages to be purchased) ready to be used. So better we stick with that now. So if somebody has some doubts, complaints, other suggestions, better raise your word now, before it will be too late! ;-) CU Christian |
|
From: David O. <da...@ol...> - 2014-05-23 08:55:02
|
On Thu, May 22, 2014 at 8:21 PM, Christian Schoenebeck
<sch...@li...> wrote:
[...]
> One thing I find suboptimal with KSP is that it is very focused on using
> function calls all over the place.
[...]
Yeah, functions with umpteen arguments get old... Then again, I'm not
generally a big fan of overly verbose code either. Named arguments? An
editor that automatically shows the argument names of the function at
hand in the status bar or similar?
> would probably be more intuitive and easier to remember. Modifying incoming
> MIDI events is also a bit odd, with KSP it is like this:
>
> on note
> if ($EVENT_VELOCITY > 100)
> ignore_event($EVENT)
> else
> change_note($EVENT, $EVENT_NOTE + 12)
> change_velo($EVENT, $EVENT_VELOCITY / 2)
> end if
> end
>
> which IMO I would found more intuitive like:
>
> on note
> if ($NOTE.velocity > 100)
> $NOTE.ignore()
> else
> $NOTE.note += 12
> $NOTE.velocity /= 2
> end if
> end
[...]
The latter needs either a proper type system with structs, classes or
similar, or run-time indexing by "name" (typically immutable strings),
both of which are quite complicated to do well with good performance.
This suggests that they took the easy route with KSP and just made
"everything a variable," resolved at compile time (performance is not
critical) by means of a one-dimensional non-nested symbol table.
So, the latter is much nicer, but TANSTAAFL. :-)
[...]
> In this case such a "polyphonic" variable is not shared, it is bound to the
> event which triggered the callback function. So no other instance of the same
> callback can modify variable $i in between, preventing you from any trouble.
> However from memory management point of view this case is a bit problematic.
> Because you have no information at parse time how many instances of the
> callback might be triggered in parallel. I am not sure what the best solution
> would be to implement this case (from memory management POV). Do you have a
> solid idea?
This is where realtime programming gets real hairy... Again, it would
seem like the "easy" route was taken with KSP, and it's not truly
dynamic (that is, all structures, variables etc are allocated and
initialized as an instrument is loaded), except that the 'polyphonic'
keyword somehow sets up pools or arrays of "sufficient" size for
polyphonic action.
In hardware synths, there's usually a fixed number of voices,
traditionally because the voices were physically built into the
hardware, and in more recent designs, because of (relatively speaking)
very tight CPU power and memory budgets. In some cases (like the old
JV-1080), you can manually split the voice pool across parts to manage
voice stealing issues, but with a soft synth/sampler these days, you
can probably get away with just pre-allocating a few hundred voices,
with polyphonic variables and whatnot that goes with them, and be done
with it. I've noticed proprietary software synths and samplers still
tend to have hard limits on channels, voices etc, and this might be
the main reason for that...
With EEL, I decided to go fully dynamic, so there are no special cases
for things like this. There are static variables (allocated per
module, and shared within the module instance) and local (VM stack)
variables that work like stack variables in C. If you want per-channel
or per-note data, you just design your objects like that, OOP style.
(EEL is really a generic programming language, not designed for any
specific type of applications, apart from the requirement of being
"realtime safe".)
So, there is full dynamic memory management in the core of the
language (call stack, arrays, tables, custom classes etc), and if you
want it all hard realtime, you should plug in a suitable memory
manager instead of malloc()/realloc()/free(), like TLSF:
http://www.gii.upv.es/tlsf/
It has crossed my mind to hardwire TLSF or similar into EEL, but there
are downsides to a realtime memory manager when you don't really need
one, and existing realtime OSes and application often have their own
custom memory managers already, so it might be better to plug into
those.
>> but that's basically how
>> to go about it; write an alternative compiler that issues bytecode for
>> an existing VM. A VM like this is basically just a high level virtual
>> CPU, and not really tied to any specific language.
>
> Probably, but in fact I would like to avoid opening the door for numerous
> flavors of high level script languages used in the sampler right now. Because
> it might create confusion among users when learning scripting with the sampler
> and/or by reading scripts of other people, if everybody is using a different
> language on top that is. So I would prefer to pick one single language flavor
> that should remain alone in this flavor (for quite some time at least).
Yes... Choice is good - but most people don't know what to choose, or why. :-D
>> EEL exists mostly because I couldn't find anything like it. I looked
>> into subverting Lua to suit my needs (replacing the GC, most
>> critically), but the Lua community showed virtually no interest in it
>> (not really needed, even for <100 Hz game scripting), so I would have
>> been completely on my own with it - and I'd rather be in that
>> situation with code that I know inside out.
>
> Yes, I saw you went a bit deeper with EEL than what we probably need to
> achieve right now. From what you saw above, the typical use case for the
> script language in a sampler is event handling once in a while. Not at high
> frequencies. You are even defining tight DSP stuff with EEL if I saw it
> correctly. That's already beyond the scope what we need right now.
Well, I've tried to make EEL about as fast as possible without (so
far) compiling to native code - but that's more or less unrelated to
the realtime aspect. As long as you run scripts in the audio thread, a
scripting engine that occasionally does a GC cycle, rebuilds large
structures or hits unsafe system calls is going to cause trouble. Even
if you only use it once during a whole gig, that's one chance of it
causing an audio drop-out.
>> For something really simple, you could look at the Audiality 2
>> scripting engine (not physically related to EEL), but that's a small,
>> domain specific language that's somewhat tied to the design of the
>> audio engine. Apart from being massively microthreaded with message
>> passing, it's a really small and simple language.
>
> Why is it called "Extensible" by the way? What is the particular extensible
> aspect of EEL?
Host applications and native modules can inject custom classes that
work just like the built-in high level types; string, array, table
etc. Other than that, it's just the usual modular stuff that any real
programming language has these days. :-)
It's crossed my mind to support "plugins" of some sort in the
compiler, to support custom syntax extensions, but I'm not sure that's
a great idea... I'd rather just add nice, generally useful features to
the official language as needed instead - though I'm trying to keep
that to a minimum as well. Inspired by the Lua philosophy, that is,
but EEL is slightly less minimalistic.
--
//David Olofson - Consultant, Developer, Artist, Open Source Advocate
.--- Games, examples, libraries, scripting, sound, music, graphics ---.
| http://consulting.olofson.net http://olofsonarcade.com |
'---------------------------------------------------------------------'
|
161 messages has been excluded from this view by a project administrator.
