目次
創作物のデータをいい感じに管理する
こんにちは
この記事は、創作活動をする人や見る人を歓迎するMisskeyインスタンス「Misskey.art」における Advent Calendar 企画「Misskey.art #2 Advent Calendar 2024」の4日目の記事です。
Yokkin (@[email protected])です。音楽(DTM)とプログラミングをやってます。
どんな曲を作ってるのかな?と思った方がいらっしゃいましたら、こちらをどうぞお聴きになってください。Skebで作った曲のプレイリストです。
今回の記事では、創作物のプロジェクトデータをフォルダだけ使って管理するいい感じの方法を、筆者の例を紹介しつつ提案したいと思います。この方法は、スプレッドシートや外部ツールを一切使用しないのが特徴です。DTMで音楽を作っている&趣味でやってるくらいの読者の方は9割しっくりくる方法かと思いますが、それ以外でも応用が利く方法でもあると思います。また、これからDTMを始める人はこの上なく✝完璧なスタート✝を決められます。
最終的には、紹介される方法を用いてこんな感じの作品の集合を表現することが目標です。
それでは始めていきましょう!
免責事項
正直、自分のワークフローくらい持ってるよ!って人もいるかもしれません。この記事は、筆者の手の内を明かすことにより発生する結果を必ずしも期待して執筆されたものではないということを先に表明しておきます。また、この方法を用いたことによる結果について筆者は責任を負えません。すみません。
なぜ構造化するのか?
この記事では、「構造化」を一つ一つの創作物の形式を決め、それらの状態や用途などの属性にしたがって分類し、その分類方法に基づき創作物の集合を作っていくことと定義します。
さて、なぜ創作物のデータを構造化する理由があるのでしょうか?「データの構造化」を行わないことで発生する2つのデメリットを考えることで、この動機を探ってみましょう。
データは見つけづらい
データは見つけづらいです。デジタル形式のデータは、実際に画像を開いたり、音声ファイルを開いたりして、人間が知覚することによって初めてそのデータがどんなものなのかわかります。人間は優れた視覚を持っているので、絵やCG、動画などはサムネイルのような機能を使ってすぐに特定することもできますが、音楽に関しては別です。
また、適当に名前を付けてしまって、あとでファイルを検索して苦労した経験をお持ちの読者の方も多いと思います。確かにデータは見つけづらいですが、裏を返せば、同時に理にかなう名前を付ければ何とかなるということも示唆します。
バラバラのデータは意味を表現できない
秩序なくして保存されたデータが単純に管理しづらそうなことは誰の目に見てもわかります。ところで、バラバラなデータは意味を表現できないという問題点もあります。
データは関連するほかのデータと結び付けたり、実際のできごとや状態を、特定の名前(たとえばファイル名やフォルダ名)や構造に結び付けたりすると、ある意味を表現できます。
たとえば、以下の図にあるような、20241117 aaa.wav
のようなファイルは、それ単体では音声ファイル以外の意味を持ちません。ところが、他のファイルと一緒に、「作品A」というフォルダにまとめると、作品Aとしての意味を持つようになります。
さらに、作品Aというフォルダは「作品A」としての意味しか持ちませんが、作品Aに「クライアントAに提出する」という作品の目的地要素が加わると、さらに作品Aの意味合いは変わってくるでしょう。
時にして、データの「流れ」を表現したい場合もあります。その際は、既存の構造を拡張することで、さらに新たな意味を表現できます。しかし、結局、データをバラバラに管理していては、この潜在的な可能性は期待されないのです。
このような理由で、創作物のデータを構造化することには意味があると考えられます。では、どのように構造化すればよいのでしょうか。
構造化の手順
突然ですが、この記事で紹介する構造化は以下の手順で行います!
- 自分の作品がどのような具体的要素(ファイル・フォルダ)から構成されているかを分析する。…①
- 作品一つにフォルダを相当させ、その中の構造を決める
- その作品の状態と行き先に注目し、それも分類方法に加える。…②
- 分類方法の枠組みを決め、フォルダに分類する
- (実際に分類する)
本節では、これらの①、②について解説を行います。
①作品を構成する具体的要素
まずは、自分の作品1つがどのようなファイルから構成されているかを分析します。ある作品を作るために用いた各ファイルは作品を構成する「具体的要素」です。以下の箇条書きは要素とファイルの対応の例で、作品は様々な要素(≒ファイル)から成り立っていることを示します。
- 作品のモチーフ、着想、きっかけ
- →画像や写真ファイル?
- →依頼内容のコピー、詞などの文書ファイル?
- 具体
- →制作ソフトウェアが読み書きするプロジェクトファイル?
- プロジェクトを制作するのに用いた素材
- →音声ファイル、動画用の素材?
- 完成品
- →画像、音声、動画ファイルなど?
これらは同じフォルダにまとめましょう。
プロジェクト毎にフォルダ作成・まとめる
筆者の一つ一つのプロジェクトの構成は、おおむね以下のような構成になっています。後ろに/
がついているのが、フォルダを表しています。それでは、要素を一つずつ見ていきましょう。
- 20241117 frutiger house/
- Audio/
- a.wav
- b.wav
- Samples/
- kick.wav
- sfx.wav
- Backup/
- 20241117 frutiger house_*.flp
- readme.txt
- 20241117 frutiger house.flp (ソフトのプロジェクトファイル)
- 20241117 frutiger house.wav
- 20241117 frutiger house.mp3
まずは、プロジェクトごとに一つフォルダを作り、名前をつけています。
- 20241117 frutiger house/
- 20241112 kawaii/
名前は大事です。まずは日付から始め、次に自分で「この曲だ!」と特定できる名前をつけます。名前は、曲名でもいいですし、メモ程度に使ってもよいでしょう。
日付の形式については、2000-01-01
や20000101
のように日付を0で埋めると、名前順で並べ替えても1 → 10 → 11 → 2 → 3 → 4 → 5 → 6 → 7 → 8 → 9
のような順序で並ばずに、正しく日付順に並ぶようになります。作品に関連する要素は、このフォルダの中へ格納していきます。
- readme.txt
このテキストファイルには、作品のモチーフ、着想、きっかけや歌詞などを書いています。Skebのリクエストなら、内容をここにコピーアンドペーストしています。
- Audio/
- a.wav
- b.wav
- Samples/
- kick.wav
- sfx.wav
Audio/
や、Samples/
は、一曲を作るのに使用したサンプル(音声ファイル)が格納されるフォルダを表しています。音楽を作るときは、たくさんのドラムやパーカッションを、サンプルがたくさん入ったライブラリから使用します(下記画像)。製作ソフト側で、プロジェクトで必要になったサンプルはこのライブラリからコピーされ、Audio/
や、Samples/
フォルダに入っていくように設定しています。
サンプルをプロジェクト毎に持っておけば、もしオリジナルのサンプルがたくさん入ったライブラリをどこかで紛失しても大丈夫です!これによって、将来的にリテイクや今後の作り直し、修正などが発生しても、同じプロジェクトを再現できる確率を高められます。
- Backup/
- 20241117 frutiger house_*.flp
Backup/
は、プロジェクトファイルの数分おきくらいのコピーが入っています。Ctrl+Z
(元に戻す)機能で元に戻せなくなるくらい作業しても、ソフトがクラッシュしても、いつでもここから元に戻せるのでいくらヘマしても、忍耐力さえあれば無限に復活できますね。
- 20241117 frutiger house.wav
- 20241117 frutiger house.mp3
忘れてはならないのは、頻繁にプロジェクトを簡単に開ける形式にエクスポートしておくことです。製作途中でも出先でも、実際にプロジェクトの中身がどんな感じだったか確認できるように、その日の作業を終えるときは必ず.wavファイルと.mp3ファイルにエクスポートしています。
作品を構成する要素でまとめよう
ここまで実際に、あるプロジェクトにおけるフォルダ構成を紹介してきました。この作品を作るごとに一つフォルダを作って整理すると、プロジェクトに必要な要素の関連性を表現できるだけでなく、将来的にも役立つことがたくさんあるかと思われます。
②作品の状態と行き先
さて、ここまで単一の創作物をどう管理するかを議論しましたが、今度はその集合を、それぞれの作品の「状態」と「行き先」をベースにフォルダ管理するのはどうかという提案をします。
それぞれの作品の状態をベースにフォルダ管理
たとえば、作品は大抵の場合3つの状態に大別できます。
- 制作中
- 没
- 実質的な制作終了
- たまにこの中から引っ張って制作中に復帰する作品もある
- 制作終了
- 晴れの舞台に行った作品
作品は全て「制作中」から生まれ、大半は「没」になります。しかし、中には作品集にして販売したり、合作などで提出したり、納品したりすることによって晴れの舞台=無事公開にまでたどり着く作品もあります。こうしたものは「制作終了」として分類します。これは筆者の例ですが、こんな感じに分類しています。
projects/
- abandoned/
- finished/
- wip/
ここでは、「没」の作品をabandoned/
に、「制作終了」をfinished/
に、「制作中」をwip/
に分類しています。
必要な場合はさらに小分類
さらに、没フォルダであるabandoned/
と制作終了フォルダfinished/
の下にさらなる小分類を行うと、abandoned/
の中身が増えすぎる問題や、finished/
におけるプロジェクトファイルが何のために作った作品なのかわからない問題を解決できます。整理例は以下です。
projects/
- abandoned/
- 2023/
- 20230101 xxxxxxxx/
- 2024/
- 20240214 xxxxxxxx/
- finished/
- skeb-aさん/
- 20220316 xxxxxxxx/
- コンピアルバム「涅槃」/
- 20210409 xxxxxxxx/
- アルバムB/
- 20210628 xxxxxxxx/
- wip/
- 20241117 fruitiger house/
まず、abandoned/フォルダの中身は大量なので、年別に整理してます。
- abandoned/
- 2023/
- 20230101 xxxxxxxx/
- 2024/
- 20240214 xxxxxxxx/
finished/
には、作品の行き先をフォルダ名にして、プロジェクトのフォルダを格納しています。これでひと目見て何の作品かわかります。
- finished/
- skeb-aさん/
- 20220316 xxxxxxxx/
- コンピアルバム「涅槃」/
- 20210409 xxxxxxxx/
- アルバムB/
- 20210628 xxxxxxxx/
作品の状態や行き先でまとめよう
このようにして、まず「作品の状態」を決め、滞りなく作品が完成した場合を考え「作品の行き先」という基準でプロジェクトを分類すると、作品の流れをフォルダだけの構造だけで表現できます!
質問コーナー
以下を想定質問コーナーとします。
他所に提出して、既にfinished/他所A/作品
に配置した作品を、自分の作品集に再度収録したい場合は、どこに置けばよいの?
→finished/
の下にフォルダ自分の作品集
を作ってそこにfinished/他所A/作品
の中身をコピーする。再版が既存の版と全く同じでも異なっている場合でも、別々なプロジェクトとして扱えば気にせず編集できる。そうでなくとも、管理を単純化できる。
まとめ
ここまで、①作品一つにフォルダを相当させ、作品の具体的要素に基づき構造を決め、②その作品の状態と行き先に注目し、分類方法の枠組みを決め、適宜フォルダに分類する手順を見てきました。
本記事では、外部のツールを使用することなく、適切にフォルダの分類基準を決めると、作品のフォルダ(たとえば20241117 frutiger house/
)を任意の場所に動かすだけで、作品を分類できるということを示しました。筆者はこの作品の運用方法を5年以上採用していますが、未だに綻びが生じず運用できており、今回そのまま紹介することができた形になります。今回この記事を読んでよいなと思った方は、ぜひおすすめしたいと思います!
書いた後で今回は当たり前のことを書いてしまったような気もしますが、しっかり記事という形で普段の習慣を整理できたことは、自分にとってもよかったかなと思います。
ここまでお読みいただきありがとうございました。寒い季節になるのでみなさまご自愛ください。それでは!
コメント
コメントはありません。