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: Andreas P. <and...@ou...> - 2019-12-08 10:32:15
|
Christian Schoenebeck wrote: > On Sonntag, 8. Dezember 2019 08:31:48 CET Andreas Persson wrote: >> Ivan Maguidhir wrote: >>> There's a problem however, I'm not able to load any instruments created >>> from scratch in gigedit as they cause GStudio3 to crash. In GSEdit3 I'm >>> able to load the same instruments but I get the warning message "File is >>> protected. Save As and Wave Export functions will be disabled." >> >> Hi, >> >> I don't think the crash and the warning are related. We have always had >> that warning, it's because we don't implement the encrypted checksum >> GSEdit uses as some kind of protection. > > I was not aware about that GSt crash before. Any suspicion about the cause of > that GSt crash? No, sorry, I don't know why it crashes. > Since Andreas assumes the crash to be a different issue. I didn't mean that the crash isn't related to the '3LS' tag, it might very well be. I just meant that the warning message is not related to the crash, as the warning has always been there. /Andreas |
|
From: Christian S. <sch...@li...> - 2019-12-08 09:52:00
|
On Sonntag, 8. Dezember 2019 08:31:48 CET Andreas Persson wrote: > Ivan Maguidhir wrote: > > There's a problem however, I'm not able to load any instruments created > > from scratch in gigedit as they cause GStudio3 to crash. In GSEdit3 I'm > > able to load the same instruments but I get the warning message "File is > > protected. Save As and Wave Export functions will be disabled." > > Hi, > > I don't think the crash and the warning are related. We have always had > that warning, it's because we don't implement the encrypted checksum > GSEdit uses as some kind of protection. I was not aware about that GSt crash before. Any suspicion about the cause of that GSt crash? Ivan, you could check your assumption and replace the defines for our own chunk names, namely LIST_TYPE_3LS and LIST_TYPE_RTIS in src/gig.h by something else. Since Andreas assumes the crash to be a different issue. You might also just copy any original GSt .gig file from some commercial source and just replace some gain value with gigedit there, since that would mean less changes to the gig file than creating one from scratch. CU Christian |
|
From: Andreas P. <and...@ou...> - 2019-12-08 07:32:04
|
Ivan Maguidhir wrote: > There's a problem however, I'm not able to load any instruments created > from scratch in gigedit as they cause GStudio3 to crash. In GSEdit3 I'm > able to load the same instruments but I get the warning message "File is > protected. Save As and Wave Export functions will be disabled." Hi, I don't think the crash and the warning are related. We have always had that warning, it's because we don't implement the encrypted checksum GSEdit uses as some kind of protection. /Andreas |
|
From: Ivan M. <iv...@ma...> - 2019-12-08 00:17:22
|
Hi Christian I get the following behaviour in GSEdit3 using the new gain option: Gain of -96 to 0dB in gigedit => Attenuation of 0 to 96dB, 6dB boost set to '0 - No' in GSEdit Gain of 6dB in gigedit => Attenuation of 0dB, 6dB boost set to '1 - Yes' in GSEdit Gain > than 0dB other than 6dB => Attenuation of the negative of the gain value, 6dB boost set to '0 - No' in GSEdit There's a problem however, I'm not able to load any instruments created from scratch in gigedit as they cause GStudio3 to crash. In GSEdit3 I'm able to load the same instruments but I get the warning message "File is protected. Save As and Wave Export functions will be disabled." I believe the problem is that libgig is using a chunk for an LS extension which was already in use by GStudio3. Specifically, I think the culprit is the '3LS' tag and that the GigaStudio developers were planning to use this for a future copy protection feature. The 3LS tag was added at libgig revision 2584. Apologies for not spotting this sooner but I didn't really know how to use gigedit and GSEdit until earlier this year. Let me know if there's anything else I can do. All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-12-07 16:10:09
|
Hi, I just committed a change to Gigedit which allows fine graded positive gain values, and therefore I dropped the old "Gain +6dB" checkbox from Gigedit. So you can now set any gain value between -96dB..+96dB. Before that change, only -96dB..0dB and +6dB were allowed, which was quite unpleasant since sometimes you just need to raise volume by e.g. +1.5dB or so which was so far not possible at all. Does this break behaviour with the original GigaStudio player? Unless you retain the old allowed value range of -96..0,+6 then definitely no; because if you checked "+6 dB" before then Gigedit will simply show it now as 6.00 value and vice versa if you set the value to exactly 6.00 in Gigedit and save the .gig file then you get the exact same data on gig file level as if you were using the +6dB checkbox before. However if you are using any new range value like e.g. +2.00 dB or +12.43dB? Well, I am not sure, but I am optimistic that even that should work as expected with Tascam's player, even though never supported by the original GigaStudio instrument editor. Because if you were checking "+6dB" before, that actually did not set a flag, it was always using a gain value on gig file level perfectly linear to any other possible -96dB..0dB value, which suggests that Tascam multiplied that value from the gig file with a constant factor to get the final floating point gain factor, exactly like we do in LS. If I am wrong, you tell me. ;-) CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-10-20 20:45:58
|
Hi Christian Many thanks for the reply earlier! On 20/10/2019 16:18, Christian Schoenebeck wrote: > > Well, since we support both gtk3 and gtk2, and since there are no plans to > drop gtk2 support, it was good to know though that there was an gtk2 issue. That's great that both will be supported going forward and that the patch was helpful. > The behaviour difference in this case was that gtk3 is a bit more aggressive > about triggering implied repaint events on its own, whereas gtk2 handles this > more conservatively and assumes applications always to tell gtk when to > repaint. On the other hand, those implied repaint events are one of the > reasons why gtk3 feels bit more sluggish sometimes compared to gtk2, even on > very recent & decent hardware. That makes sense. I think I prefer the gtk2 way though. > CU > Christian All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-10-20 15:18:26
|
On Mittwoch, 16. Oktober 2019 23:44:13 CEST Ivan Maguidhir wrote: > Whoops. It was my fault, I didn't have the gtk3-devel package installed. > The configure script now detects gtk3 properly. Well, since we support both gtk3 and gtk2, and since there are no plans to drop gtk2 support, it was good to know though that there was an gtk2 issue. I am definitely not promoting people should switch gtk version. Use what you like. ;-) The behaviour difference in this case was that gtk3 is a bit more aggressive about triggering implied repaint events on its own, whereas gtk2 handles this more conservatively and assumes applications always to tell gtk when to repaint. On the other hand, those implied repaint events are one of the reasons why gtk3 feels bit more sluggish sometimes compared to gtk2, even on very recent & decent hardware. CU Christian |
|
From: Rui N. C. <rn...@rn...> - 2019-10-17 14:19:57
|
Hello there! It's coming true: the old bunch of Qstuff*, QjackCtl [1], Qsynth [2], Qsampler [3], QXGEdit [4], QmidiCtl [5] and QmidiNet [6], are all catching up and aligning to the magical version 0.6.0 :) That's all pretty much and enough for now ;)... ** QjackCtl - JACK Audio Connection Kit Qt GUI Interface [1] ** QjackCtl 0.6.0 (autumn'19) is out! QjackCtl is a(n ageing yet modern, not so 'simple' anymore) Qt [7] application to control the JACK [8] sound server, for the Linux Audio [12] infrastructure. 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.6.0.tar.gz - source package: https://download.sf.net/qjackctl/qjackctl-0.6.0-39.rncbc.suse.src.rpm - binary package: https://download.sf.net/qjackctl/qjackctl-0.6.0-39.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qjackctl/qjackctl-0.6.0-39.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 Change-log: - Graph: avoid self-connecting over their own ports when client nodes are selected as a whole group; also try to match port-types in a orderly fashion when connecting multiple selected ports. - Changing current JACK buffer size from Setup dialog (cf. Settings / Frames/Period) may now take effect just immediately ;) - An 'Apply' button as been added to the Setup dialog; ask whether to restart the JACK audio server, if any settings are changed. - Added alternate yet non-official CMake build option. - Fix HiDPI display screen effective support (Qt >= 5.6). - Command line arguments (--start, --preset=[label] and --active-patchbay=[path]) are passed and take effect on the current singleton/unique application instance, when enabled and already running. - System-tray icon context menu has been refactored to be exactly the same as the main-window context menu that is re-instantiated on demand. - Make sure compiler flags comply to c++11 as standard. ** Qsynth - A fluidsynth Qt GUI Interface [2] ** Qsynth 0.6.0 (autumn'19) is out! 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.6.0.tar.gz - source package: https://download.sf.net/qsynth/qsynth-0.6.0-19.rncbc.suse.src.rpm - binary package: https://download.sf.net/qsynth/qsynth-0.6.0-19.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qsynth/qsynth-0.6.0-19.x86_64.AppImage 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 Change-log: - Updated the old yet non-official CMake build option. - Fix HiDPI display screen effective support (Qt >= 5.6). - System-tray icon context menu has been refactored to be exactly the same as the main-window context menu that is re-instantiated on demand. - Make sure compiler flags comply to c++11 as standard. ** Qsampler - A LinuxSampler Qt GUI Interface [3] ** Qsampler 0.6.0 (autumn'19) is out! Qsampler is a LinuxSampler [11] GUI front-end application written in C++ around the Qt framework [7] using Qt Designer. 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.6.0.tar.gz - source package: https://download.sf.net/qsampler/qsampler-0.6.0-31.rncbc.suse.src.rpm - binary package: https://download.sf.net/qsampler/qsampler-0.6.0-31.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qsampler/qsampler-0.6.0-31.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 Change-log: - Added alternate yet non-official CMake build option. - Fix HiDPI display screen effective support (Qt >= 5.6). - Make sure compiler flags comply to c++11 as standard. ** QXGEdit - A Qt XG Editor [4] ** QXGEdit 0.6.0 (autumn'19) is out! 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. 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.6.0.tar.gz - source package: https://download.sf.net/qxgedit/qxgedit-0.6.0-19.rncbc.suse.src.rpm - binary package: https://download.sf.net/qxgedit/qxgedit-0.6.0-19.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qxgedit/qxgedit-0.6.0-19.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 Change-log: - Added alternate yet non-official CMake build option. - Fix HiDPI display screen effective support (Qt >= 5.6). - Refactored all singleton/unique application instance setup logic away from X11/Xcb hackery. - Make sure compiler flags comply to c++11 as standard. ** QmidiCtl - A MIDI Remote Controller via UDP/IP Multicast [5] ** QmidiCtl 0.6.0 (autumn'19) is out! 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. 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.6.0.tar.gz - source package: https://download.sf.net/qmidictl/qmidictl-0.6.0-19.rncbc.suse.src.rpm - binary package: https://download.sf.net/qmidictl/qmidictl-0.6.0-19.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qmidictl/qmidictl-0.6.0-19.x86_64.AppImage - Android packages: https://download.sf.net/qmidictl/qmidictl-0.6.0-19.armeabi-v7a.apk https://download.sf.net/qmidictl/qmidictl-0.6.0-19.arm64-v8a.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 Change-log: - Populate automatically the network interface combo-box with detected interface names (after merge request by plcl aka. Pedro López-Cabanillas, while on qmidinet). - Complete rewrite of all the basic network interface code, while using the Qt5 framework as far as needed to support IPv4 and IPv6 seamless and interchangeably. - Added alternate yet non-official CMake build option. - Fix HiDPI display screen effective support (Qt >= 5.6). - Added left/right swipe gestures to navigate over mixer strip pages. - Make sure compiler flags comply to c++11 as standard. ** QmidiNet - A MIDI Network Gateway via UDP/IP Multicast [6] ** QmidiNet 0.6.0 (autumn'19) is out! 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. 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.6.0.tar.gz - source package: https://download.sf.net/qmidinet/qmidinet-0.6.0-19.rncbc.suse.src.rpm - binary package: https://download.sf.net/qmidinet/qmidinet-0.6.0-19.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qmidinet/qmidinet-0.6.0-19.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 Change-log: - Populate automatically the network interface combo-box with detected interface names (after merge request by plcl aka. Pedro López-Cabanillas, thanks). - Complete rewrite of all the basic network interface code, while using the Qt5 framework as far as needed to support IPv4 and IPv6 seamless and interchangeably. - Added alternate yet non-official CMake build option. - Fix HiDPI display screen effective support (Qt >= 5.6). - Make sure compiler flags comply to c++11 as standard. 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 http://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 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/2045 Enjoy && Have fun! -- rncbc aka Rui Nuno Capela |
|
From: Ivan M. <iv...@ma...> - 2019-10-16 21:44:27
|
Hi Christian Whoops. It was my fault, I didn't have the gtk3-devel package installed. The configure script now detects gtk3 properly. All the best, Ivan |
|
From: Ivan M. <iv...@ma...> - 2019-10-16 20:34:36
|
Hi Christian On 16/10/2019 19:02, Christian Schoenebeck wrote: > I just wonder why it did not work there on your machine. For me it worked > before both on Linux as well as on Mac, so I wonder what's the difference. > Are you still using Gtk2? > Yes, that was it. I'm using Fedora 30 and I have both gtk2 and gtk3 installed simultaneously. gigedit's configure appears to detect and use gtk2 in this situation. I'm looking at configure.ac to try and figure out why gtk3 isn't used. > CU > Christian All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-10-16 18:02:43
|
On Dienstag, 8. Oktober 2019 14:50:30 CEST Christian Schoenebeck wrote: > On Dienstag, 8. Oktober 2019 01:00:15 CEST Ivan Maguidhir wrote: > > Hi Christian > > > > I really like the graphical render of the LFO settings! The attached > > gigedit patch connects all of the LFO controls to queue_draw() so that > > the graphic gets redrawn while the user is making changes to any of them. > > Hmm, and I thought I already took care that all LFO parameter changes in > Gigedit would cause the LFO preview wave to be redrawn. I'll check that > again, thanks for your patch! I just committed your fix to gigedit regarding the LFO preview not being redrawn. Thanks! I just wonder why it did not work there on your machine. For me it worked before both on Linux as well as on Mac, so I wonder what's the difference. Are you still using Gtk2? BTW we just updated our automatic build server, new compilers and all builds for all architectures are running fine now again (i.e. Windows snapshots are available again). In case anybody encounters issues with the snapshot builds, let us know! CU Christian |
|
From: Christian S. <sch...@li...> - 2019-10-08 12:50:43
|
On Dienstag, 8. Oktober 2019 01:00:15 CEST Ivan Maguidhir wrote:
> Hi Christian
>
> I really like the graphical render of the LFO settings! The attached
> gigedit patch connects all of the LFO controls to queue_draw() so that
> the graphic gets redrawn while the user is making changes to any of them.
Hmm, and I thought I already took care that all LFO parameter changes in
Gigedit would cause the LFO preview wave to be redrawn. I'll check that again,
thanks for your patch!
> I noticed while I was using gigedit that the range for Control Depth and
> Internal Depth of LFO1 and LFO2 is 0..1200. This should actually be
> -4800..4800 according to GSEdit3. The same values are present in LS when
> the LFO1 and LFO2 objects are being instantiated. Also the logic for
> enabling all three LFOs tests if the Control Depth and Internal Depth
> are > 0 instead of if they are != 0.
I think you are confusing some things here. The allowed value range for the
internal depth and control depth parameters for LFOs was always 0..+1200 with
Gigasampler/GigaStudio. So that's the allowed and observed value range for
these raw parameters stored in gig files and they're always positive.
On sampler side (LS/GSt) this can effectively become 0..+2400 exactly when you
enable both internal depth and a controller depth (e.g. by selecting Depth
Controller: "internal+modwheel" in Gigedit). Because in that case internal
depth and control depth are added (on LS and GSt side, not in the gig file
however!), so the sampler's effective LFO depth becomes internal_depth +
controller_depth in that case.
> diff -Naur linuxsampler_orig/src/engines/common/AbstractVoice.cpp
> linuxsampler_mod/src/engines/common/AbstractVoice.cpp ---
> linuxsampler_orig/src/engines/common/AbstractVoice.cpp 2019-10-03
> 16:44:03.484547000 +0100 +++
> linuxsampler_mod/src/engines/common/AbstractVoice.cpp 2019-10-08
> 04:47:03.067579768 +0100 @@ -29,8 +29,8 @@
>
> AbstractVoice::AbstractVoice(SignalUnitRack* pRack):
> pSignalUnitRack(pRack) {
>
> pEngineChannel = NULL;
>
> - pLFO1 = new LFOClusterUnsigned(1.0f); // amplitude LFO (0..1
> range)
> - pLFO2 = new LFOClusterUnsigned(1.0f); // filter LFO (0..1 range)
> + pLFO1 = new LFOClusterSigned(4800.0f); // amplitude LFO
> (-4800..4800 range)
> + pLFO2 = new LFOClusterSigned(4800.0f); //
> filter LFO (-4800..4800 range)>
> pLFO3 = new LFOClusterSigned(1200.0f); // pitch LFO (-1200..+1200
> range)
You don't really want that change on sampler side. ;-) I think your motivation
was to resemble what you see in GSt's editor preview pane on Gigedit side. But
making the (rendered output) value range of LFO1 and LFO2 to become signed
would break their behaviour on LS side. What that would do is you'd get e.g.
negative cutoff frequencies with LFO2; and LFO1 would start to flip polarity
of the audio signal at every half LFO phase.
So really, LFO1 (volume) and LFO2 (filter cutoff frequency) must always have a
positive output value range per definition of their intended purpose.
CU
Christian
|
|
From: Ivan M. <iv...@ma...> - 2019-10-08 03:53:13
|
Hi Christian I was missing some changes from my linuxsampler patch earlier. I've attached an updated one. All the best, Ivan |
|
From: Ivan M. <iv...@ma...> - 2019-10-07 23:00:37
|
Hi Christian I really like the graphical render of the LFO settings! The attached gigedit patch connects all of the LFO controls to queue_draw() so that the graphic gets redrawn while the user is making changes to any of them. I noticed while I was using gigedit that the range for Control Depth and Internal Depth of LFO1 and LFO2 is 0..1200. This should actually be -4800..4800 according to GSEdit3. The same values are present in LS when the LFO1 and LFO2 objects are being instantiated. Also the logic for enabling all three LFOs tests if the Control Depth and Internal Depth are > 0 instead of if they are != 0. I've attached two patches to show you where I think changes need to be made, these are tentative. All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-10-03 14:00:10
|
On Sonntag, 29. September 2019 21:06:14 CEST Ivan Maguidhir wrote: > On 29/09/2019 11:17, Christian Schoenebeck wrote: > > Ok then I guess I'll change that in our gig engine to: > > * LFO1 (volume): mid start level > > * LFO2 (cutoff): mid start level > > * LFO3 (pitch): max start level > > Sounds good. Thanks Christian. Ok, I committed all my changes. Like discussed: 1. Default (gig) LFO wave form is now sine (a.k.a. sinus). 2. You can now switch the wave form with gigedit to one of sine, triangle, square or saw. 3. There is now a LFO phase displacement option as well. 4. Additionally I also added a graphical render of the LFO wave form as preview of the LFO settings to gigedit (see attached screen shot). Unlike GSt this preview takes all LFO settings into account, not just frequency. 5. And finally LFO3 got a "flip phase" option as well. Testers appreciated. CU Christian |
|
From: Christian S. <sch...@li...> - 2019-09-30 09:25:23
|
On Sonntag, 29. September 2019 12:53:18 CEST Maurits Lamers wrote: > Hi all, > > Using information from this mailinglist and some code I found online I > managed to compile arm64 linuxsampler packages for Ubuntu 16.04 and 18.04. > I would like to contribute my changes to the project. > > The arm and arm64-specific changes are in > https://github.com/mauritslamers/linuxsampler/commit/12f4e447e2498f8c9d1c3f > 7a98b76e8e697ad479 Well, since the sampler's minimum build requirement is now to have at least a C++14 compatible compiler, it is probably time considering to switch to std::atomic that was introduced with C++11, and thus starting to get rid of all assembly atomic code in the sampler's code base, instead of adding asm atomic code for yet another architecture: https://en.cppreference.com/w/cpp/atomic/atomic There are four major advantages of using std::atomic: 1. it compiles on all systems (OSes) and for all architectures (CPUs), and since that C++ header uses compiler extensions for the actual atomicity under the hood (e.g. __c11_atomic_store), it is the compiler which would generate the actual atomic CPU instructions. So we would 2. always have up to date atomic implementations, 3. allow the compiler to optimize code using atomicity and 4. thread sanatizers would start to work correctly and would not emit that huge amount of false alarms that we currently get with our asm atomic code. CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-09-29 19:06:42
|
On 29/09/2019 11:17, Christian Schoenebeck wrote: > > Ok then I guess I'll change that in our gig engine to: > > * LFO1 (volume): mid start level > * LFO2 (cutoff): mid start level > * LFO3 (pitch): max start level Sounds good. Thanks Christian. > unless somebody has objections. > > CU > Christian All the best, Ivan |
|
From: Maurits L. <mau...@gm...> - 2019-09-29 10:53:29
|
Hi all, Using information from this mailinglist and some code I found online I managed to compile arm64 linuxsampler packages for Ubuntu 16.04 and 18.04. I would like to contribute my changes to the project. The arm and arm64-specific changes are in https://github.com/mauritslamers/linuxsampler/commit/12f4e447e2498f8c9d1c3f7a98b76e8e697ad479 I put up the resulting deb packages as releases in the same repository. cheers, Maurits |
|
From: Christian S. <sch...@li...> - 2019-09-29 10:17:52
|
On Samstag, 28. September 2019 20:13:16 CEST Ivan Maguidhir wrote: > > As for LFO1: it seems you were right, according to your audio demo file it > > seems as if LFO1 starts with a mid value (instead of a max value that we > > currently have in our implementation). > > Yes, from listening I wasn't actually sure. I had to look at it in > Audacity. > > > As for LFO2: It's a bit harder to tell, probably it also starts with a mid > > value, it is not as clear to see/hear as with LFO 1. > > Yes. It's very hard to tell. One iteration of the LFO from 0 to max to 0 > again takes about 2 seconds. From the start of the recording to the > first 0 is 1.5 seconds so I think that means it starts with the mid value. > > > As for LFO3: That result is actually a bit surprising. From your file it > > rather sounds as if LFO3 would start at max value, and not at mid (neutral > > pitch). Was there maybe some kind of mistake? > > Yes, from looking at it in Audacity I think it starts with max value. I > don't think there was a mistake. I've attached an image of the LFO > settings I used for you to check. Thanks again. Ok then I guess I'll change that in our gig engine to: * LFO1 (volume): mid start level * LFO2 (cutoff): mid start level * LFO3 (pitch): max start level unless somebody has objections. CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-09-28 18:13:34
|
On 28/09/2019 12:51, Christian Schoenebeck wrote: > Thanks! No problem. > I looked and listened to your audio files. > > As for LFO1: it seems you were right, according to your audio demo file it > seems as if LFO1 starts with a mid value (instead of a max value that we > currently have in our implementation). Yes, from listening I wasn't actually sure. I had to look at it in Audacity. > As for LFO2: It's a bit harder to tell, probably it also starts with a mid > value, it is not as clear to see/hear as with LFO 1. Yes. It's very hard to tell. One iteration of the LFO from 0 to max to 0 again takes about 2 seconds. From the start of the recording to the first 0 is 1.5 seconds so I think that means it starts with the mid value. > As for LFO3: That result is actually a bit surprising. From your file it > rather sounds as if LFO3 would start at max value, and not at mid (neutral > pitch). Was there maybe some kind of mistake? Yes, from looking at it in Audacity I think it starts with max value. I don't think there was a mistake. I've attached an image of the LFO settings I used for you to check. Thanks again. > CU > Christian All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-09-28 11:51:44
|
On Samstag, 28. September 2019 00:55:32 CEST Ivan Maguidhir wrote: > On 27/09/2019 20:25, Christian Schoenebeck wrote: > > That way you should clearly hear the difference whether the amp LFO starts > > with max. volume or mid value volume. > > > > For LFO 2 and LFO 3 you would do the same steps. > > Hi Christian > > I've updated the wave files I linked to earlier. Of course they weren't > right because there was no modulation taking place. I didn't have the > LFO settings applied to all regions of my square wave instrument. What I > don't understand is why there was a difference in volume between > modwheel at 0 and modwheel at 127 previously when the LFOs only had the > default settings (e.g. control depth of 0)? > Many thanks. Thanks! I looked and listened to your audio files. As for LFO1: it seems you were right, according to your audio demo file it seems as if LFO1 starts with a mid value (instead of a max value that we currently have in our implementation). As for LFO2: It's a bit harder to tell, probably it also starts with a mid value, it is not as clear to see/hear as with LFO 1. As for LFO3: That result is actually a bit surprising. From your file it rather sounds as if LFO3 would start at max value, and not at mid (neutral pitch). Was there maybe some kind of mistake? CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-09-27 22:55:47
|
On 27/09/2019 20:25, Christian Schoenebeck wrote: > That way you should clearly hear the difference whether the amp LFO starts > with max. volume or mid value volume. > > For LFO 2 and LFO 3 you would do the same steps. Hi Christian I've updated the wave files I linked to earlier. Of course they weren't right because there was no modulation taking place. I didn't have the LFO settings applied to all regions of my square wave instrument. What I don't understand is why there was a difference in volume between modwheel at 0 and modwheel at 127 previously when the LFOs only had the default settings (e.g. control depth of 0)? Many thanks. All the best, Ivan |
|
From: Ivan M. <iv...@ma...> - 2019-09-27 21:45:00
|
On 27/09/2019 20:25, Christian Schoenebeck wrote: > > Hmm, sounds not very reliable for this issue. Yes, you're right. > > That way you should clearly hear the difference whether the amp LFO starts > with max. volume or mid value volume. > > For LFO 2 and LFO 3 you would do the same steps. Thanks a million for the detailed instructions. I've included links to the three output wave files. In Audacity, the max peaks for the sections with the modwheel at 127 are about 9dB quieter than the sections with the modwheel at 0. I think that means that the GSt3 editor's graphics are, as it turns out, accurate and that all three LFOs start at mid value. http://www.maguidhir.ie/lfo_test/lfo1_result.wav http://www.maguidhir.ie/lfo_test/lfo2_result.wav http://www.maguidhir.ie/lfo_test/lfo3_result.wav > Does that make sense to you? Yes it's starting to make sense. > CU > Christian All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-09-27 19:25:24
|
On Freitag, 27. September 2019 17:24:43 CEST Ivan Maguidhir wrote: > On 27/09/2019 10:12, Christian Schoenebeck wrote: > > That graphic in the GSt editor might as well just be some symbolic > > representation of the LFO wave form, or does the graphic of the LFO > > function change when you alter any parameter? > > Yes, the wavelength of the waveform representing the LFO in the graphic > changes as the frequency parameter is changed. That's the only parameter > that has any effect. The start position of the LFO stays the same (mid > value) for all frequency values. Hmm, sounds not very reliable for this issue. > > Do you have a chance to test the actual audio output to verify what the > > actual start levels of the 3 LFOs are? > > I tried this but I wasn't sure what to look for in the output. If you > could recommend a test tone to use I'll try it again. Well, if you get some sound out of that installation then it should not be so hard to do those tests: 1. Just a pick any sample that's immediately there (without a slow attack in the sample itself that is) and that's long enough (i.e. looped), probably some very simple synthetic sample like a raw saw or sqaure or so might be the best, then 2. in the GSt editor make sure that amplitude "attack time" is set to minimum to ensure the sample is immediately there when being triggered. Then do the actual LFO settings, for instance for LFO 1 (amplitude): 3. Set LFO's "Internal Depth" to zero. 4. Select some arbitrary LFO MIDI controller that you have there (e.g. Modulation Wheel). By default you see Controller = internal in GSt editor. 5. Set LFO's "Control Depth" to maximum (i.e. 1200). 6. Set LFO's frequency very low (or lowest) so that's easier to hear on which value the LFO actually starts. Now at the actual playback: 7. Push the assigned MIDI controller (e.g. modwheel) to its maximum value on your MIDI keyboard. 8. Trigger and hold a note on your keyboard. You should now hear LFO modulating the volume on your sample. 9. Release the note and now push the assigned MIDI controller (e.g. modwheel) on your MIDI keyboard to its minimum value, so that the LFO is now disabled=neutral. 10. Trigger and hold again a note on your keyboard. You should now hear the sample being played without any volume modulation, since the LFO is off. That way you should clearly hear the difference whether the amp LFO starts with max. volume or mid value volume. For LFO 2 and LFO 3 you would do the same steps. ---- Our assumption years ago was that GSt's LFO 1 (amp/volume) and LFO 2 (filter cutoff frequency) would start at maximum value, whereas LFO 3 (pitch) would start at mid (in case of pitch = neutral) value. Does that make sense to you? CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-09-27 15:24:57
|
On 27/09/2019 10:12, Christian Schoenebeck wrote: > > That graphic in the GSt editor might as well just be some symbolic > representation of the LFO wave form, or does the graphic of the LFO function > change when you alter any parameter? Yes, the wavelength of the waveform representing the LFO in the graphic changes as the frequency parameter is changed. That's the only parameter that has any effect. The start position of the LFO stays the same (mid value) for all frequency values. > > Do you have a chance to test the actual audio output to verify what the actual > start levels of the 3 LFOs are? I tried this but I wasn't sure what to look for in the output. If you could recommend a test tone to use I'll try it again. > > CU > Christian All the best, Ivan |
161 messages has been excluded from this view by a project administrator.
