Distortion when playing chords

Hello,

when I play a couple of notes at the same time (e.g. a chord with high velocity on the Grand Piano instrument), the output distorts. My first reaction was to turn down the volume (in alsamixer), but it distorts even when the mixer volume is very low. When I play the exact number of notes but with a lower velocity the distortion goes away. I guess that means that the distortion happens before the mixer, when all the notes are summed together.

Did anyone noticed that too?
Is there a solution for this? A volume parameter in definition.txt would be great, but for now even a general volume change for sample playback would be fine (in samplerbox.py).

(I’m using a Raspberry Pi 3 with a Griffin iMic USB and the „enhanced“ version http://homspace.xs4all.nl/homspace/samplerbox/index.html , but the distortion also happened with the original samplerbox software. Apart from the distortion everything else works fine.)

do u just a sound card?

Hello Lars,
I don't recognize this. I guess that using the volume/selection slider on the iMic does not make a difference either (the problem seems to be earlier); it needs control of the volume entering alsa.

In the original version the samples are played at full sample volume, but this can be changed by the globalvolume parameter. (you set it in configuration and find the exact place of control in the audiocallback procedure, "b = globalvolume").
So you can try to play with that parameter, it's quite easy as it is in the configuration.txt.
If it works, you can also make it work in my version. For this you have to re-introduce the "b = globalvolume" statement, with globalvolume being the value that works for you.

However I'm afraid that this will be in a too late stage as well because we play with already received audio.

In my version the volume value is controlled via played velocity before entering alsa. I suggest to test with reducing this in the midi callback. You'll find two statements there:

• velmixer = 127
  This is for original sampler mode with maximum velocity value ("play at sample level").
• velmixer = velocity
  This is for playing at played velocity (and samples normalized).
  You can experiment with a multiplication factor (for instance try: 1270.8 and velocity0.8)

Please share your experience, If above is the case, I want to make an extra configuration parameter for this (or reintroduce the original volumehandling as an extra option, depending on your findings).

Sorry, some formatting error occurred :-)
i suggest tor try "velmixer = 127 value" and "velmixer = velocity value", wit value for instance being 0.8. etcetera

Damn, same formatting stuff: before "value" there is an asterisk with which I want to show a multiply and no fromatting to italic ...

Thanks for helping me, Hans!
I didn’t play around with the „globalvolume“ parameter (yet), but I did try your suggestion with the multiply value, and that worked!! It really depends on the samples used, e.g. with the grand piano it was as low as 0.3 for clean playback.
So if that value could be set via definition.txt for each sample set, that would be great!

just to make that clear to myself: with that value I only adjust volume level, but still the whole velocity range (with all the different samples) would be used, right? It’s just that the overall volume is dropped. Correct?

I made a short recording and measured the volume drop: so a value of 0.3 equals a drop of -12dB. I guess that's a pretty normal value for a multisample instrument, I would be fine with that static value. But of course a parameter in definition.txt would make it more flexible.

btw when I searched for "globalvolume" in the original file there is the comment "-12dB default global volume" in the same line. Maybe it was intended to be -12dB globally..

Anyway, already works much better now.

Hello Lars, good to hear this works.
To answer your concern first: yes, the sample file is chosen using the original velocity. What we now are doing affects the volume send to the mixer. In fact it is some sort of gain control per sample set.
As for the globalvolume: This volume is meant for the next step: feeding the box's signal into the stage sound system. I deliberately moved to using the alsamixer as this is the actual output, so I never really bothered about the -12dB etc.. (In fact I normalize my samples to -6dB and play using velocitymode=accurate.)
Till now I kept the volume parameter in the definition.txt as a bypass to react on sample set volumes if needed, knowing this was not a good solution as the volume set by the buttons on a particular event will be changed to the fixed level of the sample set.

Now I have created an update which should be able to read definition.txt like "%%gain=0.8", doing what you actually tested (thanks). With this you can normalize the different sample sets without touching the WAV files (which is ofcourse the "royal" option, but labor intensive). This value is just a multiplication factor; I have not investigated the relation to dB.
I have removed the %%volume parameter as this now lost its last use.

Practical note: at this moment my samplerbox is in our rehearsal studio, so I can test end of this week at the earliest. If you need it quick, I can make the script available to you, but without any guarantee :-)
Since it is already working better for you, I suggest to wait.

To be complete: This solution is also compatible with the solution for velocity shift as created by Erik (http://www.nickyspride.nl/sb2/). Currently I have no purpose for this yet, but it is such an interesting idea that I may implement at a later stage. Just copying Erik's implementation will not work as it depends on control bars on his keyboard.. so it needs some thought...

That sounds great! I'm not in a hurry so I gladly wait till you have that ready.

Since we are already talking about definition.txt, I have another feature suggestion: I noticed that there is a (global) FADEOUTLENGTH parameter in samplerbox.py. Is it possible to make this parameter variable for each sample set? That would be really helpful e.g. for more pad-like sounds that need a long release time.

Hi Lars,
The update passed the tests = it works. I've updated the webpages and replaced the script with the new version. Hope it works for you too.

Fadeoutlength is not going to be as simples as this gain parameter. This is a technical remark; it is hard to implement a non-fixed fadeoutlength correctly,
Functional aspect is important too, in other words: what do you want to achieve / what is the problem you want to solve?
For instance: I am triggering the box with a drumpad. Drums have by nature a very short touch, so by default the samples are played too short in keyboard mode. But with drumpads you can often configure the gate time, even per pad (with this you emulate the key to be pressed longer, so it takes longer before the release=fadeout starts). This what I do and untill now I did not have the need for longer release=fadeout.

This may illustrate: https://en.wikipedia.org/wiki/Synthesizer#Attack_Decay_Sustain_Release_.28ADSR.29_envelope
Gate time is ADS (so if short enough you won't even get the full attack when release already starts).
Fadeout is the R=release only.

I've now implemented a parameter for release/fadeout value per sample set. It seems to work OK.
The value is a number indicating the fadeout time in tenths of seconds. The original samplerbox uses a fixed value of approx 0.3 seconds, so the default is %%release=3
I've updated the webpages and replaced the script with the new version. Again I hope it works for you too.
http://homspace.xs4all.nl/homspace/samplerbox/index.html

Hey Hans,
thank you so much!! I tried both the gain and the release parameter and everything works perfectly! Very convenient.
Yes, the release parameter is very helpful for pads or other sounds that need to fade out smoothly and shouldn't end abruptly as soon as you release the keys (or step off the sustain pedal).

I only made a couple of sample programs yet, will do a bit more and see how it works with them. But it seems like a perfect solution.

Cheers