SynthMakeroddson ·
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.)
frequency to pitch
From the original SynthMaker forum (2004–2014), with its members’ names and dates.
oddson ·
Found it
Since f(hz)/440hz is a ratio I assume I can do the same with normalized values.
f2p.osm
Acrobat ·
oddson wrote: 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 ·
chackl wrote: Notepitch of the frequency 440Hz
oh yes... LA! 😊
infuzion ·
I'm not so good at math, but I can reduce OK: oddson wrote: f2p.osm
I'm too lazy to post a screenshot: 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 ·
infuzion wrote: 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 ·
Acrobat wrote: infuzion wrote: 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.
oddson wrote: 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 ·
oddson wrote: 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:)
rl ·
Isn't that discussion a bit .... errm... academic?
On my system the mininum footprint is ~996kB (empty module with midi in and two mono out's exported as a VST dll). One of my bigger projects (~60000 primitives, 6500 modules - 6 envelopes) result in a VST dll size of 1,32 MB. That's about 370 kB for my schematic. With that size | don't care yet.
Wrote something here? To have a post removed or your name hidden, write to [email protected].