Hi:
I would like to do some batch processing into ".wav" files. This should be easily accomplished by running pd with -noaudio and -nogui. It almost works. I run my signal through [freeverb~] just before output. If I run the patch with -nogui, freeverb~ is bypassed and the sound is dry. In every other way, it works properly. Why this difference in output just because of -nogui? I attach a demo patch.
To reproduce:
To hear the output with reverb:
With reverb mysteriously bypassed:
uname -a Linux Congo 2.6.25.14-108.fc9.x86_64 #1 SMP Mon Aug 4 13:46:35 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux pd -version Pd version 0.41-4 compiled 18:31:52 Aug 14 2008
freeverb~ 1.2
Unfortunately I have to agree with David....if I run any patch with -nogui from my terminal, then freeverb~ is bypassed (please find a simple input reverb example patch). This doesn't make sense at all! Any ideas at all how to solve this?
Juan (Pd version 0.41.4 running on Mac OS X 10.5.8)
2008/9/26 David F. Place d@vidplace.com
Hi:
I would like to do some batch processing into ".wav" files. This should be easily accomplished by running pd with -noaudio and -nogui. It almost works. I run my signal through [freeverb~] just before output. If I run the patch with -nogui, freeverb~ is bypassed and the sound is dry. In every other way, it works properly. Why this difference in output just because of -nogui? I attach a demo patch.
To reproduce:
To hear the output with reverb:
- pd -noloadbang freeBug.pd
- click on the bang labeled "Click!"
- wait about 15 secs, pd will quit
- aplay /tmp/foo.wav
With reverb mysteriously bypassed:
- pd -nogui freeBug.pd
- wait about 15 secs, pd will quit
- play /tmp/foo.wav
uname -a Linux Congo 2.6.25.14-108.fc9.x86_64 #1 SMP Mon Aug 4 13:46:35 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux pd -version Pd version 0.41-4 compiled 18:31:52 Aug 14 2008
freeverb~ 1.2
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
i had some problem with a -nogui patch running [delwrite~],[delread~] pairs. it was a C programmer who eventually fixed the problem for me, but if i recall correctly, the issue was with the delayline samplerate not being set properly when pd is running nogui. running with gui seemed to introduce a slight delay which caused delayline samplerate to be initiatlized properly.
i wouldn't be surprised if your freeverb~ problem is somehow related, as it also uses delaylines.
oh, and the bad news was that the only way we could fix that problem was by modifying the pd source code.
hard off wrote:
i had some problem with a -nogui patch running [delwrite~],[delread~] pairs. it was a C programmer who eventually fixed the problem for me, but if i recall correctly, the issue was with the delayline samplerate not being set properly when pd is running nogui. running with gui seemed to introduce a slight delay which caused delayline samplerate to be initiatlized properly.
i wouldn't be surprised if your freeverb~ problem is somehow related, as it also uses delaylines.
iirc, this has been brought up on this list, verified and a workaround had been posted (something like: do not directly loadbang "; pd dsp 1" but rather wait a little bit)
fgamsdr IOhannes