hmm, it seems that writesf~ only works correctly for me when the "open" message is sent when DSP is already on.
For example, this works:
; dsp on ( send open message to writesf~) (send start message to writesf~) (wait some time) (send stop message to writesf~) (wait some time) ; dsp off
.. but this doesn't (starting with dsp off) :
(send open message to writesf~) ; dsp on (send start message to writesf~) (wait some time) (send stop message to writesf~) (wait some time) ; dsp off
In the second case, a file does get created, but it captures only a portion of the total recording time.
I Haven't looked through the source yet to trace this, but this raises a larger issue I think: how do we know which messages on objects work with dsp off, and which of them require dsp on?
Best Regards
Larry Troxler
Well, they should all work the same whether DSP is on or off. THis isn't always true in reality - in particular, tilde objects don't get to find out their sample rate until DSP goes on. There are probably other situations as well. This one about writesf~ is probably a bug in the object, nothing deeper. But writesf~ is delicate enough that I'm afraid to monkey with it for a "patch" release, so will wait until later to try ti fix this.
cheers Miller
On Sun, Dec 21, 2003 at 07:39:03PM -0500, Larry Troxler wrote:
hmm, it seems that writesf~ only works correctly for me when the "open" message is sent when DSP is already on.
For example, this works:
; dsp on ( send open message to writesf~) (send start message to writesf~) (wait some time) (send stop message to writesf~) (wait some time) ; dsp off
.. but this doesn't (starting with dsp off) :
(send open message to writesf~) ; dsp on (send start message to writesf~) (wait some time) (send stop message to writesf~) (wait some time) ; dsp off
In the second case, a file does get created, but it captures only a portion of the total recording time.
I Haven't looked through the source yet to trace this, but this raises a larger issue I think: how do we know which messages on objects work with dsp off, and which of them require dsp on?
Best Regards
Larry Troxler
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Saturday 17 January 2004 17:55, Miller Puckette wrote:
Well, they should all work the same whether DSP is on or off. THis isn't always true in reality - in particular, tilde objects don't get to find out their sample rate until DSP goes on. There are probably other situations as well. This one about writesf~ is probably a bug in the object, nothing deeper. But writesf~ is delicate enough that I'm afraid to monkey with it for a "patch" release, so will wait until later to try ti fix this.
cheers Miller
Sounds good to me - adding a comment in the help patch about this quirk is plenty good enough I think.
Larry
On Sun, Dec 21, 2003 at 07:39:03PM -0500, Larry Troxler wrote:
hmm, it seems that writesf~ only works correctly for me when the "open" message is sent when DSP is already on.
For example, this works:
; dsp on ( send open message to writesf~) (send start message to writesf~) (wait some time) (send stop message to writesf~) (wait some time) ; dsp off
.. but this doesn't (starting with dsp off) :
(send open message to writesf~) ; dsp on (send start message to writesf~) (wait some time) (send stop message to writesf~) (wait some time) ; dsp off
In the second case, a file does get created, but it captures only a portion of the total recording time.
I Haven't looked through the source yet to trace this, but this raises a larger issue I think: how do we know which messages on objects work with dsp off, and which of them require dsp on?
Best Regards
Larry Troxler
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
List,
While they should not occur, it has happened that in my patch, when getting up in the 100s of tracks, my "open" command has somehow been missed by my writesf~ object. If this occurs again, I would like the patch to be aware of the problem.
Do writesf~ and readsf~ generate some sort of return value? How do I catch it?
Thanks,
dan
List,
the open command for readsf has several overrides, but the help does not mention sample rate as one of them.
Assuming changing pitch is the goal, is there any way to override the sound file's header? Does readsf~ simply playback the audio preferences sample rate?
Any suggestions for a batch resample utility that works efficiently in the background, linux or osx, preferably gnu. It'd be nice if it could either watch a directory or receive messages from a patch.
Also, what are you guys using to open up and edit the sound files manually? Which sound file format is easier to do this with, wav or aiff?
Thanks, again,
dan
Hi Dan,
I believe readsf~ simply ignores the sample rate of the incoming sound and plays it at the sample rate of the patch.
There's a wonderful opensource program from Julius Smith called, simply, "resample". It's higher quality than any commercial one I know of.
cheers Miller
On Sat, Jan 31, 2004 at 11:38:49PM -0800, Dan Wilken wrote:
List,
the open command for readsf has several overrides, but the help does not mention sample rate as one of them.
Assuming changing pitch is the goal, is there any way to override the sound file's header? Does readsf~ simply playback the audio preferences sample rate?
Any suggestions for a batch resample utility that works efficiently in the background, linux or osx, preferably gnu. It'd be nice if it could either watch a directory or receive messages from a patch.
Also, what are you guys using to open up and edit the sound files manually? Which sound file format is easier to do this with, wav or aiff?
Thanks, again,
dan
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list