log10 lookup?

[Tepeix]

I don't understand the range. From -0.15 to 0 the log10 is supposed to have a value of 0 ?
Maybe it's the output that are in this range ?

[R&R]

what are the full equations you use these log10's? are you after linear, logarithmic or other type response and if not linear, how many steps is the range -0.15:1 divided to?

Not really any elaborate equations. I just need to replicate a rough frequency analysis graph visually...

Don't know how I end up with these things. But one use case here is:
log10( [knob 0 to 1] * 1500 ) * pi * 0.1

This is then feeding... I guess you could say, manually made blendshapes in ruby box.
The value 1500 might differ fom case to case, as is 0.1... to match a particlar blendshape (which are a bit arbitrary).
Working with smoothed splines so

[R&R]

I don't understand the range. From -0.15 to 0 the log10 is supposed to have a value of 0 ?
Maybe it's the output that are in this range ?

Correct! This is the output...

Don't know how I end up with these things. But one use case here is:
log10( [knob 0 to 1] * 1500 ) * pi * 0.1

PS
Pi is just a carry over from my arc. 1500, 0.1 and Pi doesn't matter really at all. Just the log curve.

[tulamide]

I really don't see the need for making your life harder. Just use, whatever math equation gives you the result you're after. Ever wondered, why a simple webpage graph like Desmos can show you a dozen of log curves animated at 60 fps? Correct, because it doesn't matter at all!

You gain nothing noticable from simplifying math at that level. you're not dealing with 44100 frames per second, like in blue/white, but 25 frames per second. Reducing math in blue/white will save you much more, up to significant.

And simplifying to cover an issue you have elsewhere in the schematic doesn't help either.

First find the real issue and solve it. Then look for ways to speed up the schematic. Not the other way around.

For reference: running log10 a million times (1,000,000 times) takes 7 hundreds of a second (0.07s), running it 25 times over a second is unmeasurable.

[juha_tp]

...

For reference: running log10 a million times (1,000,000 times) takes 7 hundreds of a second (0.07s), running it 25 times over a second is unmeasurable.

Probably (depends on the compiler and compiler options FS uses) you'll get totally different measures if the input gets changed for each function call. std::log10() takes about 25 to 29 rdtsc/val (variable) depending on compiler switches used (GCC 11.2, -O3 (w -ffast-math slower)) and when constant input it takes about 0.25 rdtsc/val.

[R&R]

I really don't see the need for making your life harder. Just use, whatever math equation gives you the result you're after. Ever wondered, why a simple webpage graph like Desmos can show you a dozen of log curves animated at 60 fps? Correct, because it doesn't matter at all!

I'm not will keep it simple and use some green log10's. Any alternatives are never the less interresting, if they exist. Part of the fun, so to speak...

I can't challenge any claims in this topic since i'm a total lightweight in this matter

And simplifying to cover an issue you have elsewhere in the schematic doesn't help either.

First find the real issue and solve it. Then look for ways to speed up the schematic. Not the other way around.

Agree! this is true...
My inital question was more of an optimization question. I'm not really covering the issue... more like mitigating it, since i'm adding some features to the synth.
Surely many issues to be solved everywhere in my synth Might be issues in other parts of my schematic. As long it works and isn't critical for now... i'll take a look at it in time

I have to do tests on a clean VST with some knobs to see if it's my schematic, or a general "drag interaction" issue.
Maybe it's just me that would call it an issue.

[tulamide]

...

For reference: running log10 a million times (1,000,000 times) takes 7 hundreds of a second (0.07s), running it 25 times over a second is unmeasurable.

Probably (depends on the compiler and compiler options FS uses) you'll get totally different measures if the input gets changed for each function call. std::log10() takes about 25 to 29 rdtsc/val (variable) depending on compiler switches used (GCC 11.2, -O3 (w -ffast-math slower)) and when constant input it takes about 0.25 rdtsc/val.

Why are you bringing up a C++ compiler and argue about a few rdtsc (which btw isn't even guaranteeing to start at the same point in time on all cores)?

This isn't C++, this is interpreted Ruby running sync'd to Flowstone! And nobody really cares, if the actual number would be 1,000,000 per 0.07s or 500,000 - this is about green graphics at 25 fps.

Even if it were 10 log10 per 0.07s, it still wouldn't matter. That I have to explain this, alarms me.

[RJHollins]

...

That I have to explain this, alarms me.

Regardless .... your 'explanations' are always helpful.

[R&R]

Forum is back again. Nice!

Feels better posting my newbie "somewhat BS" questions here, rather than cluttering the more technically advanced discord threads...

Well... optimizing greens had negligible effect as tulamide implied.
Fetching sprites and then drawing my massive knob-bitmaps seems to account for alot of the cpu cost in regard to the knobs.

Mentioned on discord that I have now reduced some CPU by dividing triggers, especially during automation. 1/2 respectively 1/4.

Would be nice to retrieve current screen refresh rate though. But haven't yet found a solid simple solution for finding screen refresh rate. Just some ruby either with dependency on some some windows lib or opening a cmd and parsing output. But that seemed to be for resolution though.

A fun way would maybe be if there is a way to contruct a small FS test with ruby box and greens... to gauge current update rate.
Is it perhaps possible using a ruby/system-timer as reference and then feed a ticker100 into a limit prim to provide update events at current rate to the ruby to do a measurement?
Atleast that would give indication of refresh rate being either 60hz or a greater one, like 90 or 100+

[R&R]

Yaay!!!

Also... Celebration! Finally managed to get my synth to store/recall zoom settings and theme correctly.

Don't know if the solution will make other DAWs poop themselves. But in Reaper it worked