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: Ivan M. <iv...@ma...> - 2020-01-20 01:26:27
|
Hi Christian On 19/01/2020 21:20, Christian Schoenebeck wrote: > Hi Ivan, > > I just realized now your patch probably does not what you wanted it to: > http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/gig.cpp? > r1=3656&r2=3655&pathrev=3656 > > You see the problem? Nothing jumped out at me straight away. The code calls SaveString for existing 3gnm chunks in the _3gnl list using their Chunk* as the ck parameter. When the end of the _3gnl list is reached SaveString is called, from that point onward, with NULL as the ck parameter resulting in new 3gnm chunks being created for those strings and appended to the _3gnl list. This should result in 128 3gnm chunks containing the empty string regardless of the number of groups in the file. Group::UpdateChunks should call SaveString with the group name set by the user, leaving the remaining 3gnm chunks set to the empty string. Sorry if I'm missing something obvious. > CU > Christian > All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2020-01-19 21:20:19
|
Hi Ivan, I just realized now your patch probably does not what you wanted it to: http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/gig.cpp? r1=3656&r2=3655&pathrev=3656 You see the problem? CU Christian |
|
From: Rui N. C. <rn...@rn...> - 2019-12-22 19:36:22
|
Greetings! The old core of QStuff*, QjackCtl [1], Qsynth [2], Qsampler [3], QXGEdit [4], QmidiCtl [5] and QmidiNet [6], are all here and now bumped to **version 0.6.1**, making it the first batch for the last (northern) winter solistice of the decade. So here they go... ** QjackCtl - JACK Audio Connection Kit Qt GUI Interface [1] ** QjackCtl 0.6.1 (winter'19) released! 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.1.tar.gz - source package: https://download.sf.net/qjackctl/qjackctl-0.6.1-40.rncbc.suse.src.rpm - binary package: https://download.sf.net/qjackctl/qjackctl-0.6.1-40.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qjackctl/qjackctl-0.6.1-40.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:1 - Custom color (palette) theme editor introduced; color (palette) theme changes are now effective immediately, except on default. - Second attempt to fix the yet non-official though CMake build configuration. - When using autotools and ./configure --with-qt=..., it is also necessary to adjust the PKG_CONFIG_PATH environment variable (after a merge request by plcl aka. Pedro López-Cabanillas, while on qmidinet [6], thanks). ** Qsynth - A fluidsynth Qt GUI Interface [2] ** Qsynth 0.6.1 (winter'19) 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.6.1.tar.gz - source package: https://download.sf.net/qsynth/qsynth-0.6.1-40.rncbc.suse.src.rpm - binary package: https://download.sf.net/qsynth/qsynth-0.6.1-40.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qsynth/qsynth-0.6.1-40.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: - Custom color (palette) theme editor introduced; color (palette) theme changes are now effective immediately, except on default. - Second attempt to fix the yet non-official though CMake build configuration. - When using autotools and ./configure --with-qt=..., it is also necessary to adjust the PKG_CONFIG_PATH environment variable (after a merge request by plcl aka. Pedro López-Cabanillas, while on qmidinet [6], thanks). ** Qsampler - A LinuxSampler Qt GUI Interface [3] ** Qsampler 0.6.1 (winter'19) released! 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.1.tar.gz - source package: https://download.sf.net/qsampler/qsampler-0.6.1-40.rncbc.suse.src.rpm - binary package: https://download.sf.net/qsampler/qsampler-0.6.1-40.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qsampler/qsampler-0.6.1-40.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: - Custom color (palette) theme editor introduced; color (palette) theme changes are now effective immediately, except on default. - Second attempt to fix the yet non-official though CMake build configuration. - When using autotools and ./configure --with-qt=..., it is also necessary to adjust the PKG_CONFIG_PATH environment variable (after a merge request by plcl aka. Pedro López-Cabanillas, while on qmidinet [6], thanks). ** QXGEdit - A Qt XG Editor [4] ** QXGEdit 0.6.1 (winter'19) 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. 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.1.tar.gz - source package: https://download.sf.net/qxgedit/qxgedit-0.6.1-20.rncbc.suse.src.rpm - binary package: https://download.sf.net/qxgedit/qxgedit-0.6.1-20.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qxgedit/qxgedit-0.6.1-20.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: - Custom color (palette) theme editor introduced; color (palette) theme changes are now effective immediately, except on default. - Second attempt to fix the yet non-official though CMake build configuration. - When using autotools and ./configure --with-qt=..., it is also necessary to adjust the PKG_CONFIG_PATH environment variable (after a merge request by plcl aka. Pedro López-Cabanillas, while on qmidinet [6], thanks). ** QmidiCtl - A MIDI Remote Controller via UDP/IP Multicast [5] ** QmidiCtl 0.6.1 (winter'19) 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. 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.1.tar.gz - source package: https://download.sf.net/qmidictl/qmidictl-0.6.1-20.rncbc.suse.src.rpm - binary package: https://download.sf.net/qmidictl/qmidictl-0.6.1-20.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qmidictl/qmidictl-0.6.1-20.x86_64.AppImage - Android packages: https://download.sf.net/qmidictl/qmidictl-0.6.1-20.armeabi-v7a.apk https://download.sf.net/qmidictl/qmidictl-0.6.1-20.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: - Provide a default IPv6 address, and feedback to the user in the options dialog (after a merge request by plcl aka. Pedro López-Cabanillas, while on [url=https://qmidinet.sourceforge.io]qmidinet[/url]). - When using autotools and ./configure --with-qt=..., it is also necessary to adjust the PKG_CONFIG_PATH environment variable (after a merge request by plcl aka. Pedro López-Cabanillas, while on [url=https://qmidinet.sourceforge.io]qmidinet[/url], thanks). ** QmidiNet - A MIDI Network Gateway via UDP/IP Multicast [6] ** QmidiNet 0.6.1 (winter'19) 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. 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.1.tar.gz - source package: https://download.sf.net/qmidinet/qmidinet-0.6.1-20.rncbc.suse.src.rpm - binary package: https://download.sf.net/qmidinet/qmidinet-0.6.1-20.rncbc.suse.x86_64.rpm - AppImage [20] package: https://download.sf.net/qmidinet/qmidinet-0.6.1-20.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: - Second attempt to fix the yet non-official though CMake build configuration. - Provide a default IPv6 address, and feedback to the user in the options dialog (after a merge request by plcl aka. Pedro López-Cabanillas, thanks). - When using ./configure --with-qt=... it is also necessary to adjust the PKG_CONFIG_PATH environment variable (also by plcl aka. Pedro López-Cabanillas). 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 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 && Be Happy! ;) -- rncbc aka Rui Nuno Capela |
|
From: Christian S. <sch...@li...> - 2019-12-22 14:28:01
|
Hi guys, I added new filter types to the LS gig engine, which includes these new filter type options on Gigedit side of course. These are actually the filter types that we already had on sfz engine side. The reason why I decided to enable them on gig side as well, was that the official GSt "lowpass turbo" filter type has some DSP issues: it often causes inpleasant audible clicks / bumps. I am not sure if that's a problem in our lowpass turbo filter DSP implementation or whether that issues already existed with the original GigaStudio lowpass turbo implementation as well. Anyway, since these new filter types are (once again) an extension to the official gig format, I obviously had some freedom to deviate behaviour for these new filter types: I always disliked the behaviour of the "minimum cutoff" parameter, which so far was simply handled like this: finalCutoff = MAX(cutoffCCValue, minCutoff); The problem with the latter was that you always ended up with a "dead" controller zone, so a certain controller value range where the controller would not do anything. Instead of doing that, with the new filter types I re-interpreted this "minimum cutoff" parameter which still defines a "minimum cutoff", but the range is now automatically spanned over the entire 0..127 controller range instead to prevent such a dead zone. I am not sure yet, but probably it would even make sense to apply this change to the official GSt filter types as well? CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-12-19 23:19:52
|
Hi Christian On 19/12/2019 12:39, Christian Schoenebeck wrote: > > Let's postpone that. I won't have the time to check that file soon. We'll keep > an eye on this issue, and if it really happens again we'll take closer look. No problem. I'll keep the instrument in case we need it later. > So what do we do about it, let's drop '3ddp' from libgig code again then? I'm going to contradict myself for the hundredth time this month now - GSEdit *is* actually reading the '3ddp' chunks. I obviously didn't set a breakpoint correctly before. I found out what ddp stands for it's: Dimension Display Position. I've also identified the functions used by GSEdit for reading and writing the 10-16 bytes. I'm trying to figure out from them how to generate the bytes in libgig. > Best regards, > Christian Schoenebeck All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-12-19 12:39:52
|
On Sonntag, 15. Dezember 2019 21:59:37 CET Ivan Maguidhir wrote: > No it was a mono sample alright. Actually, i just realised that I still > have the instrument. It was created on the 7th of December so that could > explain we can't reproduce the same behaviour now. If it's useful I can > send you the instrument as it's only 280k in size. Let's postpone that. I won't have the time to check that file soon. We'll keep an eye on this issue, and if it really happens again we'll take closer look. > > Interestingly, the '3ddp' chunk is only written by GSEdit and never > > read. Which makes me think it's only of use to GSt when playing > > instruments for effects or the mixer (or something similar) as the > > '3ddp' values seem to be switches: 0x00 for off 0xFF for on. I'm about > > to test this theory now. > > I checked this and the '3ddp' chunk isn't read by GSt either. It doesn't > look like it's used at all. So what do we do about it, let's drop '3ddp' from libgig code again then? Best regards, Christian Schoenebeck |
|
From: Ivan M. <iv...@ma...> - 2019-12-15 21:59:32
|
On 15/12/2019 20:59, Ivan Maguidhir wrote: > > > Interestingly, the '3ddp' chunk is only written by GSEdit and never > read. Which makes me think it's only of use to GSt when playing > instruments for effects or the mixer (or something similar) as the > '3ddp' values seem to be switches: 0x00 for off 0xFF for on. I'm about > to test this theory now. > > I checked this and the '3ddp' chunk isn't read by GSt either. It doesn't look like it's used at all. All the best, Ivan |
|
From: Ivan M. <iv...@ma...> - 2019-12-15 21:00:00
|
On 15/12/2019 13:34, Christian Schoenebeck wrote: > In gig v1 even. I can't remember having seen those chunks before with GSt < 3 > files. But if it really turns out that these chunks were always there, then we > can still change that of course and add them for all gig file format versions. > > In my TODO list back from that time (2003) I only had a '3dnl' chunk not being > supported by libgig on Region level yet: > http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/TODO?view=markup The '3ddp' chunks are there in all of the XSample Set instruments from Best Service that I have. These were all created with GSEdit v1. Andreas is correct about the '3ddp' chunk's size, however it's also 10 bytes for gig v1. '3dnl' is the Dimension Region name list chunk for gig v1 and gig v2. '3dnm' replaced '3dnl' as the Dimension Region name list chunk for gig v3. Interestingly, the '3ddp' chunk is only written by GSEdit and never read. Which makes me think it's only of use to GSt when playing instruments for effects or the mixer (or something similar) as the '3ddp' values seem to be switches: 0x00 for off 0xFF for on. I'm about to test this theory now. > > Maybe you were dropping a stereo sample in and misinterpreted the > automatically created stereo dimension (a.k.a. "audio channel" dimension) as > duplicate chunks. No it was a mono sample alright. Actually, i just realised that I still have the instrument. It was created on the 7th of December so that could explain we can't reproduce the same behaviour now. If it's useful I can send you the instrument as it's only 280k in size. > > CU > Christian > All the best, Ivan |
|
From: Andreas P. <and...@ou...> - 2019-12-15 14:27:43
|
Christian Schoenebeck wrote: > In my TODO list back from that time (2003) I only had a '3dnl' chunk not being > supported by libgig on Region level yet: > http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/TODO?view=markup I also had a look in an old text file of mine. There I listed 3dnm, 3dpp and 3dnl under "things not needed to be fixed". No explanation, but I guess they were not needed for the file to work in GSEdit. Further notes from that file: "3dnm/nam0, nam1, ... 0-31 - name of dimension 32 + 12*i - name of split 3dpp - most often filled with FF. Length 10 for gig v2, length 16 for v3. 3dnl - unknown empty list, only in gig v2. Maybe name of dimensions?" /Andreas |
|
From: Christian S. <sch...@li...> - 2019-12-15 13:34:31
|
On Samstag, 14. Dezember 2019 20:05:35 CET Ivan Maguidhir wrote: > > Regarding the '3dnm' and '3ddp' chunks: I moved that to UpdateChunks() > > since I found that the more appropriate place to be, and I assumed that > > these chunks are just required for GigaStudio >= v3, hence these are only > > added there and auto removed if user switches back to a previous gig > > format version: > > http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=365 > > 7 > That sounds good. Actually, I found the '3ddp' tag in several v1.0 > instruments that I have. I'll have another look at GSEdit3 later today > to see if I can find out exactly what both of these tags do. In gig v1 even. I can't remember having seen those chunks before with GSt < 3 files. But if it really turns out that these chunks were always there, then we can still change that of course and add them for all gig file format versions. In my TODO list back from that time (2003) I only had a '3dnl' chunk not being supported by libgig on Region level yet: http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/TODO?view=markup > > Then your changes to AddDimension(): I could not reproduce that issue and > > accordingly I haven't committed that part of your patch yet. In my tests, > > when I start with an Instrument with no dimension and then add another > > dimension I never ended up with duplicate RIFF chunks. Plus, as far as I > > can see it, your suggested changes would introduce other bugs, because > > e.g. you would be assigning the same DimensionRegion object several times > > to different 'pDimensionRegions' array entries. So are you sure you still > > have issues with latest libgig SVN version that we would need to address > > here? > > That's weird. I'm not seeing any duplication of the DimensionRegion > chunks with the latest libgig from SVN. > So, you can disregard the last part of the patch. Sorry about that. Maybe you were dropping a stereo sample in and misinterpreted the automatically created stereo dimension (a.k.a. "audio channel" dimension) as duplicate chunks. At least so far I couldn't reproduce a problem regarding duplicate chunks there, so I leave it as is for now, but I'll keep an eye on it. CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-12-14 19:05:49
|
Hi Christian On 14/12/2019 17:26, Christian Schoenebeck wrote: > Ok, I just committed 2 parts of your patch. I committed your 128 '3gnm' chunks > patch unmodified: > http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=3656 Thanks! > Regarding the '3dnm' and '3ddp' chunks: I moved that to UpdateChunks() since I > found that the more appropriate place to be, and I assumed that these chunks > are just required for GigaStudio >= v3, hence these are only added there and > auto removed if user switches back to a previous gig format version: > http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=3657 That sounds good. Actually, I found the '3ddp' tag in several v1.0 instruments that I have. I'll have another look at GSEdit3 later today to see if I can find out exactly what both of these tags do. > > Then your changes to AddDimension(): I could not reproduce that issue and > accordingly I haven't committed that part of your patch yet. In my tests, when > I start with an Instrument with no dimension and then add another dimension I > never ended up with duplicate RIFF chunks. Plus, as far as I can see it, your > suggested changes would introduce other bugs, because e.g. you would be > assigning the same DimensionRegion object several times to different > 'pDimensionRegions' array entries. So are you sure you still have issues with > latest libgig SVN version that we would need to address here? That's weird. I'm not seeing any duplication of the DimensionRegion chunks with the latest libgig from SVN. So, you can disregard the last part of the patch. Sorry about that. > > CU > Christian > > All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-12-14 17:26:52
|
On Freitag, 13. Dezember 2019 18:13:00 CET Ivan Maguidhir wrote: > On 13/12/2019 13:40, Christian Schoenebeck wrote: > > Nice job! :) > > > > Give me some time, I probably have to make some minor adjustments to your > > patch. Ok, I just committed 2 parts of your patch. I committed your 128 '3gnm' chunks patch unmodified: http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=3656 Regarding the '3dnm' and '3ddp' chunks: I moved that to UpdateChunks() since I found that the more appropriate place to be, and I assumed that these chunks are just required for GigaStudio >= v3, hence these are only added there and auto removed if user switches back to a previous gig format version: http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision&revision=3657 Then your changes to AddDimension(): I could not reproduce that issue and accordingly I haven't committed that part of your patch yet. In my tests, when I start with an Instrument with no dimension and then add another dimension I never ended up with duplicate RIFF chunks. Plus, as far as I can see it, your suggested changes would introduce other bugs, because e.g. you would be assigning the same DimensionRegion object several times to different 'pDimensionRegions' array entries. So are you sure you still have issues with latest libgig SVN version that we would need to address here? CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-12-13 17:13:28
|
On 13/12/2019 13:40, Christian Schoenebeck wrote: > > Nice job! :) > > Give me some time, I probably have to make some minor adjustments to your > patch. > > Thanks! No problem. I'm glad it's helpful. I'll take a look at the GSt3 crash that happens with newly created gigedit instruments next. > CU > Christian > All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-12-13 13:40:56
|
On Donnerstag, 12. Dezember 2019 04:38:45 CET Ivan Maguidhir wrote: > Hi Christian > > On 11/12/2019 12:30, Christian Schoenebeck wrote: > > Hmm... I wonder what GSt actually expects on gig file level if no loop was > > enabled. I mean it's probably not a big deal if GSt spits out a warning on > > such gig files, but would be nice to have if fixed on libgig side if > > reasonable. > > > > Can you identify what GSt instrument editor changes/fixes after you > > created a simple .gig file from scratch with Gigedit with no loop on? > > Yes, I managed to get GSEdit3 to output debug logs showing the structure > (as it sees it) of input gig files (like gigdump in LS). This showed me > several differences between gig files created with gigedit and the ones > corrected by GSEdit3. The problem causing the 'irregular structure' > message was the wrong number of '3gnm' strings - there should always be 128. > > There was also a duplicate DimensionRegion chunk being created when > designing an instrument from scratch with gigedit. > > Finally, I discovered two new chunks from the official spec. They always > seem to have the same content and I have no idea what they do :-) I just > wanted to rule them out as a cause of the problem. > > I've attached a patch with these changes. Nice job! :) Give me some time, I probably have to make some minor adjustments to your patch. Thanks! CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-12-12 03:38:59
|
Hi Christian On 11/12/2019 12:30, Christian Schoenebeck wrote: > > Hmm... I wonder what GSt actually expects on gig file level if no loop was > enabled. I mean it's probably not a big deal if GSt spits out a warning on > such gig files, but would be nice to have if fixed on libgig side if > reasonable. > > Can you identify what GSt instrument editor changes/fixes after you created a > simple .gig file from scratch with Gigedit with no loop on? Yes, I managed to get GSEdit3 to output debug logs showing the structure (as it sees it) of input gig files (like gigdump in LS). This showed me several differences between gig files created with gigedit and the ones corrected by GSEdit3. The problem causing the 'irregular structure' message was the wrong number of '3gnm' strings - there should always be 128. There was also a duplicate DimensionRegion chunk being created when designing an instrument from scratch with gigedit. Finally, I discovered two new chunks from the official spec. They always seem to have the same content and I have no idea what they do :-) I just wanted to rule them out as a cause of the problem. I've attached a patch with these changes. > > CU > Christian > All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-12-11 12:30:52
|
On Dienstag, 10. Dezember 2019 20:41:54 CET Ivan Maguidhir wrote: > On 10/12/2019 10:25, Christian Schoenebeck wrote: > > Maybe it's really just the loop setting that made the difference there. > > Because that indeed causes a data structure change. > > Yes, you're right. I created an instrument from scratch again with > gigedit. Without Loops enabled I get the 'irregular structure' message > in GSEdit3 and with Loops enabled the message doesn't appear. Using > GSEdit3 to re-save the instrument solves the problem also. Hmm... I wonder what GSt actually expects on gig file level if no loop was enabled. I mean it's probably not a big deal if GSt spits out a warning on such gig files, but would be nice to have if fixed on libgig side if reasonable. Can you identify what GSt instrument editor changes/fixes after you created a simple .gig file from scratch with Gigedit with no loop on? CU Christian |
|
From: Christian S. <sch...@li...> - 2019-12-11 12:24:49
|
On Dienstag, 10. Dezember 2019 19:04:01 CET Ivan Maguidhir wrote: > Hi Christian > > On 10/12/2019 12:06, Christian Schoenebeck wrote: > > Did you check "Apply to:" ... "All regions" checkbox and "All Dimension > > Regions" checkbox in Gigedit before you did these gain changes? > > Yes, I had applied the gain setting to all regions of each instrument in > gigedit. I loaded the instruments one by one in GSt3 again just now and > I got the attached result. I must have loaded the same instrument in > multiple channels yesterday as I didn't modify the instruments in the > interim. Now that looks much better! :) So the old allowed gain settings look all fine with GSt, and GSt player even supports the +3d gain setting correctly (even though never supported by GSt's instrument editor). Only the +12dB gain setting seems to be ignored by GSt and it used +6dB instead. So either GSt player limits the gain setting to max. +6dB or there was some compression going on. But it rather looks like gain parameter limit of +6dB on first sight. Anyway, looks good to me! Thanks! CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-12-10 19:42:16
|
Hi Christian On 10/12/2019 10:25, Christian Schoenebeck wrote: > > Maybe it's really just the loop setting that made the difference there. > Because that indeed causes a data structure change. Yes, you're right. I created an instrument from scratch again with gigedit. Without Loops enabled I get the 'irregular structure' message in GSEdit3 and with Loops enabled the message doesn't appear. Using GSEdit3 to re-save the instrument solves the problem also. > CU > Christian > All the best, Ivan |
|
From: Ivan M. <iv...@ma...> - 2019-12-10 18:04:22
|
Hi Christian On 10/12/2019 12:06, Christian Schoenebeck wrote: > > Did you check "Apply to:" ... "All regions" checkbox and "All Dimension > Regions" checkbox in Gigedit before you did these gain changes? Yes, I had applied the gain setting to all regions of each instrument in gigedit. I loaded the instruments one by one in GSt3 again just now and I got the attached result. I must have loaded the same instrument in multiple channels yesterday as I didn't modify the instruments in the interim. > CU > Christian All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-12-10 12:07:06
|
On Montag, 9. Dezember 2019 22:24:49 CET Ivan Maguidhir wrote: > Hi Christian > > I made multiple copies of a commercial gig instrument with gigedit > setting the gain option to -3dB, 0dB, +3dB, +6dB, +12dB. I've attached > the audio output of GSt3 when the same MIDI note is played on each > instrument in succession. Not really the result I would expect. Looking at your audio file 1st note is -3dB (ok), 2nd note is 0dB (ok), but then 3rd is also 0dB (instead of +3dB, maybe ok because its not allowed by GSt), then 4th is -3dB instead of +6dB which is definitely wrong because that's a setting supported by GSt, and well 5th note is again 0dB instead of +12dB (but that's again an unsupported option in GSt). Just to make this clear about deciBels in general: 0dB means "neutral" / no volume change, +6dB means increasing volume by factor 2, -6dB means half volume, +12dB means volume increase by factor 4, -12dB means volume reduced to 1/4th. So you can easily see those volume relations already with a wave editor. Did you check "Apply to:" ... "All regions" checkbox and "All Dimension Regions" checkbox in Gigedit before you did these gain changes? > I only realised after doing this that the > instrument I used is a version 1.0 gig. I'm not sure if this would make > a difference? I can redo it with a v3 instrument if necessary. Not sure either, but this gain setting is fairly old and already existed including that +6dB option when I wrote the first line of libgig code in 2003. CU Christian |
|
From: Christian S. <sch...@li...> - 2019-12-10 10:25:44
|
On Montag, 9. Dezember 2019 01:53:05 CET Ivan Maguidhir wrote: > Also, the message about 'irregular structure' I mentioned earlier isn't > displayed when Loops and Filters are both enabled and the instrument > name is set (in Instrument Properties) in gigedit. Hmmm... I can't see the connection. The info you can enter by the Instruments Properties dialog is written to DLS Info chunks, and these DLS Info chunks are always written, no matter if you entered something or not. The instrument name field (if not provided) is then filled with "NONAME" by default (see DLS.cpp). The filter enabled setting is just a bit flag on gig file level (see VCFEnabled in gig.cpp). So that filter setting does not have any influence on any data structure. Maybe it's really just the loop setting that made the difference there. Because that indeed causes a data structure change. CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-12-09 21:25:06
|
Hi Christian I made multiple copies of a commercial gig instrument with gigedit setting the gain option to -3dB, 0dB, +3dB, +6dB, +12dB. I've attached the audio output of GSt3 when the same MIDI note is played on each instrument in succession. I only realised after doing this that the instrument I used is a version 1.0 gig. I'm not sure if this would make a difference? I can redo it with a v3 instrument if necessary. All the best, Ivan |
|
From: Ivan M. <iv...@ma...> - 2019-12-09 00:53:21
|
Hi Christian On 08/12/2019 19:05, Christian Schoenebeck wrote: > > Does that mean we can leave the current chunk names for our gig format > extensions? So after you changed the chunk names you got the exact same > behaviour as yesterday? Yes. GSEdit3 displays the 'protected' message even when I create instruments with alternative values for the LIST_TYPE_3LS and LIST_TYPE_RTIS chunk IDs. Also, the message about 'irregular structure' I mentioned earlier isn't displayed when Loops and Filters are both enabled and the instrument name is set (in Instrument Properties) in gigedit. > BTW those 2 custom RIFF chunks should actually just be created by libgig if > you really used those custom features in Gigedit. Yes I know. They weren't actually included in the instruments I created yesterday. The '3LS' I spotted in my hex editor was part of the sample data. > > And that's the same GSt crash you mentioned yesterday? Or do you talk about > multiple different GSt crashes? > The crash has nothing to do with using Save As as I thought earlier. Instruments created from scratch with gigedit cause a crash. Commercial and self-made instruments created with GSEdit and re-saved with gigedit don't cause it. Oddly, if I load a gigedit authored instrument in GSEdit3 and exit the program without making any changes it asks me if I want to 'Save Changes'. If I click Yes the saved instrument doesn't crash GSt3 but also doesn't produce sound as intended. > CU > Christian All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-12-08 19:05:59
|
On Sonntag, 8. Dezember 2019 19:22:20 CET Ivan Maguidhir wrote: > Hi Christian > > On 08/12/2019 09:51, Christian Schoenebeck wrote: > > 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. > > I think Andreas is right. On modifying the chunk IDs for LIST_TYPE_3LS > and LIST_TYPE_RTIS I get the same warning about the file being > protected. I also now get the message: "This file has an irregular > structure. One possible explanation is that it was written by an > application other than the GigaStudio Editor. A full save will be > required if you modify the file." but I think this is probably something > to do with the new chunk ID values I chose. can Does that mean we can leave the current chunk names for our gig format extensions? So after you changed the chunk names you got the exact same behaviour as yesterday? I mean, I just added these 2 chunk types just 2 months ago, so now is still an appropriate time to rename them if required. Later on (i.e. after the next official release) that would become more complicated and nasty. BTW those 2 custom RIFF chunks should actually just be created by libgig if you really used those custom features in Gigedit. > > 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. > > I made two copies of a commercial instrument and set the gain to +6dB > and +12dB respectively using gigedit. Both copies load correctly in > GSEdit3 and GStudio3. The +6dB instrument is louder than the original, > but the +12dB instrument seems to be the same volume as the original > instrument. I'll do a more scientific test later and record the audio > output. > > I didn't use Save As in gigedit to create the copies above as > instruments I created with it caused GStudio3 to crash. And that's the same GSt crash you mentioned yesterday? Or do you talk about multiple different GSt crashes? CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-12-08 18:22:42
|
Hi Christian On 08/12/2019 09:51, Christian Schoenebeck wrote: > 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. I think Andreas is right. On modifying the chunk IDs for LIST_TYPE_3LS and LIST_TYPE_RTIS I get the same warning about the file being protected. I also now get the message: "This file has an irregular structure. One possible explanation is that it was written by an application other than the GigaStudio Editor. A full save will be required if you modify the file." but I think this is probably something to do with the new chunk ID values I chose. can > 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. I made two copies of a commercial instrument and set the gain to +6dB and +12dB respectively using gigedit. Both copies load correctly in GSEdit3 and GStudio3. The +6dB instrument is louder than the original, but the +12dB instrument seems to be the same volume as the original instrument. I'll do a more scientific test later and record the audio output. I didn't use Save As in gigedit to create the copies above as instruments I created with it caused GStudio3 to crash. > CU > Christian All the best, Ivan |
161 messages has been excluded from this view by a project administrator.
