Ok, as long as we're on it, here's another thing I found while patching around. Probably related to the last crazy behaviour I just described, but something on its own.
It is simpler than phase vocoding, it's just something weird about sampling into arrays and playing with [tabread4~]. Well, maybe there's a relation to the bug I just reported (check my last email sent to the list please), because that uses [tabread4~] as well.
So, if I record onto a a somewhat big array, there comes a time where it just fails completely when playing it through [tabread4~], but not with [tabplay~]. It also does not show it anymore after that particular point in the array itself. The point is around 380 seconds (6 minutes and 20 seconds).
So in this example I have a table that resizes to 400 seconds. You can open the table object and see that the last bit of it is not being displayed visually.
Well, I as first going to report this as "I can't hear it all all after that 380 seconds point". But somehow, the way I'm patching it now in this example still plays it, but completely ruined...
By the way, when I can't hear it at all is when I'm using my big phase vocoder based patch... which also uses [tabread4~]. So, not sure why or if it actually stops playing there or not, but the important thing is that something quite fishy happens at the same time, around 380 seconds, the point in which the array does not display anymore.
So, in this example I'm sending, it still plays, but rather ruined. Although there is a pretty clear relationship on how the array displays itself, weirdly enough, if I play it through [tabplay~], it is all fine and good.
Check example at: https://sites.google.com/site/porres/tabread4%7E.bug.pd
So you can check the patch I have, you can load a big file into it (6 minutes and a half at least), or if you have nothing like that at all you can just record the oscillator into the table as I have set there. And you can check yourself that this is happening the way I describe, but the question is:
- What a hell is wrong with [tabread4~]??? Does it have something to do
with that other bug I pointed regarding the phase vocoder? Anyway, in the Phase Vocoder, the problem happens way before 6:20, at around 47 seconds only, but the way it ruins the sound seems related...
Question number 2... why doen't the array display itself for more than 380 seconds? how is this related to the way [tabread4~] fails?
Thanks for the attention.
Cheers from Brasil
Alex
There is some inbuilt limit to array sizes that needs to be overridden by using the -maxsize tag when loading a file from soundfiler.
I have a feeling it might mess things up with GOP arrays if you use that.
Hi,
On 24/07/12 03:55, Alexandre Torres Porres wrote:
Ok, as long as we're on it, here's another thing I found while patching around. Probably related to the last crazy behaviour I just described, but something on its own.
It is simpler than phase vocoding, it's just something weird about sampling into arrays and playing with [tabread4~]. Well, maybe there's a relation to the bug I just reported (check my last email sent to the list please), because that uses [tabread4~] as well.
So, if I record onto a a somewhat big array, there comes a time where it just fails completely when playing it through [tabread4~], but not with [tabplay~]. It also does not show it anymore after that particular point in the array itself. The point is around 380 seconds (6 minutes and 20 seconds).
This is a known limitation with [tabread4~] and [tabread~] and pops up every now and then [1] (it could probably be useful to mention it in [tabread~] help).
Long story short: you are rather safe with [tabread~] and [tabread4~] for arrays as big as 2^24 - that is 16777216 Length in seconds will vary depending on sample-rate: Here a table for commonly used samplerates:
+--------+------------+ | s.rate | seconds | +--------+------------+ | 44100 | 380.44 | +--------+------------+ | 48000 | 349.53 | +--------+------------+ | 88200 | 190.22 | +--------+------------+ | 96000 | 174.76 | +--------+------------+
Hope this helps. Lorenzo.
[1] See here a thread from 2006: http://lists.puredata.info/pipermail/pd-list/2006-08/040671.html and here for a clear explanation: http://puredata.hurleur.com/viewtopic.php?pid=28924#p28924
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-24 09:34, Lorenzo Sutton wrote:
This is a known limitation with [tabread4~] and [tabread~] and pops up every now and then [1] (it could probably be useful to mention it in [tabread~] help).
it is mentioned in the help-patch for [tabread4~] and explained in detail in B15.tabread4~-onset.pd
ghmasd IOhannes
On 24/07/12 12:00, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-24 09:34, Lorenzo Sutton wrote:
This is a known limitation with [tabread4~] and [tabread~] and pops up every now and then [1] (it could probably be useful to mention it in [tabread~] help).
it is mentioned in the help-patch for [tabread4~]
It doesn't seem so, at least not explicitly. There is a mention to 4-point interpolation and to onsets and the tutorial below. (at least looking at 0.43 vanilla and 0.43 extended help patches)
and explained in detail in B15.tabread4~-onset.pd
True indeed, and there is a reference to it in the help patch (a 'link' in 0.43 extended)
What I meant was that it might be helpful to mention more explicitly the fact that one of the practical consequence is a limitation in 'usable' duration of samples. But I definitely won't make a fuss of it :)
Lorenzo.
-
Alexandre Torres Porres -
i go bananas -
IOhannes m zmoelnig -
Lorenzo Sutton