Stock EQ V2

[wlangfor@uoguelph.ca]

I wanted to re-post just so that I could show the settings image:



Furthermore; I know after trying that oversampling is a hard thing to add. Here's the steps to fix its integration:

To switch signal to Oversampled keep in mind that the signal for the oversampled signal must first be un-amplified before it is turned on.

Like So:

Multiplexer || Stream multiplier || EQ Co-Efficient Module || Stream Multiplier || Selector || DSP Code Cross-fader

Basically You need to make sure there is no amplification.

1: set stream multiplier to 0,
2: turn on multiplexer and selector
3: set a DSP crossfader to switch from the original signal to the oversampled.
4: reverse the order to turn off the original

But the real issue is that the signal which You turn on and off cannot be amplified or else it will overload. Kind of like Phantom power with Mic's. I was able to solve this with five slides; Each time a slide is done and goes to one, the signal from the slide goes first to an int and then to another slide. If there is five in a row, it sets five floats to 1. You can reverse the order by using selecters to re-route the links to the slides. Just make sure the only switch at the beginning is a Boolean.

There is a prototype within the schematic above which solves this.

[wlangfor@uoguelph.ca]

I'll have an update for this tomorrow. Took the night off

[wlangfor@uoguelph.ca]

OK, Working model.

This one is almost fully operational.

However, I was noticing that the bell of the ZDF "Peaking EQ" filter is not narrowing in correctly. I tried to resolve that; I even tried to rectify that with a low pass and high surrounding each channel running in parallel; However, There's a small amount of flex; And some inaccuracy still regarding the bell's whereabouts.

I have each band being surrounded by a high pass and low pass:

Code: Select all

HP
|                     |
|_____                |
|      \              |
| Bell  \             |
|        \            |
|_________\           |


So, after testing versus the other model made by Martin Vicanek I was dismayed (Though both models are made by Martin); because in His demo, the bells seemed
to be accurately placed. Whereas in this model; They "work" (and not just in a streamed impulse demo) and furthermore it's operational.

That leaves a right click menu which contains all of the settings which I had first nested in the bottom right. I'll also make the dialogue inside a box which automatically veers away from the bell with x-y co-ordinates in mind and available real estate.

"However", this new revision affects many problems that the last versions had encountered:

- The lower half having a smaller grade
- Feedback due to hikes and drops in volume
- Too much colour

Here's the latest demo. And I assure You; even though half complete (it's a very big project - It's almost as impressive as the one by Image-Line and they were paid well )


And, on a sidenote:
I had been "questioned"

http://www.flowstone.co.uk/support/viewtopic.php?f=2&t=13971&sid=9dcb17380c6064b868ea6ced6e0494dc

haha regarding the method of combining a trigger blocker and a trigger redraw limiter. It replaces the method that had been maintained and formulated by Nix (Phonix) and I replaced that method with My own due to the fact that it is not so "needy".

