The 'fix' is easy enough though: pipe /bin/false through mdadm by default so it'll get a 'false' every time it would be looking for user input; effectively making it bail out whenever something's off:
alias mdadm="/bin/false | /sbin/mdadm"
18 December 2013
On bypassing mdadm's interactive mode
So I wanted mdadm to not go interactive, ever, but instead just bail out whenever something happens it doesn't understand; you'd think the developers would have thought of that, right? Turns out they haven't.
The 'fix' is easy enough though: pipe /bin/false through mdadm by default so it'll get a 'false' every time it would be looking for user input; effectively making it bail out whenever something's off:
The 'fix' is easy enough though: pipe /bin/false through mdadm by default so it'll get a 'false' every time it would be looking for user input; effectively making it bail out whenever something's off:
04 December 2013
On quickly creating sparse and large files
I've been using dd(1) for as long as I can remember to create sparse files but for some reason I keep forgetting how to use dd's argument options so I set out to find something better... and found it: truncate(1):
From the man page: "Shrink or extend the size of each FILE to the specified size. A FILE argument that does not exist is created." -looking good:
So then I set out to find me something to quickly allocate 'real' files:
fallocate(1):
"fallocate is used to preallocate blocks to a file. For filesystems which support the fallocate system call, this is done quickly by allocating blocks and marking them as uninitialized, requiring no IO to the data blocks. This is much faster than creating a file by filling it with zeros."
And it truly is fast:
From the man page: "Shrink or extend the size of each FILE to the specified size. A FILE argument that does not exist is created." -looking good:
root@debian64:~# time truncate -s 10T testfile
real0m0.003s
user0m0.000s
sys 0m0.004s
root@debian64:~# ls -l testfile
-rw-r--r-- 1 root root 10995116277760 Dec4 10:27 testfile
root@debian64:~# du -hs testfile
0 testfile
So then I set out to find me something to quickly allocate 'real' files:
fallocate(1):
"fallocate is used to preallocate blocks to a file. For filesystems which support the fallocate system call, this is done quickly by allocating blocks and marking them as uninitialized, requiring no IO to the data blocks. This is much faster than creating a file by filling it with zeros."
And it truly is fast:
root@debian64:~# time fallocate -l 1G testfile
real 0m0.004s
user 0m0.000s
sys 0m0.000s
root@debian64:~# du -hs testfile
1.1G testfile
root@debian64:~# ls -l testfile
-rw-r--r-- 1 root root 1073741824 Dec 4 10:34 testfile
01 October 2013
On OverlayFS and distilling patches (or: how to get OverlayFS)
So, I was looking at unionfs alternatives and I wanted to try overlayfs.
You'd think a project almost begging to be merged into mainline Linux would be interested in getting some traction amongst the "regular" Linux crowd and actually provide some patches making it relatively easy to try out the code until the time finally comes they're part of mainline, right?
Well, apparently you'd be wrong assuming that: getting a clean OverlayFS patch requires distilling a diff from a patched Linux source tree on git and that is left as an exercise to the user... or simply use Ubuntu's or SuSE's kernels (no...fucking...way) as those are already patched it seems.
Anyways, this is how to do it:
Branch overlayfs.v18 is intended to work with Linux 3.10.x:
Lookin' good, w00t!
You'd think a project almost begging to be merged into mainline Linux would be interested in getting some traction amongst the "regular" Linux crowd and actually provide some patches making it relatively easy to try out the code until the time finally comes they're part of mainline, right?
Well, apparently you'd be wrong assuming that: getting a clean OverlayFS patch requires distilling a diff from a patched Linux source tree on git and that is left as an exercise to the user... or simply use Ubuntu's or SuSE's kernels (no...fucking...way) as those are already patched it seems.
Anyways, this is how to do it:
Branch overlayfs.v18 is intended to work with Linux 3.10.x:
https://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.git/tree/Makefile?h=overlayfs.v18
git clone git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git -b overlayfs.v18 overlayfs.v18cd overlayfs.v18
git remote add v3.10-rc7 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
git fetch v3.10-rc7git diff v3.10-rc7/master...HEAD > ../overlayfs-v18.patch
root@bob:/usr/src/linux# patch -p1 --dry-run < ../overlayfs-v18.patch
patching file Documentation/filesystems/Locking
patching file Documentation/filesystems/overlayfs.txt
patching file Documentation/filesystems/vfs.txt
patching file MAINTAINERS
patching file fs/Kconfig
patching file fs/Makefile
patching file fs/ecryptfs/main.c
patching file fs/internal.h
patching file fs/namei.c
patching file fs/namespace.c
patching file fs/open.c
patching file fs/overlayfs/Kconfig
patching file fs/overlayfs/Makefile
patching file fs/overlayfs/copy_up.c
patching file fs/overlayfs/dir.c
patching file fs/overlayfs/inode.c
patching file fs/overlayfs/overlayfs.h
patching file fs/overlayfs/readdir.c
patching file fs/overlayfs/super.c
patching file fs/splice.c
Hunk #1 succeeded at 1313 (offset 1 line).
patching file include/linux/fs.h
patching file include/linux/mount.h
root@bob:/usr/src/linux#Lookin' good, w00t!
31 July 2013
On Linux patches and diffs
So you're running your own customized Linux, and want to stay up-to-date a bit, right?
root@box:/usr/src/linux# patch -p1 --dry-run < ../patch-3.10.4
patching file Documentation/i2c/busses/i2c-piix4
Reversed (or previously applied) patch detected! Assume -R? [n] ^C
So what's happening here is that 'patch-3.10.4' from kernel.org actually is a diff from 3.10 to 3.10.4, not from 3.10.3 to 3.10.4.
This'd be fine except that you've already applied patch-3.10.3 the day before yesterday and you don't want to keep track of which patches are already applied and stuff, you just want to see whether or not the new 3.10.4 patches apply without problems.
Plus you've got other patches applied as well so you really just want to have a patch with the changes form one minor release to the other, right?
So that's where interdiff comes into play:
interdiff patch-3.10.3 patch-3.10.4 > patch-3.10.3-to-3.10.4
Now we have a patch that only includes the changes from 3.10.3 to 3.10.4 and that can be applied directly and cleanly to our already patched-with-the-previous-version-and-other-stuff-as-well Linux tree.
root@box:/usr/src/linux# patch -p1 --dry-run < ../patch-3.10.4
patching file Documentation/i2c/busses/i2c-piix4
Reversed (or previously applied) patch detected! Assume -R? [n] ^C
This'd be fine except that you've already applied patch-3.10.3 the day before yesterday and you don't want to keep track of which patches are already applied and stuff, you just want to see whether or not the new 3.10.4 patches apply without problems.
Plus you've got other patches applied as well so you really just want to have a patch with the changes form one minor release to the other, right?
So that's where interdiff comes into play:
interdiff patch-3.10.3 patch-3.10.4 > patch-3.10.3-to-3.10.4
Now we have a patch that only includes the changes from 3.10.3 to 3.10.4 and that can be applied directly and cleanly to our already patched-with-the-previous-version-and-other-stuff-as-well Linux tree.
On apache's mod_proxy
Another short one, a warning; a 'heads up' if you will.
Took me some time to figure out that Apache's mod_proxy actually requires the proxied service to be accessible when Apache itself starts.
It seems logical enough writing it down now, but when I was configuring mod_proxy to work with apt-cacher it sure wasn't clear looking at the log files.
So when you're playing around with mod_proxy and a random to-be-proxied service, make sure to reload/restart the service first (and verify everything working alright) and only then reload Apache to take the new mod_proxy settings into effect.
07 March 2013
Debugging a slow KDE session.
KDE (from the Kubuntu repo) and all QT applications were slow as hell after an update so I set out to investigate:
The most obvious one to start with was kopete (sloooooooooooooow), so I straced (strace -s 500 -f kopete) and it hung on this:
It's hanging on handler 6, going up in the output I found what 6 is:
Let's try to use dbus to contact kopete manually:
Everything works, more or less, but it's all extremely slow.
Let's have a look at kded:
Seems fishy.
Ubuntu bloatware I can perfectly do without, check.
After a KDM restart everything is back to normal AND that annoying pop up 'there's are X software updates' thing is gone...
The most obvious one to start with was kopete (sloooooooooooooow), so I straced (strace -s 500 -f kopete) and it hung on this:
11574 recvmsg(6, 0x7fffb90ddde0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
11574 sendmsg(6, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\t\0\0\0o\0\0\0\1\1o\0\26\0\0\0/modules/networkstatus\0\0\6\1s\0\f\0\0\0org.kde.kded\0\0\0\0\2\1s\0\37\0\0\0org.kde.Solid.Networking.Client\0\3\1s\0\6\0\0\0status\0\0", 128}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 128
11574 poll([{fd=6, events=POLLIN}], 1, 25000
It's hanging on handler 6, going up in the output I found what 6 is:
11368 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC, 0) = 6
11368 connect(6, {sa_family=AF_FILE, path=@"/tmp/dbus-TNffZVatPK"}, 23) = 0
11368 fcntl(6, F_GETFL) = 0x2 (flags O_RDWR)
11368 fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
11368 geteuid() = 1000
11368 getsockname(6, {sa_family=AF_FILE, NULL}, [2]) = 0
Let's try to use dbus to contact kopete manually:
timothy@xps:~$ time qdbus org.kde.kopete Error: org.freedesktop.DBus.Error.NoReply
Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
real 0m25.018s
user 0m0.004s
sys 0m0.008s
timothy@xps:~$ time qdbus org.kde.kopete
/
/KDebug
/KIO
/KIO/Scheduler
/Kopete
/MainApplication
/ManagerIface_contact
/Statistics
/kopete
/kopete/MainWindow_1
/kopete/MainWindow_1/actions
/kopete/MainWindow_1/actions/settings_prefs
/kopete/MainWindow_1/actions/file_quit
/kopete/MainWindow_1/actions/settings_showmenubar
/kopete/MainWindow_1/actions/settings_showstatusbar
/kopete/MainWindow_1/actions/settings_keys
/kopete/MainWindow_1/actions/options_configure_toolbars
/kopete/MainWindow_1/actions/settings_notifications
/kopete/MainWindow_1/actions/AddGroup
/kopete/MainWindow_1/actions/contactSendMessage
/kopete/MainWindow_1/actions/contactStartChat
/kopete/MainWindow_1/actions/contactMove
/kopete/MainWindow_1/actions/contactCopy
/kopete/MainWindow_1/actions/makeMetaContact
/kopete/MainWindow_1/actions/contactRemove
/kopete/MainWindow_1/actions/contactSendEmail
/kopete/MainWindow_1/actions/contactSendFile
/kopete/MainWindow_1/actions/contactAddContact
/kopete/MainWindow_1/actions/contactAddTemporaryContact
/kopete/MainWindow_1/actions/contactProperties
real 0m3.720s
user 0m0.028s
sys 0m0.004s
Everything works, more or less, but it's all extremely slow.
Let's have a look at kded:
timothy@xps:~$ qdbus org.kde.kded
Error: org.freedesktop.DBus.Error.NoReply Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
timothy@xps:~$ ps aux | grep kded
timothy 10298 0.0 0.3 793672 29280 ? Sl 10:06 0:00 kdeinit4: kded4 [kdeinit]
timothy 10455 0.0 0.1 414756 11236 ? Sl 10:06 0:00 kdeinit4: kio_trash [kdeinit] trash local:/tmp/ksocket-timothy/klauncherT10296.slave-socket local:/tmp/ksocket-timothy/kdeda10298.slave-socket
timothy@xps:~$ gdb kdeinit `pidof kded4`
[... lots of stuff...]
(gdb) bt
#0 0x00007f6aa1952023 in select () at ../sysdeps/unix/syscall-template.S:82
#1 0x00007f6aa2d99366 in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timeval const*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#2 0x00007f6aa2d466da in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#3 0x00007f6aa2d47fab in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4 0x00007f6aa2d0248e in QProcess::waitForFinished(int) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#5 0x00007f6aa31def32 in KProcess::execute(int) () from /usr/lib/libkdecore.so.5
#6 0x00007f6a80f3f1a5 in ?? () from /usr/lib/kde4/kded_notificationhelper.so
#7 0x00007f6a80f3bca5 in ?? () from /usr/lib/kde4/kded_notificationhelper.so
#8 0x00007f6a80f39ad4 in ?? () from /usr/lib/kde4/kded_notificationhelper.so
#9 0x00007f6a80f39d24 in ?? () from /usr/lib/kde4/kded_notificationhelper.so
#10 0x00007f6aa2d86446 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#11 0x00007f6aa20ef894 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#12 0x00007f6aa20f4713 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#13 0x00007f6aa3b063f6 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5
#14 0x00007f6aa2d6ce9c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#15 0x00007f6aa2d70c6a in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#16 0x00007f6aa2d9bf93 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#17 0x00007f6a9ea5fd53 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007f6a9ea600a0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007f6a9ea60164 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007f6aa2d9c3bf in QEventDispatcherGlib::processEvents(QFlags) ()
from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#21 0x00007f6aa2197d5e in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#22 0x00007f6aa2d6bc82 in QEventLoop::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#23 0x00007f6aa2d6bed7 in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#24 0x00007f6aa2d70f67 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#25 0x00007f6a8f4fde55 in kdemain () from /usr/lib/kde4/libkdeinit/libkdeinit4_kded4.so
#26 0x00000000004086a4 in _start ()
timothy@xps:~$ dpkg -l | grep "notification-helper"
ii kubuntu-notification-helper 11.10ubuntu1 Kubuntu system notification helperSeems fishy.
timothy@xps:~$ apt-cache show kubuntu-notification-helper
Package: kubuntu-notification-helper
Priority: optional
Section: kde
Installed-Size: 212
Maintainer: Kubuntu Developers
Original-Maintainer: Jonathan Thomas
Architecture: amd64
Version: 11.10ubuntu1
Depends: libc6 (>= 2.4), libkdecore5 (>= 4:4.4.95), libkdeui5 (>= 4:4.4.0), libqt4-dbus (>= 4:4.5.3), libqtcore4 (>= 4:4.7.0~beta1), libqtgui4 (>= 4:4.5.3), libstdc++6 (>= 4.1.1), konsole | x-terminal-emulator, qapt-batch
Recommends: apport-kde | apport-gtk
Filename: pool/main/k/kubuntu-notification-helper/kubuntu-notification-helper_11.10ubuntu1_amd64.deb
Size: 38114
MD5sum: 0c6b775a0f78cbdb138149ea0e32b60b
SHA1: 2f2c37f9d16a094ac6f215c22c6cb558f6e5eada
SHA256: 8a96a2b822e825d3d56d7dcba732061576b690077bd73ff5ddcfd896192399bf
Description-en: Kubuntu system notification helper
Kubuntu Notification Helper is a daemon that presents various notifications
to the user. It uses the KDE Daemon system as a base and presents the
notifications using the KDE Notification system. It also includes a
System Settings module for configuring the daemon. Kubuntu Notification
Helper is lightweight and fully integrated with KDE.
.
Current features include:
- Notifications for Apport crashes.
- Notifications for upgrade information, when available.
- Notifications for the availability restrictively-licensed packages.
- Notifications for when upgrades require a reboot to complete.
- All notifications can be hidden temporarily or permanently.
Homepage: https://launchpad.net/kubuntu-notification-helper
Description-md5: cfe41fe07651879c49f8ca54be0c1170
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
Supported: 5y
Task: kubuntu-desktop, kubuntu-full, kubuntu-active-desktop, kubuntu-active-full, kubuntu-active, edubuntu-desktop-kde
Ubuntu bloatware I can perfectly do without, check.
timothy@xps:~$ sudo apt-get remove --purge kubuntu-notification-helper
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
kubuntu-notification-helper*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 217 kB disk space will be freed.
Do you want to continue [Y/n]?
(Reading database ... 296995 files and directories currently installed.)
Removing kubuntu-notification-helper ...
After a KDM restart everything is back to normal AND that annoying pop up 'there's are X software updates' thing is gone...
23 January 2013
Fine Tuning an Original Floyd Rose
I'll start off by stating this is a guide for fine tuning a Original Floyd Rose (OFR) bridge, not a generic double locking floating bridge (DLFB) tuning guide, although the ideas and concepts are alike for many Floyd Rose licensed DLFB's.
Floyd Rose is a brand name and an Original Floyd Rose is a type of bridge.
Your Ibanez branded DLFB isn't a Floyd Rose.
Ibanez' are called Edge and were once Licensed Floyd Rose, but not any more.
The original Edge DLFB was very similar to a OFR though.
This isn't a Floyd Rose set-up guide either, that's a bit out of scope at this time.
This is a guide to fine tune your OFR and by that I don't mean on how to use the bridge's fine tuners, I mean tuning it so it stays perfectly in tune no matter the abuse.
Not even Floyd Rose's guide on their website correctly lists a method of making sure the bridge stays in perfect tune at all times for some reason.
Most guides generally have 3 major steps:
1) Tune using the tuners
2) Lock the nut
3) Tune using the fine tuners
They don't speak about what the tuning should be when pulling up or down on the bridge which is, I think, the very essence of an OFR, right?
Should be bridge be in perfect tune after pulling up and letting it return to zero?
Should be bridge be in perfect tune after diving and letting it return to zero?
Well, yes, yes it should be.
The thing is, following most guides it can't be, you'll see why and what's your definition of 'perfect'?
Pefect tuning on an OFR equipped guitar is nearly impossible, I'll explain why later on.
Anyways, I recommend getting a polygraphic tuner.
We'll need to check the entire range of tuning for all strings once we'll get to the fine tuning bit, so getting a graphic representation of the current tuning is extremely handy.
I've got a Hardwire HT-6 polygraphic tuner and fwiw: I recommend it wholeheartedly.
A word of advice when using your polygraphic tuner when tuning though: don't press down on the strings to much when you're sweeping them all at once.
Pressing down too hard makes the other strings go out of tune obviously, so you won't get a correct overview of the tuning. Gently sweep them instead.
First things first:
New strings should be stretched before tuning!
This is so important it's not funny any more.
Neglect to do it and it won't stay in tune, I can guarantee you that much!
Put the new strings on and stretch the hell out of them by pulling up on the whammy bar as much as you can and then take the string with your fingers and stretch it even more.
The better you stretch, the more stable the end tuning result will be.
I see a lot of guides recommending unscrewing the fine tuners completely as a first step, this is wrong.
We'll need to be able to both fine tune up and down, so position them in the middle.
Here's how:
Screw the 6th string's fine tuner all the way in
Screw the 4th string's fine tuner all the way out
Screw the 5th string's fine tuner right in the middle
Screw all fine tuner's on the same level as the 5th string's fine tuner, using your finger as gauge.
Next, unlock the nut and remove the nut blocks and bolts for now, remembering which is which and in what position they were on.
If the OFR was at level, it probably won't be any more now, that's fine.
This happens as, after locking the nut, fine tuning increases string tension right up to the nut; the string's part behind the nut has a different tension.
Removing the nut changes the tension again so the bridge moves a bit.
Now, make sure the Floyd Rose's fine tuners are reset to their middle position.
Then, follow these steps:
A1) Pull the Floyd Rose up and carefully let it come back to it's zero position
A2) Tune to the desired tuning using the regular tuners on the headstock
A3) Pull the Floyd Rose up carefully let it come back to it's zero position
A4) Repeat step A2
(Procedure 'A')
Pulling up ensures there isn't any slack anywhere on the length of the string and it's a very important step on some set ups; don't skip it.
This of course means you can't push down on the bridge at this time!
Now it's time to check the OFR's tilt.
It should be completely at level with the body of the guitar and I don't mean give or take.
Ensure it's completely at level or you won't get it completely in tune in all situations later on.
Most probably it won't be level, so this is how you level it:
Note: you'll need to tune again (steps A1 through A4) after every single spring adjustment at this stage.
Remove the backplate leading to the OFR's springs in the back cavity of the guitar.
You'll see a claw plate holding 2 to 5 springs connected to a big block holding the bridge and the plate is connected to the guitar's body by 2 screws.
First ensure the claw plate should be at level with the body of the guitar!
(So, remember: if you've turned the screws at all, run procedure 'A' again!)
Now the claw is level and we're tuned again, good.
Have a look at the OFR's baseplate:
if it's tilted forward (towards the headstock), you'll need to tighten the crews in the back cavity.
if it's tilted backwards (away from the headstock), you'll need to loosen the crews in the back cavity.
B1) Check the baseplate's level
B2) Determine which way the screws need to be turned (if at all)
B3) Adjust the screws
B4) Tune (procedure 'A')
B5) Repeat from step B1
(Procedure 'B')
The screws should be evenly turned (as the claw needs to be parallel to the cavity) and they're pretty sensitive: a 1/32th turn on both of them can very well cause a 10 degree change in baseplate angle after steps B1 through B5 are performed.
Right, now the baseplate is level for the desired tuning, good.
Next step: locking the nut.
Maybe you've noticed locking the nut messes up the tuning, maybe you haven't, but it does.
So have a look, if locking makes the lower strings go flat and the upper ones go sharp, you'll need to compensate for that a bit by tuning the lower ones a bit flat and the upper ones a bit sharp before locking as we'll want to minimize using the fine tuners afterwards.
Remember: tune by following steps A1 through A4!
Now that the nut's locked, the fun part starts: fine tuning the bridge.
An OFR is a balancing act and not all the strings are pulling equalling hard on the bridge, right?
That's why we're going to adjust the strings in a certain way: from the "hardest pulling" string to the "softest pulling" one (I'm not really sure, in fact, that this is correct to be honest, but it works for fine tuning).
This boils down to this sequence: E/G/A/B/D/e.
So, it's quite easy as long as you follow a couple simple rules:
* Follow the string adjustment sequence
* After adjusting 1 fine tuner, check tuning again (all strings!)
* Only tune up
* If you need to tune a string down, downtune it flat so you can tune up
* Remember the string sequence, adjusting the E string will have a shit load more impact on the other strings than adjusting the e string
So, firstly: we're going to make sure it's fine tuned for the current bridge position:
C1) Check tuning (all strings!) & determine which string need to be adjusted
C2) Fine tune for that string
C3) Repeat C1-C2 as much as needed until all strings are in tune.
(Procedure 'C')
So far, so good.
D1) Pull up on the whammy bar as far as possible
D2) Fine tune (Procedure 'C')
D3) Press down on the whammy bar as much as possible
D4) Fine tune (Procedure 'C')
D5) Repeat D1->D4 as long as tuning isn't perfect when returning the bridge to zero after pulling up/pressing down
(Procedure 'D')
Procedure D can take very, very long and to be honest, you'll come to a point where the difference between what the tuning is when using the whammy bar and perfect tuning isn't perceivable by human ear any more and you'll only know it's off by looking at the tuner.
There's one thing I forgot to mention though: gravity.
It's the law, so we've got to obey it at all times and tuning our OFR isn't an exception.
The position of the guitar and even the whammy bar influences the tuning of the bridge.
Try it: check tuning the the guitar's flat on an even surface, when on a strap, on your lap, whammy loose or locked in different positions... tuning always will be 'a bit' off.
That's why you never should tune the guitar when it's laying flat, there's just too much difference with how you'd normally hold your guitar.
As a small reference: it's pretty easy to get the OFR to, after returning to zero from pulling up or down on the whammy bar, line up perfectly on the HT6 overview display.
The overview is slightly less accurate than the individual string tuning mode, and I can visually confirm it's a wee bit off in individual string tune mode, but I can't hear the difference any more.
At that point I could run procedure 'D' for some time extra, but I usually don't bother.
Floyd Rose is a brand name and an Original Floyd Rose is a type of bridge.
Your Ibanez branded DLFB isn't a Floyd Rose.
Ibanez' are called Edge and were once Licensed Floyd Rose, but not any more.
The original Edge DLFB was very similar to a OFR though.
This isn't a Floyd Rose set-up guide either, that's a bit out of scope at this time.
This is a guide to fine tune your OFR and by that I don't mean on how to use the bridge's fine tuners, I mean tuning it so it stays perfectly in tune no matter the abuse.
Not even Floyd Rose's guide on their website correctly lists a method of making sure the bridge stays in perfect tune at all times for some reason.
Most guides generally have 3 major steps:
1) Tune using the tuners
2) Lock the nut
3) Tune using the fine tuners
They don't speak about what the tuning should be when pulling up or down on the bridge which is, I think, the very essence of an OFR, right?
Should be bridge be in perfect tune after pulling up and letting it return to zero?
Should be bridge be in perfect tune after diving and letting it return to zero?
Well, yes, yes it should be.
The thing is, following most guides it can't be, you'll see why and what's your definition of 'perfect'?
Pefect tuning on an OFR equipped guitar is nearly impossible, I'll explain why later on.
Anyways, I recommend getting a polygraphic tuner.
We'll need to check the entire range of tuning for all strings once we'll get to the fine tuning bit, so getting a graphic representation of the current tuning is extremely handy.
I've got a Hardwire HT-6 polygraphic tuner and fwiw: I recommend it wholeheartedly.
A word of advice when using your polygraphic tuner when tuning though: don't press down on the strings to much when you're sweeping them all at once.
Pressing down too hard makes the other strings go out of tune obviously, so you won't get a correct overview of the tuning. Gently sweep them instead.
First things first:
New strings should be stretched before tuning!
This is so important it's not funny any more.
Neglect to do it and it won't stay in tune, I can guarantee you that much!
Put the new strings on and stretch the hell out of them by pulling up on the whammy bar as much as you can and then take the string with your fingers and stretch it even more.
The better you stretch, the more stable the end tuning result will be.
I see a lot of guides recommending unscrewing the fine tuners completely as a first step, this is wrong.
We'll need to be able to both fine tune up and down, so position them in the middle.
Here's how:
Screw the 6th string's fine tuner all the way in
Screw the 4th string's fine tuner all the way out
Screw the 5th string's fine tuner right in the middle
Screw all fine tuner's on the same level as the 5th string's fine tuner, using your finger as gauge.
If the OFR was at level, it probably won't be any more now, that's fine.
This happens as, after locking the nut, fine tuning increases string tension right up to the nut; the string's part behind the nut has a different tension.
Removing the nut changes the tension again so the bridge moves a bit.
Now, make sure the Floyd Rose's fine tuners are reset to their middle position.
Then, follow these steps:
A1) Pull the Floyd Rose up and carefully let it come back to it's zero position
A2) Tune to the desired tuning using the regular tuners on the headstock
A3) Pull the Floyd Rose up carefully let it come back to it's zero position
A4) Repeat step A2
(Procedure 'A')
Pulling up ensures there isn't any slack anywhere on the length of the string and it's a very important step on some set ups; don't skip it.
This of course means you can't push down on the bridge at this time!
Now it's time to check the OFR's tilt.
It should be completely at level with the body of the guitar and I don't mean give or take.
Ensure it's completely at level or you won't get it completely in tune in all situations later on.
Most probably it won't be level, so this is how you level it:
Note: you'll need to tune again (steps A1 through A4) after every single spring adjustment at this stage.
Remove the backplate leading to the OFR's springs in the back cavity of the guitar.
You'll see a claw plate holding 2 to 5 springs connected to a big block holding the bridge and the plate is connected to the guitar's body by 2 screws.
First ensure the claw plate should be at level with the body of the guitar!
(So, remember: if you've turned the screws at all, run procedure 'A' again!)
Now the claw is level and we're tuned again, good.
Have a look at the OFR's baseplate:
if it's tilted forward (towards the headstock), you'll need to tighten the crews in the back cavity.
if it's tilted backwards (away from the headstock), you'll need to loosen the crews in the back cavity.
B1) Check the baseplate's level
B2) Determine which way the screws need to be turned (if at all)
B3) Adjust the screws
B4) Tune (procedure 'A')
B5) Repeat from step B1
(Procedure 'B')
The screws should be evenly turned (as the claw needs to be parallel to the cavity) and they're pretty sensitive: a 1/32th turn on both of them can very well cause a 10 degree change in baseplate angle after steps B1 through B5 are performed.
Right, now the baseplate is level for the desired tuning, good.
Next step: locking the nut.
Maybe you've noticed locking the nut messes up the tuning, maybe you haven't, but it does.
So have a look, if locking makes the lower strings go flat and the upper ones go sharp, you'll need to compensate for that a bit by tuning the lower ones a bit flat and the upper ones a bit sharp before locking as we'll want to minimize using the fine tuners afterwards.
Remember: tune by following steps A1 through A4!
Now that the nut's locked, the fun part starts: fine tuning the bridge.
An OFR is a balancing act and not all the strings are pulling equalling hard on the bridge, right?
That's why we're going to adjust the strings in a certain way: from the "hardest pulling" string to the "softest pulling" one (I'm not really sure, in fact, that this is correct to be honest, but it works for fine tuning).
This boils down to this sequence: E/G/A/B/D/e.
So, it's quite easy as long as you follow a couple simple rules:
* Follow the string adjustment sequence
* After adjusting 1 fine tuner, check tuning again (all strings!)
* Only tune up
* If you need to tune a string down, downtune it flat so you can tune up
* Remember the string sequence, adjusting the E string will have a shit load more impact on the other strings than adjusting the e string
So, firstly: we're going to make sure it's fine tuned for the current bridge position:
C1) Check tuning (all strings!) & determine which string need to be adjusted
C2) Fine tune for that string
C3) Repeat C1-C2 as much as needed until all strings are in tune.
(Procedure 'C')
So far, so good.
D1) Pull up on the whammy bar as far as possible
D2) Fine tune (Procedure 'C')
D3) Press down on the whammy bar as much as possible
D4) Fine tune (Procedure 'C')
D5) Repeat D1->D4 as long as tuning isn't perfect when returning the bridge to zero after pulling up/pressing down
(Procedure 'D')
Procedure D can take very, very long and to be honest, you'll come to a point where the difference between what the tuning is when using the whammy bar and perfect tuning isn't perceivable by human ear any more and you'll only know it's off by looking at the tuner.
There's one thing I forgot to mention though: gravity.
It's the law, so we've got to obey it at all times and tuning our OFR isn't an exception.
The position of the guitar and even the whammy bar influences the tuning of the bridge.
Try it: check tuning the the guitar's flat on an even surface, when on a strap, on your lap, whammy loose or locked in different positions... tuning always will be 'a bit' off.
That's why you never should tune the guitar when it's laying flat, there's just too much difference with how you'd normally hold your guitar.
As a small reference: it's pretty easy to get the OFR to, after returning to zero from pulling up or down on the whammy bar, line up perfectly on the HT6 overview display.
The overview is slightly less accurate than the individual string tuning mode, and I can visually confirm it's a wee bit off in individual string tune mode, but I can't hear the difference any more.
At that point I could run procedure 'D' for some time extra, but I usually don't bother.
10 January 2013
On waking up computers
Introducing something I've been working on: http://code.google.com/p/wurmd/
I've been running it on my laptop and on my OpenELEC Raspberry Pi for some time now and I quite like it; YMMV.
"Wurmd tries to solve the common problem when using Wake-On-Lan on your server/desktop/fridge/... that once it's asleep it has to be woken up again, which usually is a manual operation the user has to perform. Having the device go to sleep isn't the problem but having to fire up an additional program to wake the device back up can become a PITA after some time.
The logical next step would be to incorporate WoL functionality into programs itself, but that's hardly feasible. Sure, you may get the XBMC crew to write code so if a file share isn't online it'll automagically sends a WoL packet, but that's limited to XBMC, right? What if you want to access your file server at home from your favorite file explorer but it's asleep again?
Wurmd is a standalone program that listens on an interface in the background for initial connections to your configured devices. If it detects such a connection it'll send a WoL packet to the device to wake it up. What this means, practically, is that as long as wurmd is running on the host you can use any program to make a connection with a sleeping device and wurmd will wake it up. Your program probably won't even know what happened.
Binaries are available for both x86_64 and Raspberry Pi's architecture, ARMv6. Packages for various Linux distributions are forthcoming and I might even build an OSX binary."
I guess it's not ready for prime-time yet and there's hardly any error-handling, but it's functional.I've been running it on my laptop and on my OpenELEC Raspberry Pi for some time now and I quite like it; YMMV.
Subscribe to:
Posts (Atom)