mieki256's diary



2018/12/01() [n年前の日記]

#1 [tic80] TIC-80のサイトに作成したプログラムをアップロードしてみたり

_TIC-80公式サイト に、今まで作成したプログラムを試しにアップロードしてみたり。 _Time Tripper: TIC-80で簡単なプログラムを作ってみる の後半が参考になった。ありがたや。

以下で見れるはず…。たぶん。

_Play NEWTOTOTONE in TIC-80
_Play WCQ NO.6 in TIC-80
_Play WAVETEST2 in TIC-80

公式サイトにアップロードしたことで、ローカルで TIC-80 を実行した際に、自分の書いたソレも実行しやすくなった。 と進んでいけば、ネット経由でダウンロード・実行することもできる。はず。たぶん。

アカウントの取得。 :

自作の cart(.tic) をアップロードするためには、公式サイト上でアカウントを取得する必要がある。一応手順をメモ。

_TIC-80公式サイト の右上に「Sign In」というリンクがあるのでクリック。ログインページ(?)が開く。

既にアカウントを持ってる場合は、ユーザー名とパスワードを打ち込み、「私はロボットではありません」にチェックを入れて、「Sign in」ボタンをクリックすればアカウント管理ページに入れる。

今回は新規にアカウントを取りたいので、下のほうにある「Create an account.」のリンクをクリック。

ユーザー名、メールアドレス、パスワードを入力するページが開くので、それぞれ打ち込んで「Create an account」をクリックすればアカウントを取得できる。ちなみに、巷のWebサービスではありがちな、登録完了等のメールは送られてこなかった。

アカウント管理画面では、自分のアイコン(Avatar)をドットを打って設定できる模様。

cartのアップロード。 :

cart(.tic)をアップロードする際は、アカウント管理ページの、左下の「Add game...」をクリック。Add game のページが開く。

手元の .tic ファイルを、参照ボタンを押して選ぶか、エクスプローラ等から参照ボタンのあたりにドラッグアンドドロップして渡してやる。

カテゴリーの指定は、以下から選ぶ。
  • Games (ゲーム)
  • Demos (デモ)
  • Tools (ツール)
  • Music (音楽)
  • WIP (作業中)

「Leave a text for the game...」と表示されてる入力欄に、cart(.tic)の簡単な説明を…打ち込みたければ打ち込んでもいい。おそらく英語で書かないと海外の閲覧者が読めなくてで困るだろうけど…。自分は英語が分からんので何も打ち込まなかった。

内容に間違いが無ければ、左下の「Add game」をクリックすればアップロードができる。

どうやら、cart(.tic)のソースコードの、最初のあたりのコメント部分が読み取られて、ページタイトルその他に反映されるっぽい。そのあたりも、日本語文字列は使わずに、英数字で打ち込んでおいたほうがヨサゲ。
-- title:  (ゲームタイトル)
-- author: (作者名)
-- desc:   (簡単な説明)
-- script: lua

利用の仕方。 :

上のほうでちょこっとメモしてあるけど、再度メモ。

ローカル環境で TIC-80 を起動すれば、surfコマンドを使って、公式サイト上のプログラムをダウンロードして試すことができる。

TIC-80が入力待ちの状態で surf と打って Enterキーを叩けばリストが表示されるので…。その中の「[tic.computer/play]」を選んで決定キー(Zキー)を叩くと、公式サイトにアクセス・情報を取得してPlayページのプログラム一覧が表示される。試してみたいプログラムを選んで決定キーを叩けば、プログラムのダウンロードと実行ができる。

プログラム実行中にESCキーを叩けばメニューが表示されて、CLOSE GAME を選べばプログラムを終了できる。surfコマンドの画面に戻ってくるので、更にESCキーを叩けば、surfコマンド画面からも抜ける。

#2 [zatta] 4K/8Kってどうなんだろうな

とりとめのない思考メモ。

なんでも、NHKや民放が4K/8Kの新しいチャンネルを作ったらしくて。ブラタモリを見ようとしてNHKにチャンネルを変えたら特番が流れてて、あらそうなんだ、みたいな。

どうなんだろうな。4K/8Kって…。「そんな放送は要らない」という意見も見かけるけど…。

考えてみれば、日本のTV放送って、 という経緯があるわけで。それを考えると…この流れも延長線上としてアリなのかな。今の時代に「カラー放送なんて要らない」「白黒放送で十分だ」と言ってたら只の馬鹿だけど、「4K/8K放送なんて要らない」「HD放送で十分だ」という意見は、さて、数十年後にどう思われるのだろうか。「妥当な意見だったね」と思われるのか、それとも、「想像が足りてなかったね」と思われるのか。どっちなんだろうな…。

とはいえ、白黒放送の信号にカラー信号を追加したソレを思い返すと、4K/8Kの、アンテナもケーブルも全部交換しないと見れません、というソレはどうなんだろうという気もする。解決策が富豪的というか、そこに若干の安易さを…。いやまあ、圧縮技術や帯域の割り当てのアレコレを考えると、これでも努力したほうだろうけど。東京オリンピックに間に合わせようとしてちょっと無理してないか。みたいなところも。それとも、今回の交換作業で、将来の規格にも対応できる予定があったりするのだろうか。「次回? その時はまた全交換を」なんて言い出したりしないだろうな…。

「大画面じゃないと意味が無い」という意見もどうなんだろうなと。

例えば、ハイエンド? ハイレゾ? オーディオの世界では、加齢で聴力を失いつつある世代が、あーだこーだと自論を主張してソレしてたりするけれど。センサとしては目より耳のほうが雑なスペックだろうに、音の世界では、より高解像度なデータを求める流れも実際にあるわけで。 *1

映像も同じじゃないのかな、と。1ドットを認知できるかどうかではなく、全体としてなんとなく高精細と感じる、みたいな判定だってアリなのではないか…。自分達はCDを聞く際に、16bit、44.1KHz の解像度を正確に捉えつつ聞いてるわけではないけれど、だったら映像も同じじゃないかしらん。CDのスペックじゃ足りない、という主張をしながら、HDのスペックで十分、と主張してたら、それはなんだかおかしい話だなと…。

もっとも、若い世代は、CDスペックより落ちるMP3で音楽を聴いていて、しかもそれで結構満足してるわけだから、それを考えたら映像だって…という主張も成り立つのかな。更に、楽曲データは、記録メディアよりマスタリング技術のほうが影響大、とも聞くし。それはおそらく映像に対しても同じことが言えそう。

何にせよ、安くなってくれないと自分は買えないので…。普及と低価格化が進んでほしいなと…。

全然関係ないけど、先日たまたま見てた何かの番組で、芸人さんが「4K/8Kをやたら宣伝してるけど、この後すぐに16Kが出てきたりしませんか?」という質問をしていて、宣伝部隊が何も答えられなかった場面が気になった。16K…もう用意されているのか…。まあ、ハイビジョンが普及するのに何年かかったかを考慮すれば、16Kの普及なんて随分先だろうけど…。
*1: うっかり「目より耳のほうが」と書いてしまったけれど、「目より耳のほうがスペックが高い」という見方・主張だってありそうな気もする…。あるいは、「視覚と聴覚を比べること自体無理がある」という意見もありそうな…。このあたり、どういう見方が適切なのかな。

#3 [nitijyou] 日記をアップロード

2018/11/23までアップロードしたままの状態だったので、溜まってた分をアップロード。

2018/12/02() [n年前の日記]

#1 [tic80] FM音源について調べていたり

TIC-80の波形メモリ音源に対して、FM音源の仕組みで波形を生成して書き込めないかと実験しているところ。

自分で打ち込んだ式が何かを間違えてるらしくて、巷の解説ページで紹介されてる波形には今一つ近づかない。どこを間違えているのやら…。

2018/12/03(月) [n年前の日記]

#1 [tic80] FM音源っぽい波形を作ろうとして実験中

TIC-80の波形メモリに対して、FM音源っぽい波形を生成するソレを試しているところ。

式はそれっぽくなったようで、それらしい波形が作れるようになった。しかし予想通り、一周期分の波形の、最初と最後が繋がっていないので、急激な音量変化=高周波っぽい音(ノイズ?)が含まれてしまう。何かインチキをして、繋がった感じの波形に加工したほうがいいのかもしれないなと。

フーリエ解析をする際は、窓関数なるものを経由させて、サンプルデータの最初と終わりの不連続部分を打ち消すようにするらしい。その窓関数とやらを使ったらどうだろう、と思って関連ページを眺めていたり。

#2 [pc] マウスの調子が悪くなったらケーブルを抜いてボタン連打

メインPCにUSB接続している有線マウスの調子が悪いことに気づいたり。カーソル移動が妙に遅い。

