giuliomoro Hey sorry it's taking me a while. I hope to able to get larger blocksizes to work this week.

Forgot to mention that I have done this. It's on the dev branch for now

      a month later

      Can anyone confirm that helmholtz~ is working correctly now? Or fiddle~? I really want to buy a bela but I’m going to need real-time pitch detection as fast as the beaglebone can do it.

        dale

        as far as i know only blocksize can now be increased further, which should allow sigmund~ to qork better.

        if you need as fast as possible, then sigmund is probably not your best bet. what input are you trying to pitch-detect? what do you want to do with it? depending on those questions there might be alternatives.

          blocksize goes higher, so you can use, for instance, [fiddle~] with a window size of 1024, and at a blocksize of 512 it will use about 21% CPU (plus 9% overhead). It goes without saying, when using something like [fiddle~] or [sigmund~] with a large analysis size (1024 or more), then the lower limit of the latency will be determined by the algorithm. @lokki has developed some monophonic pitch detection patches in Pd with much lower latency.

          I’m using fiddle~ on my computer to track my voice and other instruments like flute and trumpet. I usually use a block size of 512 or 256 depending on the input. I’d like to make a pitch correction / harmonizer type of box with bela.

            dale in that case i would really recommend you look into running lv2 plugins on bela, i have x42 fat.lv2 running nicely on the bela with help from @giuliomoro, let me know if that would be an option for you and i can walk you thru 🙂

              dale sorry I had gotten my CPU figure wrong above. Here it is amended, and also other sizes:

              [fiddle~ 1024 1 20 3]: 14% (blocksize 1024)
              [fiddle~ 512 1 20 3] : 16% (blocksize 512)
              [fiddle~ 256 1 20 3] : 18% (blocksize 256)

              To these you could add about 8% I/O overhead

                3 months later

                Im also now searching for a pitch detection algo 🙂 (though I want it in C++)

                my first go today, trying a different approach that doesn't use FFT, rather its based on "Dynamic Wavelet Algorithm Pitch Tracking", and a C implementation from Antoine Schmitt (see repo below for reference)

                in my tests it seems to track pretty, but it seems heavy on cpu 🙁

                https://github.com/TheTechnobear/BelaPatches/tree/dev/c%2B%2B/pitchd

                my patch, runs puts out a sine on out1, which you can feed into in1, and then out 2 has a sine of that generated frequency. of course, you can run any signal into in1... does have to be the test sine.

                the "dywapitchtracker" is pretty straightforward - but does not seem optimised.
                for example, I changed it to not allocate memory on every pitch computation.
                i also converted it from using doubles to float (which bizarrely (?) seems to make it slightly more cpu intensive)

                so not sure if it's a dead loss.. or if there are some easy wins, that i missed.
                also though its saying 74% cpu, this I guess would not cause audio disruption, since its no a non-RT thread.

                hmm, what next?

                if the above is not going to work, Im thinking to implementing something based on KissFFT and this implementation of wsnac.
                https://github.com/kpe/zerotune/blob/master/src/wsnac.c

                alternative, I could look at using some code from pd - sigmund~, fiddle~, or helmholtz~ using KissFFT for the fft.
                thoughts?

                ok, another try... this time using a library that generally looks interesting, as has other dsp stuff
                https://github.com/cycfi/Q

                its very modern, so needs c++17, you cannot compile in bela IDE - I cross compiled it

                in repo at : https://github.com/TheTechnobear/BelaPatches/tree/dev/c%2B%2B/pitchd

                ok, comparison ... Im a little confused about :

                so I look at stats with
                top - top -p pgrep pitchd
                and
                sched/stat watch -n 0.5 cat /proc/xenomai/sched/stat

                heres is what i get:

                dywapitchtracker

                 PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                                                                                                
 8896 root      20   0   17132  14616   4492 S 49.7  2.9   0:14.01 pitchd          

CPU  PID    MSW        CSW        XSC        PF    STAT       %CPU  NAME
  0  0      0          37850266   0          0     00018000   85.6  [ROOT]
  0  9213   5          5          13         0     000600c0    0.0  pitchd
  0  9223   1          1          2          0     000600c0    0.0  pt_task_
  0  9226   1          434530     434532     0     00048046   12.5  bela-audio
  0  0      0          21776915   0          0     00000000    0.7  [IRQ16: [timer]]
  0  0      0          217354     0          0     00000000    0.8  [IRQ180: rtdm_pruss_irq_irq]

                so I think thats...
                50% - linux
                12.5% bela audio .. , 85.6% root

                what is root?

                note: IDE said something like 77% ??

                q lib

                  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                                                                                                
 9867 root      20   0   15868  14244   4508 S  0.0  2.8   0:00.12 pitchd  

