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
|
Dec
|
|
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 |
|
From: Doug G. <dou...@gm...> - 2022-01-03 01:59:04
|
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 |
|
From: Jerash m. <rmo...@gm...> - 2022-01-02 17:19:24
|
> 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 |
|
From: Christian S. <sch...@li...> - 2022-01-02 13:53:43
|
On Sonntag, 2. Januar 2022 14:42:55 CET Jerash music wrote: > Having worked with (and repairing) many midi keyboard controllers, I can say > that release velocity is not very common. Mainly available on high range > keyboard, often with weighted keys, piano style. > > Keyboard rubbers with triple sensors offer greater definition so to have > the release velocity, but it can be implemented in the device firmware or > not, at manufacturer’s choice. Keyboard rubber with double sensor could > also do release velocity, but may miss some when the key is not fully > pressed before actual release. Here, again, the sent message depends on > firmware implementation. > >I suggest that that should only be the case when note off velocity is > >actually zero. > I do agree with this, it totally makes sense to me. > > My 2 cents, > Raphaël Ok, but the core question still is: can we expect keyboards *with* note-off velocity sensors to *never* send note-off velocity zero? CU Christian |
|
From: Jerash m. <rmo...@gm...> - 2022-01-02 13:43:08
|
Having worked with (and repairing) many midi keyboard controllers, I can say that release velocity is not very common. Mainly available on high range keyboard, often with weighted keys, piano style. Keyboard rubbers with triple sensors offer greater definition so to have the release velocity, but it can be implemented in the device firmware or not, at manufacturer’s choice. Keyboard rubber with double sensor could also do release velocity, but may miss some when the key is not fully pressed before actual release. Here, again, the sent message depends on firmware implementation. >I suggest that that should only be the case when note off velocity is actually zero. I do agree with this, it totally makes sense to me. My 2 cents, Raphaël > Le 2 janv. 2022 à 13:00, Doug Gray <dou...@gm...> a écrit : > > For the record my Studiologic SL88 keyboard controller does send note off with a measured velocity value. I have verified this myself since the sfz file I am using has key off sounds. This velocity is measured at key release. > I see the documentation states that the note on velocity is reused for note off but I suggest that that should only be the case when note off velocity is actually zero. > I don’t think it is likely at least for triple sensor that ‘most midi controllers’ send zero velocity note-off. It would be good to verify this. > > Doug Gray > >> On 2 Jan 2022, at 6:28 pm, Jan Flikweert <fl...@ze...> wrote: >> >> JanFl. Wrote:" Thank you very much for this solution and the things I >> learned. It works." >> >> The solution does not work for gig files. >> >> The funny thing is that gig files can also play a release sample after aloop >> from a sample. The dimension is called releasetrigger. One dimension has a >> normal loop and the release sample has no loop. >> >> Kind regards, >> >> >> Jan Fl. >> >> >> >> _______________________________________________ >> Linuxsampler-devel mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Christian S. <sch...@li...> - 2022-01-02 12:18:12
|
Mja, that behaviour could likewise easily be adjusted for the gig engine as I did for the sfz engine this week. From the sfz docs I see, people seem to expect that the note-on velocity is always used instead of the note-off velocity? Hence I just changed that exactly this way for the sfz engine this week. For the gig engine: I agree with Dough here, if you have a keyboard that supports note-off velocity, you want to use it. But the fact that most MIDI keyboards just send note-off velocity zero still applies. So this must coexist. Doug, does your keyboard *ever* send a note-off with velocity zero? If it does not, then simply checking for velocity zero might indeed be the way to go. Maybe even for the sfy engine, too? CU Christian On Sonntag, 2. Januar 2022 13:00:28 CET Doug Gray wrote: > For the record my Studiologic SL88 keyboard controller does send note off > with a measured velocity value. I have verified this myself since the sfz > file I am using has key off sounds. This velocity is measured at key > release. I see the documentation states that the note on velocity is reused > for note off but I suggest that that should only be the case when note off > velocity is actually zero. I don’t think it is likely at least for triple > sensor that ‘most midi controllers’ send zero velocity note-off. It would > be good to verify this. > > Doug Gray > > > On 2 Jan 2022, at 6:28 pm, Jan Flikweert <fl...@ze...> wrote: > > > > JanFl. Wrote:" Thank you very much for this solution and the things I > > learned. It works." > > > > The solution does not work for gig files. > > > > The funny thing is that gig files can also play a release sample after > > aloop from a sample. The dimension is called releasetrigger. One > > dimension has a normal loop and the release sample has no loop. > > > > Kind regards, > > > > > > Jan Fl. > > > > > > > > _______________________________________________ > > Linuxsampler-devel mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Doug G. <dou...@gm...> - 2022-01-02 12:00:42
|
For the record my Studiologic SL88 keyboard controller does send note off with a measured velocity value. I have verified this myself since the sfz file I am using has key off sounds. This velocity is measured at key release. I see the documentation states that the note on velocity is reused for note off but I suggest that that should only be the case when note off velocity is actually zero. I don’t think it is likely at least for triple sensor that ‘most midi controllers’ send zero velocity note-off. It would be good to verify this. Doug Gray > On 2 Jan 2022, at 6:28 pm, Jan Flikweert <fl...@ze...> wrote: > > JanFl. Wrote:" Thank you very much for this solution and the things I > learned. It works." > > The solution does not work for gig files. > > The funny thing is that gig files can also play a release sample after aloop > from a sample. The dimension is called releasetrigger. One dimension has a > normal loop and the release sample has no loop. > > Kind regards, > > > Jan Fl. > > > > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Jan F. <fl...@ze...> - 2022-01-02 07:27:31
|
JanFl. Wrote:" Thank you very much for this solution and the things I learned. It works." The solution does not work for gig files. The funny thing is that gig files can also play a release sample after aloop from a sample. The dimension is called releasetrigger. One dimension has a normal loop and the release sample has no loop. Kind regards, Jan Fl. |
|
From: Jan F. <fl...@ze...> - 2022-01-01 17:52:35
|
CU wrote: Fixed. Works now as expected: http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4013 The order of the regions in the sfz file does not matter for LS BTW. I just saw before that it does for other players. CU Christian -------------- Thank you very much for this solution and the things I learned. It works. Kind regards, Jan Flikweert |
|
From: Christian S. <sch...@li...> - 2021-12-31 18:12:03
|
On Donnerstag, 30. Dezember 2021 22:04:37 CET you wrote: > Hi, > > I tried flipping the order of those regions. That did not work. > > Kind regards, Fixed. Works now as expected: http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=4013 The order of the regions in the sfz file does not matter for LS BTW. I just saw before that it does for other players. CU Christian |
|
From: Jan F. <fl...@ze...> - 2021-12-30 21:04:46
|
Hi, I tried flipping the order of those regions. That did not work. Kind regards, Jan Flikweert -------------------- CU Wrote: Have you tried flipping the order of those two regions, i.e. release trigger region after attack region? CU Christian |
|
From: Christian S. <sch...@li...> - 2021-12-30 18:22:29
|
On Mittwoch, 29. Dezember 2021 21:59:13 CET Jan Flikweert wrote: > Christian, > > Thanks for your explanation. I conclude that it is only needed to set notes > on/off. Stops do not need on/off. If you do not need a instrument, do not > sent notes to it. > > The next file sample-release-060-C.wav contains a sinus tone 220 hz. The > file sample-Default-060-C.wav a normal principal. > > Using Fantasia / Linuxsampler works well. > jOrgan / Linuxsampler does not work for the release part (only note on/off!) > jOrgan / sForzando works correct > > sForzando is not advisable because it cannot handle large organs. > Linuxsampler provides for me a beautiful organ with 150 instruments/stops. > Of course they are not needed all at one time, but LS can handle them, load > them. > > Kind regards, > > Jan Flikweert > > ------------------------------------- > Test.sfz > <group> > lokey=36 > hikey=96 > > <region> > sample=release-060-C.wav > trigger=release > loop_mode=one_shot > > <region> > sample=Default-060-C.wav > loop_mode=loop_sustain > loop_start=97041 > loop_end=163161 > ------------------------------------------- Have you tried flipping the order of those two regions, i.e. release trigger region after attack region? CU Christian |
|
From: Christian S. <sch...@li...> - 2021-12-30 18:02:46
|
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
|
161 messages has been excluded from this view by a project administrator.
