PureData

レピーターコントローラーとCWFの同居開始！ †

　小さな金属製のケースに、Pi2B+とUSBオーディオデバイスを入れました。今まで使っていたレピーターコントローラーで場所を占めていたのは、GPIO関係のインターフェースです。
　秋月で、PiのGPIOにちょうど載る基板が150円で売られているのを知って、それに回路を組みました。GPIOから延びるリボンケーブルが不要になって、すっきりしました。（2017年09月30日）

同居失敗！ †

　1台のPi2B+上のPureDataで、二つのパッチを同時に走らせることは、かなりの負荷がかかるようで、８時間から９時間で、システムが落ちるという状態になりました。
　パッチの作り方にまだ工夫の余地はありそうですが、取り合えずは元のPiB２台という状態に戻しました。（2017年09月24日）

問題はGUI での負荷か？ †

　２つのパッチのひとつは、レピーターコントローラーです。かなり大きなパッチなのですが、PiBでは問題なく稼働しています。もうひとつはCW用のBPFで、これは非常に軽いものです。
　PiBよりも能力的にはるかに能力の高いPi2B+で、PiBで走っているパッチが落ちるのはどうにも不思議と、考え込みました。
　気付いたのは、PiBでは、PureDataのパッチをGUIなしの環境（-- nogui を付ける）で動作させていることです。
　このレピーターコントローラーパッチでは、レピーターＴRXからのCOSの状態を標準出力に出すという部分（開発中の名残）があり、その出力が、Pi2B+の画面表示バッファをあふれさせることによって、システムがハングアップしたようです。
　試しに、Pi2B+でレピーターコントローラーのパッチをGUIなしで起動し、CPUの利用率やCPUの温度を測ると、かなり軽くなっているのに気付きました。

Raspbian jessie 以降では自動実行のファイルが変わった！ †

　コマンドラインからPureDataのパッチを起動するには、Pi2B+の起動時に自動的に動作させる必要があります。
　Raspbian jessie 以降では、［.profile］ファイルの末尾に必要な内容を追加し、raspi-config でBootOption?　の B2 を［YES］に変更する必要があります。
　とにかく、wheezy までのRaspbianとjessie 以降のRaspbian は全く違うOSと考えたほうがいいようです。
　（2017年09月25日）

トリッキーなことをして、Piの数を減らした †

　わが方ではPureDataのパッチが走っているPiが複数あります。
　最も古いのはCWFに使っているPiB+です。同じくレピーターコントローラーにも違うPiB+が稼働しています。
　Pi2はPiB+に比べると飛躍的に能力が高くなり、PureDataの複数のパッチを同時に走らせても大丈夫です。
　このPukiWikiを置いているPi2でも、PureData（Vanilla）のパロットレピーターのパッチが走っています。

問題は複数サウンドデバイスの同時稼働 †

　CWFではUSBサウンドデバイスを入出力に使っています。レピーターコントローラーでは、サウンドデバイス（Pi本体）の出力を使っています。
　PureDataで同時に走るパッチが、それぞれ別のサウンドデバイスを使えたらいいのですが、それはどうにもできないことのようです。
　OSXのPureDataでも試しましたが、不可です。

知恵を絞って †

　よく考えると、CWF＋レピーターコントローラーで、サウンドの入力はひとつ、出力は２つです。USBサウンドデバイス（PL-US35AP）をじっと眺めて、ステレオ出力の右左をそれぞれのパッチで使えばOKではないかと気がつきました。
　バラックセットで試してみると、CWF（PL-US35AP のマイク入力と出力のL 使用）と、レピーターコントローラーのパッチ（PL-US35AP の出力のR 使用）を同時に稼働させることができました。
　これでわが方で常時動いているPIは少し減って４台（RRS-Pi、PIRLP、CWF＋レピーターコントローラー、PukiWiki）になりました。
（2017年09月23日）

PD-extended ではなくPureData vanilla を使う！ †

