電装工芸日記
- 舞台照明機器の製作とか -
タグ「Ｃ言語」を含む投稿［57件］（2ページ目）
「Open DMX USB」について考えていたのは移動中アタマが空いていたからです。
学園祭への機材レンタルで搬送をしていたのですが、片道１時間半くらいかかるので考え事をするには丁度良い時間でした。
そんな中で Art-Net Patch も思い出す。余りに難しく、数日アタマを全振りしないと進められないネタのために止まっています。
ミキサー(マージ)、プリディレイ(入力に施す)、プリプロファイルカーブ、パッチ、ポストプロファイルカーブ、ポストディレイ(出力に施す)が主な機能ですが、これらの処理(エフェクターと呼称)は参照して計算、参照して計算、参照して計算をひたすら繰り返します。一つ一つはとても簡単な処理ですが、タイミング良く群のデータを短時間で処理しないといけないので構成が難しく、僅かな無駄が後からボディブローの様に効いてきます。
年齢が年齢なので経験量に対し学習量が少ないなぁ～と思いつつも、オブジェクト指向やマルチスレッドなどが普通に使える様になってきますと今までと違った構成がアタマに浮かんできます。全体を一度に見ると難しい処理ですが、構成を分解・整理すれば分割したライブラリとして進められるんじゃないかと。
厄介なのはミキサーとディレイですが、これらを実現するには最大遅延時間分の過去を送信元分保存しておく必要があります。このデータ構成を良く考え、エフェクターの出入りを一般化して進めれば機能単位での製作が可能になりそうな気がします。
目的に対しその環境や言語をどう使えばいいか具体的な見込みを付けてからデータ構造と処理アルゴリズムの本構成を考えることが大切だと思う今日この頃。
開発のプロからしたら当たり前過ぎることなんでしょうけど。
#[Art-Net] #Ｃ言語 #器具の製作
学園祭への機材レンタルで搬送をしていたのですが、片道１時間半くらいかかるので考え事をするには丁度良い時間でした。
そんな中で Art-Net Patch も思い出す。余りに難しく、数日アタマを全振りしないと進められないネタのために止まっています。
ミキサー(マージ)、プリディレイ(入力に施す)、プリプロファイルカーブ、パッチ、ポストプロファイルカーブ、ポストディレイ(出力に施す)が主な機能ですが、これらの処理(エフェクターと呼称)は参照して計算、参照して計算、参照して計算をひたすら繰り返します。一つ一つはとても簡単な処理ですが、タイミング良く群のデータを短時間で処理しないといけないので構成が難しく、僅かな無駄が後からボディブローの様に効いてきます。
年齢が年齢なので経験量に対し学習量が少ないなぁ～と思いつつも、オブジェクト指向やマルチスレッドなどが普通に使える様になってきますと今までと違った構成がアタマに浮かんできます。全体を一度に見ると難しい処理ですが、構成を分解・整理すれば分割したライブラリとして進められるんじゃないかと。
厄介なのはミキサーとディレイですが、これらを実現するには最大遅延時間分の過去を送信元分保存しておく必要があります。このデータ構成を良く考え、エフェクターの出入りを一般化して進めれば機能単位での製作が可能になりそうな気がします。
目的に対しその環境や言語をどう使えばいいか具体的な見込みを付けてからデータ構造と処理アルゴリズムの本構成を考えることが大切だと思う今日この頃。
開発のプロからしたら当たり前過ぎることなんでしょうけど。
#[Art-Net] #Ｃ言語 #器具の製作
今回の LTC Player と LTC Generator のパソコン側のシステムは全て Python で書いています。
その過程でオブジェクト指向を世に出した先達の気持ちを垣間見ることができたワケですが、そうなるとＣ言語でやってきたこともＣ＋＋にしてみたくなる。時間と脳味噌に空きが無くて１年近く止まっている Art-Net の パッチマシン も完成させたい気持ちがあるのですが、Ｃ＋＋で書いたらスマートに書けそうな気がしてきています。
Ｃ＋＋と言っても ANSI の Ｃ言語にオブジェクト指向を追加して書きやすくしたモノとしか思えませんし、実際、ANSI の Ｃ言語の記述やライブラリが混在しても大半が動きます。記述の違いは少なくありませんが、標準語に対する津軽弁や鹿児島弁の違いより容易いと思われます。
ただ、Art-Netパッチはデータベースや財務系の処理をするとの近い気がしますので、SQL や COBOL を勉強しておくと参考になりそうな気もします。これらは群のデータを扱うことに特化していますからね。Ｃ言語で SQL を扱うのは敷居が高そうですし、この時代 COBOL の情報を探すのは無理がありそうですから、Python で SQL を扱う勉強を少ししようと思います。
#Ｃ言語
その過程でオブジェクト指向を世に出した先達の気持ちを垣間見ることができたワケですが、そうなるとＣ言語でやってきたこともＣ＋＋にしてみたくなる。時間と脳味噌に空きが無くて１年近く止まっている Art-Net の パッチマシン も完成させたい気持ちがあるのですが、Ｃ＋＋で書いたらスマートに書けそうな気がしてきています。
Ｃ＋＋と言っても ANSI の Ｃ言語にオブジェクト指向を追加して書きやすくしたモノとしか思えませんし、実際、ANSI の Ｃ言語の記述やライブラリが混在しても大半が動きます。記述の違いは少なくありませんが、標準語に対する津軽弁や鹿児島弁の違いより容易いと思われます。
ただ、Art-Netパッチはデータベースや財務系の処理をするとの近い気がしますので、SQL や COBOL を勉強しておくと参考になりそうな気もします。これらは群のデータを扱うことに特化していますからね。Ｃ言語で SQL を扱うのは敷居が高そうですし、この時代 COBOL の情報を探すのは無理がありそうですから、Python で SQL を扱う勉強を少ししようと思います。
#Ｃ言語
ホール管理の増員で操作盤の置物になっているだけなので調べモノをし放題です。
PythonのライブラリをＣ言語で作る方法の基本はわかりました。このサイトだけでほぼ解決。
製作手順を大まかに書き出すと、
１）関数ライブラリを用意する。
Ｃ言語で#includeして使える関数なら汎用でも自作でも何でもいい。
２）「ラッパー関数」を用意する。
Ｃ言語の関数をPythonへ引き渡す定義をするソースファイル。Pythonからの呼び出し方と変数の変換方法をＣ言語で記述します。
３）セットアップファイルを用意する。
セットアップファイルはgccで言うところのMakeFileです。Pythonで記述され、ファイル名はsetup.pyにすることが多いそうです。
４）ビルドする。
セットアップファイルを使ってビルドする。
５）インストールする。
セットアップファイルを使ってインストールする（動作の実際はPythonパッケージ管理のpipへの登録）。
と、なります。
ラッパー関数はＣ言語とPythonの両方を知らないと記述出来ないので少し難しいですが、セットアップファイルは定型の通り記述するだけです。
#Ｃ言語 #Python
PythonのライブラリをＣ言語で作る方法の基本はわかりました。このサイトだけでほぼ解決。
製作手順を大まかに書き出すと、
１）関数ライブラリを用意する。
Ｃ言語で#includeして使える関数なら汎用でも自作でも何でもいい。
２）「ラッパー関数」を用意する。
Ｃ言語の関数をPythonへ引き渡す定義をするソースファイル。Pythonからの呼び出し方と変数の変換方法をＣ言語で記述します。
３）セットアップファイルを用意する。
セットアップファイルはgccで言うところのMakeFileです。Pythonで記述され、ファイル名はsetup.pyにすることが多いそうです。
４）ビルドする。
セットアップファイルを使ってビルドする。
５）インストールする。
セットアップファイルを使ってインストールする（動作の実際はPythonパッケージ管理のpipへの登録）。
と、なります。
ラッパー関数はＣ言語とPythonの両方を知らないと記述出来ないので少し難しいですが、セットアップファイルは定型の通り記述するだけです。
#Ｃ言語 #Python
試してはいませんが、Linux系で音源を再生するのは簡単っぽいです。
モジュールの種類はいくつもありますし、コマンドに音源ファイル名を付けて叩くだけの物もあります。
ファイルブラウザを作れるなら、プレーヤー自体を作ることは難易度が低そうです。
ただ、再生中の音源が現在何分何秒目かを得る方法が見当たりません。音源再生のライブラリに秒数を得る関数あるかもしれませんが、ネットの記事には「簡単に音源を再生出来るぢょ♪」という趣旨の物が多いのでそこまで解説してなくても仕方ないのかな？。タイム情報はガチのプレーヤーを作らなきゃ不要ですしね。
合間に調べを進めましょう。
目指す物は、音源に手を加えず、音源にタイムコードを加えたのと同じ結果を得られるプレーヤーです。
#Ｃ言語 #RaspberryPi
モジュールの種類はいくつもありますし、コマンドに音源ファイル名を付けて叩くだけの物もあります。
ファイルブラウザを作れるなら、プレーヤー自体を作ることは難易度が低そうです。
ただ、再生中の音源が現在何分何秒目かを得る方法が見当たりません。音源再生のライブラリに秒数を得る関数あるかもしれませんが、ネットの記事には「簡単に音源を再生出来るぢょ♪」という趣旨の物が多いのでそこまで解説してなくても仕方ないのかな？。タイム情報はガチのプレーヤーを作らなきゃ不要ですしね。
合間に調べを進めましょう。
目指す物は、音源に手を加えず、音源にタイムコードを加えたのと同じ結果を得られるプレーヤーです。
#Ｃ言語 #RaspberryPi
リノリュームを敷いてバラすだけなので、ヒマ潰しでＣ言語の勉強をしてます。
youtubeの「Ｃ言語入門」がナカナカ良いです。
初心者向けと言えば初心者向けですが、他の言語をある程度書けるＣ言語初心者さんとか、初心者は卒業したかな？って人が基本を再確認するのに良い内容だと思います。私もその1人です。
プログラム初心者さんがＣ言語から始めるのはオススメしませんけどね。
追記
気を抜いてyoutubeを見ていたら「照明オペしてくれませんか！？」との依頼。ホールさんが仕込んてくれた地明とホリゾントで主催者操作の予定でしたが色々あって人手不足とのこと。暇ツブシを考えていたので問題ナシ。
ホールの卓は松村電機さんのF151。私は好きな卓です。悪く言えば無芸ですが、欠点もありません。自分の主義ですが、ホール卓は基本的な機能を少ない手数で迷わず使えるのが望ましい。操作に一貫性があるシンプル・イズ・ベストってことです。F151は正にそんな卓です。作られた時期的に搭載されていないだけですが、JASCII(ASCII)の読み書きとパッチアウト(インパッチ??)が出来たらホール卓として丁度いいと思います。残念ながら今は廃番です。
イチイチご機嫌を伺わないといけない某Ｍ社の卓は嫌いです。
#Ｃ言語
youtubeの「Ｃ言語入門」がナカナカ良いです。
初心者向けと言えば初心者向けですが、他の言語をある程度書けるＣ言語初心者さんとか、初心者は卒業したかな？って人が基本を再確認するのに良い内容だと思います。私もその1人です。
プログラム初心者さんがＣ言語から始めるのはオススメしませんけどね。
追記
気を抜いてyoutubeを見ていたら「照明オペしてくれませんか！？」との依頼。ホールさんが仕込んてくれた地明とホリゾントで主催者操作の予定でしたが色々あって人手不足とのこと。暇ツブシを考えていたので問題ナシ。
ホールの卓は松村電機さんのF151。私は好きな卓です。悪く言えば無芸ですが、欠点もありません。自分の主義ですが、ホール卓は基本的な機能を少ない手数で迷わず使えるのが望ましい。操作に一貫性があるシンプル・イズ・ベストってことです。F151は正にそんな卓です。作られた時期的に搭載されていないだけですが、JASCII(ASCII)の読み書きとパッチアウト(インパッチ??)が出来たらホール卓として丁度いいと思います。残念ながら今は廃番です。
イチイチご機嫌を伺わないといけない某Ｍ社の卓は嫌いです。
#Ｃ言語
思った以上に本業が忙しくなってしまいましたが、アルゴリズムの検討はしています。
今はキー入力からコマンドを起こす処理です。これも思った以上に難しい。
入力されたコマンドを実行する際に処理が出来なければエラーを吐く方法もアリですが、入力する途中で制限をかけた方がコマンド実行に負担をかけないのでいいかなと。
また、コマンドの入力中でも一部の機能は実行したい。例えばランプチェックなどです。入力中に状況を確認して最終決定が出来れば操作性が良くなるからです。コマンド入力が確定せずともそれをチェックし、構文確認や一部の機能を実行出来る様にしたいのです。
とまぁ、言うのは簡単ですが、これをどう処理したものか。ケースバイケースでベタ処理を書くのは無駄が多いので、出来る限りリソースを汎用化することでメンテナンス性も良くしておきたい。プログラム書きの基本だと思っていますが、同じ処理は一つしか書かないってことです。
#Ｃ言語
今はキー入力からコマンドを起こす処理です。これも思った以上に難しい。
入力されたコマンドを実行する際に処理が出来なければエラーを吐く方法もアリですが、入力する途中で制限をかけた方がコマンド実行に負担をかけないのでいいかなと。
また、コマンドの入力中でも一部の機能は実行したい。例えばランプチェックなどです。入力中に状況を確認して最終決定が出来れば操作性が良くなるからです。コマンド入力が確定せずともそれをチェックし、構文確認や一部の機能を実行出来る様にしたいのです。
とまぁ、言うのは簡単ですが、これをどう処理したものか。ケースバイケースでベタ処理を書くのは無駄が多いので、出来る限りリソースを汎用化することでメンテナンス性も良くしておきたい。プログラム書きの基本だと思っていますが、同じ処理は一つしか書かないってことです。
#Ｃ言語
ANSIエスケープシーケンスによるテキスト画面表示はやりたいことのやり方が見えてきました。先にも書いた通り、ウィンドウマネージャに近い考え方で関数ライブラリにまとめる方針です。
ArtNet-Engineの主処理を書き進めたいところですが、処理の状況を確認する手段が無いと作業性が悪いので画面表示を一通り作ってしまおうという考え方です。
平行してコマンド入力も作っています。ArtNet-Engineの主処理に先行するのは画面と同じ理由ですが、この辺りが見えてこないと処理全体の構成を決めかねることにも繋がるからです。
ですが、コマンド入力がなかなか手ごわい。画面表示であれば決められた手順で結果が出ればいいのですが、コマンド入力は規則性が薄いユーザーの操作を受け付けるからです。scanf()などを用いて文字列を取得するのは簡単ですが、これではイメージする操作性にはなりません。特定のキーをショートカットのコマンド入力とし、一つ目のコマンドに続くコマンドを制限したい。コマンドに与える数値も範囲を制限もしたい。もちろん、適切なエラーメッセージを入力の都度出したい。キー入力の都度、制限と処理を行うことになりますが案外難しい。ダラダラとコマンド毎に専用処理を書いてもいいのですが、メンテナンス性を考えると出来るだけ汎用化したい。もちろん、他のコマンドを学習したユーザーがこのコマンドはこう打てばいいだろうと予測出来る適切なコマンド体系にもしたい。プログラムを書く前のアルゴリズムを考えるのに難儀しています。
#[Art-Net] #Ｃ言語
ArtNet-Engineの主処理を書き進めたいところですが、処理の状況を確認する手段が無いと作業性が悪いので画面表示を一通り作ってしまおうという考え方です。
平行してコマンド入力も作っています。ArtNet-Engineの主処理に先行するのは画面と同じ理由ですが、この辺りが見えてこないと処理全体の構成を決めかねることにも繋がるからです。
ですが、コマンド入力がなかなか手ごわい。画面表示であれば決められた手順で結果が出ればいいのですが、コマンド入力は規則性が薄いユーザーの操作を受け付けるからです。scanf()などを用いて文字列を取得するのは簡単ですが、これではイメージする操作性にはなりません。特定のキーをショートカットのコマンド入力とし、一つ目のコマンドに続くコマンドを制限したい。コマンドに与える数値も範囲を制限もしたい。もちろん、適切なエラーメッセージを入力の都度出したい。キー入力の都度、制限と処理を行うことになりますが案外難しい。ダラダラとコマンド毎に専用処理を書いてもいいのですが、メンテナンス性を考えると出来るだけ汎用化したい。もちろん、他のコマンドを学習したユーザーがこのコマンドはこう打てばいいだろうと予測出来る適切なコマンド体系にもしたい。プログラムを書く前のアルゴリズムを考えるのに難儀しています。
#[Art-Net] #Ｃ言語
追い込まれる程ではありませんが、本業がジンワリと忙しくなってきました。開発はボチボチペースで進めます。
ANSIエスケープシーケンスを使った画面表示の試作をしています。フリッカーを起こさないコツがわかったので表示が安定しています。
ただ、罫線の表示で少し疑問。解決はしたのですが不思議。
罫線素片はASCIIコードに含まれていませんのでシステム標準のUTF-8を使います。文字列リテラル"\u2500"とすれば横線が表示されます。"\u"は続く数値がUTF-8の文字コードであることを示すエスケープで"2500"は文字コードです。
不思議なのは、同じ文字列リテラルを16進数で表すと"\xE2\x94\x80"となることです。最初の"\xE2"はエスケープ文字なのでヨシとしても、続く"\x94\x40"がよくわからない。何らかの理由でオフセットしているのは確かですが、オフセット値が中途半端です。また、この表記だとビッグエンディアンなのでリトルエンディアンのRaspberryPiでナゼ？という疑問もあります。罫線素片のコード領域の起点を0x2500から0x9480に置き換えればいいだけなのですが、どうしてこうしたのでしょう。Rasbianが動くRaspberryPiに限った話なのかはわかりませんが動くように使うしかありません。
ということで、テキストのコンソール画面に罫線表示も出来る様になりました。
試作プログラムは不器用なベタ書きですが、ウィンドウマネージャもどきの関数ライブラリにしてみようと思います。
#Ｃ言語 #RaspberryPi
ANSIエスケープシーケンスを使った画面表示の試作をしています。フリッカーを起こさないコツがわかったので表示が安定しています。
ただ、罫線の表示で少し疑問。解決はしたのですが不思議。
罫線素片はASCIIコードに含まれていませんのでシステム標準のUTF-8を使います。文字列リテラル"\u2500"とすれば横線が表示されます。"\u"は続く数値がUTF-8の文字コードであることを示すエスケープで"2500"は文字コードです。
不思議なのは、同じ文字列リテラルを16進数で表すと"\xE2\x94\x80"となることです。最初の"\xE2"はエスケープ文字なのでヨシとしても、続く"\x94\x40"がよくわからない。何らかの理由でオフセットしているのは確かですが、オフセット値が中途半端です。また、この表記だとビッグエンディアンなのでリトルエンディアンのRaspberryPiでナゼ？という疑問もあります。罫線素片のコード領域の起点を0x2500から0x9480に置き換えればいいだけなのですが、どうしてこうしたのでしょう。Rasbianが動くRaspberryPiに限った話なのかはわかりませんが動くように使うしかありません。
ということで、テキストのコンソール画面に罫線表示も出来る様になりました。
試作プログラムは不器用なベタ書きですが、ウィンドウマネージャもどきの関数ライブラリにしてみようと思います。
#Ｃ言語 #RaspberryPi
本業はちょいちょいで終わったのでArtNet-Engineを書き進めました。
ユニバースによる処理時間のムラはサンプルデータとして使っているMAdot2の仕様によるものみたいです。細かくは計測していませんが、８ユニバース出すとして、ユニバース毎に均等の時間割りで送信するのではなく、８ユニバースを一気に送信して長い休みを入れているようです。このため、最初のユニバースでは処理が重くなり、後のユニバースでは処理が軽くなる現象が起きるのだと思われます。主にArtNet-Engineからの送信に影響があったようで、受信したら即送信していたものを一時スタックしてからユニバース毎に均等の時間割りで送信する様にしたところムラが無くなりました。RaspberryPiの送信処理に何か負担がかかっていたのでしょう。
現時点での１フェーズの処理時間は平均して100usec以下です。出現確率が高い例外値が250usecくらいで、極マレに出てくる最大値が900usecくらいです。処理時間が保証されないOSですからこんなもん？。
作りたい物にはなりそうですが、８ユニバース８卓(６４ユニバース入力)は厳しい気がします。これに対応するには１フェーズが確実に350usec未満でなければなりませんが、例外値がやってきた時にプリフリーズを起こしそうです。登録できる調光卓(送信元)は８台ですが、同時に使える(HTPミックスの対象となる)のを３-４台くらいにしておけば現実的かもしれません。Art-Netの規格書に「マルチキャストは４０ユニバースが上限だと思いますよ」と書いてあるのは伊達じゃないようです。
どの要素が時間を使っているのか不明なので組んで実測しますかね。ダメなら減らすダケです。
ただ、構造体とポインタが使えるとこういったデータ処理は楽です。構造体はPythonのタプルに似ていますがシンプルなのでPythonより書きやすいかもしれません。ポインタは参照渡しですのでデータの扱いが速いのです。それ以前に何をするにも速いですけど。
追記
調整したところ、１ユニバース受信する１フェーズが平均30usec、例外値が200usec程度になりました。
同時に８卓使っても１本のArt-Netに統合する現場はマレだと思いますケド、間に合いそうな数値が出たので、その様に書いて後で調整します。増やすのは大変ですが減らすのは簡単ですから。
送信の間隔はユニバース数と希望fps数から自動計算にしました。将来的にfpsを設定して調整出来れば良いかなと。
#[Art-Net] #Ｃ言語
ユニバースによる処理時間のムラはサンプルデータとして使っているMAdot2の仕様によるものみたいです。細かくは計測していませんが、８ユニバース出すとして、ユニバース毎に均等の時間割りで送信するのではなく、８ユニバースを一気に送信して長い休みを入れているようです。このため、最初のユニバースでは処理が重くなり、後のユニバースでは処理が軽くなる現象が起きるのだと思われます。主にArtNet-Engineからの送信に影響があったようで、受信したら即送信していたものを一時スタックしてからユニバース毎に均等の時間割りで送信する様にしたところムラが無くなりました。RaspberryPiの送信処理に何か負担がかかっていたのでしょう。
現時点での１フェーズの処理時間は平均して100usec以下です。出現確率が高い例外値が250usecくらいで、極マレに出てくる最大値が900usecくらいです。処理時間が保証されないOSですからこんなもん？。
作りたい物にはなりそうですが、８ユニバース８卓(６４ユニバース入力)は厳しい気がします。これに対応するには１フェーズが確実に350usec未満でなければなりませんが、例外値がやってきた時にプリフリーズを起こしそうです。登録できる調光卓(送信元)は８台ですが、同時に使える(HTPミックスの対象となる)のを３-４台くらいにしておけば現実的かもしれません。Art-Netの規格書に「マルチキャストは４０ユニバースが上限だと思いますよ」と書いてあるのは伊達じゃないようです。
どの要素が時間を使っているのか不明なので組んで実測しますかね。ダメなら減らすダケです。
ただ、構造体とポインタが使えるとこういったデータ処理は楽です。構造体はPythonのタプルに似ていますがシンプルなのでPythonより書きやすいかもしれません。ポインタは参照渡しですのでデータの扱いが速いのです。それ以前に何をするにも速いですけど。
追記
調整したところ、１ユニバース受信する１フェーズが平均30usec、例外値が200usec程度になりました。
同時に８卓使っても１本のArt-Netに統合する現場はマレだと思いますケド、間に合いそうな数値が出たので、その様に書いて後で調整します。増やすのは大変ですが減らすのは簡単ですから。
送信の間隔はユニバース数と希望fps数から自動計算にしました。将来的にfpsを設定して調整出来れば良いかなと。
#[Art-Net] #Ｃ言語
本業もやらねばなりませんがArtNet-Engineも進めたい。
ArtNet-Engineの課題はデータ処理の構成です。
まずは入力です。同じネットワークに複数の調光卓を繋ぐことは出来ますが、ユニバースの重複によるトラブルには対策が必要です。
送信元IPアドレスで仕訳けることが基本になると思いますが、どうせなら選択しつつマージしてしまおうかと。
フェスなどでは複数の調光卓を設置して使い分けるのはよくあることです。単純な差し替えとかネットワーク切り替え機などを使ってもいいのですが、選択とマージ(HTPミックス)が出来たらそれはそれでいいかなと。バックアップ卓を併設することも出来るし。
内部的には８ユニバースのパッチを考えていますが卓も８台想定します。６４ユニバースの交通整理をするのでRaspberryPiの処理能力で間に合うのかわかりませんがダメなら数を減らします。
当面は送信元の仕分けと６４ユニバースを８ユニバースにマージする処理を書きます。
処理の構造をどうするか考えていますが、データの保存には構造体配列や構造体の中に構造体を入れるなど複雑な変数構成が必要になりそうです。
Pythonとは違い、for文が速いＣ言語なら繰り返しと条件分岐を織り交ぜた処理も書きやすそうです。Ｃ言語の習得の難所でもあるポインタもこういった処理では効果を発揮します。
#[Art-Net] #Ｃ言語
ArtNet-Engineの課題はデータ処理の構成です。
まずは入力です。同じネットワークに複数の調光卓を繋ぐことは出来ますが、ユニバースの重複によるトラブルには対策が必要です。
送信元IPアドレスで仕訳けることが基本になると思いますが、どうせなら選択しつつマージしてしまおうかと。
フェスなどでは複数の調光卓を設置して使い分けるのはよくあることです。単純な差し替えとかネットワーク切り替え機などを使ってもいいのですが、選択とマージ(HTPミックス)が出来たらそれはそれでいいかなと。バックアップ卓を併設することも出来るし。
内部的には８ユニバースのパッチを考えていますが卓も８台想定します。６４ユニバースの交通整理をするのでRaspberryPiの処理能力で間に合うのかわかりませんがダメなら数を減らします。
当面は送信元の仕分けと６４ユニバースを８ユニバースにマージする処理を書きます。
処理の構造をどうするか考えていますが、データの保存には構造体配列や構造体の中に構造体を入れるなど複雑な変数構成が必要になりそうです。
Pythonとは違い、for文が速いＣ言語なら繰り返しと条件分岐を織り交ぜた処理も書きやすそうです。Ｃ言語の習得の難所でもあるポインタもこういった処理では効果を発揮します。
#[Art-Net] #Ｃ言語