Hello list,
continuing with a topic I started some time ago (but couldn't continue the discussion), I've made a simulated version of my patch to explain the situation. The full patch is too complex, and would need audio files to be sent with it.
The context is as follows: An audio file stored in a buffer is played in small segments in a forward-backward sequence. Each segment is played after the previous, with no gaps in time or reading point. First segment goes as 0 - 8638.86, 2nd as 8638.86 - 17277.7, 3rd as 17277.7 - 25916.6 , etc. All segments are triggered at the same pace, in this case 181.818 ms. You can see all the segments in the [textfile]. Ideally, the original audio file would be reproduced with no difference to the original - besides the playback pointer going forward-backward.
But when playing back the segments, after the first initial moment with almost no problems (only the clicks when playback changes direction), clicks start to appear at each segment - from around sample 229K onwards.
Since I'm using [vline~], I thought that the timing of the reading point related to the audio blocks wouldn't be a problem. But, if you record the output and look at the audio file, you'll see that the clicks come from a out of phase moment, and then the wave continues.
My question is: am I doing something wrong with the circuit? If not, is there an efficient way of achieving a similar playback of a stored buffer?
I hope everything is clear. The original patch is a monster, but this version sums up what's happening.
Btw, in the original patch all the values are calculated in real time. But with the "recorded" version the audio sound just the same. The original audio file is 5m18s long. Will the be any round-up problems while calculating the segment coordinates to tabread4~?
Thanks in advance for who has the time to read this,
Joao
Joao, if the jumps are always (theoretically zero) going to be very small (no backjumps of a whole segment) then let's suggest a quick and practical fix and ignore the whole issue of sample accuracy in the control system. I take it you only need this to sound good enough, not be sample accurate:
Place a [lop~ 1000] after the [vline~]
This will remove any sudden little jumps and smooth the playback at segment boundaries. Might be good enough for rock n roll.
On Sun, Mar 11, 2012 at 11:05:31PM +0100, João Pais wrote:
Hello list,
continuing with a topic I started some time ago (but couldn't continue the discussion), I've made a simulated version of my patch to explain the situation. The full patch is too complex, and would need audio files to be sent with it.
The context is as follows: An audio file stored in a buffer is played in small segments in a forward-backward sequence. Each segment is played after the previous, with no gaps in time or reading point. First segment goes as 0 - 8638.86, 2nd as 8638.86 - 17277.7, 3rd as 17277.7 - 25916.6 , etc. All segments are triggered at the same pace, in this case 181.818 ms. You can see all the segments in the [textfile]. Ideally, the original audio file would be reproduced with no difference to the original - besides the playback pointer going forward-backward.
But when playing back the segments, after the first initial moment with almost no problems (only the clicks when playback changes direction), clicks start to appear at each segment - from around sample 229K onwards.
Since I'm using [vline~], I thought that the timing of the reading point related to the audio blocks wouldn't be a problem. But, if you record the output and look at the audio file, you'll see that the clicks come from a out of phase moment, and then the wave continues.
My question is: am I doing something wrong with the circuit? If not, is there an efficient way of achieving a similar playback of a stored buffer?
I hope everything is clear. The original patch is a monster, but this version sums up what's happening.
Btw, in the original patch all the values are calculated in real time. But with the "recorded" version the audio sound just the same. The original audio file is 5m18s long. Will the be any round-up problems while calculating the segment coordinates to tabread4~?
Thanks in advance for who has the time to read this,
Joao
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Andy,
Joao, if the jumps are always (theoretically zero) going to be very small (no backjumps of a whole segment) then let's suggest a quick and practical fix and ignore the whole issue of sample accuracy in the control system. I take it you only need this to sound good enough, not be sample accurate:
Place a [lop~ 1000] after the [vline~]
This will remove any sudden little jumps and smooth the playback at segment boundaries. Might be good enough for rock n roll.
unfortunately, there are places where part of the table is played by
another player (you'll see the gaps in the text file).
But also, unfortunately the lop~ doesn't change the result at all, I
think. At least I couldn't hear it, also not by changing the value to
something bigger. The clicks in the direction corners are still there.
João
Hi João,
The first thing I'm wondering is if you want each segment to have the same number of samples. I see that the time to scrub through each segment is the same (181.818 ms), but then the length of segments in samples varies. I guess the pitch shift that happens from this isn't a problem?
Also, it looks like not all of the boundaries in your log.txt line up. Starting on segment 330, there are gaps now and then:
198694 207333 181.818; 210909 219994 181.818;
That explains the phase discontinuities (at least some). I know this is just your abstracted problem, but maybe similar unexpected gaps exist in your main patch?
On Sun, Mar 11, 2012 at 6:05 PM, João Pais jmmmpais@googlemail.com wrote:
Hello list,
continuing with a topic I started some time ago (but couldn't continue the discussion), I've made a simulated version of my patch to explain the situation. The full patch is too complex, and would need audio files to be sent with it.
The context is as follows: An audio file stored in a buffer is played in small segments in a forward-backward sequence. Each segment is played after the previous, with no gaps in time or reading point. First segment goes as 0 - 8638.86, 2nd as 8638.86 - 17277.7, 3rd as 17277.7 - 25916.6 , etc. All segments are triggered at the same pace, in this case 181.818 ms. You can see all the segments in the [textfile]. Ideally, the original audio file would be reproduced with no difference to the original - besides the playback pointer going forward-backward.
But when playing back the segments, after the first initial moment with almost no problems (only the clicks when playback changes direction), clicks start to appear at each segment - from around sample 229K onwards.
Since I'm using [vline~], I thought that the timing of the reading point related to the audio blocks wouldn't be a problem. But, if you record the output and look at the audio file, you'll see that the clicks come from a out of phase moment, and then the wave continues.
My question is: am I doing something wrong with the circuit? If not, is there an efficient way of achieving a similar playback of a stored buffer?
I hope everything is clear. The original patch is a monster, but this version sums up what's happening.
Btw, in the original patch all the values are calculated in real time. But with the "recorded" version the audio sound just the same. The original audio file is 5m18s long. Will the be any round-up problems while calculating the segment coordinates to tabread4~?
Thanks in advance for who has the time to read this,
Joao
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi William,
The first thing I'm wondering is if you want each segment to have the same number of samples. I see that the time to scrub through each segment is the same (181.818 ms), but then the length of segments in samples varies. I guess the pitch shift that happens from this isn't a problem?
that's not a problem, later there will be some pitch correction happening
(if I also get a good enough pitch shifter, but that's another subject)
The original audio is a "normal" sample, I just replaced it with a sine
for the debugging.
Also, it looks like not all of the boundaries in your log.txt line up. Starting on segment 330, there are gaps now and then:
198694 207333 181.818; 210909 219994 181.818;
That explains the phase discontinuities (at least some). I know this is just your abstracted problem, but maybe similar unexpected gaps exist in your main patch?
:) I didn't want to write a big mail before, but don't worry about these.
The fragments missing there are played by another player. But explaining
much more would just look the problem I'l chasing now look more complex
than it is.
The main problem is really just the [vline~] output that should be
continuous, but isn't.
In fact, after writing this patch I recalled that I didn't save the output
of the reading index into a buffer yet, to see how it looks. I'll be doing
that later today.
Thanks,
João
I'm also wondering about the timing of tabread4~'s offset inlet being updated. I get fewer clicks by tossing most of the patch into a subpatch with [block~ 1]. I haven't checked really carefully, but that does seem to make it so that clicks only occur where there are gaps in the log.txt file.
Another thing is that, even though vline~ can start ramping between block boundaries, there's still a lower limit involved. You can see in the attached patch that you can't get a period less than about 88 samples (or 44 samples for each half of the triangle wave). Seems like that shouldn't be affecting you though, since you're retriggering every ~180 samples.
On Mon, Mar 12, 2012 at 5:30 AM, João Pais jmmmpais@googlemail.com wrote:
Hi William,
The first thing I'm wondering is if you want each segment to have the same number of samples. I see that the time to scrub through each segment is the same (181.818 ms), but then the length of segments in samples varies. I guess the pitch shift that happens from this isn't a problem?
that's not a problem, later there will be some pitch correction happening (if I also get a good enough pitch shifter, but that's another subject) The original audio is a "normal" sample, I just replaced it with a sine for the debugging.
Also, it looks like not all of the boundaries in your log.txt line up. Starting on segment 330, there are gaps now and then:
198694 207333 181.818; 210909 219994 181.818;
That explains the phase discontinuities (at least some). I know this is just your abstracted problem, but maybe similar unexpected gaps exist in your main patch?
:) I didn't want to write a big mail before, but don't worry about these. The fragments missing there are played by another player. But explaining much more would just look the problem I'l chasing now look more complex than it is.
The main problem is really just the [vline~] output that should be continuous, but isn't.
In fact, after writing this patch I recalled that I didn't save the output of the reading index into a buffer yet, to see how it looks. I'll be doing that later today.
Thanks,
João
Hi William,
On Mon, Mar 12, 2012 at 11:32:44AM -0400, William Brent wrote:
Another thing is that, even though vline~ can start ramping between block boundaries, there's still a lower limit involved. You can see in the attached patch that you can't get a period less than about 88 samples (or 44 samples for each half of the triangle wave).
This actually is a limitation of [metro] which has a lower boundary of 1 millisecond. If you replace it with a metro-clone based on a feedback'd [delay] you can get lower periods.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Ah - very good to know, thanks!
On Mon, Mar 12, 2012 at 11:43 AM, Frank Barknecht fbar@footils.org wrote:
Hi William,
On Mon, Mar 12, 2012 at 11:32:44AM -0400, William Brent wrote:
Another thing is that, even though vline~ can start ramping between block boundaries, there's still a lower limit involved. You can see in the attached patch that you can't get a period less than about 88 samples (or 44 samples for each half of the triangle wave).
This actually is a limitation of [metro] which has a lower boundary of 1 millisecond. If you replace it with a metro-clone based on a feedback'd [delay] you can get lower periods.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, Mar 12, 2012 at 11:32:44AM -0400, William Brent wrote:
I'm also wondering about the timing of tabread4~'s offset inlet being updated. I get fewer clicks by tossing most of the patch into a subpatch with [block~ 1]. I haven't checked really carefully, but that does seem to make it so that clicks only occur where there are gaps in the log.txt file.
This also is the reason for the 181 msec clicks I get. Replacing the whole [list-sub] construction with a simple [$1, $2 $3( between [textfile] and [vline~] gives a nice and clean sound, except at the turnaround points where clicks are expected anyway.
The offset-index of [tabread4~] is a message inlet that is not timing accurate, [tabread4~] will use the value from here at a different time than [vline~] uses its own copy of the value, leading to clicks.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
On Mon, Mar 12, 2012 at 11:32:44AM -0400, William Brent wrote:
I'm also wondering about the timing of tabread4~'s offset inlet being updated. I get fewer clicks by tossing most of the patch into a subpatch with [block~ 1]. I haven't checked really carefully, but that does seem to make it so that clicks only occur where there are gaps in the log.txt file.
This also is the reason for the 181 msec clicks I get. Replacing the
whole [list-sub] construction with a simple [$1, $2 $3( between [textfile] and [vline~] gives a nice and clean sound, except at the turnaround points
where clicks are expected anyway.The offset-index of [tabread4~] is a message inlet that is not timing
accurate, [tabread4~] will use the value from here at a different time than
[vline~] uses its own copy of the value, leading to clicks.
Very strange. In the computer I am now, I do hear the regular clicks, but
I didn't heard them before.
The offset of [tabread4~] was there to avoid any reading errors when the
index points get too high (the whole sample is almost 7m long). So there's
not option for this, but to use only the right entry?
I was watching the recorded result of the test patch, and the clicks in
the direction change happen, even though the recorded wave is simmetrical.
I though that the result would be a continous wave with no clicks, but
where did I go wrong? I guess the corner in the wave, even being
symmetrical, always produces a click, right?
João
The offset of [tabread4~] was there to avoid any reading errors when the index points get too high (the whole sample is almost 7m long). So there's not option for this, but to use only the right entry?
Seems like you should stick with your original approach using the right inlet for good indexing resolution, and work in a [block~ 1] subpatch to force the inlet to update every sample.
yes, thanks. that does do the job. I usually don't work with reblocking at
all, and can't look inside the code to see what can be done better.
the only problem is still the clicks when the reader changes direction. I
thought that it wouldn't make any clicks, because the signal would be
continuous. but looking at the recorded wave file I notice that there is a
click there, so it might not be possible at all to avoid these?
The offset of [tabread4~] was there to avoid any reading errors when the index points get too high (the whole sample is almost 7m long). So
there's not option for this, but to use only the right entry?Seems like you should stick with your original approach using the right inlet for good indexing resolution, and work in a [block~ 1] subpatch to force the inlet to update every sample.
Hi,
On Tue, Mar 13, 2012 at 08:01:21PM +0100, João Pais wrote:
The offset of [tabread4~] was there to avoid any reading errors when the
index points get too high (the whole sample is almost 7m long). So there's not option for this, but to use only the right entry?
I believe it should be possible to correct the timing issues of the offset inlet with some additional calculations involving [timer] and [bang~] that take into account that this inlet is only updated at block boundaries. It's probably a bit tricky to get right, but I suppose it could work.
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
The offset of [tabread4~] was there to avoid any reading errors when the index points get too high (the whole sample is almost 7m long). So there's not option for this, but to use only the right entry?
I believe it should be possible to correct the timing issues of the
offset inlet with some additional calculations involving [timer] and [bang~] that take into account that this inlet is only updated at block boundaries. It's
probably a bit tricky to get right, but I suppose it could work.
shouldn't it make sense that, instead of a workaround, all features of
[tabread4~] would behave the same way?
João
I'm also wondering about the timing of tabread4~'s offset inlet being updated. I get fewer clicks by tossing most of the patch into a subpatch with [block~ 1]. I haven't checked really carefully, but that does seem to make it so that clicks only occur where there are gaps in the log.txt file.
Another thing is that, even though vline~ can start ramping between block boundaries, there's still a lower limit involved. You can see in the attached patch that you can't get a period less than about 88 samples (or 44 samples for each half of the triangle wave). Seems like that shouldn't be affecting you though, since you're retriggering every ~180 samples.
more like every ~180 ms :)
I won't be getting here into that kind of micro-control. It was more about
the precision of several fragments being played as one sound.
-
Andy Farnell -
Frank Barknecht -
João Pais -
William Brent