Git bash shortcut on Windows

Download the portable version of Git (it can be x64), and create a shortcut to run Git bash on Windows with this command line to run on “target”:

C:\Windows\SysWOW64\cmd.exe /c ""C:\Program Files (x86)\git\bin\sh.exe" --login -i"

Start in: root directory of sources.

Lágrima, F. Tárrega

Here I share another sheet music from my personal classical guitar collection, a simple and famous piece, Lágrima by Francisco Tárrega (1852—1909). I typed this myself, with my own fingerings and tab, using Sibelius 6.2.

Bourrée, BWV 996, J. S. Bach

I’m sharing this sheet music from my personal collection, the famous Bourrée in E minor by J. S. Bach (1685—1750), for classical guitar. I typed this myself, with my own fingerings and tab, using Sibelius 6.2.

The new Google Maps sucks

A couple months ago, Google began introducing a beta version of the new Maps, which at the time, I promptly refused to use, given the sluggishness and missing features it had. The feature I missed most was the screen split between Street View at the bottom half and the map itself at the top half, where I could drag the Pegman on the map, while the Street View is automatically updated. Oh and the old version is faster. So much faster.

Some time after, this horrible interface became the default, but we still could choose to use the old one. But now Google – possibly because the avalanche of bad feedbacks – rolled out a Lite version of the new Maps, which is basically the same terrible interface, but with even less features. Great solution, eh?

Fortunately, it’s still possible to go back to the old version of Maps via maps.google.com/lochp, at least until Google disables it too. Seriously, what would they swap such a great solution with a crappy one?

Gibson Les Paul weight-relieving chart

I’ve see a lot of information regarding Gibson Les Paul models weight-relieving, but never a condensed, concise chart about all the variations. So, based on all information I could gather, mostly from here and here, I compiled the chart below.

Year	Standard	Traditional
up to mid 1982	solid	N/A
mid 1982 to late 2006	9 holes
late 2006 to 2011	chambered	9 holes
2012 and beyond	modern

Follow the given links to see images of what each weight-relieving technique look like.

Ibanez Jem & Universe fretwire

I’ve seen a lot of wrong information about this, so I’ll just leave this here for further reference.

Regarding fretwire, the Ibanez Jem 7VWH uses Warmoth 6105 frets, not Dunlop 6105. That’s why you find “W/6105” on the specs.

The Ibanez Universe – all models, as far as I know, including the Jem 7V7 –, listed as having jumbo frets on the specs, have Dunlop 6140.

Actual measurements:

• Warmoth 6105 – h .047", w .096" (7VWH);
• Dunlop 6105 – h .055", w .090";
• Dunlop 6140 – h .039", w .106" (UVs).

Sony Vegas 13 sucks

I’m a long time Sony Vegas fan. My history with Sony goodies dates back to Acid Pro 3, when was still developed by Sonic Foundry, which had created a very intuitive interface and workflow. Sony bought Sonic Foundry and started migrating all the programs to .Net Framework crap, and quality began to suffer.

Sony Vegas was still usable up to version 12. Not exactly fast, but pretty usable. Testing out this version 13 – build 373 is the lastest at the moment I write this post –, I’m deeply disgusted to what they have done. Without any noticeable improvement, the interface has got a bit uglier, and everything, absolutely everything is slower. I dislike laptops, I have a desktop computer with quite powerful hardware components, and even though, the timeline elements became sluggish when reacting to the mouse, the video preview rendering is blurred and skipping frames, and any cross-fading is simply not viewable due to slowness. Among other oddities.

After some hours of headache, I simply removed this version and reinstalled the version 12 back. What a relief. No more Vegas 13 over here. I hope Vegas 14 can have more luck – although I doubt it.

Music Man JP comparison chart

After his solid Ibanez JPM, it seems that John Petrucci doesn’t know what he wants, so he changes the specs of his signature guitar each year. There are way too many versions so far, and no single place where you can find all the specs together, so I compiled a comprehensive chart of all John Petrucci models with Ernie Ball Music Man.

Note: this chart doesn’t include the dozens of limited series that have been released, just the standard specs.

Year	Model	Body	Neck	Fingerboard	Bridge PU	Neck PU	F radius	Frets
2000	JP6	Basswood	Birdseye maple	Rosewood	Custom, based on Evolution (ref)	Custom, based on Air Norton	15" 381mm	High wide h .047", w .104" h 1.19, w 2.64mm
2005					D-Sonic
2007	JP6 BFR	Alder, maple top, mahogany block	Mahogany	Rosewood or ebony
2008	JP6	Basswood	Birdseye maple	Rosewood	Crunch Lab	LiquiFire
	JP6 BFR	Alder, maple top, mahogany block	Mahogany	Rosewood or ebony
	JP6 BFR Baritone
