2019年08月22日

「紋切型社会」(武田砂鉄著、新潮文庫)

 ちょっと気分を変えて、久々の読書ネタ。「紋切型社会」(武田砂鉄著、新潮文庫)です。

20190822-1.jpg

 読み進めるのに、とても骨が折れる本だった。もちろん、良い意味で。

 武田砂鉄さんは、今の時代を覆っている「それは言わない約束だよね」というぼんやりした霧を、言葉を使って切り裂こうとしている。だから、どのような言葉も、手垢のついたやり方では使わない。そういう制約を自分に課しながら、文章を書いているように見える。どの文をとっても、「自分の言いたいことは本当にこれなのか?」と何度も自問しながら書いているようだ。書かれている内容の身近さに比べて意外なほど取っつきづらい文章を読み進めているとき、次の一文に出会って、「ああ、この感覚がこの人の文を読むときのカギだな」と感じた。

言葉の迫力を感じるのは、自分に負荷をかけてきていると実感する文章に出会った時だと、それなりの本読みを自負するこちらは切に訴え始める。(「10. なるほど。わかりやすいです。」)

 やさしい(優しい and/or 易しい)言葉がもてはやされ、少しでも骨のある言葉は忌避される。武田さんは、その風潮に抵抗している。抵抗しても、編集者から返ってくるのはこんなリアクションだ。

批評性が比較的強い原稿を出した際に、「面白いんですが、この原稿を読んで、誰がハッピーになるのですか?」と問われたことがある。メールで送られた文面を見ながら目を疑った次に相手を疑い、「原稿とは、ひとまず人をハッピーにしなければならないのでしょうか?」と返すと、「まぁでも、わざわざdisる必要はないですよね〜」と再度返されてしまう。(「20. 誰がハッピーになるのですか?」)

 こういう書き手がウェブメディアで文章を書くのは、さぞかし気苦労の多いことだろう。ウェブメディアでは、読者の反応がダイレクトに返って来やすい。でも、返ってくるのは、一読して即座に返された反応ばかりだ。中身のない「イイネ」や罵詈雑言(しかもそれこそ「紋切型」)にさらされては消耗するばかりだ。

 この本がデビュー作ということだが、武田さんはすでにあちこちのメディアでお見かけするようになっている。ぜひ、「物を考えさせる文章」を世に問い続けて、今の時代を豊かにしてほしいと思う。

posted by toshinagata at 21:32| 日記

2019年08月19日

Mac OS 10.14 で wxWidgets 開発(その2)

 「Mac OS 10.14 で wxWidgets 開発(その1)」のつづき。

4. wxWidgets のビルド (Mac OS 10.6 対応)

 wxWidgets は 3.0.3 を使う。現時点での最新は 3.1.2 だけど、これには Mac OS 10.7 以上が必要なので、10.6 サポートを切らないのなら 3.0 系列が必須となる。

$ cd path/to/wxWidgets-3.0.3
$ mkdir build-osx; cd build-osx
$ ../configure --with-osx_cocoa --with-macosx-version-min=10.6 --with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk --disable-shared --enable-monolithic | tee configure.log
$ (date 2>&1; make -j 4 2>&1; date 2>&1) | tee make.log

 本当は --prefix を指定して make install までやっておいた方がいいような気もするんだけど、今のところこれでも動いている。あまり行儀のいい使い方ではないかも。

5. wxWidgets のビルド (mingw-w64, クロスコンパイル)

 --host を指定するだけで、クロスコンパイルできる。

  #  32 bit 版
$ cd path/to/wxWidgets-3.0.3
$ mkdir build-win32; cd build-win32
$ ../configure --host=i686-w64-mingw32 --disable-shared --enable-monolithic | tee configure.log
$ (date 2>&1; make -j 4 2>&1; date 2>&1) | tee make.log
  #  64 bit 版
$ cd path/to/wxWidgets-3.0.3
$ mkdir build-win; cd build-win
$ ../configure --host=x86_64-w64-mingw32 --disable-shared --enable-monolithic | tee configure.log
$ (date 2>&1; make -j 4 2>&1; date 2>&1) | tee make.log

 wxWidgets のコンパイルはすごく時間がかかる、というイメージがあったんだけど、実際には5分ぐらいで終わった。クロスコンパイルだと、サンプルをビルドしないからかな。

 実はこのままだと、libwinpthread-1.dll という dll に依存する実行プログラムができてしまう。これは既知の問題で、基本的にはリンカオプションで回避するのだが、たまにどうしてもうまくいかないことがあるので、dll の名前を変えて強制的に静的リンクさせるようにする。(Cf. [MinGW] Link pthread statically [Ubuntu])

