Harmless Weblog

公開後1年の記事に書いたのをきっかけに、改めて反響音(リバーブ処理)の追加に取り組んだ。

しかし、元々のWeb Audio APIを使ったコードが「コピペコーディング」で、どうにか動くようにしたものなので、リバーブの処理をやはり参考のサイトからコピペしても、うまく動かず。

参考サイト：

• WEB SOUNDER - Web Audio API 解説
• Web Audio API 解説 - 16.コンボルバーの使い方 - g200kg
• ブラウザで動くアゲアゲなシンセサイザーをWeb Audio ... - Qiita

どうやら非同期処理の影響らしい、ということはなんとなくわかる。インパルス応答のwavファイルをAudioBufferとして読み込んで、Conbolverノードを原音とミックスして出力する、というときに、wavファイルをAudioBufferに読み込む処理が時間がかかるので飛ばされて、先に他の処理が走ってしまう。

このように時間のかかる処理の終了を待ってから次に進む、というのがJavascriptで言うところのコールバック、Promise、Async/Awaitなどで、関数が結果を返すまで実行を待機する。

と、教科書的なことはなんとなくわかるんだけど、実装するとうまく動かない。参考にしたコードでは、AudioBufferの読み込みにAsync/Awaitを使っているので、コピペしてみたところ、確かにエラーは出ないけれど、iPhone/iPad環境で、1回目の再生で音が鳴らない。パソコン環境だと動く、という微妙な状況。

結局3週間ほど週末に集中的にデバッグとリファクタリングに取り組んで、ようやくテストしたすべてのデバイスでエラーなく1回目で音が出るようになった。テストした環境は下記。

• Windows10 Chrome
• Windows10 Edge
• MacOS Monterey Chrome
• MacOS Monterey Safari
• Android Chrome
• Kindle Silk
• iPad Safari
• iPad Chrome
• iPhone Safari

一番のキーポイントは、window: loadイベントをasyncにしてAudio Context関係の処理をすべて囲んで、loadイベントの最初にawaitでインパルス応答の読み込み処理を済ませてしまうことだった。これはつまり参考サイトの構成そのまま。やっぱり独自にヘンなことをするのではなくて、基本に忠実にするのが結局一番確実ということだった。

処理はできるようになったんだけど、インパルス応答(IR)のwavファイルをどうするかが問題。理想的には総合通信士の試験会場でインパルス応答を測定できれば良いけれどそれは無理だし、似たような会場で測定しようにも機材がない。ネットでフリーで使える素材も限られている、というのが今回わかった。幸い、非商用に限りフリー、というコンサートホールのIRがあったので、これを使わせていただいた。

• Concert Hall Impulse Responses - Pori, Finland：(非商用の場合に限ってフリー)

重い腰を上げてリファクタリングに取り組んだので、ついでに気になっていたCSSも全面的に修正。pure.cssというフレームワークを使わせていただいているけれど、その親要素で縛られているところがなかなかわからず、cssの指定が効かないと思ってデバッグに時間がかかった。Chromeのデベロッパーツールの要素タブを睨みながらなんとか親要素を部分的にオーバーライドして、所望の動作をするようになった。

これまでの一時停止機能、反響音機能を通してまだまだ汚いながらもリファクタリングはできたと思うし、自分自身のJavascript、CSSの勉強になった。

あとはPWA対応が残っているけれど、日替わりでデータを読み込む必要性があるので、ネイティブアプリっぽくしてもあまりメリットはないかも、と思って優先度は下げている。

本サイトの固定記事へのリンク

Webアプリ「日替わり通信術」

アプリの詳しい説明

Tweet

Webアプリ日替わり通信術練習(モールス受信)を公開して1年になる。

おかげさまでTwitterやメールでアプリを使っていますとレスポンスをいくつか頂くようになり、嬉しいことにアプリを使って頂いた2名の方が2022年3月期の一総通試験で見事に合格された。元々かんなさん(奥様)の受験サポートのために開発したアプリだったけれど、公開したことで多少なりともお役に立てたようで嬉しい。

