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
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
-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
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]
|
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]
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
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
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
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?
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
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
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
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
-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
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
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
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
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
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.
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
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
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
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.
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
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,
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
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
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,
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
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
-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
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
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
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
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.
___
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.
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
37 matches
Mail list logo