$ for i in i686 x86_64; do 
  cd /usr/local/homebrew/Cellar/mingw-w64/6.0.0_2/toolchain-${i}/${i}-w64-mingw32/lib
  for j in libpthread.dll.a libwinpthread.dll.a; do
    mv $j _${j}
  done
done
6. Xcode のプロジェクトを作る

 wxWidgets のサンプルプログラム "Life" をビルドする Xcode プロジェクトを作ってみる。

 Xcode で新規プロジェクトを作成する。"Cocoa App" を選択する。

20190819-1.png

 Storyboards, Document-Based, Core Data, Unit TEST, UI Tests は全部オフにしておく。

20190819-2.png

 Info.plist 以外のファイルは不要なので、削除してゴミ箱に入れる。

20190819-3.png

 wxWidgets の "demos" の中にある "Life" のファイルを、"wxLife" フォルダ(どこでもよいが)にコピーする。

20190819-4.png

 ビルドに必要なファイルを Xcode のファイルリストに加える。

20190819-5.png

 ビルド設定を変更する。やり方をすぐ忘れてしまうのでメモ:ファイルリストの一番上のプロジェクト名を選択して、"Build Settings" を選ぶと、その下にビルド設定が表示される。

20190819-6.png

  • Architectures : Base SDK : Mac OS X 10.6
  • Deployment : macOS Deployment Target : macOS 10.6
  • Linking : Other Linker Flags : -L$(PROJECT_DIR)/../wxWidgets-3.0.3/build-osx/lib -lwx_osx_cocoau-3.0 -lwx_osx_cocoau_gl-3.0 -lwxregexu-3.0 -lwxtiff-3.0 -lwxjpeg-3.0 -lwxpng-3.0 -lz -lpthread -liconv
    # wxWidgets-3.0.3 への相対パスが正しくなるように注意。
  • Search Paths : Header Search Paths : $(PROJECT_DIR)/../wxWidgets-3.0.3/include $(PROJECT_DIR)/../wxWidgets-3.0.3/build-osx/lib/wx/include/osx_cocoa-unicode-static-3.0
  • Search Paths : Library Search Paths : $(PROJECT_DIR)/../wxWidgets-3.0.3/build-osx/lib
  • Apple Clang - Custom Compiler Flags : Other C Flags : -D__WXMAC__ -D__WXOSX__ -D__WXOSX_COCOA__
  • Apple Clang - Language - C++ : C++ Language Dialect : GNU++98 [-std=gnu++98]
  • Apple Clang - Language - C++ : C++ Standard Library : libstdc++ (GNU C++ standard)
    # C++11, libc++ のままだと Mac OS 10.6 SDK ではビルドできない

 "Build Phase" を選び、"Link Binary with Libraries" を開いて、次の5つのフレームワークを加える:Carbon, Cocoa, AudioToolbox, OpenGL, IOKit

20190819-7.png

 これでビルドに成功する。おー動くやん。

20190819-8.png

 実はこのサンプルには Mac 上で画面が正しく更新されない不具合があります。life.cppLifeCanvas::DrawChanged() の終了直前に下の3行を追加する。

#if __WXMAC__
       Refresh();
#endif

 "Puffer Train" を 1500 世代まで進めたところ。

20190819-9.png

7. MinGW 用の Makefile を作る

 makefile.unx をコピーして makefile.mingw とし、次のように修正。


CXX = $(shell wx-config --cxx)

PROGRAM = life.exe       # .exe を追加

OBJECTS = life.o dialogs.o game.o reader.o liferc.o    # $(PROGRAM).o を life.o とする。liferc.o を追加。

# implementation

.SUFFIXES:	.o .cpp

.cpp.o :
	$(CXX) -c `wx-config --cxxflags` -o $@ $<

all:    $(PROGRAM)

$(PROGRAM):	$(OBJECTS)
	$(CXX) -o $(PROGRAM) -static-libgcc -static-libstdc++ $(OBJECTS) `wx-config --libs`
  #  -static-libgcc -static-libstdc++ を追加

#  次の2行を追加
liferc.o : life.rc
	`wx-config --rescomp` -o $@ $<

clean: 
	rm -f *.o $(PROGRAM)

 wxLife のディレクトリに移動する。次のコマンドで life.exe がビルドできる。PATH を指定しているのは、wx-config を呼び出すため。これは、32 bit 版/64 bit 版の wxWidgets をビルドしたディレクトリを指定する。

