I think this depends on how oggwrite~ works internally. Objects ideally should react to changes in sample rate in real time, since the user can change the rate after the object has been created.
Unfortunately this isn't even true of the delwrite~ object, whose memory should be resized dynamically when the sample rate changes and doesn't!
cheers Miller
On Tue, Nov 06, 2012 at 10:04:45PM +0100, Pierre Massat wrote:
Hi Miller,
Thanks for your reply. Would this work if I set the samplerate from within the patch some time after startup ? Or should I start Pd with the proper sample rate, and then open my patch ? I have no idea how I can do the later, except in a very inelegant way (make a small patch with a delayed loadbang that just sends a "pd open patch.pd" message).
Cheers,
Pierre.
2012/11/6 Miller Puckette msp@ucsd.edu
This popped up on the list earlier... the sample rate gets set _after_ patches are loaded from the command line if -nogui is set. It's on my long list of things to try to fix. In the meantime, as a workaround, if you can namage to delay Pd's loading of the patch, even by a fraction of a second, it should get the proper sample rate.
cheers Miller
On Tue, Nov 06, 2012 at 08:33:22PM +0100, Pierre Massat wrote:
Dear List,
While trying to use oggwrite~ on my RPi I noticed that it complained
about
being unable to change the samplerate from 0 to 44100. I turns out that Pd launched from the command line with the -nogui flag
has
a samplerate of 0 ! Adding the "-r 44100" flag doesn't change anything, nor does adding the "-alsa" flag. I wonder what causes this, whether it is a bug or not, and how Pd manages to work fine anyway (the only real problem i've had this far was with oggwrite~)...
Any clue?
Cheers,
Pierre.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->