Re: [PD] Horizontal Connections (Was: Re: style guide idea: [send

[Mathieu Bouchard]

On Sun, 22 Mar 2009, Matt Barber wrote:


must connect to the left-most inlet of the lower object.  Reverse if
the connection travels from right to left.  The problem is there's no
good way to tell if a patch adheres to the agreement.


There's never a good way to do that. I remember losing an hour or so 
trying to debug a patch to finally realise I had two identical objects 
exactly on top of each other and that my patch was using the first's 
inlets and the second's outlet. No wonder no message got sent through.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [import]ing libdirs from places other than extra/?

[Hans-Christoph Steiner]

Its quite appalling that I didn't see this until now.  I was super  
busy back in Sept and I guess i never saw this again until now.   
Anyway, I fixed it, so the fix will be included in the nightly builds:


http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=10895

For future reference, feel free to nag me on this kind of thing.

.hc

On Sep 18, 2008, at 7:24 AM, Luke Iannini wrote:


Hi hans/all,
I'm trying to switch my entire library of patches over to [import] and
removing everything from my path to decrease loading time of my very
nested patches.

Everything worked great for the libdirs in extra (in the
Pd-extended.app bundle), but I'm not having any luck [import]ing from
anywhere else (i.e. my personal patch collection).  According to
http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files-with-pd-extended
, I was under the impression I could add libdirs (which I have added
-meta.pd files to) to ~/Library/Pd or /Library/Pd and [import] would
find them.

But, I'm unable to instantiate any of the patches in my libdirs after
doing this and [import]ing them.

[import] does not, at least, complain, when I instantiate it
(i.e. I get "libdir_loader: added 'Concepts' to the canvas-local
objectclass path" rather than "error: [import]: ERROR: can't load
library in 'Concepttt'")
so, something is working.

Moving my directories into extra/ fixes the problem, but I'd rather  
not do that!


Also, is it defined at a source level that ~/Library/Pd and
/Library/Pd are the only places libdirs can be loaded from (I couldn't
find it i so)?  Or, is is just that every folder in the global path is
searched for libdirs (or, at least, is that how it's meant to be)?

Cheers
Luke

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






"[W]e have invented the technology to eliminate scarcity, but we are  
deliberately throwing it away to benefit those who profit from  
scarcity."-John Gilmore




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

Re: [PD] [equalizer] / [lowshelf] / [highshelf] in purepd!

[hard off]

cheers.  very useful!

silly question probably, but is biquad~ 100% vanilla?  or is it sort of
'caramel' like expr ??
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] [equalizer] / [lowshelf] / [highshelf] in purepd!

[dmotd]

hi folks,

here are some purepd representations of the [equalizer] [lowshelf] and 
[highshelf] objects for calculating eq biquad filter coefficients. i put 
these together as ggee was the only external lib dependency for a project 
which used these fairly extensively. the code is almost logic identical to 
the equivelent C internals, and i have avoided using [expr], so the math may 
look a little confusing.

i only ported the code for the objects i was using, but i will add the other 
eq-cookbook filters when i next get a chance.

ciao,
dmotd
#N canvas 266 16 753 711 10;
#X obj 106 12 inlet;
#X obj 475 193 inlet;
#X obj 628 127 inlet;
#X obj 176 609 outlet;
#X text 129 166 freq;
#X text 223 181 rate;
#X text 519 192 gain;
#X text 674 129 bw;
#X obj 618 172 * 0.01;
#N canvas 350 419 450 300 e_A 0;
#X obj 145 134 pow;
#X obj 147 32 inlet;
#X obj 179 87 / 40;
#X obj 148 58 t b f;
#X msg 132 84 10;
#X obj 144 173 outlet;
#X text 191 34 gain;
#X connect 0 0 5 0;
#X connect 1 0 3 0;
#X connect 2 0 0 1;
#X connect 3 0 4 0;
#X connect 3 1 2 0;
#X connect 4 0 0 0;
#X restore 447 252 pd e_A;
#N canvas 598 23 450 300 e_omega 0;
#N canvas 0 0 450 300 pi 0;
#X obj 108 54 inlet;
#X obj 158 127 * 4;
#X obj 158 106 atan 1;
#X msg 158 85 1;
#X obj 109 187 outlet;
#X obj 158 51 loadbang;
#X obj 107 157 f;
#X connect 0 0 6 0;
#X connect 1 0 6 1;
#X connect 2 0 1 0;
#X connect 3 0 2 0;
#X connect 5 0 3 0;
#X connect 6 0 4 0;
#X restore 141 124 pd pi;
#X obj 109 15 inlet;
#X obj 228 86 inlet;
#X obj 206 117 /;
#X obj 89 161 *;
#X msg 85 102 2;
#X obj 109 44 t b b f;
#X obj 119 202 *;
#X obj 119 237 outlet;
#X text 156 14 freq;
#X text 272 88 rate;
#X connect 0 0 4 1;
#X connect 1 0 6 0;
#X connect 2 0 3 1;
#X connect 3 0 7 1;
#X connect 4 0 7 0;
#X connect 5 0 4 0;
#X connect 6 0 5 0;
#X connect 6 1 0 0;
#X connect 6 2 3 0;
#X connect 7 0 8 0;
#X restore 177 256 pd e_omega;
#X obj 446 226 f;
#X obj 339 36 t b b b b;
#X obj 339 12 loadbang;
#X obj 26 69 f \$1;
#X obj 436 191 f \$2;
#X obj 591 129 f \$3;
#X obj 55 114 > 0;
#X obj 25 115 t f;
#X obj 25 139 spigot;
#X obj 25 91 t f f;
#X obj 100 165 f;
#X msg 259 178 44100;
#N canvas 88 11 435 376 e_beta 0;
#X obj 265 155 inlet;
#X obj 86 39 inlet;
#X obj 118 325 outlet;
#X text 131 38 a;
#X text 309 156 S;
#X obj 116 295 sqrt;
#X obj 115 249 -;
#X obj 98 64 t f f;
#X obj 191 86 - 1;
#X obj 199 113 t f f;
#X obj 200 145 *;
#X obj 96 103 t f f;
#X obj 96 133 *;
#X obj 94 163 + 1;
#X obj 93 189 /;
#X connect 0 0 14 1;
#X connect 1 0 7 0;
#X connect 5 0 2 0;
#X connect 6 0 5 0;
#X connect 7 0 11 0;
#X connect 7 1 8 0;
#X connect 8 0 9 0;
#X connect 9 0 10 0;
#X connect 9 1 10 1;
#X connect 10 0 6 1;
#X connect 11 0 12 0;
#X connect 11 1 12 1;
#X connect 12 0 13 0;
#X connect 13 0 14 0;
#X connect 14 0 6 0;
#X restore 557 345 pd e_beta;
#X obj 420 306 t f f;
#X text 342 530 b0;
#X text 444 532 b2;
#X text 500 532 a0;
#X text 290 531 a2;
#X text 388 530 b1;
#X text 237 530 a1;
#N canvas 0 39 788 682 check_stability 0;
#X obj 163 27 inlet;
#X obj 335 46 inlet;
#X obj 385 46 inlet;
#X obj 435 46 inlet;
#X obj 485 46 inlet;
#X obj 535 46 inlet;
#X obj 585 46 inlet;
#X obj 351 132 f;
#X obj 442 129 f;
#X text 363 151 b0;
#X obj 389 130 f;
#X obj 228 124 f;
#X text 463 145 b2;
#X obj 537 125 f;
#X obj 286 128 f;
#X text 550 148 a0;
#X text 292 148 a2;
#X text 406 150 b1;
#X text 234 145 a1;
#X obj 164 82 t b b b b b b;
#X obj 361 234 /;
#X obj 314 232 /;
#X obj 230 194 * -1;
#X obj 282 197 * -1;
#X text 311 253 fb1;
#X text 356 256 fb2;
#X obj 86 293 t f f;
#X obj 92 321 *;
#X obj 105 345 + 4;
#X obj 126 369 *;
#X text 25 397 discriminant;
#X obj 133 473 >= -1;
#X obj 131 454 f;
#X obj 126 396 < 0;
#X obj 126 418 select 1;
#X obj 131 497 select 1;
#X text 63 510 stable ->;
#X obj 198 260 t f f f;
#X obj 326 272 t f f f f;
#X obj 311 448 bang;
#X text 245 487 stable ->;
#X obj 549 261 pack f f f f f f;
#X obj 519 261 f;
#X obj 548 646 outlet;
#X msg 242 571 filter unstable -> resetting;
#X obj 242 595 print equ;
#N canvas 0 0 677 568 real 0;
#X obj 75 59 inlet;
#X obj 186 58 inlet;
#X obj 324 52 inlet;
#X text 226 56 fb1;
#X text 373 52 fb2;
#X obj 71 320 <= 2;
#X obj 149 320 >= -2;
#X obj 146 158 f;
#X obj 366 158 f;
#X msg 237 275 1;
#X obj 237 297 -;
#X obj 255 325 -;
#X obj 237 249 t b f;
#X obj 78 111 t b b;
#X obj 249 348 >= 0;
#X msg 362 279 1;
#X obj 380 329 -;
#X obj 362 253 t b f;
#X obj 373 351 >= 0;
#X obj 362 301 +;
#X obj 249 390 +;
#X obj 148 408 +;
#X obj 75 427 +;
#X obj 75 450 == 4;
#X obj 127 187 t f f f f;
#X obj 386 190 t f f;
#X obj 71 479 select 1;
#X obj 71 516 outlet;
#X text 123 521 pass;
#X obj 199 516 bang;
#X obj 199 538 outlet;
#X text 251 539 fail;
#X connect 0 0 13 0;
#X connect 1 0 7 1;
#X connect 2 0 8 1;
#X connect 5 0 22 0;
#X connect 6 0 21 0;
#X connect 7 0 24 0;
#X connect 8 0 25 0;
#X connect 9 0 10 0;
#X connect 10 0 11 0;
#X connect 11 0 14 0;
#X connect 12 0 9 0;
#X connect 12 1 10 1;
#X connect 13 0 7 0;
#X connect 13 1 8 0;
#X connect 14 0 20 0;
#

Re: [PD] Problems compiling zexy

[Martin Hiendl]

Sorry again, but it didn't work for me.

So, I already use Pd 0.42-4.
But anyway, I tried it then with 0.41-0 and also with the "#!/bin/bash"
with the same result: The whole process always stops after 'make' with
this error:

"gcc -I.  -DHAVE_CONFIG_H -DZEXY_LIBRARY -DPD   -g -O2 -mms-bitfields
-fPIC -mfpmath=sse -msse  -c -o tabdump.o tabdump.c
tabdump.c: In function ‘tabdump_bang’:
tabdump.c:57: error: incompatible types in assignment
make: *** [tabdump.o] Error 1
x...@xyz:~/install/zexy/src$"

I updated my copy to this:

"At revision 10894."

Should I post the whole log after "autoconf", "./configure" and
"make"...?

Thanks,
Martin
-Original Message-
From: IOhannes m zmoelnig 
To: Martin Hiendl 
Cc: pd-list@iem.at
Subject: Re: [PD] Problems compiling zexy
Date: Mon, 23 Mar 2009 14:41:05 +0100

Martin Hiendl wrote:
> Thanks for your answer but unfortunately it didn't work for me.
> 
> I downloaded the svn and edited the makealias.sh to "#!/bin/bash".
> But after "make", I received this:

i just noticed that i was a bit too paranoid when doing checks for the 
used Pd-version: it required at least 0.42

i have fixed it now to only require Pd 0.41
(and yes, this means that you must use Pd-0.41 for compilation of zexy 
on 64bit; you don't want anything lower when running on a 64bit machine 
anyhow)

please update your working copy of zexy by running "svn up"


mfd
IOhannes


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

Re: [PD] Horizontal Connections (Was: Re: style guide idea: [send

[Martin Peach]

Mathieu Bouchard wrote:

On Sun, 22 Mar 2009, Martin Peach wrote:

 I like the usage agreement idea, as long as there's visual 
feedback. For example, if the inlets and outlets in pd-ext protruded 
one or two pixels, you'd be able to see the connection crossing over 
to the "wrong" outlet.

Maybe better if outlets with connections were coloured differently.


Why not just colour the wire itself!

Even if you connect the other outlets in various horizontal ways, you'll 
still be able to see the one wire crossing over a bunch of outlets... if 
it's only one wire.


If you need to see several wires... they could be coloured using random 
colours.




Exactly. I already proposed a patch to do that a couple of years ago but 
it didn't get picked up.


Martin


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

Re: [PD] default [output~] in Pd-extended

[Hans-Christoph Steiner]

On Mar 23, 2009, at 4:09 AM, IOhannes m zmoelnig wrote:


Hans-Christoph Steiner wrote:

So if we are introducing the concept of objects and GUI in Pd, then  
I think it is safe to use GOP objects.  After all, we don't expect  
newbies to know anything about C or Tcl, but that's under it it  
all.  I don't think we should add an output~ to help patches that  
don't already have them.  I just think we should have a more  
intuitive and usable output~.  The current one already uses GOP, so  
that's not a change.


i fully agree.
and would like to stress, that i am pretty sure that most users will  
not have a clue about gop when they first encounter the [output~]  
module (be it a new one or the original one).


at least i cannot seem to find any documentation about gop prior to  
3/A.05; nevertheless i think it is a good idea to use a gop- 
abstraction here.


fgmasdr
IOhannes



Anyone else want to weigh in on this?  I'd like to lobby Miller to get  
this included in 'extra' at least, then also used in the help and  
docmentation.



.hc



Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.  Now that he can realize them, he must either  
change them, or perish.-William Carlos Williams




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

Re: [PD] Horizontal Connections (Was: Re: style guide idea: [send

[Mathieu Bouchard]

On Sun, 22 Mar 2009, Martin Peach wrote:

 I like the usage agreement idea, as long as there's visual feedback. 
For example, if the inlets and outlets in pd-ext protruded one or two 
pixels, you'd be able to see the connection crossing over to the "wrong" 
outlet.

Maybe better if outlets with connections were coloured differently.


Why not just colour the wire itself!

Even if you connect the other outlets in various horizontal ways, you'll 
still be able to see the one wire crossing over a bunch of outlets... if 
it's only one wire.


If you need to see several wires... they could be coloured using random 
colours.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] variance from mapping library

[Mathieu Bouchard]

On Mon, 23 Mar 2009, Mathieu Bouchard wrote:

Here is another patch. I call it [mapping/variance2]. It computes a moving 
variance using exactly the $1 last values and not any more than that. It has 
more rounding error, but it doesn't have any unwanted delay between the two 
moving averages used in computing variance.


Well actually, my [mapping/variance2] also doesn't have the same drift 
characteristics (nor other error characteristics) as [mapping/variance], 
so, my examples about [mapping/variance] don't drift when remade with 
[mapping/variance2], but some other examples (that I didn't show) are 
worse with [mapping/variance2].


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] variance from mapping library

[Mathieu Bouchard]

On Mon, 23 Mar 2009, Mathieu Bouchard wrote:

You can send simple repeated sequences to [mapping/variance] to show that not 
only it can drift in the negative values almost endlessly, but it doesn't 
even compute the variance of N values.


Here is another patch. I call it [mapping/variance2]. It computes a moving 
variance using exactly the $1 last values and not any more than that. It 
has more rounding error, but it doesn't have any unwanted delay between 
the two moving averages used in computing variance.


#N canvas 744 170 273 272 10;
#X obj 39 33 inlet;
#X obj 39 184 outlet;
#X obj 39 52 t f f;
#X obj 39 165 -;
#X obj 39 83 t f f;
#X obj 39 111 *;
#X obj 39 130 mean_n \$1;
#X obj 114 81 mean_n \$1;
#X obj 114 101 t f f;
#X obj 114 129 *;
#X connect 0 0 2 0;
#X connect 2 0 4 0;
#X connect 2 1 7 0;
#X connect 3 0 1 0;
#X connect 4 0 5 0;
#X connect 4 1 5 1;
#X connect 5 0 6 0;
#X connect 6 0 3 0;
#X connect 7 0 8 0;
#X connect 8 0 9 0;
#X connect 8 1 9 1;
#X connect 9 0 3 1;

 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] variance from mapping library

[cyrille henry]

Mathieu Bouchard a écrit :

On Thu, 19 Mar 2009, Oded Ben-Tal wrote:

...


For the "mapping" library, there isn't much of a choice but to remake it 
with a slower algorithm, unless someone knows a magic trick for 
cancelling almost all of the error while not running so slow. 


no need to remake an other mean_n object using a beter but slower algorythm.
you just have to send a [mode 1< message to mean_n : it does switch the 
internal algo used to a more accurate one.

i just add this message to the variance object...

Cyrille

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

Re: [PD] variance from mapping library

[Mathieu Bouchard]

On Mon, 23 Mar 2009, Oded Ben-Tal wrote:


the mapping lib is optimized to work with number from -1 to 1.
do you still have error using this kind of number?


It seems that not.


Try again harder. Look at the two mails I've just sent about this subject.

 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] variance from mapping library

[Oded Ben-Tal]

the mapping lib is optimized to work with number from -1 to 1.
do you still have error using this kind of number?


It seems that not.
I do get negative numbers even with input of ~200 (no need to get to 
10) and once it gets into negative territory it settles into negative 
numbers whenever the input is constant (i.e. 0 variance).


Oded

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

Re: [PD] variance from mapping library

[Mathieu Bouchard]

On Mon, 23 Mar 2009, Mathieu Bouchard wrote:

You can send simple repeated sequences to [mapping/variance] to show 
that not only it can drift in the negative values almost endlessly, but 
it doesn't even compute the variance of N values. This is because there 
is a moving average of something involving another moving average. This 
makes a global moving average of 2N-1 values instead of N, and then the 
window isn't rectangular anymore, it's triangular, because different 
values are counted different number of times depending on how old they 
are.


errata: i mean that a moving average of a moving average is another moving 
average with a different window (the convolution of the two windows), but 
the case of [mapping/variance] is more complicated because of the extra 
operations being done, and so there is no easy way to describe it, but you 
can see that it uses too many values in the same way that the moving 
average of the moving average does.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] variance from mapping library

[Mathieu Bouchard]

On Mon, 23 Mar 2009, cyrille henry wrote:


the mapping lib is optimized to work with number from -1 to 1.
do you still have error using this kind of number?


Well, yes, of course: because float precision is relative, this behaviour 
would happen for any scale of number, except in case of underflow, but 
then, in case of underflow, the result can't be accurate anymore anyway.


You can send simple repeated sequences to [mapping/variance] to show that 
not only it can drift in the negative values almost endlessly, but it 
doesn't even compute the variance of N values. This is because there is a 
moving average of something involving another moving average. This makes a 
global moving average of 2N-1 values instead of N, and then the window 
isn't rectangular anymore, it's triangular, because different values are 
counted different number of times depending on how old they are.


That's why I added extra zeroes in the messagebox. Remove them 
one at a time and you'll see this second phenomenon in addition 
to the first one.


#N canvas 425 84 450 300 10;
#X obj 83 33 tgl 15 0 empty empty empty 17 7 0 10 -24198 -1 -1 1 1;
#X obj 83 69 t b b;
#X obj 83 107 f;
#X obj 83 126 nbx 12 14 -1e+37 1e+37 0 0 empty empty empty 0 -8 0 10
-225271 -1 -1 -0.000188258 256;
#X obj 83 50 metro 1;
#X msg 113 88 1 \, 1 \, 0 \, 0 \, 0 \, 0 \, 0 \, 0 \, 0 \, 0 \, 0;
#X obj 114 107 variance 5;
#X connect 0 0 4 0;
#X connect 1 0 2 0;
#X connect 1 1 5 0;
#X connect 2 0 3 0;
#X connect 4 0 1 0;
#X connect 5 0 6 0;
#X connect 6 0 2 1;

 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] pd-tutorial.com patches won't open?

[J. Simon van der Walt]

Back to playing with Pd after a long break with, partly inspired by the new
book at pd-tutorial.com... problem is, none of the patches which go with the
book will open. Either by double clicking or opening from within the
application, nothing happens. The files I've downloaded seem perfectly fine,
I can open them in a text editor, it's just Pd won't do anything with them.

Any ideas what could be wrong here? Mac OSX 10.4.11, Pd-extended 0.39.3

Thanks,


-- 
J. Simon van der Walt- Composer







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

Re: [PD] variance from mapping library

[cyrille henry]

the mapping lib is optimized to work with number from -1 to 1.
do you still have error using this kind of number?
Cyrille


Mathieu Bouchard a écrit :

On Thu, 19 Mar 2009, Oded Ben-Tal wrote:

abs(a)+abs(b), or something like that. But 10*10 = 
100, and if you divide that by 2^24 = 16777216, you get about 
596, which is an upper bound for the amount of error: so, the error 
is surely between -596 and +596.
I trust your math here but just notice that your example converges to 
-691.


That's because 10*10 is only one value. Then, the second 
[mean_n] has to process + 9*9 + 8*8 + 7*7 + ... 
so the theoretical error maximum is much more than 596 but much less 
than 596*10. In practice, much of the individual errors are not that big 
and perhaps some of them cancel each other.


But to find the reason for why -691 precisely, would take a long time 
and would not be any insightful.


But if I understand you correctly 'filtering' the input data through 
[int] should make variance error free (we hope).


no, it won't, because still all of the other objects process floats. The 
reason why ints wouldn't have that problem is because they have fixed 
precision, that is, the step between two adjacent numbers is 1, whereas 
for floats it's roughly proportional to the numbers themselves. For 
integers you will hit an overflow problem quite quickly, and so, for 
example, if you remake that abstraction using 32-bit integers (for 
example, using the GridFlow library) then you can already get an 
overflow by using random 5-digit numbers, but at least, it goes back to 
normal when given a more modest sequence, whereas for floats it gets 
stuck and needs to be reset (recreated).


Using int64 you could get perfect results for most uses, but I don't 
recall whether the bugs in GridFlow's int64 support were fixed or not... 
I never quite had a use for int64 in the end.


For the "mapping" library, there isn't much of a choice but to remake it 
with a slower algorithm, unless someone knows a magic trick for 
cancelling almost all of the error while not running so slow. Actually, 
it already runs in linear time, so it wouldn't be such a big loss if the 
complete sum was recomputed at every step, because it would still be 
linear. It would be a big loss if it could run in constant time (e.g. 
using an array for the queue) and had to be switched to linear time.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec




___
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] A patch to share

[Kyle Klipowicz]

Neat!
~Kyle

On Sat, Mar 21, 2009 at 10:22 AM, Pall Thayer  wrote:

> I was going through some old stuff on my computer and found this patch I
> made a few years ago for a project called Autodrawn. The piece used to run
> on my server but due to my laziness in updating or even upgrading my server
> it's no longer running. However, the PD patch that goes with the work is
> interesting so I want to share it with the community. I've loosely applied
> the GPL to it. It might not be an interesting technical feat but rather
> conceptually. It plays a repeated sequence from Kraftwerk's Autobahn
> interspersed with live mp3 feeds of police scanners. The idea was to take
> the idea of the autobahn as portrayed on the original album cover, as
> something beautifully peaceful and positive and turn it into a more modern
> view of the freeway as something ominous and dangerous which has taken on an
> even newer meaning in recent years as a symbol of the negative impacts our
> fossil fuel consumption is having on the environment. Also, I just think it
> sounds cool. Even though it's just playing the same short sequence over and
> over again, it's still fun to listen to for long periods of time.
>
> So, if you find something interesting to do with it, feel free.
>
> best r.
> Pall Thayer
>
>
> #N canvas 4 98 985 512 10;
> #X obj 149 96 mp3amp~;
> #X msg 19 70 disconnect;
> #X floatatom 193 123 5 0 0 0 - - -;
> #X obj 234 96 vsl 15 128 0 1 0 0 empty empty empty 0 -8 0 8 -262144
> -1 -1 0 1;
> #X obj 327 108 mp3amp~;
> #X msg 264 86 disconnect;
> #X floatatom 371 135 5 0 0 0 - - -;
> #X obj 412 108 vsl 15 128 0 1 0 0 empty empty empty 0 -8 0 8 -262144
> -1 -1 0 1;
> #X obj 466 123 delread~ dc 400;
> #X obj 466 167 delwrite~ dc 400;
> #X floatatom 466 105 5 0 0 0 - - -;
> #X obj 12 104 delread~ sas 400;
> #X obj 12 148 delwrite~ sas 400;
> #X obj 471 145 *~ 0.1;
> #X obj 17 126 *~ 0.1;
> #X obj 149 306 mp3amp~;
> #X msg 86 269 disconnect;
> #X floatatom 193 333 5 0 0 0 - - -;
> #X obj 234 306 vsl 15 128 0 1 0 0 empty empty empty 0 -8 0 8 -262144
> -1 -1 0 1;
> #X floatatom 322 334 5 0 0 0 - - -;
> #X obj 327 374 *~ 0.1;
> #X obj 322 352 delread~ sw 400;
> #X obj 322 396 delwrite~ sw 400;
> #X obj 544 326 f;
> #X obj 615 326 + 1;
> #X obj 683 274 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1
> 1;
> #X floatatom 563 378 5 0 0 0 - - -;
> #N canvas 0 22 450 300 (subpatch) 0;
> #X array array103 100 float 1;
> #A 0 68 61 0 73 66 0 0 0 0 75.7258 75.7258 75.7258 73.1658 68.0458
> 65.4858 65.4858 66.3391 67.1925 68.0458 68.0458 68.0458 62.9258 61.6458
> 60.3658 57.8058 55.2458 52.6858 50.1258 47.5658 45.0058 42.4458 39.8857
> 38.1791 36.4724 34.7658 33.0591 31.3524 29.6457 27.0857 24.5257 21.9657
> 19.4057 18.1257 16.8457 16.8457 14.2857 14.2857 9.16572 4.04571 1.50713
> 1.54285 45.082 50.202 47.642 47.642 47.642 47.642 47.642 48.4953 49.3486
> 50.202 51.0553 51.9086 52.762 54.042 55.322 56.602 57.882 59.162 60.442
> 61.722 63.002 64.282 65.562 66.842 68.122 68.122 68.122 68.122 80.922
> -0.385712 -0.414283 -0.45714 -0.47 -0.528568 -0.585711 -0.57
> -0.614282 0 100 50 78 54 0 0 0 0 0 0 0;
> #X coords 0 128 99 0 100 50 1;
> #X restore 619 176 graph;
> #X obj 547 347 tabread array103;
> #X obj 594 437 line;
> #X obj 525 459 *~;
> #X obj 521 392 mtof;
> #X obj 487 371 mtof;
> #X obj 487 393 osc~;
> #X obj 448 371 mtof;
> #X obj 681 370 route 0;
> #X obj 569 326 mod 8;
> #X msg 496 234 \; array103 0 68 61 0 73 66 0 0 0;
> #X obj 448 393 osc~;
> #X obj 521 414 osc~;
> #X obj 447 347 - 24;
> #X obj 486 347 - 12.1;
> #X obj 31 413 delwrite~ autob 450;
> #X obj 18 353 delread~ autob 450;
> #X obj 682 302 metro 300;
> #X obj 628 44 f;
> #X obj 699 44 + 1;
> #X obj 653 44 mod 2;
> #X floatatom 657 76 5 0 0 0 - - -;
> #X obj 612 393 delay 5;
> #X obj 740 38 delay 5000;
> #X obj 342 53 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
> -1;
> #X obj 361 44 delay 5000;
> #X obj 737 60 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
> -1;
> #X obj 496 13 metro 30;
> #X obj 657 103 route 0 1;
> #X obj 657 125 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
> -1;
> #X obj 686 125 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
> -1;
> #X obj 715 125 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
> -1;
> #X obj 49 2 delay 5000;
> #X obj 126 44 delay 5000;
> #X obj 762 153 route 0 1;
> #X obj 762 175 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
> -1;
> #X obj 791 175 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
> -1;
> #X obj 820 175 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
> -1;
> #X obj 323 24 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
> -1;
> #X obj 22 2 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1
> ;
> #X obj 761 127 pipe 6;
> #X obj 103 47 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
> -1;
> #X obj 146 150 *~ 0.4;
> #X obj 146 360 *~ 0.23;
> #X obj 324 162 *~ 0.33;
> #X msg 286 306 connecturl http://12.40.197.36:8000;
> #X obj 794 

Re: [PD] DIY GSoC: getting those projects done

[martin.peach]

padawan12 wrote:
> Chris McCormick wrote:
> 
> > Also, I hate to be cynical, but
> > I can't see any way even remotely in which Google could use Pd to make a
> > profit. ;) 
> 
> 
> Profit aside, you can make a fundamental partition in computing 
> between forward looking systems (predictive, generative, 
> hypothetical, AI, imaginative type systems) and backward 
> looking (retrospective, analytical, indexing, organising, 
> sort, search, existing value based systems). A bit like left 
> and right brain faculties. Most problems involve elements of 
> both, but Google's domain (search) really falls more into the 
> latter, while applications of Pd are constructive and fall 
> better into the former. 
> 

Hmmm, maybe a project to find and install any Pd external missing from a 
patch...

Martin

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

Re: [PD] DIY GSoC: getting those projects done

[dmotd]

hmm.. now i would have thought that with google investing a great many 
resources into mobile technology, ie. their first real attempt at killing off 
the competition (apple) with their phone architecture (android), and with the 
relative success of rjdj for the (apple) iphone, they would be rushing at the 
opportunity to port a 'killer app' to their gadget and supporting the 
environment that harbours this app (pd). afterall the frivolous world of 
consumer gadgets requires that users have access to lovely toys that do the 
things which make those consumers like the gadget enough to warant spending 
the cash in the first place (no decent software, no gadget, no matter 
how 'cool', nerdy or utilitarian the thing is in the first place).

to be even more cynical, i would suggest that if the application was rewritten 
to suggest a focussed effort at making pd/rjdj support android and that 
the 'other' modifications fell under this umbrella project we may have stood 
a better chance. but this is all rather hypothetical and would require 
playing silly games with a corporate monolith. 

or perhaps a company that relies so heavily on string manipulation considered 
pd useless? ;)

ciao
dmotd

On Monday 23 March 2009 23:03:55 Chris McCormick wrote:
> Yo,
>
> IIRC, one of their complaints from last year was that our application had
> too many parts. Next time we should pick just one or two specific tasks and
> go with them. Maybe with a community vote or whatever. Also, I hate to be
> cynical, but I can't see any way even remotely in which Google could use Pd
> to make a profit. ;) Thanks for your huge effort anyway, Hans and Georg.
>
> Best,
>
> Chris.

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

Re: [PD] ADSR variations [was: Re: Patch-off]

[Mathieu Bouchard]

On Sun, 22 Mar 2009, Frank Barknecht wrote:

Hallo Jonathan,
Consequently, the behavior of [list $1 $2 etc.] is exactly the same as 
[list append $1 $2 etc.] in this case.

I would prefer the more verbose form [list append $1 $2 ...] just for clarity.


It's not for clarity that you should want "append" to be there, it's so 
that $1 can be a symbol if need appears for it.


Otherwise, it just takes you a minute to learn that [list] with a float $1 
is a shortcut of [list append] and it's not much harder to remember than 
any other shortcuts, especially if you already know that [list] is a 
shortcut of [list append].


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Problems compiling zexy

[IOhannes m zmoelnig]

Martin Hiendl wrote:

Thanks for your answer but unfortunately it didn't work for me.

I downloaded the svn and edited the makealias.sh to "#!/bin/bash".
But after "make", I received this:


i just noticed that i was a bit too paranoid when doing checks for the 
used Pd-version: it required at least 0.42


i have fixed it now to only require Pd 0.41
(and yes, this means that you must use Pd-0.41 for compilation of zexy 
on 64bit; you don't want anything lower when running on a 64bit machine 
anyhow)


please update your working copy of zexy by running "svn up"


mfd
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] DIY GSoC: getting those projects done

[Andy Farnell]

On Mon, 23 Mar 2009 13:03:55 +
Chris McCormick  wrote:

> Also, I hate to be cynical, but
> I can't see any way even remotely in which Google could use Pd to make a
> profit. ;) 


Profit aside, you can make a fundamental partition in computing 
between forward looking systems (predictive, generative, 
hypothetical, AI, imaginative type systems) and backward 
looking (retrospective, analytical, indexing, organising, 
sort, search, existing value based systems). A bit like left 
and right brain faculties. Most problems involve elements of 
both, but Google's domain (search) really falls more into the 
latter, while applications of Pd are constructive and fall 
better into the former. 


-- 
Use the source

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

Re: [PD] DIY GSoC: getting those projects done

[Chris McCormick]

Yo,

IIRC, one of their complaints from last year was that our application had too
many parts. Next time we should pick just one or two specific tasks and go with
them. Maybe with a community vote or whatever. Also, I hate to be cynical, but
I can't see any way even remotely in which Google could use Pd to make a
profit. ;) Thanks for your huge effort anyway, Hans and Georg.

Best,

Chris.

On Sun, Mar 22, 2009 at 11:33:55AM -0400, Hans-Christoph Steiner wrote:
>
> That is indeed true.  I suppose it wouldn't hurt to nag google, and it  
> might even help.  But I don't think it would change this year's outcome.
>
> I think the key to getting a grant like this is to know what they are  
> looking for and tailor the grant to that.  It would be useful if someone 
> tried to find any materials from the successful projects and report back 
> what they learned.  I tried to do that in the past.
>
> .hc
>
> On Mar 20, 2009, at 4:01 PM, Rich E wrote:
>
>> Of course it would be nice to do the projects regardless of funding,
>> but in reality they just won't get the same attention to detail and
>> thoroughness.  I don't have a job except through grants like this..
>>
>> I'm still all for making apython libpd module... but who knows when
>> summer rolls around and i'm broke.
>>
>> Do you think it is any good to question/complain to google about not
>> getting accepted two years in a row?  I looked at some of the other
>> project pages and not only is the pd application just as good, I think
>> the proposed projects are much more valuable to the open source
>> community.  I don't want to name anything in specific, but I saw some
>> well funded projects that only proposed various bug fixes, that were
>> accepted (literally there is a project that says "go through the bugs
>> list and fix whatever you can).
>>
>> regards,
>> Rich
>>
>> On Thu, Mar 19, 2009 at 12:08 PM, Hans-Christoph Steiner  
>>  wrote:
>>>
>>> So now we have a nice collection of projects sketched out from the  
>>> GSoC
>>> application, let's encourage people to take them on.  If anyone  
>>> wants to get
>>> involved with Pd development, take a look at the project ideas and  
>>> if you
>>> are interested, then ask about them on the list and we can get  
>>> started.
>>>
>>> http://puredata.info/dev/summer-of-code/GoogleSummerOfCodeIdeas2009
>>>
>>> I think next time someone else should take on the GSoC application  
>>> process.
>>> I'm 2 for 2 at not getting it,  I've never had much luck with  
>>> grants.  And
>>> we have lots of well-sketched out projects.  We should probably  
>>> chuck the
>>> application part and start from scratch.
>>>
>>> .hc
>>>
>>> 
>>>
>>> All mankind is of one author, and is one volume; when one man dies,  
>>> one
>>> chapter is not torn out of the book, but translated into a better  
>>> language;
>>> and every chapter must be so translated -John Donne
>>>
>>>
>>>
>>> ___
>>> Pd-list@iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>
>
>
>
>
> 
>
> 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
---
http://mccormick.cx

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

Re: [PD] Problems compiling zexy

[Martin Hiendl]

Thanks for your answer but unfortunately it didn't work for me.

I downloaded the svn and edited the makealias.sh to "#!/bin/bash".
But after "make", I received this:

"[...]
gcc -I.  -DHAVE_CONFIG_H -DZEXY_LIBRARY -DPD   -g -O2 -mms-bitfields
-fPIC -mfpmath=sse -msse  -c -o tabdump.o tabdump.c
tabdump.c: In function ‘tabdump_bang’:
tabdump.c:57: error: incompatible types in assignment
make: *** [tabdump.o] Error 1
mar...@martin-laptop:~$"


It was the same with "make everything".

Then I also edited the makesource.sh to "#!/bin/bash" but it was the
same result.

Martin

-Original Message-
From: IOhannes m zmoelnig 
To: Martin Hiendl 
Cc: pd-list@iem.at
Subject: Re: [PD] Problems compiling zexy
Date: Mon, 23 Mar 2009 10:57:12 +0100

IOhannes m zmoelnig wrote:
> 
> the problem is that ubuntu has switched to zsh and makealias.sh used to 
> be a bash-script.
> i believe this is fixed in subversion.

actually i found that it is not.
until it is fixed, you have to manually fix the makealias.sh:

> 
> a hack to make it run with the old and outdated zexy is to change the 
> first line of makealias.sh to "#!/bin/bash"

and of course, you should still use the svn version...

> 
> but better use the subversion version.
> 

fgmasdr
IOhannes


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

Re: [PD] [GEM] pix_video, firewire, and linux ?

[IOhannes m zmoelnig]

IOhannes m zmoelnig wrote:

Jaime Oliver wrote:

have you tried coriander?
I know it is the way to make firewire cameras work in linux using
libdc, but had no luck interfacing with gem. it is something I've
putting off for a while,


it seems like i don't have any device that properly works with coriander.
however, from what i read, coriander can create a videoloopback device 
which can then be used by Gem as an ordinary "v4l" device.



i finally got hands on a camera that is supported by coriander 
("Unibrain Fire-i BCL 1.2"), and it works fine with Gem using coriander 
& vloopback.


notes:
 - ubuntu does not come with vloopback modules
 - i was using a ubuntu/intrepid machine which has a 2.6.27 kernel 
installed and the debian vloopback-source module is version 1.1 which 
does not work with >=2.6.27; i had to install vloopback-1.2 [1] which worked
 - the loopback device is of fixed size and this size somehow does not 
get propagated to Gem correctly; i had to manually set the size to the 
one i knew i was using (640x480)



mfg.adsr
IOhannes


[1] http://www.lavrsen.dk/twiki/bin/view/Motion/VideoFourLinuxLoopbackDevice



have you tried that?
if it doesn't work, how does it fail?

fgmadr
IOhannes




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




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] Problems compiling zexy

[IOhannes m zmoelnig]

IOhannes m zmoelnig wrote:


the problem is that ubuntu has switched to zsh and makealias.sh used to 
be a bash-script.

i believe this is fixed in subversion.


actually i found that it is not.
until it is fixed, you have to manually fix the makealias.sh:



a hack to make it run with the old and outdated zexy is to change the 
first line of makealias.sh to "#!/bin/bash"


and of course, you should still use the svn version...



but better use the subversion version.



fgmasdr
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] Problems compiling zexy

[IOhannes m zmoelnig]

Martin Hiendl wrote:

Hi!

I have a problem with compiling zexy. I have successfully compiled
Pd-Vanilla on my Ubuntu 8.10 (amd64) and its directory is:
~/install/pd-0-42-4/
And pd also found the extras when I put the path
to /usr/local/lib/pd/extra/...

So I tried to install zexy and downloaded it via CVS following these
instructions:
http://puredata.info/Members/jb/ext-doc


this documentation is *outdated*
you should chekout the sources with subversion rather than CVS (which is 
only there for legacy reasons)


getting zexy:
% svn co 
https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/zexy/





I got stuck after "make" receiving this error message:

ath=sse -msse  -c -o zexy.o zexy.c
gcc -export_dynamic -shared  -o zexy.pd_linux  *.o -lm -lc 
/usr/bin/ld: warning: cannot find entry symbol xport_dynamic; defaulting

to 4e10
strip --strip-unneeded zexy.pd_linux 
cp zexy.pd_linux  ..



And after "make install" I got this:

x...@xyz-laptop:~/externals/zexy/src$ sudo make install
[sudo] password for xyz: 
gcc -export_dynamic -shared  -o zexy.pd_linux  *.o -lm -lc 
/usr/bin/ld: warning: cannot find entry symbol xport_dynamic; defaulting

to 4e10
strip --strip-unneeded zexy.pd_linux 
cp zexy.pd_linux  ..

./makealias.sh ../src/alias ../src ../reference
./makealias.sh: 24: Syntax error: "(" unexpected
make: *** [alias-bin] Error 2


What can I do?


the problem is that ubuntu has switched to zsh and makealias.sh used to 
be a bash-script.

i believe this is fixed in subversion.

a hack to make it run with the old and outdated zexy is to change the 
first line of makealias.sh to "#!/bin/bash"


but better use the subversion version.

fgmasdr
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] default [output~] in Pd-extended

[IOhannes m zmoelnig]

Hans-Christoph Steiner wrote:



So if we are introducing the concept of objects and GUI in Pd, then I 
think it is safe to use GOP objects.  After all, we don't expect newbies 
to know anything about C or Tcl, but that's under it it all.  I don't 
think we should add an output~ to help patches that don't already have 
them.  I just think we should have a more intuitive and usable output~.  
The current one already uses GOP, so that's not a change.




i fully agree.
and would like to stress, that i am pretty sure that most users will not 
have a clue about gop when they first encounter the [output~] module (be 
it a new one or the original one).


at least i cannot seem to find any documentation about gop prior to 
3/A.05; nevertheless i think it is a good idea to use a gop-abstraction 
here.


fgmasdr
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