|
．grouping と CHAR_MAX - なんてひでえ仕様だ :D ＞ POSIX ．arm の一部と ppc を除くと CHAR_MAX == 127 なので、そこから外れるアーキテクチャでは libc で fixup するのがいいんじゃないでしょうかねえ: #define _CITRUS_LC_GROUPING_VALUE_MIN 0 #define _CITRUS_LC_GROUPING_VALUE_MAX 126 #define _CITRUS_LC_GROUPING_VALUE_NO_FUTHER 127 ... #if CHAR_MAX != _CITRUS_LC_GROUPING_VALUE_NO_FUTHER // fixup #endif ．あるいは DB に grouping127 と grouping255 とかを用意して以下略。嫌だ嫌だ。 ．そうそう、libc のメジャーバージョン上がるなら、ctype.h の ctype 表を 32bit にできませんかねえ。XPG4DL 入れるときにやっときゃよかったんだが。 ．仕様上は各ビットの可能な組み合わせが決まってるので、現状の 8bit でも足りてるような足りてないようなそんな感じですが、実装上は is* と各ビットが一対一対応してたほうが柔軟に対応できそうな気がする。rune locale の内部では実際そうなってるので、それを流用すればいいのかな。runetype.h にあるビットフィールドの定義を(rune という名前は削って)ctype.h にもっていくのかのう。 ．いっそマクロやめればいいじゃん、という説もあるけれど。ところで ctype.h の #ifdef _REENTRANT って #ifndef の間違いじゃないですかね。 ．あとはまあ個人的な好みをいえば、DB のフィールド名は #define _CITRUS_LC_NUMERIC_SYM_DECIMAL_POINT "decimal_point"とかどっかのヘッダに書いておきたい気もする(cf. citrus_esdb_file.h)。無駄といえば無駄な気もするけれど。 ．あと、新規に Rune って名前を使うのはやめたほうがいいでしょう。 |
|
．JPOPサウンドの核心部分が、実は１つのコード進行で出来ていた、という話 - 「誰もきちんと語ったことの無い話題」って、コード理論の本を読むと「逆循環コード進行」という名前で体系化されてますがな。JPOP だと循環コード進行と逆循環コード進行を一度も使ってない曲の方が珍しいってのは、この手の話題ではよく取り上げられると思います。 ．ありがちなパターンとしては、A メロを循環コードでスタートして B メロを逆循環コードでつなぐとか、サビを延々逆循環コードで埋めるとか。 ．さすがにポピュラー音楽で無調音楽とかそういうのをやるわけにもいかないから、どうしても限られたコードをどう組み合わせるかという戦いになる。「定番のコード進行を思い浮かべて、それを使うな」が差別化の第一歩なのだけれども、そもそも「定番のコード進行」とは何ぞやというのを知らないとどうしようもない。知識を集めるってのはそれなりに大切ですね。 ．とはいえ、小さい頃からの刷り込みによって、何にも考えずにフレーズを作るとこの辺のコード進行にはまってしまうように日本人の脳みそはできている。作曲の初心者は、せめて IIIm を III7 に変えてみるとか VIm を VI7 に変えてみるとかするところから始めるのが無難ですな。一方で、定番というのは陳腐ではあっても飽きが来ない水戸黄門の時代劇みたいなもんなので、不特定多数の人に聴いてもらうことが目的ならば、あえてそういうのをバカの一つ覚えみたいに使うというのも一つの生き方です。 ．よく考えてみたら逆循環コードは S-V7-T-VIm の総称だった気もする。T (トニック) が I のこともあるので、逆循環コードの説明としては、上の「本当のトニック(=I)に終止せずに」というのは必ずしも正しくないな。 |