I posted a question on the tutorials section asking if anyone could do a post on maths/binary operators [+] etc or [~] and there placing in patches. As yet nobody answered. However, whilst browsing the web to get what information I can on PD I came across Andy Farnell's site which has a few excellent tutorials. I wrote to Andy (he's also on this PD forum) asking about his use of operators in the tutorial.
You can find the tutorial here : http://bit.ly/KFQf2K
My email question and his answers are here, I hope other people may find this useful :
_You raise an interesting question. Perhaps the reason it is not
commonly asked or answered, is that it doesn't fall into a neat
category. Simple mathematical operators are used throughout patches
for many reasons, so when you ask:
> One question I always have (and nobody ever answers it)
> is how we use the maths/binary signal operators [*~] boxes, or of
> course [+~] etc.
The answer is that it depends on the task. It is most common to see
the arithmetic, trig and logical units used for conditioning
control parameters.
That means changing the data coming out of some source like an
accelerometer, touch screen, potentiometer, or a virtual GUI
object, into a different sort of data that can be used by a DSP
system.
Common changes include, thinning the data (perhaps to remove duplicates)
interpolating and averaging the data, removing outliers (clipping) or
sudden changes (slugging/slewing), filtering to remove certain
frequencies, like high pass filtering to remove DC drifts, and so on.
A DSP or control systems book with a chapter on data acquisition will
help audio application designers to understand these issues of connecting
controllers to code.
A particularly common problem is remapping data. Say I have available
float data in the range -1.0 to +1.0, and I need it expressed as
a percentage in the range 1 to 100 as an integer. This might be typical
of a feed to a web page generator that makes pie charts or some other
highly simplified presentation code.
Now cast your mind back to high school math classes, and the equation
of the line:
y = kx + c
x and y are the independent and dependent variables respectively (x set
the domain and y is the range), the slope is the k factor, and the
offset or intercept is the constant c
In parameter conditioning we very often want to map one set of data
points to another, and this is a case of using a transfer function.
In this case it is a linear transfer function that just stretches or
squashes the line to have a new slope, and moves it by some offset.
So the input becomes our x variable, and the output is y
In the above example, we need to map a range of 2 onto a range
of 100, so multiplying by 50 seems the right thing to do.
But as you see, that will give us -50 to +50
So, we have the right size, but it is in the wrong place, and to
remedy the problem we add a value of 50.
But now there is a new problem, we don't want zero to be in our
data set. How will you remove that? What does that do to the
choice of multiplier?
Can you see that rearranging the y = kx + c equation for your
unknown and deciding the offset first then the multiplier you
can map any linear range onto any new linear range?
Also, the data user specified that they wanted an integer. Type
casts should be the last thing that you do, and be aware whether
you do truncating or rounding.
> As an example I notice that in your patch /Six Simple Synthesisers
> 104/ you add in
- range of sweep and [+ 100] minimum sweep
> range.
Exactly. So given that the sliders had a range of 0 to 1 the total
range is now 100 to 2100
> Why the two boxes? I understand that adding the 100 will keep
> the sweep above a certain limit, but why not just have [*1900]?
Because, assume the input is zero, then 1900 * 0 = 0, which
violates our wish that the filter never goes below 100
> maybe it's a simpler (cleaner), and better way to control the sweep?
> I imagine that the range of 2000 is just a trial and error figure,
> or does it have some more important role - later the sweep is
> increased to *3000.
Yes, don't worry too much about precise value outcomes in media
engineering, most times you just care if it looks, feels or sounds
good. However, that is not the same as saying don't be rigorous
about your mathematical method. As you can see it takes careful
thought to condition input data properly and you should be
systematic and try to understand _why_ a particular kind of
transfer function or filter is needed.
Footnote :
It was great to have an answer and thought it may interest some people here. Unfortunately it's difficult to know which section to post it in, but since it's not a tutorial I placed it here._