Anal Probe help file question
Hi,
I have a small and simple question regarding the help file that comes with ANAL. What is the logic behind using the shift operator to store numbers in the "high seven bits"? I'm obviously missing an important mathematical-theoretical foundation, so please, someone enlighten me. Is this just a more efficient method of handling values, or long list of values?
Not really a question about [anal] and its good friend [prob], but about simple bit manipulation and binary numbers.
You probably did binary numbers in about second grade and since forgot them. I'm not going to write a primer for you, but you might want to take a look at the Wikipedia article on Binary Numbers (which, unfortunately, probably goes into too much detail for your purposes).
Let's do an analogy with decimal numbers to get you on the road. Say you've got two 3-digit numbers that you need to store as a single number (or index). Assume, furthermore, that the representation has to be unambiguous, you need to be able to re-create the original pair of numbers from the representation, and you can use 6-digit numbers for storage.
The obvious trick is to take the first 3-digit number, "shift" it 3 places to the left (also known as "multiplying by 1,000" or "tagging on three zeros on the right"), and then add the second 3-digit number to the rightmost digits.
As an example, if the first value is 123 and the second value is 987, you shift 123 to get 123,000. Then add 987 to get 123,987. Extracting the original two values is left as an exercise for the reader, as well as the proof that the 6-digit representation is unique for every possible pair of 3-digit numbers.
Binary is just the same in binary. To pull the trick off in binary, you do need to be aware of how many binary digits (that's where the word "bits" comes from) you need for representing your values.
Hope this helps.
Thanks Peter. Now I understand, and am ready to grease up on my math.
I never was that good with maths, but I'm fairly good with logic. I wonder how many Maxers have had to take out their (algebra, trig, etc.) books off the shelves...
Max is at least 90% logic, really. The rest is in the helpfiles, more or less :)
I've only twice had to dig real deep in some math, and both were for doing some cartopol/poltocar magic.
Thank you for that insight. Are you also including MSP in this 90%? I ask because I'm somewhat baffled by having to re-learn trig and algebra for making things sound the way you want them to sound. Not that I'm not prepared, or willing to do so, BTW.
I've just been (re-)reading some literature on what it looked like to program computer music back in the "Good Old Days" of the 1970s. Not to put too fine a point on it, but what we have to do in Max/MSP is, well, baby-talk compared to the math that was needed four decades ago.
I'm enough of a UI person to want to argue that there should be no math at all required to make music with computers. The computer ought to be completely transparent, no matter what you're doing with it. OTOH, it seems for some stuff you still do have to look under the hood. And Max/MSP does have a fairly geeky history, so tinkering with the carburetor and spark plugs is pretty much de rigueur.
"sound the way you want them to sound"?
Honestly, the example you've shown (markov chain that stores data in a funky way "inside a number") isn't really representative of max in general ;)
Sure, there's some difficult math involved in msp things like the FFT stuff, and building windows for transforms etc, but that's what the objects are for; they help us by doing those things, so that we don't need to learn them.
I think the helpfile you showed does "too good of a job" explaining *how* it does things, we don't really need to know them, even though some of us on here enjoy diving into the deep end for that information.
basic math and somewhat of an intermediate understanding of logical operators and you're good to go. Oh, and with msp, understanding basic sound design building blocks really helps a lot, too.
Also, for the sticklers, the objects are "anal" and "prob", which are abbreviations, whereas "anal probe" is something altogether Freudianly different ;)
i wonder why the anal example shows that this way, using binary format.
i think i would do this on the decimal layer in this situation, so that i end up with numbers up to 1280128.
using bin conversion seems only interesting when you exceed 8 digits so that it stops working the decimal way.
Hahahaha! You're welcome Tokyo Rose. I did almost retract my words, but then again, I'm pretty sure that (most) Max programmers are deep in their hearts just some silly folk. I have seen tons of other objects with equally funny names.
Regarding maths in Max, perhaps this is getting off-topic but I wonder if the old academic adagio of learning from the rudiments is really applicable to MSP. What I mean with this is taking introductory classes and reading technical books with lots of mathematics to learn DSP. I guess it distills to the usual problem we encounter with Max, when we find we are taking way too much time honing our patching skills in detriment to actual music-making.
btw, in maxmsp version 4.2 - 4.5 for OSX cycling74 had chronic constipation implemented into [anal]: the "reset" function did not work, which made the object more or less unusable.
-110
Actually,
110: Which Max version are you using? Have you checked your anal? I'm using 6.1 and mine is exhibiting problems of that very nature. The reset command is not wiping the memory, but the clear command works alright. Also, I don't know if this is normal (probably related to the above discussion) but number pairs above 128 do not get indexed.
Time to call Dr. Kellogs, perhaps?
My, how charming it is to see a new generation discovering the [anal]-[prob] joke.
It's not that the older correspondents are "crusty, outdated, obsolete." It's just we got the pun when Rose was in short pants (more likely, nappies). Nowadays it's as fresh as a chicken-crossing-the-road routine.
Cue: "Don't they teach kids anything nowadays?"
>>110: Which Max version are you using?
4.1 and 4.63 for development, and 4.5x and 5.x for casual testing.
>>Have you checked your anal?
how did you find out i am a pevert?
actually i have not. i just rembered that in 4.2 it didnt work right, the way i described.
that old install is still here, if the authorisation will allow me that i will check into it later.
becasue i just remeber, that back in the days i also had a malfunction of my [pak] - which, when investigated for, was caused by a corrupt pak file in my harddisk. so eventually the same is true for my [anal]?
>>I’m using 6.1 and mine is exhibiting problems of that very nature.
thats not good. one reason more to write my own stuff, like i used to do most of the time. [histo] at least can do half of the job of [anal], too, if required. but somehow i dont trust these max v.3 midi and note releated files, dont know why.
>>but number pairs above 128 do not get indexed
yeah only 0-127 do work, that is intented. another unpretty leftover from the good old midi times.
i assume that the object internally would have to be changed in a dramatic manner when trying to raise that range/buffer size.
when you want to build a second order markov chain, which can also handle chords, 128 is definetly not enough to store all the different IDs for transitions of "60-63-67 60-67-72 72-74-65" format.
but one can use a bunch of parallel [anal]s to come around that issue. or even a poly~.