ふと、ワイヤレスマウスの調子が悪い時に試してみると改善するかもしれない策、を思い出したり。電池を抜いて左ボタンや右ボタンを10秒程度連打すると、静電気(?が中に溜まって誤動作してる際には電気が抜けて改善するのだとか。ホントかどうかは知らないけれど。

自分の環境は有線接続だけど、試しにやってみた。ケーブルを抜いて、左ボタン〜第5ボタンを10秒ほどカチカチと連打。

繋ぎ直したら、マウスカーソルの動きが以前と同じ操作感覚になった。有線接続のマウスでも効果があるのか…。知らなかった…。

2018/12/04(火) [n年前の日記]

#1 [tic80] TIC-80上でFM音源っぽい波形を生成してみるテスト

TIC-80上でFM音源っぽい波形を生成するソレをまだ試していたり。一周期分の波形の最初と最後がずれてしまうために高周波成分が混じってしまう問題について、どう対処すればいいのか…。

窓関数を経由するのはどうか、などと考えていたけれど、要は最初と最後が繋がってるように見えればなんでもいいのだよなと思い直して。求めた一周期分の波形の、その後に続くはずの波形を一旦仮で求めておいて、それを波形の最初のあたりに合成してやれば繋がってるっぽい波形になるのでは、と。例えば FL Studio でループ素材を作ろうとするとそんな感じの処理が行われる ―― 出力設定で選択範囲後に鳴るはずの音(ディレイやリバーブ等)を出力波形の前方にうっすら重ねる事が可能なのだけど、それと同じことをやればいいのでは、と思いついたわけで。

実装してみたところ、高周波の「ビー」というノイズは聞こえなくなった。これでも充分、かもしれない。

もっとも、この処理を入れたことで、正確なFM音源っぽい波形とは異なった波形になっているはずだけど…。そもそも、音量4bit、一周期32個の波形メモリのスペックで、そのあたり気にしてもさほど意味は無いだろうし…。要するに、人間にとってどういう音が実際に聞こえるかが大事なのだから、これでもいいんじゃないかな…。

ということで、こんな感じになった。ブラウザ上で動作させるなら以下。

_wavetestfm.tic.html
cart(.tic)とソースは以下。

_ticファイル : wavetestfm_20181205.zip
_ソース : wavetestfm.lua


FM音源の仕組みについては、以下のページが参考になった。ありがたや。

_音とFM音源の軽い紹介と今昔物語 - Qiita
_FM音源を学ぶ(1) | Scene Research Station
_FM音源を学ぶ(2) | Scene Research Station

もしかして、sin波だけじゃなくて、矩形波、ノコギリ波、三角波も使えるようにしたほうがいいのだろうか…。あるいは、FM音源には色々なアルゴリズムがあるらしいけど、そのあたりも実装したら聞こえ方が変わったりするのだろうか。でも、波形メモリのスペックからして、そんなに違いは出てこないのでは、という予感も。

妄想。 :

TIC-80 は1/60単位で波形メモリを書き換えられる、といった記述が公式Wikiに載ってたような気もするのだけど。だとしたら…。

例えば、適当なwavファイルを、1/60単位でバラバラにして、そのバラバラにした波形をどうにか一周期分の波形データに加工して、1/60毎に波形メモリを書き換えて差し替えていけば、それっぽく音が鳴ったりしないか…。「ベラボー!」とか「ミッソ」とか…。

問題は、1/60単位≒16.667ms分の波形データから、どうやって一周期分を ―― 音量4bit、32個のサンプルデータに収められそうな波形を取得するか…。

ピッチを求めて、そのピッチで波形を分割して、分割した波形群を全部合成して、4bit32個に変換、とか? そんな雑な処理でも、それらしく聞こえてくれるのだろうか。それとも、聞けたものではない波形になるのだろうか。どうなんだろう。

PCM音源が当たり前の時代に何をやっているのか、という気もするけれど、今の技術を駆使すれば当時のスペックも更に活用できたりするのでは、という興味もちょっぴり。

2018/12/05追記。 :

一部バグってたので、修正して再アップロード。

2018/12/05(水) [n年前の日記]

#1 [python] Pythonでwavファイルに対して何か処理

wavファイルを何かしらを使って読み込んで1/60秒単位で分割、といった感じの処理をしてみたいなと。Pythonを使ってそういう処理はできないだろうか。

ググってみたら、どうやら Pydub なるモジュールがあるらしい。

_【Python/pydub】音声ファイル処理 | アルゴリズム雑記
_【Python】Pydubのインストール | アルゴリズム雑記
_[Python] PydubでAudioファイルを処理する - Qiita
_pydubを使って音楽を鳴らす - Python - TIL

なんだか簡単に使えそうなのでコレを使わせてもらおう…。環境はWindows10 x64 + Python 2.7.15。

Pydubのインストール。 :

インストールは pip で済んだ。ありがたや。
pip install pydub

ffmpeg.exe も、Pythonスクリプトと同じ場所に一応コピーして置いておいた。

_Builds - Zeranoe FFmpeg

読み込んで鳴らす。 :

解説ページを参考にして、wavファイルを読み込んで、情報を表示して、鳴らすスクリプトを書いた。

_read_and_play.py
from pydub import AudioSegment
from pydub.playback import play

sound = AudioSegment.from_wav("hello.wav")

print("Channel : %d" % sound.channels)  # 1:mono, 2:stereo
print("Sampling rate : %f Hz" % sound.frame_rate)
print("Duration : %f sec" % sound.duration_seconds)

play(sound)
音が鳴ってくれた。

余談。wavの入手元。 :

実験に使う wavファイルは、Freesound から入手させてもらった。アカウントを取得しないとダウンロードできないのがアレだけど…。

_Freesound
_無料で使える音源ファイルが山のようにダウンロードできる「Freesound」 - GIGAZINE

分割。 :

wav を読み込んで、NumPy配列とやらにして、1/60秒単位で分割するスクリプトを書いてみた。matplotlib とやらを使ってグラフ表示もする。

_【Python/pydub】mp3、wavのデータをNumPy配列に変換 | アルゴリズム雑記
_matplotlib入門 - りんごがでている

_divide_wav.py
from pydub import AudioSegment
from pydub.playback import play
import numpy as np
import matplotlib.pyplot as plt

infile = "hello.wav"

sound = AudioSegment.from_wav(infile)
# play(sound)

data = np.array(sound.get_array_of_samples())
x = data[::sound.channels]

rate = sound.frame_rate
frm = rate / 60
sample_len = len(x)

print("Input file : %s" % infile)
print("Channel : %d" % sound.channels)
print("Sampling rate : %d Hz" % rate)
print("1 Frame length : %f point" % frm)
print("Duration : %f msec" % len(sound))
print("Sample length : %f point" % sample_len)

dt = []
for i in range(0,sample_len,frm):
    dt.append(x[i:i+frm])

if True:
    # plt.plot(x[::1])
    row = 10
    for i in range(row):
        plt.subplot(row, 1, i + 1)
        plt.plot(dt[i])
        plt.grid()
    plt.show()

こんな感じの結果が得られた。
> python divide_wav.py
Input file : hello.wav
Channel : 1
Sampling rate : 48000 Hz
1 Frame length : 800.000000 point
Duration : 511.000000 msec
Sample length : 24514.000000 point

divide_wav_py_ss01.png

分割できてるっぽい。

後は、この1/60単位の波形から、TIC-80の波形メモリ用データをどうにかでっちあげれば…。しかし、一周期分らしきデータを取得するのって、どうやればいいんだ…。

2018/12/06(木) [n年前の日記]

#1 [python] Pythonでwavファイルに対して何か処理その2

Python + Pydub で wavファイルを読み込んで分割するところまではできたけど、その分割したデータをどうやって TIC-80用に加工するか、というところで悩んでいたり。

フーリエ解析。 :

とりあえず、以下を参考にしてフーリエ解析とやらをするところまではできたのだけど。環境は Windows10 x64 ; Python 2.7.15 + Pydub 0.23.0 + Numpy 1.15.4。

_高速フーリエ変換(FFT) - 人工知能に関する断創録

_fft_test.py
import os
import sys
from pydub import AudioSegment
# from pydub.playback import play
import numpy as np
import matplotlib.pyplot as plt

draw_wave_enable = 0
window_enable = 0


def fft(dt, rate):
    """FFT."""
    specs = []
    freqlists = []
    ampspecs = []
    phasespecs = []

    for d in dt:
        n = len(d)

        if window_enable:
            # use Hamming window
            wdw = np.hamming(n)  # Hamming Window
            windowedData = wdw * d
            spec = np.fft.fft(windowedData)  # FFT
        else:
            # not use window
            spec = np.fft.fft(d)  # FFT

        freqlist = np.fft.fftfreq(n, d=1.0 / rate)
        ampspec = [np.sqrt(c.real ** 2 + c.imag ** 2) for c in spec]
        phasespec = [np.arctan2(int(c.imag), int(c.real)) for c in spec]

        specs.append(spec)
        freqlists.append(freqlist)
        ampspecs.append(ampspec)
        phasespecs.append(phasespec)

    return specs, freqlists, ampspecs, phasespecs


def draw_fft(ampspecs, freqlists, rate, iadd):
    """Draw FFT."""
    row = 8
    for i in range(row):
        plt.subplot(row, 1, i + 1)
        plt.plot(freqlists[iadd + i], ampspecs[iadd + i])
        plt.axis([0, rate / 2, 0, 100])
        plt.xlabel("[Hz]")
        plt.ylabel("amp spec")
        plt.grid()
    plt.show()


def draw_wave(dt, iadd):
    row = 8
    for i in range(row):
        plt.subplot(row, 1, i + 1)
        plt.plot(dt[iadd + i])
        plt.ylim(ymax=1.0)
        plt.grid()
    plt.show()


def main():
    """Main."""
    if len(sys.argv) != 2:
        print("Usage: python %s WAV_filename" % os.path.basename(__file__))
        sys.exit()

    infile = sys.argv[1]
    sound = AudioSegment.from_wav(infile)  # read wave file
    # play(sound)

    data = np.array(sound.get_array_of_samples())
    x = data[::sound.channels]  # get mono channel

    # normlize
    x = (x - x.min()).astype(float) / (x.max() - x.min()).astype(float)

    rate = sound.frame_rate
    sample_len = len(x)
    frm = rate / 60
    n = sample_len / frm

    print("-- Input file : %s" % infile)
    print("-- Channel : %d" % sound.channels)
    print("-- Sampling rate : %d Hz" % rate)
    print("-- Duration : %f msec" % len(sound))
    print("-- Sample length : %d point" % sample_len)
    print("-- 1 Frame length : %d point" % frm)
    print("-- n : %d" % n)

    # divide
    dt = []
    for i in range(0, sample_len, frm):
        dt.append(x[i:i + frm])

    if draw_wave_enable:
        # draw wave
        draw_wave(dt, 0)
    else:
        # FFT
        specs, freqlists, ampspecs, phasespecs = fft(dt, rate)
        draw_fft(ampspecs, freqlists, rate, 0)


if __name__ == "__main__":
    main()

> python fft_test.py hello.wav
-- Input file : hello.wav
-- Channel : 1
-- Sampling rate : 48000 Hz
-- Duration : 511.000000 msec
-- Sample length : 24514 point
-- 1 Frame length : 800 point
-- n : 30

fft_test_py_ss01.png

しかし、これができても…。任意の周波数が複数鳴らせるサウンド仕様だったら使い道があるかもしれんけど、TIC-80はそういうサウンド仕様じゃないし…。

一定個数でデータを抜き出してみたり。 :

とりあえず、1/60秒単位で分割したwavデータから、TIC-80 の波形メモリのスペックに合わせて32ポイントずつデータを取り出して、その32ポイントのデータを元の長さに並べ直してから鳴らしてみたり。

_divide_composite.py
import os
import sys
from pydub import AudioSegment
from pydub.playback import play
import numpy as np
import matplotlib.pyplot as plt

ave_enable = 0
draw_wave_enable = 0
play_sound = 1
print_table = 0
export_wav = 1


def draw_wave(dt):
    row = 8
    for i in range(row):
        plt.subplot(row, 1, i + 1)
        plt.plot(dt[i])
        plt.grid()
    plt.show()


def composie(dt):
    ndt = []
    nwave = []
    for src in dt:
        n = len(src) / 32
        nd = np.array([0.0] * 32)
        nn = 0

        if ave_enable:
            # get average value
            for i in range(0, len(src), 32):
                for j in range(32):
                    if i + j < len(src):
                        nd[j] += src[i + j]
                nn += 1
            nd = nd / nn
        else:
            # get 32point data only
            for j in range(32):
                if j < len(src):
                    nd[j] += src[j]
            nd[0] = 0.50 * nd[0] + 0.50 * src[32]
            nd[1] = 0.75 * nd[1] + 0.25 * src[33]
            # nd[0] = 0.25 * nd[0] + 0.75 * src[32]
            # nd[1] = 0.50 * nd[1] + 0.50 * src[33]
            # nd[2] = 0.75 * nd[2] + 0.25 * src[34]
            nn += 1

        ndt.append(nd)

        dd = np.array([])
        for i in range(n):
            dd = np.append(dd, nd)
        nwave.append(dd)
    return ndt, nwave


def get_sound_from_numpy_arrays(dt, rate):
    dt = dt.astype("int16")
    # print("min = %f , max = %f" % (dt.min(), dt.max()))
    sound = AudioSegment(
        dt.tobytes(),
        sample_width=2,  # 2 byte (16 bit) samples
        frame_rate=rate,  # sampling rate
        channels=1  # mono
    )
    return sound


def main():
    """Main."""
    if len(sys.argv) != 2:
        print("Usage: python %s WAV_filename" % os.path.basename(__file__))
        sys.exit()

    infile = sys.argv[1]
    sound = AudioSegment.from_wav(infile)  # read wave file

    data = np.array(sound.get_array_of_samples())
    src = data[::sound.channels]  # get mono channel

    # normlize
    src = (src - src.min()).astype(float) / (src.max() - src.min()).astype(float)

    rate = sound.frame_rate
    frm = rate / 60
    sample_len = len(src)

    print("-- Input file : %s" % infile)
    print("-- Channel : %d" % sound.channels)
    print("-- Sampling rate : %d Hz" % rate)
    print("-- 1 Frame length : %f point" % frm)
    print("-- Duration : %f msec" % len(sound))
    print("-- Sample length : %f point" % sample_len)
    print("-- n : %d" % (sample_len / frm))

    # divide
    dt = []
    for i in range(0, sample_len, frm):
        dt.append(src[i:i + frm])

    ndt, nwave = composie(dt)

    # draw graph
    if draw_wave_enable:
        iadd = 0
        row = 10
        for i in range(0, row, 2):
            plt.subplot(row, 1, i + 1)
            plt.plot(dt[iadd + (i / 2)])
            plt.ylim(ymax=1.0)
            plt.grid()
            plt.subplot(row, 1, i + 2)
            plt.plot(nwave[iadd + (i / 2)])
            plt.ylim(ymax=1.0)
            plt.grid()
        plt.show()

    nw = np.array([])
    for d in nwave:
        nw = np.append(nw, d)

    org_src = (src - 0.5) * 0x0ffff
    org_sound = get_sound_from_numpy_arrays(org_src, rate)

    nww = ((nw - 0.5) * 0x0f).astype("int16") * 0x0fff
    new_sound = get_sound_from_numpy_arrays(nww, rate)

    if play_sound:
        # play(sound)
        play(org_sound)
        play(new_sound)

    if export_wav:
        fn = "_output.wav"
        new_sound.export(fn, format="wav")
        print("-- output : %s" % fn)

    if print_table:
        print("tbl={")
        for src in ndt:
            d = (src * 0x0f).astype("int16")
            # print("min,max=%d,%d" % (d.min(), d.max()))
            # print(d)
            s = " {"
            for i in range(0, 32, 2):
                v = ((d[i + 1] & 0x0f) << 4) | (d[i] & 0x0f)
                if i < 30:
                    s += "0x%02x," % v
                else:
                    s += "0x%02x" % v
            s += "},"
            print(s)
        print("}")


if __name__ == "__main__":
    main()

しかし…これはちょっと聞けたものじゃない…。


_hello_9600hz.wav


_hello_9600hz_output.wav


_crt_ooo_13440hz.wav


_crt_ooo_13440hz_output.wav

最初は、32個 x n個のデータを全部加算してから n で割って波形を求めてたけど、それだと聞けたものじゃなく。単に一ヶ所取り出しただけのほうがまだマシかもしれないなと…。しかしそれでも、この状態…。

以下は、元波形、加工後波形、元波形、加工後波形…の順で並べたもの。

crt_ooo_13440hz_output_ss01.png

こうして見ると、波形はそんなに違っていない…とも言えないか。結構違うな…。何にせよ、この方法ではそれらしい音にならないな…。

2018/12/07(金) [n年前の日記]

#1 [pc][windows] 音声分析用ツール Praat を試用中

音声データの分析に使える、Praat というフリーソフトがあるらしいと知り、Windows10 x64上でインストールして使い方を確認しているところ。

_Praat - Wikipedia
_Praat: doing Phonetics by Computer
_Praat入門 - Akira Utsugi's web site (宇都木昭研究室)
_Praat 簡易マニュアル

wavファイルを読み込んで、ピッチ、フォルマント、スペクトラム等を検出することができるっぽい。

式を打ち込んでsin波形その他を作ったりすることもできるし、なんだか色んな事ができるようだなと…。

2018/12/08() [n年前の日記]

#1 [pc] コモドール64のSID音源について少し調べてたり

昔のPCでは音を鳴らす際にこういうテクニックを使っていたのです、てな話がどこかに無いかなとググっていたら、 _コモドール64(C64)_SID音源 に辿り着き。関連情報を眺めていたり。

C64版 TURBO OutRun ではサンプリング音まで鳴らしてたという話が気になって動画を探したら、たしかにそれっぽい音が…。この音源スペックで、どうやってるんだ…。

_Turbo Outrun (C64) Title Theme - YouTube

以下のやり取りによると、C64 は4bitの音量指定ができるからCPUでガリガリ制御して鳴らしてるのではないか、とか、PWM で鳴らしてるのでは、という話が。どういうことをしてたんだろうな…。

_How was digital sound playback achieved on the Commodore 64? - Retrocomputing Stack Exchange

_Rob Hubbard氏_Martin Galway氏 の作った曲もなんだかスゴイ。当時、こんな曲まであのスペックで鳴らせたのか…。ただ、各動画の波形を見る限り、 _ピッチベンド を多用してるようにも見えるわけで。そういう機能をドライバが持ってないと難しそうだな…。TIC-80上では、再現はちょっと難しい気もする。

#2 [anime] ルパン三世PART5、1〜4話まで視聴

「ルパン三世PART5」が福島でも放送開始されたようで。今回のシリーズは地方じゃ見れないのかもしれないなと諦めてたので、この展開は嬉しい。ありがたや。

OP映像に表示されたシリーズ構成さんの名前を見てビックリ。マジか。今回そんなスタッフ構成だったとは…。恥ずかしながらノーチェックだった…。や、この手のメジャーなタイトルで、そんな挑戦的(?)な起用がアリとは全く思ってなかったわけで…。もっとも、考えてみれば、経歴からして多くのヒット作に関わってるベテラン脚本家さんなのだから、参加しても全然おかしくはないのだよな…。

ネットを利用した危機の設定、及び、ネットらしさを利用したその攻略方法、更には、映像にTwitterっぽいテキスト情報をオーバーレイした画作り等、感心することしきり。なるほどそう来たか、上手いこと考えるなあ、ネットってたしかにそういうところがある、みたいな。昨今は、TV番組を視聴しながら同時に感想をネットに書き込む、いわゆる「実況」という行為があるけれど。本編内で実況をしているアニメを見ながら視聴者が更に実況という構図がそこにありそうで、なんとも面白い見せ方だなと。しかも、表示されるテキストがいかにもそれっぽい。よく観察してる…。実にそれらしい…。 *1

個人的に、ルパン三世と言えば一話完結タイプという思い込みがあったけれど。今回は海外ドラマをお手本にして連続モノとして構成している、という話を見かけて、その手があったか、と。かつ、どうやら旧来の一話完結タイプも一部で残しながら、そちらでは珍しい(?)脚本家さんを起用、という試みもしているらしいので、これは先の展開が楽しみだなと。脚本より前の段階で一工夫を加える手間を惜しんでいない作品は、それだけで、個人的に好きです。

とかなんとか書いたけど。今回のヒロインがなんだかイイ感じなので、もうそれだけで色々とオッケー、てなところも。なんか…あのヒロイン…なんとなく見た目で森山塔作品を思い出す…。なんでだろ。

自分はルパンシリーズに詳しくないのでアレだけど、3話に登場したキャラ達は既存作に出てきたキャラ達なのだろうか。と思ってググってみたら、どうやら原作に出てきたキャラ達だったらしい。いやはや、よくまあこれだけリストアップしたなあ…。ルパンマニアならニヤリとするのだろうな…。
*1: ただ、このノリは海外からどう見られるのか、という不安も。一つ一つを字幕で見せるのだろうか…。でも、海外ドラマでもこういう見せ方ありそうだよな…。その場合、はどういう処理をしているんだろう…。結構なんとかなるのかな。

2018/12/09() [n年前の日記]

#1 [pc] PCエンジンの波形メモリについて調べてる

波形メモリ音源と言えばPCエンジンだろう、ということで関連情報をググっていたり。

どうして7kHzなんだろう。 :

PCエンジンがPCMで何かを鳴らす際には 7kHzぐらいまで表現できる、という話を見かけて。

どうして7kHzなんだろうと思ったら、ブラウン管に画面を表示する際の水平同期周波数が15.7kHzで、それを利用して割込みをかけるから、という話らしくて。なるほど、サンプリング周波数が15.7kHz なら、再生できる周波数は半分になるから、7kHz前後になるのだな…。

_TurboGrafx-16 - Wikipedia
Optional software enabled Direct D/A which allows for sampled sound to be streamed into any of the six PSG audio channels. When a channel is in D/A mode the frequency is as fast as the CPU can stream bytes to the port, though in practicality it is limited to 6.99 kHz when using the TIMER interrupt with its smallest loop setting (1023 cpu cycles) or 15.7 kHz using the scanline interrupt.

TurboGrafx-16 - Wikipedia より

#2 [anime] ジブリアニメのサントラには謎の周波数が載っているらしい

15.7kHzでググってたら、何故かジブリアニメのサントラの話に辿り着き。

_劇伴(サウンドトラック)に15.73kHzが収録されている ( その他趣味 ) - 音響・映像・電気設備が好き - Yahoo!ブログ

映像と合わせながら音楽の収録を行ったものに関しては、15.73kHzの音が載っちゃってるらしい…。収録現場にブラウン管TVを持ち込んで映像を再生しながら合わせていったから、ブラウン管TVの周波数が混入したのではないか、という話で。なんだか面白いな…。

自分の耳は加齢で劣化してるので聞き取れるわけがないけれど、若い人達なら聞き取れたりするのだろうか。

2018/12/10(月) [n年前の日記]

#1 [tic80] TIC-80上でPCM再生できないか試行錯誤中

TIC-80上で波形メモリを書き換えることで、PCM再生っぽいことができないか試行錯誤中。

1秒間に60回、一周期32個のデータを書き換えるとして、60 * 32 = 1920Hzのサンプリングレートのwavを作って、そこからサンプリングデータを取得すればそれらしくならないか、と思って試しているけれど…。これがさっぱりそれらしく聞こえなくて。

音階の周波数をググったところ、A#2 が 58.270Hz、B-2 が 61.735Hz なので、そのあたりの音階で鳴らしてやれば ―― TIC-80上では sfx(SFX_ID, "B-2", 音の長さ) みたいな感じで鳴らしつつ、毎フレーム、波形メモリをせっせと書き換えてやれば、と思ったのだけど。どうも「ブー」という音が混ざる。ピッタリ60Hzにしないとダメなのかな。

TIC-80のSFXエディタ上では、波形を切り替えながら効果音を再生することもできるので、8個ほどの波形メモリに、鳴らしたいサンプリングデータを順々に格納して、1マスずつ波形を切り替える、ということも試したけれど。これだと「ブー」は入らないものの、それでも元々の音とはかなり違う音が…。てっきり、一周期分を再生したら次の波形に切り替える、というタイミングで処理しているのかなと思ったけれど、その予想は外れているのかもしれない。

2018/12/11(火) [n年前の日記]

#1 [tic80] TIC-80上でPCM再生できないか試行錯誤中その2

なかなかそれらしく鳴ってくれない…。

まあ、一応、今現在の作業手順や成果についてメモ。

サンプリングレート1920Hzのwavを用意する。 :

実験に使う、モノラル、16bit、サンプリングレート1920Hzのwavは、Audacity 2.2.2 を使って用意しした。

_「Audacity」無料の音声編集ソフト - 窓の杜

操作手順は以下。
  • Audacity で wav を開いて、左下の Project Rate (Hz) を 1920 に変更。
  • トラック → リサンプリング → 1920 を指定して変換。
  • 正規化する。エフェクト → Built-in → 正規化、を選び、最大振幅を正規化 = -1.0dbに。
  • サンプル数が 32 の倍数になってないと後処理時に都合が悪いので、そのあたりは揃える。
  • A. 不要な部分を選択して Deleteキーを叩いて削除して合わせてもいいし…。
  • B. 必要な分を無音トラックを作って Mix してもいい。トラック → 新しく追加 → モノラルトラック、でトラックを追加後、ジェネレーター → Built-in → 無音 → 必要なサンプル数を入力して無音トラックを作ってから、全選択(Ctrl+A) → トラック → Mix → ミックスして作成。
  • wavとして保存し直す。ファイル → Export → オーディオの書き出し → 保存wavファイル名を打ち込んで保存。

今回は、以下の4種類の wav を用意した。


_hello_1920hz_992sample.wav


_crt_hey_1920hz_672sample.wav


_crt_ooo_1920hz_512sample.wav


_ohit_mono_1920hz_960sample.wav

32ポイントずつ分割して出力。 :

Pythonスクリプトで、wav を32ポイントずつ分割して、音量4bitにしたバイト列データをテキスト出力。

動作環境・利用モジュールは、Windows10 x64 + Python 2.7.15 + Pydub 0.23.0 + Numpy 1.15.4。

使用スクリプトは以下。

_dump_divide_32sample.py

waveファイル名を指定して実行。
> python dump_divide_32sample.py crt_hey_1920hz_672sample.wav > temp.txt

Luaスクリプトに貼り付けられるテキストが得られる。
-- Input file : crt_hey_1920hz_672sample.wav
-- Channel : 1
-- Sampling rate : 1920 Hz
-- Duration : 350.000000 msec
-- Sample length : 672 point
-- N : 21
pcmtbl={
 "88787777878888776776988978667599",
 "896855969a884684ab9937829c9916c3",
 "7b8a12bca60af4586bb04ca9815ea772",
 "5d97935b58c57738b986556c87a35a48",
 "c786656c78c468389a96835b59b79666",
 "5b78b477498a96945a5ab795566b88a4",
 "67499995765a79a576598996756a78a5",
 "77599895577a97855979b5674ab79438",
 "8bb4555cb7834b9aa3497bc4575bc575",
 "4bb7843ab8943aa9a3399aa4388aa448",
 "8aa448999449a8844ab7755bb5567bb3",
 "489a834bb7468ba549b7658a845aa747",
 "a9757a945aa748b76699559a758a747b",
 "8569847a8679758a7589649a669946a9",
 "57985896797688669868866886896688",
 "67977976896697797689669878768867",
 "87897788787698788689678788787788",
 "67768878878878777788787788787777",
 "87887787787777778788777788777777",
 "77777777777777777777777777777777",
 "77777777777777777777777777777777",
}

TIC-80上で再生。 :

TIC-80上で再生。ソースとticファイルは以下。

_pcmtest.lua
_pcmtest_20181212.zip

SFXエディタを開いて、以下のような設定にしておく。SFX ID 1番目の wave 設定を、8〜15まで順々に切り替えて、かつ、ループするように設定。

tic80_pcmtest_ss01.png

音階 B-2 を鳴らしても本来の60Hzから微妙にずれてるので、気休めかもしれないけどpitch設定も少しずらして、かつ、ループするようにしておく。

tic80_pcmtest_ss02.png

で。一応、以下のような動作になったのだけど…。

_pcmtest.tic.html
  • ブラウザ上で実行できます。
  • Z、X、C、Vキーのどれかを押せば再生されます。

しかし、実に酷い音。元々のwavと聞き比べると、なんじゃこりゃ状態。

wavの段階では、サンプリングレート1920Hzのアレな音とは言え、それでもまだなんとか聞き取れなくもないけれど。TIC-80上で鳴らすと、もはや何を言ってるのかさっぱり分からん…。TIC-80が「ベラボー」「ミッソ」と喋ったらちょっと面白いかなと思ったけれど、現時点では正直かなり厳しいなと。

処理内容について補足。 :

再生時に読み取ってるはずの波形メモリと、書き換えてる最中の波形メモリが一緒だとノイズが入ったりするのかなと想像して、一番最初の書き換え時はともかく、その後は読み出しと書き換えの波形メモリをずらすようにしてみたのだけど、全く効果が無く。

まあ、ハードウェアで処理する場合なら、そういう対策が有効だったりする時もあるけれど、この場合ソフトウェアで実現してるソレだから、そういうアレコレでノイズの有無が変わるわけでもないのだろう…。

既にPCM再生を試してる方が居た。 :

公式サイトのPlayページを眺めていたら、以下のプログラムがPCM再生を試していた。

_Play BASIC PCM @ 1.92 KHZ in TIC-80

ソースを眺めたけれど、以下の部分がよく分からない…。
 poke(0xFF9C,60)
 for i=0,32 do
  poke4(0x1FF3B+i,peek4(baseAddr+i+((t%length)*33)))
 end

ただ、 _RAM - nesbox/TIC-80 Wiki を眺めているうちに、なんとなく分かってきた。
  • poke(0xFF9C, 60) は、SOUND REGISTER の周波数を設定してる。この場合は 60Hz を指定してる。はず。たぶん。
  • poke() は1byteを書き換えて、poke4() は 4bit を書き換える。
  • poke4()に渡すアドレスは、poke()で使うアドレスを2倍したものになる。つまり、0x1FF3B の指定は、本来のアドレスなら 0xFF9D * 2 + 1 を指定してる。この場合、SOUND REGISTER の volume値のあたりから書き換え始めている、ような気がする。
  • volume の次のアドレスからは、波形を記録する領域になっていたらしい。音量4bit が 32個、つまり 16byte が並ぶ。
件のソースは 0〜32 の値でループしていて、「波形を書き換えるつもりなら、32個 ―― 0〜31 のループになるはずなのに変だな」と思ったけれど、この場合は、4bit の volume値 + 32個の波形データを書き換えているから、33回のループになっているのだろう…。

仕組みが分かったので、同じ方法で自分も鳴らしてみた。

_ブラウザ上で実行 : pcmtest2.tic.html
_ソース : pcmtest2.lua
_ticファイル : pcmtest2_20181212.zip

波形メモリを書き換えていくソレと比べて、音質はほとんど変わらなかった…。現状の TIC-80 では、これが限界なのかもしれない…。

2018/12/12追記。 :

一部ループ処理がバグってたのと、データを文字列で持ったほうがソースが短くなりそうだったので、修正して再アップロードしておいた。しかし、音質はさほど変わらず。

#2 [pc] soxを試用

sox というツールを使って、サンプリングレートを1920Hzにできそうか、リサンプリングを試してみたり。環境は Windows10 x64 + sox 14.4.2。

_SoX - Sound eXchange | HomePage

-r N でサンプリングレートの指定、--norm でノーマライズの指定、だろうか。
sox input.wav -r 1920 --norm output.wav
これで変換できた。変換後の音質は、Audacityのソレと似た感じ。

-b N オプションで8bit等に変換できるようで。もしや 4bit も変換できるのかなと試してみたけれど。
sox input.wav -r 1920 -b 4 --norm output.wav

出力された wav は、Python + Pydub ではエラーが出て開けなかった。ffmpegが呼び出されたものの変換不能と言われてしまう。

真空波動研Lite というツールで確認してみたところ…。
[out.wav]
Microsoft ADPCM 1.92kHz 4Bit 1ch 7.86kb/s
[RIFF(WAVE)] 00:00:00.520 (0.520sec) / 602Bytes

真空波動研Lite 160508 / DLL 160508 Unicode
4bitではあるけれど、PCMじゃなくてADPCMになっているようで。wavファイルは、そんなフォーマットも含めることができるのか…。

余談だけど、ADPCM というのは、絶対値じゃなくて前の値からの差分を記録していく方法。DPCMは差分の変化幅が一定だけど、ADPCMは差分の大小で幅を変えて記録する、のではなかったかな…。以下のページの図が分かりやすい、ような気がする。

_ADPCMの実験
_音声圧縮処理の基本 ―― 音楽CDやWAVファイルで使われている波形符号化方式|Tech Village (テックビレッジ) / CQ出版株式会社

2018/12/12(水) [n年前の日記]

#1 [anime][neta] カメラを90度回転させた構図

日本のアニメにおいて、例えば美少女キャラの全身像をたっぷり見せたい、てな時は、えてして縦方向にPAN(縦スクロール)させて見せたりするわけだけど。

先日、「俺が好きなのは妹だけど妹じゃない」、通称「いもいも」というアニメを眺めていたら、カメラを90度回転させた構図で、横方向にPAN(横スクロール)するカットが何度も出てきて。

変わった見せ方をするなあ、となんとなく感心しつつ、そこからなんだか色々なアレコレを考えてしまったので、そのあたりをメモ。思考メモです。

カメラを傾ける構図の効果。 :

映像作品において、カメラを意図的に傾けた構図は、観客の心理を誘導できる効果がある、とされていて。

例えば、カメラを斜めに傾けると、足元が不安定な風景になるから、観客はなんとなく不安を感じたりするわけで。ピサの斜塔を目にすると「オイオイ、大丈夫かコレ」と不安になるけれど、要はアレと同じ。本来垂直に立ってるはずのものが斜めになっているから見てるだけで不安になるという。ソレを利用して、登場人物が不安を感じてることを伝えたり、そこで異常なことが起きていると伝えたり、「さあさあ、なんだか話が怪しくなってきましたよ」と先の展開をうっすら予想させたり、といったことができたりする。

また、カメラを180度回転させて、天地を逆にする手もある。例えば、主人公がとんでもないショックを受けた場面で使ったり。文章であれば、「○○は頭から奈落の底に落ちていくような感覚を覚えた」みたいなソレを表現しているのだろうか…。 *1 まあ、上下逆さまな風景は、明らかに日常的ではない異常な風景なので、「とんでもないことが起きてますよ」となんとなくぼんやり感じさせる効果ぐらいは期待できそうではあるなと。

他にも、カメラをグルグルと回転させることで、キャラが混乱状態にあることを伝えたり、とか…。まあ、これはちょっと昭和的感覚な見せ方だけど…。もっとも、ギャグアニメやきららアニメの類なら、今でも全然フツーに使えそうではある。

カメラを傾けることで、観客は、そこに重力があるように錯覚して、それ故に不安になったりするわけだけど。ソレを利用して、アクションシーンを盛り上げることもできる。

例えば、左斜め下に主人公が走ったり飛んだりしてる構図なら、坂を下ってるような感じに見えるので、見た目よりも主人公の移動速度が増しているように観客が感じたりする。 *2

あるいは、左斜め上に主人公が走ったり飛んだりしてる構図なら、坂を上ってるような感じに見えるので、重力に逆らいつつそれでも進む主人公≒果敢にも強敵に立ち向かう主人公、等々を感じさせたりもできる。ロボットアニメ等のOPで、主人公ロボがラスボスっぽい巨大メカに立ち向かっていくカットでは、えてして左斜め上に飛んでいくわけだけど、それはつまりそういうこと。

このように、カメラを傾けた構図は、観客の心理をわずかに誘導することができたりするわけだけど…。そういったアレコレを踏まえた上で、さて、カメラを90度傾けた構図は、観客に一体何を伝えられるのか? 観客をどんな気持ちにさせられるのか? …残念ながら、これがちょっと思いつかないわけで。

ということで、90度回転させた構図については、今後の理論武装がもうちょっと必要かもしれないなあ、と。「なんとなく面白そうだからやってみた。効果? 何ソレ?」じゃなくて、「コレコレこういう効果が期待できるから、あえてここは90度回転させたのだ」みたいなことを堂々と言えたら、なんだかできる演出家っぽいよなと…。

タブーとしての風景という意味付け。 :

90度回転構図の効能は無いのか、と考えてるうちに、ふと思いついた。男性が、立っている女性のスカートの中を覗き込もうとした場合、えてして頭は90度傾くわけだけど…。つまり、そういう効果が期待できるのではないか。

例えば、90度回転構図で、美少女キャラのふともも→腰→上半身と横方向のPANで見せていけば、これはもう視聴者に対して女性のスカートの中を覗き込む行為を強制的に疑似体験させている、と言えなくもないよなと。なるほど、美少女キャラばかり出てくる系のアニメなら、使い道がある構図かもしれん…。

そこから更に発展させて…。一般的に我々は、女性のスカートの中を覗く、などという破廉恥な行為を日常的にしていないので、そういった構図は、「日常生活の中で本来見るはずのない奇妙な構図」「見てはいけない構図」「タブーとされている風景」という扱いができるのかもしれない。いやまあ、「えっ? 俺は日常的に見ているよ?」という人も世の中には居るかもしれないけど、それは例外ってことで…。ここは、「世間的には目にするはずのない風景」ということにしておくとして。

であれば、世間的にはやっちゃいけないことを堂々とやってしまっているキャラ、なんてものを描く時に、90度回転構図は使えたりするのかもしれない。例えば、堂々と何かを大声で主張しているけど、いやお前ソレ世間的にはアウトだろ真面目な顔で何とんでもないこと言ってんだ、てな主張内容だったりする時に、「タブーとしての風景」である、90度回転構図を使うとか…。もしくは、その場合、当人はしっかりすっくと真っ直ぐに立っているはずなのに、傍から見ると見事にバッタリ倒れている、という意味だって含められるのかもしれない。なんとなく、「倒錯」という単語がぼんやり思い浮かんだりもして。

ホントかよ。

考えてみたら…。布団に横になって目を開けば、そこには90度回転した風景がいつでもあるわけで…。「日常的に目にしないはずの風景」「タブーの風景」というわけでは全然ないのだよなあ…。ぎゃふん。

でもまあ、「横になれば見れるだろ」的風景だとすれば…。例えば、キャラが病気になって倒れてしまって、そのキャラの一人称視点で見せたい、なんて時はフツーに使えるわな…。90度回転構図で、ヒロインが心配そうにこちらをのぞき込む様子を見せる、とか。無難な使い方ではあろうけど、観客に疑似体験させる効果は十分に期待できそう。

画面の中になんとか詰め込むための手法。 :

エロゲのイベント絵においては、90度回転構図は珍しくないことに気づいたり。

エロゲのイベント絵は、画面の中で美少女キャラをできるだけ大きく、かつ、できるだけ全身を見せるべし、という要求があるので…。画面の対角線を軸とした斜めの構図や、真横に回転させた構図で描かれたりするのだろうなと。別にコレ、近年産まれた構図でもなくて、Windowsが普及してなくて、PC-9801が国民機と呼ばれてた時代のエロゲですらそういう構図があったので、意外と歴史のある構図というか。

さて、エロゲのイベント絵に対するそういった要求は ―― 美少女キャラをできるだけ大きく、かつ、全身をねっとりと見せろ、という暗黙の要求は、美少女キャラがやたら出てくる系のアニメにおいても同様にありそうな気がする。

実際、「冴えない彼女の育て方」というアニメでは、会話だけで飽きてきそうなシーンにおいて、エロゲのイベント絵的な斜め構図+斜めPANでヒロイン達をじっくり見せていたし。ある種ファンサービス的なカットでもあったのだろうけど、エロゲのイベント絵の構図はアニメへの流用も可能と示す一例、だったような気もするわけで。

であれば、斜め構図に限らず、90度回転構図も、同様に流用可能だよなと…。そう考えると、別におかしい構図というわけでもない。ような気もしてくる。

更に、今のTVは、昔の4:3と違って16:9になり、横方向に長くなったわけで。せっかく横に長くなったこの縦横比を利用しない手はないよなと。広がった横方向に、美少女キャラを詰め込んで、見た目の訴求力を高める。そのために、90度回転構図を活用する…。それはそれでアリなのかもしれない。

ただ、エロゲのイベント絵はずっと表示しっぱなしだから、どんなに複雑な構図・ポーズでも、何がどのように描かれているのか認知してもらえる、という面もあって…。

アニメの場合は、時間が経つとカットが流れていってしまうので、そこに何が描かれているのか観客が認知できるだけの時間を意識して使わないとマズそうな気もする。まあ、それは逆に、TVアニメにおいてはメリットになりそうだけど。昔、富野監督が、「戦闘中に議論させれば口パクだけで5秒持つんですよ!」と叫んでたけど。「90度回転させればそれだけで○秒持つんですよ!」という論もアリ、だったりするのかも。

話が少しずれるけど、ジョジョシリーズの奇異なポーズもソレなのだろうか。フツーのポーズが描いてあったらそのまま流してしまうけど、妙なポーズが描いてあると、「ん? コレどういうポーズなんだ?」としばらく凝視してしまう。どんどん読み飛ばされていく週刊連載漫画の中で、読者の目を、できるだけ自分の漫画のページに留めておきたい。そう考えた時、しばらく見つめないと何が描いてあるか分からないモノを時々ポンと置いておく、そんな策も意外に有効…と言えなくもないよなと。

描画面積の問題。 :

縦方向にPANさせるカットを作画しようとすると、フツーに考えたら、通常の用紙サイズより縦方向に長くて大きいサイズになって、鉛筆が動く距離が増えちゃって、作業時間がかかりそうだなと。

しかし、横方向にPANするカットなら、横にちょっとサイズが増えるだけで、縦のソレと比べれば、描画面積は狭くて済むはず…。

宮崎駿監督は、かつて、「アニメーターが早く描くためには鉛筆の移動速度を意識して描く必要がある」みたいなことを言っていて。「早く鉛筆を動かさないとそもそも早く描けねえんだよ。お前達の鉛筆のスピードは遅すぎる」みたいな。しかし、作画用紙のサイズが小さくなれば、鉛筆の移動速度が今までと同じでも、移動距離は長くなるわけで…。

つまり、スケジュールが厳しいアニメの場合、90度回転構図は作業時間の短縮に貢献する可能性があるので、コレを使わない手は無い。という主張もアリかもなと。

作画用紙を小さくして作業時間の短縮を試みる策は、漫画の世界なら昔実際やっていたそうで。誰だったか忘れたけれど、週刊連載を何本も抱えていた漫画家さんが、原稿用紙を通常より一回り小さいものにして試したことがある、とかなんとか。まあ、効果があったかどうかまでは分からないのだけど…。誰がやってたという話だったのかなあ…。思い出せない…。

今後に期待。 :

何にせよ、「いもいも」で見られたそれらの構図は、理論武装を強化するなり、使い方を吟味するなどすれば、スタイルとしてアリになりそうだなと。

視聴者からするとちょっと見慣れない構図だから、しばらくはどうこう言われるかもしれんけど、そのあたり、あまり気にしないほうがいいよなと…。出崎監督の3回PANもそうだけど、スタイルとして一旦定着しちゃえば特に何も言われなくなるので…。

ただ、使い道が…。「なるほど、こういう場面ならこの構図はアリだな。考えたなあ」と思える見せ方を期待したいところ。

以上、とりとめのない思考メモでした。

*1: 自分の偽記憶かもしれないのでちょっと自信が無いけれど…。たしか、「プラネテス」というアニメでは、主人公が大ショックを受けたシーンで、無重力空間であることも利用しつつ主人公をあえて上下逆さまな構図にして叫ばせてた気がする。余談だけど、あのカット、背景で大爆発や、メカの破壊後の風景も描かれてたけど、今になって考えると主人公の感情の爆発と呼応した風景であったり、あるいは、相手に対する信頼の崩壊を比喩していた風景、だったのかもしれない。
*2: コレはたしか、「未来少年コナン」の一話で、ラナを助けようとして走っていくコナンを描写する際に使ってた記憶が…。と思ったけれどアレは本当に坂を下ってたからちょっと違う事例なのかな…。斜め下に降りてる構図をあえて選ぶことで、坂を下りてることもちゃんと伝わるし、その上スピードも乗っている、という二つの効果を得ていたと捉えられなくもないけれど。他の事例では、SAOで主人公がバトルしてる時に使ってた…記憶もあるけどコレもちょっと記憶が怪しい。背中に羽根が生えてた編で、左斜め下に飛んだり、左斜め上に飛んだりしてたような…。

#2 [nitijyou] 日記をアップロード

2018/11/30から日記をアップロードしてなかったので、まとめてアップロード。とメモ。

2018/12/13(木) [n年前の日記]

#1 [pc] メインPCがスリープから復帰せず

自分が使ってるメインPCは、随分前から何故かスリープ復帰に失敗する状態で。ビデオカードとして GeForce 9x00GT を使ってた頃はスリープ復帰ができていたけれど、GeForce GTX 750 Ti に交換したあたりからスリープ復帰時に画面が真っ暗なままになる症状が出て…。なので、諦めて休止状態しか使わないようにしていたり。

しかし、しばらく前にビデオカードを GeForce GTX 1060 6GB に交換したことを何故か今頃思い出したわけで。ひょっとしてスリープ復帰できる状態に改善してたりしないかと。

試してみたけど、ダメだった。GTX 750 Ti の時より酷い感じで、電源を投入しようとしてるけど、電源が正常に入らなくて、また投入を繰り返す、みたいな状態になってしまった…。まあ、休止状態からの復帰はできてるから、相変わらずそれで我慢するしかないかな…。

原因についてググってみたけど、これではないかと思える情報には遭遇せず。もっとも、自分の環境は、CPU が Intel Core i5-2500、M/B が Intel DH67BL ―― H67チップセットを使用しているぐらいに古い製品なので仕方ないのかも…。いやまあ、ひょっとすると電源が弱まってる可能性もありそうだけど。

2018/12/14(金) [n年前の日記]

#1 [cg_tools] 久々にblenderを触ってる

仮で使う画像素材が欲しくて、blenderを起動して作業中。元モデルは DOGA-L1で作成して、VRML形式で保存して、blenderでインポート。

天井にライトがずらりと並んでるソレを作りたかったのだけど、平面のマテリアル設定で放射を設定しただけでは、望んだ結果にならず。ライトらしく見た目は白くはなったものの、周囲のモデルを照らしてくれなくて。

ググってみたら間接照明とやらを有効にしてレンダリングすればそれっぽくなるらしい…。

_[Tips]Blenderレンダーで放射をライトとして使う[Render] | Blenderで建物作ってみる会
_■ 放射をライトとして使う | @Kay-nea@のブログ

2018/12/15() [n年前の日記]

#1 [moho] Moho Pro 12を起動して触っていたり

久々に起動したので、使い方をほとんど忘れている…。

シーケンス画像ってどうやって取り込むんだっけ…。レイヤーウインドウから操作しても読み込んでくれない…。ファイル → インポート、でいいのかな…。

2018/12/17追記。 :

レイヤーウインドウの、「画像シーケンス」を追加する操作でもイケた。最初のファイルだけ指定してやればよかったのか…。

2018/12/16() [n年前の日記]

#1 [movie] 「シン・ゴジラ」を視聴

TV放映されるということで視聴してみたり。以前も放映されたけど、その際は一部を見損ねてたので、今度はちゃんと最初から終わりまでしっかり見ようと。

改めて眺めてみると、実にハイコンテクストな映画だなと。

例えば、政治家さんが、「この国はスクラップアンドビルドで」という台詞を言うけれど、ソレ、日本人しか分からないよなと…。日本人でも、小中学生はまず分からないだろうし、下手すると高校生や大学生ですら分からないかもしれない。

「半減期」云々の台詞も、原発事故を起こしてしまった現在の日本人ぐらいしか、何を言ってるか分からないはず。海外で分かるとしたら、チェルノブイリ原発事故で酷い目にあったウクライナの人達ぐらいだろうと。アメリカ人なら、まず分からない。何せ核爆発をバックにキスしちゃう映画を作る人種だし。今現在の日本人だって、原発を再稼働しちゃった西日本の人達などは、ちょっと分からない台詞だったりするのかもしれない。あるいは、原発事故を起こす前の日本人も、まず分からない台詞だよなと。例えば、事故前に製作・公開された実写版宇宙戦艦ヤマトの中で、キムタク演じる古代進が放射能に苦しむシーンがあるけれど、今見ると失笑しちゃう描写なわけで。当時の日本人の知識状態は全般的にそんなものだったから、あの頃に「半減期が」という台詞があっても、おそらく意味が分からないよなと。昔だったら、「この女性、なんでここでこういう表情するの?」と、Yahoo!知恵袋に質問が書き込まれてたかも。

在来線無人ナンタラも、東京に住んでる人しか、たぶん分からないよなと…。いや、鉄オタさんならバッチリわかるか。「シンカリオン」の主人公みたいな人なら、あのシーンで大変なことになるわな。

そんな感じで、あらゆるシーンが、日本人、それも今現在の日本人に最適化しまくった映画だなと改めて認識。故に海外で大爆死したのも納得で。こんな映画、日本人以外に分かるわけない…。海外の観客には全てが意味不明な映画だったのではあるまいか。

なんとなく思い出すのは、松本人志監督の「大日本人」。カンヌで流した際に、観客が途中退席するわ、関係者しか拍手してないわで、さっぱりウケなかったらしいけど。アレも、そりゃ設定からして何をしようとしてるのか、日本人、それもウルトラマンを見ていた層しか分からないだろうなと…。

だからと言って、その手の映画がダメ映画というわけでもなく。分からない人には分からないけど、分かる人には最適化されてる分、かなり刺さる映画なはずで。実際、「シン・ゴジラ」も多数の日本人に刺さってみせたわけで。ただ、「日本でこんなにヒットしたのだから海外でも」と考えるのは、あまりに安易過ぎるなと…。

何にせよ、この映画は、日本人の、日本人による、日本人のための映画だなあ、と思いながら眺めたり。

2018/12/17(月) [n年前の日記]

#1 [pc] 親父さん用PCのSFX電源を交換してみるも起動せず

親父さん用PCの調子が相変わらず悪い。寒い日に電源を投入すると固まる、との報告が。寒い日に固まると言うと…電源だろうか。ということで、電源を交換してみたらどうなるかなと。

親父さん用PCに積んである電源は、SilverStone SST-ST45SF。SFX電源、450W、+12V 36A シングルレーン。ちなみに、V1.0のシールが貼ってあった。

_SST-ST45SF - SilverStone - マスタードシード株式会社
_SilverStone Technology Co., Ltd.製品紹介:ST45SF

部屋の中で埃を被ってた200円PCケースの中から、SFX電源を発掘。FSP300-60GLS。SFX電源、300W、+12V1が8A、+12V2が16A。現在市場にあるのは、FSP300-60GHSなので、それより古い製品。60GHS が、+12V1=14A、+12V2=16A なのに対して、60GLSは、+12V1=8A、+12V2=16Aと、流せる電流の大きさが違う。

コンパクトなケース、IN-WIN IW-BK623 を相手に、1時間半ほど四苦八苦して、どうにか電源を交換した。が、電源を投入しても起動せず。一瞬LEDが光って、すぐに消えてしまう。CPU が AMD A8-3850 (100W) なのだけど、おそらく電源容量が足りてないのではないかなあ…。それともケーブルがちゃんと刺さってないのか。FSP300-60GLSのコネクタ、やたらと固くて刺さらないのだよな…。

仕方ないので、1時間ぐらいかけて、元の電源に戻した。ただ、戻す際に、電源のケースを開けて、エアダスターで中を掃除しておいた。まあ、その程度で状況が変わったりはしないだろうけど。一応コンデンサの類を眺めてみたけど、膨らんだり、液体が漏れたりしてるモノは見当たらなかった。

FSP300-60GLS は、200円PCケースの中に戻した。スペックは以下。

_mieki256's diary - 200円ケース機でUSBメモリにインストールしたLubuntuを起動しようと実験

こちらだとフツーに動く。やはり電源容量かな…。

Windows10が起動しなくなった。 :

何度か電源投入して、Windows10が起動していたので安心していたのだけど、夜になったらWindows10が起動せず。もしや、電源交換時にSSDからSATAケーブルを外したりつけ直したりしたことで接触不良に…。だけどそれが原因なら、フツーに起動したり操作できたりしないような気もする…。

ただ、起動しなくなる直前に、親父さんがSONY製デジカメの添付アプリ、PENTAX製デジカメの添付アプリをインストールしたそうで。どちらのCD-ROMも古くて、Windows2000〜Vistaまでの対応…。Windows10の動作に必要なファイルを古いファイルで上書きした可能性は…。いや、しかし、いくら古いアプリでも、そんなことをするだろうか…。

Windows10自身は、電源投入直後から「修復しています」→「修復できませんでした」を繰り返すだけで。システムの復元を試みようとしたら、復元に使える記録は無いと言われるし、スタートアップ修復を選んでも「修復できませんでした」と言ってくる。

諦めて、PCの初期化を選択。アプリは削除、ユーザファイルは保持した状態で、Windows10の動作に必要なファイルをごっそり書き込んでくれるはず…。これで起動する状態になってくれればいいのだけれど。

もしや、SSDの寿命では…。

2018/12/20追記。 :

自分のメインPC上で、仮想PC (VMware Player) を起動して、Windows10評価版をインストールしてみた。更に加えて、SONY製デジカメの添付アプリと、PENTAX製デジカメの添付アプリをインストールしてみた。もし、SONY や PENTAX のソレが Windows10 を破壊しているなら、仮想PC上でも Windows10 は起動しない状態になるはず。

Windows10 はフツーに起動した。つまり、SONY や PENTAX の添付アプリが原因で、Windows10 が起動不可になったわけではないなと。

となると、ますます困る。SSDかなあ…。SSDが死にかけているのかなあ…。しかし、S.M.A.R.T情報等を眺めても、異常が出てるようには見えないし…。まあ、その手の情報を過信するのも禁物、なのだろうけど。

2018/12/18(火) [n年前の日記]

#1 [gimp] GIMP 2.10.8 Portable を Windows10にインストールしようとしたけれど

GIMP 2.10.8 Portable を Windows10 x64 にインストールしようとしたけれど、テキスト入力欄に英数字を打ったら半角カタカナになってしまう…。GTK+ Windows 32bit版で以前から発生しているバグが未だに取れてないっぽい。

コレ、64bit版では発生しない不具合なのだけど、GIMP Portable は32bit版を配布するポリシーのため、発生してしまうという…。

Portable版ではなくフツーのGIMPセットアップ版をインストールしてしまうと、過去バージョンの GIMP 2.6 が削除されてしまうし、そうなると時々使いたくなるプラグイン等が動かなくなるしで、どうしたもんか。

#2 [windows] Notepad++ 7.6.1 にしてみたらちょっと困ったことに

Notepad++ 7.6.1 が公開されたらしいのでアップデートしてみたら、インストールしてあったプラグインが全て消滅。酷い…。

今までは plugins フォルダの直下に .dll を置いておいてもプラグインとして認識されていたけれど、7.6 以降は plugins\hoge\*.dll という形で、サブフォルダを作ってその中に .dll をインストールしないと使えない仕様になったらしい。以前バンドルされていたプラグインマネージャーが勝手に(?)広告付きにされてしまって、以前のソレでインストールされたプラグインは使えないようにした、という話を某所で見かけた。それはいいのだけど… emmet や Python Script がインストールできない…。不便になった…。

それでもいくつかプラグインを選択してインストールできるので、インストール・アンインストールを試していたのだけど、何故か更新時に Notepad++ が終了してくれず、プラグインのアンインストールもできない…。タスクマネージャーから無理矢理終了させてどうにかしたけれど、何のプラグインもインストールしていない状態ならフツーに終了するので、どうも何かのプラグインが悪さをしているような気がする。

#3 [pc] 親父さん用PCのメンテナンス中

親父さん用PCのWindows10が起動しなくなった件。スタートアップ修復は効果が無かった。仕方ないので、PCの初期化を選択。

Windowsは起動するようになったけど、アプリはほとんど消滅。ユーザファイルは保持すると表記されていたのに、%APPDATA%すら削除されて、Mozilla Thunderbird のアドレス帳データやメールデータも全部消滅して絶望的な気分になったけれど。Windows.old というフォルダが残っていて、そこに今までの %APPDATA% その他が残っていたのでなんとかデータを引っ張り出せた。

SSDの寿命が絡んでるのではと、SSD Life Free なるツールをインストールしてチェックしてみたけれど、正常と表示されている…。

Windows.old が50GB以上あってSSDを圧迫しているので、外付けHDDに移動させたほうがいいと親父さんにアドバイスしたけれど、USB2.0接続の外付けHDDなせいか、8GBほどコピーするだけでも数時間かかった。しかも途中でアクセス権限がどうこうのダイアログが出てきて処理が止まる。この調子では…残り42GBを移動するのに何時間かかることやら…。

2018/12/19(水) [n年前の日記]

#1 [gimp] GIMP 2.6.12 Portableをインストールして試行錯誤中

GIMP 2.6.12 Portable版を Windows10 x64上にインストールして、Python-Fu を動かせる状態にできないか実験中。

今時 GIMP 2.6.x をあえて動かす必要性は無いだろう、とは思うけど。一応メモ。

実験してる理由。 :

自分のメインPC、Windows10 x64 日本語版には、バージョンの異なるGIMPが複数インストールしてあって。
  • GIMP 2.6.12 通常セットアップ版
  • GIMP 2.8.x Portable
  • GIMP 2.10.x Portable
GIMP 2.6.x で Python-Fu を動かすためには、通常セットアップ版をインストールするしかなく。2.6 が通常セットアップ版なので、2.8 や 2.10 と共存させるためには、2.8 と 2.10 は Portable版をインストールしないといけない。

しかし、それはそれで問題が。GIMP Portable は32bit版のGIMPなのだけど、昨今の GIMP 2.10.x 32biti版は、日本語版 Windows上で動作させると数値入力欄やテキスト入力欄でキー入力ができないという、結構致命的なバグがあって。

_English input not accepted from Japanese keyboard (#2654) - Issues - GNOME / GIMP - GitLab
_Japanese input broken with glib 2.56 on Windows 32-bit (#1421) - Issues - GNOME / GLib - GitLab

これは、GTK+ 32bit版、glib (libglib-2.0-0.dll) に起因するバグらしく。64bit版なら不具合は発生しないのだけど、32bit版だけ、ずっとバグが取れてない状態で…。このあたり、GIMPに限った話ではなく、例えば GTK+ を使っている Geany というエディタでも発生してる問題で。

_Geany 1.31のWindowsにおける文字入力か表示の不具合 - 借りてきた猫のように静か

なので、せめて GIMP 2.10 だけは、64bit版を使いたい。となると、通常セットアップ版を選ぶしかなく。

しかし、GIMP 2.10 通常セットアップ版をインストールすると、GIMP 2.6.12 通常セットアップ版が強制的にアンインストールされてしまう。GIMP 2.6 でしか動かないプラグインがあったりするし、GAP (GIMP Animation Package) も GIMP 2.6用のバイナリしか無い状態だったりするので、できれば GIMP 2.6 も残しておきたい。 *1

そこでふと、GIMP 2.6 Portable 版でも Python-Fu が動かせれば、GIMP 2.6 を Portable版に、GIMP 2.10 を通常セットアップ版にできるなと。

しかし、GIMP 2.6 Portable 上で Python-Fu を動かすことはできるのだろうか…。てなわけでそのあたりを実験しているのだけど、これが上手くいかない。

動かせていた事例もあるらしい。 :

以下のやり取りを眺めた感じでは、GIMP 2.6.11 Portable 上で Python-Fu を動かせていた事例もあるらしい。

_How can you get python to function on the PortableApps version of Gimp - GIMP Chat

手順としては、たぶんこんな感じだろうか。
  1. Python 2.6.x をインストールしておく。
  2. pygtk-all-in-one-2.24.2.win32-py2.6.msi をインストールしておく。
  3. GIMP 2.6.x 通常セットアップ版を仮で一旦インストールしておく。その際、「GIMP Python extension」もインストールしておく。
  4. GIMP 2.6.x Portable版をインストールする。
  5. Protable版インストールフォルダ\App\gimp\ 以下に、Python 2.6 のインストールフォルダを、Python というフォルダ名でコピー。
  6. 通常版インストールフォルダ\lib\gimp\2.0\environ\*.env を、Portable版\App\gimp\lib\gimp\2.0\environ\ にコピー。
  7. 通常版インストールフォルダ\lib\gimp\2.0\interpreters\*.interp を、Portable版\App\gimp\lib\gimp\2.0\interpreters\ にコピー。
  8. Portable版\App\gimp\lib\gimp\2.0\interpreters\pygimp.interp を編集。python= の行と、/usr/bin/python= の行の右側を、Portable版\App\gimp\Python\\pythonw.exe に変更。
  9. 通常版\lib\gimp\2.0\plug-ins\ の中の .py ファイルを、Portable版\App\gimp\lib\gimp\2.0\plug-ins\ にコピー。
  10. 通常版\lib\gimp\2.0\python フォルダを、Portable版\App\gimp\lib\gimp\2.0\ 以下にコピー。
しかし、手元の環境、Windows10 x64 + Python 2.6.6 + GIMP 2.6.12 Portable では成功しなかった。フィルタ → Python → コンソールを選んでも、何も表示されない。該当メニューが出てくるあたり、ちょっと動きそうな気配は感じたのだけど…。

ちなみに、GIMP 2.6 通常セットアップ版では、以下の手順で Python-Fu が使えるようになるらしい。

_Installing Python for GIMP 2.6 (Windows) - Tutorials - gimpusers.com

gimp-painter- で Python-Fu を動かせていた事例もあるようで。

_the GIMP 2.6 + gimp-painter- readme
Pythonサポートを有効にするには、gimp-painter-\gimp\lib\gimp\2.0\pythonフォルダ内の

_gimpenums.pyd、 _gimpui.pyd、
gimp.pyd、
gimpcolor.pyd、
gimpthumbs.pyd
(その他、拡張子.pydのファイルがあれば全て)

をPythonのインストール先にある
Lib\site-packagesフォルダ
にコピーし、
gimp-painter-\gimp\lib\gimp\2.0\interpretersフォルダ内の
pygimp.interp
をテキストエディタなどで開き、
"python="と"/usr/bin/python="の右側をご自分の環境に合わせて修正してください。

ftp://ftp.jaist.ac.jp/pub/sourceforge.jp/gimp-painter/33685/readme_jp.xhtml the GIMP 2.6 + gimp-painter- readme より

これも試してみたけれど、ダメだった…。

gimp-painter- をインストールしたりして色々試しているうちに、GIMP 2.6.12 通常セットアップ版のPythonコンソール上で、文字入力ができなくなってることに気づいた。Enterキーだけは受け付けるけれど…。元からこういう状態だったのか、それとも色々試しているうちにこうなったのか…。

*1: 一応、GIMP 2.6用 GAP のバイナリを GIMP 2.8 にインストールしても、基本機能に関してはそこそこ動くのだけど、全ての機能が使えるわけではないらしい。全機能を使いたいなら、GIMP 2.6 が必要になりそう。

2018/12/20(木) [n年前の日記]

#1 [gimp][linux] GIMP Windows版について試行錯誤中

GIMP の導入について試行錯誤中。

Ubuntu 18.04 LTS上でGIMP+GAPを利用。 :

自分が今後 GIMP 2.6.12 を利用するとしたら、GAP (GIMP Animation Package) を使う時ぐらいかなと思えてきたので、もし Linux上で GAP の導入や利用が楽ならば、GAP を利用する時だけ Linux を立ち上げるのもアリかなと。ということで、Ubuntu 18.04 LTS 上ではそのあたりどうなのか調べたり。

Ubuntu 18.04 LTS の場合、gimp-gap というパッケージが既に用意されているらしい。

_Ubuntu - bionic の gimp-gap パッケージに関する詳細
_Ubuntu - bionic の gimp パッケージに関する詳細

インストールされる GIMP は 2.8.22。GIMP 2.8.x なら GAP が動くけど、GIMP 2.10.x では動かないという話もあるらしいので、ちょっと助かる。かもしれない。

VMware Player + Ubuntu 18.04 LTS 上で、gimp と gimp-gap を Synaptic 経由で入れてみたけど、フツーにGAPの機能が使えた。例えば、0001.xcf というファイル名で保存してから、Frame Duplicate でフレーム数を増やし、next frame に「.」を、prev frame に「,」のショートカットキーを割り当てれば、キーを叩くだけで前後のフレームに移動できる。

Windows版と違って、Linux版のGIMPならトラブルに遭遇することも少ないだろうし、特定機能が使いたくなった時だけ Linux 上で作業する手もアリかな…。

64bit版の GIMP 2.10.x Portable が存在していた。 :

GIMP 2.10.x Portable は 32bit版なので、そのままだと日本語版Windows上でキー入力ができない不具合に遭遇してしまうけど。

_GIMP Portable (image editor) | PortableApps.com

以下のページで、GIMP 2.10.x Portable 64bit Windows版が配布されてることを知った。

_Partha's Place

64bit版なら、件の不具合が発生しないので、これならなんとか使えそうな予感。Portable版だから、今まで通り GIMP 2.6.12 通常セットアップ版をインストールしたままでも済みそうな気がする。

今時GAPを使うだろうか。 :

自分が GIMP 2.6.x に拘るのは、2.6 でしか動かないプラグインがあるのと、GAP の全機能が使えたほうが気分的に安心だから、なのだけど。

考えてみたら、2.6 でしか動かないプラグインは、ここ数年使ってないような気もしてきたり。また、GAP も…全く使ってない気がする。

昔と違って今時は、手描きアニメっぽいものをお絵かきしたいならGAP以外にも選択肢があるわけで。
  • Krita
  • OpenToonz
  • Pencil2D
  • CLIP STUDIO PAINT
  • MohoPro 12
等々…。

_Krita | デジタルでのお絵描きと創造の自由を
_OpenToonz
_Pencil2D Animation - Opensource animation software

しかも、それらのソフトは、オニオンスキン等も簡単にon/offできるし…。これがもし、GAPでオニオンスキンを使おうとしたら、ちょっとググらないと操作方法が分からないぐらい面倒なわけで…。再生プレビューも、それらのソフトはサクサク表示できるけど、GAP は小さいサムネイルで確認する感じだし。

GAPを使わないとできないこと…何があるだろう…。

2018/12/21(金) [n年前の日記]

#1 [gimp] まだGIMPを触ってる

まだGIMPを触ってる。環境は Windows10 x64 version 1803。build 17134.472。

GIMP 2.10.8 Portable 64bit版では手持ちのプラグインが使えない。 :

GIMP 2.10.8 Portable 64bit版に対して、今まで使ってたプラグインが入ってるフォルダを追加登録してみたら、GIMP起動時にどれもこれもエラーが発生してしまった。しかも、何故か GIMPウインドウ内のアイコンが全て壊れてしまい、再起動しても修復されない状態になった。

考えてみたら、64bit版のアプリで 32bit版用のプラグインを動かそうとしたら、エラーが出て当然、なのかもしれない。Web上の関連文書には、「GIMP 64bit版でも32bit版のプラグインを使えるように対処した」等の記述も見受けられたのだけど…。もしかすると、GIMP 2.10.x Portable 64bit版には、そのためのファイルが同梱されてない状態なのかもしれないなと。

となると、困った。手元にある 32bit版のプラグイン群を使いたいと思ったら、32bit版の GIMP 2.10.x を使うしかないのか…。しかし、GIMP 2.10.x 32bit版は、英数字のキー入力が半角カタカナになってしまう不具合があるわけで。

GIMP 2.10.8 Portableを再インストール。 :

GIMP 2.10.8 Portable (= 32bit版) を再インストールして、せめて GTK+絡みの .dll をいくつか入れ替えたら、キー入力時の不具合が改善されないか試していたけれど、そう上手くはいかなかった。GIMP 2.10.x で追加されたプラグインが、GIMP起動時に無反応になって、数分待たないとタイムアウトして先に進んでくれない上に、GIMP のウインドウが表示された後も、結局はキー入力バグが改善されず。

ちなみに、入れ替えてみた .dll は、以下で紹介されているもの。

_Freezen of the dialoge File -> Open under Win 10 home 32bit (#1516) - Issues - GNOME / GIMP - GitLab

GIMP起動中にプラグインが無反応になるあたりは、もしかすると .dll のバージョンが合ってないのかもしれないなと。上記の5つの .dll 以外にも、プラグインの動作に必要になる dll があるのではないか…。

以下によると、glib 2.56 (libglib-2.0-0.dll その他) は不具合が起きて、2.54.3 までダウングレードしないと治らないらしい…。

_Japanese input broken with glib 2.56 on Windows 32-bit (#1421) - Issues - GNOME / GLib - GitLab

Windows用の GTK+バイナリ (Runtime?)だけどこかで公開されてないのかなとググってみたけど、どうも Windows の場合、「msys2をインストールしてビルドしてくれよな」ぐらいの情報しかないようで。

_GTK+ Download: Windows

英語キーボードに切り替える策。 :

一時的に、Windows10 のキーボード設定を ―― 「日本語 Microsoft IME」から「英語 (米国) USキーボード」に切り替えて使う方法もあることに気づいたり。この状態なら、GIMP 2.10.8 Portable (32bit版)でも、英数字のキー入力がフツーにできる。

しかし、記号の入力が…。キー刻印と違う記号が打ち込まれてしまうわけで…。

#2 [tv] 「昭和元禄落語心中」実写ドラマ版最終回を視聴

漫画を原作とする実写ドラマ。NHKで放送。録画してた最終回をようやく視聴。

映像作品としてはアニメ版が既に存在していて、そちらは、演出も、声優さんの演技も、見ていて唸るほどの非常に良い出来だったのだけど。さすがに実写ドラマ版はあのレベルまでいかないだろう、けど、一応眺めておくかなー的に見始めたら、これが結構良い出来で。結局最後まで見てしまった。

ラストのあたり、舞台上のソレと観客席のソレをシンクロさせたソレとか、EDの静止画に対して最終回で一工夫、てなあたりに感心。しかもラストの台詞が…。劇中人物は笑っているし、微笑ましいシーンのはずなのに、見ているこちらは若干ゾクリときてしまった。アレは上手い。

ただ、全般的に、師匠の青年時代と老年時代を一人の俳優で演じさせた点はちょっとどうかなと思ってしまった。老けメイクでずっと通すのは、見た目的に厳しい…。もっとも、若い頃はイケメンだった人物が歳を取ってもやはりイケメン、という設定を通すためにはその手しかないかもな、とも。年配になっても業界に残ってる男性役者さんとなると、顔からしてイケメンとはちょっと言い辛い独特の雰囲気の方ばかりなわけで。イケメンの面影が残ってる年配の役者さんは、まず居ないだろうなと…。であれば、まだ老けメイクで見せたほうが設定には忠実、と言えなくもないよなと。

また、師匠の落語が弟子より下手に見えてしまったあたりも困惑したり。もっとも、コレも設定上難しいところで。若い頃は同期にコンプレックスを感じてしまうレベルで、歳を取ったら弟子の勢いには負ける感じの雰囲気だろうから…。同期より上手くてはいけないし、弟子より元気が良くてもいけない。どの時期も、ビミョーな位置を感じさせつつ、しかし世間や弟子からは上手いと思われてる落語…。これは演じるのが難しくて当然。実写はそのあたりが難しいなと。

さておき、なんとなくだけど、アニメ版よりは、「繋いでいくこと」を前面に押し出していた印象も感じたり。出産のソレもそうだし、元恋人の最後の言葉もそうだろうし、ラストの風景もそうだろうし。そこで一本、筋が通ったドラマになっていた、ような気もするわけで。

なんにせよ、これは良いものを見せていただきました。アニメ版も素晴らしかったけど、実写版もやるなあ、みたいな。

2018/12/22() [n年前の日記]

#1 [gimp][windows] USキーボードのレイアウト図を作成

GIMP 2.10.8 Portable (32bit版) を、日本語版 Windows10 x64上で動かすと、テキスト入力欄や数値入力欄で、英数字を直接入力できなくて、何故か半角カタカナで打ち込まれる不具合に遭遇する。

WindowsのIMEを無効にして、USキーボード設定(英語キーボード配列)に切り替えれば、英数字を打ち込める状態になるけれど。その場合、記号の入力が、日本語キーボードのキー刻印とは異なる状態になるので、やりづらくなる。

ということで、日本語キーボードのレイアウトと、USキーボードのレイアウトを図にしたものを、Inkscape で作ってみたり。

keyboard_layout_jp_us_01.png
_keyboard_layout_jp_us_01.png
pdfにもしてみた。

_keyboard_layout_jp_us_01.pdf

Inkscape で保存した svg も zip にして置いときます。

_keyboard_layout_jp_us_01.zip

CC0 / Public Domain ってことで。

キーボードカバーに印刷できないかな。 :

透明で薄いキーボードカバーの上に、英語配列のソレを印刷した製品があれば、こういう時に便利だったりしないかなと。あるいは、英語キーボードのソレをキーに貼り付けられるシールとか。

もっとも、日本語キーボードから英語キーボードに設定を切り替えないといけない場面が存在してる、その状況自体が本来はマズイわけだけど…。バグが取れたらその手のグッズは不要になるし…。

2018/12/23() [n年前の日記]

#1 [anime] 「ブラッククローバー」63話を視聴

作画がスゴイ…。これはちょっとメモしておかないといかん気がする。ブラッククローバー、#63。これはスゴイ。

もっとも、あまりに凄過ぎてもはや何をやってるのか分からん映像になってたあたりはアレなんだけど、逆に言えばそのくらい大暴れだったわけで…。それでいてCGも組み合わせて面白い映像になってたカットもあったりして…。何にせよ、映像を見ているだけで圧倒されてしまった。この回はスゴイ。

それはともかく、こんな回に限ってED映像が小さくされて、L字テロップ。スタッフ名もますます読みづらく。これは酷い。誰だよ…こんな画面にしろと指示を出したのは…。

#2 [anime][neta] 実は口パクって要らないのでは

思考メモ。

TV映像をBGVにしながら作業をしていると、何かの拍子にNHKの幼児向け番組が映ることがあるのだけれど。画面を見ていて、ふと気づいた。

着ぐるみキャラって、えてして口が動いてないよな…。でも、体全体でアクションしながら、そこに声優さんがそれらしい声をあててるだけで、ちゃんとそのキャラが喋ってるように感じてしまうよな…。口が動いてないのに喋ってる、その光景に対して、文句を言う幼児の姿も、ちょっとイメージしづらいな…。

それを考えると…。もしかしてアニメキャラも、実は口パクが要らなかったりするのでは…。もちろん人間に見えるキャラが口を動かさずに喋っていたら「いっこく堂かよ」とツッコまれるだろうけど、マスコットキャラの類っぽく見えるキャラデザだったら、口パクが無い状態で喋っていても結構イケるんじゃないのか…。

などと書いているうちに、実際それに近いことを試してるアニメがあったことを思い出した。「CONCEPTION 俺の子供を産んでくれ!」というゲーム原作アニメには、狸っぽいマスコットキャラが登場するのだけれど、そのキャラはほとんど口を動かさずに、しかしベラベラ喋ってた気がする。最初のうちは若干違和感があったけど、何話か眺めていたら「これはそういうキャラだから」で気にならなくなったわけで。

考えてみたら、「宇宙戦艦ヤマト」に登場するアナライザーもソレに近いのではないか。彼も口パク無しで喋ってる…。もっとも、アレはロボットだから、口を動かさずに喋っていても不自然さを感じないのだろうけど。 *1

つまり、スケジュールの厳しさが予見される企画においては、着ぐるみだのロボットだのに見えるキャラの割合を増やして、口パクも節約するという手が…。いや、まあ、たいした節約にはならない気もするけど。

とは言え、「キャラが出てきて喋っていたら、必ず口パクを入れないといけないのだ」と思い込む必要は無さそうだなと。そのあたりはキャラデザによるのだろう。

外国ではまた違うのかも。 :

日本国内では口パクが無くても気にならない可能性がありそうだけど。外国ではまたちょっと事情が違うかもしれないなと。あちらは、台詞と口パクのタイミングが合ってないと、観客・視聴者がかなり違和感を覚えるそうで。そのせいもあって…。
  • サンダーバードの人形達は音声を元に口を動かす機構をわざわざ発明したらしいし。
  • あちらの何かのアニメにおいては、リップシンクを意識し過ぎたあまり、口だけ実写のソレを合成したものすらあるらしいし。
  • あちら向けのアニメ制作ツールにおいても、リップシンクの自動化機能の有無は売りの一つになっているし。というか無かったら「何考えてんの?」扱いだし。
  • そういえば、セサミストリートに登場するキャラのほとんどは、口を動かす系のデザイン・機構だったよな…。
海外向けを意識した場合は、日本国内と同じノリでは作れないかもしれないなと。

もっとも、日本語の台詞を喋ってる状態でみっちりとリップシンクをしてみても、英語で吹き替え等をしてみたらタイミングがずれまくるので、そのあたり気にしても意味がない、ような気もする。まあ、わざわざ英語で吹き替えをしてもらえる日本製のアニメがどのくらいあるのか分からんけど…。

*1: アナライザーはひょっとすると、喋るタイミングで松本メーターを光らせてる可能性が…。実際に映像を見てみないと分からないな…。

2018/12/24(月) [n年前の日記]

#1 [pc] ペーパークラフトを作成

以下の記事を眺めてるうちに、なんだかムラムラと作りたくなってきた。

_Apple II、Amstrad CPC 464などのペーパークラフト。自分で印刷できます | ギズモード・ジャパン
_Apple II - Papercraft Design - Rocky Bergen
_Commodore 64 Papercraft V3 - Rocky Bergen

ということで、作ってみたり。

papercraft_c64.jpg


憧れのコモドール64…。もっとも、当時の自分が憧れてたのは _VIC-1001 だったけど。

思ったこと。 :

「ペーパークラフトと言えば厚みのあるマットフォトペーパーだろう」と、安易に Canon マットフォトペーパー MP-101A4 を発掘して印刷してしまったのだけど。失敗した…。普通紙に印刷すれば良かった…。コモドール64は丸みのあるデザインなので、マットフォトペーパーは暑過ぎて丸みがつかない…。たぶんコレ、普通紙ならそれなりに丸みがつけやすいのだろうなと。

相変わらず思ったけれど、糊付けがやはり面倒臭いなと…。大体にして、紙とカッターならどの御家庭にもあるだろうけど、糊って今時はあまり無いよな…。少なくとも自分の部屋には…固まってしまった木工用ボンドや、封を切ってない瞬間接着剤はあるけど…。

糊付け不要のペーパークラフトって、作りづらいのかな…。ノウハウが必要だろうな…。

#2 [pc] MZ-80Kの写真画像を眺めてる

コモドール64のペーパークラフトを作っているうちに、どうせなら日本国内で普及してたPCのペーパークラフトを作りたいよなと思えてきて。そんなわけで MZ-80K のペーパークラフトを眺めていたのだけど。

_MZ-80K ペーパークラフト ( パソコン ) - MZ-80 パソコン開発物語 - Yahoo!ブログ
_【はじめての3DCG】:MZ-80

画像がjpegなので、その手のノイズが…。キーボードや画面のテクスチャもぼけちゃってるし…。 _ペパクラビューワー4 をインストールしてペパクラデータ版も眺めたけれど、そちらもテクスチャがボケボケで…。

せめてテクスチャだけでも作り直すか、と思ったけれど、MZ-80Kのキーボードのあたりがよくわからず。そんな感じで、写真画像をググって集めて眺めているところ。

カセットデッキの色がよく分からない。 :

カセットデッキ(データレコーダ?)の色が、黒だったり白だったりしてよく分からないなと…。蓋の部分が黒いのは間違いなさそうだけど…。

モニタ部分の色もよくわからない。 :

モニタ部分のカバーの色も、赤、灰色、緑があってよく分からない。いや、緑はMZ-80K2Eなのかな…。

MZ-80Cもモニタ部分が赤いけど、MZ-80CはMZ-80Kと比べてキーボードがフツーの配列に近い感じになってるようで。

2018/12/25(火) [n年前の日記]

#1 [anime] 「ルパン三世PART5」6話を視聴

素晴らしい。この回は素晴らしい。

5話までの連続話も上手いなーと思って見ていたけれど、いきなりここで昭和ノリで見せてくるとは…。冒頭の 「よっこりしょういち」で、思わず変な声が出てしまったほど驚かされた。こんな台詞で…悔しい…。

ルパンがピンクジャケットなあたり、「パート3のノリを再現してみたい」というスタッフ側の明らかな意思表示だろうけど。これはなかなか見事な昭和臭。おじさん達には懐かしい、回によって・脚本家によって、その場の思い付きでメインキャラの性格も設定も平気でコロコロと変わってしまう、あの頃のルパン、だったなと…。

脚本・コンテは、今回のシリーズの副監督を務める酒向大輔氏。 _「ルパン三世がやりたくて業界に入った」 と発言するだけあって、見事なルパンでした…。あの当時の、昭和アニメの雑さ・テキトーさ・くだらなさを、全力で再現するというある種の暴挙。いやはや、シビレました…。本編のとぼけた感じとは裏腹に、制作姿勢がロックだ…。

もっとも、最近の若い人は、「こんなのルパンじゃない!」と絶対言い出すだろうけど。でもまあ、何かの拍子に大昔のルパンシリーズも目にしてもらえれば、「あっ…PART5のアレも…たしかにルパンだったわ…」と気付いてもらえるだろうなと。

監督の数だけルパンは居る、みたいな評が一部で上がっていたほど、その時々の作り手によって何もかも違ってくるのがアニメ版のルパンシリーズ。何せ昔は、カリ城ルパンに対しても「あんなのルパンじゃない!」とブーイングする人達が大半だったのだから…。当時の主流だったルパン像は、ほとんどが今回みたいなノリだったわけで…。 *1 なので、「こんなのルパンじゃない!」という感想も、時代が経つと「そうだね。これもルパンだね」に変わるだろうなと。

なんとなくだけど、何が出てくるのか分からない、何でもアリなのがルパンシリーズ、なのかもしれないなと思えてきたり。

そもそもルパンは変装の名人。あまりに変装し過ぎて自分の本当の顔も忘れてしまった、なんてエピソードもあるそうで。今回は昭和ルパンに変装したんだなあ、あまりに変装が上手過ぎてナウいヤングが軒並みついていけないぜ、てな捉え方だってできるのかもしれないなと。
*1: カリ城は、パート1の後半を丸々担当した宮崎駿+パート1のキャラデザを担当した大塚康生という、正真正銘、本来のルパンのメインスタッフ構成だったのに、パート2しか見てなかった子供達から偽物扱いされちゃうという…。

2018/12/26(水) [n年前の日記]

#1 [moho] Mohoでマルチプレーンカメラ相当のソレを実験

随分前に作業してデータは作ってあったけど、アップロードする機会を逃していたので、この際アップロード。

前提。 :

アニメ制作がフィルム撮影からデジタル撮影に移行したことで、マルチプレーン・カメラ相当についてはスペックが超絶パワーアップしたのではないのかなと個人的には思っていて。

_マルチプレーン・カメラ - Wikipedia
_2次元の絵で3次元的な奥行きのあるアニメーションを制作するために使用された「マルチプレーン・カメラ」の解説ムービー - GIGAZINE
_ふるさと文化講座「東映アニメーションのマルチ撮影台」公演の様子 - YouTube

フィルム撮影時代、マルチプレーンカメラにおいて、扱えるセル・BOOK枚数は、機械の見た目からして明らかに有限だったろうけど。デジタル撮影になった現在、フィルム撮影時代と比べれば、ほぼ無限と言ってもいいぐらいに扱える枚数が増えたはずだよなと。 *1

で。そのように超絶パワーアップした道具をせっかくゲットできたのだから、ソレを使って何か面白い映像が作れたりしないものかなー、と思ってしまったりもするわけで…。

例えば、奥行方向(z軸方向)に延びてる何かしらの物体を、奥行方向でたくさんスライスして、z軸に沿ってずらりと並べてカメラを動かしたら、めっちゃ空間を感じられる映像になったりしないかな、と妄想を。

てなわけで、Moho Pro 12 を使って試してみたり。

結果。 :

まずは、背景画一枚を置いて、カメラを移動した場合。



次に、ロボットの頭、胸、肩、腕、腰、格納庫の壁、でレイヤー分けして、それぞれのレイヤーの、z値と拡大縮小率を変えて配置して、カメラを動かした場合。



最後に、背景を3DCGでレンダリングした場合。ちなみに、使った3DCGソフトは blender。

感想。 :

正直ビミョー。どうなのコレ。

試す前は、きっとムンムンと空間を感じる映像になるのではないかとワクワクしていたのだけど。実際やってみたら、これがあんまり…。こんなはずでは…。

ただ、少なくとも、一枚の背景画をズームするよりは、何枚かレイヤーで分けてあるほうが、まだ全然空間を感じられるような気はするなと。

また、3DCGでレンダリングしたソレは、思っていたほど空間を感じられるわけでもないなと。コレなら、レイヤー分けして作った映像と大して変わらない気もする。カメラが奥行方向に移動する程度の単純な動きなら、わざわざ3DCGでやる必要は無いのかもしれないなと。おそらく、カメラ位置だけではなく、カメラの向きも大きく変化する映像なら、3DCGでやる意味も出てくるのではないかしらん。

そもそも人間の目は、細かく分けられたレイヤーが、各々ビミョーにズームする様子を、個別に捉えられないのではないか、という気もしてきた…。この場合、ロボットの上半身、下半身、背景の壁、といった3枚程度で分離してズームするだけでも充分じゃないのか、という気がする…。

ロボットっぽい形のモノだから効果が薄いのかもしれない。例えば、TVゲームの _アフターバーナー_ギャラクシーフォース の背景のように、木だの岩だのパイプだの、小さい何かがびっしり置いてある、みたいな映像だと印象がまた違ってくるのかも…。

何にせよ、せっかくゴイスな道具が手に入っても、人間側がナイスなアイデアを出せないと宝の持ち腐れだなと…。

*1: 実際は、撮影ソフト側で枚数制限があったりするだろうけど…。それでも、フィルム撮影時代と比べたら桁違いの上限、ではないのかなと。

2018/12/27(木) [n年前の日記]

#1 [pc] Sonic Piを試用

たまたま何かの拍子に Sonic Pi なるソフトの存在を目にしたので試しに触ってみようかと。Windows、Mac、Raspberry Pi 等で動かせる、サウンド関係のツールらしい。プログラミングをするようなノリで音を出せるソフトなのだとか。

_Sonic Pi - The Live Coding Music Synth for Everyone
_Sonic PiでSoundProgramming! - Qiita
_Sonic Piメモ
_ライブコーディング入門:Sonic Pi篇パート1
_Sonic Piで音プログラミング! | Device Plus - デバプラ

とりあえず、Windows10 x64 上で Sonic Pi Portable版 Sonic-Pi-for-Win-Portable-v3.1.0.paf.exe をDLしてインストールしてみたり。

起動したらエディタ部分のフォントがかなり大きく…。「Size -」というボタンを何度もクリックして適切なサイズに。

各記事で紹介されてる事例を打ち込んで音を確認してみたり。結構イイ感じの音が鳴るのだな…。

#2 [zatta][neta] ○○を○○に置くと○○ができるソレ

寝ていたら夢の中で、なんだか気になる光景を目にした。お店の中にSLのプラモデルが飾ってあるのだけど、店長さんがそのプラモデルをPCに繋がってる盤のような何かに置いたら、途端にSLの汽笛の音だの、走ってる時のシュッシュッポッポッみたいな音が聞こえてくる、みたいなソレで。

目が覚めてから、なんだか考えてしまった。サウンドデータという、目には見えないモノを、プラモデルという形で分類かつ可視化した状態と言えなくもないのかなと。コレもある種のオブジェクト化、なのだろうか。

まあ、上記のソレは、「夢の中で凄いアイデアを思いついた」とかそういうアレでは全然なくて。その手の商品・製品は既に存在しているから、ソレが夢にたまたま出てきただけの話、なのだけど…。

たしか、大昔に、親戚の子供さんがそういう玩具を家に持ってきた記憶が…。ポケモンのフィギュアを何かの盤に乗せると、フィギュアの種類に応じて何かのデータを表示して遊べますよ、みたいな玩具で。ググってみたけど、たぶんコレかな…。

_データフィギュアを使ったポケモンバトルが楽しめる トミー「バトルタワースタジアム」 - 気になるe-Toy遊んでレポート

どういう仕組みで動いているのか個人的にはかなり不思議だったけど。盤本体がデータを持っているのか、それともフィギュア側がデータを持っているのか…。

任天堂も、一時期そういう商品を出していた気がする。フィギュアに何かのデータを紐づけて、ゲームと連携していたような…。ググってみたけど、コレかな。

_amiibo - Wikipedia

コレは、NFCタグを使ってますよ、と説明されてるな…。

また、昨日、タイミングよくそういう作例を目にしたなと。NFCタグを利用して、CDケースをスピーカの上に置くと、CDケースに対応した曲が流れ始める、という仕組みだそうで。

_オーディオプレイヤーを再デザインした話。 またはIoT時代のOOUXについて。 - ワタナベ書店

コレ、安くなったとはいえ、NFCタグを使うあたりがコスト的になんだかアレだなと。QRコード等で処理できたら、プリンタで印刷したソレを貼り付けるだけで済むからコスト的にはイイ感じになったりしないだろうか。もっともその場合、読み取り側の仕組みが面倒なことになりそうか…。光学系のアレコレが入ってくるもんな…。

何にせよ、目の前に実際に手に取れるブツがあって、ソレを所定の場所に置くことで何かしらができますよ、という仕組み自体は玩具その他で既に利用されていて。こういう仕組みを他の何かしらに利用できないものかなあ、などとちょっと夢想したりもするのです。「そうか。そういう使い道があったか」「あの機械の操作を、この仕組みで置き換えると、めちゃくちゃ直感的になるなあ」みたいな何かが出てこないものかなと。

考えてみたら、ケータイだのカードだのをかざすと支払いができる、なんてのもソレなのかな。フィギュアやミニチュアを置くと何かが起きる、てなソレと比べると、随分とお堅い印象は受けるけど、似たようなものだよな…。

PCのアプリの起動を、こういうソレにしてみたらどうなるだろう。ラジカセのミニチュアをどこかに置くとメディアプレイヤーが起動するとか。…マウスでアイコン選んでクリックしたほうが早いか。

フィギュアと読み取り側を逆にしたらどうなるだろう。フィギュアを動かしてどうこうではなく、スマホのカメラでフィギュアを映すと…みたいな。なんだか既にありそう。

2018/12/28(金) [n年前の日記]

#1 [cg_tools] 年賀状用のイラストを作成中

年賀状用のイラスト画像を作成中。

最近、 _TIC-80 を少し触ったことでドット打ちが楽しくなってきたので、年賀状のソレもドット絵にしようかと思ったけれど。それもなんだかアレだなと思ってきて若干3DCGっぽくしたいなと。ということで、 _MagicaVoxel を起動して作業を始めたり。ただ…3Dでドット打ちは…難しいな…。感覚が掴めない…。

2018/12/29() [n年前の日記]

#1 [pc] 手持ちのプリンタがそろそろマズイ感じ

年賀状を印刷しようとしたら、手持ちのプリンタ、Canon iP4600 の後トレイが年賀はがきを送れなくて困ったり。紙が入った、と思ったらそのまま何もせず排出したり、あるいはちょっとだけ入ったところで止まったり。めちゃくちゃ古い製品・個体だから、寿命かな…。どこかのローラーがダメになっているのかも…。

プリンタのプロパティ → ユーティリティ → 給紙ローラクリーニングを行ってみたけれど、変化なし。

紙がプリンタ内に飲み込まれるタイミングで、ほんのちょっとだけ指で押し込むかのような気持ちで軽くうっすらと圧力をかけたら、読み込んで印刷してくれた。どうも、紙を飲み込む際に、紙が滑ってる気配がする…。「ここまで飲み込めたら異常無し」として処理する位置までスムーズに紙が送られないと、そこで異常が起きたと判断して止まるようだなと。

後トレイから紙を入れる場合は不具合が起きるけど、下部のカセットトレイから普通紙を送る分には問題無く動いてる模様。インクジェットプリンタ向けハガキは表面が普通紙よりもツルツルしてるから、それで滑ってるのかもしれない。

2018/12/30() [n年前の日記]

#1 [zatta] 蛍光灯の種類を間違えて覚えてた

部屋の蛍光灯がなかなか点かなくなってきて、新品と交換しないといかんなと。親父さんが電器店に行く用事があるとのことで、「昼白色」の蛍光灯も買ってきてとお願いしたのだけど。買ってきてもらった蛍光灯のパッケージを目にして後悔。「ナチュラル色」と書いてある…。

自分、何故か、電球色<昼光色<昼白色、の順で明るいものと思い込んでた…。電球色<昼白色<昼光色、だったのだな…。わざわざPanasonicが「クール色」「ナチュラル色」と混同しないような種類名をつけて店頭に置いてあるというのに…。

でもまあ、今まで使ってた、真っ黒になりつつある蛍光灯と比べたら、新品だけあって全然明るいので、使い物にならないというわけではないのだけど…。失敗した…。

たぶん、太陽光に近い色=昼光色、と間違って覚えていたのだな…。太陽光より明るい色=昼光色、と覚えておくべきだったのだろうか…。

#2 [nitijyou] 年賀状を出してきた

今年はなんとか年末中に年賀状を作れた…。もっとも、今から出しても元旦には届かないだろうけど。

2018/12/31(月) [n年前の日記]

#1 [nitijyou] ドンキホーテとやらを見てきた

近所でドンキホーテなるお店が開店したらしいので見てきたり。

自転車の駐輪場が無いな…。気が利かない…。

駐車場はほぼ満杯で、店内も混雑していた。親子連れが目立った気がする。

色んな商品が置いてある店なのだな…。なんとなく、ホームセンター+ドラッグストアな感じ。ゲーミングマウスまでいくつか置いてあったのは驚いた。

ただ、火事になったら大変なことになりそうな予感がする店内のレイアウトだった気もする。通路幅等が十分に確保できてない上にどこが出口か分からない配置になっていて、いざという時に客が逃げられないのではあるまいか…。

#2 [nitijyou] 弟が帰省

16:45頃到着。

弟が寝泊まりできるように、午前中に部屋を掃除しておいた。

#3 [pc] 手持ちのタブレットPCがベタベタになってた

手持ちのタブレットPC、DELL Latitude 10 の、ガラス面と本体のラバー部分の間から接着剤のようなものがにじみ出ていてベタベタする状態になってた。ショック。

弟曰く、シールはがしで取れないか、との話で。ダイソーで買ったシールはがしが部屋にあったので、綿棒に染み込ませて拭いてみたら多少は取れてきたけれど、それでもまだベタベタする…。

ちなみに、シールはがしにも種類があって、オレンジから抽出した系のソレはプラスチックを溶かすのでこういう場面で使ったらマズイらしい…。

以上、31 日分です。

過去ログ表示

Prev - 2018/12 - Next
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31

カテゴリで表示

検索機能は Namazu for hns で提供されています。(詳細指定/ヘルプ


注意: 現在使用の日記自動生成システムは Version 2.19.6 です。
公開されている日記自動生成システムは Version 2.19.5 です。

Powered by hns-2.19.6, HyperNikkiSystem Project