CPU  PID    MSW        CSW        XSC        PF    STAT       %CPU  NAME
  0  0      0          38558036   0          0     00018000   77.6  [ROOT]
  0  9867   1          1          6          0     000600c0    0.0  pitchd
  0  9876   1          119946     119948     0     00048046   20.4  bela-audio
  0  0      0          22172066   0          0     00000000    0.8  [IRQ16: [timer]]
  0  0      0          60024      0          0     00000000    0.9  [IRQ180: rtdm_pruss_irq_irq]

                ok, so thats zero in linux space.
                20.4 in bela-audio , and 77.6 in root?

                ive no idea what the IDE would say, since i cannot run it in the ide 😉

                this is not that surprising, since with q_lib all processing is done in the audio thread,
                whereas dywapitchtracker its all done in a separate low priority thread.

                there is no reason, I cannot move q_lib to a separate thread.

                note: there is a test tone being generated in exactly the same way in both examples.
                for dywapitchtracker the ONLY thing done apart from the test tone, is to copy samples to an array.
                SO... id say 12.5% is basically producing the test tones.

                in which case - Im assuming that means the qlib pitchtracker is only taking 8%?

                thoughts?

                EDIT: i'm using a 16 sample buffer (-p 16)

                EDIT: ah...i remember talking to @giuliomoro about ROOT before...
                this is just 'left over' xenomai , so yeah, Im only interested in bela-audio
                and looking at bela-audio, on the simple examples , min cpu is about 12% so that tallies.
                if Im reading @giuliomoro comments about overhead in above post - 8% is pretty reasonable.

                Im wondering about dywapitchtracker if its on the audio thread... since although its reporting high load, that is presumably partly because its being run at a very low priority?!
                EDIT: nah, that has underruns, and kills the board 🙂

                EDIT : Wow....
                drop qlib down to using a 64 sample buffer (-p 64) , and Im down to 14.8% - thats seems to be just a 2.3.% overhead!
                I think thats enough for me to call this done 🙂

                2 months later

                giuliomoro That's great news! Thanks for you effort! I'll have to give it a try soon. I've used Pisound for the other project because it relied heavily on ~sigmund, but will definitely use Bela mini for any upcoming projects.

                  a month later

                  Joel de Guzman has been working, in C++, on an opensource pitch detection algorithm he calls Bitstream Autocorrelation.
                  You can read about it here www.cycfi.com/2020/07/fast-and-efficient-pitch-detection-revisited/

                  It's part of the Q audio DSP library github.com/cycfi/Q
                  If you look in 'issues' Dealerpriest states he had it working on Bela.

                  I'm also looking at Bela specifically for a system involving real time pitch detection. This looks like just the thing!

                  I've made this project to use Q from a Bela program. As someone somewhere (possibly on the music-dsp mailing list?) pointed out, this pitch detection method may not be faster/more efficient on a device that has a floating point unit (such as Bela), but it's surely worth a try.

                  4 days later

                  Very useful, cheers Giulio.

                  I see, further up, Technobear has tested the Q library pitch detector and found it's cpu overhead to be relatively good. I just got it working today and found my entire project (pitch detector, 2 sine osc, 2 ring mod) to use about 20% cpu. The problem is it's failure mode seems to be buffer underruns on high notes (I play violin).

                  With a buffer size of 64 it works reliably upto nearly 2khz, good enough!

                  Buffer size of 32 it works to 1.5k,
                  Buff 16 works < 800hz (maybe fine for guitar or voice)

                  Tracking is good, accurate and fast. I'm getting some octave mistakes but a LP filter will hopefully sort that.

                  To use Q library I found that '-std=c++17" COMPILER=gcc' works for the Hello World delay project but does not compile projects with pitchdetector included. Following Dealerpriest I tried '-std=c++1z' WITHOUT using 'COMPILER=gcc' and it compiled with that.

                    resynth To use Q library I found that '-std=c++17" COMPILER=gcc' works for the Hello World delay project but does not compile projects with pitchdetector included. Following Dealerpriest I tried '-std=c++1z' WITHOUT using 'COMPILER=gcc' and it compiled with that.

                    good to know, do you have some code I could test it with, so I could update the example?

                      @resynth it was a while ago when I was playing with this... so my memory is not perfectly clear.

                      however, I seem to remember the 'issue' I had with qlib was the frequency range was a bit limited.
                      iirc, when I asked about it, they said indeed it was designed for guitar/voice (?) and that it might not be suitable for other frequencies and sources.
                      (I was trying to use it as a tuner, and it was not anywhere near reliable over a decent range for that, even with a sine wave)

                      Giulio - Q library pitch_detector example code copied into Bela-Q gitub comment, not quite sure how to attach cpp files here (not that I did it very well on gitub!)
                      It's my first C++ so mainly copied/pasted from Technobear and Dealerpriest. It works with '-std=c++1z' WITHOUT using 'COMPILER=gcc'. I have no idea why, just trial and error.

                      Technobear - Did you have problems with Q tracking low frequencies or just the high ones?
                      What did you end up using for your tuner?

                      Ultimately I want 4 instances of pitch tracking, 1 per violin string, so it has to be efficient. Speed and accuracy are of equal concern though. My previous experience of pitch tracking is Korg MS20, Pigtronix stompboxes and Axoloti. I feel like Q compares favourably but haven't yet done any direct A/B or looked at it "scientifically".

                      This'll do me for now but if anyone has a working, faster, more accurate pitch detector please lemme know!

                        resynth Technobear - Did you have problems with Q tracking low frequencies or just the high ones?
                        What did you end up using for your tuner?

                        hmm was a while back... I think I had problems at both ends of the spectrum...
                        I did write an email, where I detailed the issues, and showed my results - but annoyingly cant find it !
                        unfortunately, iirc - they pretty much replied - it was working with the 'spec'

                        I'm a bit surprised I didn't check in by test program to github... it was a simple variation of the code you linked to above.

                        on a brighter note: the article you linked to was from after my attempts with it, and they imply its been improved.. so perhaps its now suitable for your purpose.

                        the tuner, I ended up not sorting out.. it was all about calibration, and I spent so much time messing with the js code, I got fed up with it before completing it 😉

                            thetechnobear it was all about calibration, and I spent so much time messing with the js code, I got fed up with it before completing it

                            “A work of art project is never finished, merely abandoned" [Paul Valéry, Gore Vidal, Oscar Wilde and/or a combination thereof]

                              2 months later

                              giuliomoro Thanks a lot! Actually, during the NIME performance, I've used Bela Mini for one of the devices and it works brilliantly.