@EEight did you make it any further combining libpd and oboe?

@jancsika Thanks for this information.

I left a comment on the libpd repo to see if there's a way to set this on libpd since it appears it doesn't use the args passed in.

I'm finally getting a chance to look back at this.

@jancsika I couldn't find a reference to batch mode. I'm also using libpd, so I'm not sure if that's something that's implemented there.

I tried upsampling again using the example patch the helmholtz~ comes with illustrating re-sampling (http://www.katjaas.nl/helmholtz/helmholtz.html). I was able to get faster processing from what I can tell and the pitches were correct, but the lowest detectable pitch doubles for every double of sample rate. For example at 44100, the lowest is 25hz and upsampling 8 - 16x made the lowest around 400hz which is too high.

Are there any other potential methods for this?

@sunji said:

While you can upsample to make frames faster, you'll only be getting the same speed increase equivalent with dropping the window size. And what you gain in speed you lose in accuracy, starting in the lower frequencies. Doubling the sr with a 512 point window is effectively the identical to a 256 point window, just with twice the computations.

Thanks. Right now, the pitch detection range is 25hz - ~3000hz. Basically the frequency of the most common instruments.

I have an app that does pitch detection in real time as people tune their instruments. It records the results and gives a printout of how well they played in tune. I'd also like to give them this same print out for things they previously recorded (so not in real time). So, that's the challenge right now - to try and do the same pitch detection that's happening in realtime, but as fast as possible when using a pre-recorded source.

Should I be using block~ or switch~? I tried block~ first and increased the oversampling to up to 16 ( just to test). It seems to work in processing faster. The downside is the pitch increases by the block multiple so the pitch detection ends up trying to detect pitches too high to detect.

Thanks! I'll give that a try and see what happens.

Is it possible to do pitch detection faster than real-time? I'd love to be able to analyze the pitch of a file (currently stored in an array) faster than real-time. Are there any options for being able to do analysis like this?

@whale-av said:

In extended you could simply change the samplerate for Pd for each track played.......... https://forum.pdpatchrepo.info/topic/10302/openpanel-and-readsf-play-audio-file-detuned-and-slowed-down

Thanks! I appreciate the thought out reply. I'll take a look and see what I can do. In my case, PD's rate is set by the OS and I can't guarantee the rate of the wav files so some type of conversion will be necessary.

Thanks again.

I have pd running at 48k (what my iOS device runs at) and I'm trying to play a wav file that is 44.1k. When doing so, the pitch is shifted up. Is there a conversion I need to make in order to ensure that the file plays at the correct pitch/rate? Right now I'm essentially following the phase vocoder example (since I might do time stretching), but the pitch isn't the original pith.

Turned out to be a filepath issue for me. Not sending a proper path caused it.