Menu
▾
▴
linuxsampler-devel
|
From: Christian S. <sch...@li...> - 2019-09-26 13:32:38
|
Hi all, I was reviewing our gig engine's LFO code and noticed that their behaviour does not match with GigaStudio's original LFO behaviour. So I planned to change that: 1. Our gig engine is using triangle LFOs whereas it looks like GigaStudio actually had sine LFOs. So my plan is to make sine to become default and make triangle available as option instead (as part of a new gig file format extension). Looks like GSt only ever had one function type (sine) for LFOs. 2. Start value of unsigned LFOs (which are amplitude LFO and filter cutoff LFO in the gig engine): I see that our implementation of those 2 (unsigned) LFOs start with wrong initial values; the very 1st rendered sample is 0 and then the function jumps to the middle of the value range and continues from there. That initial jump is certainly a bug that should be fixed. But what about the actual start point; does anybody know whether GSt starts with a) zero, or b) mid value range, or c) max. value on those 2 LFOs (amp LFO & filter cutoff LFO)? A start phase option for our LFOs (as format extension) might make sense as well BTW. CU Christian |
|
From: Ivan M. <iv...@ma...> - 2019-09-27 02:55:34
|
On 26/09/2019 14:32, Christian Schoenebeck wrote: > Hi all, Hi Christian, > > I was reviewing our gig engine's LFO code and noticed that their behaviour > does not match with GigaStudio's original LFO behaviour. So I planned to > change that: > > 1. Our gig engine is using triangle LFOs whereas it looks like GigaStudio > actually had sine LFOs. So my plan is to make sine to become default and > make triangle available as option instead (as part of a new gig file format > extension). Looks like GSt only ever had one function type (sine) for LFOs. Many thanks for discovering this. > > 2. Start value of unsigned LFOs (which are amplitude LFO and filter cutoff LFO > in the gig engine): I see that our implementation of those 2 (unsigned) > LFOs start with wrong initial values; the very 1st rendered sample is 0 and > then the function jumps to the middle of the value range and continues from > there. That initial jump is certainly a bug that should be fixed. But what > about the actual start point; does anybody know whether GSt starts with > a) zero, or b) mid value range, or c) max. value on those 2 LFOs (amp LFO & > filter cutoff LFO)? I checked the GSt3 editor and its audio window indicates that LFOs 1-3 start with the mid value. Seeing as the wave-forms in this window appear to be accurate representations of audio file contents and LFO settings the phase information should be accurate also. > A start phase option for our LFOs (as format extension) might make sense as > well BTW. This sounds like a good idea. > CU > Christian All the best, Ivan |
|
From: Christian S. <sch...@li...> - 2019-09-27 09:12:49
|
On Freitag, 27. September 2019 04:39:39 CEST Ivan Maguidhir wrote: > I checked the GSt3 editor and its audio window indicates that LFOs 1-3 > start with the mid value. Seeing as the wave-forms in this window appear > to be accurate representations of audio file contents and LFO settings > the phase information should be accurate also. 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? Do you have a chance to test the actual audio output to verify what the actual start levels of the 3 LFOs are? 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 |
|
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 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: 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: 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-28 18:13:34
Attachments:
VirtualBox_WindowsXP_28_09_2019_18_33_12.png
|
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-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-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: Christian S. <sch...@li...> - 2019-10-03 14:00:10
Attachments:
ls_lfo_ext.png
|
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: 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: Ivan M. <iv...@ma...> - 2019-10-08 03:53:13
Attachments:
linuxsampler-2.1.1.svn22_lfos.patch
|
Hi Christian I was missing some changes from my linuxsampler patch earlier. I've attached an updated one. All the best, Ivan |
|
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: 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: 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: 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: 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: 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 |
Thanks for helping keep SourceForge clean.
X