　PD-Extended　を長らく使ってきたのですが、さすがに開発が2014年に停まっているものを、もう使うことはできないようです。
　PD-extendedが秀逸であったのは、[morse]や［comport］さらには最新のsatelliteCCRMAでは［GPIO］関係のライブラリも入っているという使いやすさでした。
　最大の問題は、USBオーディオデバイスとの相性が非常に悪いことです。これはPD-extendedのバグ＝PureDataの開発者以外が勝手に追加したライブラリのバグだと思われます。
　ネットの情報などによると、開発が進められているPureData vanillaの0.47版からは、ライブラリを追加できるdeken が入っているとのことで、それを使い、ネットから必要なライブラリを追加するのがどうやら「正しい」使い方のようです。
　http://www.footfoot.tokyo/article30/puredata-deken-plugin　などを参考にして、何とか[morse]なども入れることが出来ました。
　モジュールの一覧はhttp://blazicek.net/list_of_pure_data_objects.html　などにあります。
（2017年08月30日）

PL-US35AP なども問題なし！ †

　PureData Vanilla ではPL-US35AP などのUSBオーディオデバイスも、何の問題もなく安定して動作します。あまりにあっけなく、今までの努力（勝手な苦労）はいったい何であったのかと思うほどです。
（2017年08月30日）

PureDataは非常におもしろい。 †

　大昔から小生は非常に飽きっぽい性格であったようです。DXを追いかけることだけは何十年やっても飽きないのですが、PureDataも少しかじって、実用になるものができたら、ハイそれまでよーー、となりかけています。
　CWFもレピーターコントローラーも快調に稼働しています。毎日使うというか連日＝24H/7D＝稼働するものを自分の設計で作り上げ使い続けるというのは、確かに面白いのですが、あまりに安定していて、そのありがたみを忘れがちです。
　そろそろPureDataで何か次のもの、といってもオーディオ帯域のものか、簡単なコントローラー的なもの＝を拵えようと考えています。（Apr 22 , 2014）

PureData とOSXの相性 †

　PureDataでCWFを作った際に、母艦としてクロスプラットフォームでの開発に使ったのは、OSX,10.10か10.9でした。（←もう記憶が怪しいのです。）
　2016年になって、パロットレピーターをPureDataでも実現してみようと思ってCWFと同じような作業を始めると、OSX上のPureDataの挙動がおかしいのです。
　あれこれググると、10.11＝El Capitan では動作がおかしくなったというレポートが多数上がっています。
　試行錯誤の末に、わが方（OSX 10.11.3）では、PureDataの 0.43.4 の64ビット版だと動作に問題ないことが分かりました。
　AppStore?で配布しているソフトに関しては、アップルが動作の確認をしているのだと思いますが、ネットで配布されているソフトの場合には、開発元がOSの変化に対応するしかないのでしょう。（2016年２月８日）

wavではなくてaif †

　PureDataではオーディオファイルとしてWAV形式もAIFF形式も使えることになっていますが、上記のわが方の環境では、WAVはだめで、AIFF＝拡張子が.aif しか動きませんでした。

PureData on RaspberryPi? の問題 †

　PureDataは非常に良くできたソフトなのですが、Pi上で動くPureData＝SatelliteＣCRMAの場合には、問題があります。
　PureDataはオーディオを扱うのが得意なのですが、USBオーディオデバイスの認識に関して、トラブルが絶えません。
　IRLP on Pi = PiRLPを稼働させる時にもトラブったのですが、Pi自体というか、Rasbienで認識され正常に動いているUSBオーディオデバイスでも、SatelliteＣCRMAでは動かない、という場合が多々あります。
　というよりも、SatelliteＣCRMAで正常に稼働するUSBオーディオデバイスのほうが少ない、というのが現状です。
　３年ほど前にCWFを作った際に使った手持ちの古い（USB1.1の時代）デバイスが、「たまたま」うまく動作した、という気がします。
　Piもバージョンが変わり、それにつれてSatelliteCCRMAもバージョンがアップしているのですが、根本的な問題は解決されていません。（2016年２月９日）

USBオーディオデバイス認識の覚え書き †

microSDカードに焼いたイメージは　SatelliteCCRMA_Rpi2_v1.03.dd
　このバージョンではGPIO関係のモジュールが入っていて、非常に使い易くなっています。
USBオーディオデバイスはPL-US35AP
　PCIの製品で、Amazonなどでも売られています。WiRESでも使用実績があって、音質もよいものです。Mac上でもWinでも問題なく稼働。1000円少しで買えます。

まずはお決まりのことを。

