|
raddevus wrote: I know there basically is a solid way to say XXX frequency is a particular note
Not really, or at least only if you make certain assumptions. From the perspective of music theory that isn't correct at all.
Warning: below is a little clarification about technicalities and theory, but for the practical purposes of what you're doing you don't really need to take this into account for most cases. I think it's worth mentioning though while we're discussing notes and frequencies, because there are some misunderstandings here. And, yeah, I have a bit of a thing about this because it's a common misconception that bugs me.
You can easily find tables of frequencies matched to notes on the scale, but they are lies told for practical purposes and convenience. In reality, there is no defined frequency for any note, there are just arbitrary standards that can be--and often are--ignored by musicians in practice.
The A=440 thing is a relatively recent convention designed to make it easier for musicians to play together while being in tune with each other. It's just a convention, and it's far from universal. For the purposes of a MIDI pickup, though, it's safe to assume that A=440 unless the guitarist is into archaic or oddball tunings.
That's the easy part, though. The real problem is that the Western scale is based on ratio intervals between notes rather than any absolute pitches (frequencies), and the intervals change with each key, which can require the notes themselves to change frequency to be perfectly in tune for a particular key. That is, E-flat in one key may be a slightly different frequency than E-flat in another key, if you want perfect consonance with the other notes on the scale. You might think that's crazy, but it's true, and it's the reason for things like blue notes in jazz.
Microtonal instruments like voice, violin, trombone, etc. automatically adjust pitch for each key, because intonation is done by ear and your ear will tell you to adjust the intonation for each key, musicians do this automatically. But fretted and keyboard instruments are another story, they have discrete pitches that they can play with little wiggle room, and so the musician can't adjust on the fly and it's impossible to tune them so that they are in tune in every key.
This is why every piano in the world is out of tune, always, and if you don't believe me ask a piano tuner. The only way to make a piano truly in tune is to re-tune it every time you change the key being played in, but since that isn't practical pianos are normally tuned in such a way to spread the inaccuracies evenly over the whole range of the instrument to keep the problem minimal (this is called even temperament, and this is what those frequency-to-note tables are based on, and that's why those tables are lies).
So, no, there is no real mapping between frequencies and notes on the scale, not technically. But by convention and practicality much of this is hidden unless you have a good ear and/or an interest in music theory. The upshot, though, is that you should take those frequency/note tables with a grain of salt and not try to match the frequencies too exactly. However, using such a table should work just fine if you are using it with a guitar tuned to A=440 and even temperament. But it won't work for all cases, and anyway I think it's best to understand that notes aren't defined by frequencies if you're really going to get deep into this kind of thing.
modified 19-Oct-18 14:03pm.
|
|
|
|
|
That's a great read but my original statement was a mistake:
raddevus wrote: I know there basically is NOT a solid way to say XXX frequency is a particular note
I left out the word not. Oops. 
I learned a lot about pitches, instruments, tambre from my time at Berklee College of Music and from David L Burge (Perfect Pitch Ear Training SuperCourse: Name EXACT Notes by Ear.[^]).
|
|
|
|
|
Haha!
Well, you gave me an excuse to go on a rant about even temperament, so that was fun at least 
|
|
|
|
|
|
Bit shift 5 is the same as divide by 32. (only faster)
It is taking 32 samples, and calculating the average.
|
|
|
|
|
englebart wrote: Bit shift 5 is the same as divide by 32. (only faster)
It is taking 32 samples, and calculating the average.
Yes!! Nailed it on both accounts.
It's a nice little piece of code from the sample. 
|
|
|
|
|
This picture is a screen shot of the default Git Bash console on my Windows 10 desktop. Does anybody, even on the Git maintainers team, honestly expect people to like these colors? What were they thinking when they picked them? Please tell me they were on drugs, and can't be held responsible! 
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
|
Yes, it does. Long live the CGA color scheme.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
DBase IV
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I do... It took me a while to configure a similar configuration on my Debian. I would ditch the red though, on a black background it's eyeburning (discovered the hard way when I set up bash for a red on black text. 15 minutes later I was back to green on black).
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
modified 4-Sep-18 4:20am.
|
|
|
|
|
den2k88 wrote: red though, on a black background it's eyeburning
The default Git bash colors are really terrible on Windows.
I had an issue even being able to see the text, just as you said...red on black background can barely even be seen.
I don't think the colors were ever "tested". Just like they were set and never looked at by the design team. Makes no sense at all. 
I finally chose the dracula theme. That one should really be the default.
|
|
|
|
|
With the exception of red that is quite common in bash highlighting, even in full terminal mode I remember those colors.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
What do you think of Blue text on a Black background? Moreover, there are other low-contrast colors, too. It just sucks.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
The Chocolatey warning message shown here is much easier to read. IMO, their maintainers have a much better understanding of the principles of good color selection than do the Git maintainers. Though Chocolatey has some lapses, given their characteristics, I suspect they are actually caused indirectly by calls into PowerShell.
Several years ago, I made a study of console mode color combinations, for which I created a program that ran through every possible combination of foreground and background ConsoleColor settings. Maybe it's time for me to write about it.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
The bluescreen isn't blue without a reason: You will find in a lot of books on graphic design that white on blue is one of the most readable color combinations. Black on yellow is another combination at the top of the list. I don't remember which of the two has the top score; it is a very close race.
So it should come as no big surprise that traffic signs very often are black on yellow or white on blue. Pink on black may catch your attention more easily, but if the text content is the essential thing, then green on black is far better, much more readable.
When I was still a student, I did all my programming green-on-black - we had no alternative (except for the card readers that were still available). A couple years later, black-on-white screens were introduced, but made no great success: Green-on-black, 25 lines of 80 chars, was the preferred choice until the arrival of VGA (and even a few years into the VGA era).
In my first job, when PCs had just been introduced, one of the old guys pointed to the Tandberg 2215 terminals: "Take a good look at these! You won't see anything that can match them, ergonomically, for the next ten years, at least." --- It turned out that he was right. Screens got more functions, more colors, more resolution, but it took more than ten years before we got the same readability, and even today, screens have higher functionality, but are no better ergonomically. (That is of course strongly affected by how we choose to use these screens - today, poor ergonomics are essentially caused by poor choices, not by screen technology.)
|
|
|
|
|
Black on yellow is tops I believe, that's why so many road signs are those colors.
|
|
|
|
|
That's been essentially my experience, too. Moreover, I cannot understand why anyone would pick a low-contrast color such as the stock blue color for text, when the default color scheme for most shells is black.
For years, I have considered attempting to devise an automated color picker that takes the active background color into account when it selects a foreground color.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
I love the blue screen. Illegible red text on that blue drives me up the wall. Nobody that coded that colour combo ever used it themselves, on Windows at least.
It's not just Git Bash - the Posh Git extension that makes PowerShell a Git console has exactly the same horrific colour scheme.
"'Do what thou wilt...' is to bid Stars to shine, Vines to bear grapes, Water to seek its level; man is the only being in Nature that has striven to set himself at odds with himself."
—Aleister Crowley
|
|
|
|
|
Here are the responsible people: Family[^]
|
|
|
|
|
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
It seems that project managers like to think that they know best, and screw the experts. I remember a senior manager telling the head of the Human Factors group on the Comanche helicopter that a double press world work, which meant that did not need a pressure sensitive screen. Of course what he did not seem to take into account was that the helicopter would be shaking and maneuvering, so the crew member would have to keep his eyes on the screen for both touches, instead of being able to take his eyes off once he had identified the control with his touch. Look at the crap Microsoft has given us like the ribbon and metro.
|
|
|
|
|
With regard to Metro, I agree that it's mostly a load of crap. However, after almost a decade of daily use, starting when I transitioned from Office 2002 (Office XP) to Office 2010, I've grown accustomed to the ribbon, and I have an idea about why they adopted it, and are extending it into other parts of Windows, etc. Somewhat to their credit, they seem to have learned from some of their mistakes, and are grudgingly adding support for the old, trustworthy Windows widgets to the Metro (UWP) kit.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
Their implementation in Office basically sucked for year since it did not allow you to change it, and it hide functionality. All they had to do was keep the menu, possibly using a scheme like used in several programs where you just had to hit the alt key, and give users the option of showing the menu all the time. They wanted to force people to use the Ribbon so they gave no option. Instead should have provided it as the standard option and allowed users to decide what they wanted instead of dictating. I too have gotten use to the Ribbon, but I am not sure it is that much better than toolbars. That the menu and toolbars have their place is shown in even Microsoft applications still using these older concepts, and you see menus all the time in Web apps. Nobody seems to have bothered with the Ribbon concept in web apps, which to me shows it was not all that great a concept.
|
|
|
|
|
You aren't likely to see it in Web apps because it significantly increases the download bandwidth required to support the page, since those graphics are much larger than any text menu. Even using something as efficient as SVG requires more bytes to transmit than the text, most of which must be transmitted anyway, to convey the URL behind each button. CDNs can mitigate the cost somewhat, but it requires a good bit of extra infrastructure to use them under HTPPS.
Another reason you are unlikely to see ribbons in Web applications is that they consume far more screen real estate, which is contrary to Responsive design principles. In that regard, Google is pushing developers very strongly in that direction, and with good reason. Who knows, maybe we'll eventually get back to the simple predominantly text pages that dominated the early WWW.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