$ PATH="../../wxWidgets-3.0.0/build-win32:$PATH" make -f makefile.mingw  # 32 bit
$ PATH="../../wxWidgets-3.0.0/build-win:$PATH" make -f makefile.mingw  # 64 bit

 ちゃんと動いております。

20190819-10.png

8. MinGW 上のビルドを Xcode から実行する

 上の Makefile を Xcode から呼び出すには、「ターゲット」を作ればよい。これもすぐ忘れてしまうのでメモ。ターゲットは下の四角のところに表示されているので、ここのポップアップメニューを開いて、"Add Target..." を選ぶ。

20190819-11.png

 ターゲットのタイプは、"Cross Platform" で "External Build System" を選ぶ。

20190819-12.png

 ターゲットの名前を wxLife_win32 などとする。

20190819-13.png

 "Info" で作業ディレクトリとコマンドラインを指定する。コマンドは /usr/bin/env として、PATH を設定してから /usr/bin/make を呼び出すようにする。

  • Build Tool: /usr/bin/env
  • Arguments: PATH=$(PROJECT_DIR)/../wxWidgets-3.0.3/build-win32 /usr/bin/make \-f makefile.mingw
  • Directory: $(PROJECT_DIR)/wxLife

20190819-14.png

 command-B (Build) で 32 bit 版がビルドされます。64 bit 版をビルドするには、もう1つ別のターゲットを作って、PATH の設定を build-win にすればよい。

タグ:Mac wxWidgets
posted by toshinagata at 00:35| 日記

2019年08月18日

Mac OS 10.14 で wxWidgets 開発(その1)

 新 MacBookPro で、wxWidgets の開発環境を立ち上げた。目標は、「Mac OS 10.6 上で実行できる 64 bit アプリを作ること」および、「Windows の 32 bit, 64 bit アプリを両方作ること」。

1. 開発環境の整備

 先日の Alchemusica のビルドの時に済ませていたのだが、ここに書いておく。以前に書いた「wxWidgets のクロスコンパイル (PowerPC 編)」と同じく、XcodeLegacy を使う。

(1) Xcode 10 と Command Line Tool for Xcode 10 をインストールしておく。Mac App Store 経由ではなく、Apple Developer サイト https://developer.apple.com/ の Download → More で探してダウンロードするのがよい。(昔の Xcode をダウンロードするために、いずれこのサイトが必要になる)。ちなみに、Firefox (68.0.1) ではこのページの表示がおかしかった。Safari が必要かもしれない。

20190817-1.png

(2) XcodeLegacy をダウンロード・展開する。

(3) (1) のサイトから Xcode 3.2.6 のインストーラをダウンロードして、XcodeLegacy のフォルダに入れておく。

(4) 次のように実行。今回は、10.6 の SDK だけインストールしておく。

$ cd path/to/xcodelegacy-master
$ chmod +x Xcodelegacy.sh
$ ./Xcodelegacy.sh -osx106 buildpackages
$ sudo ./Xcodelegacy.sh -osx106 install
$ sudo mkdir /Developer
$ sudo ln -sf '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs' /Developer/SDKs

2. mingw-w64 クロスコンパイラ

 Windows アプリを Mac 上でビルドするため、mingw-w64 のクロスコンパイラを導入する。以前に「wxWidgets のクロスコンパイル」で書いた時は、Darwin 用にビルドされたバイナリを使った。しかし、これはかなり古くて、gcc が 4.9 である。最新の mingw-w64 では gcc8 なので、さすがに古すぎるでしょう。

 自前でクロスコンパイラをビルドしてみよう、としばらく頑張ったが、あちこちでつまづいた。結局あきらめて、Homebrew を使うことにした。mingw-w64 のダウンロードページでは MacPorts 版へのリンクが張ってあるが、Homebrew 版もある。ただし、普通に Homebrew を使うと、/usr/local がとっ散らかるので、イレギュラーだが /usr/local/homebrew にインストールすることにした。

ここは考え方が分かれるところ。Homebrew 公式では、「/usr/local にインストールする方がトラブルは少ないよ」と書かれていて、それは確かに一理ある。でも、自分としては、サードパーディのパッケージマネージャーに /usr/local をいじられるのにどうしても抵抗を感じる。結果として mingw-w64 は無事動いたので、当面はこの運用でいくつもり。

