[PD] -batch option

[Oliver Larkin]

Thanks I will try recording to a table. The purpose of this eventually is
to use sigmund~ to batch analyse audio files so I need the standard DSP
chain to work

On Monday, May 12, 2014, Lorenzo Sutton <lorenzofsutton at gmail.com> wrote:

> On 12/05/2014 13:48, Roman Haefeli wrote:
>
>> Hi Oli
>>
>> The problem is not that [delay] quantizes messages on block boundaries,
>> but [writesf~] does so ([delay] is totally precise). If you want exactly
>> 1s wav files, you need to replace [writesf~]. You could create a table
>> with the desired length and use [tabwrite~]  to record to that table.
>> Then you could send a 'write' message to [soundfiler] to export table
>> content to a wav file. The resulting wav file should have the exact
>> length of the table (I haven't tested that, though).
>>
>
> Furthermore... Are you really interested in capturing output from e.g.
> [phasor~] as in the example (ad possibly other dsp objects), or simply
> creating a 1 second ramp? I the latter case you don't necessarily need that
> phasor~ and could just use a table and soundfiler as Roman suggested.
>
> Lorenzo.
>
>
>> Roman
>>
>>
>> On Mon, 2014-05-12 at 12:22 +0100, Oli Larkin wrote:
>>
>>> Hi,
>>>
>>> I'm experimenting with the -batch option. I would like to be able to
>>> process wave files and they should end up exactly the same length in terms
>>> of samples as the original file.
>>>
>>> Here is a test patch which writes a ramp which should last 44100
>>> samples. I am launching it like this:
>>>
>>> /Applications/Pd-0.45-4.app/Contents/Resources/bin/pd -batch -nomidi
>>> -send "file test" /Users/oli/batchtest.pd
>>>
>>> The resulting file is 44096 samples long. I realise this is because the
>>> message rate delay which stops the recording is quantized to block
>>> boundaries (64*689 = 44096)
>>>
>>> Is there any way i can stop the recording after exactly 44100 samples
>>> have elapsed?
>>>
>>> thanks
>>>
>>> oli
>>>
>>> //batchtest.pd
>>>
>>> #N canvas 696 426 450 300 10;
>>> #X obj 194 157 writesf~;
>>> #X msg 189 107 start;
>>> #X obj 218 30 loadbang;
>>> #X msg 114 198 stop;
>>> #X obj 293 34 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
>>> -1;
>>> #X msg 250 111 open /Users/oli/test.wav;
>>> #X msg 292 66 \; pd dsp 1;
>>> #X obj 215 60 t b b b b;
>>> #X obj 74 159 t b b;
>>> #X msg 50 218 \; pd xquit;
>>> #X obj 86 51 phasor~ 1;
>>> #X obj 74 128 delay 1000;
>>> #X obj 285 191 receive file;
>>> #X obj 285 230 print file;
>>> #X connect 1 0 0 0;
>>> #X connect 2 0 7 0;
>>> #X connect 3 0 0 0;
>>> #X connect 4 0 7 0;
>>> #X connect 5 0 0 0;
>>> #X connect 7 0 11 0;
>>> #X connect 7 1 1 0;
>>> #X connect 7 2 5 0;
>>> #X connect 7 3 6 0;
>>> #X connect 8 0 9 0;
>>> #X connect 8 1 3 0;
>>> #X connect 10 0 0 0;
>>> #X connect 11 0 8 0;
>>> #X connect 12 0 13 0;
>>>
>>>
>>> _______________________________________________
>>> Pd-list at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
>>> listinfo/pd-list
>>>
>>
>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
>> listinfo/pd-list
>>
>>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
> listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140512/75eaa235/attachment-0001.htm>