冗談半分で合格者倍増を狙っていると公開時に書いたけれど、残念ながら2022年3月期から合格者(受験番号)のネット公開はされなくなって、受験者への個別メール連絡のみとなってしまったため、アプリの効果を定量的に測ることは困難になってしまった。もしアプリを使っておられる方で合格された方はTwitterやjarl.comのメール宛にお知らせ頂ければありがたいです。

ダウンロード不要で利用登録など何もない単なるWebアプリなので、利用者がどれくらいいらっしゃるのかはわからない。レンタルサーバのアクセス記録から、通信術アプリのファイルが読まれた回数を数えて、ざっくり利用者数を推計したのが下のグラフ。9月期の試験までに徐々に利用者が増え、試験後にいったん減って、年明けに3月期の試験に向けて増加が見られる。受験者数は100名ほどだし、なんとなくオーダーは合っているように思う。もちろん日替わり問題を1日に何度もこなしている方もいると思うので、ユニークユーザはもう少し減るだろう。

「一総通 通信術 モールス」等のキーワードで検索するとトップページに表示されるので、今のところモールス受信術の練習アプリとしては高いシェアを獲得しているものと思うけれど、それでも利用者は30名とかその程度。完全無償のアプリでもこうなので、一総通向けの市販教材やツールが皆無なのも仕方がない。まったく商売にならない超ニッチな分野ということがよくわかる。

公開後の1年で、メジャーなアップデートとしては以下のような感じ。いずれも利用者さんからのリクエストや指摘で実装したもので、重い腰を上げられたのは利用者さんのおかげだと思う。

• 一時停止機能の実装
• 欧文の語間スペースの調整機能の実装
• 本文表示を改良

現在開発・テスト中のブランチとして、PWA(Progressive Web Apps)への対応がある。これはWebアプリをネイティブアプリのように使えるようにする技術。強力なキャッシュ管理でオフラインでも(まるでネイティブアプリのように)使えるのがメリットなんだけど、iOSだとキャッシュが強力すぎて日替わり更新が反映されないという問題が解決できずにスタックしているところ。

開発頓挫したブランチとしては、音源保存機能の実装がある。元々はラズパイでmp3の音源を作ってアップするところからスタートしているけれど、これだと速度などが決め打ちになってしまうし、スマホ利用だとダウンロードのパケットを消費する。そのためにWeb Audio APIでリアルタイムに生成する方式に変えた経緯がある。このmp3を作るPythonのプログラムがcgiとしてレンタルサーバ上で動かせれば可能かもしれない。

あとリクエストというほどではないけれど、複数の受験者の方から、試験会場ではモールスの音が反響して聴きづらかったという指摘があった。これについてはリバーブをかけるオプションを追加できたら良いと考えているけれど、のんびり取り組もうと思う。→反響音効果を実装しました(2022.4.22)

本サイトの固定記事へのリンク

Webアプリ「日替わり通信術」

アプリの詳しい説明

Tweet

日替わり通信術アプリをご利用の方から、本文表示の記号が実際と異なるとご指摘のメールを頂戴した。

これはアプリ開発当初から気になっていた部分で、モールス符号への変換に1バイト文字(半角英数、半角カナ)を使っていることに由来する。1バイト文字を使うと和文の濁点・半濁点の処理が簡単になるメリットはあるものの、すべての記号を1バイト文字にマップしなくてはいけないので、どうしても不自然な記号を使わざるを得ない。

例えば[ホレ]は"<"とか、欧文で[BT]は"メ"にするとか。ご要望があったのは、和文の段落(」)を句点(。)で表現するのがわかりづらいという点。そのうちゆっくり直せばいいかな、と思っていたけれど、せっかくご要望をいただいたことだし、ちょうど総合通信士試験が終わった時期でアプリをメンテナンスしても影響が少ないということで、着手することにした。

【従来の本文表示(和文)】

【従来の本文表示(欧文)】

ところでアプリを公開してラズパイ4を買ったあたりから、スクリプトのバージョン管理にgitを使うようになった。一応公開したアプリでもあるし、きちんと管理した方がいいな、という気持ちで始めたものだけど、今では手放せない便利ツールになっている。

