Re: [PD] big soundfiles
On Thu, 25 Nov 2010, Derek Holzer wrote: Yes please! Ah, forgot this one. Here it is (attachment). ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC#N canvas 663 73 450 374 10; #X obj 214 95 soundfiler; #X obj 23 17 table zoo 0; #X obj 214 114 print; #X msg 154 46 read -resize -maxsize 1e+07 zoolook.wav zoo; #X obj 24 217 *~ 0.5; #X obj 24 111 sig~; #X floatatom 24 74 8 0 0 0 - - -; #X obj 152 207 snapshot~; #X floatatom 132 274 15 0 0 0 - - -; #X obj 24 92 / 44100; #X obj 26 308 dac~; #X obj 154 65 t b a b; #X obj 154 128 print; #X obj 154 109 realtime; #X msg 94 100 set 0; #X obj 24 149 *~ 22050; #X obj 156 248 t f; #X obj 132 248 +; #X msg 230 231 0; #X obj 24 130 rpole~ 1; #X obj 24 198 tabread4~ zoo; #X floatatom 132 313 15 0 0 0 - - -; #X obj 132 293 / 22050; #X obj 152 188 metro 100; #X obj 152 169 loadbang; #X obj 124 178 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X connect 0 0 2 0; #X connect 3 0 11 0; #X connect 4 0 10 0; #X connect 4 0 10 1; #X connect 5 0 19 0; #X connect 6 0 9 0; #X connect 7 0 17 0; #X connect 8 0 22 0; #X connect 9 0 5 0; #X connect 11 0 13 1; #X connect 11 1 0 0; #X connect 11 2 13 0; #X connect 13 0 12 0; #X connect 14 0 19 0; #X connect 15 0 20 0; #X connect 15 0 7 0; #X connect 16 0 17 1; #X connect 17 0 8 0; #X connect 17 0 16 0; #X connect 17 0 20 1; #X connect 18 0 17 1; #X connect 19 0 15 0; #X connect 20 0 4 0; #X connect 22 0 21 0; #X connect 23 0 7 0; #X connect 23 0 14 0; #X connect 24 0 23 0; #X connect 25 0 23 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
On Mon, 29 Nov 2010, tim vets wrote: If you have to play a very large file in RAM, you can do it by emptying your signal-rate counter into a message-rate counter that takes care of the big digits while the signal-rate counter keeps on taking care of the small digits and fractions. (do you want an example ?) which afaict he didn't give an example for yet. I'm not sure what he meant, but that was what I made up of it...probably wrong :) Done... The idea is that if you want very precise [tabread4~] on large sounds, you have to do the lookup relatively to a recently looked-up point, so, at every block boundary, the newest point becomes the new reference point, such that the signal-rate read-head stays in low values (high precision), whereas the message-rate read-head does all the large motion. That way, you can get up to twice the number of precision bits (but usually less than that). ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/2010 08:40 PM, Mathieu Bouchard wrote: On Sat, 27 Nov 2010, Derek Holzer wrote: Thank you Roman, this is exactly the kind of concise and clear information I was looking for to include in the chapters on sample playback in the Pd FLOSS Manual! But that is relevant to [tabread~] and [tabread], NOT [tabread4~], which furthermore, if you only need to play back without transposing, you might also want to consider [tabplay~] (depending on your problem of course), which does not has this problem at all. fgart IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzzak8ACgkQkX2Xpv6ydvQiSwCfdb+dAzFq4rSAET5bP3C3aBoU iM8AniFQx104laXpsXIhra5NbUXXc/vU =XH3S -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
do I interpret it correct if I assume that a solution for [tabread~]-ing big files without quality loss would be to make a counter and split one big [line~] movement into small segments ? something like: [metro 100] | [f]X[+ 4410] | [s adder] and [r adder] | [t bf] | | [0, 4410 100( | |/ [line~] / | __ / [+~] | [tabread~] ? gr, Tim 2010/11/29 IOhannes m zmölnig zmoel...@iem.at -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/2010 08:40 PM, Mathieu Bouchard wrote: On Sat, 27 Nov 2010, Derek Holzer wrote: Thank you Roman, this is exactly the kind of concise and clear information I was looking for to include in the chapters on sample playback in the Pd FLOSS Manual! But that is relevant to [tabread~] and [tabread], NOT [tabread4~], which furthermore, if you only need to play back without transposing, you might also want to consider [tabplay~] (depending on your problem of course), which does not has this problem at all. fgart IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzzak8ACgkQkX2Xpv6ydvQiSwCfdb+dAzFq4rSAET5bP3C3aBoU iM8AniFQx104laXpsXIhra5NbUXXc/vU =XH3S -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
On 2010-11-29 14:45, tim vets wrote: do I interpret it correct if I assume that a solution for [tabread~]-ing big files without quality loss would be to make a counter and split one big [line~] movement into small segments ? something like: [metro 100] | [f]X[+ 4410] | [s adder] and [r adder] | [t bf] | | [0, 4410 100( | |/ [line~] / | __ / [+~] ??? you are still hitting the problem that the output of [+~] has probably to little precision. your patch will thus not give you any benefit. | [tabread~] i was _not_ talking about [tabread~] but about [tabplay~] [bang( | [tabplay~] alternatively you can use the send inlet (message!) of [tabread4~] for better precision. the help-patch directs you to B15.tabread4~-onset.pd msdfrt# IOhannes 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] big soundfiles
2010/11/29 IOhannes m zmoelnig zmoel...@iem.at On 2010-11-29 14:45, tim vets wrote: do I interpret it correct if I assume that a solution for [tabread~]-ing big files without quality loss would be to make a counter and split one big [line~] movement into small segments ? something like: [metro 100] | [f]X[+ 4410] | [s adder] and [r adder] | [t bf] | | [0, 4410 100( | |/ [line~] / | __ / [+~] ??? you are still hitting the problem that the output of [+~] has probably to little precision. your patch will thus not give you any benefit. | [tabread~] i was _not_ talking about [tabread~] but about [tabplay~] sorry if I was not clear, I was in fact thinking of Mathieu's message: If you have to play a very large file in RAM, you can do it by emptying your signal-rate counter into a message-rate counter that takes care of the big digits while the signal-rate counter keeps on taking care of the small digits and fractions. (do you want an example ?) which afaict he didn't give an example for yet. I'm not sure what he meant, but that was what I made up of it...probably wrong :) Tim [bang( | [tabplay~] alternatively you can use the send inlet (message!) of [tabread4~] for better precision. the help-patch directs you to B15.tabread4~-onset.pd msdfrt# IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
On 2010-11-29 15:15, tim vets wrote: 2010/11/29 IOhannes m zmoelnig zmoel...@iem.at sorry if I was not clear, I was in fact thinking of Mathieu's message: If you have to play a very large file in RAM, you can do it by emptying your signal-rate counter into a message-rate counter that takes care of the big digits while the signal-rate counter keeps on taking care of the small digits and fractions. (do you want an example ?) which afaict he didn't give an example for yet. I'm not sure what he meant, but that was what I made up of it...probably wrong :) yes. alternatively you can use the send inlet (message!) of [tabread4~] for better precision. the help-patch directs you to B15.tabread4~-onset.pd this is where you should start. hmnsdft IOhannes 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] big soundfiles
On Sat, 27 Nov 2010, Derek Holzer wrote: Thank you Roman, this is exactly the kind of concise and clear information I was looking for to include in the chapters on sample playback in the Pd FLOSS Manual! But that is relevant to [tabread~] and [tabread], NOT [tabread4~], which is normally used with more resolution : in the latter case, you divide the 6 minutes into the number of steps you expect to need between samples. If you play at speed 1.125, that's 9/8, so, you need 1/8 steps, so, divide 6m20s by 8. With different denominators (1.1 = 11/10) it can get complicated though. ___ | Mathieu Bouchard - Aix-en-Provence ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
That's a nice theoretical explanation Mathieu (no sarcasm intended), but let's think practical for a second. If you were going to give some simple advice to Pd newcomers about the length of a soundfile they should load to be read by [tabread4~] without noticeable distortions, what would it be? Please no what do you consider noticeable discussions, let's just think friendly suggestion ;-) D. On 11/27/10 7:40 AM, Mathieu Bouchard wrote: On Fri, 26 Nov 2010, Derek Holzer wrote: So what could the max size of a file be without losing any detail with [tabread4~]? There is no such thing... It's completely relative to the amount of detail you want to have. If you want a million points between sample 1 and sample 2 you can have them, but if you go between 100 and 101 you already can't have that anymore. If you want to be able to use sixteenths of samples, you can up to sample 1048576, but after that it's only eights, until the double of that size, etc. [tabread4~] is made to read between the samples, but there's no standard on how many points between the samples one might want... it depends on what you decide to do with the data, and the maximum error you can tolerate in that situation. Is that the hardcoded 400 elements limitation? I think that it's just so that you don't load something too big, for the typical amounts of RAM that people had back when [soundfiler] was written. ___ | Mathieu Bouchard - Aix-en-Provence -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 132: 'Remember .those quiet evenings' ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
On Sat, 2010-11-27 at 11:20 +0100, Derek Holzer wrote: That's a nice theoretical explanation Mathieu (no sarcasm intended), but let's think practical for a second. If you were going to give some simple advice to Pd newcomers about the length of a soundfile they should load to be read by [tabread4~] without noticeable distortions, what would it be? Please no what do you consider noticeable discussions, let's just think friendly suggestion ;-) I _guess_ there is probably no rule of thumb here. I also believe this is dependent on the content of the table. Consider very low frequencies: A small error in time won't lead to a small error in amplitude, whereas for high frequencies a tiny error in time will probably cause a huge error in amplitude. What I am trying to say is that the noticability is likely different with each sound file. When playing a table at Pd's native rate, you can play tables error-free with up to 16777215 samples. At 44.1kHz, this would translate to ~6min20s length in time. When using interpolation, you might have to use your ears to decide what's O.K. for you. The problem is, though, that the interpolation algorithm used in [tabread4~] some consider as bad (me included) and adds some unnecessary distortion (i.e. discontinuities in the first derivate). This makes it hard to distinguish errors introduced by precision problem from errors introduced by the 'bad' algorithm. Roman On 11/27/10 7:40 AM, Mathieu Bouchard wrote: On Fri, 26 Nov 2010, Derek Holzer wrote: So what could the max size of a file be without losing any detail with [tabread4~]? There is no such thing... It's completely relative to the amount of detail you want to have. If you want a million points between sample 1 and sample 2 you can have them, but if you go between 100 and 101 you already can't have that anymore. If you want to be able to use sixteenths of samples, you can up to sample 1048576, but after that it's only eights, until the double of that size, etc. [tabread4~] is made to read between the samples, but there's no standard on how many points between the samples one might want... it depends on what you decide to do with the data, and the maximum error you can tolerate in that situation. Is that the hardcoded 400 elements limitation? I think that it's just so that you don't load something too big, for the typical amounts of RAM that people had back when [soundfiler] was written. ___ | Mathieu Bouchard - Aix-en-Provence ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
Thank you Roman, this is exactly the kind of concise and clear information I was looking for to include in the chapters on sample playback in the Pd FLOSS Manual! Best, Derek On 11/27/10 12:02 PM, Roman Haefeli wrote: When playing a table at Pd's native rate, you can play tables error-free with up to 16777215 samples. At 44.1kHz, this would translate to ~6min20s length in time. -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 110: Lowest common denominator ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
On Fri, 26 Nov 2010, João Pais wrote: how about removing the expXXX numbers, and use only concrete floats? or is there any software reason that doesn't let that happen? I don't know what you mean. If you mean stuff like 1.31072e+6, you have to know that all numbers are represented like that internally, and never like 1310720. Except that in the internal float format, it's always with binary powers instead. The example above is written a lot more like 1.25*pow(2,20) internally. But really it's 0,10010100,010 ; that is the + sign, then 127+20, then 1.25-1. Those internal floats are somewhat more precise than the printed floats, because pd doesn't print enough digits. ___ | Mathieu Bouchard - Aix-en-Provence ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
On Fri, 26 Nov 2010, Roman Haefeli wrote: Anyway, I think the solution would be to use 64bit float as the index. In 64-bit Pd, this isn't an issue anymore (or more correct: It will be with _much_ larger tables). If using the full 64-bit range, we won't have enough RAM in year 2040 to reach the limit. That's unless we start using mmap() like crazy, to waste a lot of RAM indices (possible pointers). ___ | Mathieu Bouchard - Aix-en-Provence ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/26/2010 08:34 AM, Roman Haefeli wrote: Anyway, I think the solution would be to use 64bit float as the index. true. In 64-bit Pd, this isn't an issue anymore (or more correct: It will be with _much_ larger tables). what do you mean by 64-bit Pd? it _could_ mean 2 thing (for me): - - any (newish) Pd compiled on 64bit platform - - a Pd that uses 64bit (double-precision) floats for it's internal t_sample/t_float type, regardless of the architecture it runs on #1 is simply wrong, as all proper Pd's (that is, _not_ Pd-anywhere) use 32bit (single precision) float for numbers. so on my amd64 system, i still have the same issue #2 would be the solution, but even though i started double-ifying Pd some time ago, i haven't done anything in the last 2 years or so, which made the project stall. so Pd is not double-precision ready yet (i think it is still only the sound-generators like [phasor~] and [osc~] that are missing) masdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzvfjgACgkQkX2Xpv6ydvTMzgCfVKwuVYqCbZJFtKMnYbeW1dPk uCgAn0JH63AQddg6ZEbrHFp2y1PjGYQy =xqYd -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
Those internal floats are somewhat more precise than the printed floats, because pd doesn't print enough digits. my problem is with the printed format. sometimes it's also a problem when getting those numbers from some operation, and they have to be worked in symbols or something (don't have a concrete example). but I thought that something like that wouldn't be just a design error. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
On Fri, 2010-11-26 at 10:30 +0100, IOhannes m zmölnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/26/2010 08:34 AM, Roman Haefeli wrote: Anyway, I think the solution would be to use 64bit float as the index. true. In 64-bit Pd, this isn't an issue anymore (or more correct: It will be with _much_ larger tables). what do you mean by 64-bit Pd? it _could_ mean 2 thing (for me): - - any (newish) Pd compiled on 64bit platform - - a Pd that uses 64bit (double-precision) floats for it's internal t_sample/t_float type, regardless of the architecture it runs on #1 is simply wrong, as all proper Pd's (that is, _not_ Pd-anywhere) use 32bit (single precision) float for numbers. so on my amd64 system, i still have the same issue #2 would be the solution, but even though i started double-ifying Pd some time ago, i haven't done anything in the last 2 years or so, which made the project stall. so Pd is not double-precision ready yet (i think it is still only the sound-generators like [phasor~] and [osc~] that are missing) Thanks for the clarification. Indeed, I was believing, that Pd compiled on an amd64 maschine would operate with 64bit floating point numbers internally. Too bad, this isn't the case. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
On Fri, 26 Nov 2010, João Pais wrote: my problem is with the printed format. sometimes it's also a problem when getting those numbers from some operation, and they have to be worked in symbols or something (don't have a concrete example). but I thought that something like that wouldn't be just a design error. [makefilename %f] [gf/sprintf %f] etc ___ | Mathieu Bouchard - Aix-en-Provence ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
On 2010-11-26 04:04, Mathieu Bouchard wrote: Those internal floats are somewhat more precise than the printed floats, because pd doesn't print enough digits. ...and if you save your patch any floats in it will be printed out the same way so you end up with effectively about 24-bit floats next time you open it. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
So what could the max size of a file be without losing any detail with [tabread4~]? Is that the hardcoded 400 elements limitation? D. On 11/25/10 1:52 PM, Mathieu Bouchard wrote: On Tue, 23 Nov 2010, Derek Holzer wrote: And keep in mind that sound quality goes down as file size goes up. This is because of the interpolation. You might do better cutting your file up and putting it into several different arrays. If you play at normal speed with [tabread~] (not 4), you hit that problem anyway at index 16777216, and it's not because of any interpolation. However, if you do use [tabread4~] with fractional floats, you hit the problem at much lower indices, because fractions disappear gradually first, then odd numbers disappear, etc. Overall, it's because for a float, the numerator has to be between 8388608 and 16777215, while the denominator (or the multiplier) is a power of two... so each time you cross a new power of two, you lose half of the details, as the tiniest steps double in size. -- Derek Holzer http://www.umatic.nl http://blog.myspace.com/macumbista ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
On Fri, 26 Nov 2010, Derek Holzer wrote: So what could the max size of a file be without losing any detail with [tabread4~]? There is no such thing... It's completely relative to the amount of detail you want to have. If you want a million points between sample 1 and sample 2 you can have them, but if you go between 100 and 101 you already can't have that anymore. If you want to be able to use sixteenths of samples, you can up to sample 1048576, but after that it's only eights, until the double of that size, etc. [tabread4~] is made to read between the samples, but there's no standard on how many points between the samples one might want... it depends on what you decide to do with the data, and the maximum error you can tolerate in that situation. Is that the hardcoded 400 elements limitation? I think that it's just so that you don't load something too big, for the typical amounts of RAM that people had back when [soundfiler] was written. ___ | Mathieu Bouchard - Aix-en-Provence ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
On Tue, 23 Nov 2010, Derek Holzer wrote: And keep in mind that sound quality goes down as file size goes up. This is because of the interpolation. You might do better cutting your file up and putting it into several different arrays. If you play at normal speed with [tabread~] (not 4), you hit that problem anyway at index 16777216, and it's not because of any interpolation. However, if you do use [tabread4~] with fractional floats, you hit the problem at much lower indices, because fractions disappear gradually first, then odd numbers disappear, etc. Overall, it's because for a float, the numerator has to be between 8388608 and 16777215, while the denominator (or the multiplier) is a power of two... so each time you cross a new power of two, you lose half of the details, as the tiniest steps double in size. ___ | Mathieu Bouchard - Aix-en-Provence ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
On Tue, 23 Nov 2010, Derek Holzer wrote: And keep in mind that sound quality goes down as file size goes up. This is because of the interpolation. You might do better cutting your file up and putting it into several different arrays. Oh, and isn't it the case that [tabread~] 0.42 has an extra inlet for the purpose of getting more precision ? The read point is now relative to a message-rate setting. If you have to play a very large file in RAM, you can do it by emptying your signal-rate counter into a message-rate counter that takes care of the big digits while the signal-rate counter keeps on taking care of the small digits and fractions. (do you want an example ?) ___ | Mathieu Bouchard - Aix-en-Provence ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
Yes please! D. On 11/25/10 1:57 PM, Mathieu Bouchard wrote: On Tue, 23 Nov 2010, Derek Holzer wrote: And keep in mind that sound quality goes down as file size goes up. This is because of the interpolation. You might do better cutting your file up and putting it into several different arrays. Oh, and isn't it the case that [tabread~] 0.42 has an extra inlet for the purpose of getting more precision ? The read point is now relative to a message-rate setting. If you have to play a very large file in RAM, you can do it by emptying your signal-rate counter into a message-rate counter that takes care of the big digits while the signal-rate counter keeps on taking care of the small digits and fractions. (do you want an example ?) ___ | Mathieu Bouchard - Aix-en-Provence -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 189: You are an engineer ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
how about removing the expXXX numbers, and use only concrete floats? or is there any software reason that doesn't let that happen? On Tue, 23 Nov 2010, Derek Holzer wrote: And keep in mind that sound quality goes down as file size goes up. This is because of the interpolation. You might do better cutting your file up and putting it into several different arrays. Oh, and isn't it the case that [tabread~] 0.42 has an extra inlet for the purpose of getting more precision ? The read point is now relative to a message-rate setting. If you have to play a very large file in RAM, you can do it by emptying your signal-rate counter into a message-rate counter that takes care of the big digits while the signal-rate counter keeps on taking care of the small digits and fractions. (do you want an example ?) ___ | Mathieu Bouchard - Aix-en-Provence ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
On Fri, 2010-11-26 at 02:10 +0100, João Pais wrote: how about removing the expXXX numbers, and use only concrete floats? ? Can you elaborate on this? What are 'expXXX' numbers and what are 'concrete floats'? Anyway, I think the solution would be to use 64bit float as the index. In 64-bit Pd, this isn't an issue anymore (or more correct: It will be with _much_ larger tables). Roman or is there any software reason that doesn't let that happen? On Tue, 23 Nov 2010, Derek Holzer wrote: And keep in mind that sound quality goes down as file size goes up. This is because of the interpolation. You might do better cutting your file up and putting it into several different arrays. Oh, and isn't it the case that [tabread~] 0.42 has an extra inlet for the purpose of getting more precision ? The read point is now relative to a message-rate setting. If you have to play a very large file in RAM, you can do it by emptying your signal-rate counter into a message-rate counter that takes care of the big digits while the signal-rate counter keeps on taking care of the small digits and fractions. (do you want an example ?) ___ | Mathieu Bouchard - Aix-en-Provence ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles [interpolation]
Hi Ronni, like I said, it has to do with interpolation. I'm working on a chapter for the Pd FLOSS Manual about soundfiles now, but here is the short version... math gurus on the list please correct me if I am wrong since this will likely end up in that chapter! When you play back the samples in the array at the same rate that they were recorded, then Pd doesn't have a lot of work to do since it just reads back the values. However, when you play them back at a different rate, for example by reading a 44.1K sample at 48K, then Pd often has to interpolate (i.e. guess the missing values in between the samples) in order to create the audio. That is what the 4 in [tabread4~] means: 4 point interpolation which uses the 4 nearest values to calculate any value which might fall in between two samples. Super-geek explanation by Miller here: http://www-crca.ucsd.edu/~msp/techniques/v0.11/book-html/node31.html Here is the part where I know the answer but not the explanation, however... but the larger the soundfile you load into an array, the lower the quality of the interpolation. Can someone fill *me* in on this so I can write intelligently about it in the FLOSS Manual? Best, Derek On 11/24/10 2:57 AM, ronni montoya wrote: hi derek , can you explain me why does sound qualit goes own as file size goes up? Is that something particular in pd? -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 117: Make it more sensual ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles [interpolation]
On Wed, 2010-11-24 at 11:28 +0100, Derek Holzer wrote: Hi Ronni, like I said, it has to do with interpolation. I'm working on a chapter for the Pd FLOSS Manual about soundfiles now, but here is the short version... math gurus on the list please correct me if I am wrong since this will likely end up in that chapter! When you play back the samples in the array at the same rate that they were recorded, then Pd doesn't have a lot of work to do since it just reads back the values. However, when you play them back at a different rate, for example by reading a 44.1K sample at 48K, then Pd often has to interpolate (i.e. guess the missing values in between the samples) in order to create the audio. That is what the 4 in [tabread4~] means: 4 point interpolation which uses the 4 nearest values to calculate any value which might fall in between two samples. Super-geek explanation by Miller here: http://www-crca.ucsd.edu/~msp/techniques/v0.11/book-html/node31.html Here is the part where I know the answer but not the explanation, however... but the larger the soundfile you load into an array, the lower the quality of the interpolation. Can someone fill *me* in on this so I can write intelligently about it in the FLOSS Manual? I guess, you bring in two different problems here. First problem: You want to know the value of a signal at an exact point in time s(t), but you only have values stored for the nearby samples s(n) and s(n+1). Depending on the algorithm used, you can calculate a more or less accurate value for s(t) by taking into account the nearby points and assume a certain path for the curve going trough all points. This problem applies also to small tables (not only big ones). If you're playing a sample at the native rate of Pd, s(t) is always matching s(n) and no interpolation error is introduced, as you already stated. The second problem is: You can't even express the exact point in time, when the t in s(t) is a very huge number, because t is expressed as a 32-bit floating point number. Please someone correct me, if wrong, but above a certain value (2^24-1=16777215, I guess) you cannot even represent every integer with the 32-bit floating point format used by Pd. So, even when playing a sample with Pd's own samplerate, it only works nice up to a certain table size. When you play samples 'behind' that magic number, every second sample is played for the time of two samples. If you play a sample at a different speed than Pd's rate, the error starts much earlier and increases over time. This is because the higher the number is to index a certain sample, the less values between two sub-sequent integers are available, so the difference between the value you meant and the value that can be represented might increase. Check also this thread: http://lists.puredata.info/pipermail/pd-list/2007-09/053463.html I hope, I didn't cause more confusion. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles [interpolation]
Yes, it was the second point that I couldn't articulate. Thanks! D. On 11/24/10 1:56 PM, Roman Haefeli wrote: On Wed, 2010-11-24 at 11:28 +0100, Derek Holzer wrote: Hi Ronni, like I said, it has to do with interpolation. I'm working on a chapter for the Pd FLOSS Manual about soundfiles now, but here is the short version... math gurus on the list please correct me if I am wrong since this will likely end up in that chapter! When you play back the samples in the array at the same rate that they were recorded, then Pd doesn't have a lot of work to do since it just reads back the values. However, when you play them back at a different rate, for example by reading a 44.1K sample at 48K, then Pd often has to interpolate (i.e. guess the missing values in between the samples) in order to create the audio. That is what the 4 in [tabread4~] means: 4 point interpolation which uses the 4 nearest values to calculate any value which might fall in between two samples. Super-geek explanation by Miller here: http://www-crca.ucsd.edu/~msp/techniques/v0.11/book-html/node31.html Here is the part where I know the answer but not the explanation, however... but the larger the soundfile you load into an array, the lower the quality of the interpolation. Can someone fill *me* in on this so I can write intelligently about it in the FLOSS Manual? I guess, you bring in two different problems here. First problem: You want to know the value of a signal at an exact point in time s(t), but you only have values stored for the nearby samples s(n) and s(n+1). Depending on the algorithm used, you can calculate a more or less accurate value for s(t) by taking into account the nearby points and assume a certain path for the curve going trough all points. This problem applies also to small tables (not only big ones). If you're playing a sample at the native rate of Pd, s(t) is always matching s(n) and no interpolation error is introduced, as you already stated. The second problem is: You can't even express the exact point in time, when the t in s(t) is a very huge number, because t is expressed as a 32-bit floating point number. Please someone correct me, if wrong, but above a certain value (2^24-1=16777215, I guess) you cannot even represent every integer with the 32-bit floating point format used by Pd. So, even when playing a sample with Pd's own samplerate, it only works nice up to a certain table size. When you play samples 'behind' that magic number, every second sample is played for the time of two samples. If you play a sample at a different speed than Pd's rate, the error starts much earlier and increases over time. This is because the higher the number is to index a certain sample, the less values between two sub-sequent integers are available, so the difference between the value you meant and the value that can be represented might increase. Check also this thread: http://lists.puredata.info/pipermail/pd-list/2007-09/053463.html I hope, I didn't cause more confusion. Roman -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 54: Do something sudden, destructive and unpredictable ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
didn't know about that, which interpolation are you speaking about? in the table everything should be correct, right? do you have any precise description of that problem? And keep in mind that sound quality goes down as file size goes up. This is because of the interpolation. You might do better cutting your file up and putting it into several different arrays. D. On 11/23/10 4:16 AM, Hans-Christoph Steiner wrote: Check the help patch for soundfiler, you'll need to use the -maxsize flag in your [read( message and set it to something bigger. .hc On Nov 22, 2010, at 8:24 PM, ronni montoya wrote: hello, when i load a big .wav file with sounfiler i get this message: soundfiler_read: truncated to 400 elements ? -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
Check the replies. I have definitely noticed longer soundfiles having lower quality when designing ParticleChamber, for example. Newer versions of this (unreleased so far, too many bugs...) allowed pitch shifting, which is where I noticed the artifacts. Longer soundfiles started to sound more grainy than shorter ones when played back in whole or in part at other-than-recorded sample rates. D. On 11/24/10 11:54 PM, João Pais wrote: didn't know about that, which interpolation are you speaking about? in the table everything should be correct, right? do you have any precise description of that problem? And keep in mind that sound quality goes down as file size goes up. This is because of the interpolation. You might do better cutting your file up and putting it into several different arrays. D. On 11/23/10 4:16 AM, Hans-Christoph Steiner wrote: Check the help patch for soundfiler, you'll need to use the -maxsize flag in your [read( message and set it to something bigger. .hc On Nov 22, 2010, at 8:24 PM, ronni montoya wrote: hello, when i load a big .wav file with sounfiler i get this message: soundfiler_read: truncated to 400 elements ? -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 159: Tidy up ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/23/2010 04:04 AM, Bernardo Barros wrote: how big? if it is really big (2gb), maybe you may try wave64 format. you may, but Pd proper does not support anything like that. [readanysf~] may be able to read them though. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzrdOoACgkQkX2Xpv6ydvQrQgCfa8lZbetuiG6Qn6ugA4rH6+RR jtMAoJQ/rR1XpzhU469vzse9pno8Dzlp =fIwu -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
I usually use the [wavinfo] to know how big a file is, and then maxsize $1 to set an array to the necessary size. Maybe it would make sense to remove this 4M samples boundary from Pd? there are more and more people for whom that's just in the way. João Check the help patch for soundfiler, you'll need to use the -maxsize flag in your [read( message and set it to something bigger. .hc On Nov 22, 2010, at 8:24 PM, ronni montoya wrote: hello, when i load a big .wav file with sounfiler i get this message: soundfiler_read: truncated to 400 elements ? and i cant load the complety sound , just a part. Is there any way of loading complete .wav files? thanks R. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Using ReBirth is like trying to play an 808 with a long stick.-David Zicarelli ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
And keep in mind that sound quality goes down as file size goes up. This is because of the interpolation. You might do better cutting your file up and putting it into several different arrays. D. On 11/23/10 4:16 AM, Hans-Christoph Steiner wrote: Check the help patch for soundfiler, you'll need to use the -maxsize flag in your [read( message and set it to something bigger. .hc On Nov 22, 2010, at 8:24 PM, ronni montoya wrote: hello, when i load a big .wav file with sounfiler i get this message: soundfiler_read: truncated to 400 elements ? -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 132: 'Remember .those quiet evenings' ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
I think iemlib/soundfile_info is less buggy than ext13/wavinfo these days. .hc On Nov 23, 2010, at 3:44 AM, João Pais wrote: I usually use the [wavinfo] to know how big a file is, and then maxsize $1 to set an array to the necessary size. Maybe it would make sense to remove this 4M samples boundary from Pd? there are more and more people for whom that's just in the way. João Check the help patch for soundfiler, you'll need to use the - maxsize flag in your [read( message and set it to something bigger. .hc On Nov 22, 2010, at 8:24 PM, ronni montoya wrote: hello, when i load a big .wav file with sounfiler i get this message: soundfiler_read: truncated to 400 elements ? and i cant load the complety sound , just a part. Is there any way of loading complete .wav files? thanks R. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] big soundfiles
hello, when i load a big .wav file with sounfiler i get this message: soundfiler_read: truncated to 400 elements ? and i cant load the complety sound , just a part. Is there any way of loading complete .wav files? thanks R. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
how big? if it is really big (2gb), maybe you may try wave64 format. 2010/11/22 ronni montoya ronni.mont...@gmail.com: hello, when i load a big .wav file with sounfiler i get this message: soundfiler_read: truncated to 400 elements ? and i cant load the complety sound , just a part. Is there any way of loading complete .wav files? thanks R. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] big soundfiles
Check the help patch for soundfiler, you'll need to use the -maxsize flag in your [read( message and set it to something bigger. .hc On Nov 22, 2010, at 8:24 PM, ronni montoya wrote: hello, when i load a big .wav file with sounfiler i get this message: soundfiler_read: truncated to 400 elements ? and i cant load the complety sound , just a part. Is there any way of loading complete .wav files? thanks R. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
