shift operators in max...

Kasper's icon

hi

for many plug-ins (but not only for plugins) I used to use the
"shift" operators in order to
a) have a bigger/better resolution
b) have a"coarse" and "fine-tune" control

(I guess this is what is called 8-bits versus XX-bits , don't know
how many, in any case with this method I have 1144 values instead of
128)

Now I am switching to a new controller, sending OSC values between
0.-1. (it is touchOSC on an iPod Touch) - so teh number of
points/values are "infinite" (or at least more than 128, I don't know
how many actually) but I would like to keep the same Coarse/fine-tune
system

I came with a patch which replicates what "shift operators" does
(but in floats), but stil I am wondering if, in this case, I should
not think of a very different method.... (I guess the << 3 is very
MIDI-related, so instead of using * 8. I could do * 9. - the total
range would be a more human-friendly 0-10, etc...)

any advice welcome

here is the small patch , in max4.6

many thanks

kasper

Max Patch
Copy patch and select New From Clipboard in Max.


seejayjames's icon

I also really like the TouchOsc. Cool stuff!

Maybe if you use pairs of sliders (like using 4 as 2 sets of 2 in the Simple Mode), then one could be for Coarse and one for Fine. Just scale the 0. 1. range to an appropriate Coarse range (maybe 40-2000 for frequency?) and the second one to something like -20. 20., then add the results? Alternatively, the Fine one could be (say) 0.9 to 1.1, then you multiply the Coarse by this. Then the values would always scale to the same percentage regardless of the range of the Coarse. I'd probably go that route.

(scale 0. 1. 40 2000) (scale 0. 1. 0.9 1.0) etc. applied to the incoming slider or XY data. No bit-shifting needed.

--CJ

Kasper's icon

>
>Maybe if you use pairs of sliders (like using 4 as 2 sets of 2 in
>the Simple Mode), then one could be for Coarse and one for Fine.
>Just scale the 0. 1. range to an appropriate Coarse range (maybe
>40-2000 for frequency?) and the second one to something like -20.
>20., then add the results? Alternatively, the Fine one could be
>(say) 0.9 to 1.1, then you multiply the Coarse by this. Then the
>values would always scale to the same percentage regardless of the
>range of the Coarse. I'd probably go that route.
>
>(scale 0. 1. 40 2000) (scale 0. 1. 0.9 1.0) etc. applied to the
>incoming slider or XY data. No bit-shifting needed.

hi

this is certainly quite close to the patch i did send - however there
is more in the "bitshift" system than only a coarse/fine:

the nice thing with this bitshift system is that you have ALL values
between 0 and 1144 - with the sytem of 40-2000, on an iPod (which is
a small surface) I doubt if you can have ALL frequencies, even with
-20/+20

of course one has to wonder what could "all frequencies" mean - once
we talk in frequencies (not notes) andin floats

What I do for the moment is to multiply by 9. the first slider, and
leaving the second one in the 0-1 resolution, it gives me the range
0.-10. (in floats) and what i feel is a good resolution. And "all
values" are covered

but if someone has a better idea, I would be very willing to hear about it

best

kasper

Stefan Tiedje's icon

Kasper T Toeplitz schrieb:
> of course one has to wonder what could "all frequencies" mean - once we
> talk in frequencies (not notes) andin floats

If you deal with frequencies, I'd always want a relative resolution,
that is actually notes and cent. You will always have a resolution
restriction to the number of pixels involved. That will be true for Max
or any pixel based display. I'd interpret the sliders as notes/cent and
then translate them to frequencies with mtof. That way you always have a
resolution which corresponds to the ear...

Btw. a shift by 3 is exactly the same as a multiplication by 8...

Stefan

--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

Kasper's icon

>
>
>Btw. a shift by 3 is exactly the same as a multiplication by 8...
>

yeah, I know ( or learned) - that's why on my included patch i did *
8. - but on the iPOD (or osc) * 9. seemed more logical

thanks

kasper