今回だとリリース済みのjavascriptのmasterブランチには手をつけず、新たに本文表示改善用のブランチを切って、修正を開始。うまく動いたところまでコミットしながら進めて、試験運用まで。もし不具合があればmasterブランチをチェックアウトすればすぐに戻せるし、NASやGithubのリモートリポジトリにpushすればそのままバックアップになる。試験運用で問題がなければ、masterにマージすれば良い。

gitを使う前はどうしていたかというと、スクリプトファイル自体を別名(バージョンが変わるごとに01,02,03とか)でコピーしたり、コードの中身も変更するところは古いコードをコメントアウトして残しておいたり、ひどいものだった。

今回は1バイト文字で本文を自動生成する部分には手を付けず、Webアプリで本文表示する際に全角文字と記号の変換をさせるようにした。こうすれば電報文の自動生成と音を鳴らすところは従来通りなので新たなバグを作り込むリスクは低い。

javascriptで半角カナ→全角カナの変換は、参考になるサイトがあって、必要な記号もこれでだいたい対応できる。「?」だけはエスケープが必要で、キーマップに入れるとエラーになる。

苦労したのは時刻のところの数字の略体の解釈。時刻部分に限り、カナの「イウクハホタム」をそれぞれ[一][二][三][七][八][九][〇]にマップしなくてはいけない。これは結局キレイなコードは書けず、replaceのメソッドチェーンでズラズラと並べる力技で解決した。もう少しエレガントなコードを書けるようになりたいものだ。

【改良後の本文表示(和文)】

【改良後の本文表示(欧文)】

本サイトの固定記事へのリンク

Webアプリ「日替わり通信術」

アプリの詳しい説明

Tweet

Webアプリの日替わり通信術(モールス受信)は公開からもうすぐ1年になる。少しずつではあるが、ツイッターやメールで使っていただいていると報告を頂くこともある。アプリ利用者の中から合格者が出ることを祈りたい。

ツイッターで、語間スペースが狭いのでは、とご指摘をいただいた。これはバグわざとで、普通は2語の間の間隔は単点7個分となっているけれど、総通受験者のヒアリングで「語間が狭く感じた」というレポートがあったため、狭くしてある。狭い状態で練習して慣れておけば本番にゆとりが生まれるはず。

とはいえ標準的な間隔を知っておくことも重要だと考えて、語間の調整機能を実装。語間を決め打ちでソースを変更するのは簡単なんだけど、狭いのと標準を選択できたり、その設定をCookieで保存したりするのが久しぶりのコード書きで忘れていて時間を要した。

波形で比較すると、上段が「狭い」、下段が「標準」。

本サイトの固定記事へのリンク

Webアプリ「日替わり通信術」

アプリの詳しい説明

Tweet

アメリカのアマチュア無線連盟(ARRL)が主催するDXコンテスト(規約)。参加は4年ぶり。

このコンテストの時期は何かと週末用事があることが多く、なかなか参加できない。今回も土日とも朝から出かける用事があって、参加できたのは日曜日の早朝6時過ぎから8時頃まで。

局数は望めないので、久しぶりに使う21MHzモービルホイップのSWR調整をするつもりで参加。リグもたまには火を入れておこうとFT-1021Xを起動。

ベランダに三脚を立てて三脚基台にモービルホイップを取り付ける。カウンターポイズは以前自作したもの。これでエレメント長やカウンターポイズのはわせ方を変えるとSWRが変化して、だいたい1.5くらいまで追い込めた。エレメント長は標準だと長すぎて最短にしてもHi-SWRなので、買った時に金鋸で1cmほど切ってある。

FT-1021Xも久しぶりなので、ドライブレベルの調整から。送信は問題なさそうだけど、しばらく電源を入れておくと受信は信号にガリガリ音が乗る。バックグラウンドノイズは大丈夫なんだけど、CWのトーンが歪むような感じ。古いリグなので経年劣化は避けられないか。フルパワーは怖いのでパワーは100W。

この設備で、S5くらい振ってCQ空振りしている局なら拾ってもらえる感じ。でも聴こえるのは西海岸のお馴染みさんばかり。2015年の同コンテストでは中部の州や一部東海岸まで聞こえたのはサイクル24のピークだったからだとわかる。サイクル25に向けて底は脱したと思うんだけど、Condxが上がってくるのはもう少し先かな。

