hi all
i had encountered some issues with the object class [writesf~] in the
modes -batch and -nogui.
i was told by dmotd in #dataflow this might be related to setting the
samplerate for certain samplerate dependent object is not happening at
the correct time in -nogui mode. i found two work workarounds to
overcome this (basically they do the same):
* sending a message to the patch using the -send flag: -send "pd dsp 1"
* using [loadbang]-[delay 1]-[dsp 1(-[s pd] instead of using a plain
[loadbang] for turning dsp on.
now it seems, that this doesn't work in -batch mode, since the [delay]
triggers the 'dsp on' only logically delayed, but not effectively (this
is at least my interpretation of what is going on). it also seems, that
[writesf~] wants the 'dsp 1' message to come not only logically later,
but _really_ later. otherwise it creates just an empty file with 0 byte
size (the resulting soundfile doesn't even contain the heaser).
i figured out, that using -send "pd dsp 1" helps, and finally enables
[writesf~] to write correct soundfiles in -batch mode.
also i noticed, that messages to [writesf~] need to be sent _after_
turning dsp on. which means, that you have to use a [delay 0] when
wanting to start [writesf~] on loadbang.
Before writing a bug report, i would like to discuss the issue here in
order to not write some bogus bug report:
* is my interpretation of things correct?
* what other object classes might be affected as well, if any?
is there some easier way to make a patch work in -batch mode than having
to edit it and put a [delay 0] after every [loadbang]?
for testing purposes i attached a test patch.
cheerio
roman