雑多なブログ

音楽や語学、プログラム関連の話題について書いています

楽器練習におけるメトロノームの有効な活用法について

メトロノーム使って練習するのは当たり前?

楽器の練習にメトロノームは必要だし、メトロノーム使わずに練習するのは良くない、とは楽器のレッスンを受けていて言われてきた。 たしかにメトロノームを全く使わずに練習していると、リズムやテンポ感を甘い状態でだらだら練習してしまうところはあると思う。

ただ、何も考えずに先生から言われたからといって、常にメトロノーム鳴らして練習する、という短絡的な発想は良くない。

メトロノームを使わない方が良い場面

譜読みが進んでおらず、運指もあやふやで、つっかえずに演奏できないような段階では、メトロノーム使わない方が良い。 もしくはメトロノームを使うにしても、早く弾いたり通しで演奏するのは難しいけど、数小節はつっかえずに演奏できる、といった場所をメトロノーム使って練習するのは良いと思う。

つっかえて止まってしまうような場所をメトロノームを使って練習するのはやめておいた方が無難。弾けない状態で無理矢理メトロノーム使っても、最終的にはメトロノームを無視して好き勝手に演奏してしまいたくなるもの。 自分含めビギナーの演奏を見ていると、メトロノームを無視してリズムぐちゃぐちゃになった状態でそのまま練習している事が多く見受けられる。

こういった段階ではメトロノームを活かす事はできないので、無理してメトロノームを使う必要はない。

状況によっては、メトロノームを使わない方が良い理由

前述のように、まともに演奏できない状態で無理矢理メトロノーム使っても、自分に都合良いリズムやテンポで演奏してしまいがち。で、この状態で何度も何度も練習していると、メトロノームの刻むリズムを無視する癖が付いてしまう。

程度の差はあれども、人間は誰しも都合の悪い事を無視したり軽視する側面がある。これは人間性というより、人間の認知機能の特性だと思う。さておき、都合の悪いことを軽視していると、油断しているところで重要な情報を見落としてトラブルに見舞われる、といった事は多々ある。

メトロノームの扱いも同じで、普段からメトロノームを軽視する習慣を続けていく事で、いざきっちりとリズムやテンポキープのトレーニングが必要になっても、今までの習慣によって、ルーズな練習を無意識に行うようになる。

人間は習慣によって形成される

普段運動しない人が思いつきで1日運動しても、翌日サボってしまうといつまでも習慣化しない。なぜかというと、運動しない日々を過ごす事が習慣になっているため、たまたま1日だけ運動しても元の習慣に引きずられてしまうのである。

まとめ

そんなわけで、話を元に戻すと、メトロノームを適切に目的を持って活用する習慣を作らない限り、ルーズな状態でリズムやテンポを捉え続ける癖を強化する結果になってしまうという事になるので、そのあたり意識してやっていくと良い。

しかし、言うは易く行うは難し。 理屈を考える事はできても、実際にそれを実行するのは、自分にとっても難しい。頑張っていこうと思う。

Typescript: 型

2022年5月2日更新

最近改めてTypescriptの型について学んだので、過去に記述した内容のアップデートも含めて今回記事の更新を行なった。

型の定義

型の指定は次の形式で記述する。

const 変数名: データ型
let : データ型

プリミティブ型

代表的なプリミティブ型は次の通り。

型名
string let name: string = 'Hello Typescript'
number let value: number = 99
boolean let isChecked: boolean = true
const isVisible: boolean = false
null let value: null = null
undefined let value: undefined = undefined

Array

配列の要素の型を指定し、後ろに角かっこを付ける。

// 要素がnumber の配列
let aryValue: number[] = [1, 2, 3, 4]
// 要素が string の配列
let strValue: string[] = ['hello', 'Typescript']

二次元配列もこの通り。

let aryValue: number[][] = [
    [1, 2, 3, 4],
    [5, 6, 7, 8]
]

tuple

一見して配列のようにも見えるが、順序と個々の要素の型が決まっている。

let tupValue: [number, string]  = [22, 'Hello Tuple']

// これは型指定の順序と値の代入の順序が異なるためエラーとなる
let tupValue: [number, string]  = ['Hello Tuple', 22]

object

オブジェクトを示す型は objectで基本的な定義方法は次の通り。

const user: object = {
    name: 'Tarou',
    age: 25
}
// こちらでもOK
const user2: {} = {
    name: 'Jirou',
    age: 33
}