というわけで2時間で10局と交信。WASの新州追加はなく、初交信は3局であとはお馴染みさん。FT-1021Xの状態が心配だけど、がっつりDXをやりたい時はかんなさんにFT-991Aを借りるので、1021はもうしばらくインテリアとして飾っておこう。

WASは18州で変わらず。googleのGeochartで交信済みの州を塗ってみた。色の濃いのが今回交信した7州。

Freq. Point  Multi  QSO
----------------------------------------
21MHz   30     7    10
----------------------------------------
Score  30 x 7 = 210
Multi: NM, CA, AZ, MT, OR, WA, CO

Tweet

1日目は用事を済ませて夕方からベランダに14MHzのモービルホイップを仮設して参加。いきなり14エリア(西欧)が聞こえていて、何度も呼んでドイツと交信できてボウズは回避。

1局でも交信できればあとは気楽。とにかく設備がしょぼいので、CQ空振りの局を呼んでもスルーされる確率が8割くらい。残り2割も一発コピーはまず無理で、何度も?を送られたりコピーミスされて打ち直して、どうにか交信できるという感じ。

2日目は7時頃から。北米が入っていて、なんとか交信できた。そろそろコンディションが上がってきそうだな、というタイミングでHi-SWRで送信不可に。毎回ベランダに仮設するモビホで悩まされる症状で、カウンターポイズを触ったり同軸を触ったりすると治るときもあるけれど、一度不安定になるとどうしようもない感じ。今回もこちらから呼んでコールバックがあったのに、急にHi-SWRになってナンバーが送れなくなったり。

いったん出かけて夕方帰宅してまたカウンターポイズを触ったりしてなんとかSWR2くらいまで下げられたのでコンテスト再開。EUの局はピークS5くらいでけっこう強く聞こえるんだけど、呼んでも呼んでも届かない。他の局が呼んでいるとまず無理で、空振りしているときに呼んで、耳の良い局ならなんとかコールサインの一部が届いている感じ。だいたい「JH1?」とか聞き返されて、2回くらいミスコピーを訂正してもらってなんとか交信成立。

タワーにビームアンテナのローカル局ですら何度もミスコピーされているくらいなので、やっぱりコンディションがイマイチなのかも。できたかどうか怪しい交信も含めて10局で終了。あとでローカルさんに聞いたら、14MHzはやはりイマイチで、21MHzの方が開けていたとのこと。モビホは上に書いたようにSWRの調整がシビアで、一度調整したものは触りたくないということもあって、21MHzは聞けなかった。

たった10局ながら、まだCFMされていないエンティティの局もあって、久しぶりにNewの期待は持てるかも。しょぼい設備と成績でもコツコツと続けているのは、そうしないといろいろ忘れてしまう(LoTWへのアップロードの方法とか)のと、運良くNewエンティティとの交信ができるかもしれないということで。

Freq. Point  Multi  QSO
----------------------------------------
14MHz   28     18    10
----------------------------------------
Score  28 x 18 = 504
DXCC Multi: 3D2, BY, UA, DL, HA, K, LZ, YB, YL
Zone Multi: 3, 4, 14, 15, 16, 20, 28, 32

【過去のCQ WW CWコンテストの様子】 2020年, 2019年，2018年(不参加)，2017年，2016年，2015年，2014年，2013年，2012年

Tweet

秋の行楽シーズンの東京UHFは毎年移動運用先をどこにするかが悩ましい。今年は特に天気も良くて公園の駐車場や展望台は厳しいと予想。

観光地ではないけれど、割と有名な移動運用スポットに朝一で行ってみて、もし先客ありなら何度か使っている林道入口に変更する作戦。変更した場合もロスタイムは30分くらい。

狙ったポイントは8:30頃に到着したら先客なしでラッキー。アンテナを立てて準備をしていたら、軽バンの御同輩がいらっしゃって、「一緒に運用しても良いですか？」とのこと聞いたらどうも東京UHFとは関係なく1200とかフリーライセンスラジオとかの運用をするみたいな感じだった。やはり地元では有名なスポットということ。