$ cd /usr/local
$ sudo mkdir homebrew
$ sudo chown $USER:staff homebrew
$ curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C homebrew
$ export PATH=/usr/local/homebrew/bin:$PATH   # .bash_profile にも入れておく。
$ export HOMEBREW_CACHE=/usr/local/homebrew/cache   #  同上
$ brew install mingw-w64
...

 標準の /usr/local へのインストールだと、バイナリをロードしてくるだけなのだが、非標準のインストールだと、一からビルドするので時間がかかる。それでも1時間かからずに終わった。

 ついでに、ターミナルから Homebrew の使用/不使用を簡単に切り替えられるように、次の関数定義を .bash_profile に入れておいた。

enable_brew() { disable_brew(); export PATH=/usr/local/homebrew/bin:$PATH; }
disable_brew() { export PATH=`echo -n $PATH | awk -v RS=: -v ORS=: '$0 != "/usr/local/homebrew/bin"' | sed 's/:$//'`; }

3. 10.6 対応の gfortran のビルド

 普通の人は関係ないと思うけど、私には gfortran が必要なのです。これも、10.6 で動くバイナリが作れないといけない。ライブラリの依存とかが面倒なことになるので、-isysroot /Developer/SDKs/MacOSX10.6.sdk の条件で gfortran 自体をビルドすることにした。

 以前に gcc 4.7 を fortran 付きでビルドした。今回は、なるべく新しいものを、と思って、まずは gcc 9.1 をビルドしてみたのだが、途中でこんなエラーが出て沈没した。

../../../../gcc-9.1.0/libsanitizer/sanitizer_common/sanitizer_mac.cc: In function ‘bool __sanitizer::GetRandom(void*, __sanitizer::uptr, bool)’:
../../../../gcc-9.1.0/libsanitizer/sanitizer_common/sanitizer_mac.cc:1081:3: error: ‘arc4random_buf’ was not declared in this scope; did you mean ‘arc4random_stir’?
 1081 |   arc4random_buf(buffer, length);
      |   ^~~~~~~~~~~~~~
      |   arc4random_stir

 調べてみると、arc4random_buf() は Mac OS 10.7 以降でしか使えない。そこで、バージョンを1つ下げて gcc 8.3 に切り替えた。次のようにして、無事ビルドできた。

$ sudo mkdir /usr/local/gcc8
$ cd /Developer/SDKs/MacOSX10.6.sdk/usr/local; ln -s /usr/local/gcc8 gcc8
$ cd path/to/gcc8.3
  #  gcc8.3 ディレクトリの中に gmp-5.0.5, mpfr-3.1.2, mpc-1.1.0,
  #  isl-0.21, gcc-8.3.0 を展開してある
$ cd gmp-5.0.5
$ mkdir build; cd build
$ ../configure --prefix=/usr/local/gcc8 --disable-shared --enable-static --with-sysroot=/Developer/SDKs/MacOSX10.6.sdk CFLAGS=-fPIC CXXFLAGS=-fPIC | tee configure.log
$ make -j 2 2>&1 | tee make.log
$ make check | tee makecheck.log
$ sudo make install
$ cd ../../mpfr-3.1.2
$ mkdir build; cd build
$ ../configure --prefix=/usr/local/gcc8 --disable-shared --enable-static --disable-thread-safe --with-sysroot=/Developer/SDKs/MacOSX10.6.sdk CFLAGS=-fPIC CXXFLAGS=-fPIC --with-gmp=/usr/local/gcc8 | tee configure.log
  #  --disable-thread-safe 重要!
$ make -j 2 2>&1 | tee make.log
$ make check | tee makecheck.log
$ sudo make install
$ cd ../../mpc-1.1.0
  #  mpc-0.9 だと --with-sysroot がないので面倒
$ mkdir build; cd build
$ ../configure --prefix=/usr/local/gcc8 --disable-shared --enable-static  --with-sysroot=/Developer/SDKs/MacOSX10.6.sdk CFLAGS=-fPIC CXXFLAGS=-fPIC --with-gmp=/usr/local/gcc8 --with-mpfr=/usr/local/gcc8 | tee configure.log 
$ make -j 2 2>&1 | tee make.log
$ make check | tee makecheck.log
$ sudo make install
$ cd ../../isl-0.21
$ mkdir build; cd build
$ ../configure --prefix=/usr/local/gcc8 --disable-shared --enable-static --with-sysroot=/Developer/SDKs/MacOSX10.6.sdk --with-pic --with-gmp-prefix=/usr/local/gcc8 | tee configure.log 
$ make -j 2 2>&1 | tee make.log
$ make check | tee makecheck.log
$ sudo make install
$ cd ../..
$ mkdir build-gcc; cd build-gcc
$ ../gcc-8.3.0/configure --prefix=/usr/local/gcc8 --with-sysroot=/Developer/SDKs/MacOSX10.6.sdk --with-build-sysroot=/Developer/SDKs/MacOSX10.6.sdk --with-gmp=/usr/local/gcc8 --with-mpfr=/usr/local/gcc8 --with-mpc=/usr/local/gcc8 --disable-nls --disable-tls --disable-multilib --enable-languages=c,c++,fortran --with-pic | tee configure.log
  #  --disable-tls 重要!