　/etc/modprobe.d/alsa-base.conf　というファイルの中の options snd-usb-audio index=-2 を options snd-usb-audio index=0　に書き換えます。

---

PL-US35APの認識のさせ方（接続順）

（１）　PL-US35APを繋いでPi2起動

                            PL-US35AP＝点灯→点滅

（２）　PD　起動

                            PL-US35AP＝点滅

（３）　PL-US35APを抜く
（４）　PL-US35APを再接続

                            PL-US35AP＝点灯

（５）　PD　終了
（６）　PD　起動

                            PL-US35AP＝点滅

---

　この順で行えば、PL-US35APをPD on Pi2Bで問題なく認識でき、録音再生も正常です。電源投入やreboot時に少々面倒ですが、まぁ仕方ないかと思います。
　SatelliteCCRMAの問題もあるようですが、PiではUSBの機器はどうも本当の意味での「plug and play」ではないようです。（2016年２月10日）

書き忘れ †

　　上記の記述はPi2で行いました。SatelliteCCRMAの最新版＝1.03はPiB+でも動作しますが、PL-US35APを上記と同じようにPDから認識させることはできませんでした。
　　SatelliteCCRMAのHP上で配布されている、PiB用のイメージ＝0.95＝は、PiB+では稼働しませんでした。（2016年２月11日）

追記 †

　　上記の手順を何度も繰り返すと、PI2のシステムに不具合を生じます。実験をする前に、かならずSDカードのバックアップをすることが必要です。

---

dwc_otg.speed=1 を書き込んでもNG †

　ネットで情報を検索すると、ラズベリーパイでUSB音源を使うには、皆さん、あれこれと試行錯誤をされているようです。
　複数のサイトで　/boot/cmdline.txt に　dwc_otg.speed=1 を追加すればＯＫとあったので、勇んでやってみたのですが、結局だめでした。
　やはりPureData on Pi という環境は、Pi単独の状況以上にUSBオーディオデバイスに関しては、相性がきついようです。
　ちなみに、わが方では sudo pico /boot/cmdline.txt とやってもパーミッションエラーで書き込めませんでした。
　最終的には、SDカードをMacに挿して、直接ファイルを書き換えたのですが、USBオーディオデバイスに関しては、変化なしでした。（2016年２月13日）

SSH とVNC は違う！！ †

　　ラズベリーパイ上のPureDataを操作するためには、Macのターミナルで「ssh -XY ccrma@……」という形でログインします。ソフトのインストールにしても、Piの状態の監視にしても、同様です。
　　わが方のMac＝MacBookPro?の上では、VNCソフト＝正確にはOSXの「画面共有」とTeamviewerが稼働して、MacMini?とWires-X用のスティックＰCを操作しています。
　VNCでの操作とターミナルでPiを操作しているのは、同じように感じていましたが、根本的な違いがあることに気付きました。
　意識的に気付いたのではなく、パロットレピーターのパッチを組んでPI2上で動かしている時に、ターミナルが動いているMacBookPro?がスリープすると、PI2の上で動いていたパッチも動作を終えることに気付いたのです。
　最初はPiかSatelliteCCRMAのバグかとも考えたのですが、Linuxの世界では、それが当たり前のことだと今回わかりました。
　VNCは操作される方の画面を取ってきているだけなのですが、SSHでログインすると、まさに繋がった状態になるようです。
　あれこれと今回もネットで検索して、「nohup」というコマンドを、一連のコマンド（今回の場合は、pd -nogui …….pd）の前に付け、最後に「&」もつけて、OKになりました。
　これでどこからもPI2にログインしていない状態でも、PureDataのパロットレピーターパッチが動きつづけるはずです。（2016年２月14日）

７時間で落ちる！ †

　不思議な現象に遭遇しています。上記のように、PI2単体で、つまりはどの端末からもログインされていない状態で、パロットレピーターのパッチは、動作を続けるはずでした。
　実際の運用に向けて、10分毎のID送出ルーチンも書き加えて、機嫌よく動作を開始したのですが、６時間から８時間で落ちました。不思議です。
　落ちた際には、PDでのオーディオデバイスの認識が勝手に変わっています。やはり、PureData 0n Pi2 という状況でのUSBオーディオデバイスの認識は、かなりの相性問題（と俗に言われているバグ）があるようです。
　SatelliteCCRMAのHPにはオーディオテクニカのATR2USBという製品が推奨されています。オーディオテクニカですから、日本のメーカーなのですが、同じ型番のものは、国内では入手できないようです。OEM供給らしい同じ筐体のものも入手して、実験を続けるつもりです。
　ググると、Pi/Pi2から音を外へ出すことに関する情報はネットのあちらこちらにあるのですが、音声入力に関しては、情報がぐっと減ります。
（2016年２月16日）

