Sound breaks up at faster tempos

Hey guys.
So I've made some progress with my setup:

-HansEhv build
-Pi Zero
-PhatDac
-DIN MIDI working

I want to use this as a drum sampler, and have it hooked up to my Beatstep Pro for sequencing. When I trigger notes manually, everything seems fine and as expected. However, when I am feeding a sequence to the SamplerBox, there is a problem:

At lower tempos, it is working fine, but if I increase the tempo to a certain point, the sound gets all garbled, like it's breaking up (kinda sounds like farts:)). This problem is worst through DIN Midi. Through USB, I can reach slightly higher tempos before the problem occurs. The problem is worse when more notes are being played.

It seems that the SamplerBox isn't able to handle quick successions of multiple notes, like in drum sequences.

I am unsure whether this is a limitation of the software, or the Pi Zero hardware. I have tried messing with the blocksize in samplerbox.py. It does seem to have an effect at higher values, but is not enough to fix the problem entirely, as when I push it past 1280 or so, the sound starts to worsen again. My polyphony is set to 24.

Questions:

1. Has anyone else observed this kind of issue?
2. Does the software take advantage of multiple CPU cores ( in multicore Pis)?
3. Any ideas on things to try?

Thanks

Just to add, I did have to use this solution to get MIDI working: https://openenergymonitor.org/emon/node/12412

This new issue may or may not be related to that.

Hi Nimbo,
Sounds like a performance issue. I recognize the garbled sound as an effect I got after changing samplerbox_audio module in way that it got more cpu-intensive (that's in fact the reason why some parts look unstructured... it's because this is faster).
From you usage I conclude that you possibly do not need any fadeout of sounds.
If so you can try to set %%release to zero as this will save computations for every active note at every audio callback. If this has effect, then we can dig further in the direction of eliminating code not needed for your specific usage. I'll be watching this space :-)
Samplerbox does not use python multithreading (yet, nice hint), so changing your zero with a 3B will not show improvement in that area.
However the 3B is 64bit which may have effect, as well as the fact it's processor may faster by nature (did not read anything about that though...).
I don't think the midi solution affects this. Differences between the two modes can be caused by the extra serial library used by the direct midi.

Hi Hans, and thanks for your input.
Yeah, the Pi3B actually has a 1.2ghz chip, so 20% more than Zero, in addition to being 64bit. Also has more RAM. However, if we can get it to work on the Zero, I think it's the better option for this kind of application, considering cost and size.

My gut also tells me that this is a performance issue, so if you're willing to help me figure it out, that would be very much appreciated. My understanding of coding is basic at the best.

You are correct that I won't need fadeout. I also wouldn't need things like sustain pedal and pitch bend. It would be good to make the code leaner by removing this kind of thing.

If we can sort this out, I think it would be a great idea to make a drum-specific build, to make this more "plug and play" for new users. I absolutely love the concept of SamplerBox, as there really aren't any retail products to deliver this kind of functionality at a reasonable cost. MIDI samplers aren't really the fashion anymore:)

Anyway, back to your suggestion. I have trawled through samplerbox.py, and am confused as to where I should be setting %%release to 0.
I'm seeing some variables set by entries in definitions.txt, but I'm not using a definition file for my presets. Is it Boxrelease?
Alternatively, should I just create a definition file to test? Would that suit our purpose here?

I should also probably mention that I have USE_ALSA_MIXER set to False. The PhatDac has no hardware control, and therefore there is no name for MIXER_CONTROL. SamplerBox wouldn't run unless the script contained a valid name here, so I set USE_ALSA_MIXER=False to bypass the check.

Hi Nimbo,
Yes you can set the BOXRELEASE to 0 to change the basic default (or set a higher value than 30, just to prove mechanism).
I imagined you'd use a definition.txt to get playing at sample length instead of the play length set by the Beatstep, so I didn't mention this possibility.

Let's first see whether testing shows this is indeed an area of concern for your usage before starting with stripping code ... :-)
Because this might imply removing the "fill in the missing notes", which is a backbone piece of the original code. But indeed unneeded for drum machine usage.

Re ALSA-MIXER - that's why it's an option :-)

First of all, setting BOXRELEASE=0 helps immensely. The problem is not completely gone, but it's a lot better now.

About definitions.txt, I hadn't considered sample length vs play length, as I hadn't noticed sample cutoff in testing. I have now checked more closely, and can hear that certain samples do cut off when releasing the controller pad early. However the changelog in samplerbox.py does state that the default for mode is "once" (April 10 2016)?

So anyway, I have tried to use a definition file now. However, whenever there's a definiton file present in a preset folder, that preset won't load. The LCD just says "Empty preset".

This is the definition.txt I am trying to use:

%%mode=once
%%velmode=sample
%%release=0
%%fillnote=N

Obviously I'm doing something wrong, but I can't figure it out?

Also, in theory, would setting mode=once use less CPU resources than mode=keyb?

So I got definition.txt working by adding:

midinote*.wav

Should have realized that the file takes over sample loading:)

No noticeable performance difference with mode=once by the way.

Hi Nimbo,
You caught me; luckily I'm not getting paid for this, it would have cost me a raise :-)
In a later update I changed the default playmode to VELSAMPLE (this is set in the local config) without putting it into the change log.

Your test result is clear.
This aspect is located in a place where the total of concurrent playing wav's is important.
Are you indeed playing much notes at the same time when it occurs?
I never got further than about 6-8 notes and had no problems with that on a Pi-2.
Anyway I'm going to check the code for further stripping while keeping drum requirements intact.

By the way: when using release the cut-off is softened, this might have contributed to noticing this at first.

I've looked at beatstep specs and figured you'd like to know that I plan to introduce a multi midi channel mode with each channel having a different voice (wav-set). I was triggered by the accordeon topic in this forum and figured I can use that myself as well. Now I see this is also pretty usefull for a sequencers like yours.
It will take time though - and the issue above takes precedence :-)

Hi Hans.
About concurrent notes; I haven't scientifically tested the exact number of concurrent notes which cause the issue. But of course, the higher the tempo, the more concurrent notes. I have used a pretty dense (many notes) sequence for my tests on purpose. However, it's not so complicated that one would'nt use such a sequence in normal composition.

I am going to go back and examine my samples to see if there's any silent space I can cut out. I think they're trimmed ok, but you never know. It's probably best to make the samples as short as possible.

The multimidi mode sounds interesting, though I'm not sure the Beatstep Pro can output different Midi channels from the same sequence track. It does have three sequencer tracks, 2 for synths and one for drums, and each track's midi channel can indeed be set independently. It's a recent purchase for me, so I may be wrong.

Although, it would indeed be cool to load up 3 instruments on the same Samplerbox:)
For my particular project, it's not really useful, but it might be interesting for future projects. And definitely interesting for other users.

Do let me know if you need me to test anything in particular.

Also, for multimidi, you've probably already thought about it, but it might be an idea to try to implement multithreading for that. I have no idea how much work that is:)

Hi Nimbo,
Getting useless silences out will definitely help as they create unneeded polyphony (extra pending wav's in the audio routine).
You can already load more instruments using the voice option, but there is no possibility yet using them at the same time via different midi channels. An interesting path which I will certainly investigate.

Hi Hans.
I have gone through all my samplesets, and there actually was a lot of silent space I was able to cut out. Also, I had saved them all in stereo, thinking I might want to set panning for the samples at some stage. I've gone off that idea at the moment, so I converted all samples to mono. This has further improved performance to the point where I am almost satisfied.

Really excited to see whether you can cook up any more improvements in code:)