FC2ブログ

書き終わってから思ったけど、かなり置いてけぼりな内容になってますね、これ。^^;

Max(プログラム言語)
01 /19 2018
みなさま、どうもです。

180119_1.jpg
※画像をクリックすると拡大写真が見れます。


何かとネタにしているミキサーくんもやっとゴールが見えてきました。

今で全体の8割ぐらいまでは設計できたのではないかと思います。
正直、そんなに本格的な物を作るつもりは全くなかったのに...(苦笑)。
(こういうの、一度やり始めると自分なりの完璧を求めてしまうんですよね。^^;)

以前書いていた『マルチトラックレコーディング機能』ですが、全然問題なく実装することができました。
CPUとハードディスクの頑張り次第ですけど、理論的にはメインアウトとモノラル10チャンネル分で最大11ファイル分を同時録りすることができると思います...まだ試せていないけど。^^;
(メインアウト含む4チャンネル分ぐらいの同時録音までしか試せていない。)

ただ、Max/MSPの仕様(というか、同時処理ができない都合上)の問題で少し違和感を生じることがありますが...これは使う人じゃなければまったく訳わかめな話なのでやめときます(笑)。


まあ、そんな感じなんですけども、ついでなのでこのツールの中身(ソース)を少し公開したいと思います。
ちょっとサイズがでかすぎるのでかなり縮小させてますけどもご了承くださいませ。^^;

180119_2.jpg
180119_3.jpg
※画像をクリックすると拡大写真が見れます。

拡大画像を見たところで???ではあるんですけども、上のツールの中身(ソース)はこんな感じなんですね。
これでも一つ一つの機能を一個の箱(オブジェクト)に詰め込んで、ある程度はスッキリさせてるんですけど、まともに全部公開しようもんなら20枚近くは撮らなければいけないぐらいのボリュームになってます。
少なくとも簡単なシーケンスツール(リズムマシン系)を作るようなノリのボリュームではないということを言いたいわけです。

当初の予定では上の2枚ぐらいのサイズの量で作れるボリュームのもののはずやったんやけどなあ。
(少なくともプレイヤーやらサンプラーは全く考えていなかった。)

...うん、ほんま、どうしてこうなった?(笑)


あと、先日書いていたオーディオプレーヤーと簡易サンプラー(ポン出し)機能について。

180119_4.jpg
※画像をクリックすると拡大写真が見れます。

サンプラーは5個のオーディオファイルを読み込めます。
再生範囲やら再生速度も変更したりすることもできます。
ただし、ポン出し的な機能にしたかったのでベロシティ(音の強弱)やらループ機能は対応してません。
音のボリューム調整(ノーマライズ含む)ぐらいで直接の音色加工はできない(※)仕組みになってます。
うん、本当にただの『ポン出し』機能。
(※インサートエフェクターとセンドエフェクターを通すことはできます。)

オーディオプレーヤーは無駄にDJ仕様(Eqとフィルター内蔵)にしてみたりと。
ただ単にプレイヤーの音をいじって遊びたかっただけなんですけども。

フィルターのスライダーをいじってたら気分は無駄にクラブDJ的な感じになれる...かもしれないです。
...いや、僕がなりたいだけやな。^^;


そんな感じで、使い方によってはハードのミキサーを使わずにこれを使ってライブをすることもできるかもしれないです...今の時代、ライブで使えるDTMソフトはなんぼでもあるんでわざわざそんな暴挙をやるメリットはあまりないですけどね(笑)。

でも、外部のエフェクターソフトを読み込めるんで音作りをしたうえでデモを作成するにはいいかもしれないです。
簡易プリアンプやらオーディオプレイヤーもついてるからいわゆる「歌ってみた」系の録音とかにはいいかも。
(メインアウトとチャンネルを別々に録音することもできるし!)

うん、僕は一体何がしたいんやろ?(笑)

今回もこのような記事にお付き合いして頂き、本当にありがとうございます。

動画をアップロードするのってこんなに怖いのね。^^;

Max(プログラム言語)
07 /05 2017
みなさま、どうもです。


人生初マイ動画


ここ最近、ブラックな記事が続いていてなんかすみません。^^;

とういうわけで、生まれて初めて動画を作ってYoutubeにアップロードしてみました。

うん、恐いですね。
こんな稚拙な動画を世に出してしまってええのか?と...そんな感じで投稿し終わってからの後悔が半端ないです。
改めて動画を作っている人はすごいなと痛感した次第です(笑)。


元々は別のアプリケーションの紹介動画をちゃんと(?)作ろうと思って色々とやっていたのですが、如何せん動画作成のノウハウや映像編集ソフトの使い方が全く分からずお手上げ状態。\(^o^)/
埒が開かないので、できるところから挑戦してみようと思って奮闘した結果がこの動画です。

