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