$ (date 2>&1; make -j 4 2>&1; date 2>&1) | tee make.log
$ sudo make install

 gfortran のスタティックリンクのため、/usr/local/gcc8/lib/gfortran.spec を修正。

#*lib: -lquadmath -lm %(libgcc) %(liborig)
*lib: -lm %(libgcc) %(liborig)
  #  lquadmath を無条件にリンクするのをやめる

 リンク時には、-static-libgfortran -static-libgcc /usr/local/gcc8/lib/libquadmath.a を指定する。これで、libgfortran.dylib, libquadmath.dylib に依存しないバイナリができる。

 長くなったので、いったん切ります。次は Xcode プロジェクトの設定など。

タグ:Mac wxWidgets
posted by toshinagata at 00:58| 日記

2019年08月13日

CoreAudio: Sound Canvas VA の音(だけ)にノイズが乗る

 新 MacBookPro でいろいろなアプリの動作を検証していて、あれっと思った。Alchemusica で Sound Canvas VA を鳴らして、イヤホンで聞くと、ノイズが乗る。内蔵音源とか LinuxSampler とか、他の音源ではそういうことはない。録音済みの aiff を再生しても問題ない。イヤホンを外して、スピーカーで鳴らすと、正常に鳴っている。「Sound Canvas VA +イヤホン」の組み合わせだけがおかしい。

 いろいろ調査していて、一つ気づいたのがこれ。イヤホン(ヘッドホン端子)への出力は、デフォルトで 48000 Hz になっている。

20190813-1.png

 これを 44100 Hz に変えると、ノイズはなくなった。CoreAudio の内部は基本的に 44100 Hz で動いているので、48000 Hz の場合はどこかでサンプリングレートのミスマッチを起こしている可能性が高い。それにしても、どうして Sound Canvas VA だけ?

 調査にとりかかった。Alchemusica のオーディオ出力は、Audio Settings の Bus 1 〜 Bus 40 の出力をミキサーで混ぜて、それを Output デバイスに送る仕組みになっている。CoreAudio の言葉で言えば、ミキサーは kAudioUnitType_Mixer, kAudioUnitSubType_StereoMixer、出力デバイスは kAudioUnitType_Output, kAudioUnitSubType_DefaultOutput で指定される AudioUnit である。出力デバイスを変更すると、AudioUnitkAudioOutputUnitProperty_CurrentDevice が変更される。この2つの間は、コールバック関数で接続されている。このコールバック関数は、ミキサーからデータを取得して出力デバイスに流すが、オーディオ録音を行う時には同時にファイルへの書き込みも行っている。

 最初に考えたのは、ミキサーの出口が 44100 Hz, 出力デバイスの入り口が 48000 Hz だから、コンバータをかませばいいのでは、という案。しかし、やってみるとこれはうまくいかなかった。ミキサーの先にコンバータをつないで 48000 Hz で出すと、コールバック関数でデータをもらうときに AudioUnitRender() 関数がエラーを吐く。現状でも「Sound Canvas VA 以外」ではちゃんと動いているのだから、これでは一歩後退だ。

 コールバック関数は次のようになっている。これがどう呼ばれるかをもう少し調べてみた。