動画でいじってるソフトはこのブログでも何度か紹介していたd-process(通称、デプロ)の最新版です。
(まだ工事中のため、このバージョンはサイトにはアップロードしていません。)

過去に何度か音声データの形式としてブログでも公開はしていたんですが、やってることがやってることだけに映像が無いとなかなか伝わらないので、これをきっかけに映像として見せれるものを作ってみました。
『破壊系ランダム・シーケンサー』と一言で言うのは簡単ですけど、実際にそれを頭の中でイメージして頂くには言葉足らずな部分が多すぎるので難しいですから。^^;
(「ちゃんと説明して」って言われてもできる自信がないですね(苦笑)。)

あと、なぜかテロップが英語ですが、Max/Mspに興味持っているのは国内よりも国外の方の方が多いだろうということで今回は(できもしないくせに)英語にしています。
おそらく動画内の英語はどこか間違っているような気がします。
正直、ツッコミが来るのが物凄く怖いです。投稿し終わってからずっと胃が痛いです。^^;

...とまあ、とりあえずはそんな感じです。


Max/Mspを使ったネタや動画を上手い事ブログに活かしたいんですけど...思った以上に難しそうですね。
とりあえずは目先の事をどうにかしよう。^^;


【追記】
改めて動画を見直して思ったけど、意味の無い無駄な行動が多すぎ(苦笑)。
(操作ミスとかそういう意味で。)

今回もこのような記事にお付き合いして頂き、本当にありがとうございます。

こういうの一般向きと言いながら実は自分用に作っている人が多いんだって。ww

Max(プログラム言語)
10 /01 2016
みなさま、どうもです。

20161001.jpg


うーん、なんか久々にちゃんとした記事を書くような気がする...。
別に前回までの記事があかん記事を書いていたわけではないんですが、ああいうノリはあまり得意ではないですな。
というか、見苦しいイラストを何枚も公開してすみませんでしたと(笑)。
(ただし、前回のはあかん記事やなとは思っている(苦笑)。)

...まあ、今さらな話なんですけども。^^;

さて、ブログじゃなくてWebサイトの方の連絡なんですが、生意気にもMaxのTips集なるコンテンツを作ってみました。
とは言っても、まだ記事が1個しかできておりませんが。^^;

Maxで色々と作業用エディター的なパッチを何個も作っていくうちに残しておきたい処理が何個もあるのでTips集的なコンテンツを作ろうと思った次第です。

ぶっちゃけ、Tips集とは名ばかりで実質的にはハタヤマが自分がまた使いそうな処理を忘れないための備忘録的な感じだったりします。
オブジェクト単位として個別にソースファイルとしては残しているんですけども、いざ再利用しようと開いたときには処理の流れを忘れてしまっているということが結構あったりしますので...。^^;

ほんと、Tips集とか生意気なタイトルをつけてしまってすみません。

まあ、だいぶ昔にブログでもMax講座的な記事を何個か書いていたんですが、ああいうノリで書いています。
かなり適当です。僕、本職エンジニアじゃないんでそこまで詳しくないっていうか、キレイなプログラムを書くことに命をかけている人間でもないんで。^^;
(正直、悪さ(メモリーリークとかいったPCにダメージを与える動き)をせずに動けばええねん。ぐらいにしか思っていなかったりする訳で...。)

なので、「この方がもっとよくね?」なコーディングとかあると思いますけど、ただ、嘘は書いていないとは思います...たぶん。
まあ、さわれる人はまずこんなの頼らない(見ない)でしょ(笑)。

と、冗談はともかく、まあゆるい感じでやってます。
ちなみに第1回目はdropfileオブジェクト(※↑の画像)の基礎的な使い方について書いています。
興味がございましたらどうぞ。
こちらから。

今回もこのような記事にお付き合いして頂き、本当にありがとうございます。

simple_st_comp

Max(プログラム言語)
04 /08 2016
みなさま、どうもです。

exsample_patch_160408.jpg

Maxで作ったシンプルなコンプレッサー。
あくまでも今作ってるドラムサンプラーの一機能として作成。

と言っても、MAXのリファレンス(チュートリアル)に載ってたコンプレッサーを基にステレオコンプ化させただけのものなので全くのオリジナルとは言えませんが。^^;

Battery3に付いてるコンプ機能を自分なりに真似したかったので準備してみました。
NI社には申し訳ないんですけど、Battery3のコンプ機能、いまいち好きじゃないんで。
(注:ハタヤマが使いこなせないだけです。)

Maxでコンプだったらomx.comp~オブジェクトを使うべきなんでしょうが、あれはどうもあまり好きにはなれません。
多機能すぎるし、何よりもアタックとリリースの調整がいまいちよく分からないので。
(あれ、タイム(ms)じゃなくて効きらしいんですよね。)