オブジェクトのプロパティの型を指定することもできる。

const user3: {
    name: string,
    age: number
} = {
    name: 'Saburou',
    age: 18
}

any

any型はなんでも受けいれてしまうため、Typescriptを使うメリットが活かせない。
基本的には使わない方が良いが、APIリクエストのレスポンスなど、
型の指定が難しい場合に、明確な意図を持って使用すべき型だと思う。

let value: any = 1
value = 'string_value'
value = {"key": "value"}

null と undefined

定義方法は他の型と同じ。

let nullValue: null = null

デフォルトでは、この2つの値はどういった型の変数にも代入でき、
以下のような代入が可能となっている。

let hoge: string = 'hello'
hoge = null
hoge = undefined

strictNullChecks : true

コンパイル時のオプション strictNullChecks : true を指定すると、
上記のような代入はエラーになる。

変数にnullやundefinedが代入される場合は、次のようにユニオン型の型注釈で表現する事ができる。

let hoge: string | null = 'hello'
hoge = null

never

never型は下記に該当する関数の戻り値に指定できる。

  • 絶対にreturnされない関数
  • 例外 throw する関数
function neverReturn(): never {
    throw new Error('もどりません')
}
neverReturn()

スパムコメントが付いた。

怪しげなコメントが付いたので晒しておく。

メールアドレスのドメインからして怪しいので、該当するメールアドレスからメールが届いたり、ブログなどにコメントが付いていた場合は注意してくらはい。

下記コメント内容。

 林遠

失礼致しました。Amazonで日本のラズベリーパイを販売している林遠です。
ブログを拝見しました。弊社のラズベリーパイカメラレビューブログ記事を書きしてくれませんか。
こちらは無料でサンプルを提供します。
連絡メールはjp02@vertue.cnです。
御返事お待ちしております。どうぞよろしくお願いします。

Error: "prettier/@typescript-eslint" has been merged into ....

eslintを実行したら下記エラーが発生。

Error: "prettier/@typescript-eslint" has been merged into "prettier" in eslint-config-prettier 8.0.0. See: https://github.com/prettier/eslint-config-prettier/blob/main/CHANGELOG.md#version-800-2021-02-21

.eslintrc.js の内容は次の通り。

module.exports = {
    env: {
        browser: true,
        es6: true
    },
    extends: [
        "eslint:recommended",
        "plugin:@typescript-eslint/recommended",
        "prettier",
        "prettier/@typescript-eslint",
    ],
    plugins: ["@typescript-eslint"],
    parser: "@typescript-eslint/parser",
    parserOptions: {
        "sourceType": "module",
        "project": "./tsconfig.json"
    },
    root: true,
    rules: {}
}

"prettier/@typescript-eslint",コメントアウトしたらエラーが出なくなった。

GPLライセンスについてのメモ

Wordpressのテーマについて調べていたのだけれども、GPLライセンスのものが大半だったので、GPLライセンスについて調べてみた。

Web 制作会社または Web 制作会社の成果物を検討する場合は GPL の適用範囲が WordPress の派生物でも再配布されるもののみであることに注意してください。WordPress のテーマやプラグインを個人利用、ビジネス利用の目的で作成した場合、GPL はそのテーマ、プラグイン、派生物を、一般に公開するところまでは求めていません。Web 制作会社が作成したすべてのカスタムテーマについてライセンスを調べる必要はありません。

引用元: https://japan.wordcamp.org/for-organizers/gpl-primer/

改変したプログラムを配布する場合はソースの公開が必要で、GPLライセンスのテーマを使ってウェブサイトを構築した場合はソースの公開は不要という解釈で良いのだろうか?

そもそも、wordpress自体がGPLライセンスなので、wordpressを使って一部カスタマイズしてウェブサイトを公開するだけならば問題ないのかな?

参考サイト

https://taedoo.at.webry.info/201405/article_5.html https://xtech.nikkei.com/it/article/COLUMN/20100118/343301/ https://in.spicagraph.com/other/wp-theme/

楽器の演奏で暗譜することについての自己分析

最近、曲を暗譜するほど弾き込んでいれば、目をつぶっても演奏できる事に気づいた。