static OSStatus
sMDAudioRecordProc(void* inRefCon, AudioUnitRenderActionFlags* ioActionFlags, 
  const AudioTimeStamp* inTimeStamp, UInt32 inBusNumber, UInt32 inNumberFrames, 
  AudioBufferList* ioData)
{
    OSStatus err = noErr;
    /*  Render into audio buffer  */
    err = AudioUnitRender(gAudio->mixerUnit, ioActionFlags, inTimeStamp, inBusNumber, inNumberFrames, ioData);
    ...
}

 すると、出力デバイスが 44100 Hz だと inNumberFrames512 であるのに対して、48000 Hz だと 471470 で呼ばれることに気づいた。471/44100 ~ 512/48000 ~ 0.0107 だから、471 または 470 フレームのデータを受け取って、それを内部で 512 フレームに割り直して出力すれば、ちょうど 48000 Hz になる。つまり、サンプリングレートの変換は、出力デバイスの方が自分で面倒を見ていることになる。

 この inNumberFrames は、AudioUnitRender() でミキサーに要求するデータの数でもある。ミキサーはその先で、入力側につながっている AudioUnit に同じ数のデータを要求しているはず。ということは、Sound Canvas VA は、データ数が 512 なら正常にデータを送るが、471 や 470 の場合は正しくデータを送っていないのではないか。要求されるデータ数が2の累乗であることを暗黙に仮定する、というのはいかにもありそうなコーディングスタイルだし、わざわざ 48000 Hz のデバイスをつないでテストしない限り問題なく動作してしまう。

 それじゃ、こちらで回避する方法はあるのか? データの要求数を「キリのよい数」にしておいて、それをバッファに保存しておき、必要な数だけ送り出せばいい。幸い、入力デバイスからのオーディオ入力の実装のためにリングバッファを作ってあったので、このコードを流用することにした。


/* エラー処理は省略してあります */
static OSStatus
sMDAudioRecordProc(void* inRefCon, AudioUnitRenderActionFlags* ioActionFlags, 
  const AudioTimeStamp* inTimeStamp, UInt32 inBusNumber, UInt32 inNumberFrames, 
  AudioBufferList* ioData)
{
    OSStatus err = noErr;
    MDAudioIOStreamInfo *info = (MDAudioIOStreamInfo *)inRefCon;
    MDSampleTime startTime, endTime, renderTime;

    /*  Sample time range to handle during this callback  */
    startTime = inTimeStamp->mSampleTime;
    endTime = startTime + inNumberFrames;
    if (info->firstInputTime < 0) {
        info->firstInputTime = inTimeStamp->mSampleTime;
    }

    /*  Fill the ring buffer until enough data is present in the ring buffer  */
    while ((renderTime = MDRingBufferEndTime(info->ring)) < endTime) {
        AudioTimeStamp timeStamp = {0};
        int i, n;
        timeStamp.mSampleTime = renderTime;
        timeStamp.mRateScalar = inTimeStamp->mRateScalar;
        timeStamp.mFlags = kAudioTimeStampSampleTimeValid | kAudioTimeStampRateScalarValid;
        n = info->bufferSizeFrames;
        for (i = 0; i < info->bufferList->mNumberBuffers; i++)
            info->bufferList->mBuffers[i].mDataByteSize = n * info->ring->bytesPerFrame;
        err = AudioUnitRender(gAudio->mixerUnit, ioActionFlags, inTimeStamp, inBusNumber, n, info->bufferList);
        /*  Write to ring buffer  */
        err = MDRingBufferStore(info->ring, info->bufferList, n, renderTime);
    }
    
    /*  Fill ioData from the ring buffer  */
    err = MDRingBufferFetch(info->ring, ioData, inNumberFrames, startTime, false);
}

 だいぶ苦労したけど、動くようになりました。CoreAudio は難しいねえ。

タグ:Mac Alchemusica
posted by toshinagata at 16:09| 日記

2019年08月12日

MacBookPro 2019 来ました

 MacBookPro 2019 が到着しました。

20190811-1.png

 OS のバージョンが上がるといろいろ不具合が生じるので、今はその不具合を検証しているところ。今のところ常用しているソフトウェアの中では、Keynote に若干問題がありそう。これまで Keynote '09 (5.0) を使っていたのだが、プリインストールの Keynote 8.1 に移行する。ところが、ちょこちょこ仕様が変わっていたりするんだよな。いろいろチェックが必要。

追記。仕事で使っている他の Mac がまだ El Capitan なので、Keynote 8 が使えない。Mojave に Keynote 5 ってインストールできるのか? と試してみたところ、少し動作がおかしいところはあるが、一応動くみたい。ただし、32 bit アプリなので、他の Mac が Catalina に移行したらアウト。その時は腹をくくって Keynote 8 に移行するしかない。または PowerPoint に鞍替え?? うーん…

 あと、Paper2 がダメみたい。アプリケーションアイコンに×印がついて、立ち上がりもしない。これはどういうことだろう? 手持ちのアプリケーションでは、他に VirtualBox がこうなっていた。Paper2 については、Paper3 がリリースされた時から少し雲行きが怪しくなっていた(異様に使いにくくなっていた)ので、代替品を探す必要があるかなと思っている。幸い、内部情報は XML でエキスポートできるみたいだし。

 他にもいろいろ不具合点は出てきそう。おいおい検証していく。

タグ:Mac
posted by toshinagata at 12:48| 日記

