Just to add to the confusion, I think I may have done this to myself. I had already installed the app earlier, but this afternoon, I changed the bundle identifier, so for a short while, two apps with the same name existed on the phone. I think that may have been the ultimate cause of my mionr problem.
Friday, November 20, 2009
Failed to load error
Just had an experience where I was trying to load an app onto my phone, but kept getting "Failed to upload to device." I cleaned the source code, tried other miscellaneous things, reset the phone, and nothing. It took quitting Xcode and restarting to get it to work, which I find a very common requirement.
Just to add to the confusion, I think I may have done this to myself. I had already installed the app earlier, but this afternoon, I changed the bundle identifier, so for a short while, two apps with the same name existed on the phone. I think that may have been the ultimate cause of my mionr problem.
Just to add to the confusion, I think I may have done this to myself. I had already installed the app earlier, but this afternoon, I changed the bundle identifier, so for a short while, two apps with the same name existed on the phone. I think that may have been the ultimate cause of my mionr problem.
Tuesday, November 10, 2009
View Connection Error
While experimenting with the navigation controller, I got this error after having hooked up a nib to the main view controller that show up under the navigation controller in IB:
reason: '-[UIViewController _loadViewFromNibNamed:bundle:] loaded the "MainMenuViewController" nib but the view outlet was not set.'
What I had forgotten to do was to go into the MainMenuViewController and attach the view to the File Owner.
reason: '-[UIViewController _loadViewFromNibNamed:bundle:] loaded the "MainMenuViewController" nib but the view outlet was not set.'
What I had forgotten to do was to go into the MainMenuViewController and attach the view to the File Owner.
Monday, November 9, 2009
How to access resources in the main bundle.
The app I'm working has images embedded in the bundle; they may be JPG or PNG. Trying to find a path those resources can be done in one of three possible ways, as far as I see right now:
1) NSString *imgPath = [NSString stringWithFormat:@"%@/%@", [[NSBundle mainBundle] bundlePath], nameOfImage];
#1 is what I ended up using, since that's exactly where the images are located and I don't have to be concerned about the type of the image.
2) NSString *docPath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory,NSUserDomainMask,YES) objectAtIndex:0]; // And add as part of a formatted string, like in item 1.
#2 was a side path I took, forgetting that you have to add the references as part of a folder structure (which I'm not completely clear on at this time)
3) NSString *jpgPath = [[NSBundle mainBundle] pathForResource:nameOfImage ofType:@"jpg"];
#3 was the way I was recently taught, but the it always bothered me that there was an "ofType" message. How can you rest assured that the image type will ALWAYS be of that type. I'd have to do a bit of extra work (pulling from a plist, or database, or parsing the image name) to ensure I had the proper resource type. And since images are, very generally speaking, interchangeable (at least as far as my content developers are concerned!), I feel this is a case where it pays to be more flexible, so #3 just doesn't work for me (in this situation).
1) NSString *imgPath = [NSString stringWithFormat:@"%@/%@", [[NSBundle mainBundle] bundlePath], nameOfImage];
#1 is what I ended up using, since that's exactly where the images are located and I don't have to be concerned about the type of the image.
2) NSString *docPath = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory,NSUserDomainMask,YES) objectAtIndex:0]; // And add as part of a formatted string, like in item 1.
#2 was a side path I took, forgetting that you have to add the references as part of a folder structure (which I'm not completely clear on at this time)
3) NSString *jpgPath = [[NSBundle mainBundle] pathForResource:nameOfImage ofType:@"jpg"];
#3 was the way I was recently taught, but the it always bothered me that there was an "ofType" message. How can you rest assured that the image type will ALWAYS be of that type. I'd have to do a bit of extra work (pulling from a plist, or database, or parsing the image name) to ensure I had the proper resource type. And since images are, very generally speaking, interchangeable (at least as far as my content developers are concerned!), I feel this is a case where it pays to be more flexible, so #3 just doesn't work for me (in this situation).
Regarding the Tab Bar control
When adding new tabs and populating the data from another nib view, two things need to be set:
1) In the actual nib view, you need to set the class to the controller, as you would expect.
2) You also need to do the same thing for the view that is listed under the tab controller (once for each tab).
Otherwise you will get a crash if you try to access anything in that particular tab:
'[ setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key webView.'
1) In the actual nib view, you need to set the class to the controller, as you would expect.
2) You also need to do the same thing for the view that is listed under the tab controller (once for each tab).
Otherwise you will get a crash if you try to access anything in that particular tab:
'[
Friday, November 6, 2009
Don't forget to synthesize!
I decided to reduce the problem I was having by removing extraneous files from the project. In the process, I moved certain properties from one file to another.
All was well, and I solved that initial problem.
However, I started adding back in some additional code, and got this error when trying to assign a UIImageView pointer to a property:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[MainViewController setVideoSlot1:]: unrecognized selector sent to instance 0x3d23150'
As it turns out, I forgot to (re)synthesize those properties that I had earlier moved from one file to another. The odd thing is, Xcode didn't bother to give me the normal warnings for properties that haven't been also synthesized. There maybe an additional condition that has to be fulfilled before you will see that warning. Keep an eye out.
All was well, and I solved that initial problem.
However, I started adding back in some additional code, and got this error when trying to assign a UIImageView pointer to a property:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[MainViewController setVideoSlot1:]: unrecognized selector sent to instance 0x3d23150'
As it turns out, I forgot to (re)synthesize those properties that I had earlier moved from one file to another. The odd thing is, Xcode didn't bother to give me the normal warnings for properties that haven't been also synthesized. There maybe an additional condition that has to be fulfilled before you will see that warning. Keep an eye out.
View Linkage Error in Tab Bar Controller
In an attempt to add new views to the tab bar view template app, I got the following error (truncated from its lengthier form:
[UIViewController _loadViewFromNibNamed:bundle:] loaded the "FirstTab" nib
In the MainWindow.xib tab view controller, I had already linked my "FirstTab" nib, but a second step was required:
[UIViewController _loadViewFromNibNamed:bundle:] loaded the "FirstTab" nib
In the MainWindow.xib tab view controller, I had already linked my "FirstTab" nib, but a second step was required:
- Open FirstTab.xib.
- Right click on the view (or do this through the inspector).
- Drag the New Referencing Outlet to the File's Owner.
- Select the 'view' option (which is likely the only one).
Thursday, November 5, 2009
Don't move the buttons, please
You can often find this control set on many web comic sites. When you are viewing the most current comic, there is no need for Next/Newest, so they aren't displayed.
However, when you click on Previous, frustration ensues:
The Previous button is shift over to the left. The cursor doesn't move, so the next time I click, I actually end up pressing Newest, returning me back to the beginning. Awkward.
However, when you click on Previous, frustration ensues:
The Previous button is shift over to the left. The cursor doesn't move, so the next time I click, I actually end up pressing Newest, returning me back to the beginning. Awkward.
Tuesday, October 27, 2009
Why does 'cd' work differently for drives and paths?
This has been a frustrating pet peeve of mine for a while.
When I hope my Windows command line, it starts me out on a network drive, specifically "H:", which of course I rarely have a need to be in. My first instinct, which is always wrong, is to type:
This always fails, because what Windows expects you to do is this:
Why? Is there a way around this? My main problem is that I don't use the Windows command line that often, so I forget the nuance of switching between drives as opposed to switching paths.
When I hope my Windows command line, it starts me out on a network drive, specifically "H:", which of course I rarely have a need to be in. My first instinct, which is always wrong, is to type:
- H:>cd c:
This always fails, because what Windows expects you to do is this:
- H:>c:
Why? Is there a way around this? My main problem is that I don't use the Windows command line that often, so I forget the nuance of switching between drives as opposed to switching paths.
Friday, October 23, 2009
Automated Zipping in Xcode
I like to automate everything. I'm a firm believer in the "one-click, build-all, distribute-all" type of solution.
Per Apple's recommendations, after you generate your .app file, you need to compress it by right clicking on the file and selecting, conveniently enough, "Compress." Not exactly automated. After doing some searching, I found this little gem:
Luckily, I found an alternate gem:
Per Apple's recommendations, after you generate your .app file, you need to compress it by right clicking on the file and selecting, conveniently enough, "Compress." Not exactly automated. After doing some searching, I found this little gem:
- ditto -c -k --sequesterRsrc --keepParent "$PRODUCT_NAME.app" "$PRODUCT_NAME$revnum.zip"
Luckily, I found an alternate gem:
- zip -r -T -y "$PRODUCT_NAME$revnum.zip" "$PRODUCT_NAME.app"
Tuesday, October 20, 2009
I forget where I found this, but it's been useful to me:
Error:
"svn: Can't move '.svn/tmp/entries' to '.svn/entries': Operation not permitted" (in Terminal, when trying to check-in or update the repository)
Fix:
Use 'chflags -R nouchg .' on the command line. Note '.' at the end. It is not optional.
Here is what the options do:
-R: "Change the file flags for the file hierarchies rooted in the files instead of just the files themselves."
'nouchg' is the negated form of: "uchg, uchange, uimmutable set the user immutable flag (owner or super-user only)"
Error:
"svn: Can't move '.svn/tmp/entries' to '.svn/entries': Operation not permitted" (in Terminal, when trying to check-in or update the repository)
Fix:
Use 'chflags -R nouchg .' on the command line. Note '.' at the end. It is not optional.
Here is what the options do:
-R: "Change the file flags for the file hierarchies rooted in the files instead of just the files themselves."
'nouchg' is the negated form of: "uchg, uchange, uimmutable set the user immutable flag (owner or super-user only)"
Friday, October 9, 2009
While trying to add UIWebView. Have the IBOutlet connected and it compiles, but I'm missing something:
Tried:
when it should have been:
where WebDialog inherited from ParentDialog. Inheritance is a tricky little bugger if you're not paying attention.
2009-10-09 16:04:38.035 Green Splash Theme[2529:20b] *** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[What am I missing?setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key myWebView.'
Tried:
- Link the UIWebView's delegate to the file owner;
- Make the UIViewController a
as well. - Ah-ha! The class that was controlling the UIWebView was a sub-class of another class. In my call to instantiate my new UIWebView class, I used the parent class instead. Changing it to the more specific class made it work.
vcCtrl = [[ParentDialog alloc] initWithNibName:@"WebDialog" bundle:nil];
when it should have been:
vcCtrl = [[WebDialog alloc] initWithNibName:@"WebDialog" bundle:nil];
where WebDialog inherited from ParentDialog. Inheritance is a tricky little bugger if you're not paying attention.
View Outlet Not Set Error
Here's another interesting one:
2009-10-09 10:20:36.845 MyApp[329:20b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '-[UIViewController _loadViewFromNibNamed:bundle:] loaded the "MayAppView" nib but the view outlet was not set.'Make sure that you connect the View in the nib file to the file's owner. (I'll try to explain it better at another time.)
Thursday, October 8, 2009
Unrecognized Selector Error
In case you get this:
Remember to synthesize the property in question (in this case 'Delegate', which would require a 'setDelegate' selector if I were to hand-code the property). I like Objective-C overall so far, but there are a few quirks that bug me. The property + synthesize issue is one of them. You don't have to call @synthesize if you make the getter/setters yourself, but failure to do either thing should generate an error, not a warning like it does during compilation. I totally missed it.
2009-10-08 17:26:29.125 MyApp[5487:20b] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[HowToPlayViewController setDelegate:]: unrecognized selector sent to instance 0xd3dae0'
Remember to synthesize the property in question (in this case 'Delegate', which would require a 'setDelegate' selector if I were to hand-code the property). I like Objective-C overall so far, but there are a few quirks that bug me. The property + synthesize issue is one of them. You don't have to call @synthesize if you make the getter/setters yourself, but failure to do either thing should generate an error, not a warning like it does during compilation. I totally missed it.
Moving onto the Interface Builder
My student has been sick all week, so I haven't had an opportunity to continue on with lessons, which is great, since I didn't finish writing up all that he and I had talked about last time.
This time we'll talk about the Interface Builder (IB). The IB is an entirely separate application from Xcode and is used to visually create the user interface (whereas you would normally have to do it through code). The IB creates the .nib/.xib files mentioned last time and though IB is a separate app, you typically end up launching it by clicking on the .xib files that are in your Xcode project. In the case of a simple project, it's typically called MainWindow.xib.
Once in IB, you have four primary windows to worry about (sometimes more).
1) The nib list window -- this contains a summary of all the components of your UI.
2) Inspector window -- this contains the details of the particular component you're looking at. It has four tabs on it.
3) Library window -- this is were all the UI components come from.
4) The user interface window -- this is where you drag items from the library onto.
For the moment, I'm not going to go into intimate details. Each item will take a bit to get into. Try this, however. Drag some Library items (like buttons, labels, etc.) to the UI window. In particular, add a UIImageView item. Initially, it's a blank rectangle. But if you highlight the view and go into the Inspector window -> Attributes, you should see a drop down box called: Image.
You may not have anything listed in the drop down. In that case, return to Xcode and add a png or jpg file to your project (the Resources group is a nice place to put it), then relaunch IB. It should show up then. Select it from the list and you should then see the image in the UI window. You may need to play around with other attributes and the sizing of the window to get the image to look right.
If you go back to Xcode and run the app (assuming you created a basic Windows-based app), then image should show up. Fantastic!
Getting an image to display is trivial, as you can see. Adding buttons and labels is also quick and easy. However, getting them to respond to a user's touch is a different beast altogether. We will need to talk about IBOutlets and IBActions at that point, and those topics are for another day.
This time we'll talk about the Interface Builder (IB). The IB is an entirely separate application from Xcode and is used to visually create the user interface (whereas you would normally have to do it through code). The IB creates the .nib/.xib files mentioned last time and though IB is a separate app, you typically end up launching it by clicking on the .xib files that are in your Xcode project. In the case of a simple project, it's typically called MainWindow.xib.
Once in IB, you have four primary windows to worry about (sometimes more).
1) The nib list window -- this contains a summary of all the components of your UI.
2) Inspector window -- this contains the details of the particular component you're looking at. It has four tabs on it.
3) Library window -- this is were all the UI components come from.
4) The user interface window -- this is where you drag items from the library onto.
For the moment, I'm not going to go into intimate details. Each item will take a bit to get into. Try this, however. Drag some Library items (like buttons, labels, etc.) to the UI window. In particular, add a UIImageView item. Initially, it's a blank rectangle. But if you highlight the view and go into the Inspector window -> Attributes, you should see a drop down box called: Image.
You may not have anything listed in the drop down. In that case, return to Xcode and add a png or jpg file to your project (the Resources group is a nice place to put it), then relaunch IB. It should show up then. Select it from the list and you should then see the image in the UI window. You may need to play around with other attributes and the sizing of the window to get the image to look right.
If you go back to Xcode and run the app (assuming you created a basic Windows-based app), then image should show up. Fantastic!
Getting an image to display is trivial, as you can see. Adding buttons and labels is also quick and easy. However, getting them to respond to a user's touch is a different beast altogether. We will need to talk about IBOutlets and IBActions at that point, and those topics are for another day.
Wednesday, September 30, 2009
Auto Insert Closing Braces in Xcode
Just a side note... I find this very handy under Xcode->Preferences:
Automatically insert closing "}"
I don't know why it's not checked by default, but there you go.
Basics of Xcode
My buddy already knows the Mac well enough to move around and has installed Xcode before. I'm not going into the install process; the instructions are clear enough. After the install, you can launch Xcode from Developer:Applications:Xcode.app.
On first launch, you'll see the Xcode News; I usually uncheck the display again box. You can restore it from under the Help menu. Close it for now.
Click File->New Project. You get something like this:
Lots of options to choose from. In the selection column on the left, you can pick from iPhone OS and Mac OS X options, as Xcode is used to develop software for both platforms. We're interested in the iPhone OS section for now. Under "Library" you can produce a static library, which is basically a collection of code that you can create to re-use across multiple application and share with your friends and family. That's a topic for another day.
Under "Application," there are a variety of choices. They are all ways to quickly generate a foundation of pre-written code for specific needs. You could choose any one of them and by adding and removing the write code, create another one from the list. There is nothing special about any of the project templates other than the fact they generate extra code for you that you might have needed to write anyway.
That said, choose the "Window-based Application," click on "Choose...," name the project something like 'MyCoolApp' and save it. This should pop up:
There's a lot to look at. Here's the high level things we're concerned with:
Groups & Files is where the source code, resources, libraries and lots of other things live. You'll be spending much of your time in the Classes group. You add, move, and remove groups as you desire in order to best organize the project. A well organized project is a happy project.
The contents of whatever is highlighted here will show up in the upper, right side, dual-colored pane. Any files that you highlight will show up in the lower right side editor pane, including pictures and plists, but not the likes of xib/nib files.
It's useful to go backwards up the Groups & Files list, starting with Frameworks.
By default, the Frameworks group contains the basics: UIKit, Foundation and CoreGraphics. These libraries give you the basic tools to start writing sophisticated code. You'll end up using at least one thing out of each of them 99% of the time, so Xcode puts them there automatically.
Under Resources, you get a the MyCoolApp-Info.plist (or just Info.plist in some cases) and the MainWindow.xib. The plist is the property list for the application and is used to set, as would be expected, various properties concerning your application, including the name that is to be displayed on the iPhone (otherwise, your app would be named the same as your project, i.e. "MyCoolApp").
The xib file (called a 'nib' file, despite the spelling; Mac OS X uses nibs while iPhone uses xibs. Coding for the Mac has been around longer and the name has stuck, since nibs and xibs essentially do the same thing) contains "freeze-dried code." Without going into too much detail, it part of the system (which launches the Interface Builder app) where you can easily layout your user interface without having to write code. However, you will need to write code to actually get your nifty new layout to do anything when the user taps on the screen.
The Other Sources group never gets touched. You can look at the two files in it, but don't touch them. I may mention somethings about 'main.m' in a later post.
And lastly, the Classes group is where you will do the main bulk of your work (unless you create another group that you'd prefer to work in). Under the Window-base Application template, there are two files, MyCoolAppDelegate.h and MyCoolAppDelgate.m.
The .h file is a header file; it is in essence a public view into the code. If someone is interested in how your code works (as located in the .m file), they would look at the .h file (because the .m file is typically not available for viewing). The .m file is the source code itself and where all the work happens. You will have multiple .h and .m files in any app that is of reasonable complexity.
That's it for now. More coming soon, hopefully.
On first launch, you'll see the Xcode News; I usually uncheck the display again box. You can restore it from under the Help menu. Close it for now.
Click File->New Project. You get something like this:
Lots of options to choose from. In the selection column on the left, you can pick from iPhone OS and Mac OS X options, as Xcode is used to develop software for both platforms. We're interested in the iPhone OS section for now. Under "Library" you can produce a static library, which is basically a collection of code that you can create to re-use across multiple application and share with your friends and family. That's a topic for another day.
Under "Application," there are a variety of choices. They are all ways to quickly generate a foundation of pre-written code for specific needs. You could choose any one of them and by adding and removing the write code, create another one from the list. There is nothing special about any of the project templates other than the fact they generate extra code for you that you might have needed to write anyway.
That said, choose the "Window-based Application," click on "Choose...," name the project something like 'MyCoolApp' and save it. This should pop up:
There's a lot to look at. Here's the high level things we're concerned with:
Groups & Files is where the source code, resources, libraries and lots of other things live. You'll be spending much of your time in the Classes group. You add, move, and remove groups as you desire in order to best organize the project. A well organized project is a happy project.
The contents of whatever is highlighted here will show up in the upper, right side, dual-colored pane. Any files that you highlight will show up in the lower right side editor pane, including pictures and plists, but not the likes of xib/nib files.
It's useful to go backwards up the Groups & Files list, starting with Frameworks.
By default, the Frameworks group contains the basics: UIKit, Foundation and CoreGraphics. These libraries give you the basic tools to start writing sophisticated code. You'll end up using at least one thing out of each of them 99% of the time, so Xcode puts them there automatically.
Under Resources, you get a the MyCoolApp-Info.plist (or just Info.plist in some cases) and the MainWindow.xib. The plist is the property list for the application and is used to set, as would be expected, various properties concerning your application, including the name that is to be displayed on the iPhone (otherwise, your app would be named the same as your project, i.e. "MyCoolApp").
The xib file (called a 'nib' file, despite the spelling; Mac OS X uses nibs while iPhone uses xibs. Coding for the Mac has been around longer and the name has stuck, since nibs and xibs essentially do the same thing) contains "freeze-dried code." Without going into too much detail, it part of the system (which launches the Interface Builder app) where you can easily layout your user interface without having to write code. However, you will need to write code to actually get your nifty new layout to do anything when the user taps on the screen.
The Other Sources group never gets touched. You can look at the two files in it, but don't touch them. I may mention somethings about 'main.m' in a later post.
And lastly, the Classes group is where you will do the main bulk of your work (unless you create another group that you'd prefer to work in). Under the Window-base Application template, there are two files, MyCoolAppDelegate.h and MyCoolAppDelgate.m.
The .h file is a header file; it is in essence a public view into the code. If someone is interested in how your code works (as located in the .m file), they would look at the .h file (because the .m file is typically not available for viewing). The .m file is the source code itself and where all the work happens. You will have multiple .h and .m files in any app that is of reasonable complexity.
That's it for now. More coming soon, hopefully.
Starting from Scratch
A co-worker of mine is interested in learning Objective-C. He has literally no coding experience at all, so I'm going to try and help him along. As you can imagine, I'm starting with the absolute basics. He is computer savvy, so that makes it a bit easier since I can often hand wave application level topics (like what a 'Group' is in Xcode and how to add files to it for example).
I think that Objective-C is a actually a fairly reasonable first language to start with (compared to C/C++/Java). Xcode and Interface Builder hide a lot of the nitty-gritty away from the user, so the ramp up time to get something fun and meaningful going is fairly short. You still have to take time to understand the concept of pointers and memory management which I think is a good thing. I always have been very conscientious my stack and heap issues and I think it has made me a better programmer. Luckily, memory management is very well defined (here), and the basic concepts are quick to grasp.
My plan is to get him up and running with the basics of computer science and present to him some best practices early on so that if he takes to it like a fish to water, he is got a solid foundation.
I think that Objective-C is a actually a fairly reasonable first language to start with (compared to C/C++/Java). Xcode and Interface Builder hide a lot of the nitty-gritty away from the user, so the ramp up time to get something fun and meaningful going is fairly short. You still have to take time to understand the concept of pointers and memory management which I think is a good thing. I always have been very conscientious my stack and heap issues and I think it has made me a better programmer. Luckily, memory management is very well defined (here), and the basic concepts are quick to grasp.
My plan is to get him up and running with the basics of computer science and present to him some best practices early on so that if he takes to it like a fish to water, he is got a solid foundation.
Thursday, January 29, 2009
Ah, the rosy memories of Palm
I am an ex-Palm programmer. It's been years, but I loved the whole programming culture that Palm had created. I loved their UI design philosophies, their hardware, the conventions, the fantastic API support, I loved it all. I was a Palm freak. Then not too long after the IPO'd, it got kinda sad there at Palm, it seems. There was no more love being pumped into their wonderful products. The kool-aid had gone sour for me (that, and the project I was working on that I so adored got cancelled), so I bailed out and found other new-fangled toys to play with (which was never quite as enjoyable). But here, now, many years later, Apple has restored my faith in the idea that you can indeed have an exquisite, easy to use interface on a handheld device. And more importantly you can provide excellent developer support at the same time. Or at least that's how it seems to me for now... I reserve the right to be cynical. I've eaten from the Cupertino tree many times in the past; not all its fruit are sweet and delicious.
Music Scales
I was practicing my scales up until last night when I ever so smartly cut the tip of my finger. Now I can't play until the skin grows back. Oh, well.
But before that, I was practicing my major scales. I now finally understand the Circle of Fifths/Fourths. Basically, starting with C, you can move clockwise to determine the number of sharps or counterclockwise for the number of flats you'll have in the major scale. Moving clockwise, you determine the next note by the fifth of the previous note. So, from C, you get D (2), E (3), F (4), G (5). The scale of G has one sharp in it. Which note is sharp, then, you ask?
Well, the scale always takes the form of whole, whole, half, whole, whole, whole, half intervals. On the C scale, which has neither flats or sharps, this is: C D EF G A BC. See? C >> D >> E > F >> G >> A >> B > C, where >> is a whole interval and > is a half interval.
Let's do the same with G: G >> A >> B > C >> D >> E >> F# > G. Two wholes, one half, three wholes, one half. Since E to F is normally a semitone, we have to use F# instead to make a full interval. Thus G has one sharp, and that sharp is F#.
Similarly, going backwards in fourths from C, the next note in the circle (going counter clockwise is F: C (1), D (2), E (3), F (4). F has one flat in it: F >> G >> A > Bb >> C >> D >> E > F. Normally, B to C is a semitone. But to get from A to "B?" (where ? is either normal, flat or sharp), you must use a half interval, which is the note of A#/Bb. Since you have already used up the letter A in the scale alphabet, it is more clean to use Bb.
An additional point to not forget is that the circle progresses forward based on the the previous note. So in the above examples, the next note to consider from F is Bb (the fourth note) and from G is D (the fifth note) and that each progression adds an additional flat or sharp.
Here's an interesting tidbit: in musical notation, you can tell which key you are in by the number of sharps or flats that are drawn next to the clef symbol. Of course, you have to know which notes will be flat or sharp, but I haven't figured out how to easily memorize all of that yet. I just understand the patterns.
But before that, I was practicing my major scales. I now finally understand the Circle of Fifths/Fourths. Basically, starting with C, you can move clockwise to determine the number of sharps or counterclockwise for the number of flats you'll have in the major scale. Moving clockwise, you determine the next note by the fifth of the previous note. So, from C, you get D (2), E (3), F (4), G (5). The scale of G has one sharp in it. Which note is sharp, then, you ask?
Well, the scale always takes the form of whole, whole, half, whole, whole, whole, half intervals. On the C scale, which has neither flats or sharps, this is: C D EF G A BC. See? C >> D >> E > F >> G >> A >> B > C, where >> is a whole interval and > is a half interval.
Let's do the same with G: G >> A >> B > C >> D >> E >> F# > G. Two wholes, one half, three wholes, one half. Since E to F is normally a semitone, we have to use F# instead to make a full interval. Thus G has one sharp, and that sharp is F#.
Similarly, going backwards in fourths from C, the next note in the circle (going counter clockwise is F: C (1), D (2), E (3), F (4). F has one flat in it: F >> G >> A > Bb >> C >> D >> E > F. Normally, B to C is a semitone. But to get from A to "B?" (where ? is either normal, flat or sharp), you must use a half interval, which is the note of A#/Bb. Since you have already used up the letter A in the scale alphabet, it is more clean to use Bb.
An additional point to not forget is that the circle progresses forward based on the the previous note. So in the above examples, the next note to consider from F is Bb (the fourth note) and from G is D (the fifth note) and that each progression adds an additional flat or sharp.
Here's an interesting tidbit: in musical notation, you can tell which key you are in by the number of sharps or flats that are drawn next to the clef symbol. Of course, you have to know which notes will be flat or sharp, but I haven't figured out how to easily memorize all of that yet. I just understand the patterns.
Monday, January 19, 2009
On Musical Triads
I'm teaching myself guitar. Today, reading "The New Complete Guitarist," I got to the part on scales and chord theory. I already know how to play basic open and barre chords, but I feel I need to learn the details before I can advance my skills. Not unlike how I learn how to program. I very much expect this to change as I learn more, but here is what I am starting with.
1st: Major scales have a "root" note. C is the typical main scale (due to characteristics to be described later) and so its root is of course: C.
2nd: Intervals on the major scale occur between the notes. This gives us either a "tone" or a "major second" such as C to D or a "semitone" or a "minor second" such as E to F. The concept of a "second" refers to the ordinal position relative to the base note being references (C and E in the above examples).
3rd: Interval jumps (second, third, fourth, etc) on the C major scale are organized thusly:
5th: The concept of the "dominant seventh" describes the addition of the seventh interval, though I am not sure why. "Dominant" refers to the fifth chord on the major scale.
1st: Major scales have a "root" note. C is the typical main scale (due to characteristics to be described later) and so its root is of course: C.
2nd: Intervals on the major scale occur between the notes. This gives us either a "tone" or a "major second" such as C to D or a "semitone" or a "minor second" such as E to F. The concept of a "second" refers to the ordinal position relative to the base note being references (C and E in the above examples).
3rd: Interval jumps (second, third, fourth, etc) on the C major scale are organized thusly:
- A single tone jump is a "major second"
- A single semitone jump is a "minor second"
- A double (three notes total, including the base note) jump that is entirely made of tone is a "major third." If there is a semitone in it, it is called a "minor third."
- With four tones or semitones, it is called a "perfect fourth."
- With five tones or semitones, it is called a "perfect fifth."
- For six and seven tones or semitones, it is called a "major sixth" and "major seventh" respectively.
- A: A BC D EF G A
- B: BC D EF G A B
- C: C D EF G A B
- D: D EF G A BC D
- E: EF G A BC D E
- F: F G A BC D EF
- G: G A BC D EF G
5th: The concept of the "dominant seventh" describes the addition of the seventh interval, though I am not sure why. "Dominant" refers to the fifth chord on the major scale.
Sunday, January 18, 2009
Loathing of Emacs
I try to stay out of the editor wars; I'm a firm believer in the adage that you should pick a text editor for programming and stick with it. Learn it as best you can (and as it suits your needs) and use it everywhere. But a couple of recent experiences have caused me to really loathe Emacs. Okay, not really Emacs itself, since I know so little about it, but I really dislike the Emacs' "force it on you" attitude I've encountered recently.
First issue was in my attempt to gently learn Common Lisp. The book I was reading insisted on using Emacs... for the basic reason it allegedly helps in tracking parentheses. No. Don't write a book (or a programming language) on the assumption that a newbie will have to learn not only the new language, but also an entirely new (and non-intuitive) text editor.
Second issue was reading a book that used Oz (via Mozart) as its primary source for programming examples. Not a problem, so long as you teach me a little about the language. I even d/l the interpreter for my Mac OS. When I launched it, it insisted that I have Aquamacs installed. What? Why? And why that particular version of Emacs? I already have Emacs on my Mac to begin with! I don't want another one. So, I install Aquamacs and run it (independent of Mozart). Fine, now I see what it looks like. But how the hell do I exit? Why does't Cmd-Q work? Why is Aquamacs insistent on not letting me shoot myself in the foot and letting my Mac handle the quit routine? C-x C-c didn't work either. I had to force quit my way out of Aquamacs.
Anyway, the whole past couple of events have been really frustrating. I know how hard Vim is to learn, but I never, ever had a problem killing the app in a GUI environment, nor has any language book insist that I use it for that particular langauge. I also know I don't know Emacs itself at all, but why are there people out there so gung-ho on it that I can't possibly use an alternative? My hope in reading these books was to learn a new language or two, not struggle with installing software. So, I'm off to learn some other programming techniques instead. Maybe one day I'll come back to those books, after I've sufficiently learned Emacs on my own terms.
First issue was in my attempt to gently learn Common Lisp. The book I was reading insisted on using Emacs... for the basic reason it allegedly helps in tracking parentheses. No. Don't write a book (or a programming language) on the assumption that a newbie will have to learn not only the new language, but also an entirely new (and non-intuitive) text editor.
Second issue was reading a book that used Oz (via Mozart) as its primary source for programming examples. Not a problem, so long as you teach me a little about the language. I even d/l the interpreter for my Mac OS. When I launched it, it insisted that I have Aquamacs installed. What? Why? And why that particular version of Emacs? I already have Emacs on my Mac to begin with! I don't want another one. So, I install Aquamacs and run it (independent of Mozart). Fine, now I see what it looks like. But how the hell do I exit? Why does't Cmd-Q work? Why is Aquamacs insistent on not letting me shoot myself in the foot and letting my Mac handle the quit routine? C-x C-c didn't work either. I had to force quit my way out of Aquamacs.
Anyway, the whole past couple of events have been really frustrating. I know how hard Vim is to learn, but I never, ever had a problem killing the app in a GUI environment, nor has any language book insist that I use it for that particular langauge. I also know I don't know Emacs itself at all, but why are there people out there so gung-ho on it that I can't possibly use an alternative? My hope in reading these books was to learn a new language or two, not struggle with installing software. So, I'm off to learn some other programming techniques instead. Maybe one day I'll come back to those books, after I've sufficiently learned Emacs on my own terms.
Subscribe to:
Comments (Atom)