さっき、なぜか、ふと、「本宅のCちゃん」(おばさん)は親戚の中では一番好きだったことに気付いた。そして今、おじさんだったら千葉のNおじさんだと気付いた。なぜかは良く分からないが、その二人は(偉そうことや小言や教訓めいたことを言ったりせず)純粋に可愛がってくれたからだろうか。二人とも もう亡くなってしまったが、その数年前に会ったりメールで話せたのは良かった。

おじさんとは また飲みたかったが、もう仕方ない。こうやって、たまに思い出すだけでいい。別に実際に飲まなくても問題ない(逆に、(最後に飲んだ時のように)飲み過ぎたりして大変だw)。

 

(かといって、二人に頻繁に会ったり、「人生の相談」をしていたとか、尊敬していたなどということは全然ない。生前は、「まあ、(親戚なんて)面倒だけど嫌いじゃない」程度だった。それでも、なぜか、おばさんには こっちに戻った時に会う気になった。今考えると どうしてそんな気になったのか自分でも分からないが、やっぱり好きだったんだろう。

そう言えば、(僕は葬式とか法事なんて、もう本人が居ないのだから、単なる儀式で意味がないと思っているにも関わらず、)おじさんが亡くなった最初の法事に行く気になったのも、好きだったからなのだろう。

もし相談なんてしていたら、逆にこういう気持ちにはならない気がする。いや、そんなこともないかも知れないが、僕は相談できるほど信頼できる家族・親戚が居なかったので、分からない。

と、最後に暗くなるのは良くないな。)

 

バランスを取るために余計なことを書くと、「おばさん」と言えば森高の「叔母さん」を連想するけど、全く1μgも共通点はなく、今の僕より若かったであろう頃から ごく普通の田舎のおばさん臭いおばさんだった^^

  •  0
  •  0

先日からJoplinのエディタの代わりに使い始めたMDエディタ、QOwnNotesは なかなか良い。が、前回も書いたけど、完璧ではないので使っていると問題は出て来るので、気になるものからフォーラム(正確には「問題報告ページ」だろうが、ここでは簡単に「フォーラム」と書く)に投稿して対応してもらっている。

その対応がなかなか良くて感心している。言葉はぶっきらぼう簡潔だけど、ちゃんと対応する気が感じられるのがいい。しかも速い。そこら辺は昔やっていたMusicBeeに似た雰囲気で、懐かしい。

(11/4 17:02) が、(忙しいせいか)結構いい加減かつクソ野郎癖の強い人で、なかなかイライラすることがあった。が、他にいいエディタがないので今は使うしかないと、諦めている。その代わり、寄付はしない。

(11/4 18:53) いつもの「坊主憎けりゃ」で、使うどころか画面を見るだけでもイライラするので、QOwnNotesは止めた! 少々物足りないけど、安心感のあるZettlerに戻る(とりあえず今はねw)。

 

そういう問題の中で一番最初に何とかしたかったのは、日本語(Fcitx+Mozc)の未確定入力(pre-edit text)に下線が出ないことだ。落ちるとかでなく表示だけの問題なので、致命的ではないのだが、エディタで文章を書いている時には、どこからが変換対象なのか分からない(候補を良く見ればいいかも知れないが、書くのを邪魔される)のは結構なストレスだ。ただ、普通のアプリは出るのが謎だった。

検索してみると、いくつか情報が出て来た。いいヒントになったのは、LibreOffice(実際にはKDE?)のフォーラムへの報告だった。更に、fcitx-qt5のフォーラムに まさにこの問題が報告されていたのだが、作者の環境では「起こっていない」で未解決(と思われる)のまま閉じられて仕舞っている。

どうやらQt5アプリとFcitxの組み合わせで起こるようだ。実際、いくつかのQt5アプリで試したら ほぼ全滅だった。以下に結果を示す。

  • 下線が出ない。
    • digiKam7, QuiteRSS, QtQR, SMPlayer, VLC, FeatherPad, Calibre, Nextcloud, KeePassXC
  • 下線が不完全に出る。
    • LibreOffice Writer
  • 下線が出る。
    • LibreOffice Calc

確かにdigiKam(7からだったと思う)では下線が出なくて使いにくかったが、この問題のせいだったことが分かった。

それで、これはQOwnNotesの問題ではないのだが、fcitx-qt5の作者は問題が起こって居ないスタンスで解決の見込みがないので、QOwnNotesもLibreOfficeと同様な対応をしてもらえないか聞いてみたが、さすがに無理だった。(出て来ないが、「無理強い」の今の言葉だw ← 「無茶振り」だw)

その時はQt5の問題と思ったが、実際には、Fcitx(fcitx-qt5)の問題のようだ。ただ、Qt5がfcitx-qt5に下線を描くように指定していないせいだとしたら、Qt5の問題だ。この辺りは分からない。

そこで、「ちょっと何とか」できないかと思ってQOwnNotesのソースを見たが、上のLibreOfficeのパッチを適用するところに相当する部分はなく、未確定入力に関しては何も処理していない(確定した文字列を受け取って処理しているだけ?)と想像した。そこでfcitx-qt5のソースを見たら、(無理やり)下線を出す方法が分かった気がしたので やってみたら、たった1行の修正(削除)だけで見事に出た!

この変更は、本来 文字列に指定された(そういうことがあるのか?)スタイルに関係なく、無理やり下線を出しているので どこかで問題が起きそうだが、2時間くらい使った範囲では大丈夫だ。

ただ、他のQt5でないアプリでは下線は破線でなく実線なのが気になった。少しソースを検討したら、本来はデフォルトで実線の下線を描くつもりのようで、指定されたら破線にしているようだ。それがなぜか、実線の下線すら描いていない。Fcitxの設定があるのか調べたが、なかった。

そこで、とりあえず、破線の下線(DashUnderline)の指定がない場合(デフォルト)は実線の下線(SingleUnderline)を描くように修正した。参考までに、以下に修正したソースの関連部分を載せる。変更箇所は"Default to draw underline."辺りである(行頭の":"は省略した部分)。

platforminputcontext/qfcitxplatforminputcontext.cpp:

void QFcitxPlatformInputContext::updateFormattedPreedit(
 const FcitxFormattedPreeditList &preeditList, int cursorPos) {
:
    if (preedit.format() & TextFormatFlag_Underline) {
        format.setUnderlineStyle(QTextCharFormat::DashUnderline);
    } else { // Default to draw underline.: Butty: 2021/11/3
        format.setUnderlineStyle(QTextCharFormat::SingleUnderline);
    }
:
    update(Qt::ImCursorRectangle);
}

※上のソースコードのオリジナル部の著作権は、オリジナルファイルの先頭に記載のとおり。

 

妙なのは、これが全然問題になっていないことで、ひょっとすると僕とか特定の環境だけで起こり、世の中の多く(実は少ないのか?)の方は普通に使えているのかも知れない。であるので、本来は こういう修正は作者に連絡してオリジナルに入れてもらうべきだが、上記のように作者が「起こってない」スタンスということもあって保留した。

(11/4 12:19) その後、別件で「まっさら」かつ僕のとは別な環境(KDE neon)で試したところ、やっぱり問題は起こったので、少なくとも僕だけの問題ではないようだ。ただ、Ubuntu系だけかも知れないし、そもそも作者が上記のとおりなので、報告は保留する。

 

もし、この投稿を読まれて「自分のところでも起こっている」という方が多いなら、オリジナルに入れてもらうようにします。そういう方は、コメントを書いて下さるか、「いいね!」か「そうね!」を押して下さい。

あと、「とりあえず、自分も直したい」という方がいらっしゃたら、もう少し詳しいやり方(と言っても、ビルドの方法、ビルド時にエラーが出た時の対処、インストール方法程度)を書きます。ただ、上の記述で分からない方ですと、理解して頂けるように書けるか不安です。

 

とりあえず、また一つ問題が解決して、(しかも、QOwnNotes以外もザクっと直って)気分がいい。そして、QOwnNotesは(気になることは他にも もう少しあるけど、)さらにサクサク書けるようになった^^

 

PS. 僕の「ちょっと何とか」は、大体ちょっとどころじゃ済まないが、今回は大丈夫だったwww でも、忘れた頃にトラブる可能性はある。

  • QOwnNotes

    QOwnNotes

    Open source markdown note-taking for Linux, macOS …

  •  0
  •  0

結構前に書こうと思ったけど、良く確認してから投稿しようと思い、その後全く問題が起こっていないので確かそうだ。

僕のPCとルータの相性なのかも知れないが、スリープからの復帰後にNWが使えなくなる問題があった。一番最初に使っていたバッファローのルータ(WHR-G301N)では起こらなかったが、次のバッファローの新しいもの(WSR-300HP)では起こったので、ルータの仕様が悪いのかと思って使うのを止めた。

その後、IPv6(IPoE)対応にするためにI/Oデータのルータ(WN-SX300GR)に換えたら また起こったので、これも駄目かと思った。

なので、バッファローには濡れ衣を着せてしまった。申し訳ない。

バッファローの旧と新(I/Oデータも)の違いはGigabit Ethernet対応かどうかなので、その辺りと僕のPCの相性なのかも知れない。

が、通信速度の低下を少しでも減らすためにIPv6は使いたいので、「何とか」した。想像だったのだが、PCのスリープからの復帰をルータが ちゃんと認識していないのが原因ではと思った。それで、ルータのポートからPCのケーブルを「抜き挿し」するのを擬似(電気)的に実現しようと、スリープからの復帰時にNW-IFを一旦落としてから上げるようにした。

少し詳しく書くと、nmcliというコマンドで、(connectionでなく)deviceレベルでNW-IFの機能を停めて(down)から起動(up)させた。