2010	JPX	Chambered alder, maple top, mahogany block		Ebony				Jumbo h .057", w .110" h 1.45, w 2.79mm
2011	JPXI	Alder, maple top, mahogany block					20" 508mm	Medium jumbo h .051", w .108" h 1.30, w 2.74mm
2012	JP12	Basswood, maple top, mahogany block
2013	JP13			Rosewood	Illuminator	Illuminator	17" 432mm
2014	Majesty	Basswood, maple top	Mahogany, neck-thru	Ebony
2015	JP15	African mahogany, maple top	Roasted maple
	Majesty Artisan		Honduran mahogany, neck-thru	Ebony
2016	JP16	Basswood	Roasted maple	Smokey ebony	Sonic Ecstasy	Sonic Ecstasy
2017	Majesty Monarchy	African mahogany, maple top	Honduran mahogany, neck-thru	Ebony
2019					Dreamcatcher	Rainmaker
2021	JP 20th	Honduran mahogany, maple top	Honduran mahogany		Crunch Lab	LiquiFire	15" 381mm	High wide h .047", w .104" h 1.19, w 2.64mm
	Majesty 20th		Honduran mahogany, neck-thru		Dream Catcher	Rainmaker	17" 432mm	Medium jumbo h .051", w .108" h 1.30, w 2.74mm
	Majesty 8	Basswood	Mahogany, neck-thru

Other changes:

• On the first model, the following are optional: piezo, matching headstock, shield fretboard inlays. A “full loaded” specimen has all three.
• Compensated nut was introduced in early 2006.
• The BFR Baritone has a 27.5" scale length.
• Stainless steel frets debuted with the JPXI in January 2011, and later became standard on all JP models ordered since January 2012.
• The rectangular tremolo base plate was introduced in August 2011.
• In 2011 the piezo saddles changed for ones with lower output; because of this, the preamp was changed for one with a higher output to compensate.
• The BFR logos (on the 12th fret) were retired from all models with the release of the JP13, in early 2013.
• The JP12 was the last model to feature a passive circuit for the magnetic pickups, which can work without a battery. The JP13 and all later models feature an active circuit for everything, including the magnetic pickups: without batteries guitar has no sound.
• Around October 2016 the logo at the back of the headstock changed, from “Made in San Luis Obispo California, USA” to “Californa heritage, since 1974” with a bear picture.
• The JP16 has a Korean-made Floyd Rose bridge, and no piezo system.
• In 2019, the Majesty eletronics layout was redesigned, with less wiring in the back cavity. The layout of the back controls is different.
• The Majesty 8 has a fixed bridge and it’s 25 to 27" multi-scale.

This chart was last updated in 2024-04-02.

A balanced .008 gauge string set for guitar

Last month I restrung my 2004 Music Man JP6 with a .008 gauge string set, D’Addario EXL130. I started to feel very uncomfortable with the G string, because it has so much more tension than all the others. I even considered trading the JP6 for an Ibanez Jem, which I travelled about 150 km just to test for a couple minutes, and it felt good on my fingers, possibly due to my 8 years playing exclusively a 1996 UV7BK.

Then yesterday I took a different direction and it came to my mind the idea of assembling a balanced string set, thus fixing the problem with the heavy G string. I know that there are commercial balanced sets, but they just alleviate the problem, not fixing it. I found this excellent post on Jemsite, where the guy made a comprehensive chart with all D’Addario sets and tension of each string. The .008 data confirmed what my fingers already knew: the G string is much heavier than it should. Also, the A string is slightly heavier, but I really didn’t felt it that much.

What I can’t really understand is why all the string sets are so unbalanced, and why so few people complain about it.

In order to find the right gauge to balance my .008 set, I found a handy online calculator for string tension, not very intuitive, but accurate. With it, I found the gauge of .013 for the G string, instead of the .015, to balance my .008 set. The B string of an ordinary .010 set – D’Addario EXL110 – is exactly .013, so if I buy such a set I could pick the B string and use it. Also, the D string is a .026 gauge, which could replace my current A of .030, making my set more even.

After replacing these two strings, and loosening the spring claw and the truss rod a bit, my JP6 felt a lot better. Instant gratification. The heaviness of the G is finally gone, the bends are easier, and the slightly loosened A added a very smooth feel to the wound strings. And I love loose strings. Here is the tension chart comparison:

Ordinary (unbalanced) .008 set:

E: .008" [PL] = 10.38 pounds
B: .010" [PL] = 09.10 pounds
G: .015" [PL] = 12.90 pounds
D: .021" [NW] = 12.05 pounds
A: .030" [NW] = 14.05 pounds
E: .040" [NW] = 12.11 pounds

Total tension = 70.59 pounds

My balanced .008 set:

E: .008" [PL] = 10.38 pounds
B: .010" [PL] = 09.10 pounds
G: .013" [PL] = 09.68 pounds
D: .021" [NW] = 12.05 pounds
A: .026" [NW] = 11.23 pounds
E: .040" [NW] = 12.11 pounds

Total tension = 64.55 pounds

And I’m not thinking about the Jem anymore. By now.

Named arguments in C

When experimenting with some C99 features of C, I found a very cool trick to have named parameters, using a feature called designated initializers. The first time I read about designated initializers I must admit I found it to be pretty useless, but as I started testing it out, I ended up finding it very useful, since it can make code a lot more readable. Using it together with variadic macros, it was possible to have a very clean named parameter system.

Straight into the code, this is the technique:

typedef struct { int year; const wchar_t *name; } Foo_args; // parameters
void Foo_func(Foo_args args) {
	int x = args.year + 10; // use the argument
}
#define Foo(...) Foo_func((Foo_args){ __VA_ARGS__ })

And this is how you call the function:

Foo(.year = 2014, .name = L"Rodrigo");

The function calling is clear, and its implementation doesn’t add much noise to the code: I believe the price is payable and the result is worth.

Fixing .htaccess in Apache with Ubuntu 12

I have an ordinary Apache installation on an Ubuntu 12 OS, where the root webserver directory is ordinarily pointing to /var/www. I have many subdirectories within it, and I’d like to have one of these subdirectories using clean URLs, specifically becaused I was testing some RESTful API stuff. However, I’ve struggled a bit to make Apache recognize my .htaccess file.

So, after some minor stress, here it is the quick step-by-step guide of what I did, without further explanations:

sudo vim /etc/apache2/sites-available/default

Within the Directory /var/www directive, change AllowOverride None by AllowOverride All. Then run these two commands:

sudo a2enmod rewrite
sudo service apache2 restart

And all of sudden it started working.

A simple alternative to C++ exceptions

I’ve been doing a lot of C++11 research and coding ultimately, and I’m still upset with the C++ exceptions. When reading the concepts, it seems to be a reasonably good alternative to simply return a boolean, but as you try to stuff it in your code, you begin to feel like manipulating a stressed hedgehog. And it’s very frustrating, since you have to stop thinking about your code – what really matters –, to think about the implications of the code you are writing upon the code itself.

Usually, my needs are really simple, I just need an extended way to report a success or a failure from a function. I never wrote something that really needed to tackle differents kinds of errors: it’s just success, or failure with a reason, which usually popped in an alert message box.

After quitting the exceptions, when trying to solve this problem, my first move was to use an extra string pointer as the last parameter to hold eventual error messages. It goes like this:

bool Func(int p1, int p2, wstring *pErr=nullptr) {
	if(false) {
		if(pErr) *pErr = L"Error message.";
		return false;
	}
	if(pErr) *pErr = L""; // all good
	return true;
}

bool Second(float nn, wstring *pErr=nullptr) {
	if(!Func(42, 1337, pErr)) { // will return error message from inner function
		return false;
	} else if(false) {
		if(pErr) *pErr = L"Another error.";
		return false;
	}
	if(pErr) *pErr = L""; // all good
	return true;
}

{
	wstring err;
	if(!Func(42, 1337, &err))
		scream(err.c_str());
}

There is no problem with this approach, and I used it for quite some time. It is clear, and one would have no doubts about what is going on. It is, however a bit cumbersome to write all those pErr checks. So at some point I started considering something else.

My second approach was to use a standard pair as the return type to the function. Something like this:

pair<bool, wstring> Func() {
	if(false)
		return make_pair(false, L"Error description message.");
	return make_pair(true, L"");
}

{
	pair<bool, wstring> ret = Func();
	if(!ret.first)
		scream(ret.second.c_str());
}

I never really used this. It doesn’t look clear enough, and the declaration of the pair variable, just to hold the return value, doesn’t amuse me.

Then I start thinking about writing a “bool on steroids” class, specifically overloading the operator bool, so there would be no need to declare a variable just to hold the result value of the invoked function. This is the class:

#include <string>

class Failed {
public:
	Failed(bool allGood)                   : _hasFailed(!allGood) { }
	explicit Failed(std::wstring reason)   : _hasFailed(true), _reason(reason) { }
	explicit Failed(const wchar_t *reason) : _hasFailed(true), _reason(reason) { }
	virtual ~Failed()                      { }
	operator bool() const         { return _hasFailed; }
	const wchar_t* reason() const { return _reason.c_str(); }
private:
	bool _hasFailed;
	std::wstring _reason;
};

And this is the usage:

Failed Func() {
	if(false)
		return Failed(L"This function failed.");
	return true;
}

Failed Second() {
	if(Failed f = Func()) { // if Func() returned false
		return f; // return from inner function
	} else if(false) {
		return Failed(L"Another error message.");
	}
	return true;
}

{
	if(Failed f = Second())
		scream(f.reason());
}

This approach looks a lot elegant to me. It’s clean, allows the chaining of error messages, and it even allows the inheriting of the Failed class to add more specific error data – although I never really needed this.

The only thing which makes me uncomfortable with this class is the _hasFailed member, which holds a reversed boolean value of the object meaning: if there’s a success, it’s false; if there’s a failure, it’s true. I implemented it this way so that I could use a declaration of the class within an if statement, with no need to declare a variable just to hold the result, as I did on the previous example when I returned a standard pair. Also, it explains why I chose the name “Failed” instead of something like “BigBool”: to explicit the idea of a failure being handled by the if.

Other than that, I consider it a neat approach, and that’s the best solution I could come up with so far.