2019年08月02日

映画「アルキメデスの大戦」

 「アルキメデスの大戦」、見てきました。「数学で戦争を止めようとした」男の話、だと?

20190802-1.jpg

 「帝国海軍を象徴する大戦艦」の建造を止めさせるため、山本五十六(舘ひろし)が抜擢したのが、軍隊嫌いの天才数学者、櫂直(菅田将暉)。櫂は、予想通りの妨害や嫌がらせに辟易しながらも、自分の責務を全うするために奔走する。新造艦を決定する会議で長弁舌をふるうシーンが圧巻、と予告されていたが、その後にもっとすごいシーンが出てきた。田中泯が菅田将暉を激賞していたのはこのシーンのことなんだろうな。これを見るだけでも、入場料を払った値打ちが十分にある。

 この映画は、基本的には「櫂直(菅田将暉)を愛でる」ためのものだと思った。まず、この男は「計測する」ことにひどく執着する。普通の人(田中正二郎=柄本佑)に対して「美しいものを測りたいと思わないのか? 君は変わっているね」と言ってしまう、コミカルな面もある。一晩で造船技術に関する本を読破して、設計図面を描けるレベルになるという、超人っぷり。

 ただ、数学者としての才能を見せる場面は見当たらなかったな。櫂はアメリカ留学を断念して山本に協力するのだが、プリンストンには行かなくて正解だったんじゃないか、と思わなくもない。(日本では大天才ともてはやされていた人がアメリカやヨーロッパに渡って、実は凡庸な才能しかなかったことに気づいて悩む、というのは、この当時よくあった話でしょう)。「計算がやたら速い」という描写はあるけど、単純な加減乗除の計算と数学の才能は別物だからね。数学者らしい場面は、いよいよ切羽詰まった場面で、既存のデータを近似する数式を導き出すシーンぐらいか。あの場面は「2階の微分方程式が…」とか独り言を言いながら式を書き散らしていたから、数学監修の人が実際に導出した式を使っているのだろう。

 原作の三田紀房さんは、本作を描くきっかけの一つが、新国立競技場の総工費が膨れ上がって批判が高まり、白紙撤回されたことだったと述懐している。そういう目で見ると、セコい裏工作を仕掛けている嶋田繁太郎(橋爪功)が森喜朗元総理と重なって見えてきたりもします。

タグ:映画
posted by toshinagata at 21:52| 日記

2019年07月27日

Alchemusica 0.8.0 公開

 Alchemusica の新バージョン 0.8.0 を公開しました。0.7.0 からいろいろ変えた気になってたけど、svn log をまとめてみたら、結局新しい機能はオーディオ設定をエキスポートできるようにしただけだった。

20190725-1.png

 LinuxSampler と内蔵エフェクトを使い、その設定をエキスポートするやり方を書いてみました。→「Alchemusica: LinuxSampler, 内蔵エフェクトを使う

 曲は矢代秋雄のピアノ協奏曲より第1楽章。SC-88 で作成したピアノパートをそのまま LinuxSampler/Bosendorfer で鳴らしているので、ちょっとバランスの悪いところがありますね。冒頭はもう少し静かに始めないといかんかったかな。

posted by toshinagata at 00:38| 日記

2019年07月22日

Switch インタビュー「舘野泉×中村桂子」

 NHK Eテレの Switch インタビュー、「左手のピアニスト」舘野さんと「生命誌研究者」中村桂子先生。お二人とも今年83歳ですか。舘野さん、少し話すのが不自由そうで、さすがにお年を感じさせる。それでも、ピアノの前に座れば、ピアノ協奏曲を一晩で二曲こなす体力があるんですね。

 今回は、中村先生がお相手ということもあって、しきりに「生きている」というキーワードが出てきた。ピアノを弾いていると「生きている」と実感する、音楽が「生きている」、云々。

 バッハ/ブラームスのシャコンヌのくだりが面白かった。舘野さんは、脳出血からの復帰コンサートに向けて、この曲をさらい始めたけど、どうにもつまらない。「こんな風に、音が一つしかないわけですよ、今まで両手でたくさん音を鳴らしていたのに…」と言いながら、曲の一節を弾いて見せるんだけど、中村先生には「すてきな音楽」にしか聞こえない。そりゃそうだよね、目の前で舘野さんがバッハを弾いて、それがつまらなく聞こえるはずがない。舘野さんは「つまらなく」弾いてたつもりなんだろうけど。ところが、2ヶ月ぐらいたったある時、音楽が「生き始める」。この感覚、自分で音楽をやる人なら、きっとわかるだろう。ただの音の並びだったものが、ある時から「生きたもの」になって、語り始める。

 こんな風に、「音楽が形作られていく過程」って、なかなか見せてはもらえない。そういう意味で、とても貴重な話を聞かせてもらった。そういえば、ずっと以前に BS でやっていた舘野さんの特集番組では、間宮芳生さんに「風のしるし」の作曲を委嘱したときのやりとりも紹介されていた。あれも面白かったなあ。

 中村先生はとても気品のある話し方で、舘野さんの話をうまく引き出しておられた。後半は中村先生が主役になって生命誌の話…になるはずなのだけど、そっちでもなんだか舘野さんが主役になっちゃってましたね。中村先生の話をもう少し聞きたかった気もする。まあしかし、「ひどく専門性の高い話(遺伝情報がどうとかこうとか)」か「誰でも知ってそうな話」の二択になってしまうのかもしれず、舘野さんとの組み合わせでは中村先生のお仕事の魅力はあまり生きてこないのかもしれないな。

 そうは言いつつも、ゆったりとした時間が流れる、いいインタビューでした。楽しかった。

