「入門 Redmine」を Amazon で注文しちゃった。
Redmine は Ruby on Rails で書かれたバグ管理システム (Bug Tracking System / Issue Tracking System)。同種のソフトウェアに Trac がある。
今まで、ぼくは Trac を使っていたのだけど、Trac は複数リポジトリーに対応していない。バージョン管理システムに Subversion を使ってるうちはまだ良かったのだけど、最近 git (というか repo) に手を出すやうになって、どうにも Trac ではプロジェクト管理が出来なくなって来た。Redmine は複数リポジトリーにも対応しているし、Git も OK という話を聞いたので注文した次第。といふわけで、このブログにも Redmine ネタが多くなるかもしれない。
iPhone で「Wi-Fi をオン」にすると、GPS が受かるまでの時間と精度が上がる。この時、どこかの Wi-Fi に接続する必要はない。Wi-Fi 未接続でも全然 OK。
先日、銀座の町で軽く迷子になった。自分がどこにいるかを知りたかった。iPhone のマップ・アプリを立ち上げたら、自位置が捕捉されない。いつまで待っても「この辺り」ってのが分かる程度で、あのピンポイントに「ココ」って教えてくれるところまで集束しない。
ダメ元で Wi-Fi を ON にしたら、少し待った後、あっけなくマップに青い玉が現れた。Wi-Fi を ON にしただけで、どこの Wi-Fi 環境にも繋げていないのに!
試しに Wi-Fi を OFF にしたら、青い玉は消えた。再び「あの辺り」って輪っか表示になった。
結局、「Wi-Fi ON」で目的地まで歩いて行った。
GPS は GPS 衛星の信号を受け取って自分の位置を測定する。この信号の受信に、だいたい 3 分〜 5 分位いかかる。
これでは時間がかかりすぎるので、AGPS (Assisted GPS) という仕組みが使われている。iPhone の説明ページを引用しませう。
iPhoneには、GPSがさらに進化したA-GPS（Assisted GPS）を搭載しています。携帯電話ネットワークから得た情報を使って一番近い人工衛星をすばやく見つけ、現在地の確定をスピードアップします。
この説明の通りなら、3G モードで AGPS が動いているはず。Wi-Fi モードをオンにする必要はない。
実は iPhone は、携帯電話ネットワーク以外からも、GPS を補正する技術を持っている。
iPhoneには、A-GPSのほかにも、iPhoneならではの位置特定テクノロジーが組み込まれています。iPhoneは、GPS衛星、Wi-Fiホットスポット、携帯電話基地局からの信号を使って、最も正確な位置をすばやく割り出します。
Wi-Fi を ON にすると、iPhone は Wi-Fi のホットスポットを探しに行く。で、iPhone はホットスポットの場所情報のデータベースを持っているんでせう。「接続可能なホットスポット一覧」を作ったら、そのデータベースを使って自位置を決定、もしくは GPS 情報の補正に使っているんではないかしらん。
位置検出のスピードと精度を上げたければ、Wi-Fi をオンにすればいい。
デメリットも考えておきませう。Wi-Fi をオンにすると、電力消費が増える。バッテリーの持ちが悪くなる。
自分の位置を知りたいのか、それともバッテリーを持たせたいか。十分吟味しませう。
ちなみに、ぼくはかうしてる。
「GPS のスピードと精度が上がる」んじゃなくて「位置検出のスピードと精度が上がる」という指摘を受けました [Thanks: eggman さん]。文中の記述を修正しました。タイトルは一応そのままに m(_ _)m
Ubuntu Linux に Google Chrome のパッケージが提供されるやうになった。
ぼくの環境 (Ubuntu 8.04 Hardi) では日本語が表示できない (Ubuntu 8.10 Intrepid では日本語表示に成功したとのコメントもあり)。オプション設定画面が開かない、ブックマーク (Ctrl+b) にアクセスできない、等々の不具合もある。でも、英語ページの表示は激速。面白い。
Ubuntu Linux 8.04 でのインストール方法
deb http://ppa.launchpad.net/chromium-daily/ppa/ubuntu hardy main deb-src http://ppa.launchpad.net/chromium-daily/ppa/ubuntu hardy main
$ sudo aptitude install chromium-browser
$ chromium-browser
起動後の画面はこんな感じ。pre-alpha っていう警告。
ぼくのブログを見ると、日本語がバケバケ (日本語表示はどうすればいいのかな?)
C 言語の勉強で Queue (キュー) のプログラムを組んでる友達がいる。
先日、「@aka なら、15 分位いで queue のプログラムを書けるよね?」と振られたので、「15 分は無理だけど 1、2 時間で作れると思う」と返した。それで気付いたんだけど、ぼくは Queue のプログラムを書いたことがない。せっかくなので、ちょっと挑戦してみた。
int 型のデータを enqueue/dequeue するだけのプログラム。とってもシンプル。
大雑把なコードを書くのに 30 分。バグ潰しに 1 時間。ブラッシュアップに 1 時間。
ソースコードは gist で管理している。ライセンスは GPL (ってほどのコードでもないけど)。fork はご自由に。
ソースコードも一応貼っておく。C99 のソースコード。gcc でコンパイルする時は、-std=c99 オプションが要る。
queue.h
#ifndef __QUEUE_H__
#define __QUEUE_H__
typedef struct node_tt
{
struct node_tt* prev;
int n;
} node_t;
typedef struct
{
node_t* head;
node_t* tail;
} queue_t;
queue_t* new_queue(void);
bool enqueue(int n, queue_t* queue);
int dequeue(queue_t* queue);
void del_queue(queue_t* queue);
#endif /* __QUEUE_H__ */
queue.c
#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>
#include "queue.h"
/* ---------------------------------------- *\
Function declaration
\* ---------------------------------------- */
static bool is_empty(queue_t* q);
/* ---------------------------------------- *\
Functions
\* ---------------------------------------- */
queue_t* new_queue(void)
{
queue_t* q = (queue_t*)malloc(sizeof(queue_t));
if (q == NULL){
fprintf(stderr, "Allocation Error: queue\n");
return NULL;
}
q->tail = NULL;
q->head = q->tail;
return q;
}
/* Return TRUE if succeeded to malloc NEW node, else return FALSE. */
bool enqueue(int n, queue_t* queue)
{
node_t* new = (node_t*)malloc(sizeof(node_t));
if (new == NULL){
fprintf(stderr, "Allocation Error: node\n");
return false;
}
new->n = n;
new->prev = NULL;
if (is_empty(queue)){
queue->tail = new;
} else {
queue->head->prev = new;
}
queue->head = new;
return true;
}
/* Return 0 if queue is empty, else return dequeued value */
int dequeue(queue_t* queue)
{
node_t* last = queue->tail;
if (is_empty(queue)){
fprintf(stderr, "QUEUE is empty\n");
return 0;
} else {
queue->tail = last->prev;
}
int n = last->n;
free(last);
return n;
}
void del_queue(queue_t* queue)
{
if (!is_empty(queue)){
node_t* last = queue->tail;
queue->tail = last->prev;
free(last);
}
free(queue);
}
static bool is_empty(queue_t* q)
{
return q->tail == NULL;
}
#ifdef DEBUG
/* ---------------------------------------- */
int main(void)
{
queue_t* q = new_queue();
enqueue(5, q);
enqueue(4, q);
enqueue(3, q);
printf("%d\n", dequeue(q));
printf("%d\n", dequeue(q));
printf("%d\n", dequeue(q));
// queue is empty
// dequeue error check when queue is empty
printf("%d\n", dequeue(q));
enqueue(2, q);
printf("%d\n", dequeue(q));
// queue is empty
del_queue(q);
return 0;
}
#endif /* DEBUG */
オンライン・ストレージ・サービスの openomy がサービスを終了する。
サービス終了のアナウンスは、2009-03-14 に出た。サービスが終了するのは 2009-03-24。この 10 日のうちに、openomy に保存したファイルを各自ダウンロードするやうに、とおふれが出ている。
サービス終了の理由は何だらう。
This is obviously a bittersweet post for me to write, but we are moving on to new things and it's the right time to do so. (中略) but that time has come to an end.
(訳) こんなことを書くのは辛い (bittersweet) ことだけど、(openomy 以外の) 新しいことを始めようと思う。今がその時だと思う。(openomy) を終わらせる時が来てしまった。
競合ひしめきあうオンライン・ストレージ・サービスから撤退して、何か別のことを始めたがっているやうに見える。
思い返せば、openomy と出会ったのは 2005 年の 12 月だった。
2005 年当時、オンライン・ストレージというと数十 MB しか保存できないサービスがかった。そんな中、1 GB のストレージ容量を持つサービスが、現れたのが 2005 年末だった。Openomy も、そんな波の中で生まれたサービスの一つだった。
Openomy は、タグでファイルを管理するという手法を取る、非常にシンプルなサービスだった。
面白かったのは、Linux を早くからサポートしていた点 (2006/02 時点でサポート済)。これは、ウェブ・ブラウザーで対応しているという意味じゃなくて、ファイラーから普通にアクセスできるようになっていた。
ギークで尖ったサービスだったけど、個人ベースの開発ってのが大変だったのかもしれない。少し残念な結果になってしまった。
開発者の Ian Sefferman さんはお疲れ様。次に期待してるよー。
2009-03-18 午前 2 時、iPhone OS 3.0 の発表が行なわれた。
まずは、最近の現状。iPhone が 1,370 万台売れたとか、iPod Touch が 1,700 万台売れたとか。おめでとう。その後、アプリ開発者向けに 3.0 API の説明と API を使ったアプリの紹介、最後にユーザー向け新機能の紹介だった。
大きな新機能は 5 つ。
有料アプリの中で、更に追加機能を販売できるようになる。例えば、パズル・ゲームで 1〜10 面は最初から付けといて、20 〜 30 面にはもう 100 円。30 〜 40 面はもう 100 円という風な価格設定ができるやうになる。
この仕組みを使うと、RPG ゲームで有料アイテムを配布したり、有料コンテンツを配信したり、オンライン雑誌を毎月 150 円で売るとかも出来るやうになるのかな?
ちなみに、アプリ内での販売機能はフリー・アプリでは使えない。ユーザーとしては、「無料アプリと思ってたら、主要機能は追加購入しないといけなかった」なんて騙しを心配しなくていいので、この配慮は嬉しい。
同じアプリ同士での通信が可能になる。同じアプリを動かしてる人を、自動で Bluetooth で探してくれもする。
これは、将棋ゲームとかの対戦ゲームを簡単に作れるってことなのかな。
iPhone のドック・コネクターに接続した機器を、アプリから制御できるやうになる。
例えば、外部スピーカーの音量をコントロールするとか、FM ラジオ・アンテナから FM ラジオを聞けるやうにするとか。やろうと思えば、iPhone 対応万歩計とか体重計とか、温度計とか気圧計とか作れるってことなんでせう。これは、アクセサリーを作ってるメーカーさんには朗報かも。
iPhone は「地図」として Google Maps を使ってる。この Google Maps を、アプリの中に組み込めるようになる。
今まで iPhone で「地図」を使ったアプリは、いくつかあった。例えば、Y! 地図とか、いつもナビとか、楽天トラベルとか、食べログとか。でも、こういったアプリは地図を自前で用意していた。お金のある企業が作ってるアプリだからこそ、出来ることでせう。
地図を用意するなんて、一般の開発者には出来ない。今回の機能拡張で、誰でも手軽に地図アプリを作れるやうになる。
Push 通知は、外部サーバーを使って実現される。アプリ開発者は、まずサーバーを用意する。サーバーから Apple Push Notificiation Service に通知を送ると、その通知が iPhone に送られるという仕組み。通知の受け取り口を一つに絞ってしまうことで、iPhone バッテリー消費を少なくするんでせう。
この仕組みを使うと、一種のバックグラウンド処理が出来る。バックグランウドで行なうべき処理を、iPhone アプリで行なうんじゃなくて、外部サーバーでやってしまうといふことね。
なので、おそらく音楽をバックグラウンドで流す、という処理は出来ないと思う。
コピー & ペーストが出来るやうになる。例えばコピーのやり方はこんな感じ。
iPhone を振ると Undo できるらしい。すごい!
その他の新機能は以下の通り。
開発者向けベータは、今日公開。iPhone OS 3.0 が一般ユーザーに公開されるのは、今年の夏! iPhone 3G ユーザーには、全員無償配布。iPod Touch には $9.95 (千円) で、アップデートを提供。
夏が待ち遠しい!!
今日 (2009-03-16 Mon)、NHK BS が twitter を取り上げる。
最近、twitter がニュース・ソースとして注目を集めている。手軽に書き込めるので、速報性の高い。重要なニュース・ソースは複数から書き込みがあるので、誤報が淘汰され易い。そういった所が、注目を集める要因でせう。今回の NHK BS の話にしても、取材依頼を受けた kengo さんが tweet (Twitter に投稿すること) して、Twitter ユーザーの関心を買った。ぼくにとって、正に Twitter が情報のソースだった。
取材依頼の詳しい流れは、観測気球さんが丁寧にまとめていらっしゃる。
Twitter ユーザーの人は是非、是非。
そして、テレビのほうも是非、是非。
番組名は NHK BS の「きょうの世界」。時間は 23 時台。10:50〜11:40 の間で放映されるらしい。
ちなみに、うちは BS が入らないので見れない。グゥ。
PS. よければ Twitter / at_aka を Follow して下さい。
昨日、修理に出していた CD プレーヤー CEC CD3300R が戻って来た。おかえりっ。二週間ぶり!
どうやら、CEC のサポート・センターでは音跳び症状が再現しなかったらしい。それでも、ドライブ・メカは交換してくれたとのこと。戻って来た CEC CD3300R で問題のディスクを聞いても、確かに音跳びしなくなっていた。CEC さん、ありがとう。
あと、原因についての所見もついていた。CD ディスクに原因があるのでは? とのこと。HF 値やジッター値の測定データが付いていて、普通の CD の半分位いの値だったと書かれていた (ちゃんと調べてくれたんだねぇ。ありがとうございます!)。
音跳びのしたカラヤンのオペラ・セットは CD (コンパクト・ディスク) のロゴ・マークが付いていない。EMI の公式盤のはずなのに。安い CD を出してくれることはありがたいけれど、最低限の品質保証は欲しいと思った。
CEC の CD プレーヤーの修理中、友達が Denon の CD プレーヤーをぼくに貸してくれた。ぼくの持ってる CD プレーヤーの 2 倍位いする CD プレーヤーをね。目論見としては、CD プレーヤーが戻って来て両者の音の差を味わえば、愕然として「更に上の CD プレーヤー」を買いたくなるはず、ということらしい。
修理から戻って来た CEC CD3300R は、確かに Denon の CD プレーヤーより、音の明解さが足りない。いろいろと心動くものもある。
けれども、ぼくは踏み留まった。
踏み留まれなかったのは友人の方で、TEAC の CD プレーヤーを中古で買っていた。ミイラ取りがミイラになってるよ!。
昨日、Git 本を予約しちゃったのに続いて、Mercurial の本も注文しちゃった。Git も Mercurial も最近、はやりのバージョン管理ソフトね。
「入門 Mercurial」は、CVS も Subversion も触ったことがない人にも分かるように書かれている。なので、バージョン管理の説明も懇切丁寧。ソースコードを過去に戻せる「タイムマシン」のようなもの、と説明している。その解説は間違っていないのだけど、git や bzr に慣れ親しんでいて subversion などとっくに卒業している身には、少々くどい。Mercurial は、それなりに Geek なツールなので、もう少し対象を Geek に見積もってもよいのではないかと思った。
全体的に「入門」の名にふさわしい内容。初めて Mercurial を触ってみる人。分散型バージョン管理をいじってみたい人に十分な内容だと思う。ssh の解説が多いのも良かった (ssh は別 PC にリモート・リポジトリーがある時に使う)。
付録あたりに、Emacs や Trac との連携が入っていたら、と思うのは望み過ぎかな。。。
最近、バージョン管理ソフトの git が楽しくてしょうがない。で、日本語の解説本がないかと探しているんだけど見つからない。
カッとなったんで、Amazon で洋書を注文しちゃった。O'Reilly から出る「Version Control With Git: Powerful Tools and Techniques for Collaborative Software Development」という本。発売は 2009/05 (2 か月後かな?)。定価は 3,564 円。中身も見ずに予約しちゃったけど、O'Reilly だし外れはないよね?
Google Reader に、「共有記事」専用のコメント機能が付いた。この機能を使うと、Google Reader で「共有設定した記事」ごとにオフライン・チャットのようなものが出来るやうになる。
コメントの追加方法は簡単。Google Reader でコメントしたい記事に出会ったら、記事下段の「Share」をクリック (キーボード・ショートカットは S)。すると、「Add comment」というリンクが記事の一番下に現れる。そのリンクをクリックして、コメントを書くだけ。
今のところ、この機能を使って書き込んだコメントが見られるのは Google Reader で「友達」指定した人達だけ。逆に言えば、「友達」指定した人達が書き込んだコメントを見ることが出来る。そこからコンバセーションが生まれることを、Google Reader の開発陣は期待しているんでせう。
友達のコメントを見るには、サイドバーから「Friends' shared items」を開き、「Comment view」をクリックする。
この新機能、「Share with note」とどう区別するの? Comment view でリスト表示は出来ないの? いろいろ突っ込みどころがあるけれど、ぼくは期待してる。「共有」を軸に「友達」と繋がるってのが楽しそう。
あと、iPhone からもコメントを書けるのがいいな。
Git で archive を作るの続き。Git でアーカイブを作るのはいいけれど、特定のファイルだけアーカイブに含めたくない (exclude 処理)。こんな時は、tar をフィルターとして使えばいい。
例えば、README.OBSOLETE をアーカイブから削除する場合はかうする。
git archive HEAD | tar --delete README.OBSOLETE | gzip > foo.tar.gz
「一回アーカイブ作って、tmp ディレクトリーに展開して、要らないファイルを削除して、もう一回アーカイブを作り直して、tmp ディレクトリーを削除する」なんて手順よりも、こっちの方がスマートでせう。
Trac の SCM に Subversion を使ってる人の多くは、Subversion のコミット・ログを Trac のチケット・コメントに自動反映させる hook を利用していることと思う。
これを、Git でも使えるようにしてみた。
まず Trac で Git を使うようにするには、GitPlugin for Trac をインストールする必要がある。ここら辺のウェブ・ページを参考にしてインストールされたし。
Git 用の hook スクリプトを github で公開している。まずは、そちらで最新版を入手されたし。
$ git clone git://github.com/ataka/trac-git-post-receive-hook.git
一応、(2009-03-11 現在の) ソース・コードのコピーも置いておく。
#!/bin/sh
# The original script is available at
# http://trac-hacks.org/browser/timingandestimationplugin/branches/trac0.11/scripts/git-post-receive
#
#
# An example hook script for the post-receive event
#
# This script is run after receive-pack has accepted a pack and the
# repository has been updated. It is passed arguments in through stdin
# in the form
# <oldrev> <newrev> <refname>
# For example:
# aa453216d1b3e49e7f6f98441fa56946ddcd6a20 68f7abf4e6f922807889f52bc043ecd31b79f814 refs/heads/master
#
# see contrib/hooks/ for an sample, or uncomment the next line (on debian)
#
TRAC_ENV="/var/trac/YOURPROJECT"
POST_COMMIT="/usr/local/src/Trac-0.11.1.ja1/contrib/trac-post-commit-hook"
LOG="/dev/null"
echo "in git post commit: $TRAC_ENV" | cat >>$LOG
while read oval nval ref ; do
if expr "$oval" : '0*$' >/dev/null
then
git-rev-list --reverse "$nval"
else
git-rev-list --reverse "$nval" "^$oval"
fi | while read com ; do
echo "posting a comment to trac" | cat >>$LOG
echo " *** $com"
AUTHOR="$(git-rev-list -n 1 $com --pretty=format:%an | sed '1d')" \
MSG="$(git-rev-list -n 1 $com --pretty=medium | sed '1,3d;s:^ ::')"
echo "author ... $AUTHOR"
echo "msg ... $MSG"
sleep 0.1
sudo -u www-data $POST_COMMIT \
-p "$TRAC_ENV" \
-r "$com" \
-u "$AUTHOR" \
-m "$MSG" \
echo "DONE posting a comment to trac" | cat >>$LOG
done
done
echo "Done with trac commit hook: $TRAC_ENV" | cat >>$LOG
exit 0
git-post-receive-hook を手に入れたら、それをリモートの git リポジトリーの hook ディレクトリーに入れてやる。ここでは、リモート・リポジトリーが /git/foo.git にあるとして話を進めませう。
$ chmod +x git-post-receive-hook $ cp -p git-post-receive-hook /git/foo.git/hooks
次に、git-post-receive-hook で Trac の設定を行なう。具体的には、TRAC_ENV に trac project への path を、POST_COMMIT に trac-post-commit-hook への path を指定する。例えば、Trac Project を /trac/foo に置いていて、Trac を Ubuntu のパッケージからインストールしている場合は、次のように編集する。
TRAC_ENV="/trac/foo" POST_COMMIT="/usr/local/src/Trac-0.11.1.ja1/contrib/trac-post-commit-hook"
最後に、/git/foo.git/hooks/post-receive.sample を post-receive に名前を変更して、git-post-receive-hook を呼び出すようにする。
$ cd /git/foo.git/hooks $ cat post-receive.sample #!/bin/sh /git/foo.git/hooks/git-post-receive-hook $ mv post-receive.sample post-receive
post-commit じゃなくて、post-receive を使うことに注意。
設定は以上で終了。あとは、Subversion と同じやうにログが書くだけ。ローカル・リポジトリーからリモート・リポジトリーに git-push したタイミングで、Trac のチケットにログが反映されるようになる。
随分と間が空いてしまったけれど、「Victor のウッドコーン・スピーカー」ブロガー・ミーティングのエントリーの続き。
今回は、ブロガー・ミーティングで聞いたウッドコーン・スピーカーの音について書いてみる。
と、その前に、ぼく以外にもブロガー・ミーティングの感想エントリーを書いている人達がいるので少し紹介しませう。ブロガー記事の一覧は livedoor ニュースにある (何故 livedoor ニュース?)。
「Reason to be cheerful, part 2」の yasuyuki さんは、体験型ブロガー・イベントなのに体験 (音を聞く) 時間が少なかったことを取り上げてらっしゃる。
こういう体験型のミーティングで、前座となるべき「会社の由来」とかをダラダラと話させるのは、ホントどうかと思う。まずは体験させろよと。
確かに。おっしゃる通り。ブロガー・ミーティングの構成は難しいと感じた。Victor を知らない人には良い説明だったと思うんだけど、ウッドコーン・スピーカーに興味があった人にはつまらなかったことでせう。
「ブロガー」というネット・リテラシーの高い人間を呼んでるんだから、「このウェブページに、会社の説明がマンガで載ってます」って予め知らせておくとか出来たんじゃないか、と今さらながらに思う。
木のスピーカーがイイ！って言うわりに (中略) 比較の対象が無い。せめて自社製の他の木じゃないスピーカーを持って来て同じCDを再生して比べさせて欲しい。
比較対象がないと分からない、というのもその通り。部屋の環境も違う、アクセサリーも違う、CD も違う、では (例えば) 自宅のオーディオと比べても本当に良いのか分からないよねぇ。
ウッドコーン・スピーカーそのものについては、好評価が多い。ムジログさんは、オーディオ・マニアではないと断りつつも、次のように書いてらっしゃる。
特に音で「解像度」という表現もされていましたが、音の輪郭のみならず、ひとつひとつの音がきちんとひとつひとつの音として忠実に鳴っている、という印象を受けました。
Kite's Field の kite さんは、ウッドコーン・スピーカーのセットを買ってしまわれたらしい。
「みたいもん」のいしたにさんは、オーディオに詳しいらしく、会場でも一番マニアックな質問をなさっていた。マイ CD を持って来てかけていたのは、ぼくといしたにさんだけだったのではないか? (グールドのゴルトベルグ変奏曲をかけてらっしゃった)。
そんないしたにさんが、定価 79,800 円の EX-AR3 に下した評価は、
私は事前にあまり情報を入れていかなかったので、会場で音を聞いて「これは15万ぐらいはする製品だな」と思っていたぐらいです。
まあ、他人の感想はこれ位いにして、自分の感想を書きませう。
イベント当日。会場入りすると、奥にオーディオ・システムが見えた。
スピーカーはスピーカー・スタンドの上に、更にスタンドはコンクリート・ブロックの上にのっている。スピーカー同士は離れて置かれていて、壁と距離 (後ろと横) も十分に取られていた。スピーカーの周りには、吸音のためにかマットのようなものが点在している。CD レシーバーはスピーカーの床にオーディオ・ボードを敷いて置かれていた。天井の高さは、一般家庭では望むべくもない高さだった。
ビクターは、本気でオーディオのセッティングをして来ているな、と感じた。
ウッドコーンの音を聞いて、まず思ったのは。
「部屋良すぎ!」(ごめんなさい)
冗談じゃなくて、本当にね。部屋がいいと思った。これがスタジオの音なのか、と感動した。変な反射音はないし、こもったりする感じもない。音の響きがすごくいい。
そういう意味では、ブロガー・ミーティングで聞いたウッドコーン・スピーカーの音は多少、下駄をはかせた音だったと思う。部屋はいいし、オーディオ・セッティングも力を入れているんだから。
せめて、セッティングについては一言位い言っても良かったんじゃないかと思う。
「家に帰ったら、スピーカーの間隔を空けてみて下さい。それだけでも音が良くなりますよ。出来れば、スピーカーの間には何も置かないようにして下さい。置く場合は、今みたいに床に置くとかで。それから、スピーカーと周りの壁との距離も余裕があれば 1 m 以上離してみて下さい。スピーカーは、スピーカー・スタンドがあれば言うことなしですが、なければ安定するものの上に置いてみて下さい。これで随分音が良くなります。それで、このイベントで聞いた音を思い出してみて下さい。それでもウッドコーン・スピーカーの方が良いと思います」
こんなことを言って欲しかったなぁ。
EX-AR3 の音は良かった。
音場は広く、スピーカーの外側にも楽器があるように感じた。小さなスピーカーなので、ちょっとびっくり。
特に目を引くのが、定位の良さと解像度の高さ。楽器がどこにあるのか分かるし、音と音との分離していて聞き取り易い。ラジカセなんかだと、ごちゃっとしてたはずの音が、明確に描き分けられていた。
一方で、「木のスピーカー」というふれこみほどには、「木」の響きの乗った音ではなかったのが意外だった。むしろ「木の響き」はほとんど感じられず、音の細やかさが前面に出てくるスピーカーだった。
小さなスピーカーらしく、スピード感とアタック感もあった。ウッド・スティックや三味線の弾く音なんか、とてもキビキビしてて、聞いてて気持ち良かった。さすがに、重低音は表現しきれてなかったけどね。
全体的には、モニター系の音だった。一番似ていると感じたのは Soulnote。sc 1.0 + sa 1.0 + sm 2.0 のセット (計 45 万円位い) を、解像度とか定位とか楽器のリアリティーを下げて、5 万円位いでまとめたら、こんな感じになる気がする。友達にかう言ったら、それは誉めてるの? 貶してるの? と聞かれたけれど、褒めてるだよ!?
最後にもう一度書いておく。EX-AR3 の音は良かった。
最近、タンブラーにティーパックを入れてお茶を作るようになった。
220 円で 20 パック。一日 2 パック使ったとして、10 日持つ。一日 20 円ちょっとの計算。とっても経済的
もう、毎日ペットボトルに 178 円もつぎ込んでた時代には戻れない。
そんなティーパックも、一箱使い切って、切れてしまった。先週は帰りが遅かったし、近所のコンビニは改装中で休業。
仕方ないので、Amazon で注文してみた。Amazon Prime に入会しているので、配送代は気にしない。忙しい時はネットが便利 :)
銀座にあるオーディオ・ショップ「SoundCreate (サウンドクリエイト)」に行って来た。
Soundcreate は、特に Linn の製品に力を入れていることで有名なオーディオ・ショップ。Linn は、英国王室御用達を取っているイギリスのオーディオ・メーカー。
Linn の取り扱い店は、そんなに多くない。ぼくが聞いたのは、インターナショナル・オーディオ・ショー東京の中でだった。で、その時の音が全然面白くなかった。「これが英国王室御用達? 上品だけど面白くない。」んで、すぐに他のブースに移ってしまった。隣のブースでかかっていたタンノイ (こちらも英国のスピーカー) の方が、よっぽど楽しかった。
でも、最近、短慮を改めるようになって来た。オーディオ・ショーって、人が多いし、セッティングも詰め切れてなかったりする。つまり、オーディオがベストな状態で鳴ってるわけじゃない。
「あれが Linn の実力なわけがない!」
そんな想いで、雑誌でよく「Linn に力を入れれているオーディオ・ショップ」として取り上げられているサウンドクリエイトにお邪魔したというわけ。
Linn は、アナログ LP プレーヤーで売り出したオーディオ・メーカー。なので、サウンドクリエイトでは LP プレーヤーの試聴が出来る。むしろ、下手するとサウンドクリエイトでは CD プレーヤーがないんじゃないかと思っていたけれど、そんなことはなかった (ホッ)。
サウンドクリエイトには 3 つの試聴室がある。目的が Linn の試聴だったので、その旨伝えると一つの部屋に通された。CD プレーヤーからアンプ、スピーカーまでを Linn で固めたシステムは一つしかなかった。話を聞くと、日々、オーディオ・システムを入れ替えているのだという。「Linn のお店」というイメージがあるけれど、「Linn しか聞けない」というわけではないみたい。ちなみに、他の部屋では NuForce のアンプもあったし、Sonus faber のガルネリ・メメント (スピーカー) もあった。
さて、問題の Linn の音。
全体のバランスが良かった。その中でも特に低域の表現力が高かった。ドンってバスドラが叩かれると、空気が震えるのを感じた。コントラバスがブォンって弓で弾かれてるのが分かった。オーディオ・ショーで聞いたのとは、段違いの音だった。
とても満足に、Linn の音を味わえた :)