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
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jerash m. <rmo...@gm...> - 2022-08-01 13:53:44
|
Late reply, but minimum velocity release of 1 is also confirmed on many IK.multimedia keyboards ans korgs. Could never find a keyboard with 0 release velocity. Hope that helps. Raphaël Le mar. 11 janv. 2022 à 14:00, Christian Schoenebeck < sch...@li...> a écrit : > On Freitag, 7. Januar 2022 08:29:49 CET Doug Gray wrote: > > I've crawled around a number of product manuals and discovered a variety > of > > behaviours for note off. Some do send v=64 including some recent models > > (Casio Privia PXS series, Yamaha CP88, YC88 to name a few notables). > > On the other hand the Yamaha Arius ADP Series of console pianos send > > v=1-127, ie zero is not sent. I have verified this today myself on an > Arius > > ADP-164. > > Some older designs send a zero velocity, possibly the lower end of the > > spectrum of controllers such as the Masterkey49. > > Unfortunately the higher profile midi keyboards such as the Kawai(VPC-1), > > Native Instruments, Arturia don't share the detail in their product > > manuals, at least not that I could find. > > So not as definitive as I expected. > > Mmm, that's unfortunate. Thanks for the research though! > > For now I keep the current simple implementation (check for zero > velocity). In > future this should probably be changed to a MIDI learn mechanism and/or > checking for this feature according to MIDI v2. Again, haven't checked the > MIDI v2 specs yet, but I read somewhere they have added capability > negotiation. > > CU > Christian > > > > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > |
From: Rui N. C. <rn...@rn...> - 2022-04-02 11:20:26
|
Greetings, The first batch of the 'QStuff*' is ready: QjackCtl [1], Qsynth [2], Qsampler [3], QXGEdit [4], QmidiCtl [5] and QmidiNet [6], are all out for the (northern) Spring'22 season. ** QjackCtl - JACK Audio Connection Kit Qt GUI Interface [1] ** QjackCtl 0.9.7 (spring'22) released! QjackCtl is an aged yet modern, not so 'simple' anymore, Qt [7] application to control the JACK [8] sound server, for the Linux Audio [12] infrastructure. Change-log: - Main application icon is now presented in scalable format (SVG). - Migrated command line parsing to QCommandLineParser/Option (Qt >= 5.2) - Fixed translations path to be relative to application runtime. Website: https://qjackctl.sourceforge.io http://qjackctl.sourceforge.net Project page: https://sourceforge.net/projects/qjackctl Downloads: https://sourceforge.net/projects/qjackctl/files - source tarball: https://download.sf.net/qjackctl/qjackctl-0.9.7.tar.gz - source package: https://download.sf.net/qjackctl/qjackctl-0.9.7-51.2.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qjackctl/qjackctl-0.9.7-51.2.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qjackctl/qjackctl-0.9.7-51.2.x86_64.AppImage Git repos: https://git.code.sf.net/p/qjackctl/code https://github.com/rncbc/qjackctl.git https://gitlab.com/rncbc/qjackctl.git https://bitbucket.com/rncbc/qjackctl.git ** Qsynth - A FluidSynth Qt GUI Interface [2] ** Qsynth 0.9.7 (spring'22) released! Qsynth is a FluidSynth [10] GUI front-end application written in C++ around the Qt framework [7] using Qt Designer. Change-log: - Main application icon is now presented in scalable format (SVG). Website: https://qsynth.sourceforge.io http://qsynth.sourceforge.net Project page: https://sourceforge.net/projects/qsynth Downloads: https://sourceforge.net/projects/qsynth/files - source tarball: https://download.sf.net/qsynth/qsynth-0.9.7.tar.gz - source package: https://download.sf.net/qsynth/qsynth-0.9.7-51.4.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qsynth/qsynth-0.9.7-51.4.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qsynth/qsynth-0.9.7-51.4.x86_64.AppImage - Windows package (thanks to Pedro Lopez-Cabanillas): https://download.sf.net/qsynth/qsynth-0.9.7-51.4.win-x64-setup.exe - Flatpak [21] package (thanks again to Pedro Lopez-Cabanillas): https://flathub.org/apps/details/org.rncbc.qsynth Git repos: https://git.code.sf.net/p/qsynth/code https://github.com/rncbc/qsynth.git https://gitlab.com/rncbc/qsynth.git https://bitbucket.com/rncbc/qsynth.git ** Qsampler - A LinuxSampler Qt GUI Interface [3] ** Qsampler 0.9.6 (spring'22) released! Qsampler is a LinuxSampler [11] GUI front-end application written in C++ around the Qt framework [7] using Qt Designer. Change-log: - Main application icon is now presented in scalable format (SVG). - Migrated command line parsing to QCommandLineParser/Option (Qt >= 5.2) - Fixed translations path to be relative to application runtime. - liblscp: Install doxygen (doc/html) files again (via cmake). Website: https://qsampler.sourceforge.io http://qsampler.sourceforge.net Project page: https://sourceforge.net/projects/qsampler Downloads: https://sourceforge.net/projects/qsampler/files - source tarballs: https://download.sf.net/qsampler/qsampler-0.9.6.tar.gz https://download.sf.net/qsampler/liblscp-0.9.6.tar.gz - source packages: https://download.sf.net/qsampler/qsampler-0.9.6-50.2.rncbc.suse.src.rpm https://download.sf.net/qsampler/liblscp-0.9.6-50.1.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qsampler/qsampler-0.9.6-50.2.rncbc.suse.x86_64.rpm https://download.sf.net/qsampler/liblscp6-0.9.6-50.1.rncbc.suse.x86_64.rpm https://download.sf.net/qsampler/liblscp-devel-0.9.6-50.1.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qsampler/qsampler-0.9.6-50.2.x86_64.AppImage Git repos: https://git.code.sf.net/p/qsampler/code https://github.com/rncbc/qsampler.git https://gitlab.com/rncbc/qsampler.git https://bitbucket.com/rncbc/qsampler.git https://git.code.sf.net/p/qsampler/liblscp https://github.com/rncbc/liblscp.git https://gitlab.com/rncbc/liblscp.git https://bitbucket.com/rncbc/liblscp.git ** QXGEdit - A Qt XG Editor [4] ** QXGEdit 0.9.6 (spring'22) released! QXGEdit is a live XG instrument editor, specialized on editing MIDI System Exclusive files (.syx) for the Yamaha DB50XG [14] and thus probably a baseline for many other XG devices. Change-log: - Added missing file code to desktop exec entry. - Main application icon is now presented in scalable format (SVG). - Migrated command line parsing to QCommandLineParser/Option (Qt >= 5.2) Website: https://qxgedit.sourceforge.io http://qxgedit.sourceforge.net Project page: https://sourceforge.net/projects/qxgedit Downloads: https://sourceforge.net/projects/qxgedit/files - source tarball: https://download.sf.net/qxgedit/qxgedit-0.9.6.tar.gz - source package: https://download.sf.net/qxgedit/qxgedit-0.9.6-50.1.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qxgedit/qxgedit-0.9.6-50.1.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qxgedit/qxgedit-0.9.6-50.1.x86_64.AppImage Git repos: https://git.code.sf.net/p/qxgedit/code https://github.com/rncbc/qxgedit.git https://gitlab.com/rncbc/qxgedit.git https://bitbucket.com/rncbc/qxgedit.git ** QmidiCtl - A MIDI Remote Controller via UDP/IP Multicast [5] ** QmidiCtl 0.9.6 (spring'22) released! QmidiCtl [5] is a MIDI remote controller application that sends MIDI data over the network, using UDP/IP multicast. Inspired by multimidicast [15] and designed to be compatible with ipMIDI [15] for Windows. QmidiCtl [5] was long ago designed for the Maemo [17] enabled handheld devices, namely the late Nokia N900 [18] and promoted to the Maemo Package [18] repositories. Nevertheless, QmidiCtl [5] may still be found effective as a regular desktop application and recently as an Android application as well. Change-log: - Main application icon is now presented in scalable format (SVG). - Migrated command line parsing to QCommandLineParser/Option (Qt >= 5.2) Website: https://qmidictl.sourceforge.io http://qmidictl.sourceforge.net Project page: https://sourceforge.net/projects/qmidictl Downloads: https://sourceforge.net/projects/qmidictl/files - source tarball: https://download.sf.net/qmidictl/qmidictl-0.9.6.tar.gz - source package: https://download.sf.net/qmidictl/qmidictl-0.9.6-50.1.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qmidictl/qmidictl-0.9.6-50.1.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qmidictl/qmidictl-0.9.6-50.1.x86_64.AppImage - Android packages: https://download.sf.net/qmidictl/qmidictl-0.9.6-50.1.arm64-v8a.apk https://download.sf.net/qmidictl/qmidictl-0.9.6-50.1.x86_64.apk https://play.google.com/store/apps/details?id=org.rncbc.qmidictl Git repos: https://git.code.sf.net/p/qmidictl/code https://github.com/rncbc/qmidictl.git https://gitlab.com/rncbc/qmidictl.git https://bitbucket.com/rncbc/qmidictl.git ** QmidiNet - A MIDI Network Gateway via UDP/IP Multicast [6] ** QmidiNet 0.9.6 (spring'22) released! QmidiNet is a MIDI network gateway application that sends and receives MIDI data (ALSA-MIDI [9] and JACK-MIDI [8]) over the network, using UDP/IP multicast. Inspired by multimidicast [15] and designed to be compatible with ipMIDI [16] for Windows. Change-log: - Main application icon is now presented in scalable format (SVG). - Migrated command line parsing to QCommandLineParser/Option (Qt >= 5.2) Website: https://qmidinet.sourceforge.io http://qmidinet.sourceforge.net Project page: https://sourceforge.net/projects/qmidinet Downloads: https://sourceforge.net/projects/qmidinet/files - source tarball: https://download.sf.net/qmidinet/qmidinet-0.9.6.tar.gz - source package: https://download.sf.net/qmidinet/qmidinet-0.9.6-50.1.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qmidinet/qmidinet-0.9.6-50.1.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qmidinet/qmidinet-0.9.6-50.1.x86_64.AppImage Git repos: https://git.code.sf.net/p/qmidinet/code https://github.com/rncbc/qmidinet.git https://gitlab.com/rncbc/qmidinet.git https://bitbucket.com/rncbc/qmidinet.git -- License: All of the Qstuff* are free, open-source Linux Audio [11] software, distributed under the terms of the GNU General Public License (GPL) version 2 or later [12]. References: [1] QjackCtl - A JACK Audio Connection Kit Qt GUI Interface https://qjackctl.sourceforge.io [2] Qsynth - A fluidsynth Qt GUI Interface https://qsynth.sourceforge.io [3] Qsampler - A LinuxSampler Qt GUI Interface https://qsampler.sourceforge.io [4] QXGEdit - A Qt XG Editor https://qxgedit.sourceforge.io [5] QmidiCtl - A MIDI Remote Controller via UDP/IP Multicast https://qmidictl.sourceforge.io [6] QmidiNet - A MIDI Network Gateway via UDP/IP Multicast https://qmidinet.sourceforge.io [7] Qt framework, C++ class library and tools for cross-platform application and UI development https://qt.io/ [8] JACK Audio Connection Kit https://jackaudio.org [9] ALSA, Advanced Linux Sound Architecture https://www.alsa-project.org/ [10] FluidSynth - A SoundFont Synthesizer A real-time software synthesizer based on SoundFont 2 specifications https://www.fluidsynth.org [11] LinuxSampler - The Linux Sampler Project A modular, streaming capable, realtime audio sampler https://www.linuxsampler.org [12] Linux Audio consortium of libre software for audio-related work https://linuxaudio.org [13] GPL - GNU General Public License https://www.gnu.org/copyleft/gpl.html [14] Yamaha DB50XG (https://web.archive.org/web/20150607065739/) http://www.soundonsound.com/sos/1996_articles/may96/yamahadb50xg.html [15] multimidicast - sends and receives MIDI from ALSA sequencers over network https://llg.cubic.org/tools/multimidicast [16] ipMIDI - MIDI over Ethernet ports - send MIDI over your LAN https://nerds.de [17] Maemo.org - Home of the Maemo community https://www.maemo.org [18] Maemo.org Wiki - Nokia N900 https://wiki.maemo.org/Nokia_N900 [19] Maemo.org - Downloads: QmidiCtl https://maemo.org/downloads/product/Maemo5/qmidictl [20] AppImage, Linux apps that run anywhere https://appimage.org/ [21] Flatpak, next-generation technology for building and distributing desktop applications on Linux https://flatpak.org/ See also: https://www.rncbc.org/drupal/node/2328 Enjoy! -- rncbc aka Rui Nuno Capela |
From: Rui N. C. <rn...@rn...> - 2022-03-06 11:33:34
|
On 3/5/22 17:56, Christian Schoenebeck wrote: > On Samstag, 5. März 2022 18:02:22 CET Rui Nuno Capela via Linuxsampler-devel wrote: >> On 3/5/22 09:40, Christian Schoenebeck wrote: >>> On Dienstag, 1. März 2022 19:33:31 CET Christian Schoenebeck wrote: >>>> On Dienstag, 1. März 2022 19:01:53 CET Rui Nuno Capela wrote: >>>>> hi every1, >>>> >>>> Hi Rui, >>>> >>>>> for quite some time I've been noticing that windows builds are failing >>>>> (see subject) probably due to old autoconf/automake build system being >>>>> dropped in favor to now official cmake... >>>>> >>>>> and one other thing: the front-page/web is no longer reflecting the *svn >>>>> updates, ever since this late Mon Nov 22 17:08:21 CET 2021, as it >>>>> seems... >>>>> >>>>> is there anything I can do to help? >>>> >>>> As for the build errors: if you find some time, try to login to the CI >>>> page >>>> and change the compilatation commands accordingly. cmake is already >>>> installed. Otherwise I will have some time at the weekend to handle it. >>> >>> I fear the current requirement is too high: >>> CMake 3.15 or higher is required. You are running version 3.13.4 >>> >>> Rui, please check if you can lower the cmake version requirement. If it is >>> not possible then I fear I have to leave this broken for months to come, >>> as I don't have time to update the server for this right now. Sorry. >> >> hi Christian, >> >> what you mean? this is what: >> >> cmake_minimum_required (VERSION 3.13) > > OK, I see that you just lowered this to 3.13. Thanks! > The api-doc-lscp job is working now again. > > I look for the other CI targets tommorow. As we are cross compiling I have to > figure out what the equivalent with cmake is. Previously we had, e.g.: > > ["liblscp-win32" target]: > ./configure --host=i686-w64-mingw32 --prefix=$install_dir --disable-static > make -j4 > make install-strip > > ["liblscp-mac-x86_64" target]: > CC="clang -target x86_64-apple-darwin11 -B $toolchain/cctools/bin --sysroot=$toolchain/MacOSX10.7.sdk" \ > CXX="clang++ -target x86_64-apple-darwin11 -B $toolchain/cctools/bin --sysroot=$sdk/MacOSX10.7.sdk" \ > CXXFLAGS="-stdlib=libc++ -std=c++11 -I/usr/include/c++/v1 -O2 -ffast-math -fomit-frame-pointer" \ > ./configure --host=x86_64-apple-darwin11 --disable-static --prefix=$install_dir > make -j4 > make install-strip > > If you already have some idea about the equivalents, let me know. You can also > just login to the build page and try yourself in the meantime if you want. > hi Christian, no idea, never tried cross-compilation with cmake, but this would be a start: https://cmake.org/cmake/help/book/mastering-cmake/chapter/Cross%20Compiling%20With%20CMake.html# thanks -- rncbc aka. Rui Nuno Capela rn...@rn... |
From: Christian S. <sch...@li...> - 2022-03-05 17:57:08
|
On Samstag, 5. März 2022 18:02:22 CET Rui Nuno Capela via Linuxsampler-devel wrote: > On 3/5/22 09:40, Christian Schoenebeck wrote: > > On Dienstag, 1. März 2022 19:33:31 CET Christian Schoenebeck wrote: > >> On Dienstag, 1. März 2022 19:01:53 CET Rui Nuno Capela wrote: > >>> hi every1, > >> > >> Hi Rui, > >> > >>> for quite some time I've been noticing that windows builds are failing > >>> (see subject) probably due to old autoconf/automake build system being > >>> dropped in favor to now official cmake... > >>> > >>> and one other thing: the front-page/web is no longer reflecting the *svn > >>> updates, ever since this late Mon Nov 22 17:08:21 CET 2021, as it > >>> seems... > >>> > >>> is there anything I can do to help? > >> > >> As for the build errors: if you find some time, try to login to the CI > >> page > >> and change the compilatation commands accordingly. cmake is already > >> installed. Otherwise I will have some time at the weekend to handle it. > > > > I fear the current requirement is too high: > > CMake 3.15 or higher is required. You are running version 3.13.4 > > > > Rui, please check if you can lower the cmake version requirement. If it is > > not possible then I fear I have to leave this broken for months to come, > > as I don't have time to update the server for this right now. Sorry. > > hi Christian, > > what you mean? this is what: > > cmake_minimum_required (VERSION 3.13) OK, I see that you just lowered this to 3.13. Thanks! The api-doc-lscp job is working now again. I look for the other CI targets tommorow. As we are cross compiling I have to figure out what the equivalent with cmake is. Previously we had, e.g.: ["liblscp-win32" target]: ./configure --host=i686-w64-mingw32 --prefix=$install_dir --disable-static make -j4 make install-strip ["liblscp-mac-x86_64" target]: CC="clang -target x86_64-apple-darwin11 -B $toolchain/cctools/bin --sysroot=$toolchain/MacOSX10.7.sdk" \ CXX="clang++ -target x86_64-apple-darwin11 -B $toolchain/cctools/bin --sysroot=$sdk/MacOSX10.7.sdk" \ CXXFLAGS="-stdlib=libc++ -std=c++11 -I/usr/include/c++/v1 -O2 -ffast-math -fomit-frame-pointer" \ ./configure --host=x86_64-apple-darwin11 --disable-static --prefix=$install_dir make -j4 make install-strip If you already have some idea about the equivalents, let me know. You can also just login to the build page and try yourself in the meantime if you want. Best regards, Christian Schoenebeck |
From: Rui N. C. <rn...@rn...> - 2022-03-05 17:02:48
|
On 3/5/22 09:40, Christian Schoenebeck wrote: > On Dienstag, 1. März 2022 19:33:31 CET Christian Schoenebeck wrote: >> On Dienstag, 1. März 2022 19:01:53 CET Rui Nuno Capela wrote: >>> hi every1, >> >> Hi Rui, >> >>> for quite some time I've been noticing that windows builds are failing >>> (see subject) probably due to old autoconf/automake build system being >>> dropped in favor to now official cmake... >>> >>> and one other thing: the front-page/web is no longer reflecting the *svn >>> updates, ever since this late Mon Nov 22 17:08:21 CET 2021, as it seems... >>> >>> is there anything I can do to help? >> >> As for the build errors: if you find some time, try to login to the CI page >> and change the compilatation commands accordingly. cmake is already >> installed. Otherwise I will have some time at the weekend to handle it. > > I fear the current requirement is too high: > > CMake 3.15 or higher is required. You are running version 3.13.4 > > Rui, please check if you can lower the cmake version requirement. If it is not > possible then I fear I have to leave this broken for months to come, as I > don't have time to update the server for this right now. Sorry. > hi Christian, what you mean? this is what: cmake_minimum_required (VERSION 3.13) cmake 3.15 is actually only required if you follow the build instructions on the homepage: cmake -B build && cmake --build build && cmake --install build but may try the older way instead: cmake -B build && make -C build && make -C build install or even older: mkdir build cd build cmake .. && make && make install hth. cheers -- rncbc aka. Rui Nuno Capela rn...@rn... |
From: Christian S. <sch...@li...> - 2022-03-05 09:40:51
|
On Dienstag, 1. März 2022 19:33:31 CET Christian Schoenebeck wrote: > On Dienstag, 1. März 2022 19:01:53 CET Rui Nuno Capela wrote: > > hi every1, > > Hi Rui, > > > for quite some time I've been noticing that windows builds are failing > > (see subject) probably due to old autoconf/automake build system being > > dropped in favor to now official cmake... > > > > and one other thing: the front-page/web is no longer reflecting the *svn > > updates, ever since this late Mon Nov 22 17:08:21 CET 2021, as it seems... > > > > is there anything I can do to help? > > As for the build errors: if you find some time, try to login to the CI page > and change the compilatation commands accordingly. cmake is already > installed. Otherwise I will have some time at the weekend to handle it. I fear the current requirement is too high: CMake 3.15 or higher is required. You are running version 3.13.4 Rui, please check if you can lower the cmake version requirement. If it is not possible then I fear I have to leave this broken for months to come, as I don't have time to update the server for this right now. Sorry. Best regards, Christian Schoenebeck |
From: Christian S. <sch...@li...> - 2022-03-02 16:03:40
|
On Dienstag, 1. März 2022 23:45:30 CET Rui Nuno Capela via Linuxsampler-devel wrote: > On 3/1/22 18:33, Christian Schoenebeck wrote: > > On Dienstag, 1. März 2022 19:01:53 CET Rui Nuno Capela wrote: > > > > As for the frontsite: I don't think there is any issue. You were not > > commiting with star "*" in front. That's why it did not show up there > > (expected behaviour since 2003). > > hi Christian > > oops, you're right, this one missed the asterisk: > -- > r4023 | capela | 2022-01-09 10:45:21 +0000 (Sun, 09 Jan 2022) | 1 line > > 0.9.5 > -- > > exactly the same with liblscp a few minutes earlier: > -- > r4022 | capela | 2022-01-09 10:43:35 +0000 (Sun, 09 Jan 2022) | 1 line > > 0.9.5 > -- > > it should have been '* A Winter'22 Release (v0.9.5)" but somehow only > the "0.9.5" got through, maybe my fault :( > > thanks anyway NP. :) BTW git style comments are accepted by the server side scripts as well, i.e.: " one-line summary of this commit * Some detailed explanation. * And another detailed one. " or " one-line summary of this commit * Some detailed explanation. * And another detailed one. " E.g.: http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=3804 As long as at least one line starts with an asterisk character somewhere, then the commit log is published on the front site. If another form would be more intuitive for you, we can still extend the scripts of course. Best regards, Christian Schoenebeck |
From: Rui N. C. <rn...@rn...> - 2022-03-01 22:45:55
|
On 3/1/22 18:33, Christian Schoenebeck wrote: > On Dienstag, 1. März 2022 19:01:53 CET Rui Nuno Capela wrote: > > As for the frontsite: I don't think there is any issue. You were not commiting > with star "*" in front. That's why it did not show up there (expected > behaviour since 2003). > hi Christian oops, you're right, this one missed the asterisk: -- r4023 | capela | 2022-01-09 10:45:21 +0000 (Sun, 09 Jan 2022) | 1 line 0.9.5 -- exactly the same with liblscp a few minutes earlier: -- r4022 | capela | 2022-01-09 10:43:35 +0000 (Sun, 09 Jan 2022) | 1 line 0.9.5 -- it should have been '* A Winter'22 Release (v0.9.5)" but somehow only the "0.9.5" got through, maybe my fault :( thanks anyway -- rncbc aka. Rui Nuno Capela rn...@rn... |
From: Christian S. <sch...@li...> - 2022-03-01 19:15:59
|
On Dienstag, 1. März 2022 19:01:53 CET Rui Nuno Capela wrote: > hi every1, Hi Rui, > for quite some time I've been noticing that windows builds are failing > (see subject) probably due to old autoconf/automake build system being > dropped in favor to now official cmake... > > and one other thing: the front-page/web is no longer reflecting the *svn > updates, ever since this late Mon Nov 22 17:08:21 CET 2021, as it seems... > > is there anything I can do to help? As for the build errors: if you find some time, try to login to the CI page and change the compilatation commands accordingly. cmake is already installed. Otherwise I will have some time at the weekend to handle it. As for the frontsite: I don't think there is any issue. You were not commiting with star "*" in front. That's why it did not show up there (expected behaviour since 2003). Best regards, Christian Schoenebeck |
From: Rui N. C. <rn...@rn...> - 2022-03-01 18:02:16
|
hi every1, for quite some time I've been noticing that windows builds are failing (see subject) probably due to old autoconf/automake build system being dropped in favor to now official cmake... and one other thing: the front-page/web is no longer reflecting the *svn updates, ever since this late Mon Nov 22 17:08:21 CET 2021, as it seems... is there anything I can do to help? thanks && cheers -- rncbc aka. Rui Nuno Capela rn...@rn... |
From: Christian S. <sch...@li...> - 2022-01-22 15:19:15
|
On Samstag, 22. Januar 2022 16:05:26 CET you wrote: > That is clear. It is another way of setting volume to zero. CC7 will do the > same. Is there a hard coded CC in Linuxsampler which mutes an instrument? As far as regular CCs are concerned, no, there is only CC7 hard coded for something like that. Here are the currently hard coded CCs being effective for all engines/formats in LS: https://svn.linuxsampler.org/cgi-bin/viewvc.cgi/linuxsampler/trunk/src/engines/EngineBase.h?revision=3854&view=markup#l1548 We also have hard coded RPNs and NRPNs though, and the one you are probably looking for is the "volume level of note" NRPN from the Roland GS spec: https://svn.linuxsampler.org/cgi-bin/viewvc.cgi/linuxsampler/trunk/src/engines/EngineBase.h?revision=3854&view=markup#l2062 CU Christian |
From: Jan F. <fl...@ze...> - 2022-01-22 15:05:35
|
That is clear. It is another way of setting volume to zero. CC7 will do the same. Is there a hard coded CC in Linuxsampler which mutes an instrument? Kind regards, Jan Fl. -----Original Message----- From: Christian Schoenebeck [mailto:sch...@li...] Sent: zaterdag 22 januari 2022 15:45 To: lin...@li... Subject: Re: [Linuxsampler-devel] toggle instrument on/off On Donnerstag, 20. Januar 2022 16:50:19 CET Jan Flikweert wrote: > Hi all, > > The use of Linuxsampler seems easy to me. If you do not need an instrument, > don't sent notes to it. > > I discovered that CC 71 works like toggle of/on instrument, stop. > > Is this correct, is this the meaning of CC71? No it's not. We have a bunch of hard coded CCs (independent from loaded instrument) like sustain, panpot, portamento, sostenuto, channel volume, but CC71 is not a hard coded CC in LS. I assume you simply loaded an instrument which defined CC71 e.g. as filter cutoff controller in its instrument patch. That would result in the behaviour that you won't hear active notes as long as CC71 (and therefore its cutoff frequency) is turned down to zero. CU Christian _______________________________________________ Linuxsampler-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
From: Christian S. <sch...@li...> - 2022-01-22 14:47:48
|
On Freitag, 21. Januar 2022 09:05:01 CET Jan Flikweert wrote: > Hi all, > > > > I use Windows 10 64 bit and The most recent version of Linuxsampler/gigedit > due to recent changes in the builds of Linuxsampler. > > > > I run gigedit 64 bit as administrator. > > > > 1.Modifying a gig file > > 2.and saving it > > 3.causes a crash of the program gigedit > > 4.without saving anything to the gig file. > If somebody can create a backtrace of the crash I can look at it. I currently don't have the time to reproduce this on a Windows machine by myself, sorry. CU Christian |
From: Christian S. <sch...@li...> - 2022-01-22 14:44:44
|
On Donnerstag, 20. Januar 2022 16:50:19 CET Jan Flikweert wrote: > Hi all, > > The use of Linuxsampler seems easy to me. If you do not need an instrument, > don't sent notes to it. > > I discovered that CC 71 works like toggle of/on instrument, stop. > > Is this correct, is this the meaning of CC71? No it's not. We have a bunch of hard coded CCs (independent from loaded instrument) like sustain, panpot, portamento, sostenuto, channel volume, but CC71 is not a hard coded CC in LS. I assume you simply loaded an instrument which defined CC71 e.g. as filter cutoff controller in its instrument patch. That would result in the behaviour that you won't hear active notes as long as CC71 (and therefore its cutoff frequency) is turned down to zero. CU Christian |
From: Jan F. <fl...@ze...> - 2022-01-21 08:05:19
|
Hi all, I use Windows 10 64 bit and The most recent version of Linuxsampler/gigedit due to recent changes in the builds of Linuxsampler. I run gigedit 64 bit as administrator. 1.Modifying a gig file 2.and saving it 3.causes a crash of the program gigedit 4.without saving anything to the gig file. Kind regards, Jan Fl. |
From: Jan F. <fl...@ze...> - 2022-01-20 15:50:27
|
Hi all, The use of Linuxsampler seems easy to me. If you do not need an instrument, don't sent notes to it. I discovered that CC 71 works like toggle of/on instrument, stop. Is this correct, is this the meaning of CC71? Kind regards, Jan Fl. |
From: Christian S. <sch...@li...> - 2022-01-11 12:59:39
|
On Freitag, 7. Januar 2022 08:29:49 CET Doug Gray wrote: > I've crawled around a number of product manuals and discovered a variety of > behaviours for note off. Some do send v=64 including some recent models > (Casio Privia PXS series, Yamaha CP88, YC88 to name a few notables). > On the other hand the Yamaha Arius ADP Series of console pianos send > v=1-127, ie zero is not sent. I have verified this today myself on an Arius > ADP-164. > Some older designs send a zero velocity, possibly the lower end of the > spectrum of controllers such as the Masterkey49. > Unfortunately the higher profile midi keyboards such as the Kawai(VPC-1), > Native Instruments, Arturia don't share the detail in their product > manuals, at least not that I could find. > So not as definitive as I expected. Mmm, that's unfortunate. Thanks for the research though! For now I keep the current simple implementation (check for zero velocity). In future this should probably be changed to a MIDI learn mechanism and/or checking for this feature according to MIDI v2. Again, haven't checked the MIDI v2 specs yet, but I read somewhere they have added capability negotiation. CU Christian |
From: Rui N. C. <rn...@rn...> - 2022-01-09 18:37:51
|
Hi all, The first batch of the 'QStuff*' is now being released for the New Year: QjackCtl [1], Qsynth [2], Qsampler [3], QXGEdit [4], QmidiCtl [5] and QmidiNet [6], are all out for the (northern) Winter'22 season. ** QjackCtl - JACK Audio Connection Kit Qt GUI Interface [1] ** QjackCtl 0.9.6 (winter'22) released! QjackCtl is an aged yet modern, not so 'simple' anymore, Qt [7] application to control the JACK [8] sound server, for the Linux Audio [12] infrastructure. Change-log: - Dropped autotools (autoconf, automake, etc.) build system. - Limit or mitigate fast auto-scrolling when moving Graph client nodes off the viewport. - Whenever possible, adopt the previous named default preset, when starting the JACK-server on premises. - Conditional fix to MacOSX and FreeBSD builds. Website: https://qjackctl.sourceforge.io http://qjackctl.sourceforge.net Project page: https://sourceforge.net/projects/qjackctl Downloads: https://sourceforge.net/projects/qjackctl/files - source tarball: https://download.sf.net/qjackctl/qjackctl-0.9.6.tar.gz - source package: https://download.sf.net/qjackctl/qjackctl-0.9.6-50.1.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qjackctl/qjackctl-0.9.6-50.1.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qjackctl/qjackctl-0.9.6-50.1.x86_64.AppImage Git repos: https://git.code.sf.net/p/qjackctl/code https://github.com/rncbc/qjackctl.git https://gitlab.com/rncbc/qjackctl.git https://bitbucket.com/rncbc/qjackctl.git ** Qsynth - A fluidsynth Qt GUI Interface [2] ** Qsynth 0.9.5 (winter'22) released! Qsynth is a FluidSynth [10] GUI front-end application written in C++ around the Qt framework [7] using Qt Designer. Website: https://qsynth.sourceforge.io http://qsynth.sourceforge.net Project page: https://sourceforge.net/projects/qsynth Downloads: https://sourceforge.net/projects/qsynth/files - source tarball: https://download.sf.net/qsynth/qsynth-0.9.5.tar.gz - source package: https://download.sf.net/qsynth/qsynth-0.9.5-49.2.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qsynth/qsynth-0.9.5-49.2.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qsynth/qsynth-0.9.5-49.2.x86_64.AppImage - Windows package (thanks again to Pedro Lopez-Cabanillas): https://download.sf.net/qsynth/qsynth-0.9.5-49.2.win-x64-setup.exe Git repos: https://git.code.sf.net/p/qsynth/code https://github.com/rncbc/qsynth.git https://gitlab.com/rncbc/qsynth.git https://bitbucket.com/rncbc/qsynth.git ** Qsampler - A LinuxSampler Qt GUI Interface [3] ** Qsampler 0.9.5 (winter'22) released! Qsampler is a LinuxSampler [11] GUI front-end application written in C++ around the Qt framework [7] using Qt Designer. Change-log: - Dropped autotools (autoconf, automake, etc.) build system. - Fixed for Qt6 plugins path eg. widget theme or styles. Website: https://qsampler.sourceforge.io http://qsampler.sourceforge.net Project page: https://sourceforge.net/projects/qsampler Downloads: https://sourceforge.net/projects/qsampler/files - source tarballs: https://download.sf.net/qsampler/qsampler-0.9.5.tar.gz https://download.sf.net/qsampler/liblscp-0.9.5.tar.gz - source packages: https://download.sf.net/qsampler/qsampler-0.9.5-49.1.rncbc.suse.src.rpm https://download.sf.net/qsampler/liblscp-0.9.5-49.1.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qsampler/qsampler-0.9.5-49.1.rncbc.suse.x86_64.rpm https://download.sf.net/qsampler/liblscp6-0.9.5-49.1.rncbc.suse.x86_64.rpm https://download.sf.net/qsampler/liblscp-devel-0.9.5-49.1.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qsampler/qsampler-0.9.5-49.1.x86_64.AppImage Git repos: https://git.code.sf.net/p/qsampler/code https://github.com/rncbc/qsampler.git https://gitlab.com/rncbc/qsampler.git https://bitbucket.com/rncbc/qsampler.git https://git.code.sf.net/p/qsampler/liblscp https://github.com/rncbc/liblscp.git https://gitlab.com/rncbc/liblscp.git https://bitbucket.com/rncbc/liblscp.git ** QXGEdit - A Qt XG Editor [4] ** QXGEdit 0.9.5 (winter'22) released! QXGEdit is a live XG instrument editor, specialized on editing MIDI System Exclusive files (.syx) for the Yamaha DB50XG [14] and thus probably a baseline for many other XG devices. Change-log: - Dropped autotools (autoconf, automake, etc.) build system. Website: https://qxgedit.sourceforge.io http://qxgedit.sourceforge.net Project page: https://sourceforge.net/projects/qxgedit Downloads: https://sourceforge.net/projects/qxgedit/files - source tarball: https://download.sf.net/qxgedit/qxgedit-0.9.5.tar.gz - source package: https://download.sf.net/qxgedit/qxgedit-0.9.5-49.1.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qxgedit/qxgedit-0.9.5-49.1.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qxgedit/qxgedit-0.9.5-49.1.x86_64.AppImage Git repos: https://git.code.sf.net/p/qxgedit/code https://github.com/rncbc/qxgedit.git https://gitlab.com/rncbc/qxgedit.git https://bitbucket.com/rncbc/qxgedit.git ** QmidiCtl - A MIDI Remote Controller via UDP/IP Multicast [5] ** QmidiCtl 0.9.5 (winter'22) released! QmidiCtl [5] is a MIDI remote controller application that sends MIDI data over the network, using UDP/IP multicast. Inspired by multimidicast [15] and designed to be compatible with ipMIDI [15] for Windows. QmidiCtl [5] was long ago designed for the Maemo [17] enabled handheld devices, namely the late Nokia N900 [18] and promoted to the Maemo Package [18] repositories. Nevertheless, QmidiCtl [5] may still be found effective as a regular desktop application and recently as an Android application as well. Change-log: - Dropped autotools (autoconf, automake, etc.) build system. Website: https://qmidictl.sourceforge.io http://qmidictl.sourceforge.net Project page: https://sourceforge.net/projects/qmidictl Downloads: https://sourceforge.net/projects/qmidictl/files - source tarball: https://download.sf.net/qmidictl/qmidictl-0.9.5.tar.gz - source package: https://download.sf.net/qmidictl/qmidictl-0.9.5-49.1.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qmidictl/qmidictl-0.9.5-49.1.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qmidictl/qmidictl-0.9.5-49.1.x86_64.AppImage - Android packages: https://download.sf.net/qmidictl/qmidictl-0.9.5-49.1.arm64-v8a.apk https://download.sf.net/qmidictl/qmidictl-0.9.5-49.1.x86_64.apk https://play.google.com/store/apps/details?id=org.rncbc.qmidictl Git repos: https://git.code.sf.net/p/qmidictl/code https://github.com/rncbc/qmidictl.git https://gitlab.com/rncbc/qmidictl.git https://bitbucket.com/rncbc/qmidictl.git ** QmidiNet - A MIDI Network Gateway via UDP/IP Multicast [6] ** QmidiNet 0.9.5 (winter'22) released! QmidiNet is a MIDI network gateway application that sends and receives MIDI data (ALSA-MIDI [9] and JACK-MIDI [8]) over the network, using UDP/IP multicast. Inspired by multimidicast [15] and designed to be compatible with ipMIDI [16] for Windows. Change-log: - Dropped autotools (autoconf, automake, etc.) build system. Website: https://qmidinet.sourceforge.io http://qmidinet.sourceforge.net Project page: https://sourceforge.net/projects/qmidinet Downloads: https://sourceforge.net/projects/qmidinet/files - source tarball: https://download.sf.net/qmidinet/qmidinet-0.9.5.tar.gz - source package: https://download.sf.net/qmidinet/qmidinet-0.9.5-49.1.rncbc.suse.src.rpm - binary packages: https://download.sf.net/qmidinet/qmidinet-0.9.5-49.1.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qmidinet/qmidinet-0.9.5-49.1.x86_64.AppImage Git repos: https://git.code.sf.net/p/qmidinet/code https://github.com/rncbc/qmidinet.git https://gitlab.com/rncbc/qmidinet.git https://bitbucket.com/rncbc/qmidinet.git -- License: All of the Qstuff* are free, open-source Linux Audio [11] software, distributed under the terms of the GNU General Public License (GPL) version 2 or later [12]. References: [1] QjackCtl - A JACK Audio Connection Kit Qt GUI Interface https://qjackctl.sourceforge.io [2] Qsynth - A fluidsynth Qt GUI Interface https://qsynth.sourceforge.io [3] Qsampler - A LinuxSampler Qt GUI Interface https://qsampler.sourceforge.io [4] QXGEdit - A Qt XG Editor https://qxgedit.sourceforge.io [5] QmidiCtl - A MIDI Remote Controller via UDP/IP Multicast https://qmidictl.sourceforge.io [6] QmidiNet - A MIDI Network Gateway via UDP/IP Multicast https://qmidinet.sourceforge.io [7] Qt framework, C++ class library and tools for cross-platform application and UI development https://qt.io/ [8] JACK Audio Connection Kit https://jackaudio.org [9] ALSA, Advanced Linux Sound Architecture https://www.alsa-project.org/ [10] FluidSynth - A SoundFont Synthesizer A real-time software synthesizer based on SoundFont 2 specifications https://www.fluidsynth.org [11] LinuxSampler - The Linux Sampler Project A modular, streaming capable, realtime audio sampler https://www.linuxsampler.org [12] Linux Audio consortium of libre software for audio-related work https://linuxaudio.org [13] GPL - GNU General Public License https://www.gnu.org/copyleft/gpl.html [14] Yamaha DB50XG (https://web.archive.org/web/20150607065739/) http://www.soundonsound.com/sos/1996_articles/may96/yamahadb50xg.html [15] multimidicast - sends and receives MIDI from ALSA sequencers over network https://llg.cubic.org/tools/multimidicast [16] ipMIDI - MIDI over Ethernet ports - send MIDI over your LAN https://nerds.de [17] Maemo.org - Home of the Maemo community https://www.maemo.org [18] Maemo.org Wiki - Nokia N900 https://wiki.maemo.org/Nokia_N900 [19] Maemo.org - Downloads: QmidiCtl https://maemo.org/downloads/product/Maemo5/qmidictl [20] AppImage, Linux apps that run anywhere https://appimage.org/ See also: https://www.rncbc.org/drupal/node/2303 Have a great New Year! -- rncbc aka Rui Nuno Capela |
From: Doug G. <dou...@gm...> - 2022-01-07 07:30:09
|
I've crawled around a number of product manuals and discovered a variety of behaviours for note off. Some do send v=64 including some recent models (Casio Privia PXS series, Yamaha CP88, YC88 to name a few notables). On the other hand the Yamaha Arius ADP Series of console pianos send v=1-127, ie zero is not sent. I have verified this today myself on an Arius ADP-164. Some older designs send a zero velocity, possibly the lower end of the spectrum of controllers such as the Masterkey49. Unfortunately the higher profile midi keyboards such as the Kawai(VPC-1), Native Instruments, Arturia don't share the detail in their product manuals, at least not that I could find. So not as definitive as I expected. On Wed, 5 Jan 2022 at 03:19, Christian Schoenebeck < sch...@li...> wrote: > I changed the behaviour for both the SFZ engine and gig engine to > distinguish > by note-off velocity being exactly zero for now: > http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4020 > > That should fix expected release trigger behaviour for both keyboards with > and > without key release sensors appropriately. > > If it turns out that some MIDI keyboards with release sensors do send > note-off > velocity zero (which I doubt), then this behaviour can still be changed to > some more complicated MIDI-learn mechanism. > > BTW the original MIDI v1 specs say keyboards that do not support note-off > velocity should send 64 as note-off velocity value. Probably one of the > very > few mistakes made in the ancient MIDI specs, at least IMO. I haven't > looked > into latest MIDI v2 specs yet. I noticed though there was some voting > process > on a note-off related change on midi.org, that thread on midi.org is > password > protected though, so no idea what this was exactly about. > > CU > Christian > > On Montag, 3. Januar 2022 19:29:58 CET Raphaël Mouneyres wrote: > > thanks for the tests, it makes sense from a firmware perspective to set > > 0x01 as a minimum. > > > > I'll try to have a look at how another keyboard reacts when I have one > > at hand, probably during this week or next one, and I'll report back. > > > > Raphaël > > > > Le 03/01/2022 à 02:58, Doug Gray a écrit : > > > I have run a test on the SL-88, the lowest reported release velocity > seems > > > to be 0x01. I have tried to release keys as gently as I can but have > not > > > yet seen a release velocity of zero. It’s easy to hit the 0x01 so I’m > > > quite confident it is the lowest possible value. This was not what I > > > expected but makes good sense. > > > Doug Gray > > > > > > > > > Sent from my iPhone > > > > > >> On 3 Jan 2022, at 4:19 am, Jerash music <rmo...@gm...> wrote: > > >> > > >> > > >> > > >>> Le 2 janv. 2022 à 14:53, Christian Schoenebeck > <sch...@li...> a écrit : > > >>>> On Sonntag, 2. Januar 2022 14:42:55 CET Jerash music wrote: > > >>>> Having worked with (and repairing) many midi keyboard controllers, I > > >>>> can say that release velocity is not very common. Mainly available > on > > >>>> high range keyboard, often with weighted keys, piano style. > > >>>> > > >>>> Keyboard rubbers with triple sensors offer greater definition so to > > >>>> have > > >>>> the release velocity, but it can be implemented in the device > firmware > > >>>> or > > >>>> not, at manufacturer’s choice. Keyboard rubber with double sensor > could > > >>>> also do release velocity, but may miss some when the key is not > fully > > >>>> pressed before actual release. Here, again, the sent message > depends on > > >>>> firmware implementation. > > >>>> > > >>>>> I suggest that that should only be the case when note off > velocity is > > >>>>> actually zero. > > >>>> > > >>>> I do agree with this, it totally makes sense to me. > > >>>> > > >>>> My 2 cents, > > >>>> Raphaël > > >>> > > >>> Ok, but the core question still is: can we expect keyboards *with* > > >>> note-off > > >>> velocity sensors to *never* send note-off velocity zero? > > >> > > >> Mmm, …yes it may be possible. > > >> it may be possible to send a zero release velocity if the firmware > > >> calculates a release velocity and includes a « timeout » for the > maximum > > >> release time, and then decides that timed out values are zero. But I > > >> have not expressly tested it, and each manufacturer could have his own > > >> vision. > > >> > > >> I’ve been explained by Yamaha that the three contact rubbers are > > >> especially useful for retriggering calculation of half pressed keys, > but > > >> they did not talk about release velocity calculation. Maybe Doug Gray > > >> could try the following on his SL88 : « Release the key as slow as > > >> possible in about 4 seconds » to try to reach the minimum release > > >> velocity value. As the keyboard rubber has three contacts, it could > > >> potentially send a zero release velocity if you reach a timeout > between > > >> two contacts releases. I’m not sure if it is humanly possible to reach > > >> this potential timeout, as the contact points are really really close. > > >> The real duration of this timeout is not documented so needs testing. > > >> > > >> Raphaël > > >> > > >> _______________________________________________ > > >> Linuxsampler-devel mailing list > > >> Lin...@li... > > >> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > > > _______________________________________________ > > > Linuxsampler-devel mailing list > > > Lin...@li... > > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > > > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > |
From: Nicola P. <nic...@gm...> - 2022-01-05 17:27:53
|
Wow! Thank you Christian! I will test it asap. Il 03/01/22 19:17, Christian Schoenebeck ha scritto: > For the SFZ users out there; experimental support for automatic reloading of > modified .sfz files: > > http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4019 > > It works as simple as you might imagine: > > 1. Load an .sfz file as usual into LinuxSampler. > > 2. Open the .sfz file with an editor of your choice (a text editor, something > more fancy specifically for SFZ, doesn't matter). > > 3. Change something in the sfz file. > > 4. Hit "Save" in the editor. > > The sampler will automatically reload the SFZ instrument at this point. > > CU > Christian > > > > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel -- Nicola Pandini http://nicolapandini.damai.it |
From: Christian S. <sch...@li...> - 2022-01-05 16:32:21
|
On Mittwoch, 5. Januar 2022 11:26:57 CET Andrew C wrote: > Hi Christian, > > Ah ok, that was my issue with the instrument editor not opening after all! I disabled this behaviour for now as a workaround, so it no longer unloads instrument editor plugins on a LSCP "RESET" command: http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4021 > I might be missing something, but once the plugins are closed and that > destructor code is run (i.e a RESET is sent), how can linuxsampler open > them up again? > At that point, sending the LSCP commands to create a new audio interface, > load a gig file and open it for editing again gives the 'cannot find > instrument editor' message. IIRC The original intended behaviour was to unload all instrument editor plugins to prevent them causing a crash if they were still open, as a sampler reset basically wipes away everything from RAM editors are working on. ClosePlugin() then resets bPluginsLoaded, which would cause the next time instrument editors were requested, to automatically reload the plugins. And it did that actually there. However AFAICS the subsequent LSCP "CHANNEL EDIT" command was issued so fast on your side that it apparently caused a race condition: 1. now missing plugins were reloaded 2. previous DLL instance was unloaded and immediately deleted the new plugin instances of step (1.) again (due to the InnerFactoryDestructor being executed deferred) At least that's what I assume ATM. I currently don't have plans to address this potential race, from my comments in the svn diff you probably see that it would not be a quick and easy to fix, e.g. Windows would be tricky. Hence my decision for this workaround for now. CU Christian |
From: Andrew C <cou...@gm...> - 2022-01-05 10:27:18
|
Hi Christian, Ah ok, that was my issue with the instrument editor not opening after all! I might be missing something, but once the plugins are closed and that destructor code is run (i.e a RESET is sent), how can linuxsampler open them up again? At that point, sending the LSCP commands to create a new audio interface, load a gig file and open it for editing again gives the 'cannot find instrument editor' message. Thanks, Andrew. On Thu, Dec 30, 2021 at 6:03 PM Christian Schoenebeck < sch...@li...> wrote: > On Dienstag, 28. Dezember 2021 11:21:28 CET Andrew C wrote: > > This is the output when I, shall we say, non-interactively (i.e netcat) > > send a command to Linuxsampler: > > > > Data type is libgig and data version is 4.3.0.svn34 > > Trying to find an available editor. > > Loading instrument editor plugins...Successfully loaded: > > /usr/local/lib/linuxsampler/plugins/libgigeditlinuxsamplerplugin.so > > OK > > InnerFactories.begin. > > Returning available editors result. > > Instrument plugin is > > Searching for matching editors now... > > Trying to find an editor that can support: libgig and 4.3.0.svn34 > > Trying to find an available editor. > > Loading instrument editor plugins...Successfully loaded: > > /usr/local/lib/linuxsampler/plugins/libgigeditlinuxsamplerplugin.so > > OK > > InnerFactories.begin. > > Returning available editors result. > > Registered instrument editors again: > > Searched finished for matching editors... > > vEditors looks empty. What about available editors string?Trying to find > an > > available editor. > > Loading instrument editor plugins...Successfully loaded: > > /usr/local/lib/linuxsampler/plugins/libgigeditlinuxsamplerplugin.so > > OK > > InnerFactories.begin. > > Returning available editors result. > > ERROR: There is not any instrument editor registered to the sampler! > > > > > > It looks like the iterating through the previously registered editors > gets > > "forgotten" or otherwise the 'InnerFactories.begin()' loop is empty in > the > > 'non-interactive' example.. > > Phew.. That's enough wall of text then! > > Are you requesting a sampler reset per LSCP comand via netcat somewhere in > between? Because a sampler reset request will reset really everything, > i.e. > the sampler would also call > > src/Sampler.cpp: > void Sampler::Reset() { > ... > InstrumentEditorFactory::ClosePlugins(); > ... > } > > And ClosePlugin() closes all open plugin DLLs. Once the instrument editor > DLL > is unloaded from memory, the following destructor code is executed > automatically: > > src/plugins/InstrumentEditorFactory.h: > ~InnerFactoryRegistrator() { > InnerFactoryTemplate<PluginClass_T> innerFactory; > InstrumentEditor* pEditor = innerFactory.Create(); > if (InnerFactories.count(pEditor->Name())) { > InnerFactory* pZombie = > InnerFactories[pEditor->Name()]; > InnerFactories.erase(pEditor->Name()); > if (pZombie) delete pZombie; > } > innerFactory.Destroy(pEditor); > } > > CU > Christian > > > > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > |
From: Christian S. <sch...@li...> - 2022-01-04 16:18:38
|
I changed the behaviour for both the SFZ engine and gig engine to distinguish by note-off velocity being exactly zero for now: http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4020 That should fix expected release trigger behaviour for both keyboards with and without key release sensors appropriately. If it turns out that some MIDI keyboards with release sensors do send note-off velocity zero (which I doubt), then this behaviour can still be changed to some more complicated MIDI-learn mechanism. BTW the original MIDI v1 specs say keyboards that do not support note-off velocity should send 64 as note-off velocity value. Probably one of the very few mistakes made in the ancient MIDI specs, at least IMO. I haven't looked into latest MIDI v2 specs yet. I noticed though there was some voting process on a note-off related change on midi.org, that thread on midi.org is password protected though, so no idea what this was exactly about. CU Christian On Montag, 3. Januar 2022 19:29:58 CET Raphaël Mouneyres wrote: > thanks for the tests, it makes sense from a firmware perspective to set > 0x01 as a minimum. > > I'll try to have a look at how another keyboard reacts when I have one > at hand, probably during this week or next one, and I'll report back. > > Raphaël > > Le 03/01/2022 à 02:58, Doug Gray a écrit : > > I have run a test on the SL-88, the lowest reported release velocity seems > > to be 0x01. I have tried to release keys as gently as I can but have not > > yet seen a release velocity of zero. It’s easy to hit the 0x01 so I’m > > quite confident it is the lowest possible value. This was not what I > > expected but makes good sense. > > Doug Gray > > > > > > Sent from my iPhone > > > >> On 3 Jan 2022, at 4:19 am, Jerash music <rmo...@gm...> wrote: > >> > >> > >> > >>> Le 2 janv. 2022 à 14:53, Christian Schoenebeck <sch...@li...> a écrit : > >>>> On Sonntag, 2. Januar 2022 14:42:55 CET Jerash music wrote: > >>>> Having worked with (and repairing) many midi keyboard controllers, I > >>>> can say that release velocity is not very common. Mainly available on > >>>> high range keyboard, often with weighted keys, piano style. > >>>> > >>>> Keyboard rubbers with triple sensors offer greater definition so to > >>>> have > >>>> the release velocity, but it can be implemented in the device firmware > >>>> or > >>>> not, at manufacturer’s choice. Keyboard rubber with double sensor could > >>>> also do release velocity, but may miss some when the key is not fully > >>>> pressed before actual release. Here, again, the sent message depends on > >>>> firmware implementation. > >>>> > >>>>> I suggest that that should only be the case when note off velocity is > >>>>> actually zero. > >>>> > >>>> I do agree with this, it totally makes sense to me. > >>>> > >>>> My 2 cents, > >>>> Raphaël > >>> > >>> Ok, but the core question still is: can we expect keyboards *with* > >>> note-off > >>> velocity sensors to *never* send note-off velocity zero? > >> > >> Mmm, …yes it may be possible. > >> it may be possible to send a zero release velocity if the firmware > >> calculates a release velocity and includes a « timeout » for the maximum > >> release time, and then decides that timed out values are zero. But I > >> have not expressly tested it, and each manufacturer could have his own > >> vision. > >> > >> I’ve been explained by Yamaha that the three contact rubbers are > >> especially useful for retriggering calculation of half pressed keys, but > >> they did not talk about release velocity calculation. Maybe Doug Gray > >> could try the following on his SL88 : « Release the key as slow as > >> possible in about 4 seconds » to try to reach the minimum release > >> velocity value. As the keyboard rubber has three contacts, it could > >> potentially send a zero release velocity if you reach a timeout between > >> two contacts releases. I’m not sure if it is humanly possible to reach > >> this potential timeout, as the contact points are really really close. > >> The real duration of this timeout is not documented so needs testing. > >> > >> Raphaël > >> > >> _______________________________________________ > >> Linuxsampler-devel mailing list > >> Lin...@li... > >> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > > _______________________________________________ > > Linuxsampler-devel mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
From: Raphaël M. <rmo...@gm...> - 2022-01-03 18:30:09
|
thanks for the tests, it makes sense from a firmware perspective to set 0x01 as a minimum. I'll try to have a look at how another keyboard reacts when I have one at hand, probably during this week or next one, and I'll report back. Raphaël Le 03/01/2022 à 02:58, Doug Gray a écrit : > I have run a test on the SL-88, the lowest reported release velocity seems to be 0x01. I have tried to release keys as gently as I can but have not yet seen a release velocity of zero. It’s easy to hit the 0x01 so I’m quite confident it is the lowest possible value. > This was not what I expected but makes good sense. > Doug Gray > > > Sent from my iPhone > >> On 3 Jan 2022, at 4:19 am, Jerash music <rmo...@gm...> wrote: >> >> >> >>> Le 2 janv. 2022 à 14:53, Christian Schoenebeck <sch...@li...> a écrit : >>> >>>> On Sonntag, 2. Januar 2022 14:42:55 CET Jerash music wrote: >>>> Having worked with (and repairing) many midi keyboard controllers, I can say >>>> that release velocity is not very common. Mainly available on high range >>>> keyboard, often with weighted keys, piano style. >>>> >>>> Keyboard rubbers with triple sensors offer greater definition so to have >>>> the release velocity, but it can be implemented in the device firmware or >>>> not, at manufacturer’s choice. Keyboard rubber with double sensor could >>>> also do release velocity, but may miss some when the key is not fully >>>> pressed before actual release. Here, again, the sent message depends on >>>> firmware implementation. >>>>> I suggest that that should only be the case when note off velocity is >>>>> actually zero. >>>> I do agree with this, it totally makes sense to me. >>>> >>>> My 2 cents, >>>> Raphaël >>> Ok, but the core question still is: can we expect keyboards *with* note-off >>> velocity sensors to *never* send note-off velocity zero? >> Mmm, …yes it may be possible. >> it may be possible to send a zero release velocity if the firmware calculates a release velocity and includes a « timeout » for the maximum release time, and then decides that timed out values are zero. >> But I have not expressly tested it, and each manufacturer could have his own vision. >> >> I’ve been explained by Yamaha that the three contact rubbers are especially useful for retriggering calculation of half pressed keys, but they did not talk about release velocity calculation. >> Maybe Doug Gray could try the following on his SL88 : « Release the key as slow as possible in about 4 seconds » to try to reach the minimum release velocity value. >> As the keyboard rubber has three contacts, it could potentially send a zero release velocity if you reach a timeout between two contacts releases. I’m not sure if it is humanly possible to reach this potential timeout, as the contact points are really really close. The real duration of this timeout is not documented so needs testing. >> >> Raphaël >> >> _______________________________________________ >> Linuxsampler-devel mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel -- Raphaël |
From: Christian S. <sch...@li...> - 2022-01-03 18:17:53
|
For the SFZ users out there; experimental support for automatic reloading of modified .sfz files: http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4019 It works as simple as you might imagine: 1. Load an .sfz file as usual into LinuxSampler. 2. Open the .sfz file with an editor of your choice (a text editor, something more fancy specifically for SFZ, doesn't matter). 3. Change something in the sfz file. 4. Hit "Save" in the editor. The sampler will automatically reload the SFZ instrument at this point. CU Christian |