とりあえず問題は解決したので、少し前まで使っていた。ただ、ちゃんとした対処でないし、復帰時に一旦NWが切れるのでちょっと気分が悪かった。IPv6のネゴシエーションは遅いようで、少し(数十秒)時間が掛かるのが嫌だった。

それが、先日のQuad9のDNSサーバが遅い問題に対処した時にNWを いろいろいじっていたら、NW-IFを落とさなくても済む方法、つまり、「ちゃんとした」対処方法が分かった。

まず、スリープからの復帰後にNWが使えなくなる問題の直接の原因は、復帰後に(PC(Linux)の)DNSサーバの情報がなくなってしまう※ためだ。そのため、IPレベル(例: IPアドレス直打ち)ではちゃんと通信できるものの、ホスト名で外部にアクセスしようとしてもIPアドレスが分からないために通信できなくなっていた。

※その原因は分からない。いつもながら不勉強で、この辺りは分からないことが多い。

それで、スリープに入る前にDNSサーバの情報を保存しておき、復帰時に再設定するようにしたら、万事うまく行った。

めでたしめでたし。

この時に思い付いたもう一つの解決法は、NW-IFを一旦落とすのにnmcliのconnectionを操作するものだ。ただ、スリープからの復帰時にconnectionを有効にするのに時間が掛かるのと、DNSだけでなくルーティング情報も保存する必要があり、また、IPv6の一時アドレスがリセットされるので、今ひとつ好みでないので却下した。

 

でも、他の人は特に困っていないようなのが謎だ。やっぱり、相性みたいなものがあるのか?

  •  1
  •  1

(2021/11/5 4:10) その後いろいろあり、QOwnNotesは作者共々クソだという結論に達し※、使うどころか画面を見るだけでもイライラするのでアンインストールして、とりあえずZettlrに戻った。それで使いにくいことがあれば、何とかすることにした。

※実際に使ったりフォーラムをのぞいてみて、自分で確認されたい。

やっぱり、舌の根は永遠に乾かないようだ。(そもそも、舌の根が乾いた時は死んでいるのではないか?)

であるので、以下のほとんどは「古い情報」である。


先日は、MDの編集は(Joplinじゃなくて)Zettlrが一番いいと思ってそう書いたのだが、そのすぐあとに、「ちょっと待て」的な展開になった。

先日のリストで「最初に何か(MDは不可)開かないと起動しない。」と書いて却下したQOwnNotesは、本当にそんなにしょうもないものかと疑問に思ったのだ。それに、仮に何か開かないと起動しないとしたって、機能が良ければ使えるかも知れないとも思った。

再度試したら、以前(Evernoteを止める時だったか)試した時の設定の痕跡が残っていたために、何か開かないと起動しない状態になっていることが分かった。再設定したら普通に起動した。全く失礼だった。

しかも、再度試す きっかけとなった機能紹介ページにあるように、機能や操作性がちゃんとしていて意外にいい感じだった。それでも、「完璧」とは言えないが、他に全滅なので それだっていいと思って詳しく試した。

Evernoteを止める時に試した時は、MDを使う気がなかったのとスマフォ版がないので却下したように思うが、今は状況が違って充分候補になる。

結果は、結構な当たりだった。Zettlrに完勝している訳ではないが、良い点はZettlrより多く、悪い点はZettlrより少なかった。(→ 付録を参照)

一番いいのは、ごく当たり前の話ではあるが、sym-linkに対応していることだ。これで、前回苦労して作ったけど なんか煩雑で嫌いな、MDが変更されるたびにJoplinにコピーし続ける処理が不要になる(と思った)。

一方で、Zettlrにない欠点もある。QOwnNotesはリソース(画像)の格納先にはノートのトップディレクトリの"media"というディレクトリだけしか指定できないのだ。それ以外の指定では概ね画像は出ない(フルパスとかを書けば可能らしいが、僕の用途には向かない)。

かたや、Joplinはノートを外部編集に出す時には画像ファイルをノートのトップディレクトリの"resources"に入れるので、そのままではQOwnNotesで画像が出ない。ひどいことに どちらも強情で、設定でディレクトリを変えられるようにはなっていない。

改造した時(後述)に分かったが、QOwnNotesは意外にディレクトリ名をハードコードしていて、それが何箇所にもあった。機能などの出来がいい割には雑なところがあって、どこの人かは分からないがUS的な雰囲気を感じた。

そのせいか、フォーラムでの問い合わせに作者は「変更はできない」と平然と書いていて(参照不明)、なかなか「ん?」だった。

一方、Joplinはディレクトリ名を定数にしていたので、こういうところは抜かりないものだと感心したものの、変更できないようにする考えが理解できなかった。まあ、変えると全部のノートに影響してシステムが崩壊してしまいかねないのは分かるから、仕方ない。

それで、仕方なく「何とか」しようと思った。これはZettlrの時に比べれば簡単で(とその時は思った)、Joplinの出すノート(作業用ノート)中の画像指定タグ中の画像のディレクトリ("resources")を"media"に置換してQOwnNotesに出せばいい。

なお、画像ファイル本体はresourcesにあるので、resourcesをmediaにsym-linkしておく。

早速実装しようとして、気付いた。編集が終わったノートをJoplinに戻す時には、逆に"media"を"resources"に変換しなくてはならないが(そうしないとJoplinで画像が出ない)、それは そんなに簡単なことではない。というのは、いつQOwnNotesで編集を終えるか分からないからだ。※ Zettlrの時同様、Joplinが作業用ノートを削除したことを契機にできるが、削除されたファイルの中身は置換できないので、やっぱり、Zettlrの時同様に、ファイルの変更を監視して逐次Joplinにコピーすることになって、何も簡単ではない。そんなはずではなかったが・・・

※もちろん自分(僕)は分かるので、そういう(手動の)操作を追加すればいいが、必ず忘れるし面倒なので、そういうことは避ける方針だ。これは、PCでUSBメモリを抜く時にアンマウント操作をすべきかどうかの話*に似ている。

*不要という人も多いが、僕はOSの仕組み上、必要だと思う。例えば、OSは、メモリがいつ抜かれるか分からないではないか。それに備えて常に安全策を取っているOSがあるようだが、それは何か違うし、それだって完全に安全ではない。そういうOSでは書き込み中に抜いてもいいのだろうか?

本当に「何もせずに抜いていい」と言うなら、USBの端子に「抜かれつつある状態」を検出する仕組み、または、処理中は抜けないようにロックする仕組みが必要だ。

しかし、一晩頭を冷やして考えて、(他の案もあったものの、)QOwnNotesかJoplinを改造して、QOwnNotesが"resources"を認識するようにするか、Joplinが作業用ノートに"media"で出すようにすれば、万事丸く収まる気がした。

早速QOwnNotesを改造してみたら、うまくできた。ただ、オリジナルのQOwnNotesが更新されるたびに改造し直す必要があるので面倒だ(作者にフィードバックしてオリジナルに入れてもらえばいいが、結構なパワーが要る)。※

QOwnNotesにはスクリプティングという機能(JavaScriptらしい)があり、それを使えば改造しなくても実現できるかもしれないが、なかなかハードルが高いので保留にした。

※と書いたら、さっき更新の通知が来たwww (18:00)

更新のたびに改造するのはJoplinでも同様だが、僕はJoplinに これ以上の改良は期待しておらず、激遅とメモリの馬鹿食いが解消されない限りMDの編集には使わないので、仮に今後更新しなくても大きな問題はないと考え、Joplinも改造してみた。こっちはGUI版とコマンドライン版があって全部は確認できていないが、おそらくうまく行ったと思う。

JoplinはJavaScript(正確にはTypeScript?)で書かれているので、コンパイルが不要なのが楽だった。 (← TypeScriptからJSへのコンパイルは要る。これが長くて面倒・・・) でも、nodeの更新が必要なのに気付かず、ちょっと手こずった。

それから、Joplinにはプラグインの機能があるので、それを作れば改造しなくても実現できるのかも知れないが、QOwnNotesのスクリプティングと同様にハードルが高い。

Joplinは以下のように改造した。

  • ノートを外部編集設定した時
    • 作業用ノート中の画像指定のディレクトリの"resources"を"media"に置換する。
    • それがファイルに書き出される。
      • それがQOwnNotesに読み込まれる。
  • ノートの外部編集設定を解除した時
    • ファイルから読み込んだ作業用ノート(QOwnNotesが更新した(かも知れない)もの)中の画像指定のディレクトリの"media"を"resources"に置換する。
      • そのあとで、何事もなかったようにJoplinの内部パスに変換される。

なお、外部編集設定している間もJoplinはノートが更新されるたびに表示を更新するので、その時は画像が出なくなる。読み込まれるたびに変換すればいいのだろうが、無駄な処理だし面倒なのでやっていない。 (← その後、更新されても ちゃんと画像が出ることが分かった。それが下に書いたように正しい動作で、出なかったのはQOwnNotesの版(改造版かどうか)と合ってなかったからかも知れない。)

良く考えると、読み込まれるたびに上の変換が行われるはずなので、外部編集設定を解除するまでは、少し動作が違うのかも知れない。まあ、それほど大きな問題ではない。

あとは、改造版Joplinを「ちゃんと」使えるようにすればいいのだが、改造したものは「開発版」と出ていて設定なども本物とは別で、その直し方(書いてない・・・)を調べようとするところで力尽きたw

→ JSとTSの違い(あと、昨日はJSを直して居たが、それはTSから生成されるため、危うく消滅するところだった)、その他諸々に戸惑いながらも どうにかできた。改造版Joplin (GUI版)とオリジナル版QOwnNotesで連携できている。

CLI版は謎の動作(中身を表示すると、画像のディレクトリが外部編集と同じディレクトリになっている)だが、オリジナル版と同じなので良しとした。面倒なのでAppImageは作らず、npmやnodeで起動することにした。

