frequency to pitch

[oddson]

Can anyone tell me how to get the pitch value from a frequency ratio?

I can replicate the p2f math but not the inverse function.

(I thought there would be a primitive for this - at least green if not a stream.)

[oddson]

Found it


Since f(hz)/440hz is a ratio I assume I can do the same with normalized values.

f2p.osm

[Acrobat]

Found it


Since f(hz)/440hz is a ratio I assume I can do the same with normalized values.

f2p.osm

Where is that 69 coming from?

[chackl]

Notepitch of the frequency 440Hz

[Acrobat]

Notepitch of the frequency 440Hz

oh yes... LA!

[infuzion]

I'm not so good at math, but I can reduce OK:

f2p.osm

I'm too lazy to post a screenshot:

Code: Select all

MIDIpitch~=log10(f*50.1136)*39.8631+69

before: 10 primitives, including 2 divides
after: 6 primitives, 0 divides
WIKI (if you want to post your middle-steps odd)

[oddson]

The problem is sample rate... for normalized frequencies f(A4) is constant only within any given sample rate... but multiplying by the calculated inverse is much better since I only want the division done once and not with every change of the input. And there was some other waste too...

As for primitive count I don't worry about a handful of simple primitives as long as they bring something to the table. Sometimes it's comprehensibility.


Interestingly you don't need to use 69... you can use zero just as well as the pitch-to-frequency primitive lets you start at any value including note=0.

There are some other consolidations that cut down the math still further.

So, with note=0 and consolidating the log math

freq2pitch.osm

I think this is the minimal version that still calculates from normalized frequency correctly for varying sample rates.

[exonerate]

It can be done without any divides while still keeping sample rate independence.....



Doesn't really save anything though I guess.

cheers

Exo

[infuzion]

I'm confused... does the P-F read the sample rate?
TIA

[Acrobat]

I'm confused... does the P-F read the sample rate?
TIA

No, it boosts a normalized freq, where 0 is 0 hz and 1 is SR/2, TMK...


EDIT: --mh so why 0 input ouputs 0.0003..? - mmmh

[exonerate]

I'm confused... does the P-F read the sample rate?
TIA

No, it boosts a normalized freq, where 0 is 0 hz and 1 is SR/2, TMK...


EDIT: --mh so why 0 input ouputs 0.0003..? - mmmh

The pitch to freq does take into account the samplerate,

The reason why you see 0.0003 output is because the pitch range is the same as midi, Midi note 0 is not 0 freq because the midi range is only 127 steps and that doesn't cover the whole frequency range,

So midi number 0 is 8.1758 hertz and 127 is 12543.9 hertz

As you can see converting a pitch of 0 to freq will not give you 0 freq because of the limited midi range.

[oddson]

Like Exo says, P-F provided a normalized frequency for a given midi pitch. So it's dependant on sample rate.

As for avoiding divides... the 1/x primitive only gets called once so there's no divide with each new value. It's 2 multiplies and a log10 calculation for each change in frequency.

[infuzion]

OK, thanks! & I fixed the WIKI.

As for primitive count I don't worry about a handful of simple primitives as long as they bring something to the table. Sometimes it's comprehensibility.

I have to keep on top of reduction, or else my huge OSMs will become so big I can't edit them. My own MultiEnv is 230Kb with 3 included patches, & that is after alot of reduction. I do keep just enough extras to keep it understandable, so if I wanted I could reduce down to 210kb if I pushed it. Without any reduction, I'm sure it would have been 400k+, & slower due to all the primitives. If each VST has atleast 4 envs (easily more), that would have been 1.2Mb before adding the first OSC.

But I do try to keep the original & readable versions on my HD for reference, so I'm grateful for more explanatory versions as well.

[oddson]

I hear ya... but most primitives are only a few bytes of data in an OSM and I don't think they're any bigger in a VST or exe.

Unless I'm using a module hundreds of times I don't worry about extracting every last one I can.

That said in this case I had missed several opportunities for reducing the footprint and processing speed of the module.

Certainly one should look for divides that are in-line with the data input and if they can be extracted (with a reciprocal multiplication like above) then they should be. But a divide that is downstream for something that only changes very rarely (like with a sample-rate change or after a resize of a GUI element) then I don't worry about that.

Clever planning will save you more memory and CPU than picking out a few primitives here and there.

[infuzion]

I hear ya... but most primitives are only a few bytes of data in an OSM and I don't think they're any bigger in a VST or exe....
Clever planning will save you more memory and CPU than picking out a few primitives here and there.

A little extra here, a few there... you're beginning to sound more like a politician when planning a budget

Placing in a Float with a value of "1" & a Stream Mult adds exactly 38b uncompressed.

While it is good to have a well explained version to study, I prefer to have reduced versions handy since I never know when & how much I'll need that module.

I also find some great "Clever planning" ideas while I reduce that I wouldn't see otherwise. Sometimes if you just get in good habits, the need to reduce lessens.

Feel free to add your tips here:)