PlanetZ forums - scopeusers.com

i often read from developers that they have used some "custom design" for making eq and compressor devices.
now... what does this mean, exaclty??!
how can one build an eq circuit in sdk beside using the "normal" EQ atoms!?
the same apply for a compressor, but in this case i learnt that i can tweak the sidechain input...

you build electronic circuits with normal resistors, capacitors, inductors and transistors(valves), etc...

but how this translates to SDK!?
should one design a circuit, solve it, take the frequency dependent transfer function and traslate the formula in a sdk-array of math operations onto the incoming audio signal?!?
what does this mean to assemble a circuit made of transistors, resistances, inductors, capacitors into sdk!?!?
sorry if this seems a dumb question!!

it's not a dumb question, as it's of course not obvious - but exactly the method you described above, so you're pretty close already... at least strategically
if you start from an existing device (let's assume a Wah pedal) you have 2 options:

analyse the circuit and model the function by each part (transistor, coil, capacitor), an extremely complex approch.

the other method would be to model the functional performance of the whole unit, e.g. you feed a signal into the pedal and and develope a bunch of functions that describe amp, distortion and frequency response.

of course a mixed approch is also possible (and usually more effective), some parts are modelled by function, some by electronic part. For example if the pedal contains a Germanium transistor, you might specifically add the characteristics of this item.

All signal processing functions can be built from additions and multiplications basically (subtract is 'add negative' and division is 'multiply inverse' plus a few trig and calculus macros.
This is what Adern called 'only the most basic math atoms' in their description of Flexor.
As you probably know the Flexor filters have a very different sound than the Creamware versions.

cheers, Tom

hi bosone, all,

as you probably know, and probably mentioned above, we, at DAS did our own algorythm for compression and eq ...

as you mentioned, this means that we made an EQ basic atom (used in MASTER IT EQ and C350) and a compressor (let's say dynamic) basic atom .

i can only here talk about what we did ... and unfortunately, gary , astro, we did not modeled transistors, capacitors or selfs ... and i do think that no one do this but i may be wrong ...

in fact these analog electronic components work for analog ... and do not mean a lot in digital signal processing ... what is more important, is the way electronic circuits act on a audio signal (eq comp ...) and then find a function in digital domain that can emuklate it .

SO, in the digital domain, there are algorythms, (take it like maths operations, equations) that can give the same results as some complex analog electronic circuits ...

And what we did in SDK ( and more) is to resolve these equations ...

so what we used for building these basic atoms, was to combine "very basic" math atoms (multiply, and addition ) in order to get the desired digital functions, such as tranfer functions in time and frequency domains or working on the signal level for dynamics ...

So once again, this is what WE at DAS did, and maybe some others have different approach ...

any way these developments were very very interesting ... months of learning theory of digital signal processing, lots of work to remember very old knowledge from school and studies

and overall, a good result !!! and that is in fact the most important : trying and do something different from CW / SC ...

And to be honest, when we began these works, we did not know at all if it could be possible !!!

IT IS ...

sorry for my bad english ... it's a bit hard for me to talk about this in english !!!

cheers
olive

sonolive wrote: ... and unfortunately, gary , astro, we did not modeled transistors, capacitors or selfs ... and i do think that no one do this but i may be wrong ...

no need to excuse that you didn't...
Bosone asked about these parts (probably thinking of industrial circuit emulation software where this is regular practice), so it had to be included in an answer.
Of course one can do this in Scope (as in any other software).
But as mentioned, it's rather ineffective and even the most tiny error on this level may have tremendous effects on the overall result.

If the 'part-by-part-modelling' approach is choosen for sake of realism those tiny errors can make it completely useless in less than a second.
On the other hand this may be used in a creative way, as it allows to model components that do not even exist...

SO, in the digital domain, there are algorythms, ...

as this forum is also read by regular folks, let's just clear 2 mysterious items that show up once and again
an algorithm is the math equivalent of what a cooking recipe is in kitchen. The rule how things are to be processed.
A very simple example is currency translation: multiply amount by exchange rate is the algorithm to find out how much cash you'd get in for foreign country.

an equally fuzzy item is a Scope atom.
It may contain anything from encapsulated machine code to a complete processing program like a compressor - or more precisely: an atom can be built of atoms itself, so it's not that atomic...
It's internal structure may be accessible or it may be not - depending on the options it's 'creator' has set.

... in fact these analog electronic components work for analog ... and do not mean a lot in digital signal processing ... what is more important, is the way electronic circuits act on a audio signal (eq comp ...) and then find a function in digital domain that can emuklate it .
...
And what we did in SDK ( and more) is to resolve these equations ...
....such as tranfer functions in time and frequency domains or working on the signal level for dynamics ...

this is certainly the more 'practical' approach than part-by-part-modelling in several ways.
First the increased level of detail may not contribute to the audible result at all.
And then modelling may become so complex that it cannot be performed in realtime anymore - a condition that industrial circuit design software rarely faces, if at all.

So once again, this is what WE at DAS did, and maybe some others have different approach ...

even with the same approach, someone else may analyse a circuit and find a different way to model it - even with nothing else but the basic set of processing modules - aka atoms.
this cannot be emphasized enough, as a lot of folks out there still seem to restrict innovation to new machine code only.
There is an enormous range (as Olive mentioned) of possibilities how a function can be implemented.

And finally... though I'm not really sure about it, so it's more a guess from other industrial approaches, Scope (SDK) may well be (or include) a machine code generator on it's own.
This software is anything but outdated... it's just... vintage
(look in guitar sales to find out what this means...)

cheers, Tom

People forget to mention the unit delay (a delay with one sample delay value - You can use the feedback module instead, because thats infact an one sample delay module).

There exist several topologies, like direct form I & II, Lattice etc. for digital EQ designs.

Cheers

hi

People forget to mention the unit delay

absolutely right !!! basic atom for these dev (i mean eqs)

You can use the feedback module instead,

or any other combination that gives you one sample delay ...

like direct form I & II, Lattice ...

and even more, in each form you choose, you have to be very carefull of wich algo (implementation) you use in order to optimize quantization and truncation ... at nodes ...

cheers
olive