これまで自分は、ある程度曲が弾けるようになっても不安で常に楽譜を見ながら演奏していた。それによって次のような弊害が生じている、ということに改めて気づいた。

  • 楽譜を見るために脳のリソースが浪費されてしまう
  • お膳立てされた状況でないと弾けなくなってしまう
  • 耳で取り入れる情報の優先度が下がってしまう
  • 周りを見る余裕がなくなる
  • 常に楽譜を見ていると更に楽譜の内容を見なくなってしまう

楽譜を見るために脳のリソースが浪費されてしまう

楽譜を見ながら演奏する場合は次のようなプロセスを辿る事になる。

  1. 楽譜を視覚情報としてとりいれる
  2. 楽譜の内容を解釈する
  3. 演奏に反映する

楽譜を読むだけでもそれなりの複雑な処理を脳は行なっているので、 それによって演奏に割ける脳のリソースが減る事になる。

耳で取り入れる情報の優先度が下がってしまう

視覚情報の存在感は大きいため、どうしても耳で取り入れる情報が疎かになりがちな面がある。

周りを見る余裕がなくなる

これも前の項目と共通だけれども、楽譜を読むのに気を取られていると、周りの状況に対する意識が薄れてしまいがち。 ジャムセッションの最中、周りのメンバーが次にどうしたいのか合図を出していても、楽譜読むのに夢中になっていると合図を見落としてしまったり、周囲のノリを読めずにチグハグな演奏になってしまう事がある。

お膳立てされた状況でないと弾けなくなってしまう

ちゃんと楽譜を見て演奏するのが当たり前、という状況でいつも演奏ているとイレギュラーに対応できなくなってしまう。

たとえば、こういった場面には多々遭遇する。

  • 譜面台がなくて鍵盤の横に楽譜を置く
  • 照明が暗くてくっきり楽譜が見れない
  • 楽譜が風で飛ばされる
  • 楽譜が自分から遠くて読みづらい(真っ直ぐ見れず、横からみるとか)

こういった場面で、常に楽譜をちゃんとセッティングした状態で読む事に慣れていると、いざこういった状況に遭遇するとパニックになってしまう事がある。 そのため、楽譜を暗譜しておいた方がいざという時に、落ち着いて対応できる。

常に楽譜を見ていると更に楽譜の内容を見なくなってしまう

常に楽譜を見ていると、意外と楽譜の内容を見ずに演奏しがち。

一説によると、脳は一度見たものを記憶から読み出して補完するという特性があるようなので、それ故に何度も何度も見続けているような新鮮味の薄れた情報は自動的に記憶で補完されてしまうものだと思う。

ということで、楽譜を見る必要がある時に意識して見るという姿勢で取り組んだ方が、楽譜の内容をしっかり読み込めるのではないかと思う。

まとめ

これは自己分析なので誰にでも当てはまるか分からない。 それに、必ずしも楽譜を暗譜しなければいけない、とは自分は思っていない。状況によっては楽譜がないと困った事にもなるので。

ただ、日常の練習に暗譜の練習を取り入れるのは良いと思う。

サイトの内容と関係のない中古ドメイン使うな

アフィリエイトの手法で、SEO対策か何かで中古ドメインを使うというのがあるが、使用方法については配慮をしろよ、と思う事が多々ある。

ドメインとは次の要素をわかりやすく表現するためのものだ。

  • 住所を表す
  • サイトのコンテンツを示す(ジャンルや内容)
  • 運営元の情報(所在や運営団体の形態)を示す

久しぶりに技術的な(あるいは音楽であったり、その他趣味関連)情報が掲載されているWebサイトを閲覧したら、アフィリエイトサイトに成り代わっていて非常に苛立たしい想いをする事がたまにある。

アフィリエイトしても良いけど、せめて商材に合ったドメイン名をチョイスして欲しい。

不適切な例を挙げてみよう。

元々幼児向けの絵本の公式サイトのドメインとして取得されていたドメインを取得して、出会い系サイトのアフィリエイトサイトやエロサイトを構築。

上記のようなケースは不適切であるばかりか、公序良俗に反したドメインの利用方法だと考えられる。

元々幼児向けの絵本の公式サイトのドメインとして運用されていた場合、ドメインが有効期限切れになって、新しい所有者にドメインが移っても、検索エンジンやどこかリンク元のサイトが古かったりするので、ユーザーの意図に反したコンテンツを返す結果になってしまう。

ということで、アフィリエイトするのは自由だけど、中古ドメインの不適切な利用はやめろ!馬鹿野郎! と思いながら、日々検索ノイズを格闘しながらネットを彷徨っている。