多機能すぎるのは処理も無駄に重たくさせてしまいますからね。処理数も多くなるし。
うん、そこが一番嫌。

そんなわけで、別の方法で準備をしてみませた。
ぶっちゃけ、チュートリアルに載っていたことをほぼまんま使っているだけなので、後先問題にならないかビビりものです(笑)。

というわけで、完成具合はこんな感じ。

・心臓部分(simple_st_comp.maxpat)
simple_st_comp.jpg
(載せたところで分かる人にしか???な話ですけども。^^;)

・原音
simple_st_comp-bypass.mp3&autoreplay=1&volume=80" />
(※音量にはご注意を)

・コンプ後(※わざとエグくコンプかけてます。)
simple_st_comp-processed.mp3&autoreplay=1&volume=80" />
(※音量にはご注意を)

うむ、なかなか良い感じじゃ...と、自画自賛しておきます(笑)。

こういうオブジェクトって使いまわしができるように作っていった方が後々ラクだったリするんですよね。
C言語みたく関数化さえしておけば、関数をインクルードしてしまえばその都度一から作る必要も無いわけだし。
(というか、それはプログラムを組む上での常識なんですけどね...。^^;)

そんな感じで最近は共通関数というか、パッチ(疑似オブジェクト)を作ることに力を入れてます。
パーツさえ作ってしまえば、あとは少し修正するぐらいで済むので。

つか、そっちをフリーでダウンロードできるようにしようかな?
まさに「Who does that !?(※誰得だよ!?)」な話ではございますが (笑)。


今回もこのような記事にお付き合いして頂き、本当にありがとうございます。

MAX7 : buffer~を復習する(その4(groove~オブジェクト))

Max(プログラム言語)
07 /10 2015
みなさま、どうもです。
今回もMAX7に関する記事です。

■目標■
「buffer~オブジェクトについて復習をする。」

今回はbuffer~オブジェクトに突っ込んだオーディオファイルを流します。
録音(サンプリング)まで書けたらいいなあ...。
(そんな体力残ってるかな?^^;)

※注意※
基本的なこと(パッチングの手法、メッセージやインスペクターなど)については省略していますのでご注意ください。
(その辺はお手数ですが各自でお調べください。)

音を鳴らすよ。(groove~オブジェクト)

前回、buffer~オブジェクトで領域の確保とオーディオファイルの読み込み方等基本的なことを書きました。

領域を確保してオーディオファイルを読み込んだのはいいけど、再生しないことには意味がない。
ということで、今回は再生することについて書きます。

今回、groove~オブジェクトをメインに書きます。
他にもplay~オブジェクトなるものもありますが、今回はこれについてはふれません。
(単に僕が使いこなせないのと、使い勝手があまり好きじゃないっていうのが理由です。)

今回はこれを基に説明します。
buffer.jpg

まず、
my_buffer.jpg
でmy_bufferという名のバッファー(サイズ:5000ms、チャンネル数:2ch)が確保され、その中にpiano_2.wavが格納されています。

で、再生については、
groove.jpg
が担当しています。

このgroove~オブジェクトの中身ですが、上記の場合だと、
「my_bufferを2chで出力しろ。」となります。

このgroove~オブジェクトですが、数学の公式みたいな感じで書くと下記みたいになります(笑)。
■groove~オブジェクト■
groove~ [バッファー名] [チャンネル数(※指定なければ1ch)]



もちろん、これだけでは何もしてくれませんので、指示(メッセージ)を与える必要があります。
指示については前回のbuffer~オブジェクトと同様にメッセージを送ります。

下記には基本的なメッセージだけ紹介しておきます。

startloop.jpg
再生(ループ再生)開始させるためのメッセージ。
決して、『play』ではないので注意。

stop.jpg
言わずもがな停止するためのメッセージ。

loop_mes.jpg
ループ再生するかどうかを設定するところ。
✕みたいなものはトリガーボタンで、反転状態で0(off状態),1(on状態)が出力されます。
メッセージ自体は下の「loop $1」がループするかどうかを決めます。
「$1」にはトリガーボタンから送られてくる数値が入れられます。C言語でいう引数みたいなものです。

初めからループすることを前提にするのであれば『loop 1』のメッセージボックスのみで大丈夫です。

playspeed.jpg
ここの部分は再生速度を設定するためのメッセージとなります。
今までと違うのはメッセージボックスではなくオブジェクトがメッセージを送るということです。
メッセージボックスだけがメッセージを送るという訳ではないということです。

上の数字の箱(実数)の値がsig~オブジェクトに送られて再生速度を送る仕組みです。

