|From FingerSoup on 16.01.2003, 05:53:
For VST/VSTi, you can compare the decimal value to the Hex value by double-cllicking and then reading the values at the bottom of the "psycle-native gui" frame (the grey part on the right).
Psycle plugins are a different matter entirely. People code them to work however they want, and have no display to tell you the HEX value of something decimal
So am I right in thinking that Hex is mainly a language set and used mostly by the programmer whilst decimal is to a large extent being used for synthesis calculation in instruments
It's not a language per se, but a different way to represent a value.
Hex is Base 16. Decimal is base 10. Binary is Base 2, and Octal is Base 8.
So, assuming the same 16 bit integer:
Decimal - 46759 IS:
Binary - 1011011010100111
Octal - 133247
Hex - B6A7
- Start History and Math Lesson -
Because all computers work in Binary, and most programmers are lazy, they want to write down the least amount of data. Here's how binary works (and why it takes too much to write.)
A byte has 8 bits. the maximum value for any amount of data is (2 to the power of N)-1. thus the largest number possible in 8 bits of data is 255.
Given the decimal number 212,
Just as decimal has the following place-holders:
100's 10's 1's
2 1 2
In decimal, you can have 0-9 in any of the placeholders. multiply these digits by the place holder, then add all the results together. So for decimal, you get:
(100 * 2) + (10 * 1) + (2*1) = 212
Binary only allows 2 digits (0 and 1), and thus works with the following place holders:
128's 64's 32's 16's 8's 4's 2's 1's
1 1 0 1 0 1 0 0
therefore following the same logic as the decimal numbers:
(128*1) + (64 *1) + (32 * 0) + (16 * 1) + (8 * 0) + (4 * 1) + (2 * 0) + (1 * 0) = 212
So, to a computer, 212 in Decimal is really 11010100 Binary. Talk about a lot of writing for lazy people...
Because Binary is base 2, programmers decided that the easiest conversions would be multiples of base 2. First was Octal, which is base 8. With one Octal digit, you can represent 3 bits of data. Start at the left, and group in 3's. Then convert each chunk of 3 bits to decimal. Place the digits next to each other, in the same order as the groups were in. Thus, 101 would be 5 Octal, 010 is 2 octal, 101110 is 56 octal, etc...
The biggest problem with Octal, is that computers store things in 8 bit. Octal could only represent bits in groups of 3, meaning a full 8 bits (Decimal 255, or binary 11111111) is represented in octal as 377. To edit a binary file directly, this short form would either require endless conversions for a file to be read (as one byte would overflow into another) or it would requite adding an extra bit that is ALWAYS set to zero. It gave most programmers icky feelings when confronted with having to do these kinds of things... Especially when your computer back then had only 16K of memory to do these conversions... Programmers don't like icky feelings. So they asked: "Why don't we group 4 bits together instead of 3?" The answer was "Because there aren't enough digits." Due to the sheer bloodymindedness of programmers, they said: "Fine. Lets just steal some letters from the alphabet and call them digits!"
So hexidecimal was born. A=10, F=15. You can fill in the rest in between. Basically, you take your binary code (11010100) and break it into groups of 4. convert to decimal, and substitute values over 9 with the appropriate letter.
0100 = 4
1101 = 13 = D
11010100 = D4
Hex was born, and all was good in the land of programming. FF now represents 255 (the maximumn 8-bit value).
Now of course we have the problem of decimals, or "Floating point math" as we call it in programming. Floating point is just too difficult for me to explain, so someone else can. Basically, floating point math has a bunch of extra rules, so the computer can convert 4.342869 to a bunch of 1's and 0's for the computer to do math with. If you just write it in Hex, it is ever-so-slightly less processor intensive, as the computer will not have to calculate these conversions for you.
- end Lesson -
So, the answer to "Is it difficult to convert Hex to Floating point?" is Not really for a computer. It will take a little bit more processor time, but not much (unless you really overdo it).
But, if the question is "how many interface changes would it take to convert Hex to floating point in a tracker-style interface?" the answer is, a lot. You have to consider how many decimal places you will allow for the floating point number, how many bits of accuracy, Maximum/Minimum values, etc... Whereas with Hex, you just need to worry about "how many bits Do I have?" because every digit in Hex really accounts for 4 bits of data. Thus regardless of how big your number is (within the limits of your bit limit) you will ALWAYS have a specified number of HEX digits, thus a specified number of columns. Hence, the grid-like view of trackers: Every track and note looks the same.
I thought you beat the inevitability of death to death, just a little bit...