npmとnodeとelectronの違いが分からないが、興味ないので放置する。

あとはQOwnNotesでの画像の追加や新規ノート作成に対応などが残って居るが、おいおい やりたい。 (これも疲れそうだ) (11/1 13:33)

 

それから、(これが最初だったのだが)上の処理の他に、QOwnNotesの動作を改善し、使いやすくするための処理をJoplin→QOwnNotesのコネクタに入れた。

  • QOwnNotesはノートのタイトルをファイル名から取るが、Joplinのノートのファイル名はIDなので、ノートを表示させないとタイトルが分からなくて不便。
    • それを解消するため、Joplinが外部編集設定した時に、作業用ノートのタイトル(Joplinでは最初の行に書かれている)を短縮してファイル名に入れるようにした。
    • 重複を防ぐため、元のIDも付けるようにした。
  • QOwnNotesは画像タグのタイトル(またはキャプション)が空だと画像を表示しない。
    • それを解消するため、Joplinが外部編集設定した時に、作業用ノート中にタイトルが空の画像タグを見付けたら、ファイル名をタイトルに入れるようにした。
    • MDでは画像のタイトルを見ることはまずないし、空のものにファイル名を付けるのに特段の問題はなさそうだ。
    • ※ノートから画像を抽出する部分のソースを見ると、タイトルが空でも問題ないはずなのだが そうでないので、別のところで落としているようだ。

 

と、最初は「簡単だ!」と思ったけど実はそうでもなかったという、いつものパターンである。(Joplinの改造を仕上げる件が残って居るものの、)今は、以下のように普通にMD(画像も)が表示でき、快適に編集できている。

QOwnNotesをJoplinの外部エディタにして、ノートを編集できるようにした。

 

最後にもう一回言いたいのは、ZettlrでもQOwnNotesでも どちらもでいいけど、Joplinのエディタを使っていた時のイライラから解放され、まさにサクサクと(それが普通なんだけど)文章が書けるようになって(Joplinも最初はそうだったはずだが、いつの間にか肥大化・肥満化・劣化してしまったようだ・・・)、うれしい限りだ。

 

付録: ZettlrとQOwnNotesの長所と短所

主に相互の比較の観点で書いた。また、基準はJoplinのエディタ(機能としては かなり良いほう)である。なお、太字は僕が重視した(「これはちょっと」、「これはいい」と思った)点である。

Zettlrの長所・短所

  • 長所
    • 他のエディタよりは ちゃんと使える。
    • 全ノートに対する検索ができる。
    • ノートの編集ペーンはプレビュー兼用だけど見やすい。
  • 短所
    • 検索で前候補に行けない。 → その後、Shift+Enterで行けることが分かった。 (11/5 5:53)
    • sym-linkで誤動作する。 → コネクタで対応した。 → 最新版(2.0.2)では直っていそうな感じ。ただし、相変わらずsym-linkのファイルは開けない。 (11/5 5:53)
    • MDのタグの動作が変・変なものに変えてしまう場合がある。例: コードブロック, 横線 → Auto completeを調整すれば大丈夫そうな感じ。 (11/5 5:53)

      • それをコピー・ペーストしても、ちゃんと働かないことがある。補完の影響?
    • ()や"などの補完が余計なことが多いうえにoffにできず、面倒。 → 設定があった(最新版で増えた?)。それ以外もAuto completeを調整すれば大丈夫かも。 (11/5 5:53)
    • 編集中に表示位置がジャンプすることがある(Joplinよりはずっと少ない)。
      • プレビューが別でないので、ジャンプは仕方ない?
      • 表示はジャンプするが、カーソル位置は動かないので まだ良い。 (11/5 5:53)
    • 選択したブロックを箇条書き・番号リストにすることができない。 → 選択して右クリック → "Insert numbered/unordered list"でできる。が、箇条書きは頭の文字が違う(そのうち直る?)。 (11/5 5:53)

      • 番号リストのリナンバーもできない。 (できるものは見たことない)
    • 書式設定の ショートカット・ボタンが少ない。
    • 細かいカスタマイズができない。 → CSSの調整である程度できる? (11/5 5:53)
    • 日時の挿入ができない。 → スニペットで代用できる。(11/5 5:53)
    • 日本語処理が今ひとつ。
    • 左サイドバーの機能が貧弱。
    • Joplinのタグに相当するものがない。
    • Joplinとタイトルの指定方法が異なる。
    • テーマの色の趣味が悪いうえに調整できない。→ CSSで調整できる。 (11/5 5:53)
      • テーマでフォントも決まってしまうので不便。

QOwnNotesの長所・短所

  • 長所
    • 他のエディタより ちゃんと使える。
    • 使用メモリ量が少ない。: Zettlrの約1/4。
      • 例: 4ノートを開いている場合、アイドル時約140MB
        • この少なさは何かの間違いではないかと思って調べ直すのだが、合っている。
    • 編集中に位置がジャンプしない。
      • ただし、プレビューペーンは頻繁にジャンプする(それでも、Joplinと違って ちゃんと戻る)が、エディタは動かない。
    • 全ノートに対する検索ができる。
    • 細かいカスタマイズが結構できる。
      • できないことも結構ある。
    • 日時の挿入ができる。
      • フォーマットが変更できる。
    • ノート一覧が縦なので、ノートが多くなっても見やすい。
    • 高速
      • ノートの切り替え(読み込み)がJoplinよりずっと速い。
    • 文字列を選択してネットで検索できる。
      • これが欲しかった!!
    • Joplinのタグに相当するものがある。
    • ノートの暗号化が可能
      • 実際に使うかは不明。
    • スクリプティング機能がある。
      • 実際に使うかは不明。
    • コネクタでノートを常時コピーしないので、Joplinでの変更が検出できる。
  • 短所
    • 画像の保存ディレクトリとタグのディレクトリが"media"で固定。対応が必要。 → Joplinを改造し、外部編集時のディレクトリを"media"にして対応した。 (11/3 13:36)
      • 本文に記載のとおり。
    • 選択したブロックを箇条書き・番号リストにすることができない。 ← スクリプトでできることが分かった。すごい。 (11/2 6:21)
      • → スクリプト"List maker"でできる。 (11/2 6:21)
      • 番号リストのリナンバーもできない。 (できるものは見たことない)
        • → スクリプト"Fix list numbers"でできる。 (11/2 6:21)
    • 書式設定のボタンが少ない。
    • MDの解釈・実装のJoplinとの差
      • 画像タグのタイトル([])が空だと表示されない。 → コネクタで対応した。: 修正する(ファイル名を付ける)ようにした。
      • HTML要素(例: "<s>")をコードブロックに入れても無効化できない。 → &xxx;を使うしかない? なぜか、今試したら問題ない。他のアプリとの混同や勘違いだった? (11/2 8:44)

        • あとで問題になりそうではある。
      • 画像タグの前に空行がないと、プレビューがおかしくなる。
        • 画像の前に縦の空白が入る。
      • 単一の改行は無視されて繋がってしまう。空行を入れないと、期待する結果にならない。
        • MD本来の動作なので、仕方ない。
        • こいういうのが嫌で却下したMDエディタがあったが、QOwnNotesは それを補うほどのメリットがある。
        • ただ、それと違うのは、勝手にノートを変更(「修正」)しないことだ。これは重要だ。
    • 検索結果のハイライトが消せない。 → 対処してもらって解決した。 (11/3 13:36) → が、実際には、どうしようもない場当たり的な修正だったし、作者自身が作ったものの仕様を覚えてなくて、こっちが混乱させられたり(そもそも、ハイライトが消えないのが仕様だったのを、僕に指摘されて場当たり的に消したものだから、整合性が取れなくなった)と、クソさが露呈し、それで使うのを止めた。 (11/5 20:40)

      • 検索文字列を消せばハイライトも消えるが、位置がリセットされてしまう。
    • 日本語処理が今ひとつ。
      • 直接関係ないが、日本語入力(Fcitx+Mozc)の未確定入力の下線が出ないのがちょっと辛い・・・ Fcitx側で調整できるのだろうか? → いろいろ調べたところ、Qt5の問題のようだ。ほとんどのアプリで下線が出ない。 (11/1 17:01) → QOwnNotesの問題ではなく、fcitx-qt5の問題だった。自分で対処した。 (11/3 13:36)
        • ただ、LibreOffice CalcとImpressでは出るのが謎。使い方があるのだろうか?
    • 画像がある場合、プレビューの縦の余白が広過ぎることがある。
      • 画像タグの書き方によるようで、次を空行にすれば直ることが分かった。
    • ノートにタイトルが指定できない。: ファイル名で見るしかない。 → コネクタで対応した。: ファイル名にタイトルを付けるようにした。
    • プレビューペーンが最後まで見えない(ことがある)。
      • コードブロックの開きと閉じの対応(インデント)が悪かったためだった。
    • 書式付き文字をコピーして、他のアプリでペーストすると、書式の文字列も貼り付けられてしまうことがある。: 再現せず。
      • 別のアプリ(ReText)だったか?
  • QOwnNotes

    QOwnNotes

    Open source markdown note-taking for Linux, macOS …

  • Overview

    Overview

    Open source markdown note taking for Linux, macOS …

  •  0
  •  0

Joplin(特にエディタ)がクソで使い物にならなくなったので※、他を探してみたのだが(試したものを付録に書いた)、結局、Zettlrしか残らなかった。エディタの機能ではJoplinは足りているのだが、遅かったり表示がジャンプしたりと邪魔されて普通に文章が書けないという点で、使うことができない。