車のアクセスも良く、標高800mほどで富士山方面に開けている。トイレはないけれど、500mほどのところにトイレの使えるキレイな施設があるので、車2台で来れば交代で行くことはできそう。今回はかんなさんがお仕事だったので私ひとりで移動。

設備はFT-817に7エレ八木を三脚で立てた。踏み立てくんの方が風には強いけれど、重いので。バッテリーは以前買ったモバイルバッテリー。テーブルはコンパクトになり少し高さのあるものを新調した。これはなかなか良い感じ。あとは椅子がもう少し快適だと良いな。

難点は寒いこと。ロケーションの良い場所は必然的に標高が高く風が抜けるのでこの時期は寒い。今までの東京UHFコンテストも寒さで撤退したことが何度かある。今回は上下防寒服で、平地では暑いくらいの服装で臨んだけれど、甘かった。風が吹かなければ充分耐えられる寒さだけど、風に当たっているとどんどん体力が奪われる感じ。こういうときは車内で快適に運用できる車が欲しくなる。

温かい飲み物を飲みながら、お昼はカップラーメンを作って、ひたすら430CWでCQを出す。パイルにはならないけれど、ほどほどに呼ばれる感じ。10回連続でCQ空振りはほとんどなかった。都内は28局かな。都外は静岡や長野からも呼ばれた。

9時からはじめて、13時には温かい飲み物も尽きて撤収。4時間の運用で、モバイルバッテリーは残量50%、ドンキ2in1のバッテリーは残量30%とまだ余裕があった。

Freq. Point  Multi  QSO
----------------------------------------
430MHz    117    27    86
----------------------------------------
Score  117 x 27 = 3,159
都内: 八王子,青梅,府中,昭島,調布,町田,小金井,日野,東久留米,多摩,稲城,あきる野,西東京,品川区,豊島区,板橋区,練馬区,足立区,桧原村
都外: 茨城,栃木,埼玉,群馬,千葉,神奈川,静岡,長野

【過去の東京UHFコンテスト】
2020年, 2018年, 2017年, 2016年

Tweet

今年もクラブコールで全市全郡コンテストに参加。COVID-19の第5波の緊急事態宣言が全国一律で解除された直後の開催だったけれど、宴会や宿泊は控えてコンテストに集中。

私はこの一年でクラブ局運用にもだいぶ慣れてきて、直近のXPO&AIコンテストでほぼ最適化できた感じ。具体的にはPCキーイングをクラブ局でも使えるようにして、7MHz CWでコンディションが良ければ50QSO/hr以上のレートで交信し続けられるようになった。

ただ私は夜は寝てしまうので、21時の開始から翌朝までは1.9と3.5MHzを他のメンバーにお任せ。私は朝8時過ぎから手付かずの7MHz CWで昼までと、午後は14、21、28、50、144を少しずつ。16時からは開きつつあった3.5MHzを18時頃まで。

一番稼げたのは7MHzで、163QSO。3時間半の運用だったので、レートは46QSO/hrほどと、いまいち伸びなかった。バンド内が混み合っていて混信が多かったのと、コンディションもあまり良くなかったかも。3分くらい呼ばれなかった時間がけっこうあった。

心配だった長いコンテストナンバーの聞き取りは、ノイズや混信がなければ意外とすんなり取れた。ただ数字の略体を混ぜて送られると混乱するかも。A=1、O=ゼロあたりはこちらも身構えているので大丈夫だけど、何局かU=2、N=9を混ぜて打ってきた局がいた。あと、取れたと思ってもミスコピーしていて、TUを打った後にCTESTWINでエンターで確定しようとしたら、「該当するマルチがありません」で弾かれるパターン。こうなるとどうやってもログが入らない(※)し、次の局はすぐ呼んでくるし、最初にやってしまったときはパニックで、結局後から呼んできた局を完全無視してしまった。この後はメモ用紙を手元に置くようにして、NR不正で弾かれた局はとりあえずメモ用紙に手書きしておいて、次の局を対応しつつ、CQを出している間にネットで総痛の検索をしてQTHを確かめて入力していた。そんな局が3局ほどあったかな。

※マニュアルを読んだら、マルチ不正でもCtrl+Enterで強制的に入力できるみたい。これは覚えておきたかったなぁ。スルーしてしまった局には大変申し訳ないことをした。

