(English)
I can understand that "software" sounds like something unknown and you might not want to use it just because it is "software"... I used to draw design for electrical circuits, so I can totally understand how that feels. For someone who is feeling that way, let me explain a little about the internal design.

(Japanese)
ソフトウェアというだけで得体の知れないものに見えてしまって使う気が起きないのも理解している。 僕は電気回路図面を書いていたから、その気持ちは痛いほどわかるんだ。 だから、ここでは少しだけ内部設計について明らかにしておくよ。

(English)
The SYRO transfer stream is consisted of 16-bit monaural WAV file. Digital signal is designed to be able to carried together on the analog audio. SYRO SDK from KORG can input a 16-bit monaural WAV file, which is an audio data, and output a 16-bit monaural SYRO transport stream. Due to the time constraints of design and implementation, we decided to use the implementation from KORG as it is for the part that generates the SYRO transport stream. The SYRO SDK's WAV data input section is premised on a 16-bit monaural WAV file. So we have added the processing for normalization of WAV file format in the pre processing stage. "WAV File Pre Processor" is the part that performs normalization processing. "SYRO Transport Stream" which is output by SYRO SDK, will be output as an audio output module and delivered to volca sample. Easy, right?

(Japanese)
SYRO転送ストリームは、16ビットモノラルのWAVファイルで構成される。 このアナログオーディオにディジタルの信号を乗せることができるように設計されている。 KORGのSYRO SDKのサンプルは音声データである16ビットモノラルのWAVファイルを入力して、16ビットモノラルのSYRO転送ストリームを出力するようになっている。 設計と実装の時間的な制約から、SYRO転送ストリームを生成する箇所はKORG社の実装をほぼそのまま流用することにした。 SYRO SDKのWAVデータ入力部は16ビットモノラルのWAVファイルが前提になっているから、その前段でWAVファイルのフォーマットを正規化する処理を追加した。 "WAV File Pre Processor"と書かれた部分が正規化処理を行う部分だ。 SYRO SDKで出力した"SYRO Transport Stream"をAudio Output Moduleで音声出力してvolca sampleに届けるという仕組みになっている。 簡単でしょ？

(English)
Below is the diagram for someone who may want to know the architecture.

(Japanese)
中身のアーキテクチャがどうなっているのか知りたい人もいるだろうから図を書いておいたよ。

(English)
The software is designed with 2 layers. One core part that does not reply on the User Interface and will process the primitive data. The other part is the GUI part, which is literally the part that handles the User Interface and core part. Since we wanted to separate the core functions and the User Interface we made the core part functions independently as a lower layer library. In this way, you do not have to worry if the Use Interface needs to be completely different for some reason, and you can quickly add new features to solve the essential problems quickly. I recommend this method for your software development! to conclude, the core part of this software os roughly divided into 2 parts: a Converter part that processes input and a Transporter part that processes output. Looking at these block diagrams, the overall structure is easy to understand, isn't is?

(Japanese)
ソフトウェアは2層に分かれて設計されている。 コア部分がユーザーインターフェースに依存しないプリミティブなデータ処理を行う部分。 GUI部分は文字通り、ユーザーインターフェースとコア部分を操作する処理を行う部分だ。 基幹機能とユーザーインターフェースは分離できるようにしたかったので、基幹部分は下層ライブラリとして独立して機能するようにした。 こうすれば何らかの事情でユーザーインターフェースを全く別のものにしたくなった時でも困らずに済むし、新しい機能を追加する時も素早く本質的な問題から解決できるんだ。 この方法はお勧めだよ。 このソフトウェアの基幹部分は、入力を処理するConverter部分と、出力を処理するTransporter部分の二つに大きく分かれている。 こういったブロック図で見ると全体構造がわかりやすいね。