※想像して欲しい。1文字打つ・消すたびに5秒くらい待たされるので、記憶と予想で新しいカーソル位置を想定して作業する苦しさを。30年前のviだって、そんなことはなかったよ。もちろん、何か大きなことをすると(いつ起こるかは不明)いきなりカーソルが行方不明になって、文章を書くレベルじゃねえ!

前回候補に挙がったTriliumは、(いろいろな問題はあるけど一番大きいのは、)内部的にMDでない(HTMLのようだ)※せいかJoplinのノートを開くと書式が変わってしまう。Triliumを使うために全部のノートを見て修正するなんてやってられないので、やっぱり使いものにならない。

※どうしてそうしたかは分からないが、推測してみると、MDよりHTMLのほうが 幅広い表現が可能なためかも知れない。が、世の中の標準に合わせずに自分だけの(詳細が不明な)仕様で通そうとしても先は ない。そういう点で、Triliumはセンスが悪い。

更に、PC(Linux)だけの話なら まだいいが、僕はスマフォ(Android)でもノートを共有して開きたい。すると、ノートの同期システムが必要になるのだが、こちらも(僕には)まともなものがなかった(例: ちゃんと同期しない、電池を食う)。また、同期するといっても、常に全部のノートをスマフォに入れておく必要はなく、見たいものだけ適宜ダウンロードすればいいのだが、そういうものは なかなかない。Dropboxは近いのだが、その上のノートをMDエディタで開いた時に画像が開けない問題があった。Dropbox対応のMDエディタなら可能かも知れないが、有料である。※

※高いものではないから、ちゃんと使えるなら買ってもいいけど、買わないと確かめられないので どうにもならない。

すると、PCとサーバとスマフォでノートを同期するという点では、Joplinは必要充分で なかなか良いことに気付いた。

なお、JoplinのAndroidアプリはLinux版と同様に重くて(EvernoteのAndroidアプリと同様) ほとんど編集はできず、表示専用と割り切っている。

そこで考えたのは、いつものように、JoplinとZettlrで「何とかする」ことだ。それぞれの得意な(「使える」)ところを使い、以下のように分業させるのだ。

JoplinとZettlrの分業

  • Joplin
    • (Linuxアプリ) ノートの管理
    • (スマフォアプリ) スマフォでのノートの表示
      • 重いので、編集は元から諦めている。
      • ノートの編集(書き込み)の代わりに、自作のメモ記録システム(BNote)を使っている。
        • 必要なら、そのメモをPCでノートに貼り込む。
    • ノートのサーバとの同期
  • Zettlr
    • ノートの編集

試しに上記の分業システム(のPoCかプロト)を昨日作り、どうにか動くようになった。以下に基本的な動作を示す。

動作

  1. Zettlrで編集したいノートに対して、Joplinで外部エディタでの編集を設定する(ノート名で右クリック → "Edit in external editor")。
    • あらかじめ、Joplinの設定の外部エディタに、JoplinとZettlrを連携させるためのコマンド(「コネクタ」?)を指定しておく。
  2. JoplinとZettlrを連携させるコマンド(zettlr.sh)は以下を実行する。
    1. 編集用にJoplinからエクスポートされたノート(「元ノート」)を作業ディレクトリにコピーする(→ 「作業ノート」)。
      • 元ノート自体をZettlrに指定してもいいのだが、Joplinの他のファイル(設定やログ)が見えるのが嫌だし、それらを誤って変更したり削除してしまうのを防ぐために こうしている。
      • また、下にも書いたが、Zettlrは単にファイル名を指定しても開けない場合があるので、(仕方なく)作業ディレクトリを作ることにした。
      • 更に、Zettlrはsym-linkは開けないようなので、(仕方なく)編集するノートを作業ディレクトリにコピーすることにした。
        • このために かなり面倒になった。。。
        • 調べたら、ワークスペースやノートのあるディレクトリにsym-linkがあると うまく動かないことがあるようで(→ 参照)、実際に この環境でもしばらく使っていたらノートが開けなくなってしまった(なぜか、Zettlrを再起動すると開ける)ので、(仕方なく)作業ディレクトリ直下からsym-linkを排除し、ノート中のリソース(画像)を抽出してJoplinのディレクトリからsym-linkして(サブディレクトリにある分には大丈夫なようだ)表示できるようにした。これで様子を見ることにした。
    2. 作業ノートを指定してZettlrを起動する。
      • あらかじめ、Zettlrに作業ディレクトリをワークスペースとして設定しておく。
        • 設定しないと、Zettlrが起動中に新たにノートを開く時にエラーで開けない場合が多い。
    3. 作業ノートの更新または元ノートが削除されるのを待つ。
      • 作業ノートの更新の場合、少し更新を「ためて」からJoplinのディレクトリにコピーする。
        • ノートを書いている時は頻繁に作業ノートのファイルが更新され、そのたびにコピーするのは無駄だし重そうなのでそうした。
        • 現状は、10回以上更新があったか、10回未満でも約20秒間更新がなかった場合にコピーするようにしている。
      • 元ノートが削除された場合(Joplinで外部エディタでの編集が解除された)、作業ノートを削除して終了する。
        • 作業ノートを元ノートにコピーしていない場合(上記の保留された更新が未反映の場合)には、エラーダイアログを出す。 → あとで手で反映させるなどが必要。
    4. 3に戻る。
  3. ノートの編集を終える時は、Joplinでノートの外部エディタでの編集の設定("Edit in external editor")を解除する。 → 元ノートが削除され、上の「元ノートが削除された場合」が実行される。

使っている時の画面を見ても、単に「2つのMDエディタが動いているだけ」だが、背後では上のような複雑な処理をしている。そのおかげで、Zettlrでノートを変更すると少し経ってJoplinの表示も更新される。

Zettlr(左)でJoplin(右)のノートを編集している様子

 

効果・良かったこと

  • 操作性: Zettlrは高速(というか、当たり前の速さ)だし、MDエディタとしての挙動も概ね一般的(Joplinに近い)なので、書く時にストレスがなさそうだ。
    • 今までのところ、機能不明・不足以外のストレスはない。
      • 他のエディタのようなプレビュー画面はない(印刷プレビューのみ)のだが、それで充分使えるところがZettlrの表示の すごい・うまいところだと思う。やたらに機能を増やさず、着実に進めている印象がいい。
    • 一方、Joplinのエディタは まさに"disturbance/distraction-ful"だ。
  • メモリ量: JoplinもZettlrも同じElectronで動いていると思われるが、Zettlrは随分まとも(というか普通)。
    • 開いているノートの数と使用メモリ量(アイドル時)の比較例
      • Joplin: 1ノート(サイズ: 約40KB): 約1.2GB
      • Zettlr: 5ノート(サイズ: 合計約1MB): 約680MB
    • Joplinはエディタの他にノート管理や同期の機能があるとは言え、メモリを食い過ぎる。多くのノートを開くと、簡単に2GBを超える。
    • Joplinのメモリは減ることがないが、Zettlrは作業状態に応じて ちゃんと減るのが いい(というか、それが普通だ!)。

処理速度もメモリ量も、同じElectronなのにZettlrは ちゃんとしているが、Joplinは全然「なってない」。Zettlrができているので、やればできるはずのことをしていない(Androidアプリも同様にひどい)。作者は、手を広げるよりも、まず こういう基本的なところを詰めるべきだと思う。

惜しいこと

  • ノートを編集するたびにJoplinで外部エディタでの編集を設定するのが面倒。
    • Joplinを終了しなければ設定は維持されるので それほど煩雑ではないが、(可能ならZettlrに組み込まれた)シンプルなメニュー的なものが欲しい。
  • JoplinとZettlrの管理情報(タイトルの設定方法やタグやノートのIDやマークダウンリンクなど)が別々なので煩雑。
    • ノートIDの統合はできないだろうから、Joplinをベースにするしかなく、必要になるたびにJoplinに戻るのが面倒そうだ。
    • 書いていて気付いたが、Zettlrで貼り込んだ画像をJoplinに戻す必要があることを忘れて居た。面倒かも知れない。。。
    • 同様に、新規ノートはZettlrでは作れない(Joplinに入れる機能がない)。: なかなか先が長そうだ・・・
  • Zettlrの編集機能が「もう一声」。
    • 総合的には、試した他よりは ずっといいのだが・・・
      • 書式設定の機能・メニューが少ない。
      • 日本語処理は特にしていないようで、日本語中の英語の単語選択(ほとんど文章全部が選択される)もスペルチェックも誤動作する(ノートのほぼ全体が真っ赤になるw)。
    • このブログ(WordPress)のエディタくらいの機能があれば言うことないが、なかなかうまく行かないものだ。
      • 何度もブログでノートを書くことを考えているのだが、エディタの機能だけで済むものでもなく、なかなかうまく行きそうにないので諦めている。
    • あと、テーマがどれもイマイチ。自分でCSSをいじれるが、もう少し普通の感覚のものを用意して欲しかった。
      • もしかすると、日本(というか、僕?)以外では、用意されたものがごく普通なのかも知れないw が、特に色遣いの趣味が悪い。明る目の緑とかキツい赤とか止めて欲しい・・・
  • "Zettlr"の綴りが いつも分からないw
    • Zettler? Zottler? Zottero? ヒ○ラー? デスラー?などと、最初の"Z"しか分からない。

メモ・残件

  • ファイル更新の検出は、inotifywaitというコマンドを使った。これをモニターモードで動かし、出力されるイベントを読み込んで処理する。
    • ファイルのコピー中などに起こったイベントを落とさないように、モニターモードで動かすことにした。
  • 連続した複数のイベントを保留してまとめる処理は、イベントの読み込み(bashのreadコマンド)にタイムアウトを指定することなどで実現した。
  • 現状では、編集中のノートごとに上のファイル更新の検出処理が起動されてイマイチなので、いつか統合したい。
    • ただ、基本的に待っているだけなので、負荷は高くない。が、無駄にプロセスが多くなって気分が悪い。
  • 上に書いたように、Zettlrで追加した画像や新規ノートをJoplinに入れる処理が必要だが、作るのは容易ではない。対応できるまでは適宜Joplinを併用するしかない。

 