MM-ADUSB3 もだめでした †

　上記の「同じ筐体のもの」というのは、サンワサプライが売っているMM-ADUSB3です。筐体もVRの位置も全く同じです。
　これを入手して試した見ましたが、だめでした。（2016年２月21日）

発想を変えてMacMini?＋Arduinoにした！ †

　今回PureDataに２年ぶりに触ろうと思い立ったのは、パロットレピーターを作ろうと考えたからです。最終的には、HTで送信した内容が、山彦となって返ってくればいいのですから、もうPi2にこだわるのは止めにしました。
　というよりも、複数のUSBオーディオデバイスを接続して試したのですが、どれもうまくいかなかったからです。
　PiB＋SatelliteCCRMA＋手持ちの古いUSBオーディオデバイスが上手く稼働したので、PiB+やPi2でもできるだろうと考えたのが、間違いのもとであったようです。
　Pi2のほうでの構築は一旦中止して、MacMini?＋Arduinoでやってみました。
　こっちのほうがデジタルI/O＝SQオープンで録音を開始し、SQクローズで録音を止めて、その後PTTをONにして再生し、再生終了でPTTをOFFにする、というようなことは簡単にできます。オーディオデバイスにしても、MacMini?本体のものを使うので、何の問題も生じません。
　もちろんPureDataはOSXでもWindowsでもLinuxでも、同じパッチが走ります。オーディオデバイスやI/O関係の部分を修正したらOKになりました。
（2016年２月19日）

教訓 †

　何年か前に、ARRLのアマハンの記事を参考に、５ポールのパッシブタイプのCWフィルターを作成しました。最初は非常に切れ味よく動作していたのですが、しばらくすると、ロスばかりが大きくて、使えない状態になりました。
　原因は、フェライトコアで作成したハイＬのコイルの経年変化でした。
　ディスクリートで作る回路には、作った時の調整と、経年変化に対応することが必須です。
　それに対して、ソフトで組んだものは、基本的には調整も経年変化も無関係です。PureDataで作成したCWFは切れ味こそもう一つですが、ソフトでアンプ＝低周波の10dbのアンプも簡単に実現できて、ずっと使っています。
　特にタイミングに関することを多用した、今回のパロットレピーターや、レピーターコントローラーの場合には、無調整というのは非常にありがたいものだと感じました。
　一方で、ソフトにはバクが付きものです。ソフト自体にも、OSにも必ずバグは潜んでいます。それを知った上で、時々はソフトやコンピュータ自体の再起動をすることが大切です。（2016年２月21日）

DTMFの解読ルーチンを組んだ！ †

　DTMFは良くできたシステムです。60年以上も前に考えられたもののようです。要するにピポパなのですが、可聴音域の中で、倍音関係にならない低群４つ、高群４つの周波数の組み合わせ＝４×４で16＝０〜９＋A〜D＋＃と＊で16の信号を送る、というものです。
　VoIP無線が始まってからは、アマチュア無線でもすっかりなじみ深いものになりました。
　かつては専用のICが市販されていて、エンコードもデコードも簡単にできたのですが、昨今の無線機では、すべてCPUとカスタムICで作成されています。
　そのために、DTMFの基準から少々（中にはかなり）外れた周波数になっている無線機もあって、VoIPのノードをアクセスする時に、ピポパが通りにくかったりもします。
　パロットレピータの中に、DTMFデコードのルーチンを組み込めば、HTでシャックの無線機のコントロール＝たとえば、レピータ装置のON/OFFなど＝もできると考えました。
　ネットの情報やPureData関係の書物に掲載されているものでも、DTMFのデコードには、FFT＝高速フーリエ変換を使うのが王道のようです。
　しかし、どういう訳かわが方では、フーリエ変換ではうまくDTMFのデコードができませんでした。
　FFTで組んであるPureDataのパッチは格好がいいのですが、動かなければ意味がありません。
　そこで、ディスクリートでは考えられないような「力技」でやってみました。
　低群、高群の８つの周波数を中心にしたBPFをこしらえたのです。かつてNE567というICがあり、トーンの検出によく使われていました。わが方の部品箱にも、まだ数本はあると思います。
　NE567を８本使って回路を組めと言われたら、ハンダ付けが好きな小生でも遠慮します。
　しかし、PureDataでは基本のBPFが組めて動作の確認が出来れば、後はコピペと数値の変更でOKです。
　半日ほどで組めました。
　次の問題は、複数のピポパ音をどう記憶させるかです。順序だけが決まっていて、音の長さも不ぞろいで送られてくるピポパを元に、さてPureDataでどうしたら制御回路が組めるかが、これからの課題であります。（2016年２月27日）

