Re: [PD] [tabread4~] bug???

2012-07-24 Thread i go bananas
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.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [tabread4~] bug???

2012-07-24 Thread Lorenzo Sutton

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


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [tabread4~] bug???

2012-07-24 Thread IOhannes m zmoelnig
-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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAOcigACgkQkX2Xpv6ydvTKlACbBN1X37EMy6TLGNqOTHL9UQ0k
2iwAn2SdmjmHq34kPKgtutgFrBdd8xiz
=Qjwi
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [tabread4~] bug???

2012-07-24 Thread Lorenzo Sutton

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.

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list