付録: 試して却下したMDエディタ

以下のもの(すべてLinux版)を試したが、どれも僕には今ひとつだった。次点的なものはMark TextとAbricotineとReTextだった。

(書いたあとで再度試して分かったが、)Mark Textはキーの挙動と勝手な修正とメモリ量などを我慢すればZettlrより良さそうで、乗り換えたくなっている。が、更に少し試したら結構バグがあるようだし、ノートを勝手に修正されるのは困るので、保留した。Abricotineはメモリを食うのが惜しい。ReTextは いろいろ惜しい。いったい何を考えているのか分からない。そこを直せばいい感じだ。

  • Remarkable: パッケージ不足でインストール不可だった。
  • ReText: タブキーで箇条書きがインデントしない。
    • プレビューの画像のサイズが大きい(リサイズされない)。
    • ライブプレビューの表示位置がエディタと同期せず、不便。 (← レンダラーにWebkitを使えば同期する。)
    • 改行の解釈・処理が違うようで、改行だけで次に空行がないと、行が繋がってしまう。
    • メモリ量は少なそう。
  • Mark Text: MDを勝手に変更(修正)する。カーソルがノート内にある場合、Page Up/Down, 上下キーの動きがおかしい。
    • MDの箇条書きの子要素の前に余計な空行が入る(MDを勝手に変更する)。
      • その他も勝手にいろいろ(空行や空白など)書き換わる。「正しいMD」に修正してしまうようだ。
    • MDの空行が無視される。入れてもなくなる。
    • 細かいバグが多そう。
      • Ver. 1未満なので仕方ない? (結構時間は経っているが・・・)
    • 日本語対応は一番良い。
    • 雰囲気はZettlrに似ている。
    • メモリ量は多目だが、Joplinよりは少なそう。
  • MindForger: PPAがUbuntu 20.4 LTS(focal)に非対応でインストール不可だった。
  • Abricotine: 開くノート(ウインドウ)の数に応じてメモリがかなり増える。約340MB+200MB/ノート。
    • 複数のノートは別ウインドウ
    • 設定がファイル
    • 表示は綺麗。
    • Zettlrに近い。
    • 古い: 2015年。ただし、GitHubでのリリースは2020年。
  • Notable: ワークスペース型で、ノートのインポートが必要。
  • Haroopad: タブキーで箇条書きがインデントしない。
    • 複数のノートは別ウインドウ
    • なぜか、メニューのフォントが汚い。
    • 雰囲気が、僕が使っているエディタjEditに似ている。
    • メモリ量は少なそう。
    • 寄付の表示が消せない。 (← ボタンを押せば消える)
    • 古い: 2015年。
  • GhostWriter: 複数のノートが同時に開けない。
  • QOwnNotes: 最初に何か(MDは不可)開かないと起動しない。
  • Markdownify: ライブラリが合わないようで、起動しない。
  • Znote: Joplinで作ったMDの画像が表示できない。
  • Apostrophe: Joplinで作ったMDの画像が表示できない。
    • 機能が貧弱
    • Flatpakなので、インストール・起動・アンインストールが面倒
  • StackEditPro: サイトが開けなかった。
  •  1
  •  0

「いつもイライラしてんな?」って言われそうだけど、実際そうなので仕方ないw

Joplin(ノートアプリ)を丁度1年くらい使ったが、近頃は乗り換えたくなって居る。以下に その理由を挙げる。

  • エディタがクソで、書くことに集中できず イライラする。
    • 大きい(といっても、サイズは100KBくらい)ノートの途中に1文字でも書く(置換でも挿入でも)と、ノートの表示位置がジャンプして場所が分からなくなってしまう。しかも、その挙動が不定(ジャンプしないこともあるし、ジャンプする位置も まちまち)。
      • それで何度も、似たようなことが書いてある別の場所に書き込んでしまった。
    • 遅い。: 大きいノートを開くのも編集するのも遅い。必ず数秒は待たされる。
  • メモリを馬鹿食いする。
    • すぐに2GBを超えて(大きいノート複数開いて編集すると すぐに超える)減ることがない。
      • それでPCのメモリを圧迫するので、一日に何度も(Joplinを)再起動している。
  • サポートの姿勢が今一つ。
    • 上のような問題はフォーラムに上がっていて(、それ以前に自分で使っていれば)作者は分かっているはずなのに、「仕方ない」みたいな姿勢で放置して サーバとか新しいことをやっている。
    • 自分のやりたいものだけ直している感じ。

 

それで ちょっと思い立って今朝探してみたら、以下の(以前は見落としていた)候補が見付かった。ただ、どちらも今ひとつだ。

  • Zettlr
    • ノートを共有・同期できない(そういう機能がない)。
      • Dropboxのようなファイル共有の仕組みを使えば共有は可能だが、複数で編集した時に競合する。
        • 例: どちらかの変更が失われてしまう。
      • 僕の使い方では編集するのはPCだけなので大きな問題はないが、ちょっと怖い。
    • スマフォアプリがない。
      • 他のユーザの例を調べると、別なMDのエディタを使っているようだ。
    •  編集(フォーマット)機能が今ひとつ。
      • 例: 取り消し線がない。 ← あった。メニューになかったためサポートしていないタグ(<s>)を試したのと、インポートしたファイルでうまく動いていなかったので誤解した。
        • 標準的なMDに準拠しているためだろうが、実用性に欠けていないか? ユーザーは不満でない??
  • Trilium
    • 作者が正体不明で怪しい。
      • 名前どころか、国すら不明。
        • ドキュメントの言語やGitHubのメンバーを見ると、中国系では?
      • Webページがなく、GitHubだけ。
        • 一方、Zettlrのページは しっかりしている。
    • リリース(2017年頃)から数年経っているのに、まだV1になっていない。
    • 同期できるのはいいけど、オフラインの時にどうなるか不明。
      • サーバが独自なので、インストールが手間。
    • ノートも画像も全部DB(SQLite)に入れるのでは、あとでとんでもないことになる気がする。

今のところはZettlrしかないが、もう少し検討したり探してみたい。

その後、やっぱりJoplinが遅過ぎて使い物にならないので、試しにTriliumに いくつかのノートを移して使おうとしてみたのだが、たった1個で不完全な点(例: インポートするとフォーマットが崩れることがある)が出てきたり、そもそもセキュリティや運用上の不安(全ノートが一つのDBファイルに入っている)があるので止めた。エディタの使い勝手はJoplinより10倍くらいいいのだが、実用性・現実性(?)に欠けるので仕方ない。

一方、しっかり・堅実に作られている印象のZettlr(実際、Triliumでのフォーマット崩れは起こらない)はスマフォでうまく使えないので すぐには移れないが、何とかならないか考えるとともに、他も探したい。 (10/17 11:04)

 

PS. 勘違いした取り消し線の件でZettlrのフォーラムをちょっと見たら、別なソフトだが、MediaElch(メディア管理ソフト)同様にドイツ人らしい真面目なサポート姿勢が垣間見えて、いい感じがした。

PS2. 「Triliumが怪しい」と書いて気付いたが、僕も、以前 正体を明かさずにソフト開発の仕事を始めようとしたが、その点だけでも論外だったのを実感した。

  •  0
  •  0

数日前に、Backblaze B2(以下、B2)中の もう更新しない(であろう)データをGoole Cloud Storage (Archive) (以下、GCS)に移動する設定を追加して、10日くらい前からほぼ「定常運用」をして居る。以下のグラフを見て分かるように、操作数・データ量などや料金は落ち着いている。

保存しているだけで何もしないなら、毎日、保存データ量分の料金(現状は4円)だけが増える。更新チェック(約3回で1円, 1日1回実施している)や追加バックアップ(量と回数による。: 下を参照)をすると、その分が追加される。