［spigot］と［sel］で解決 †

　上記の制御というのは、たとえば「１２３」とHTからピポパを送信したら、リレーがかちんと動いて何かの電源回路をOFFにする、というものです。
　最初は「１」「２」「３」をそれぞれ変数に入れてAND（論理積）を取る、などということを考えていたのですが、PureDataのパッチは「流れ」であることを思い出して、考えを変えました。
　HTから「１」が送信されたら第一関門が開き（［sel］で１どうかの判別、［spigot］で関門）「２」がきたら……「３」がきたら［bang］をリレーの制御回路（ArduinoのどれかのポートをHighにする）に送る、というふうに変えて、簡単に制御回路が実現できました。（2016年２月28日）

昔はスパゲッティ、今はもんじゃ焼き？？ †

　かつてBASIC全盛期に、継ぎはぎ、つぎ足し、建て増しだらけで、見通しの悪くなったプログラムを「スパゲッティのようだ」と形容していました。
　正確には、茹でて時間が経ったスパゲッティです。絡み合っていて、しかもべったりくっついていて整理がつかないものです。
　まぁそれでもちゃんとどうさしたらOKですが、何かの不具合が生じた場合の、変更がむずかしくなります。
　一方、PureDataですこし大きなパッチを組むと、絡み合うというよりも、どんどん平面的に大きくなって行ってしまいます。もんじゃ焼き（と書いても、上方の小生は実際には食べたことがないのですが……）のような感じです。（2016年２月28日）

OSX 10.11では問題が †

　PureData（PD-Extended 0.43.4）をOSX　10.11.3（MacBookPro? 15インチ　2010年）で動かしていると、２時間ほどでハングアップすることが分かりました。Command-Qでの終了もできなくなります。同じパッチを10.6.8上で動かしても、全く問題はありません。（2016年３月６日）

FT-DX5000のデータをFT-991へ転送！ †

　わが方の運用では、FT-DX5000がメインですが、CQを出しているDXがかなり強い場合などでは、FT-991をQRPで運用（出力５W）することがあります。
　その際に、FT-DX5000で受信している周波数をFT-991で設定するのですが、全くの手動です。
　IcomのCI-Vにはトランシーブ機能があって、A機の周波数変更がそのままCI-Vで繋がったB機に送れます。
　FT-DX5000にもFT-991にもCATはあるのですが、Icomのトランシーブ機能に相当するものはありません。
　しかし、ここであきらめてはサンデー毎日のセミプロアマチュア無線技士の名がすたると考えて、久々にPureDataのコマンド一覧を眺めました。
　YaesuのCATはRS-232Cです。CI-Vと違って汎用のUSB--シリアルの変換器でコンピュータに繋ぐことができます。これはYaesuのほうにアドバンテージがあります。
　PureDataにはその名も［comport］というコマンドがあります。これを使って、何とか5000==>>991という周波数データ転送パッチができました。
　YaesuのCATは機種によってコマンドが微妙に異なります。FT-DX5000では周波数データは８桁ですが、FT-991では９桁です。それを合わせるのに、今回も少々トリッキーなパッチになりました。
　今はMacMini?で動作してますが、さてPi2で動かしたほうがいいのかどうか、最終的な実装はまだ少し先です。（2016年５月21日）

パッチの説明 †