ここで異なるのが出力される形が他のメッセージと異なるということです。
sig~オブジェクトの場合、
signal_line.jpg
がでてますが『シグナル』という音の信号が出力されています。
なお、このシグナルについてはオブジェクトに「~(ティルダ記号)」がついていたらシグナルが出力されると思っておいてください。
(※某書に書かれていることをまんま引用するのであれば「シグナルを受け取ったり出力するオブジェクトは名前の最後にティルダ記号「~」が付いている。」ということです。)

ちなみに、
data_line.jpg
は数値や文字列といったデータが流れています。

しかし、なんでこの部分だけ『シグナル』でやりとりをする仕様にしたのかは謎です。
さすがにそこは僕には分からないので、開発者に聞いてください...ただし、英語で(笑)。

さて、オブジェクトの上にある
inlet.jpg
この部分を『インレット』と呼ぶんですが、インレットの入れる場所によって処理が異なります。
(※ちなみに出口については『アウトレット』と言います。)
真ん中と右(第2インレット、第3インレット)については再生開始位置(※第2インレット)と再生終了位置(※第3インレット)を入力することができます。

例えば、こんな感じ。
start_end.jpg
やっと一番初めの話に戻ってきたような気がしますが、こんな感じで開始位置と終了位置を入力することができます。
あとはwaveform~オブジェ(波形が書かれてるオブジェ)やその下の数値の箱(ナンバーボックス)をいじることで変更することができます。
(やりようによってはランダムで範囲をしてすることもできます。(←後にこれが重要となります。))

蛇足(loadbangについて)

過去の記事や、上の内容ではあえて無視してましたけど、
loadbang.jpg
ってなんやねん?と。
そろそろつっこまれそうなので書きます。

loadbangは「パッチを開いた(読込んだ)時にbangメッセージを送ります」という文字通りのオブジェクトです。
ちなみにbang(bangメッセージ)っていうのは「オブジェクトに何らかの動作のきっかけを与えるメッセージ(※某書の文を引用)」とのことやけど、僕にはこれをうまく説明することができません。
とりあえず『「お前、やれ!」コール(just do it!コール)』を送っているもんだと思ってもらえれば何の支障も出ません...たぶん(笑)。
(ふざけたことを書いてるようで、本当のことだし...。)

まあ、難しく考えずにloadbangオブジェクトはパッチを読込んだ時に設定(初期化)するためのオブジェクトと思ってくれたら問題ないです。

例えば、
buffer.jpg
の場合だと、loadbangの下に「-4.」というメッセージがあって、live.gain~ってところにつながっています。

live.gain~は音量スライダー(音量調整)みたいなものなので、
「パッチを読み込んだ時点で-4dBにしときます。」ということになります。

loadbangで設定しておかなければ、初期状態の0dBのままなので、そのまま再生したときがうるさくて気分が萎えます(笑)。

まあ、そんな感じで初期化させておきたいものに関してはloadbangを使います。


やっぱり、サンプリングまではいけませんでしたね。^^;

自分向けで外のこと(読む人側)は気にしないとか言いつつ、まだ丁寧に書いているような気がします。
正直、書いてるこちら側からすると効率悪いんでもうすこし雑に書いてもいい気がします(笑)。

まあ、そんなことはさておき、次の記事でサンプリングについて書きます。それでは。
(丁寧に書く部分も次で終わりやと思います。(ここで基本が終わるから。))

今回もこのような記事にお付き合いして頂き、本当にありがとうございます。

MAX7 : buffer~を復習する(その3(buffer~_01))

Max(プログラム言語)
07 /03 2015
みなさま、どうもです。
今回もMAX7に関する記事です。

■目標■
「buffer~オブジェクトについて復習をする。」
buffer_01.jpg
※画像をクリックすると拡大写真が見れます。

さて、今回から本格的にbuffer~オブジェクトについて入っていきたいと思います。

※注意※
基本的なこと(パッチングの手法、メッセージやインスペクターなど)については省略していますのでご注意ください。
(その辺はお手数ですが各自でお調べください。)

まずは領域を確保せよ。

前回、「『buffer~オブジェクト』は波形(音声データ)をメモリーに置いて作業を行う。」と書きました。
つまり、『メモリー・ベース』で波形を扱うにはメモリーのどっかにそれ用の領域が必要になるということです。

領域なんて言い方をすると難しく聞こえますが、単純に作業場というか自分の場所を作ってあげるようなものです。
例えば、オフィスの中に自分の作業をするための机(スペース)を置くようなものです。
自分の机がなければ何の作業もできませんからね(笑)。

以下、前回の記事で出したパッチ(↓)で話を進めていきます。。
buffer.jpg