最終的にクラブ局全体としては500QSO以上で新記録。SSBで参加したメンバーもいたけれど、コンテストに慣れておらず1局交信するのに5分とか10分かかっていて、CWと比べるとどうしても効率が悪い感じ。ただSSBにしか出ない局も多いだろうから、マルチのためには必要かも。

クラブには今のところCWでコンテストに出られるメンバーはベテラン1名と、私とかんなさんしかいない。新しいメンバーがCWを覚えてくれる見込みもないし、難しいところ。自分たちは引退されたベテランOMさんからCWの面白さ、楽しさを教えてもらったけれど、自分はそれを後進に伝えることができていないということだよなぁ。

クラブコールでACAGコンテストに参加中です。144MHzと21MHzのCWで1時間程CQを出しました。交信していただいた各局ありがとうございました。 pic.twitter.com/UxlV9gKD3H

— KANNA JH1CFW (@p_delta_v) October 10, 2021

【過去の全市全郡コンテストの様子】 2020年，2019年(不参加)，2018年，2017年，2016年(不参加)，2015年，2014年，2013年，2012年

今年もクラブ局で参加。COVID-19感染拡大防止のため、CWのみ最小限の人数で。

CWができるメンバーの間で、「トップクラスの局はコンスタントに50QSO/hrのペースで交信し続ける」、つまり24時間のコンテストで50 x 24 = 1200局という会話をしていて、個人的に今回は50QSO/hrのレートを1時間以上続けることを目標にした。

このペースを出そうとすると呼び回りでは無理で、CQを出すことが必須。それもハイバンドではなく局数の多い7MHzでないと難しいと思う。

XPOコンテストでは朝9:30から10:30まで7MHz、10:30から11:00まで14MHzを担当。バンド内をざっと呼び回って、CQを出し始めるまでは12QSO/30分 = 24QSO/hr程度。CQを出し始めるとペースが上がって、22〜23QSO/30分 = 44〜46QSO/hrくらい。50QSO/hrまでもう少し。Condxが良ければいけたかも。14MHzにQSYするとやはりペースが落ちて、20QSO/hrくらい。

リグはFT-897(100W)で300Hzのメカフィル使用。アンテナはロータリーダイポールかな。このときはメモリーキーヤ＋CQ Oneパドルで、呼ばれた時に相手のコールサインを手打ちしなくてはならず、打鍵ミスでかなりのロスが出た。打鍵ミスは単純に練習不足で言い訳もできないけれど、手打ちだと疲れもあるし、交信速度を稼ぐためには符号の速さは維持したいし、難しいところ。

愛・地球博記念コンテストは2日目の7:40頃から12時の終了まで、休憩をしつつ7MHzを私一人で担当。リグとアンテナは同じで、レートを上げるためにPCキーイング(CTESTWIN + SCU-17)にさせてもらった。これだと打鍵ミスの心配をしなくて良いので精神的にも楽で、長時間運用でもそれほど疲れない。

7MHzでCQを出し始めた直後から次々と呼ばれて、ピークは60QSO/hrくらいまでレートを上げることができた。12時までの平均でも50QSO/hrは達成できたかな。思っていたより長時間ペースを維持できたのはやはりPCキーイングによるところが大きいと思う。

終わってみれば7MHzだけで215局、44マルチと個人的には1日の最高交信数を達成。頭はそれほど疲れなかったけれど、生理的欲求でどうしても休憩は必要だし、24時間のコンテストで50QSO/hrを維持し続けるというのは少なくともシングルオペでは難しいだろうなぁ。マルチオペで交代しながら複数バンドをCondxに応じて最適に運用すればなんとか、という感じだろうか。いくらCQを出し続けても相手がいなくてはどうしようもないし。

200局以上交信していると、呼んでくる局のスキルとかもけっこうわかるようになってくる。最高で3〜4局のパイルになったと思うけれど、ぴたりゼロインして呼ばれると、符号が完全に重なって全く分離できなくなる。なんとか1文字でも拾って絞り込みたいんだけど、複数の局が同じ文字を含んだコールサインだったりするとどうしようもない。AGNを連発して呼んでる方が察して控えてくれるのを待つしかなかったり。あと、一瞬でも先に呼び始めた方を取りたいのに、結局識別できるのは長いコール(/x)とか遅い符号の局のラストレターだったり。