His method required that all floats had an aggregated trigger and that trigger was passed on to a trigger divider and (I'd used a "redraw limiter" only). That limiter was then placed at the head of a float array and items to make them "tick".
I find My "new" method to be a bit better because it is less maintenance and ultimately requires less work in the schematic. There You are Spogg and Tulamide; A working model for You to "Peruse".

All's well.

Full reply to the "questioning" here:

http://www.flowstone.co.uk/support/viewtopic.php?f=2&t=13971

So, Finally, to recap;
That's a trigger blocker attached the input and then the intended object.
Next, a redraw limiter from the source to the intended object as well.

This seems to cut down the amount of data each float value passes on. I think some of that has something to do with what image knob it uses.
I'd thought about the way it seems to colour too; Like it's designed for a graphic designer in mind. I'd contemplated that this "reaction" of the program
could be engaged by a simple colour count and contrast merely by measuring int values of the RGB. It seems to like contrasting colours (colours that are 25 RGB apart)

[martinvicanek]

You spend much effort on graphics but your DSP is all wrong. When you configure a flat curve the response is some kind of lowpass but not flat. You have the peaking filters in parallel, that won't work, they have to be in series.

This is my last comment on your schematics. Frankly, I doubt you can create something useful as long as you believe that multiplication sounds better than division.

Good luck!

[wlangfor@uoguelph.ca]

You spend much effort on graphics but your DSP is all wrong. When you configure a flat curve the response is some kind of lowpass but not flat. You have the peaking filters in parallel, that won't work, they have to be in series.

This is my last comment on your schematics. Frankly, I doubt you can create something useful as long as you believe that multiplication sounds better than division.

Good luck!

I guess I think less zeroes sound nice, and there's more digits when division is done. It's why people oversample, so there is less artifacts. And artifacts just relate to extra digits. That's all they mean. But I practically apply this wizardry everyday.

Moving right along, been great but other people would probably be interested in the newest guts I'm going to put into this bad boy. Like Martin had said, He was unhappy with the sonic result; He would go over the readings with a graph so that He could depict what this EQ was really doing. I guess though it's easy to overlook that I have limited time and really cannot be making this stuff all day lol.

but here's some talk about the differences between multiplication and division:
https://stackoverflow.com/questions/226465/

I think what people forget about is speed man. Multiplication is faster; lest We forget, this math is being done on the fly. But Multiplication is less accurate so there is truncated digits. Moving on (33% in python ).

However, Here is a basic EQ that uses only ZDF's and I'm building a custom knob to drive it. I built this new knob from scratch and it's steel while the others are default.
Enjoy this bit of work; And compare the "colour" from My "knob" to the default hehe:


Use it for whatever, CC0



Notice Martin, that this time I'm not using a graph line but instead I am relying upon impulse to depict real-time what it's doing . Sick right?
I'd realized (for the rest of You) that there were less calculations by just using impulse and ZDF's seem a bit faster than coef's so I did it that way. The cool part is that it shows You exactly what it is doing. Nifty that You see exactly what You hear. I plan to offset the graph in this manner:



So, the black is an area that will not be affected by the knobs when it is finished, they'll be frequencies above or below the EQ's affect. I'll just have to use a logarithm to convert that into distance to decide how long that will be. A bit tricky to do seeing I have an area of affect as well, but let's face it; It will look better. That way the graph will spill over onto the black areas as well.

EDIT:
I will add, however; That I'm aiming to use parallel processing due to the fact that I want to add stereo width (by however many bands there are) and I'll be adding a de-esser band. I'll maybe add a second impulse graph for the de-esser so that it shows what it has taken away. Sick right?

[wlangfor@uoguelph.ca]

New Version:

[wlangfor@uoguelph.ca]

OK, so I have tested many methodologies and there's also been many conversations regarding object orientation and flowstone.

The problem with object orientated code is there is no real way to "separate" everything. So; It's really the sum of the whole that defines speed. And speed (though We would like to think otherwise) is what determines what sounds good and bad. So; While I respect that there are many opinions any "official" opinion on colour regarding a product like this one is subjective.

There is no physical space, there is only one document formed called a .fsm or .osm and all of that code is run "together" there's no walls to say one code should not affect the other. And while it makes it easier to understand each object as its own identity; There is no such maxim in products such as this one.

So, let's stick to the facts please; Because the only equalizers I have seen made with this product as fast as My own are Nix's Freq, And bitsonic.eu's as well as the Equilibre. There are no other in existence made by this product that either sound good enough or were reliable enough to use. If You want to be competitive in a friendly way then show off Your project that's somehow better than everyone else's. The proof is in the pudding And I'd like to see. if You know better than prove it.

And I will point out that the reason that the test Martin Vicanek had done didn't match because based upon the examples He provided to Me recently had no sample rate dependent specification. And that's neither good nor bad, but again subjective. I notice the ZDF's which I had been using earlier seemed fast, but to work essentially accurately they would need to be tweaked in order to always be accurate dependent on sample rate. It seemed they were a mish mash of maybe two filter designs and the calculations resulting were a few Hz off. I'd tried them out after reading a post by Adam Szabo and Martin Vicanek. And similarly Martin's tests were off and so were mine.

So, objectively moving ahead; I've been working on sound colour that I am pleased with. It sounds very much like the renaissance EQ by waves.
It's interesting that it worked out so weel in comparison to the other sonic colouring I experienced in previous versions.
Without a doubt, if You were to use this equalizer for a commercial project it'd do a good job, but it's just a prototype that's incomplete. However it sounds great.


I was able to come up with a combination that seems smooth but professional; Albeit there are only knobs driving it. I had tried to combine both knobs and bells to control the equalizer but perhaps I will have to add a middleman.

There's an older equalizer project I had been working on that was based upon the sweepy Q by SMG.
And Here it is:


It's a little slow and I'm not so happy with it. But fundamentally I am very happy with the way in which it works.
And again, if You're going to comment on My stuff well that's great. But if You're going to say that I'm using a faster method VS. what is considered popular in most circles in some negative way then why bother.

I could pull up a hundred documents that say as a matter of factly that even float multiplication is faster than plain division. Hundreds.
And I've gotten really tired of testing out projects that crash My computer. The same people Who have mentioned their likes and dislikes made them.
You see, I used to work with javascript. And quite often I'd realize that even math could slow down javascript. I used to make some pretty amazing stuff back in the days before ajax. And it worked just as well. But the reality I'd come to appreciate (and I think Nix has as well) is that processors are not infallible and they are not as efficient as We would like to believe.

Please, if You wish to comment I will not be offended by whatever You say; But if You wish to say that You know better than step up to the plate and add Your project to this post so I can learn from it and ultimately side with Your beliefs. But all I've experienced by testing 99% of the projects made by the same commenters is a crashed FL studio and lost work. My projects work and I am doing everything I can to make them work better.

I've noticed My project works fine when using under 40% CPU. But when utilizing more it crashes sometimes. I thought of a way around it maybe. I could possibly have it so that by default the signal is dry on load and then it slowly blends in the wet signal after say a second or two or three to load. Might be a fait accompli no?

Thanks for following the post. But I expect more than words if You wish to teach me something about programming. Humble Me with examples please and not subjective rhetoric.

[nix]

Hi man,
I'm not sure if you're a troll-r u?
I am not so brilliant at DSP to write the peaking biquad eq,
the mod I did was just to add 4 more nodes and the sweet graphic work was by my mate.
So it was quite cosmetic.
I had lots of problems with automation crashing, that's why the trigger line is kinda odd.
The linked controls are done with an inverse equation.

To help you with the last bit of your prior post-
if you'd like you project to boot with minimal DSP,
the selector prim is the unit. When the selector is unlatched, no DSP should happen.
You'd like the new trigger counter in the 64-bit version, u can follow triggers along with the processor.
If you aren't trolling us, and really do find this interesting-
the new version is coming along very nicely

[ChrisHooker]

wlang,

NO-ONE is arguing against the fact that multiplication is less taxing on the CPU than division... what they ARE saying is that it does not change the sound... that a more CPU-intensive process does not change the sound... it will only take up more and more of the buffer to complete the calculation until you get stuttering and drop-outs. The plug-in does not reduce or skimp on calculations in any way to get more done in the required time. It will process the code exactly the same until it can't keep up with limited CPU power, and then it just STOPS. There is NO tonal change whatsoever. It either runs or it doesn't.

BOTH multiplication and division introduce errors at VERY low amounts... but neither is worse than the other. Do a very simple test running a sin wave through both mult and div of equal amounts. Comparing an untreated signal to the output of the same signal after it's been multiplied by .001 then multiplied by 1000 to bring it back to the original level (or divided by 1000 then divided by .001), you have to raise the volume of the difference between the orig and effected signals by about 1000% to hear any noise created by fractional errors. WAYY below the actual signal, and completely acceptable THD by any standards. Compare the mult signal difference noise to the div signal's... Crank up the amplitude until you can hear them: Both have noise at the same level.

To your other point about any knobs or other graphics having an effect on the sound of the entire plugin: Want proof that graphics and streams use different priority threads, and thus disproves your assumption? Try adding multiple signal analyzers (FFTs, for example), one at a time, on any streaming audio signal. As you start to tax the graphics demands hard enough, the graphics update rate will slow down or even become unresponsive, but the audio signal remains unchanged.

Simple tests can disprove what you are claiming.

[RJHollins]

I'm confused about the useing of the term 'Color'.

In Audio Engineering, this 'color' usually refers to additional Harmonics added to the 'pure' signal or function [eq].

Just one example.