電装工芸日記
- 舞台照明機器の製作とか -
タグ「Python」を含む投稿［119件］（5ページ目）
弊社の音響担当に意見を聞きました。使ってもらうために彼らの慣れに合わせたいと思っているので、私の感覚だけで作りたくないのです。
こちらのイメージも具体的になってきたのでナルホドねぇ～が連発でしたが、そんな話の中で驚いたのはいわゆる叩きに使えるアプリが少ないという事実。
世の中には音楽再生アプリが数多ありますので私が作ったアプリを使ってくれるだろうかと思っていましたが、音響さんにとって便利な機能を積極的に取り込めば割り込む余地はありそうです。
大半の音楽再生アプリはあくまで音楽を聴くことを目的にしているためか操作に対するレスポンスが悪くキッカケ合わせに使うのは難しいのだそうです。私が音源再生のライブラリとして使っているVLCライブラリはレスポンスが良いので不思議です。
マルチスレッド化を考えていますが、その前にソースコードの整理が必要っぽいです。
フラグを用いた逐次処理をベタベタの平文で書いていますが、2000行に届こうともなるとインデックスが使えない平文ではエディタを上下スクロールするだけでも面倒ですし、今後の加筆、修正を考えるとこのままではいけないような気がします。
特に PysimpleGUI の設定が大量なので、せめてこの辺りをＣ言語で言うところのヘッダーファイル化したいものです。定数や関数をオレ様ライブラリ化するのですが、これが正しい書き方なのでしょう。
ここまでを試作とし、Python として美しい書式で新たに書いた方がいいのかな？
#Python
こちらのイメージも具体的になってきたのでナルホドねぇ～が連発でしたが、そんな話の中で驚いたのはいわゆる叩きに使えるアプリが少ないという事実。
世の中には音楽再生アプリが数多ありますので私が作ったアプリを使ってくれるだろうかと思っていましたが、音響さんにとって便利な機能を積極的に取り込めば割り込む余地はありそうです。
大半の音楽再生アプリはあくまで音楽を聴くことを目的にしているためか操作に対するレスポンスが悪くキッカケ合わせに使うのは難しいのだそうです。私が音源再生のライブラリとして使っているVLCライブラリはレスポンスが良いので不思議です。
マルチスレッド化を考えていますが、その前にソースコードの整理が必要っぽいです。
フラグを用いた逐次処理をベタベタの平文で書いていますが、2000行に届こうともなるとインデックスが使えない平文ではエディタを上下スクロールするだけでも面倒ですし、今後の加筆、修正を考えるとこのままではいけないような気がします。
特に PysimpleGUI の設定が大量なので、せめてこの辺りをＣ言語で言うところのヘッダーファイル化したいものです。定数や関数をオレ様ライブラリ化するのですが、これが正しい書き方なのでしょう。
ここまでを試作とし、Python として美しい書式で新たに書いた方がいいのかな？
#Python
Pythonでマルチスレッドをする方法を改めて調べていました。
以前は threading を使いましたが、concurrent.futures が便利っぽい。普通の関数を使うのと大差ない手間で使えます。
しかもマルチスレッドだけでなくマルチプロセスも扱えます。マルチプロセスでも fork して管理する作業が無く、マルチスレッドとほぼ同じ書き方で使えるので、どちらかで書いておけば後から変更するのも簡単。
マルチスレッドとマルチプロセスの違いは先達の書き込みが沢山があるので割愛しますが、今回の用途ではマルチスレッドが良さそうです。処理の総量はシングルプロセスでも十分に間に合っているのですが、ウィンドウマネージャーの待ちとシリアル通信の待ちがかみ合わないことへの措置なので軽快なマルチスレッドなワケです。
#Python
以前は threading を使いましたが、concurrent.futures が便利っぽい。普通の関数を使うのと大差ない手間で使えます。
しかもマルチスレッドだけでなくマルチプロセスも扱えます。マルチプロセスでも fork して管理する作業が無く、マルチスレッドとほぼ同じ書き方で使えるので、どちらかで書いておけば後から変更するのも簡単。
マルチスレッドとマルチプロセスの違いは先達の書き込みが沢山があるので割愛しますが、今回の用途ではマルチスレッドが良さそうです。処理の総量はシングルプロセスでも十分に間に合っているのですが、ウィンドウマネージャーの待ちとシリアル通信の待ちがかみ合わないことへの措置なので軽快なマルチスレッドなワケです。
#Python
LTC Player は音源プレーヤー部がほぼ終わり。今後は LTC Generator の制御を組み込んでいきます。
LTC Generator の制御部はマルチスレッドを使って音楽プレーヤーと分ける必要があると思われます。LTC Generator との通信は最短で33msec(1/30秒)毎に行われますが、PysimpleGUI の sg.window.read() のタイムアウトを25msecにしているためにタイミングが間に合わない可能性があるからです。タイムアウトをもっと早くすれば良さそうなものですが、これ以上早くすると PysimpleGUI にとってよろしくないのです。あちらを立てればこちらが立たず状態ですが、トータルの処理量には無理は無く、あくまでタイミングの問題ですから、マルチスレッドにすればストレス無く動くと思います。
スレッド間通信には Queue を使えばいいでしょう。共有メモリや Pipe より通信は遅いのですが、List だろうが Tuple だろうがPythonで扱う変数をそのまま扱えるので便利です。通信するデータ量も僅かですから速度が気になることもないでしょう。ちなみに、Queue を送った後にほんの僅かな sleep() を入れると受け側のスレッドが動くまでの時間を短く出来る様です。
#Python
LTC Generator の制御部はマルチスレッドを使って音楽プレーヤーと分ける必要があると思われます。LTC Generator との通信は最短で33msec(1/30秒)毎に行われますが、PysimpleGUI の sg.window.read() のタイムアウトを25msecにしているためにタイミングが間に合わない可能性があるからです。タイムアウトをもっと早くすれば良さそうなものですが、これ以上早くすると PysimpleGUI にとってよろしくないのです。あちらを立てればこちらが立たず状態ですが、トータルの処理量には無理は無く、あくまでタイミングの問題ですから、マルチスレッドにすればストレス無く動くと思います。
スレッド間通信には Queue を使えばいいでしょう。共有メモリや Pipe より通信は遅いのですが、List だろうが Tuple だろうがPythonで扱う変数をそのまま扱えるので便利です。通信するデータ量も僅かですから速度が気になることもないでしょう。ちなみに、Queue を送った後にほんの僅かな sleep() を入れると受け側のスレッドが動くまでの時間を短く出来る様です。
#Python
LTC Player はいい感じに進んできました。
PlayListには「Continue」って項目を入れています。音終わりで止める(AutoPauseする)か曲を続けるかの設定です。単に止めて続けても面白くないし、曲間の時間を設定出来たら面白そうなので、曲が終わって次の曲が始まるまでの待ち時間を設定出来るようにしました。0秒にしておけば普通の曲ツナギです。もちろん、待ち時間が終わらなくても PLAY を押せば次の曲に行きます。ついでにマイナス秒も設定出来るようにしてみました。前倒しで曲を終りにする機能です。お尻の無音が長い曲を曲続きにしたい場合に便利かなと。使う人がいるかわかりませんが、ソースを見たら簡単に入れ込めそうだったので欲を出してみました。ライブラリがVLCなので厳密な時間再現は出来ませんけどね。
それにしても、Python のソースなのに明らかにアセンブラっぽい。どう見ても一般的な Python の流儀から外れています。勉強しながら考えなら書いていると体に染みついたアセンブラ風味になってしまうようです。ソースコードを誰かに納品するワケじゃありませんのでオレ流で構わないのですけどね。けど、オブジェクト指向でクラス・インスタンスをベースにするより、フラグベースでリニアな処理手順にした方が分岐が少なくてバグを見つけやすいかもと思ったり。リニアに書くのが非合理的なのでオブジェクト指向なんでしょ！という正論は聞きませんwww
#Python
PlayListには「Continue」って項目を入れています。音終わりで止める(AutoPauseする)か曲を続けるかの設定です。単に止めて続けても面白くないし、曲間の時間を設定出来たら面白そうなので、曲が終わって次の曲が始まるまでの待ち時間を設定出来るようにしました。0秒にしておけば普通の曲ツナギです。もちろん、待ち時間が終わらなくても PLAY を押せば次の曲に行きます。ついでにマイナス秒も設定出来るようにしてみました。前倒しで曲を終りにする機能です。お尻の無音が長い曲を曲続きにしたい場合に便利かなと。使う人がいるかわかりませんが、ソースを見たら簡単に入れ込めそうだったので欲を出してみました。ライブラリがVLCなので厳密な時間再現は出来ませんけどね。
それにしても、Python のソースなのに明らかにアセンブラっぽい。どう見ても一般的な Python の流儀から外れています。勉強しながら考えなら書いていると体に染みついたアセンブラ風味になってしまうようです。ソースコードを誰かに納品するワケじゃありませんのでオレ流で構わないのですけどね。けど、オブジェクト指向でクラス・インスタンスをベースにするより、フラグベースでリニアな処理手順にした方が分岐が少なくてバグを見つけやすいかもと思ったり。リニアに書くのが非合理的なのでオブジェクト指向なんでしょ！という正論は聞きませんwww
#Python
PysimpleGUI の使い方が更に見えてきたので LTC Player はそれっぽさが増しています。
右クリックメニューが便利ですね。ほとんどのウェジットに設定が出来ます。ボタンを配置することなく操作イベントを起こせるので、使用頻度が少ない操作やパソコンに間違って触れても発生させたくない操作には良いようです。問題は「ここには右クリックメニューがあるよ」をどうやって示すかです。隠しコマンドの様なショートカットキーは嫌いなのでその様にはしたくありませんし、「ここにあるよ」を強く主張したらボタンと同じです。強く主張することなく右クリックメニューがあることを示すデザイン手法が欲しいところです。もう少し研究が必要です。
まだまだα版ですが、「自分が仕事で使うなら欲しい機能」を実装していくのは楽しいですね。
VLC Media Player にもある機能ですが、スライダーで再生位置を設定したり、カーソルキーで少し戻す・送る機能は便利です。音源を聞きながらのデータ整理では能率が良いですし、リハでは「音の終わりから何秒戻したところから再生したい」とかがよくあるからです。されど本番では絶対に触りたくない機能ですから、右クリックメニューで有効/無効を設定出来る様にもしておくと更にイイ感じです。
#Python
右クリックメニューが便利ですね。ほとんどのウェジットに設定が出来ます。ボタンを配置することなく操作イベントを起こせるので、使用頻度が少ない操作やパソコンに間違って触れても発生させたくない操作には良いようです。問題は「ここには右クリックメニューがあるよ」をどうやって示すかです。隠しコマンドの様なショートカットキーは嫌いなのでその様にはしたくありませんし、「ここにあるよ」を強く主張したらボタンと同じです。強く主張することなく右クリックメニューがあることを示すデザイン手法が欲しいところです。もう少し研究が必要です。
まだまだα版ですが、「自分が仕事で使うなら欲しい機能」を実装していくのは楽しいですね。
VLC Media Player にもある機能ですが、スライダーで再生位置を設定したり、カーソルキーで少し戻す・送る機能は便利です。音源を聞きながらのデータ整理では能率が良いですし、リハでは「音の終わりから何秒戻したところから再生したい」とかがよくあるからです。されど本番では絶対に触りたくない機能ですから、右クリックメニューで有効/無効を設定出来る様にもしておくと更にイイ感じです。
#Python
PysimpleGUI は簡単な画面を簡単に作れますが、母体である Tkinter の機能の一部を直接引っ張り出すことで思った以上に細かい作り込みも出来ます。
もちろん、直接使うのに比べたら出来ることは少ないのですが、少ない学習量と記述量でここまで出来るなら御の字だと思います。主なGUIライブラリは、一つのことをするのに「あっちにコレ」「そっちにソレ」と彼方此方に記述をしなければなりません。細かく言うなら、雛形 class をオーバーライドして自分用の class 定義を延々とやらねばならず、Pythonの書き方としては王道なのでしょうが、簡単なことを簡単に実現するには程遠い感じです。
何を以って良しとするかは難しいですが、GUI画面製作の入門として PysilmpleGUI がお勧めなのは間違いありません。class ってイマイチわからない、って人も使えると思います。
もちろん、オブジェクト指向の書き方が出来るプログラム言語で class を使わないのは魅力が半減ですから身に付けるべきですケドね。
本業が詰まってしまい LTC Player の製作は完全に止まっていますが、合間に勉強を進めていきましょう。
#Python
もちろん、直接使うのに比べたら出来ることは少ないのですが、少ない学習量と記述量でここまで出来るなら御の字だと思います。主なGUIライブラリは、一つのことをするのに「あっちにコレ」「そっちにソレ」と彼方此方に記述をしなければなりません。細かく言うなら、雛形 class をオーバーライドして自分用の class 定義を延々とやらねばならず、Pythonの書き方としては王道なのでしょうが、簡単なことを簡単に実現するには程遠い感じです。
何を以って良しとするかは難しいですが、GUI画面製作の入門として PysilmpleGUI がお勧めなのは間違いありません。class ってイマイチわからない、って人も使えると思います。
もちろん、オブジェクト指向の書き方が出来るプログラム言語で class を使わないのは魅力が半減ですから身に付けるべきですケドね。
本業が詰まってしまい LTC Player の製作は完全に止まっていますが、合間に勉強を進めていきましょう。
#Python
そんなこんなで LTC Player の製作は止まっています。進めたいのですが時間だけでなくアタマの容量も不足してます。
PysimpleGUI を筆頭にプログラム環境でどこまで出来るかを探りながらなので、自分でもどう仕上がるかわからんという本音もあります。
最近気づいたのは、sg.FileBrowse() などのボタンとしてレイアウトしなければならない機能は、不可視設定した column に入れ込んでしまえば表示しなくても使えること、ボタンオブジェクトを押したことにする .Click() を使えば他の event から(もちろんメニューからも)読み出せるというものです。PysimpleGUIを使ったことがないとピンとこないことですが、これは PysimpleGUI のレイアウトに自由度を与えてくれます。
追記
.Bind() を使うと細かいキーボード操作を event として取り込むことが出来るらしい。
キー操作をプレスにするかリリースにするかを選べるハズです。この辺りも研究課題です。
#Python
PysimpleGUI を筆頭にプログラム環境でどこまで出来るかを探りながらなので、自分でもどう仕上がるかわからんという本音もあります。
最近気づいたのは、sg.FileBrowse() などのボタンとしてレイアウトしなければならない機能は、不可視設定した column に入れ込んでしまえば表示しなくても使えること、ボタンオブジェクトを押したことにする .Click() を使えば他の event から(もちろんメニューからも)読み出せるというものです。PysimpleGUIを使ったことがないとピンとこないことですが、これは PysimpleGUI のレイアウトに自由度を与えてくれます。
追記
.Bind() を使うと細かいキーボード操作を event として取り込むことが出来るらしい。
キー操作をプレスにするかリリースにするかを選べるハズです。この辺りも研究課題です。
#Python
LTC Player はファイルを読み込んでセットリストの編集をするところまで来ました。
この辺り、かなり面倒です。編集の手順、再生中のLockなど、よく考えないといけません。
それでも、かなりそれっぽくはなってきました。
#Python
この辺り、かなり面倒です。編集の手順、再生中のLockなど、よく考えないといけません。
それでも、かなりそれっぽくはなってきました。
#Python
LTC Player はPySimpleGUIとpython-vlcを勉強しながら書いてきたためにソースコードがゴチャゴチャ。
この先もあるので、変数やインスタンスの名前も手直ししながら大整理をしました。時間がかかりましたが読みやすく手直しもし易くなりました。
で、そんな整理をすると出てくる出てくる細かいバグ。
先日、mp3再生中にポジションスライダーを動かすと警告が出て再生速度などがおかしくなることがありましたが、対策はplay()、stop()、pause()を実行した後にis_playing()が望みのフラグを返すまで待つというものです。コレが抜けてる所が数カ所。状況が整っていないのに次の指令が来ることが原因だったようで、再生速度が狂う現象は解消されました。mp3でスライダーを多用すると再生時間のズレが出るのは変わりませんが、wavなら期待通りの動きなのでいいかなと。
現在の画面。PlayListとNEXTはモックアップです。
#Python
この先もあるので、変数やインスタンスの名前も手直ししながら大整理をしました。時間がかかりましたが読みやすく手直しもし易くなりました。
で、そんな整理をすると出てくる出てくる細かいバグ。
先日、mp3再生中にポジションスライダーを動かすと警告が出て再生速度などがおかしくなることがありましたが、対策はplay()、stop()、pause()を実行した後にis_playing()が望みのフラグを返すまで待つというものです。コレが抜けてる所が数カ所。状況が整っていないのに次の指令が来ることが原因だったようで、再生速度が狂う現象は解消されました。mp3でスライダーを多用すると再生時間のズレが出るのは変わりませんが、wavなら期待通りの動きなのでいいかなと。
現在の画面。PlayListとNEXTはモックアップです。
#Python
LTC Player はPySimpleGUIの扱い方を探りながらです。Tkinterのラッパーらしいですが、簡単に使える反面制約が多いので、別な意味で難しいところがあります。
主な制約はウェジット(オブジェクト)の並べ方によって挙動が違うことです。全てではないのですが「ナゼそうなる！？」に出会うことが少なくありません。昨日もExecl的な表示をするTable機能で出くわしてしまい数時間悩んでしまいました。下記の試作品では「Add Music」が今の位置では期待通りの挙動をしますが、表の左隣りでは期待通りに動きません。ウェジットを単独テストしてからレイアウトに入れ込めば期待に反する挙動が起きても並べ方が原因だろうと予想出来ます。
問題点と言えば問題点ですが、クセといえばそれまでですし、TkinterやKivyに比べて簡単なことは余りある価値です。これで無理な製作は自分はやらないとすればいいでしょう。
画像は製作途中の物です。パラメータやレイアウトは今後変更していきますが、基本的な機能は実装出来ました。挙動を確認しながら進めていきます。
一般的な音楽プレーヤーには無い機能を考えています。
画面でわかりやすいのは「▼ NEXT ▼」です。プレイリストの順番で再生していくのは当然ですが、これにアサインしてからPLAYに行く前提です。曲順が入れ替わっても前の曲が再生している最中に呼び出せます。照明の卓っぽいですねwww。
あとは、曲間というか次の曲への手順を決めます。曲間が自動停止か続くかはもちろん、次の曲へ渡すまでの秒数を決める様にします。表のNextの列にPauseとあるのは自動停止、秒数らしき数字があるのは曲続きの意味と待ち秒数です。
VLCにも少し問題があります。
スライダーで再生ポジションを表示し変更できる様にしてありますが、スライダーの動作によってはVLCがタイムスタンプのエラーを出します。圧縮が高いmp3の為かもしれませんが原因は不明です。
止まりはしないのですが、エラー発生の後、テンポやピッチが狂うことがあります。ダンスイベントが主目的ですから本番でポジションスライダーを触ることは無いと思いますが、必要な時にテンポやピッチが狂うのは困ります。
処理手順の変更でエラーを防止できないか調べることにします。
追記
ふとアイデアが出て、本業中なのに手を止めて修正www
VLCのエラーは対策が出来たっぽい。
かなり面倒な手順ですが、
０）ポジションスライダーのイベント確認
１）再生停止 stop()
２）ポジションスライダーの情報からポジション値を計算
３）再生開始 play()（タイム00:00:00.00からになります）
４）再生確定まで待つ
５）ポジション値をセット
６）操作が一時停止中ならpause()
といった感じ。
VLCをリセットし、改めて再生して位置を宣言する手順です。
コマンドプロンプトにはエラー表示が出ず、テンポやピッチの狂いも起こっていないようです。
追記の２
mp3ファイルではポジションスライダーの行き来を繰り返すとタイムスタンプがズレることがあります。
いやーな感じでしたが、wavファイル(非圧縮)だと起こりません。mp3の圧縮方法を知っていると納得出来ますし、wavファイルで問題が無いならいいかなと。
#Python
主な制約はウェジット(オブジェクト)の並べ方によって挙動が違うことです。全てではないのですが「ナゼそうなる！？」に出会うことが少なくありません。昨日もExecl的な表示をするTable機能で出くわしてしまい数時間悩んでしまいました。下記の試作品では「Add Music」が今の位置では期待通りの挙動をしますが、表の左隣りでは期待通りに動きません。ウェジットを単独テストしてからレイアウトに入れ込めば期待に反する挙動が起きても並べ方が原因だろうと予想出来ます。
問題点と言えば問題点ですが、クセといえばそれまでですし、TkinterやKivyに比べて簡単なことは余りある価値です。これで無理な製作は自分はやらないとすればいいでしょう。
画像は製作途中の物です。パラメータやレイアウトは今後変更していきますが、基本的な機能は実装出来ました。挙動を確認しながら進めていきます。
一般的な音楽プレーヤーには無い機能を考えています。
画面でわかりやすいのは「▼ NEXT ▼」です。プレイリストの順番で再生していくのは当然ですが、これにアサインしてからPLAYに行く前提です。曲順が入れ替わっても前の曲が再生している最中に呼び出せます。照明の卓っぽいですねwww。
あとは、曲間というか次の曲への手順を決めます。曲間が自動停止か続くかはもちろん、次の曲へ渡すまでの秒数を決める様にします。表のNextの列にPauseとあるのは自動停止、秒数らしき数字があるのは曲続きの意味と待ち秒数です。
VLCにも少し問題があります。
スライダーで再生ポジションを表示し変更できる様にしてありますが、スライダーの動作によってはVLCがタイムスタンプのエラーを出します。圧縮が高いmp3の為かもしれませんが原因は不明です。
止まりはしないのですが、エラー発生の後、テンポやピッチが狂うことがあります。ダンスイベントが主目的ですから本番でポジションスライダーを触ることは無いと思いますが、必要な時にテンポやピッチが狂うのは困ります。
処理手順の変更でエラーを防止できないか調べることにします。
追記
ふとアイデアが出て、本業中なのに手を止めて修正www
VLCのエラーは対策が出来たっぽい。
かなり面倒な手順ですが、
０）ポジションスライダーのイベント確認
１）再生停止 stop()
２）ポジションスライダーの情報からポジション値を計算
３）再生開始 play()（タイム00:00:00.00からになります）
４）再生確定まで待つ
５）ポジション値をセット
６）操作が一時停止中ならpause()
といった感じ。
VLCをリセットし、改めて再生して位置を宣言する手順です。
コマンドプロンプトにはエラー表示が出ず、テンポやピッチの狂いも起こっていないようです。
追記の２
mp3ファイルではポジションスライダーの行き来を繰り返すとタイムスタンプがズレることがあります。
いやーな感じでしたが、wavファイル(非圧縮)だと起こりません。mp3の圧縮方法を知っていると納得出来ますし、wavファイルで問題が無いならいいかなと。
#Python