CQを出しているのは混信のない中途半端な周波数なので、正確にゼロインしてくる方はおそらくリグのオートゼロイン機能を使っておられるのだと思う。こういうときに、フィルタで切れない範囲で周波数をズラして呼んでもらえると、こちらもピックアップしやすいし、そうやって一発コールでサクっと抜けていく局はベテランかなと思う。オートゼロインの機能は便利だと思うけれど、機械的に正確に合わせてしまうとこういう弊害がある。設備は良いハズなのに、なぜかパイルで呼び負けると感じる局は、オートゼロインに頼らず耳で合わせるか、オートゼロインの周波数からわざと少しズラして呼んでみると、ピックアップしてもらいやすくなるかも。

AI TESTお疲れさまでした。朝からクラブ局のお手伝いでした。キッコロはまた来年まで森に帰ります。 pic.twitter.com/aq5zwBAz1d

— ソウヘイ JH1CFV (@hsohei) September 23, 2021

【参考リンク】

2020年のXPO,AI TESTの様子

過去のXPO記念コンテストの様子：2019年，2018年，2017年，2016年，2015年，2014年，2013年，2012年

過去の愛・地球博記念コンテストの様子：2019年，2018年(不参加)，2017年，2016年，2015年，2014年，2013年，2012年

Tweet

2021年4月に公開した日替わり通信術のWebアプリ。特にアクセス解析などはしておらず問合せやレスポンスもあまりないのでどの程度使っていただいているかはわからない。この9月期の一総通の試験で「アプリを使って練習して合格しました」という報告をお待ちしています。

初期の頃から使っていただいているローカルさんから、(書き取りの)途中で電話などがかかってきたとき、一時停止機能があると助かる、というご要望を頂いていた。確かに一度始めてしまうと標準速度で5分間は手が離せないし、忙しいお仕事の方だと一時停止機能は欲しいかもしれない。

Web Audio APIで提供されているSuspend/Resume機能で一時停止自体は実装できると思うんだけど、全文を流して終了したときの判定をsetTimeout関数で行っていて、考えなしにSuspendさせると、終了時間がズレてしまう。

setTimeoutのタイマーを一時停止と同時に破棄して、再開と同時に新しいsetTimeoutで終了までのタイマーをセットする。と、考え方は簡単なんだけど、作り始めてみるとなかなかうまく動かない。まあプログラムなんてそんなもの。特にこのWebアプリは開発初期からのつぎはぎだらけのコードで、リファクタリングしようしようと思いつつ、「動いているからまあいいか」とそのままになっているもので、こっちを直すと別のところが変になる、という感じ。

これは重い腰を上げてリファクタリングするか、ということで、jscwlibというそのものズバリ、モールス符号を鳴らす便利なライブラリを使って丸ごと作り直すことを検討。このライブラリは日替わり通信術の開発を始めた後でTwitterで教えてもらったもので、和文にも対応しているし非常に便利。カナの本文さえ用意すれば、play関数に放り込むだけで再生してくれるし、もちろん一時停止とか、周波数などの設定もグラフィカルにできるし、音源のダウンロードまで可能。

ただ、自分の本文生成のスクリプトはこのライブラリを前提として作っていなかったので、こちらにも手を入れる必要があって、それなりに大変そう。そして、jscwlibのソースを眺めていたら、一時停止のコードもあって、自分のoscillatorの実装もそんなに違わなかったので、これを真似してなんとか元のコードの改良で動作するようになった。

ということで一時停止機能はなんとかリリースできた。あと需要がありそうなのはシークバーとか音源ダウンロードあたりだろうか。シークバーは一時停止の機能の応用で頑張ればできるかもしれない。音源ダウンロードはjscwlibでできているので技術的には可能だと思うんだけど、どうやったらいいか見当もつかない状況。

機能アップもリファクタリングも気になってはいるけれど、本質的には開発当初の思想、つまり「アプリを開いたら即一総通の受信練習ができる」は維持していきたい。

【リンク】Webアプリ 日替わり通信術

Tweet