Alex Weiss wrote:

> As I work on the sounds I obviously keep making changes to
> the .csd files to generate multiple versions. However, no matter how hard I
> try that always leads to chaos in the end: I come back weeks (or even
> months) later, find a couple of great wave files with synthesized sounds
> together with .csd, but can't figure out which .csd file corresponds to
> which wave file,

A revision control system and careful attention to file naming might
go a long way to solve this problem.

> After much thought, I think I found a potential solution to the problem.
> What if, upon rendering, a host embedded the csd as a chunk in the
> resulting .wav? That way every sound would carry its own code within
> itself, putting an end to the chaos.

That would work.

> I understand that creating custom
> chunks in a .wav is non-standard and should be avoided,

Most of the big DAW manufacturers ignore this rule. I don't see why the
Csound community should not also ignore it.

Furthermore the libsndfile on github already has recently acquired an API
to add custom chunks to file formats that support it.

Cheers,
Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

On 25/02/2012 09:17, Erik de Castro Lopo wrote:
> Alex Weiss wrote:
>
>> As I work on the sounds I obviously keep making changes to
>> the .csd files to generate multiple versions. However, no matter how hard I
>> try that always leads to chaos in the end: I come back weeks (or even
>> months) later, find a couple of great wave files with synthesized sounds
>> together with .csd, but can't figure out which .csd file corresponds to
>> which wave file,
>
> A revision control system and careful attention to file naming might
> go a long way to solve this problem.
>


I agree with this. Assuming the csd file is fully deterministic (no 
random elements which would generate different outputs each run), it 
fully describes (and in effect is a fully reliable alternative to) the 
soundfile itself. The rcs system would preserve incremental changes to 
the csd file, and could well be a more efficient solution than 
preserving  a large number of soundfiles.

If the work is being done at the command line, it would be possible to 
use a makefile or shell script to manage rendering, e.g. automatically 
updating a logfile of each csd invocation with a date stamp and whatever 
other idents such as soundfile names were needed - it may be able to 
automate the creation of soundfile names themselves, e.g. with version 
numbers from the rcs.

>> After much thought, I think I found a potential solution to the problem.
>> What if, upon rendering, a host embedded the csd as a chunk in the
>> resulting .wav? That way every sound would carry its own code within
>> itself, putting an end to the chaos.
>
> That would work.
>
>> I understand that creating custom
>> chunks in a .wav is non-standard and should be avoided,
>
> Most of the big DAW manufacturers ignore this rule. I don't see why the
> Csound community should not also ignore it.
>

Of course using WAVEX the problem is expressly obviated, as anyone can 
define a custom chunk with an unique custom GUID (which is how PVOCEX 
and AMB are defined, for example). There are already established chunks 
in WAVE for production metadata, not least the Broadcast WAVE extension. 
The only issue in embedding a csd file in the soundfile header (apart 
from the possibly large "padding" of the header before the data, and of 
course the custom software to do it) is how to read it. Ostensibly you 
need tools that can extract the csd chunk and display it properly 
formatted etc. It implies that people will want to "open" such a 
soundfile in WinXound, say, as if it was  a plain csd file. Arguably a 
csd file once written to a header should be regarded as read-only as any 
change is likely to "invalidate" the soundfile. My fear is that this 
could become an unwieldy and cumbersome solution quite quickly.

> Furthermore the libsndfile on github already has recently acquired an API
> to add custom chunks to file formats that support it.
>

If that implies the possibility to put together separate utilities to 
read/write verbose chunk contents, that would fit the command line 
script or makefile approach very nicely. Although post hoc editing of 
header chunks carries its own set of issues.

Richard Dobson

Alternatively, you could write a small Python program to start your csd, and
store the date/time, csd name, csd location, the rendered wave file name,
location, etc into a database...

Richard

--
View this message in context: http://csound.1045644.n5.nabble.com/Workflow-question-and-a-proposal-tp5514766p5514994.html
Sent from the Csound - General mailing list archive at Nabble.com.

First your problem is a real problem and an important problem, as will
become increasingly evident to distraught scholars of the future, if
they need to pay any attention to what we are doing.

I use Csound exclusively to make entire pieces, not samples to use in
pieces. That said, I make a LOT of pieces and they don't have easy
names. I have solved my version of your problem thusly:

Csound is always a component in another program, which is the actual
composition. This is either a Lua script or a C++ program.

The composition receives command line arguments, or it may have an
explicit title variable. The first command line parameter (argv[0])
is the name of the program. The basename of the program (or the
explicit title variable) becomes the title of the piece. All other
files involved in the composition are named off this: title.orc,
title.sco, title.wav, title.norm.wav, title.mid, title.xml, title.mp3,
etc.

I try to keep each and every part of the piece in one single file, the
composition source code. If I had no way to avoid using large chunks
of data for my piece, as you must do, then I would use a version
control system or a database and the composition program would know
how to get its materials out of this store, again keyed off the title
of the piece. A strictly maintained convention for pathnames for plain
directories (one dir per piece, title/wav, title/mid,
title/samples/sample1, etc., or as Tito suggests) would also work.

Hope this helps,
Mike

On Sat, Feb 25, 2012 at 2:57 AM, Alex Weiss  wrote:
> Hi csounders
>
> I have a general workflow question for all of you as well as a proposal for
> a potential solution to one of my workflow problems. I often use csound to
> generate individual sounds instead of entire pieces (which, as I understand,
> is how many users use csound). Consequently, I either have one .csd per
> sound or at least one instr for it (with similar instrs grouped into one
> .csd). As I work on the sounds I obviously keep making changes to the .csd
> files to generate multiple versions. However, no matter how hard I try that
> always leads to chaos in the end: I come back weeks (or even months) later,
> find a couple of great wave files with synthesized sounds together with
> .csd, but can't figure out which .csd file corresponds to which wave file,
> or which parameters I used to generate them. I tried various filename
> schemes as well as orchestra commenting schemes, but all to no avail. Has
> anybody else experienced this problem? What are your workflows? I'm curious
> to hear how other people deal with this, or if I'm the only one...
>
> After much thought, I think I found a potential solution to the problem.
> What if, upon rendering, a host embedded the csd as a chunk in the resulting
> .wav? That way every sound would carry its own code within itself, putting
> an end to the chaos. I understand that creating custom chunks in a .wav is
> non-standard and should be avoided, but from what I know almost all
> players/DAWs/etc simply skip chunks they don't understand, so the file would
> play back perfectly fine. The only problem would be making changes to the
> file, as most applications will probably overwrite the header upon writing
> to disk. But at least it's something... Any opinions?
>
> Thanks,
> Alex



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

> After much thought, I think I found a potential solution to the problem. What if, upon rendering, a host embedded the csd as a chunk

foo.csd makes foo.wav.  If you make a copy, foo2.csd makes foo2.wav.
Why add a chunk to the .wav file when you can use the file name to
express the relationship?

2012/2/25 Alex Weiss :
> What if, upon rendering, a host embedded the csd as a chunk in the resulting
> .wav?

I think this is a brilliant idea. And it might make sense to do it by
default, so that I might recapture the csd later even if I was not
awake enough to save it with the sound file at the time of
rendering/experimentation.

-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp