And that's not the end of the vicious cycle.
Students who saved their money to buy a Max license are often unwilling
to
accept that their work could have been done as easy in Pd, and
sometimes even
better and/or easier.
If you think of free
software as an ethical issue like I do and are
very nice, bookmarked! :)
athos
On 11 January 2012 14:55, Pierre Massat pimas...@gmail.com wrote:
Dear List,
I wanted to let you know that i'm writing a blog called GuitarExtended.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management
On Fri, 2012-01-13 at 11:09 +0100, João Pais wrote:
Hi,
another pitfall, after selecting a receive-send pair, if you click another
receive, the last selected send will still be active, and the connection
will be made with only 1 click. Or maybe this is more clear:
- create in receive
Le 2012-01-13 à 10:46:00, João Pais a écrit :
and you're only talking about the aesthetical/workflow features. to bring up
a subject that I am paying attention only now, try out to see how high you go
with [expr pow(2,$f1)] until you loose resolution - 20 in pd, but 30 in max5
(the coming up
Le 2012-01-13 à 08:05:00, Mathieu Bouchard a écrit :
Neither binary nor decimal representation is more precise than the other,
it's just that their precision never matches exactly. 20 bits is slightly
less than 6 decimals, whereas 16 decimals is slightly more than 53 bits. Thus
you can only
But whatever the theoretical precision of a float, I think the thing
that makes Pd floats less precise than Max floats lies in the use of the
%g format specifier to print them out, which can result in a lower
precision than the float is capable of. This makes it possible to use
maximum
Hi,
João Pais wrote:
see how high you go with [expr pow(2,$f1)] until you loose
resolution - 20 in pd, but 30 in max5 (the coming up of Pd double
precision will help this, but it's a work Katja is doing alone).
High moral feeling (i.e. the we're better because we're free logo)
isn't enough
and you're only talking about the aesthetical/workflow features. to
bring up
a subject that I am paying attention only now, try out to see how high
you go
with [expr pow(2,$f1)] until you loose resolution - 20 in pd, but 30 in
max5
(the coming up of Pd double precision will help this, but
João Pais wrote:
see how high you go with [expr pow(2,$f1)] until you loose
resolution - 20 in pd, but 30 in max5 (the coming up of Pd double
precision will help this, but it's a work Katja is doing alone).
High moral feeling (i.e. the we're better because we're free logo)
isn't enough for
Looking forward to the first installment!
On Jan 13, 2012 2:11 AM, athos bacchiocchi athos.bacchioc...@gmail.com
wrote:
very nice, bookmarked! :)
athos
On 11 January 2012 14:55, Pierre Massat pimas...@gmail.com wrote:
Dear List,
I wanted to let you know that i'm writing a blog called
Le 2012-01-13 à 16:10:00, João Pais a écrit :
I already have an abstraction in pd to automatically set the offset to
play segments with tabread4~. But if I need e.g. to play indices
1 to 10111, which are read from an array, and then rescaled
in the meantime, how is it possible to
Paywares or freeware same problem,
for example, you can not load more than 4g into RAM with ableton live because
it's 32bit,
also the error message for out memory only come with the last release, so live
was crashing but without knowing
what's happening during more than ten years.
This problem
- Original Message -
From: Mathieu Bouchard ma...@artengine.ca
To: João Pais jmmmp...@googlemail.com
Cc: Max abonneme...@revolwear.com; Jonathan Wilkes jancs...@yahoo.com; pd
list pd-list@iem.at; Ben Baker-Smith bbakersm...@gmail.com
Sent: Friday, January 13, 2012 1:35 PM
Le 2012-01-13 à 11:14:00, Jonathan Wilkes a écrit :
From: Mathieu Bouchard ma...@artengine.ca
For [tabread~], yes, because they're below 16777216.
With Katja'sdouble-precision Pd does this problem go away?
If it does what I think it does, Katja's build reduces the problem by a
factor of
Le 2012-01-13 à 09:06:00, Martin Peach a écrit :
But whatever the theoretical precision of a float, I think the thing that
makes Pd floats less precise than Max floats lies in the use of the %g format
specifier to print them out, which can result in a lower precision than the
float is capable
I think Pd uses %g which probably means %.6g by default, but it looks more like
%.5g.
You're right, the precision is only lost when the patcher is written out
somewhere.
In the attached patcher clicking on [1( calculates pi, which gets printed to a
number box and the screen in 5 digit
Here's a more complete example of the precision thing.
Martin
#N canvas 364 685 450 300 10;
#X msg 32 18 1;
#X obj 32 44 atan;
#X obj 32 68 * 4;
#X floatatom 92 85 15 0 0 0 - - -;
#X obj 111 164 sin;
#X floatatom 160 181 15 0 0 0 - - -;
#X obj 111 214
Le 2012-01-13 à 20:12:00, martin.pe...@sympatico.ca a écrit :
In the attached patcher clicking on [1( calculates pi, which gets
printed to a number box and the screen in 5 digit precision as 3.14159,
but the subsequent [sin] object gives a value much closer to zero than
when you click on
18 matches
Mail list logo