　FT-DX5000でもFT-DX5000でもCATに「FA;」と送ると、VFO-Aの周波数を返してきます。PureDataの［comport］のinletに「FA;」を10進にした「70 65 59」というメッセージを送ると左outletから受信データ（例えば14.025.000MHzならば「FA14025000;」を10進にしたデータが、１バイトずつ出てきます。
　つまり「70 65 49 52 48 50 53 48 48 48 59」が出てきます。
　これをFT-991に繋がってる違うportから出せばOKのようですが、FT-991のばあいは、FAと；の間の周波数データは９桁です。つまり14.025.000MHzならば「70 65 48 49 52 48 50 53 48 48 48 59」とならないと動作しません。
　そのために、［metro 100］でFT-DX5000に繋がったportに「70 65 59」（=FA;）を送る前に、FT-991に繋がったportに「70 65 48」（=FA0）を送ります。
　（PureDataのバグのようですが、パッチの上に２番目に作った［comport］では、「70 65 48」は動作せず、「70,65,48」とする必要がありました。）
　次いで、FT-DX5000から返された周波数データから、頭の「70 65」を取り除いた残りを、FT-991のportに送って、FT-991の周波数がFT-DX5000と同じになります。
　なお、このパッチを動かすためには、FT-991のRS-232CのTOT（Menu30番）を1000msにする必要があります。（2016年５月21日）

PiB+で動かすことにした。 †

　MacMini?上で動作の確認ができたので、パッチをまずはPi2にコピーしました。［comport］で指定するUSBデバイスのナンバーを変更するだけで、あっけなく動作しました。
　Pi2は2016年６月に一般にリリースされるRRS-Pi（ネットワークを使ったリモコンソフト）に使うので、余っているPiB+にmicroSDカードを挿して動作を確かめました。重いパッチではないのですが、Pi2とPiB+ではMacBookPro?からSSHでログインし、さらにX-WindowでPi上のPureDataのパッチを操作すると、かなりぎくしゃくとした動きになりました。
　それでも、パッチの動作自体には問題はなく、しばらくはこの状態で、やってみることにします。
　余談ですが、SatelliteCCRMAに土台になっているRasbienには、どうもバグがあるようで、PiB+をRebootするたびに、２つ繋いであるUSB--シリアル変換器の番号が入れ替わります。不思議です。（2016年５月23日）

USBサウンドデバイスの問題、解決！ †

　2016年６月21日のタイムスタンプで、SatelliteＣCRMAの新しいイメージファイル（SatelliteCCRMA_Rpi_v1.05.dd）が配布されています。
　久々にPi2に入れてみたら、このバージョンでは、USB関係がかなり改善されたらしくて、手持ちのUSBサウンドデバイスはすべて動きました。
　国内で広く流通しているPL-US35AP も動作OKです。
　このデバイスはダイナミックレンジが狭いようで、ATR2USB のほうが総合的には良いようですが、こっちは国内では入手難です。（2016年10月24日）

USBオーディオデバイス追記 †

　MM-ADUSB-3（サンワサプライ）でもPi2＋PureDataでの動作を確認できました。これは外見はATR2USBと全く同じですが、どうやら中身は違うようで、PureDataからは違うデバイスとして認識されます。
　Pi2の場合は、/etc/modprobe.d/alsa-base.conf　というファイルの中の options snd-usb-audio index=-2 は書き換えないでそのまま-2にしておきます。（2016年10月25日）

macOS Sierra での動作 †

　OSXが10.11の段階から、PureData（PD-Extension）は正常な動作をしなくなっていました。
　今回MacBookPro?を新調して、同時にOSも10.12になったので、本格的にPDの修復（？）をしました。
　http://puredatajapan.info/?p=2062　の記事を参考にして、素のPDに必要なExternalを読み込んで、PD-Extensionと同様の環境にしようと考えました。
　「PureData vanillaでdekenを使ってGemを導入する」どおりにやってみても、他のExternal＝例えば「comport」が読み込まれないのです。
　ユーザー/ライブラリ/PD の下に出来た「Gem-0.93.3」フォルダの中の「Gem」をPD直下に移動させます。その後、必要なExternalの「中身」を「Gem」の中に移動します。
　もっとスマートな方法があるに違いないのですが、とりあえず、今まで作ったパッチがMacBookPro?（macOS 10.12.1）のでも動作するようになりました。
（2016年11月20日）