タグ:音楽 科学
posted by toshinagata at 21:52| 日記

2019年07月12日

続・Mac の更新を検討中

 先日の「Mac の更新を検討中」から、ぐずぐずしている間に MacBook Pro が全モデルアップデートされてしまいました。なんとまあ。

MacBook Pro (2017)
Touch Bar なし
MacBook Pro (2018)
Touch Bar あり
MacBook Pro (2019)
Touch Bar あり
MacBook Pro (2019)
Touch Bar あり
画面解像度 2560x1600 2560x1600 2560x1600 2560x1600
CPU 第7世代
2.3GHzデュアル
Intel Core i5
第8世代
2.3GHzクアッド
Intel Core i5
第8世代
1.4GHzデュアル
Intel Core i5
第8世代
2.4GHzクアッド
Intel Core i5
メモリ 2,133MHz LPDDR3 2,133MHz LPDDR3 2,133MHz LPDDR3 2,133MHz LPDDR3
グラフィック Intel Iris Plus Graphics 640 Intel Iris Plus Graphics 655 Intel Iris Plus Graphics 645 Intel Iris Plus Graphics 655
ポート Thunderbolt3 x2 Thunderbolt3 x4 Thunderbolt3 x2 Thunderbolt3 x4
税込価格 225,504円 262,224円 220,104円 ***,***円

Apple Store が混んでいるのか、2.4GHz のカスタマイズ価格を調べようと思ったのに全然つながらん…

 上位機種とはクロックが大きく違うわけだけど、このあたりがどうなんだろうか。こちらの記事「MacBook Pro(2019)13インチエントリーモデルは予想以上の性能!新旧モデルのベンチマークや大幅高速となった動画処理などパフォーマンス比較」によると、ベンチマークの数字だとシングルコアで 7%、マルチコアで 11% 程度上位機種が速い、という結果が出ている。その程度の差なら、別にエントリーモデルでも十分か。むやみに性能が高いと、発熱もすごいしな。これで決まりかな。

タグ:Mac
posted by toshinagata at 23:32| 日記

2019年07月07日

クラシック音楽館:平尾貴四男、矢代秋雄

 クラシック音楽館で邦人作品を取り上げていたので、見ました。平尾貴四男の「砧」と、矢代秋雄のピアノ協奏曲。指揮は山田和樹。

 「砧」は曲の存在は知ってたけど、聴いたのは初めて。戦時中 (1942) に書かれたというのが意外なぐらい、洗練された印象を受けた。

 矢代秋雄の協奏曲は、河村尚子の独奏。この人の演奏は初めて聴いたのだけど、なんかすごく力の入った感じの、独特のスタイルで演奏する人ですね。第一・三楽章で出てくるカデンツァ風の部分、音が重い。もっと歯切れよく叩きつける様に弾くところだと思っていたので、新鮮だった。

20190707-1.png

 一番感銘を受けたのは第一楽章の第二主題のところで、和音の一つ一つにそれぞれ表情がある。ぞくぞくする。

20190707-2.png

 第二楽章と第三楽章は、なんかもうちょっとタメがあってもいいような気がした。次々と楽想が溢れ出てくる感じで、それはそれでいいのかもしれないけど、聴いてる方が忙しいんだよね。そういう曲だ、と言ってしまえばそれまでなんだけど。

タグ:音楽
posted by toshinagata at 23:28| 日記
email.png
Powered by さくらのブログ