今までに分かったことなどを書く。

  • データ移動(B2→GCS)関係
    • バックアップ対象設定の変更で、B2のデータがGCSに移動するか(B2の保存データ量が減るか)? → Yes.: duplicacy check -statusで各リビジョン(履歴)のデータ量が分かり、将来のprune(不要データの削除処理)で減ることが分かった。
    • 一度に大量に(全部)減らすとpruneに時間が掛かるのと、失敗した場合に大変なので2回に分けて減らすことにした。今のB2のデータ量は約270GBで、来月にもう一度、約270GB分を減らす設定をする。
      • 上を合わせるとB2の残りが0になってしまうが、集計の誤差や重複排除の影響があるため、そうはならない。ただ、残りは かなり少なくなるはずである。
  • GCSのコスト関係
    • ストレージだけの料金の見積もり: 1651円(USD 14.8)/年, 138円(USD 1.23)/月
      • データ量を1TBとし、USD 1= 112円とした。
      • 単価: 0.134円(USD 0.0012)/GB・月
    • バックアップ対象ファイルのチェック(更新チェック)の料金の概算: 3回で1円くらい。 → 約10円/月
    • バックアップ(アップロード)の料金: 推定: 約5円/回(ストレージのチェック) + 約1円/GB
    • 定期更新チェック(1回/日)と追加バックアップ分を含めた年間料金・単価の試算
      • 既存1TB, 追加バックアップなし
        • 支払い額: ストレージ: 1651円 + 更新チェック: 120(30/3*12)円= 1771円(USD 15.8)/年
        • 総合単価: 0.144円 (USD 0.00129)/GB・月
      • 既存1TB + 追加100GB/年 (1回で追加)
        • 支払い額: ストレージ: 1813円 + 更新チェック: 120円 + バックアップ: 105(5+100*1)円= 2038円(USD 18.2)/年
        • 総合単価: 0.151円 (USD 0.00135)/GB・月
      • 既存1TB + 追加100GB/年 (10回で追加)
        • 支払い額: ストレージ: 1813円 + 更新チェック: 120円 + バックアップ: 155(5*10+100)円= 2088円(USD 18.6)/年
        • 総合単価: 0.155円 (USD 0.00138)/GB・月
      • 既存1TB + 追加500GB/年 (1回で追加)
        • 支払い額: ストレージ: 2458円 + 更新チェック: 120円 + バックアップ: 505(5+500*1)円= 3083 (USD 27.5)円/年
        • 総合単価: 0.251円 (USD 0.00224)/GB・月
      • 上より、追加料金はバックアップのデータ量が効くので、回数が多過ぎなければ(例: 月に1回以下)小まめにしても良さそうだ。ただ、「100MBを10回」のように細かいものは割に合わない。例えば、1回10GB以上がいいのではないか。
    • 料金はUSD建てのため、実際の支払額は為替相場に影響される。円が大幅に安くなると困るが、さすがに2倍にはならないだろう・・・
      • Googleのレートは毎日変わっている訳ではないので、毎月更新のようだ。
  • 運用関係
    • B2→GCSの移動対象ファイル・ディレクトリの追加の仕方: 以下のようにすることで、毎年GCSに移すものが増えても、バックアップ対象の設定(duplicacyではfilters)を変えなくて済むようにした。
      1. 移動対象を同じディレクトリに作成した"Archived"ディレクトリに移動する。
        • B2: パターン「Archivedという名前のディレクトリ」をバックアップ対象外にしておく。
          • パターンの例: e:(.+/)?Archived/
            • 注: 設定ファイル内での他のパターンとの順序関係で有効性が変わる。下も同じ。
        • GCS: 同Archivedをバックアップ対象にしておく。
          • パターンの例: i:(.+/)?Archived/
      2. 移動したものを書き込み不可にする。(意図せず変更しないようにするため)
      3. 元のディレクトリにArchivedからのsym-linkを作成する。
    • 数日前に、ストレージに保存されているduplicacyの設定ファイル(config)のストレージクラスをStandardにしてみた。
      • 更新チェックやバックアップのたびにストレージからダウンロードされるので、Archiveクラスだと ストレージ操作やデータ取得の単価が高く(約10倍)、わずかに料金がかさむため。
      • configのサイズはとても小さい(< 1KB)ので、Standardクラスの料金は毎月の無料枠(5GB・月)内に収まる。
      • これにより、更新チェックの料金(現状は約10円/月)が更に下がることが期待できる。
    • 問題など
      • バックアップ先がB2とGCSの2箇所になるので、リストアが面倒(どちらにあるか・どちらからリストアすべきかを考える必要がある)。
        • まずB2で試し、なかったりArchivedに入っていたらGCSからリストアする。
      • バックアップ対象設定を誤る(例: 設定が非対称)と両方にバックアップされず、いざという時にリストアできない可能性があるので、注意・確認が必要。
      • B2とGCSでバックアップのトップディレクトリが異なるので、間違えやすい。
      • バックアップ(HDD)を整理しようとして本物を削除してしまい、B2のバックアップからリストアして復旧できた。
  •  0
  •  0