まず初めにこのパッチ内でオーディオファイルを扱うためにメモリーに領域(作業スペース)を確保してやります。
上記のパッチの場合だと、これがそのスペースを確保するための宣言になります。
my_buffer.jpg

buffer~については何度も説明しているから良しとして、じゃあ、その隣の「my_buffer piano_2.wav 5000 2」はなんじゃ?という話になります。

これらはアーギュメントと言いまして、オブジェクトの動作方法を定めたり、初期パラメータを指定するのに用いります。
「my_buffer piano_2.wav 5000 2」は正確には「my_buffer」、「piano_2.wav」、「5000」、「2」に分けられます。

では、「my_buffer」、「piano_2.wav」、「5000」、「2」は何を意味しているかというと、
「my_buffer」:バッファー名(作業スペースの名前) ※バッファー名は必須
「piano_2.wav」:バッファーにあらかじめ置いておく音声データ
「5000」:バッファーのサイズ(ms) ※5000ms = 5秒
「2」:チャンネル数 (2ch = ステレオ ※1ch = モノラル)
※バッファー名以外は必須ではない。
(アーギュメントで指定しなくても問題は無い。(メッセージで設定可能(※後述))
※チャンネル数は宣言しなければ1chで設定される。


以上のことをまとめると以下のとおりになります。
■buffer~オブジェクト■
buffer~ [バッファー名] [あらかじめ読み込むファイル名] [バッファー・サイズ(msec)] [チャンネル数]
※アーギュメントの区切りは半角スペース


まあ、そんな感じで「今からこの領域使わせてもらうかんね。」と宣言します。

別に初めから全てを設定しなくてもいい。

上では最初の内にある程度設定をした状態で準備をしましたが、絶対にここまでやらなくてはいけないということもないです。
というか、扱っているうちに「あ、音声ファイル変えよっと。」とか「サンプリングしなおそう。(※これは後日説明)」とかいうこともありますし。
そうなると、バッファーサイズが変わったりもしますからね。

そういう場合、buffer~オブジェクトの場合ならこんな感じメッセージ・ボックスに書かれたメッセージを送って指示を与えます。
message.jpg
『read』『clear』『replace』など書かれているものがメッセージになります。
メッセージはボタンみたいなもので、このメッセージボックスをクリックすることで表記されているメッセージがオブジェクトに送信されます。
例えば、『read』のメッセージを押すとオーディオファイルを開くダイアログが表示されるし、『clear』を押すとバッファー内の音声データがいったん消されたりと...まあいろいろ。
(その辺はf1を押してリファレンスを読みましょう(笑)。)

ちなみにメッセージボックスはクリックするだけじゃなくてbangというメッセージでもメッセージを送信することはできるけど...そういうことはここでは書きません。
まあ、そういうこともできるということだけ知っといてください。機会があれば後日書きます。

とにかく、何でもかんでも一番初め(buffer~オブジェクト内)に宣言しなくても問題ないということです。
正直、バッファー名とチャンネル数を除いては後からでも設定できるので、その辺は使用目的に応じて臨機応変に宣言しましょう。
(※バッファー名もメッセージで変更することもできるようです。→『set』)

バッファーの中身は?

バッファーにオーディオファイルを読み込むのはいいけど、中身はどうなっているの?それって見れないの?

いえいえ、ちゃんと見れますよ。

方法は2つありまして、
1.『buffer~オブジェクト』をダブルクリックする。
2.『waveform~オブジェクト』に波形を描画させる。
の方法で中身を見ることができます。
(このほかにも手段はあると思いますが、とりあえず今はこれだけでいいっしょ。)

1.の方法はただバッファーの中身を見るだけ。
2.はバッファーの中身を描画させて、そこからいろいろな情報を抜き出すことができるのでメインはこちらになります。

2.の方法は下記のような感じで描画可能です。
waveform.jpg
『set my_buffer』と書かれたメッセージ・ボックスによってwaveform~オブジェクトにバッファーの中身が描画されます。
この『weveform~オブジェクト』には波形だけではなくその波形の情報(「長さ」など)も含まれてますのでそこからいろんなデータを持ってきて次の処理につなげることができます。

例えば、こんな感じ。
waveform_2.jpg
この場合、『waveform~オブジェクト』から再生範囲(とりあえず頭から最後まで)の長さを取得して『groove~オブジェ』で再生する流れになってます。
(見た目の問題上、一部処理を省略していますが...。^^;)

とりあえず、今回はここまで。
次回は『buffer~オブジェクト』が何をしているのかを書きます。

今回もこのような記事にお付き合いして頂き、本当にありがとうございます。

MAX7 : buffer~を復習する(その2(sfplay~とbuffer~))

Max(プログラム言語)
06 /19 2015
みなさま、どうもです。
今回もMAX7に関する記事です。

■目標■
「buffer~オブジェクトについて復習をする。」

前回、buffer~オブジェクトについて復習をするために、簡単なサンプラー、
buffer_01.jpg
※画像をクリックすると拡大写真が見れます。
を作ると言いましたが、そこに入る前にもう一つ前置きを書いておこうかと思います。

サンプリング(録音)&プレイバック(再生)を行う2つの処理
前回、「『メモリー・ベース』のサンプラーがどーたらこーたら...」みたいな話をしていたと思うんですけど、いわゆるサンプラーってやつは『メモリー・ベース』と『ディスク・ベース』の2種類に分かれるんですね。
そのことについては後ほど語るとして、まあサンプラーってやつはそういうものなんだと今は思っておいてください。
(今は『サンプラー』=『ただのオーディオ・プレイヤー』とでも思っておいてください。)

で、Maxでも『メモリー・ベース』のサンプラー、『ディスク・ベース』のサンプラーを作ることができます。

今回はサンプリング(録音)は抜きで、再生することだけに絞って説明しますが、MAXでプログラミングすると下図のようになります。
sfplay.jpg  buffer.jpg
見た目は少し異なりますが、これらのパッチができることはほぼ一緒です。
ただ、厳密に言うと多少異なります(例えば右のパッチだと、パッチを読み込んだ時点で音が鳴るとか)が、そういうところは今は重要ではないので無視してください(笑)。
(それを言い始めると話が進まなくなるので。^^;)

まず、左側のパッチ、
sfplay.jpg
ですが、こっちは『ディスク・ベース』でオーディオファイル(piano.wav)を再生しています。
『ディスク・ベース』なんて言っちゃうと難しく聞こえるかもしれませんが、単純にハードディスクのオーディオファイルを直接読み込んで再生しているだけです。
考えようによっては「ん?」って思うかもしれないですけど、ごく普通にシンプルなことをしているだけです。

ここで肝となるのが、
obj_sfplay.jpg
というオブジェクト(C言語でいうところの『関数』)です。

細かいこと(オブジェクトが云々)については今は書きませんが、sfplay~オブジェクトによって、
「ハードディスクから直接オーディオファイルを読み込んでいるんだなあ。」
ということだけ頭に置いといてください(笑)。

ちなみに上記の場合だと、「ディスクからpiano.wavを読込んで2chで再生」するになります。
※ここで言う「2ch」とはステレオ(L/R)のことです。

次に、右側のパッチ、
buffer.jpg
では『メモリー・ベース』でオーディオファイル(piano_2.wav)を再生しています。
「なんのこっちゃ?」ですが、要するにディスクから読み込んだオーディオファイルをメモリーに置いてから再生をします。
直接再生する『ディスク・ベース』と比べると「なんでそんな手間なことを...」と思いますが、ここがポイントで重要なのです。

こちらの場合、
obj_buffer.jpg
という2つのオブジェクトが肝になります。

これについても今は詳細を書きませんが、
「読込んだオーディオファイルをわざわざメモリーに置いている。」
ということだけ頭に置いといてください。

ちなみにわざわざを漢字で書くと『態々』になります。
知っていると意外とドヤ顔ができますので覚えといても損ではないです...あ、どうでもいい?(笑)

閑話休題、これも簡単に説明しておくと
①buffer~:メモリーに「my_buffer」という2ch、5000ms(5秒)分の領域を確保し、ディスクから読み込んだpiano_2.wavをその領域に置く。
(物置部屋に「マイ・スペース」をおいて、そこに物を置くような感じです。)
②groove~:「my_buffer」に置いたpiano_2.wavを再生する。
という意味になります。
余談ですが、単に再生するだけであればgroove~以外にもplay~というオブジェクトありますが、今回はgroove~のみで進めます。
(ぶっちゃけた話、play~はあまりよく分かってません(笑)。)

さて、もう一度書きますが、上記のパッチ程度だとほぼ同じことができます。
「じゃあ、なんで『ディスク』と『メモリー』と別個の処理があるんじゃい!?」という疑問もでてきますが、これにはちゃんと理にかなった理由があるんですよ。

「メモリー・ベース」と「ディスク・ベース」(※超アバウトに)
『buffer~オブジェクト』は波形(音声データ)をメモリーに置いて作業を行う。
『sfplay~オブジェクト』は波形があるディスク(ハードディスク)の場所から直接作業を行う。
置く場所(作業場所)は違えど、やっていることはほぼ一緒。

...なんで、メモリーとハードディスクと分けた処理があるのか?

これについては『サンプラー』というものを理解する必要があるんですけど...正直、真面目に説明するとしんどいし、読む側も疲れるので大雑把に説明します。
(ぶっちゃけ、そこまで詳しくないので書けない。)
まあ、詳しく知りたい方はwkipedia辺りをご覧くださいな(笑)。

以下、大雑把に説明しますので「ここ、厳密にはちがうぞ、バカヤロー!」とかいうのは無しでお願いします。^^;

さて、ここではサンプラーの始祖ともいわれるメロトロンについては置いといて、よく言われるサンプラーについて書きますね。
まあ、こういうサンプラーの話ね。(↓AKAI S3000XL)
S3000XL_L.jpg

サンプラーの仕組みって、何気にパソコンに似てるんですよね。
パソコンってデータそのものはHDD、作業領域はメモリー、処理はCPUで...とそれにものすごく近いんですよ。

HDDにある波形をメモリーに持って行ってそこをベースに音声加工やら再生などの作業をする...まあ、これがいわゆる『メモリー・ベース』ってやつなんですけども。
目的が違うだけで、やっていることはパソコンと大して変わらないというね。

でも、サンプラーが生まれた頃なんて、今と比べると全然容量がありません。
その頃はHDDの容量も少なかったし、非常に高価だったらかHDDなんか設置してられなかったわけですよ。
代わりになるフロッピーやらZipディスクもデータの転送速度も遅かったからリアルタイム処理には全く適さないわけで...。
(言っても、HDDも処理速度や転送速度は遅いですからね。)

だからアクセス・スピードが非常に早いメモリーに一時的に波形をおいて作業をするしかなかったわけですよ。
まあ、メモリーの容量も今とは桁違いに容量少なかったわけで、初めの頃なんて1、2秒しかサンプリングできなかったそうで...。
(上のS3000XLにデフォルトのスペック(2MB)だと44.1KHzでステレオ10.4秒、モノラル20.8秒ですからね。)

おまけにメモリーチップもアホみたいに高価だったららしいです...リアル世代ではないのであまり実感ないですけど(笑)。

ところがどっこい、PCの高性能化によって楽器をPC上の上でも走らせることが可能になります。
いわゆる「ソフトウェアシンセ」の誕生という奴ですな。
もちろん、サンプラーも同様にソフトウェア化されるわけですよ。ほら、御宅が使ってる『Battery』やら『KONTAKT』のことでっせ。

正直、ハードウェア・シンセ/サンプラーなんてPCのスペックと比べたら雲泥の差(※失礼)ですからね。
ハードウェアサンプラーだと技術的やらコスト的なところでクオリティに限界がくるわけですよ。
だったら、「ソフトウェアの方が良いだろうよ?」と。
(「そのきれい過ぎない音がええんやんけ!」とかいう意見は今は置いといてね。)

となると、人って欲深いもので「だったらよりリアリティーな音を出したい」っていう欲が出てくるわけですよ。
うん、人ってわがまま!(笑)

「大容量の波形を求めるのはええけどやあ、そんな大容量なデータをどこで作業さすねん?メモリーでやったら一瞬で「ポンッ!」でっせ。」という話ですよ。
人間かてキャパ越えしたら壊れますからね。まあそれに近い感覚ですよ...え、それは違う?^^;

そんなこんなでどっかの技術者が頑張ったおかげでハードディスクから高速に大容量のデータ(GB越え)をロードする技術を完成させました。
知っている人には知っている『GigaSampler』ですね...僕は使ったことないですけど。(高かったし(笑)。)

この頃には既に...というか現在進行刑ですけども、昔に比べたら大容量のハードディスクなんて安価で手に入りますからね。
(下手したらメモリーよりも安い場合もあるし。)
おまけにハードディスクストリーミング機能まで充実してきたから「無理してメモリーを使う必要ねえじゃん」となり、ここから『ディスク・ベース』になっていくわけですよ。

だからと言って、『ディスク・ベース』が普及して大団円になったか?というと、そういう訳でもないんですね。
決して『ディスク・ベース』が完璧という訳でもないのです。

例えば、「「ハードディスク」は「メモリー」よりも早いか?」って言われるとそうでもなく、やっぱり「メモリー」の方が断然早いんですね。
(なんというか、これは「「HDD」と「SDD」どっちの方が早いか?」と問われるのにものすごく近い話で(笑)。)

おまけに何も考えずに大容量サンプルを使いまくってたらすぐにPCが重たくなりますからね。
鳴らすだけなら全然問題なくても、リアルタイムで加工をするとやっぱりどんだけ良いCPUやらメモリを積んでてもすぐにフリーズしちゃいます。

こういう時の「このダメPCめ!」の発言はお門違いなわけで、それは単に使っている人間がPCに対して「鬼畜の所業」をしているに過ぎないのです(笑)。


さて、長ったらしい話もそろそろまとめに入りましょう。

メモリー、ハードディスクのメリット、デメリットを考えると、
メモリー・ベース:扱える容量は多くないが、アクセススピードが速い。容量内だったら処理が重たくならないのでリアルタイム処理に適している。
ディスク・ベース:扱える容量は多いが、アクセススピードが遅かかったり、処理が重たくなる等でリアルタイム処理にはあまり適していない。

ということになります。

なので、「メモリーとディスク...どっちが優れているか?」とかいう話ではないのです。
その辺は目的やら用途で変わってくるから、結局のところ、「使う側次第です。」ということになります。

リアルタイムに録音して編集しながらパフォーマンスしたいなら『メモリー・ベース』の方が有利だし、あらかじめ用意した音声やらどでかい容量の音声を扱い、加工を目的とするのであれば『ディスク・ベース』の方がはるかに有利だったりするわけで、結局は「何をする(したい)か?」で見分けなければいけないという訳ですね。

という感じで、今回はこの辺までにして、次回はbuffer~オブジェクトの詳細に入っていきたいと思います。

今回もこのような記事にお付き合いして頂き、本当にありがとうございます。

MAX7 : buffer~を復習する(その1(前置き))

Max(プログラム言語)
06 /14 2015
みなさま、どうもです。
今回はMAX7に関する記事です。

まあ、初めなので今回だけ少し『Max』そのものについて触れたいと思います。

まず『Max』ってなんやねん?っていう話ですが、細かい話は抜きにして、簡単に言うと音楽や映像などのためのビジュアルプログラミング言語です。
詳しく知りたい方はWikipediaもしくはこちらをご覧ください。

さて、『プログラミング言語』なんて言うと、
#include <stdio.h>
int main(void)
{
   printf("hello world!");  //hello world!を出力
   return 0;
}
※C言語でおなじみのhello worldを出力するプログラム

みたいなイメージが出てきますが、こんなC言語やらJavaみたいなテキストでプログラミングを行うものではありません。

『Max』の場合、オブジェクト(C言語等でいうところの関数)という箱みたいなものを線でつないでプログラミングをしていきます。
言っちゃえば今流行のモジュラーシンセをパッチングするのに近い感じですよね。(下記の図)
patch.jpg
これは440Hzのサイン波と396Hzのサイン波の音を流すだけのパッチです。
(注:Maxでは完成したプログラムを「パッチ(もしくは、パッチャー)」といいます。)

「これをC言語で同じように表現しろ」なんて言われると馬鹿みたいに勉強しないといけませんからね。
少なくとも僕にはそんなものC言語で書けないし、ぶっちゃけ、上のソースコードを見てるだけでも気分が悪くなりますからね(笑)。
(※SE時代のトラウマによるものです(笑)。)

まあ、そんな感じでMaxを用いることで音楽や映像のことについては適当につなぐだけでそれなりの物が簡単に作ることができます。
(もちろんちゃんとしたものを作ろうと思うとそれなりに知識は要りますよ。)

...て、そんなこと書いていますけど、「お前、Maxのこと詳しいのか?」と言われると「いや、全然」って即答できます。
だって、触ってても使ってるところ(使う目的)が限定されてるますから。
なので、実際は分からないことだらけ。

そんなわけで、勉強がてらに分からないなりに自分の試したことをまとめてみようかな?と思います。
ほら、自分が理解したことを人に理解してもらえるようにまとめるってかなり勉強になりますから(笑)。

ぶっちゃけ、毎日Maxを使っているわけじゃないから一定期間が間が空いてしまうと忘れてしまうわけなんですね。
そんなときのためにいつ見ても「ああ、そういうことね」と思いだせるものを残したいっていうのが本音なんですけども。^^;

ほぼ自分のために書いているようなものですが、参考になれば幸いです。


■目標■
「buffer~オブジェクトについて復習をする。」

buffer~: オーディオ・サンプルをメモリーに格納する

うん、意味わからないですね。
C言語的に言うと音声を(PCの)メモリーに格納するための領域を確保し管理するっていうことなんですけども...どういうこっちゃ。

というわけで、今回、buffer~オブジェクトを復習するために作成したパッチはこちら。
buffer_01.jpg
※画像をクリックすると拡大写真が見れます。

何をやっているかというと、外部からの音もしくはオーディオファイルをメモリーにおいて音をならす処理をしています。
いわゆる『メモリー・ベース』のシンプルなソフトサンプラーです。
サンプラーなんて言っちゃうと本格的なパッチに思えますが、本当に勉強するためだけのお試しパッチです(笑)。

...と、今回はここまでにして、各処理の詳細については次回に書くことにします。
詳細っていってもそんなにガチガチには書かないので変な期待はしないでくださいね。^^;

前置きが長くなりすぎてちょっと疲れました(笑)。

今回もこのような記事にお付き合いして頂き、本当にありがとうございます。

top