オープンサウンドデータでは、2019年発足当初はESU社のLokSound向けとしてサウンドデータの提供を開始しました。2023年からは、DesktopStation・Nagoden・SmileWorks・DCC電子工作連合による独自のサウンドデコーダであるSmileSoundのサポートも開始しました。
ここでは、サウンドデータ作成方法の違いについて、述べていきたいと思います。
SmileSoundからサウンドデータの作成に入られた方や、プログラミングをお仕事とされている方や学校で学んできた方には、馴染みのある仕様になっていますが、LokSoundでデータを作成されてきた方には謎ばかりと思うかもしれません。
ここでは、その違いが何に起因しているのかということと、LokSoundからSmileSoundへ移行するにあたり、考え方をまとめたいと思います。プログラミングの視点から考えると、以下のように違いがあります。ちょっと分かりにくい表現ですが、1つずつ説明していきます。
SmileSound | LokSound | |
サウンドデータ作成ツール | DSSP | LokProgrammer |
動作方法 | 逐次処理 | イベント駆動 |
プログラミング方法 | スクリプト | 状態遷移(ブロック図) |
条件分岐の扱い | ユーザーが条件分岐をスクリプトごとに記述。 | ブロックごとに条件分岐を記述。 分岐箇所はブロック図ごとに制約 |
動作方法
SmileSoundでは、逐次処理と呼ばれる動作方法を採用しています。逐次とは、”1つずつ順番に”、という意味で考えてください。運動会のプログラムと一緒で、上から順番に、競技を行っていきますよね。それと一緒です。これは、プログラミング言語では一般的なもので、プログラマにとってはとっつきやすい記述法です。ブロック(処理)が終わったら自動的に下に行きます。そして、条件分岐の命令を書いたときだけ、その条件に従ってジャンプしたり、特定の動作をさせたりします。
一方、LokSoundでは、イベント駆動(イベントドリブン)を採用しています。これは、「ある条件が成立したら、Aブロック、この条件が成立したらBブロックにジャンプしてください」という記述方法です。この考え方も、プログラミング言語で使われますが、複雑な条件分岐を扱うと、複雑化しやすいという弱点があります。また、この方法では、必ず他のブロックに動くときには条件を設定しなければなりません。よって、終わったら必ず特定のブロックにしか行かない場合でも、「常にTRUE」などのようなダミーの条件を設定しなければなりません。
プログラミング方法
SmileSoundとLokSoundでは、プログラミング方法が異なります。スクリプトと状態遷移図(ブロック図)という大きな違いがあるためです。どちらも利点・欠点があり、受け取り方は個人差があるでしょう。状態遷移図をスクリプトで表現する事もできますし、スクリプトを状態遷移図に書き直すこともできます。ただし、表現力としてはスクリプトの方が大きいのが一般的です。しかし、上から1行ずつプログラミングしなければなりませんので、慣れが必要です。
条件分岐の扱い
この部分が一番混乱するかと思います。上で説明した通り、SmileSoundでは分岐をコマンドで表現しなければなりません。この分岐が成立しなければ下に逐次処理で動いてしまうので、そのことを考慮して作らないといけません。ここが面倒なところです。LokSoundの場合は、→に条件を記述しておくと、その条件が成立するまでブロックから動きません。条件分岐の表現は、LokSoundの方が圧倒的に書きやすく、分かりやすいです。しかし、これが弱点となるケースもあります。たとえば条件分岐が多すぎるときは膨大な→の山となります。