YouTubeを聴きながらツイートしていたが、量が多くなったので ここにまとめたい。当初は全部の日・演奏(3日, 12人)をまとめて書こうと思って居たが、1日分(約4時間だけでも結構疲れて いつ聴き終わるか分からないので、各日ごとに分ける。

参照: コンクールのトップページ, Wikipedia

各演奏の感想・印象

  • 本選1日目
    1. Pacholec (ポーランド, 第1番, スタインウェイ)
      • 僕はなぜか、曲を第2番と勘違いした(次の人の途中でコンクールのプログラムを見るまで気付かなかった)。間違える訳はないのだが、酔っていたせいか?
        • ただ、事前に1番の予感がしていたので、それは当たった。が、外れたと勘違いしたw
      • 第1楽章: 悪くない。が、パワーが足りないところがある気がする。迫力がもう少し欲しい。音は綺麗だ。オケ(テンポ)は少し遅い。
        • なぜかスタインウェイらしくない音だった。柔らか過ぎる?
      • 第2楽章: 綺麗ではあるが、今ひとつな感じ。音が滑らかでなく深みが足りない。
      • 第3楽章: 悪くない。こういうのが得意なのかも。ただ、音を切り気味で滑らかさが足りないところはある。
    2. Rao (中国, 第1番, スタインウェイ)
      • 第1楽章: テンポは丁度いいが、ピアノの出だしがちょっと大げさかな。一生懸命弾いている感じは するが、ちょっと違う感じ。余裕がないって感じか。
      • 第2楽章: 音が余り綺麗でなく、滑かさも足りない箇所がある。
        • スタインウェイは調子が出て来たのか、最初より少し音が良くなった気がする。弾き方の違い?
      • 第3楽章: 最後の速い部分は滑らかだったので、ちゃんと滑らかに弾けるのだ。だから、第2楽章などは ああいう表現だったのか。
    3. 反田 (日本, 第1番, スタインウェイ) → 2位
      • 以前聴いたラフマニノフのピアノ協奏曲(第2番(2016), 第3番(2019))は どちらも今ひとつだったが、今回は悪くなかった。彼(and/or 僕)と曲との相性か、彼(and/or 僕)の進化か。
        • 第3番はこの演奏を聴く数時間前に聴いたが、気の抜けたピアノで、最初の十数秒で聴く気が失せた。遅いテンポだけの問題ではないと思う。
      • 第1楽章: 気のせいか、イントロは今までで一番いい。オケも乗ってきた?
        • ピアノの出だしは許せる。ちょっと硬いところはあるが、今までの人よりはいい感じだ。
        • これは悪くない。乗れる。彼はショパンが向いているのかも知れない。
        • オケとの関係もあるが、ルガンスキーのちょっと甘い演奏より いいと思う。
        • 特に文句がない。今までの2人よりずっといい。上位に入っただけのことはあるようだ。
        • こっちも全力投球して疲れたw
      • 第2楽章: 結構遅いけど嫌にならないのが不思議だ。中盤の辺りは わずかに硬い感じ。
        • この辺りのパワーの入れ方がいい!
        • 最後の音の出し方も なかなかいい(もう少し弱いほうが好みだが)。
      • 第3楽章: 「もう大丈夫」って感じだった。
        • この当たりでは、スタインウェイはスタインウェイの音になっている。
        • 気持ち良く弾けたようだ。こっちも気持ち良かった。
      • ただ、乗れたけど、個性が薄かった気がする。それで違和感なく聴けたのでは? そして、僕が「いい」と思う演奏とコンクールで上位に入る演奏は別なので、(審査基準などは知らないが、)そこが1位になれなかった、かつ、単独2位でなかったポイントかも。
        • 優勝した人はどうなのか 楽しみではあるが、何となく気に入らない気がする。
      • (書いたあとで) この日のYouTubeのコメントを少し見たら、ほとんど(おそらく、日本人は多くないだろう)が彼を良く評価していた(例: Thomas Nguyen: "My rough guess, Kyohei Sorita will become the winner of this year competition")。それらのコメントがリアルタイムで(次の日の演奏の前に)書かれたとしたら、彼が一番いいというのは確かだ。であれば、僕が「いい」と思ったのは さほど一般ずれしていない(→ 上位に入ってもおかしくない?)ことが分かった。
        • それにしても、ここまで沢山の好評価を得るとは、彼は余程すごいようだ。
    4. Armellini (イタリア, 第1番, Fazioli) → 5位
      • イタリア人のせいか、ピアノはFazioliになった。何となく大きい(長い)。どんな音なのか、楽しみだった。
      • 彼女の演奏している姿・表情は なかなか感情豊か(passionate?)だった。反田も結構なものだったが、やっぱりラテン系は違うのかも知れない。
      • 第1楽章: 少し(結構)遅い。このテンポは余り好きでない。
        • いかにもラテン的に流麗に弾く。硬さが ないのはいいが、切れやパワーが少し欠ける気がする。
        • 切れ込みとか鋭さが足りない。
        • この辺りの音が不明瞭なのはなぜか?
          • ただ、今聴いてみるとそうでもないので、僕の問題か。通して聴くと感じるのか。
        • Fazioliのピアノは柔らかい音で、スタインウェイのような鋭さはないようだ。特に中域が柔らかいような、こもり気味で音が通らない・オケに負ける感じ(温まっていないせいかも)。
          • あと、高音などはそれなりに出るのだが、スタインウェイのように綺麗ではない。ただ、低音は綺麗で許せる。
          • うろ覚えだけど、カワイやヤマハ、あと、ヨーロッパの有名なピアノも こんな音だったかも。
        • 演奏かピアノか、音の線が細い感じもする。そこが一番物足りない。
      • 第2楽章: 最後の音の出し方は良かった。
      • 第3楽章: なぜか豹変した。それまでは、悪くはないが今ひとつな感じだったが、曲とピアノが合ったのか。
        • この楽章は今までと全然違って、かなりいい。彼女は こういう曲が得意なのではないか? テンポの変化がいかにもラテン的だ。ここだけなら上位に行けた気がする。
        • 終盤(この辺りから)がすごく良かった! そこはすごく気に入った。全部こういう感じだと良かった。
        • Fazioliのピアノはどうも今ひとつだと思って居たが、この楽章は良かったので、演奏の問題だったのかも。
          • あるいは、弾き始めのピアノの問題?

 

雑感

  • 今は、TVじゃなくてPCで好きな時に聴ける・観られる(しかも全部!)ので便利だ。
  • 審査員に懐かしい・名前を知っている人が居た。: ネルソン・ゲルナー(以前、コンサートでラフマニノフのピアノ協奏曲を聴いた), ケビン・ケナー(昔、ショパンコンクール 1990のTV番組で観た。その時は、日本人は確か横山幸雄ともう一人、女性が居たはず( ← 高橋多佳子。他に有森博 他も居て、日本人が多かった)), ダン・タイ・ソン
    • それから、低俗な話題だが、審査員に一人綺麗な女性が居たけど名前が分からなかった。さっき調べたら、それらしい人はSa Chenだけだが、なんか雰囲気が違う。まあ、どうでもいいことだ。
  • 何度も同じような曲を聴くのは苦痛。会場で聴いている人はすごい。決勝(協奏曲)だと、1日に最大4回(全部同じ曲の場合もある)、座って聴き続けるのだ。オケや審査員はもっと大変そうだ。
    • 僕は1日分を2日に分けて聴いた。しかも間に休みの日を挟んでw
  • 当然ではあるが、指揮者・オケが各演奏者ごとに異なる演奏をしているのがすごい。
    • 飽きて惰性で演奏しちゃいそうだけど、気が抜けないだろうな・・・
  • 1日の最初の頃に弾く人は不利な気がする。2-3番目くらいが良さそう。特に、決勝などの本当に一番最初は不利だ。
    • ピアノの調子 (車みたいに暖機が要りそう)
    • 審査員の調子・乗り・レベル感の確定
    • 聴衆の乗り
    • 会場(ホール)の調子?
  • 演奏者が出る時に、みんな会場の紹介アナウンスで名前を呼ばれたらすぐに出て行こうとするけど、タイミング(そのあとで少しオケが調整しているようだ)があるらしく、係の人に止められていたのがおもしろかった。フェイント?
  • 会場は結構こじんまりとしていて、いい感じ。ステージの床の木(「本物のフローリング」?)が良かった。
  • ページにある、コンクールのシンボルのデザイン(色遣い)は いい感じ。意味は分からないがw
  • 何度も聴いて(聴かされてw)分かったが、僕がショパンのピアノ協奏曲を好きでないのは、特に第1番に関しては、イントロが大げさで古臭く感じるからだ(僕にとってはモーツァルトの同第22番と同様)。それが進むにつれて解消され、第3楽章に至っては なかなか乗れて「いい感じ」ですらあることに気付いた。
    • 第2番のイントロは出だしは静かで(でも、すぐに大げさになるが)、ピアノの入り方がかっこいいので、第1番よりは好きだ。でも、なぜか今回は(いつも?)弾く人が少なかった。
  • 多くのYouTubeのコメントの中で、うまいこと言うと思ったのは次だ。
    • Lea Meine:

Pacholec : Polish essence
Rao : Great effort
Sorita : Controlled experience
Armellini : Musical freedom
I don’t think I can rank them, but that’s how I feel about their performances.

 

※最初、"final"を「決勝」としたが、スポーツのような感じがして落ち着かなかった。それと「本選」のどちらが適切か分からないが、日本のWikipediaにならって「本選」に修正した。

  •  0
  •  0

近頃、ネットのアクセスがすごく遅い気がしていたのだが、(良くあることだが)たまたま混んでいるせいだと思って居た。しかし、今朝は どうも違うような気がしたので、スピードテストをしてみると、テストが始まるまでは すごく遅いものの、スピード自体は問題なかった。

それで、DNSが遅いのではと思って調べたら、どうやら、僕が使っているDNSサービスのQuad9(9.9.9.9)は10/16(おそらくUTC)頃から急に遅くなったようだ。 (→ 参照: "Not found"になる場合あり) 以下に、DNSPerf("Not found"になる場合あり)で調べた、Quad9と有名なCloudflare(1.1.1.1)の応答速度変化を示す。

他も見てみると、Quad9同様に近頃遅くなったものが多いので、世界的な問題なのだろうか? 何かの攻撃・活動?? まあ、そういうことは僕は どうでも良くてw、とりあえず遅いのを解消したいので、PCのDNSサーバ設定をCloudflareに変更した。当然ながら、スピードテストの開始が速くなり、他のwebの表示も気持ちいいほど速くなった。

おもしろかったのは、僕のこのブログの表示は いつも遅い(でも、下に出る表示時間はそれほど遅くない)と思って居たのだが、それも ほぼ一瞬で出るようになったことだ。「今までの遅さはなんだったんだ!」と思ったw

同様に、ネットが妙に遅く感じることがあったのは、Quad9が遅いこともあったのではないか(もちろん、ネット自体が遅いことが ほとんどだったと思う)。

その後、dnspingというプログラム(パッケージdnsdiagでインストールする)でDNSサーバの応答時間が測れることが分かって調べたら、Quad9の応答時間はCloudflareやGoogleの約2-5倍であることが分かった。なお、Cloudflareは速いが変動があり、Googleは言われるほど速くなかった。以下にいくつかの測定結果を示す。

Quad9: 平均 222ms

--- 9.9.9.9 dnsping statistics ---
4 requests transmitted, 4 responses received, 0% lost
min=187.845 ms, avg=222.095 ms, max=271.483 ms, stddev=40.576 ms

Cloudflare: 平均 118ms

--- 1.1.1.1 dnsping statistics ---
4 requests transmitted, 4 responses received, 0% lost
min=23.369 ms, avg=117.756 ms, max=172.085 ms, stddev=70.577 ms

同2回目: 平均 43ms
--- 1.1.1.1 dnsping statistics ---
6 requests transmitted, 6 responses received, 0% lost
min=23.226 ms, avg=42.777 ms, max=138.602 ms, stddev=46.946 ms

Google: 平均 132ms
--- 8.8.8.8 dnsping statistics ---
5 requests transmitted, 5 responses received, 0% lost
min=22.459 ms, avg=132.160 ms, max=232.088 ms, stddev=101.970 ms

同2回目: 平均 77ms

--- 8.8.8.8 dnsping statistics ---
6 requests transmitted, 6 responses received, 0% lost
min=22.410 ms, avg=76.629 ms, max=196.265 ms, stddev=83.767 ms

それから、Quad9はどうも駄目になっている感じの記事もあった。最初は見出しからドイツ語だと思って(本文は英語だったw)拙い翻訳版しか見ていないので詳細は不明だが、良くある資金不足だろうか。

 

そんな状況を眺めつつ考えたら、べつに外部のDNSサーバでなくてもルータのでいいような気がした。というのは、Quad9は安全面で良い(例: 危険なサイトをブロックする)から使っていたのだが、Cloudflareにはそういう機能はないので、速度以外に選ぶ理由はない。が、速度ならルータのサーバ(プロバイダのをキャッシュする)が一番速いはずだ。

なお、Quad9の危険サイトブロック機能は惜しいが、今まで働いたことがないので なくてもいい気がする。ブラウザにも、危険なサイトから保護する機能はある。

書いたあとで思い出したが、たまに、なぜかCloudflareの「ブラウザをチェックしています」という画面が出ていたが、Cloudflareにも似たような機能があって、それだったのか。ということは、全然気付いて居なかったけどQuad9が使われていなかった(ダウンとみなされてCloudflareに切り替わって居た)ことが多そうだ。謎だ・・・

とすれば、Cloudflareでも ある程度は安全性の向上が期待できそうだ。ただ、上の変な画面が出る(実はこれ、最近まで危険なサイトかと思って閉じていたよwww)。 ← 調べたら、これはCloudflareのDNSでなく、CDNの機能のようなので、やっぱり、CloudflareのDNSにするメリットは(僕には)余りない。

測ってみたら、以下のように、平均1.3msと爆速だった(キャッシュされたサイトに限る)。

--- 192.168.0.1 dnsping statistics ---
5 requests transmitted, 5 responses received, 0% lost
min=1.212 ms, avg=1.273 ms, max=1.329 ms, stddev=0.044 ms

キャッシュされていないサイトはプロバイダのサーバが参照されるが、近いせいもあってCloudflareなどと遜色なかった。以下にdnspingの結果を示す。

プロバイダ(DTI): 平均 61ms

--- 2404:1a8:7f01:b::3 dnsping statistics ---
5 requests transmitted, 5 responses received, 0% lost
min=22.127 ms, avg=61.362 ms, max=209.331 ms, stddev=82.741 ms

同2回目: 平均 52ms

--- 2404:1a8:7f01:b::3 dnsping statistics ---
6 requests transmitted, 6 responses received, 0% lost
min=21.448 ms, avg=52.380 ms, max=191.389 ms, stddev=68.169 ms

あと、Cloudflareがうたうメリットの一つにアクセスが記録されないからプライバシー面で良いことがあるが、プロバイダはDNSだけでなく アクセス履歴はなんでも記録できるから、DNSアクセスだけ記録しないことにメリットはないと考えた。

それで、PCのDNS設定をルータに変えた。気のせいか、このブログの表示が更に速くなった気がする^^

なお、ルータは代替DNSサービスやv6のDNSサービスを持たないので、代替サーバ※はCloudflareにした。

※ PS2に書いたが、上(NetworkManagerの設定)は実際には「代替」サーバでなく、ルータ(またはプロバイダ)のサーバと対等な「追加」サーバとなっていた。良く調べなかったせいもあるが、この辺りは 見た目ほど単純でなく、中は すごく こんがらがっていて誤解しやすいので、今まで分からなかった。 (10/23 18:43)

僕のルータ(I/Oデータ WN-SX300GR)が残念なのは、IPoE接続(MAP-E)の時はDNSサーバを変更できないことだ。もしできれば、ルータのキャッシュにない時はCloudflareなどにアクセスできるのだが。まあ、大きな問題ではない。あと、プロバイダのDNSサーバから送られてくるのか、resolv.confにフレッツ用の設定らしきもの(例: search flets-east.jp iptvf.jp)が入ってしまうが、気にしなければ良いw

それから、スマフォ(Andorid)は簡単にはDNSサーバが変更できないため元々ルータだったので、何も変更は要らなかった。

 

結局、「ごく普通の設定」が最適だった訳で、僕が良くやる「とりあえずいじる」の「過ぎたるは−」的な失敗ではあったw

 

それにしても、数年前から「CloudflareやGoogleにするとネットが速くなる」って良く見ていたが、本当なのだろうか? (国内にもいくつかサーバがあるのだろうが、)わざわざ遠いサーバを参照しても、それに見合うとは思えない。プロバイダのDNSサーバが貧弱とか混んでいる場合の話だろうか。後者だったらネット自体も遅くなる気がする。

 

PS. 僕のPCのDNS検索が遅かった件については、DNS検索結果をPC内でキャッシュしないようにしているせいもあることに気付いた。通常はキャッシュする(DNSサーバのIPアドレスが自分のPCになる)ようだが、確かv6対応にした時に何か問題があって止めた気がする(が、詳細を思い出せない)。

→ 少し調べたら、どうやらdnsmasqをNetworkManager経由で使っていたのを2020年の年末に止めたようだ。その経緯をノートで調べたら、その時は楽天モバイル(ポケットWi-Fi)を使おうとしていて、光のプロバイダのDNSサーバの設定が競合してDNS検索が遅かった(今回のようにブラウザの表示が遅かった)ので無効にしたことが分かった。もう楽天モバイルは使わないので戻してもいいはずだ。が、ちょっと面倒だw まあ そのうちやりたい。

本文に書いたようにルータがキャッシュしているので戻すメリットは余りないが、(キャッシュで ある程度高速化できるので、遅い)Quad9が再び使えるようになることか。まあ、それにどのくらい価値があるか・・・ (そもそも、Quad9は楽天を使う時に始めたので、特に必要はない。)

(15:40) とりあえずやってみたら、またハマったw

DNSキャッシュとして最初から使われていたのはdnsmasqでなく、systemd-resolvedだった。どうも設定ファイルにdnsmasqの痕跡がなくておかしいと思った。dnsmasqは動いたのだが(これも分かりにくいことがあって、ちょっと苦労した)、元々のものがいいのでsystemd-resolvedに戻そうとしたら、DNSが参照できなくなって苦労した。

こうなるとネットの検索すらできないので、難儀した。それで一時的にdnsmasqを有効にした。

結局、ここでも楽天のための設定変更が悪かった。/etc/systemd/resolved.confで DNSStubListener=no にしていたために、プログラムがsystemd-resolvedでDNS検索しても応答がなかった。

修正したら うまく行き、キャッシュされたホストについては概ね0.5ms以内に応答が得られるようになったので満足した。(というか、単に元に戻しただけなのだがwww)

なお、DNSサーバはプロバイダのものにした(ルータから渡される情報をそのまま使うことにして、何も設定していない。 → この場合、v6のサーバが使われるようだ)。

PS2. 今調べたら、Quad9の速度が回復しているようだ。とすれば、上に書いたローカルなDNSキャッシュ機能を使えば、速度低下を起こさずに使えそうだ。そうする意味は、気休め程度にQuad9による安全性が期待できるだけだが、どうしたものか。 (と、振り出しの近くに戻る?w)

(18:32) 使えるものは使う主義なので、結局、再びQuad9を使ってみることにした。今度はちゃんとキャッシュが効いて、最初の検索以外は遅くない。もしまた遅くなったら戻せば良いのだ(でも、その時は きっと忘れていることだろうwww)。まあ、「懲りない奴」ってことで・・・

(10/22 15:50) やっぱりQuad9は遅い(定常状態で遅い)。いくらキャッシュしても、ヒット率が低い(例: 24%)ので、全体的な速度は低下する。特に、ブラウザで最初にページを開く時は(キャッシュがヒットせずに)遅くてイライラするので止めて、プロバイダのサーバにした。大体Quad9の10倍速く、再び高速・快適になった。

PS2. 僕のPCのDNS検索が遅かった件について、更に別な関連することが見付かった。ブラウザ(Firefox)の設定でDNS over HTTPSをQuad9に設定していた。そのため、webページの表示が遅かったのはOS(Linux)の設定とは関係だったようだ。OSの設定を変更して速くなったのは、たまたま同じ頃にQuad9が回復したせいなのだろうか。

あと、OSのDNSの設定も複雑で、NetworkManagerとsystemd-resolvedを使っている場合、DHCPで取得したDNSサーバのアドレス(= プロバイダのもの)も使われるのだが、それらと自分で追加設定したものが並列に有効で(早いもの勝ち?)、実際にどれが使われるかが不明だ(見ていると、時間が経つと変わるようだ)。

マニュアルもなかなか意味不明で、いろいろ設定しても なかなか意図したように(DHCPのDNSサーバアドレスを無視する)は動かない。試行錯誤した結果、NetworkManagerのv6の設定で"Automatic, addresses only"というモードにすると、DHCPではIPアドレスだけ設定し、DNSなどは使われず、systemd-resolvedにも送られないことが分かった。

DHCPで得られる情報のIPアドレス以外(DNS以外は不明)は不要なのかという疑問はあるものの、それで使ってみて、まだ大きな問題はない。 (10/22 12:24)

注: PSに追記したが、Quad9を使うのを止めたため、今は元の"Automatic"の設定に戻した。 (10/22 22:03)

PS3. 更に、DNS over TLSを使うのも一苦労だった。resolved.confでDNSOverTLSを設定するだけでは駄目で、DNSにサーバのIPアドレスだけでなく、"#"でホスト名を追加する必要があった(例: DNS=9.9.9.9#dns.quad9.net)。(→ 参照1, 参照2)

ちょっと凝ったことをしようとすると、なかなか大変だ。 (10/22 15:03)

注: PSに追記したが、Quad9を使うのを止めたため、今はDNS over TLSは使っていない。 (10/22 22:03)

 

(10/23 18:43 少し補足)

  •  1
  •  0

結構前からSpotifyで少し配信されて居たのを試しに聴いてがっかりしたので全然興味なかったが、今日 発売配信されたのを知って ちょっと試してみたが、やっぱり駄目だった。時間(とお金)の無駄だ。

  •  1枚目のメインのリミックスはオリジナル(1970, 2009リマスター)より音(音質, 音作り)が悪い。あと、アレンジ(ミックス)も悪い。
    • 音の悪さは2曲目の"Dig a pony"から感じた。特に、低音のドラム(バスドラ?)が潰れたような音だ。
    • 音がすっきりしていない、抜けが悪いという点で"Mono masters" (2009)に通じるものがある感じだ。
    • 3曲目の"Across the universe"もひどい音で、イントロから不自然な感じだ。それから、元々大げさな演奏なのに、コーラスが更に不自然になり、オケは更に大げさになってしまった。
    • ここまで聴いたところで嫌になって止めた。
    • 例の世襲プロデューサーのセンスが悪いのだろう。自己満足の改悪は止めて欲しい。
  • 2, 3枚目のセッションだのリハだのジャムは映画"Let it be" (1970)さながらの たるんだ演奏(感想の例: (3枚目)"Get Back - Take 8": 「以前の曲((2枚目)"Don’t Let Me Down - First Rooftop Performance")同様、気の抜けたサイダーもいいとこ・・・」)にがっかりした。(Spotifyの配信で数曲しか聴いてない)
    • がっかりするのも当然で、いい演奏なら当時出していたはずなのだ。出せないレベル(みんなが放り投げた)だったから、今まで残っていたのだ。
  • 4枚目のGlyn Johnsミックス(1969)は海賊盤で持っている(1970年版も)し、そもそも中身が余りおもしろくなかった(「オリジナルよりずっといい」とは言えない)ので、今出ても聴く気が起こらない。
  • 5枚目の"Let it be EP"は何のためにあるか不明で、やっぱり おもしろくなかったが、このセットの中では一番まともな気がする。

結局、僕にとっては、スペクターの労作であるオリジナル版(音質の点では2009リマスター)が一番いい。確かに、アレンジで やり過ぎな面もあるが、上に書いたように そのままでは どうしようもなかった素材を実にうまくまとめ上げたと思う。だから、"Let it be... naked" (2003)の音自体はシンプルでいいけど、やっぱりしっくり来ず、積極的に聴く気になれない。むしろ、-nakedが出てオリジナルの良さを再認識したくらいだ。

 

そして、なぜ、この5枚組にもなるデラックスなアルバムには「ルーフトップ・コンサート」が丸ごと入ってないのだろうか? 僕はこれが一番聴きたい。てっきり、2か3枚目がそうなんだと思って(良く確かめずに)掛けたが、違っていた。 → 映画(ドキュメンタリー)で出すからか。 ← 11/25から公開だそうだから、その前に音を出しちゃったらネタバレみたいになってしまうからか。

そして、そのあとにそのCDなどを(何種類も)売り出して、「二度おいしく」なるのを期待しているのか。もう、立派なビートルズ商法だ。

 

PS. 豆知識(というか知らなかったこと): 「リハーサル」の綴りは"rehearsal"だった。当てずっぽうで"reharsal"と打ち込んだら、スペルチェックで引っ掛かった。"hear"が入っているのは 分かるような気がするが、発音には出ないので妙な感じ。

他に、関係ないけど英単語関連で、同意・承諾(音は「コンセント」)を"concent"と打ったら違っていて、"consent"だった。前者は日本の「コンセント」なのだが、単語としてはあるものの一般的ではないようだ。これを送ったら笑われるところだったw

  •  0
  •  0