Hi Jakob,
In a former version of my patch, I did this successfully when I was using [tabread4~] as my file-playing-object, but I needed to switch to [readsf~] in order to implement dynamic loading of wav-files.
I would recommend you reconsider using [tabread4~] (or even tabplay~, see below) as your tool to read a soundfile. If what you want is to load a number of wav files, the best thing is to send several messages to [soundfiler] to read (and resize) soundfiles into a set of [array define]s. You can then either send a 'set' message to [tabread4~] to change the array you are reading from, or have a bunch of dedicated [tabread4~]s one for each soundfile...
This is a more efficient way for your patch to load all sounds on startup and *not* load each file every time you need to play it. It is a bit of an extra effort, but you will gain much more from the fact that you are not reading from disk on every soundfile loop.
That's why I want to constantly check the position of the wav-file that
[readsf~] is currently at, when it plays the wav-file.
As a side effect from the [soundfiler] solution, you'll always know where in the file you are because you need to control playback yourself. However, it might just be quicker to use [tabplay~] instead, and just play a section of the file by sending it a list instead of the usual 'bang'.
Hope it helps,
f
On Tue, 2019-11-19 at 18:21 -0500, Federico Camara Halac wrote:
Hi Jakob,
In a former version of my patch, I did this successfully when I was using [tabread4~] as my file-playing-object, but I needed to switch to [readsf~] in order to implement dynamic loading of wav-files.
I would recommend you reconsider using [tabread4~] (or even tabplay~, see below) as your tool to read a soundfile.
I think the reason for switching from [tabplay~] to [readsf~] was memory constraints of the target device. See 1
(which reminds me of the Pd list netiquette: Doesn't it specifically say that HTML formatting is discouraged? Personally, I'd appreciate it very much if mails were written in plain text.)
Roman
You can get the samplerate and file length of your file by sending a read message to soundfiler and not specifying a table to write to. From that you can calculate the expected play time.
On Wed, 20 Nov 2019 at 04:42, Jakob Laue jakkesprinter@web.de wrote:
Hey all, I want to play a wav-file with [readsf~] and I want to loop the wav-file. This can easily be done by connecting [readsf~]'s right outlet it its inlet. The problem is that I have a metronome in my patch which is the master of the tempo. The [readsf~] object will get out of sync with the metronome when it loops the same file over a longer period of time. That's why I want to constantly check the position of the wav-file that [readsf~] is currently at, when it plays the wav-file. By this, I can restart/loop the wav-file in sync with the metronome, as soon as it has almost reached its end. Do you have an idea how I could do that?
In a former version of my patch, I did this successfully when I was using [tabread4~] as my file-playing-object, but I needed to switch to [readsf~] in order to implement dynamic loading of wav-files.
Thanks, Jakob _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Tue, 2019-11-19 at 21:39 +0100, Jakob Laue wrote:
Hey all, I want to play a wav-file with [readsf~] and I want to loop the wav- file. This can easily be done by connecting [readsf~]'s right outlet it its inlet. The problem is that I have a metronome in my patch which is the master of the tempo. The [readsf~] object will get out of sync with the metronome when it loops the same file over a longer period of time. That's why I want to constantly check the position of the wav- file that [readsf~] is currently at, when it plays the wav-file. By this, I can restart/loop the wav-file in sync with the metronome, as soon as it has almost reached its end. Do you have an idea how I could do that?
You should definitely start each loop in sync with the metronome. It seems you're letting [readsf~ ] playback loop itself by using the end bang to trigger playback again. This is not wrong, but if the length of your soundfile doesn't match exactly a multiple of your metro period, then metro and loop playback will drift apart.
Pd is absolutely deterministic. There is no need to ask [readsf~] for the current cursor position. You can derive it from the time that has passed since you started it. But even that would only be necessary if you have user input and you want to determine current playback position at time of user input.
If my assumption is correct that in your patch playback and loop lengths are predefined, you could simply play the portion of the file that exactly fits into a multiple of your metro period. You should then use the bang from metro to retrigger the start of the playback.
Roman
Just a reminder - send the "open" message at least a tenth of a second in advance of the "start" message to avoid glitches in the output. If you want to loop a soundfile, use two readsf~ objects in turn (and then, for bonus points, you can cross-fade them to avoid clicks at the loop point).
If sub-millisecond timing is desired, note that the output always starts on a 64-sample boundary; you can use bang~ and timer to measure the time since the last block started and give the "start" message an advance in samples to avoid audible jitters.
cheers Miller
On Wed, Nov 20, 2019 at 08:52:52AM +0100, Roman Haefeli wrote:
On Tue, 2019-11-19 at 21:39 +0100, Jakob Laue wrote:
Hey all, I want to play a wav-file with [readsf~] and I want to loop the wav- file. This can easily be done by connecting [readsf~]'s right outlet it its inlet. The problem is that I have a metronome in my patch which is the master of the tempo. The [readsf~] object will get out of sync with the metronome when it loops the same file over a longer period of time. That's why I want to constantly check the position of the wav- file that [readsf~] is currently at, when it plays the wav-file. By this, I can restart/loop the wav-file in sync with the metronome, as soon as it has almost reached its end. Do you have an idea how I could do that?
You should definitely start each loop in sync with the metronome. It seems you're letting [readsf~ ] playback loop itself by using the end bang to trigger playback again. This is not wrong, but if the length of your soundfile doesn't match exactly a multiple of your metro period, then metro and loop playback will drift apart.
Pd is absolutely deterministic. There is no need to ask [readsf~] for the current cursor position. You can derive it from the time that has passed since you started it. But even that would only be necessary if you have user input and you want to determine current playback position at time of user input.
If my assumption is correct that in your patch playback and loop lengths are predefined, you could simply play the portion of the file that exactly fits into a multiple of your metro period. You should then use the bang from metro to retrigger the start of the playback.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hello all! Thanks for all your replies! With your help I was now able to implement a solution by calculating and checking the play time of the sample. Cheers!
Am 20.11.2019 um 17:32 schrieb Miller Puckette msp@ucsd.edu:
Just a reminder - send the "open" message at least a tenth of a second in advance of the "start" message to avoid glitches in the output. If you want to loop a soundfile, use two readsf~ objects in turn (and then, for bonus points, you can cross-fade them to avoid clicks at the loop point).
If sub-millisecond timing is desired, note that the output always starts on a 64-sample boundary; you can use bang~ and timer to measure the time since the last block started and give the "start" message an advance in samples to avoid audible jitters.
cheers Miller
On Wed, Nov 20, 2019 at 08:52:52AM +0100, Roman Haefeli wrote:
On Tue, 2019-11-19 at 21:39 +0100, Jakob Laue wrote: Hey all, I want to play a wav-file with [readsf~] and I want to loop the wav- file. This can easily be done by connecting [readsf~]'s right outlet it its inlet. The problem is that I have a metronome in my patch which is the master of the tempo. The [readsf~] object will get out of sync with the metronome when it loops the same file over a longer period of time. That's why I want to constantly check the position of the wav- file that [readsf~] is currently at, when it plays the wav-file. By this, I can restart/loop the wav-file in sync with the metronome, as soon as it has almost reached its end. Do you have an idea how I could do that?
You should definitely start each loop in sync with the metronome. It seems you're letting [readsf~ ] playback loop itself by using the end bang to trigger playback again. This is not wrong, but if the length of your soundfile doesn't match exactly a multiple of your metro period, then metro and loop playback will drift apart.
Pd is absolutely deterministic. There is no need to ask [readsf~] for the current cursor position. You can derive it from the time that has passed since you started it. But even that would only be necessary if you have user input and you want to determine current playback position at time of user input.
If my assumption is correct that in your patch playback and loop lengths are predefined, you could simply play the portion of the file that exactly fits into a multiple of your metro period. You should then use the bang from metro to retrigger the start of the playback.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Federico Camara Halac -
Jakob -
Jakob Laue
-
Matt Davey -
Miller Puckette -
Roman Haefeli