Re: [PD] best way to do 1/x

[Mathieu Bouchard]

On Wed, 9 Jul 2008, PSPunch wrote:

I was imagining rather a single send/receive pair messing around with 
execution order of data entering at once.


This does not happen except for the confusion that is caused by creating 
those invisible wires across parts of the programme that are presumed to 
not communicate just because one expects everything to go through [inlet]s 
and [outlet]s. Even when everything goes through [inlet]s and [outlet]s, 
there's a fair chance of getting confused on some things sometimes, 
because visible connections aren't always so visible. Sometimes a 
connection looks like an actual togetherness, and sometimes it just looks 
like a line among too many. It's a matter of obfuscation.


I'd rather use almost exclusively [inlet] and [outlet] as means of 
organising patches, instead of [s]/[r] all over the place, and then I'd 
use [s]/[r] only in simple patterns that are made as local as possible. 
This is because it makes programs more obvious.


 _ _ __ ___ _  _ _ ...
| 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] [PD-announce] Pd-0.40.3-extended-rc2 released

[Luke Iannini]

On Fri, Jul 4, 2008 at 1:37 AM, IOhannes m zmoelnig <[EMAIL PROTECTED]> wrote:
> Luke Iannini wrote:
>> So, sorry to pick on the hexloader some more : ) but it seems it is
>> the culprit.  Can anyone confirm?
>
> it makes sense.
>
> could you send me the complete output of the pd-console when loading
> your patch with "-verbose". (might get big; so zip it and send it to me
> privately; or put it somewhere online...)
Hi IOhannes,
Sorry for the wait, I had a busy week.  Here's the output... I put it
online in case anyone else is interested. (I cleared the initial
output messages, so it starts immediately after I click off the
[sft.coral] object)  Big indeed; 616 megs, be ready for that (luckily
it's ideal for compression: 20.4megs zipped).*  And this is only one
module... if I had tried the patch where I load 16 of them I would
have run out of HD space (not to mention RAM); glad I didn't : ).
http://www.proyekto.net/sndrft/GiantLoad.txt.zip

It occurred to me that it might make sense to cache the last known
location of an object and try that location first?  Or is that a
hack...  I don't know.  But it seems it would help all loaders to do
so.

Also, I'm guessing stripping down my Pd-prefs to include a minimum of
directories would greatly help, yea?  Or, put another way, it's a good
argument to accelerate use of [import].

Best
Luke

>
>
> i am not sure how to handle the problem generally yet.
> ideas are:
> - remove the recursive library search in hexloader (no more hexloading
> for non-C externals; who is using that anyhow? libdir doesn't seem to
> like hexloader so much anyhow)
> - remove the the HEXLOADER_PATCHES functionality (it seems to be not
> working anyhow)
> - remove the entire hexloader quirks and just claim that you cannot
> write objects with filenames containing special characters.
>
> after all the endless struggles with hexloader, i start tending towards
> the last one...
>
>
> fgmasdr
> IOhannes
>
> ___
> 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

[PD] vline~, vsnapshot~, etc.

[Matt Barber]

Dumb question:

What does the "v" in [vline~], [vsnapshot~], etc. mean?  Is it also
the same in the "vinlet" and "vexpr" object classes?

Thanks,

Matt

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

Re: [PD] best way to do 1/x

[PSPunch]

Mathieu,


I was imagining rather a single send/receive pair messing around with 
execution order of data entering at once.

Thanks a bunch though.


--
David Shimamoto


> On Wed, 9 Jul 2008, PSPunch wrote:
> 
>> I've never noticed send/receive causing unpredictable execution order. 
>> Can someone show me an example of under what circumstances this occurs 
>> so I can avoid future head aches?
> 
> all cases. the receivers are ordered in the order that they are created. 
> if you are currently editing a patch, this is likely to be different 
> from the order that it will be when you will reload the patch. the only 
> way to change the order is to recreate the receivers in the correct 
> order, but really, you should seek a more transparent way of doing 
> things. For example, if [r $0-stuff] has to be received in two distinct 
> phases, make a splitter that uses a [t a a] from [r $0-stuff] to [s 
> $0-stuff-1] and [s $0-stuff-2] so that all receivers that need the 
> information early use $0-stuff-1 and the ones that need it late use 
> $0-stuff-2.
> 
>  _ _ __ ___ _  _ _ ...
> | 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] best way to do 1/x

[Mathieu Bouchard]

On Wed, 9 Jul 2008, PSPunch wrote:

I've never noticed send/receive causing unpredictable execution order. 
Can someone show me an example of under what circumstances this occurs 
so I can avoid future head aches?


all cases. the receivers are ordered in the order that they are created. 
if you are currently editing a patch, this is likely to be different from 
the order that it will be when you will reload the patch. the only way to 
change the order is to recreate the receivers in the correct order, but 
really, you should seek a more transparent way of doing things. For 
example, if [r $0-stuff] has to be received in two distinct phases, make a 
splitter that uses a [t a a] from [r $0-stuff] to [s $0-stuff-1] and [s 
$0-stuff-2] so that all receivers that need the information early use 
$0-stuff-1 and the ones that need it late use $0-stuff-2.


 _ _ __ ___ _  _ _ ...
| 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] best way to do 1/x

[PSPunch]

Hi,


I've never noticed send/receive causing unpredictable execution order.
Can someone show me an example of under what circumstances this occurs 
so I can avoid future head aches?

--
David Shimamoto



> Atte André Jensen wrote:
>> Frank Barknecht wrote:
>>
>>> Yes, it is. ;)
>> But slightly more tricky is that send/recieve must have the same 
>> "problems", but may be more difficult to spot.
>>
> 
> indeed, this problem exists.
> 
> that is why you should use explicit connections and [trigger] whenever 
> possible.
> 
> on the other hand, i do have plans for a [receive] where you could 
> enforce a certain order (similar to [gemhead])
> 
> 
> and since we are there: never use [delay] to enforce a certain execution 
> order (it does work, but usually you will get weird (though totally 
> deterministic) results in more complex setups)
> 
> fmgasd.r
> IOhannes
> 
> ___
> 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] better tabread4~

[Matt Barber]

Cyrille,

Could you try this optimization for the tabread6c~ I threw together?
It uses the same general notation as the tab4c~ suite:

t_sample a3plusa4plusa5 = 0.25f*c+0.125f*e-0.333f*d-0.0417*a;
t_sample fminusa = f-a;
t_sample eminusb = e-b;
t_sample dminusc = d-c;

a5 = 0.208f*((fminusa-5.f*eminusb+10.f*dminusc));
a4 = 2.667f*eminusb-0.5f*fminusa-5.5f*dminusc-a3plusa4plusa5;
a3 = a3plusa4plusa5-a4-a5;
a2 = 0.667f*(d+b)-0.0417f*(a+e)-1.25f*c;
a1 = 0.667f*(d-b)+0.0833f*(a-e);
a0 = c;

*out++ =  a5 * frac + a4 ) * frac + a3) * frac + a2) * frac + a1)
* frac + a0;


I've tested it and I think it works...  I count 20 *'s and 25 +'s = 45
ops vs. 31 *'s, and 27 +'s = 58 ops (if the fractions were written out
as decimals).

Thanks,

Matt


> Date: Tue, 08 Jul 2008 18:35:51 +0200
> From: cyrille henry <[EMAIL PROTECTED]>
> Subject: Re: [PD] better tabread4~
> To: Charles Henry <[EMAIL PROTECTED]>
> Cc: pd-list@iem.at
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> hello Chuck,
>
> i tested this. (and commited)
> i think tabread6c~ is a bit better than tabread4c~. but differences are more 
> smaller
>
> thx
>
> Cyrille
>
>
> Charles Henry a ?crit :
>> On Sat, Jun 28, 2008 at 6:43 AM, cyrille henry
>> <[EMAIL PROTECTED]> wrote:
>>
>>
>> The coefficients used in this scheme are
>>
>> a0= Y[0]
>> a1= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2]
>> a2= -1/24*Y[-2] + 2/3*Y[-1] - 5/4*Y[0] + 2/3*Y[1] - 1/24*Y[2]
>> a3= -3/8*Y[-2] + 13/8*Y[-1] - 35/12*Y[0] + 11/4*Y[1] - 11/8*Y[2] + 7/24*Y[3]
>> a4= 13/24*Y[-2] - 8/3*Y[-1] + 21/4*Y[0] - 31/6*Y[1] + 61/24*Y[2] - 1/2*Y[3]
>> a5= -5/24*Y[-2] + 25/24*y[-1] - 25/12*Y[0] + 25/12*Y[1] - 25/24*Y[2] + 
>> 5/24*Y[3]
>>

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

[PD] Mac OS X 10.3 build for Pd-extended

[Hans-Christoph Steiner]

I put together a test build for Pd-extended on 10.3.  Please test it:

http://at.or.at/hans/pd/installers.html

You might need to copy Gem.pd_darwin out of the previous version of  
Pd-extended to make it work.

.hc

 


'You people have such restrictive dress for women,’ she said,  
hobbling away in three inch heels and panty hose to finish out  
another pink-collar temp pool day.  - “Hijab Scene #2", by Mohja Kahf



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

[PD] compiling pd-extended ubuntu hardy amd64

[Sergi Lario]

I get some errors trying to compile pd-extended in a ubuntu hardy amd64.

I did this steps:

1.- Get pd-extended trunk code via svn

[EMAIL PROTECTED]:/home/pd-extended$ svn co
https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/ ./

2.- Get Gem code from

http://gem.iem.at/

and copy the content

[EMAIL PROTECTED]:/home/pd-extended$ cp /home/sll/Escriptori/gem-0.91.1.tar.gz 
./
[EMAIL PROTECTED]:/home/pd-extended$ tar xzvf gem-0.91.1.tar.gz

3.- Rename floder to Gem

[EMAIL PROTECTED]:/home/pd-extended$ mv gem-0.91.1 Gem

4.- Compile pd-extended

[EMAIL PROTECTED]:/home/pd-extended/packages/linux_make$ sudo make install

While I was getting errors I modifyed some code and install libs like this:

A. add -fPIC to c-flags in gem2pdp
B. install libswscale-dev
C add -fPIC to miXed for cyclone -
[EMAIL PROTECTED]:/home/pd-extended/externals/miXed$
vim Makefile.common

After each point I tried to compile another time with make install

At the moment I get this errors and I don't know how follow with it.

/home/pd-extended/externals/iem/hdspm_mixer/hdspmmixer.c:99: avís: unused
parameter 'x'
install: ha fallat stat() sobre
«/home/pd-extended/externals/moocow/extended/build.moo/ext*/*.pd»: No such
file or directory
install: ha fallat stat() sobre
«/home/pd-extended/externals/pmpd/*.pd_linux»: No such file or directory
make[2]: [pmpd_install] Error 1 (ignored)
install: ha fallat stat() sobre
«/home/pd-extended/externals/pidip/*.pd_linux»: No such file or directory
make[2]: *** [pidip_install] Error 1
make[1]: *** [externals_install] Error 2
make: *** [install] Error 2

(* avís = warning  ,  ha fallat = has failed)

If somebody knows anything about it, please let me know.

Thanks,

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

Re: [PD] print all abstractions and externals

[Luke Iannini]

On Tue, Jul 8, 2008 at 3:36 AM, Claude Heiland-Allen
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> Yet another approach ;)
>
> I've got a suite of bash scripts that help narrow down which externals
> are missing.  Here's a real-life-example:
>
> --8<--
> [EMAIL PROTECTED]:~/maximus/pdpatchinfo$ cat ../2007/d01234two/*.pd |
> ./objs.sh | ./externals.sh pd-0.41-4.txt | ./externals.sh Gem.txt  |
> ./abstractions.sh ../2007/d01234two/
> 0
> 1
> analogue_adsr~
Hi Claude,
Speaking of analogue_adsr~, any plans to add it to Pd-E?  It is my
favorite envelope : )
(it's not hard for me to drop it in myself, but I bet others would like it too)

Best
Luke


> complex-mod~
> expr
> expr~
> hilbert~
> #in
> mtx_.*
> mtx_diag
> mtx_mul
> #out
> repeat
> #store
> [EMAIL PROTECTED]:~/maximus/pdpatchinfo$
> --8<--
>
> Which reminds me I need gridflow, zexy and iemmatrix to run that patch,
> plus some objs that are bundled with pd, and a home-brewed external.
>
> I patched one of my installed versions of Pd to print out every class
> registered with Pd during load time, which can then be massaged into a
> raw list of objects for each library (eg: Gem.txt).
>
>
> Claude
> --
> http://claudiusmaximus.goto10.org
>
>
> ___
> 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] analog-modelling 808 hihat and cowbell

[hard off]

that's a brilliant idea to use receives
on the oscillators, so that the same ones can be used for both the bell and
the hat.

sounds great too.

here are some other drum sounds i have made and/or collected:

http://puredata.hurleur.com/sujet-1930-diy-library-part-diy-perk
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] analog-modelling 808 hihat and cowbell

[Damian Stewart]

Damian Stewart wrote:

hey everyone,

to complement Roman Haefeli's excellent 808 kick and clap abstractions 
(http://www.romanhaefeli.net/software/pd/rdz_dsplib.tar.gz), i've put 
together a hihat and cowbell, constructed by close listening to a 
collection of 808 samples. it's not perfect but it's close enough.


whoops, forgot the [d-smooth~]. oh, and [d-default].

i should clean up the d-lib and release it, really..

d

--
damian stewart | +31 6 5902 5782 |  [EMAIL PROTECTED]
frey | live art with machines | http://www.frey.co.nz
#N canvas 581 174 522 372 10;
#X obj 50 110 == 0;
#X obj 49 165 f \$2;
#X obj 50 136 sel 1 0;
#X obj 71 187 f \$1;
#X obj 50 79 init \$1;
#X text 166 86 usage: [d-default \$2 30];
#X text 169 107 if \$2 is 0 \, output 30 \, else output \$2;
#X obj 18 40 inlet;
#X text 162 143 input: passes straight through;
#X obj 49 257 f;
#X obj 50 287 outlet;
#X text 163 35 provide default argument functionality;
#X connect 0 0 2 0;
#X connect 1 0 9 0;
#X connect 2 0 1 0;
#X connect 2 1 3 0;
#X connect 3 0 9 0;
#X connect 4 0 0 0;
#X connect 7 0 9 0;
#X connect 9 0 10 0;
#N canvas 409 245 462 312 10;
#X obj 66 185 outlet~;
#X obj 67 40 inlet;
#X obj 66 110 line~;
#X obj 66 76 pack 0 10;
#X obj 124 52 d-default \$1 10;
#X obj 248 50 inlet;
#X text 165 137 smooth from signal rate to audio rate;
#X text 162 157 first arg / right inlet sets smooth time;
#X connect 1 0 3 0;
#X connect 2 0 0 0;
#X connect 3 0 2 0;
#X connect 4 0 3 1;
#X connect 5 0 3 1;
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] analog-modelling 808 hihat and cowbell

[Damian Stewart]

hey everyone,

to complement Roman Haefeli's excellent 808 kick and clap abstractions 
(http://www.romanhaefeli.net/software/pd/rdz_dsplib.tar.gz), i've put 
together a hihat and cowbell, constructed by close listening to a 
collection of 808 samples. it's not perfect but it's close enough.


put all the attached patches together in the same folder and open 808test.pd.

enjoy, and send me links to audio if you use it :-)

take care
d
--
damian stewart | +31 6 5902 5782 |  [EMAIL PROTECTED]
frey | live art with machines | http://www.frey.co.nz
#N canvas 187 161 622 421 10;
#X obj 66 249 808cowbell;
#X obj 67 100 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X obj 163 247 808hihat;
#X obj 188 100 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X obj 340 95 hsl 128 15 0.7 1.3 0 0 empty empty empty -2 -8 0 10 -262144
-1 -1 7700 1;
#X text 351 79 master tuning;
#X obj 337 161 s 808-tuning;
#X obj 382 281 808brain;
#X obj 162 101 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X floatatom 375 128 5 0 0 0 - - -;
#X obj 153 324 dac~;
#X obj 252 99 vsl 15 128 0 1 0 0 empty empty empty 0 -9 0 10 -262144
-1 -1 12700 1;
#X text 159 80 CH;
#X text 188 80 OH;
#X text 67 79 CB;
#X text 228 79 OH decay;
#X obj 337 8 loadbang;
#X msg 337 28 1;
#X connect 0 0 10 0;
#X connect 0 0 10 1;
#X connect 1 0 0 0;
#X connect 2 0 10 0;
#X connect 2 0 10 1;
#X connect 2 1 10 0;
#X connect 2 1 10 1;
#X connect 3 0 2 1;
#X connect 4 0 6 0;
#X connect 4 0 9 0;
#X connect 8 0 2 0;
#X connect 11 0 2 2;
#X connect 16 0 17 0;
#X connect 17 0 4 0;
#N canvas 482 294 491 373 10;
#X obj 30 116 s~ 808-sq-1;
#X obj 25 210 s~ 808-sq-2;
#X obj 24 300 s~ 808-sq-3;
#X obj 190 126 s~ 808-sq-4;
#X obj 185 210 s~ 808-sq-5;
#X obj 194 306 s~ 808-sq-6;
#X obj 105 11 r 808-tuning;
#X obj 190 98 *~ 0.7;
#X obj 29 94 *~ 0.9;
#X obj 31 49 * 210;
#X obj 189 50 * 540;
#X obj 183 164 * 550;
#X obj 194 256 * 800;
#X obj 24 253 * 380;
#X obj 24 162 * 320;
#X obj 190 72 d-square~ 540;
#X obj 186 187 d-square~ 550;
#X obj 194 283 d-square~ 800;
#X obj 24 276 d-square~ 380;
#X obj 23 187 d-square~ 320;
#X obj 29 73 d-square~ 210;
#X text 327 166 808 support;
#X text 325 210 [EMAIL PROTECTED];
#X text 325 195 damian stewart 2008;
#X text 328 241 GPL v3;
#X connect 6 0 9 0;
#X connect 6 0 10 0;
#X connect 6 0 11 0;
#X connect 6 0 12 0;
#X connect 6 0 13 0;
#X connect 6 0 14 0;
#X connect 7 0 3 0;
#X connect 8 0 0 0;
#X connect 9 0 20 0;
#X connect 10 0 15 0;
#X connect 11 0 16 0;
#X connect 12 0 17 0;
#X connect 13 0 18 0;
#X connect 14 0 19 0;
#X connect 15 0 7 0;
#X connect 16 0 4 0;
#X connect 17 0 5 0;
#X connect 18 0 2 0;
#X connect 19 0 1 0;
#X connect 20 0 8 0;
#N canvas 636 171 503 465 10;
#X obj 106 236 line~;
#X obj 94 281 *~;
#X text 11 109 attack;
#X obj 23 32 inlet;
#X obj 21 59 t b;
#X obj 107 260 *~;
#X obj 88 141 +~;
#X obj 97 378 *~ 0.2;
#X msg 22 91 1 2;
#X obj 107 169 del 2.2;
#X msg 106 201 0.3 70;
#X obj 106 335 bpq2~ 2691 1.631 100;
#X obj 201 171 del 76;
#X obj 88 101 r~ 808-sq-4;
#X obj 213 100 r~ 808-sq-6;
#X obj 95 409 outlet~;
#X text 196 154 release;
#X text 106 156 decay/sus;
#X msg 202 201 0 400;
#X text 323 382 [EMAIL PROTECTED];
#X text 323 367 damian stewart 2008;
#X text 326 413 GPL v3;
#X text 324 338 808 cowbell;
#X text 20 9 bang to trigger;
#X connect 0 0 5 0;
#X connect 0 0 5 1;
#X connect 1 0 11 0;
#X connect 3 0 4 0;
#X connect 4 0 8 0;
#X connect 4 0 9 0;
#X connect 4 0 12 0;
#X connect 5 0 1 1;
#X connect 6 0 1 0;
#X connect 7 0 15 0;
#X connect 8 0 0 0;
#X connect 9 0 10 0;
#X connect 10 0 0 0;
#X connect 11 0 7 0;
#X connect 12 0 18 0;
#X connect 13 0 6 0;
#X connect 14 0 6 1;
#X connect 18 0 0 0;
#N canvas 189 357 478 328 10;
#X obj 78 238 clip~ -1 1;
#X obj 80 213 *~ 1;
#X obj 85 275 outlet~;
#X text 268 222 basic square wave;
#X obj 180 83 random 1000;
#X obj 80 189 +~;
#X obj 282 164 d-smooth~;
#X obj 284 43 inlet;
#X obj 281 104 loadbang;
#X obj 283 128 \$2;
#X text 272 246 \$1 = frequency;
#X text 304 272 (0 = equal);
#X text 270 261 \$2 = pulsewidth (-1..1);
#X obj 79 157 osc~;
#X obj 151 41 loadbang;
#X obj 151 62 t b b;
#X obj 89 84 f \$1;
#X text 72 5 frequency;
#X text 277 18 pulsewidth;
#X obj 80 34 inlet;
#X obj 78 128 + 0;
#X obj 180 102 / 500;
#X connect 0 0 2 0;
#X connect 1 0 0 0;
#X connect 4 0 21 0;
#X connect 5 0 1 0;
#X connect 6 0 5 1;
#X connect 7 0 9 0;
#X connect 8 0 9 0;
#X connect 9 0 6 0;
#X connect 13 0 5 0;
#X connect 14 0 15 0;
#X connect 15 0 16 0;
#X connect 15 1 4 0;
#X connect 16 0 20 0;
#X connect 19 0 16 0;
#X connect 20 0 13 0;
#X connect 21 0 20 1;
#N canvas 419 100 748 568 10;
#X obj 204 84 +~;
#X obj 47 268 line~;
#X obj 98 318 *~;
#X obj 66 176 t b;
#X obj 65 119 inlet;
#X obj 51 296 *~;
#X obj 184 5 r~ 808-sq-1;
#X obj 172 31 r~ 808-sq-2;
#X obj 170 57 r~ 808-sq-3;
#X obj 288 4 r~ 808-sq-4;
#X obj 300 30 r~ 808-sq-5;
#X obj 314 56 r~ 808-sq-6;
#X text 514 390 open hh;
#X obj 402 325 line~;
#X obj 393 381 *~;
#X obj 402 93 inlet;
#X obj 395 5

Re: [PD] delay problems

[Ricardo Dueñas Parada]

That was the problem, indeed.

Thanks.

2008/7/8 Frank Barknecht <[EMAIL PROTECTED]>:
> Hallo,
> Ricardo Dueñas Parada hat gesagt: // Ricardo Dueñas Parada wrote:
>
>> Sometimes the object delay doesn't work correctly, I mean, if I put a 500,
>> I expect to have a 500 ms bang delay. And it does, but when it wants.
>> Other times it just let the bang pass, as with 0 delay.
>>
>> Most of the times it happens when I have a delay right after an inlet,
>> seriously I don?t know what could be happening.
>>
>> I correct it by changing the value of the delay, usually to 1000, and it 
>> works
>> correctly, then I rewrite the correct value.
>
> I'm pretty sure that [delay] in Pd works correctly, unless there are
> new bugs, which everyone and their sister would already shout about by
> now in an object as important as delay.
>
> If it works correctly, the only reason for the behaviour you describe
> that I can think of is that you are sending a number instead of a bang
> to [delay] at certain times.
>
> Sending a number to the delay on *both* inlets will change the delay
> time. The change happens immediatly, if you send the number to the
> hot, left inlet, and on the next bang, if you used the cold inlet for
> the number.
>
> You could insert a [bang] object before the [delay] to get rid of the
> numbers, but maybe first find out, where the numbers come from.
>
> Ciao
> --
>  Frank Barknecht _ __footils.org__
>
> ___
> 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] smallest number from a stream of numbers

[Enrique Erne]

Frank Barknecht wrote:
> Hallo,
> cyrille henry hat gesagt: // cyrille henry wrote:
> 
>> Ben Carney a écrit :
>>> Hello there list!
>>>
>>> pretty simple question I think, but I'm a bit stumped.
>>>
>>> I have a stream of numbers coming in from a flex sensor and I would love 
>>> to be able to grab the lowest number from x amount of numbers, every 30 
>>> numbers or so.
>>>
>>> I looked through the [list minmax] example, but could not figure out how 
>>> to make it do it "live".
>>>
>>  |
>> [mapping/last_n 30]
>>  |
>> [list minmax]
>>  |
> 
> Or 
> 
>  [list-lastx 30]
>  |
>  [list-minmax] 
>  

Or how about

/\
[moses]  \
| \
[trigger a a]

with a handmade counter that resets moses every n'th time.

eni

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

Re: [PD] change in range

[Claude Heiland-Allen]

Ben Carney wrote:

I believe  that this is perfect


thank you so much.


did you just whip that up or did you have it on hand?


Made freshly, so fresh that there's a bug when changing right hand inlet..

Attached is a fixed version (I hope)



Best,

On Tue, Jul 8, 2008 at 3:09 PM, Claude Heiland-Allen <
[EMAIL PROTECTED]> wrote:


Claude Heiland-Allen wrote:


Ben Carney wrote:


I know change doesnt let same numbers pass on. Is there a way to only let
numbers pass on if they are say... plus or minus 3 of the current value?


Arg, sorry - I was too hasty.

The attached works ok for me (although with some minor quirks regarding "<"
vs "<=").

 something like this?
[snip nonsense]


Claude
--
http://claudiusmaximus.goto10.org


#N canvas 0 0 450 300 10;
#X obj 23 17 inlet;
#X obj 26 171 moses;
#X obj 78 172 moses;
#X obj 140 15 loadbang;
#X obj 169 78 f \$1;
#X obj 168 105 abs;
#X obj 76 118 * -1;
#X obj 210 14 inlet;
#X obj 139 139 +;
#X obj 50 217 t f f;
#X obj 50 251 outlet;
#X obj 140 45 t b b;
#X obj 139 78 f 0;
#X obj 57 145 +;
#X obj 210 42 t b f;
#X connect 0 0 1 0;
#X connect 1 0 9 0;
#X connect 1 1 2 0;
#X connect 2 1 9 0;
#X connect 3 0 11 0;
#X connect 4 0 5 0;
#X connect 5 0 6 0;
#X connect 5 0 8 1;
#X connect 6 0 13 1;
#X connect 7 0 14 0;
#X connect 8 0 2 1;
#X connect 9 0 10 0;
#X connect 9 1 12 0;
#X connect 11 0 12 0;
#X connect 11 1 4 0;
#X connect 12 0 8 0;
#X connect 12 0 13 0;
#X connect 13 0 1 1;
#X connect 14 0 12 0;
#X connect 14 1 5 0;
#N canvas 0 0 450 300 10;
#X floatatom 77 95 5 0 0 0 - - -;
#X floatatom 77 182 5 0 0 0 - - -;
#X floatatom 172 93 5 0 0 0 - - -;
#X obj 77 134 differs_by_n 3;
#X connect 0 0 3 0;
#X connect 2 0 3 1;
#X connect 3 0 1 0;
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] change in range

[Ben Carney]

I believe  that this is perfect


thank you so much.


did you just whip that up or did you have it on hand?

Best,

On Tue, Jul 8, 2008 at 3:09 PM, Claude Heiland-Allen <
[EMAIL PROTECTED]> wrote:

> Claude Heiland-Allen wrote:
>
>> Ben Carney wrote:
>>
>>> I know change doesnt let same numbers pass on. Is there a way to only let
>>> numbers pass on if they are say... plus or minus 3 of the current value?
>>>
>>
> Arg, sorry - I was too hasty.
>
> The attached works ok for me (although with some minor quirks regarding "<"
> vs "<=").
>
>  something like this?
>>
>
> [snip nonsense]
>
>
> Claude
> --
> http://claudiusmaximus.goto10.org
>
> #N canvas 0 0 450 300 10;
> #X obj 23 17 inlet;
> #X obj 26 171 moses;
> #X obj 78 172 moses;
> #X obj 140 15 loadbang;
> #X obj 169 78 f \$1;
> #X obj 169 104 abs;
> #X obj 76 118 * -1;
> #X obj 212 17 inlet;
> #X obj 112 146 +;
> #X obj 50 217 t f f;
> #X obj 51 250 outlet;
> #X obj 140 45 t b b;
> #X obj 139 67 f 0;
> #X obj 57 145 +;
> #X connect 0 0 1 0;
> #X connect 1 0 9 0;
> #X connect 1 1 2 0;
> #X connect 2 1 9 0;
> #X connect 3 0 11 0;
> #X connect 4 0 5 0;
> #X connect 5 0 6 0;
> #X connect 5 0 8 1;
> #X connect 6 0 13 1;
> #X connect 7 0 5 0;
> #X connect 8 0 2 1;
> #X connect 9 0 10 0;
> #X connect 9 1 8 0;
> #X connect 9 1 13 0;
> #X connect 11 0 12 0;
> #X connect 11 1 4 0;
> #X connect 12 0 8 0;
> #X connect 12 0 13 0;
> #X connect 13 0 1 1;
>
> #N canvas 0 0 450 300 10;
> #X floatatom 77 95 5 0 0 0 - - -;
> #X floatatom 77 182 5 0 0 0 - - -;
> #X obj 77 134 differs_by_n 3;
> #X floatatom 172 93 5 0 0 0 - - -;
> #X connect 0 0 2 0;
> #X connect 2 0 1 0;
> #X connect 3 0 2 1;
>
>


-- 

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

Re: [PD] change in range

[Claude Heiland-Allen]

Claude Heiland-Allen wrote:

Ben Carney wrote:

I know change doesnt let same numbers pass on. Is there a way to only let
numbers pass on if they are say... plus or minus 3 of the current value?


Arg, sorry - I was too hasty.

The attached works ok for me (although with some minor quirks regarding 
"<" vs "<=").



something like this?


[snip nonsense]

Claude
--
http://claudiusmaximus.goto10.org
#N canvas 0 0 450 300 10;
#X obj 23 17 inlet;
#X obj 26 171 moses;
#X obj 78 172 moses;
#X obj 140 15 loadbang;
#X obj 169 78 f \$1;
#X obj 169 104 abs;
#X obj 76 118 * -1;
#X obj 212 17 inlet;
#X obj 112 146 +;
#X obj 50 217 t f f;
#X obj 51 250 outlet;
#X obj 140 45 t b b;
#X obj 139 67 f 0;
#X obj 57 145 +;
#X connect 0 0 1 0;
#X connect 1 0 9 0;
#X connect 1 1 2 0;
#X connect 2 1 9 0;
#X connect 3 0 11 0;
#X connect 4 0 5 0;
#X connect 5 0 6 0;
#X connect 5 0 8 1;
#X connect 6 0 13 1;
#X connect 7 0 5 0;
#X connect 8 0 2 1;
#X connect 9 0 10 0;
#X connect 9 1 8 0;
#X connect 9 1 13 0;
#X connect 11 0 12 0;
#X connect 11 1 4 0;
#X connect 12 0 8 0;
#X connect 12 0 13 0;
#X connect 13 0 1 1;
#N canvas 0 0 450 300 10;
#X floatatom 77 95 5 0 0 0 - - -;
#X floatatom 77 182 5 0 0 0 - - -;
#X obj 77 134 differs_by_n 3;
#X floatatom 172 93 5 0 0 0 - - -;
#X connect 0 0 2 0;
#X connect 2 0 1 0;
#X connect 3 0 2 1;
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] change in range

[Claude Heiland-Allen]

Ben Carney wrote:
> since cyrille answered my question with cat like speed and pinpoint
> accuracy, I have another on for the list.
> 
> I know change doesnt let same numbers pass on. Is there a way to only let
> numbers pass on if they are say... plus or minus 3 of the current value?

something like this?

in
[t f b]
|  X
| [f ]
|  |
| [t  f   f]
|[- 3]   [+ 3]
[moses]/[moses]
  |
  out

Claude
-- 
http://claudiusmaximus.goto10.org


> 
> 
> 
> 
> ___
> 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

[PD] change in range

[Ben Carney]

since cyrille answered my question with cat like speed and pinpoint
accuracy, I have another on for the list.

I know change doesnt let same numbers pass on. Is there a way to only let
numbers pass on if they are say... plus or minus 3 of the current value?
-- 

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

Re: [PD] Pdpedia error messages

[Hans-Christoph Steiner]

IDMI/Poly, the hosts, are in the process of upgrading their server to  
Leopard and it seems to have broken a lot of things.  I guess you get  
what you pay for ;)  Too bad it had to be on the Mac OS X server,  
rather than the Debian server.


I'll try to fix it ASAP.

.hc

On Jun 30, 2008, at 9:26 PM, Mike McGonagle wrote:

This appears to be happening for all links from the front "door"  
page... none of the languages appear to be working.


Mike


On Mon, Jun 30, 2008 at 1:15 PM, Thomas Mayer  
<[EMAIL PROTECTED]> wrote:

Hi,

when I try to open http://wiki.puredata.info/en/ I get all those php
messages:

Warning: require_once(WikiFamilySettings.php) [function.require-once]:
failed to open stream: Permission denied in
/Library/WebServer/VirtualHosts/pdpedia/htdocs/en/LocalSettings.php on
line 29

Fatal error: require_once() [function.require]: Failed opening  
required

'WikiFamilySettings.php'
(include_path='/Library/WebServer/VirtualHosts/pdpedia/htdocs/en:/ 
Library/WebServer/VirtualHosts/pdpedia/htdocs/en/includes:/Library/ 
WebServer/VirtualHosts/pdpedia/htdocs/en/languages:.:')

in /Library/WebServer/VirtualHosts/pdpedia/htdocs/en/LocalSettings.php
on line 29

cu Thomas
--
"Prisons are needed only to provide the illusion that courts and  
police

are effective. They're a kind of job insurance."
(Leto II. in: Frank Herbert, God Emperor of Dune)
http://thomas.dergrossebruder.org/

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




--
Peace may sound simple—one beautiful word— but it requires  
everything we have, every quality, every strength, every dream,  
every high ideal.

—Yehudi Menuhin (1916–1999), musician
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
listinfo/pd-list




 



Mistrust authority - promote decentralization.  - the hacker ethic


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

Re: [PD] [pd] where is sssad?

[Hans-Christoph Steiner]

On Jun 30, 2008, at 6:15 AM, Chris McCormick wrote:

> On Fri, Jun 27, 2008 at 07:37:36PM +0200, Frank Barknecht wrote:
>> Hallo,
>> dani hat gesagt: // dani wrote:
>>
>>> you mean this?
>>> http://mccormick.cx/viewcvs/oldcrap/s-abstractions/sssad/
>>
>> If your frightended by the  "oldcrap" in that URL (though it's
>> probably harmless), you can get the official version from the Pd SVN
>> at sourceforge in the directory:
>>
>> /trunk/abstractions/footils/sssad
>
> Hey Frank,
>
> I wonder if it wouldn't be worth putting a very small information page
> about sssad into the puredata wiki with links to the SVN and how to
> download it? Just so that people can find sssad using Google.
>
> Also, I should probably put an svn:externals link to sssad instead of
> including it wholesale in my own repository. I guess I could then  
> check
> my small additions into the main repository. What do you think?

I think it would be best to release it as its own library in libdir  
format.  Currently, there is the bug in the libdir that doesn't allow  
an object to have the same name as a library.  I am intending on  
focusing on completing the libdir format once this Pd-extended  
release is done.

.hc

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



 


Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.   
It's about as sensible to say we declare war on night attacks and  
expect we're going to win that war.  We're not going to win the war  
on terrorism.- retired U.S. Army general, William Odom



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

Re: [PD] XML-files

[Hans-Christoph Steiner]

On Jul 7, 2008, at 9:52 AM, [EMAIL PROTECTED] wrote:

> altern wrote:
>> [EMAIL PROTECTED](e)k dio:
>>
>>> How is it possible to make-XML files useable in Pd.
>>> e.g for controlling
>>>
>>
>> not sure what you are after but i am reading an XML file using python
>> via pyext external and returning some data to PD
>>
>
> or also using pdtcl (in svn) and the tDOM Tcl package

There is also the detox external for directly reading XML into Pd.

.hc


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



 


Computer science is no more related to the computer than astronomy is  
related to the telescope.  -Edsger Dykstra



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

Re: [PD] smallest number from a stream of numbers

[Ben Carney]

oh shit.


there is a mapping/last_n object.


I thought you meant using the mapping object with my last 30 numbers.

argh

-

On Tue, Jul 8, 2008 at 2:31 PM, Ben Carney <[EMAIL PROTECTED]> wrote:

> hmm...
>
> I have to say I don't quite know what this [mapping] is. I tried the
> obvious (trying to create a [mapping] object). can I get a bit of a further
> explanation f what you mean, cyrille?
>
>
> thanks
>
>
> On Tue, Jul 8, 2008 at 1:58 PM, cyrille henry <[EMAIL PROTECTED]>
> wrote:
>
>>
>>
>> Ben Carney a écrit :
>>
>>  Hello there list!
>>>
>>> pretty simple question I think, but I'm a bit stumped.
>>>
>>> I have a stream of numbers coming in from a flex sensor and I would love
>>> to be able to grab the lowest number from x amount of numbers, every 30
>>> numbers or so.
>>>
>>> I looked through the [list minmax] example, but could not figure out how
>>> to make it do it "live".
>>>
>>>
>> |
>> [mapping/last_n 30]
>> |
>> [list minmax]
>> |
>>
>> c
>>
>>
>>  much thanks in advance,
>>>
>>>
>>> --
>>>
>>> Ben C.
>>>
>>>
>>> 
>>>
>>> ___
>>> Pd-list@iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>
>
>
> --
>
> Ben C.




-- 

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

Re: [PD] smallest number from a stream of numbers

[Ben Carney]

hmm...

I have to say I don't quite know what this [mapping] is. I tried the obvious
(trying to create a [mapping] object). can I get a bit of a further
explanation f what you mean, cyrille?


thanks

On Tue, Jul 8, 2008 at 1:58 PM, cyrille henry <[EMAIL PROTECTED]>
wrote:

>
>
> Ben Carney a écrit :
>
>  Hello there list!
>>
>> pretty simple question I think, but I'm a bit stumped.
>>
>> I have a stream of numbers coming in from a flex sensor and I would love
>> to be able to grab the lowest number from x amount of numbers, every 30
>> numbers or so.
>>
>> I looked through the [list minmax] example, but could not figure out how
>> to make it do it "live".
>>
>>
> |
> [mapping/last_n 30]
> |
> [list minmax]
> |
>
> c
>
>
>  much thanks in advance,
>>
>>
>> --
>>
>> Ben C.
>>
>>
>> 
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>


-- 

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

Re: [PD] smallest number from a stream of numbers

[Frank Barknecht]

Hallo,
cyrille henry hat gesagt: // cyrille henry wrote:

> Ben Carney a écrit :
> > Hello there list!
> > 
> > pretty simple question I think, but I'm a bit stumped.
> > 
> > I have a stream of numbers coming in from a flex sensor and I would love 
> > to be able to grab the lowest number from x amount of numbers, every 30 
> > numbers or so.
> > 
> > I looked through the [list minmax] example, but could not figure out how 
> > to make it do it "live".
> > 
> 
>  |
> [mapping/last_n 30]
>  |
> [list minmax]
>  |

Or 

 [list-lastx 30]
 |
 [list-minmax] 
 
if you only want to depend on [list]-abs.

Ciao
-- 
 Frank Barknecht _ __footils.org__

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

Re: [PD] mrpeach osc - pipelist question

[Frank Barknecht]

Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:

> However I can't think of a solution for dealing with "list list a b c" 
> going through [route list] to become "list a b c" then through [list 
> prepend list] to become "list list a b c" and not "list list list a b c", 
> in which case it will end up being trimmed to "list a b c" instead of 
> "list list a b c". But I know I can't just tell you to use [route2] 
> instead of [route] for this case.

Which reminds me to remind people, that most of the [list]-abs
abstractions fail horribly if one of the reserved selectors is part of
a list, because many of the abstractions internally serialize the list
and later repack it.  For example a list "list 1 2 bang 3", when
serialized will give: 

 1 
 2 
 bang
 3

but I don't know of a smart way to repack this to get "list 1 2 bang
3" again. Same for "list list" lists.

Ciao
-- 
 Frank Barknecht _ __footils.org__

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

Re: [PD] smallest number from a stream of numbers

[cyrille henry]

Ben Carney a écrit :
> Hello there list!
> 
> pretty simple question I think, but I'm a bit stumped.
> 
> I have a stream of numbers coming in from a flex sensor and I would love 
> to be able to grab the lowest number from x amount of numbers, every 30 
> numbers or so.
> 
> I looked through the [list minmax] example, but could not figure out how 
> to make it do it "live".
> 

 |
[mapping/last_n 30]
 |
[list minmax]
 |

c


> much thanks in advance,
> 
> 
> -- 
> 
> Ben C.
> 
> 
> 
> 
> ___
> 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

[PD] smallest number from a stream of numbers

[Ben Carney]

Hello there list!

pretty simple question I think, but I'm a bit stumped.

I have a stream of numbers coming in from a flex sensor and I would love to
be able to grab the lowest number from x amount of numbers, every 30 numbers
or so.

I looked through the [list minmax] example, but could not figure out how to
make it do it "live".

much thanks in advance,


-- 

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

Re: [PD] better tabread4~

[cyrille henry]

ok, cool

now, it would also be nice to have a good band limited table reader...

cyrille


Charles Henry a écrit :
> Hey, Cyrille,
> 
> I kind of thought so...  we are quickly running into the law of
> diminishing returns.  I was up late, last night, working on the
> analysis some more.  I think I can have another 6-point version with
> better characteristics tonight.
> 
> Chuck
> 
> On Tue, Jul 8, 2008 at 11:35 AM, cyrille henry
> <[EMAIL PROTECTED]> wrote:
>> hello Chuck,
>>
>> i tested this. (and commited)
>> i think tabread6c~ is a bit better than tabread4c~. but differences are more
>> smaller
>>
>> thx
>>
>> Cyrille
>>
>>
>> Charles Henry a écrit :
>>> On Sat, Jun 28, 2008 at 6:43 AM, cyrille henry
>>> <[EMAIL PROTECTED]> wrote:
>>>
 ok, i'll try that.
 but i don't think adjusting the 2nd derivative is the best thing to do.
 for me, having a 6 point interpolation would be more important.
>>> I put together a 6-point interpolation formula and analyzed it.  For
>>> this I used a 5th degree polynomial, and 6 constraints:
>>>
>>> (I want to change up the notation a bit, and not use the letters a, b,
>>> c, etc... when switching to 6-point.  Y[-2],Y[-1],Y[0], Y[1], Y[2],
>>> Y[3] are the points from the table. a5 is the coefficient of x^5, a4
>>> is the coeff. of x^4, ... a0 is a constant term.  f(x) is the
>>> interpolation polynomial.)
>>>
>>> f(0)=Y[0]
>>> f(1)=Y[1]
>>> f'(0)= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2]
>>> f'(1)= 1/12*Y[-1] - 2/3*Y[0]  + 2/3*Y[2] - 1/12*Y[3]
>>> f''(0)= -1/12*Y[-2] + 4/3*Y[-1] - 5/2*Y[0] + 4/3*Y[1] - 1/12*Y[2]
>>> f''(1)= -1/12*Y[-1] + 4/3*Y[0]  - 5/2*Y[1] + 4/3*Y[2] - 1/12*Y[3]
>>>
>>> This uses improved approximations for the derivative.  One advantage
>>> of going to 6-point interpolation is to get better numerical
>>> derivatives.  These approximations of the 1st and 2nd derivatives are
>>> accurate up to a higher frequency than before.  We can also continue
>>> to increase the number of points arbitrarily, without necessarily
>>> having to increase the degree of the polynomial.  The degree of the
>>> polynomial is only determined by the number of constraints, not the
>>> number of points.
>>>
>>> The coefficients used in this scheme are
>>>
>>> a0= Y[0]
>>> a1= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2]
>>> a2= -1/24*Y[-2] + 2/3*Y[-1] - 5/4*Y[0] + 2/3*Y[1] - 1/24*Y[2]
>>> a3= -3/8*Y[-2] + 13/8*Y[-1] - 35/12*Y[0] + 11/4*Y[1] - 11/8*Y[2] +
>>> 7/24*Y[3]
>>> a4= 13/24*Y[-2] - 8/3*Y[-1] + 21/4*Y[0] - 31/6*Y[1] + 61/24*Y[2] -
>>> 1/2*Y[3]
>>> a5= -5/24*Y[-2] + 25/24*y[-1] - 25/12*Y[0] + 25/12*Y[1] - 25/24*Y[2] +
>>> 5/24*Y[3]
>>>
>>>
>>> After that, I continued with the impulse response calculations and
>>> spectral response calculations, which are a bit disappointing.  I'll
>>> spare you the equations (for now) and post the graphs.  The new traces
>>> for the 6-point interpolator are shown in green.  It's a little bit
>>> hard to see, but the things to look for are the rate at which the
>>> graph falls off and the locations of the peaks.  The 6-point function
>>> has a flatter spectrum, which comes up closer to the Nyquist
>>> frequency, and falls off faster.  These are the key characteristics of
>>> the spectrum we want.  The green trace falls off according to 1/w^4,
>>> compared to 1/w^3 for tabread4c~ and 1/w^2 for tabread4~
>>>
>>> You can see the impulse response in the first graph along with the
>>> spectrum.  The log vs. dB scale is used same as before, and secondly,
>>> I've posted a linear graph, so you can see the difference between
>>> functions near the Nyquist frequency (x=pi).
>>>
>>> It gives me some ideas for another 6-point scheme, more like
>>> tabread4c~, which will fall off at a rate of 1/w^5 and have more
>>> notches in the frequency response.  I'll work on it a bit, and see how
>>> it goes.
>>>
>>> Chuck
>>>
>>>
>>> 
>>>
>>>
>>> 
>>>
>>>
>>> 
>>>
>>> ___
>>> 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] better tabread4~

[Charles Henry]

Hey, Cyrille,

I kind of thought so...  we are quickly running into the law of
diminishing returns.  I was up late, last night, working on the
analysis some more.  I think I can have another 6-point version with
better characteristics tonight.

Chuck

On Tue, Jul 8, 2008 at 11:35 AM, cyrille henry
<[EMAIL PROTECTED]> wrote:
> hello Chuck,
>
> i tested this. (and commited)
> i think tabread6c~ is a bit better than tabread4c~. but differences are more
> smaller
>
> thx
>
> Cyrille
>
>
> Charles Henry a écrit :
>>
>> On Sat, Jun 28, 2008 at 6:43 AM, cyrille henry
>> <[EMAIL PROTECTED]> wrote:
>>
>>> ok, i'll try that.
>>> but i don't think adjusting the 2nd derivative is the best thing to do.
>>> for me, having a 6 point interpolation would be more important.
>>
>> I put together a 6-point interpolation formula and analyzed it.  For
>> this I used a 5th degree polynomial, and 6 constraints:
>>
>> (I want to change up the notation a bit, and not use the letters a, b,
>> c, etc... when switching to 6-point.  Y[-2],Y[-1],Y[0], Y[1], Y[2],
>> Y[3] are the points from the table. a5 is the coefficient of x^5, a4
>> is the coeff. of x^4, ... a0 is a constant term.  f(x) is the
>> interpolation polynomial.)
>>
>> f(0)=Y[0]
>> f(1)=Y[1]
>> f'(0)= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2]
>> f'(1)= 1/12*Y[-1] - 2/3*Y[0]  + 2/3*Y[2] - 1/12*Y[3]
>> f''(0)= -1/12*Y[-2] + 4/3*Y[-1] - 5/2*Y[0] + 4/3*Y[1] - 1/12*Y[2]
>> f''(1)= -1/12*Y[-1] + 4/3*Y[0]  - 5/2*Y[1] + 4/3*Y[2] - 1/12*Y[3]
>>
>> This uses improved approximations for the derivative.  One advantage
>> of going to 6-point interpolation is to get better numerical
>> derivatives.  These approximations of the 1st and 2nd derivatives are
>> accurate up to a higher frequency than before.  We can also continue
>> to increase the number of points arbitrarily, without necessarily
>> having to increase the degree of the polynomial.  The degree of the
>> polynomial is only determined by the number of constraints, not the
>> number of points.
>>
>> The coefficients used in this scheme are
>>
>> a0= Y[0]
>> a1= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2]
>> a2= -1/24*Y[-2] + 2/3*Y[-1] - 5/4*Y[0] + 2/3*Y[1] - 1/24*Y[2]
>> a3= -3/8*Y[-2] + 13/8*Y[-1] - 35/12*Y[0] + 11/4*Y[1] - 11/8*Y[2] +
>> 7/24*Y[3]
>> a4= 13/24*Y[-2] - 8/3*Y[-1] + 21/4*Y[0] - 31/6*Y[1] + 61/24*Y[2] -
>> 1/2*Y[3]
>> a5= -5/24*Y[-2] + 25/24*y[-1] - 25/12*Y[0] + 25/12*Y[1] - 25/24*Y[2] +
>> 5/24*Y[3]
>>
>>
>> After that, I continued with the impulse response calculations and
>> spectral response calculations, which are a bit disappointing.  I'll
>> spare you the equations (for now) and post the graphs.  The new traces
>> for the 6-point interpolator are shown in green.  It's a little bit
>> hard to see, but the things to look for are the rate at which the
>> graph falls off and the locations of the peaks.  The 6-point function
>> has a flatter spectrum, which comes up closer to the Nyquist
>> frequency, and falls off faster.  These are the key characteristics of
>> the spectrum we want.  The green trace falls off according to 1/w^4,
>> compared to 1/w^3 for tabread4c~ and 1/w^2 for tabread4~
>>
>> You can see the impulse response in the first graph along with the
>> spectrum.  The log vs. dB scale is used same as before, and secondly,
>> I've posted a linear graph, so you can see the difference between
>> functions near the Nyquist frequency (x=pi).
>>
>> It gives me some ideas for another 6-point scheme, more like
>> tabread4c~, which will fall off at a rate of 1/w^5 and have more
>> notches in the frequency response.  I'll work on it a bit, and see how
>> it goes.
>>
>> Chuck
>>
>>
>> 
>>
>>
>> 
>>
>>
>> 
>>
>> ___
>> 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] mrpeach osc - pipelist question

[Mathieu Bouchard]

On Tue, 8 Jul 2008, Martin Peach wrote:

It has 'clear' and 'flush'. I suppose (without trying it right now) that 
those two will be interpreted as messages to pipelist, since the 
'anything' method is called as a last resort by Pd when no method 
matches the selector. Perhaps renaming them to 'clearpipe' and 
'flushpipe' would reduce the possibility of confusion;


You can eliminate the possibility of confusion by requiring that a "send" 
selector be prepended, just like it is for [netsend]. However, [list 
prepend send] doesn't cut it because [route send] doesn't undo it 
properly: "list a b c" becomes "a b c"... see my last email.


We need something called [list untrim] and/or [unroute].

C'est assez déroutant... ou dégoûtant: c'est selon.

 _ _ __ ___ _  _ _ ...
| 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] Seam carving audio

[Ico Doornekamp]

* On 2008-07-08 hard off <[EMAIL PROTECTED]> wrote  :

> i'm thinking about how you'd do this,
> 
> and the picture in my mind is of a single 2 second long clarinet note with a
> hihat being hit after about 1 second.
> 
> so, if you were going to stretch or compress that, you'd want to preserve
> the parts with the most 'colour' ...which i would guess would be the attack
> of the clarinet and then especially the attack of the hihat.

Maybe a bit too naive approach, but what about chopping up the audio in
small fragments, and discarts fragments that have about the same
spectral footprint as their neighbours ? This will leave the dynamic
parts intact and leaves out the 'boring' bits.

Ico

-- 
:wq
^X^Cy^K^X^C^C^C^C

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

Re: [PD] mrpeach osc - pipelist question

[Mathieu Bouchard]

On Tue, 8 Jul 2008, IOhannes m zmoelnig wrote:

(the other, more clumsy solution was of course to use 
[list]->[pipelist]->[list trim])


This doesn't work with real lists, because [list] won't prepend an extra 
list selector, so [list trim] will remove that when $1 is a symbol. Then 
you can use [route list] to distinguish that, but it will have the side 
effect of removing the list selector from a list when $1 is a symbol, but 
you can add it back once or twice using [list prepend list], which will 
add it twice when $1 was a symbol (except "list"), and once otherwise; 
then [list trim] will exactly undo the [list prepend list] or the [list] 
that the message went through depending on the case.


e.g. "a b c" becomes "list a b c" and then "a b c" again, fine, but your 
way, "list a b c" stays "list a b c" and then becomes "a b c", which is 
wrong; instead you [route list] which turns "list a b c" into "a b c", at 
which point you know it was a list that you just trimmed, therefore with 
[list prepend list] it becomes "list list a b c" which will go through 
[list trim] to become "list a b c".


However I can't think of a solution for dealing with "list list a b c" 
going through [route list] to become "list a b c" then through [list 
prepend list] to become "list list a b c" and not "list list list a b c", 
in which case it will end up being trimmed to "list a b c" instead of 
"list list a b c". But I know I can't just tell you to use [route2] 
instead of [route] for this case.


 _ _ __ ___ _  _ _ ...
| 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] delay problems

[Frank Barknecht]

Hallo,
Ricardo Dueñas Parada hat gesagt: // Ricardo Dueñas Parada wrote:

> Sometimes the object delay doesn't work correctly, I mean, if I put a 500,
> I expect to have a 500 ms bang delay. And it does, but when it wants.
> Other times it just let the bang pass, as with 0 delay.
> 
> Most of the times it happens when I have a delay right after an inlet,
> seriously I don?t know what could be happening.
>
> I correct it by changing the value of the delay, usually to 1000, and it works
> correctly, then I rewrite the correct value.

I'm pretty sure that [delay] in Pd works correctly, unless there are
new bugs, which everyone and their sister would already shout about by
now in an object as important as delay.  

If it works correctly, the only reason for the behaviour you describe
that I can think of is that you are sending a number instead of a bang
to [delay] at certain times. 

Sending a number to the delay on *both* inlets will change the delay
time. The change happens immediatly, if you send the number to the
hot, left inlet, and on the next bang, if you used the cold inlet for
the number.

You could insert a [bang] object before the [delay] to get rid of the
numbers, but maybe first find out, where the numbers come from.

Ciao
-- 
 Frank Barknecht _ __footils.org__

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

Re: [PD] delay problems

[Claude Heiland-Allen]

Ricardo Dueñas Parada wrote:
> Hi list, I want to ask you about a problem I'm having for a while.
> 
> Sometimes the object delay doesn't work correctly, I mean, if I put a 500,
> I expect to have a 500 ms bang delay. And it does, but when it wants.
> Other times it just let the bang pass, as with 0 delay.
> 
> Most of the times it happens when I have a delay right after an inlet,
> seriously I don´t know what could be happening.

put a [bang] object right after the inlet, to ensure you are really 
getting only bangs and not some other messages that delay understands...

> 
> I correct it by changing the value of the delay, usually to 1000, and it works
> correctly, then I rewrite the correct value.
> 
> Any idea?
> 
> _Ricardo
> 
> ___
> 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

[PD] delay problems

[Ricardo Dueñas Parada]

Hi list, I want to ask you about a problem I'm having for a while.

Sometimes the object delay doesn't work correctly, I mean, if I put a 500,
I expect to have a 500 ms bang delay. And it does, but when it wants.
Other times it just let the bang pass, as with 0 delay.

Most of the times it happens when I have a delay right after an inlet,
seriously I don´t know what could be happening.

I correct it by changing the value of the delay, usually to 1000, and it works
correctly, then I rewrite the correct value.

Any idea?

_Ricardo

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

Re: [PD] better tabread4~

[cyrille henry]

hello Chuck,

i tested this. (and commited)
i think tabread6c~ is a bit better than tabread4c~. but differences are more 
smaller

thx

Cyrille


Charles Henry a écrit :
> On Sat, Jun 28, 2008 at 6:43 AM, cyrille henry
> <[EMAIL PROTECTED]> wrote:
> 
>> ok, i'll try that.
>> but i don't think adjusting the 2nd derivative is the best thing to do.
>> for me, having a 6 point interpolation would be more important.
> 
> I put together a 6-point interpolation formula and analyzed it.  For
> this I used a 5th degree polynomial, and 6 constraints:
> 
> (I want to change up the notation a bit, and not use the letters a, b,
> c, etc... when switching to 6-point.  Y[-2],Y[-1],Y[0], Y[1], Y[2],
> Y[3] are the points from the table. a5 is the coefficient of x^5, a4
> is the coeff. of x^4, ... a0 is a constant term.  f(x) is the
> interpolation polynomial.)
> 
> f(0)=Y[0]
> f(1)=Y[1]
> f'(0)= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2]
> f'(1)= 1/12*Y[-1] - 2/3*Y[0]  + 2/3*Y[2] - 1/12*Y[3]
> f''(0)= -1/12*Y[-2] + 4/3*Y[-1] - 5/2*Y[0] + 4/3*Y[1] - 1/12*Y[2]
> f''(1)= -1/12*Y[-1] + 4/3*Y[0]  - 5/2*Y[1] + 4/3*Y[2] - 1/12*Y[3]
> 
> This uses improved approximations for the derivative.  One advantage
> of going to 6-point interpolation is to get better numerical
> derivatives.  These approximations of the 1st and 2nd derivatives are
> accurate up to a higher frequency than before.  We can also continue
> to increase the number of points arbitrarily, without necessarily
> having to increase the degree of the polynomial.  The degree of the
> polynomial is only determined by the number of constraints, not the
> number of points.
> 
> The coefficients used in this scheme are
> 
> a0= Y[0]
> a1= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2]
> a2= -1/24*Y[-2] + 2/3*Y[-1] - 5/4*Y[0] + 2/3*Y[1] - 1/24*Y[2]
> a3= -3/8*Y[-2] + 13/8*Y[-1] - 35/12*Y[0] + 11/4*Y[1] - 11/8*Y[2] + 7/24*Y[3]
> a4= 13/24*Y[-2] - 8/3*Y[-1] + 21/4*Y[0] - 31/6*Y[1] + 61/24*Y[2] - 1/2*Y[3]
> a5= -5/24*Y[-2] + 25/24*y[-1] - 25/12*Y[0] + 25/12*Y[1] - 25/24*Y[2] + 
> 5/24*Y[3]
> 
> 
> After that, I continued with the impulse response calculations and
> spectral response calculations, which are a bit disappointing.  I'll
> spare you the equations (for now) and post the graphs.  The new traces
> for the 6-point interpolator are shown in green.  It's a little bit
> hard to see, but the things to look for are the rate at which the
> graph falls off and the locations of the peaks.  The 6-point function
> has a flatter spectrum, which comes up closer to the Nyquist
> frequency, and falls off faster.  These are the key characteristics of
> the spectrum we want.  The green trace falls off according to 1/w^4,
> compared to 1/w^3 for tabread4c~ and 1/w^2 for tabread4~
> 
> You can see the impulse response in the first graph along with the
> spectrum.  The log vs. dB scale is used same as before, and secondly,
> I've posted a linear graph, so you can see the difference between
> functions near the Nyquist frequency (x=pi).
> 
> It gives me some ideas for another 6-point scheme, more like
> tabread4c~, which will fall off at a rate of 1/w^5 and have more
> notches in the frequency response.  I'll work on it a bit, and see how
> it goes.
> 
> Chuck
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] Seam carving audio

[Mathieu Bouchard]

On Tue, 8 Jul 2008, Damian Stewart wrote:

(i'm reminded of a particular electroacoustic composition tutorial class 
i attended when studying a couple of years ago, where we were being 
taught to use SoundHack and the tutor was saying all sorts of things to 
us like 'you should use the Hanning window here because it sounds best' 
and 'don't use settings here below  because it won't sound good'. i 
managed to convince him to demonstrate what 'sounding bad' was like, and 
then we spent the rest of the tutorial playing with settings and making 
'bad sounding' audio. it was great.)


Yes. As I said, I'm sure you can get pretty cool sounds out of this 
effect, but if all you're looking for is a way to make a cleaner kind of 
stretching/shrinking, it's the wrong place to look for it, which is why I 
was being negative about it. If the point is to make funny-sounding stuff, 
you probably have something more interesting than a shovelful of allpass 
filtres here.


On a related note, gridflow/examples/postdigital.pd is an example of 
messing with a setting called "quality", _lowering_ it until it looks so 
low-fidelity that it becomes _interesting_. Then it shows the frame 
difference with the original image, which is even more fun. I think of 
postdigitalism as about not taking quality settings literally, which is 
why I came up with this patch under that name, or came up with that name 
for that patch.


Note that my use of the term is tongue-in-cheek and I haven't read Kim 
Cascone nor Roy Ascott, and chances are that I'm not going to do it soon 
(I have a large pile of unread books in the queue and it doesn't get any 
smaller). But I enjoy talking about those æsthetical issues a lot, just 
that I tend to use my existing background instead, which may give wholly 
different results... e.g.: what if Claude Shannon had written a book named 
«Différence et Répétition»? that's the kind of question I sometimes ask 
myself.


 _ _ __ ___ _  _ _ ...
| 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] Seam carving audio

[hard off]

i'm thinking about how you'd do this,

and the picture in my mind is of a single 2 second long clarinet note with a
hihat being hit after about 1 second.

so, if you were going to stretch or compress that, you'd want to preserve
the parts with the most 'colour' ...which i would guess would be the attack
of the clarinet and then especially the attack of the hihat.

[bonk~] will find those bits for you quite easily. so you can just mark the
sections bonk~ finds and set them as 'do not touch'

but the hard part is stretching the remaining sections.  i think ableton and
melodyne have good approaches for this, and from what i can gather it's a
good granular approach with the grain length being constantly adjusted so
that the playback doesn't introduce too much AM effect.

i have a feeling they also do a pitch analysis, so that the playback grain
length can be adjusted longer for lower overall pitch and shorter for higher
pitched sections.


i could be completely wrong of course.  wouldn't be the first time. :)
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Seam carving audio

[Damian Stewart]

Chris McCormick schreef:
> This might sound
> like a mess, but I'd like to hear it.

(i'm reminded of a particular electroacoustic composition tutorial class 
i attended when studying a couple of years ago, where we were being 
taught to use SoundHack and the tutor was saying all sorts of things to 
us like 'you should use the Hanning window here because it sounds best' 
and 'don't use settings here below  because it won't sound good'. i 
managed to convince him to demonstrate what 'sounding bad' was like, and 
then we spent the rest of the tutorial playing with settings and making 
'bad sounding' audio. it was great.)

d

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

Re: [PD] Seam carving audio

[Damian Stewart]

Chris McCormick schreef:
> Isn't part of what makes a note perceptible it's higher energy compared
> to the surrounding space in the spectrogram? If this is the case, seam
> carving would delete seams around the notes since they have less energy,
> whilst preserving the sounds of the notes themselves. This might sound
> like a mess, but I'd like to hear it.
> 
> Maybe I sould just do it.

that's the spirit. i reckon it could sound super-amazing. let me know if 
you give it a go, and pass on a link to the audio results...

d

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

Re: [PD] Seam carving audio

[Mathieu Bouchard]

On Tue, 8 Jul 2008, Chris McCormick wrote:

Compared to the "deleting least important columns" technique that they 
show at 1:40, the Seam Carving technique sweeps the distorsions under 
the carpet. After that, don't wonder what the big lump under the carpet 
is.

Yes, that is the exact point of seam carving. I'm not sure why you're
putting a negative lumps-under-the-carpet slant on the idea.


Well, it's only negative if someone is going to be using this as if it 
were for _scaling_ the picture. If from the start it's clear that this is 
going to be an effect that is quite special, it's alright. I wouldn't like 
to have this to resize images in a web browser, for example.



When applying the technique to the spectrogram of a song, you should hear
it many times more than you'd see it.

I take it this is speculation. I am interested to know if anyone has
tried it and listened to the results.


No, I haven't listened to it. So I suppose that what I say doesn't count.

Isn't part of what makes a note perceptible it's higher energy compared 
to the surrounding space in the spectrogram?


Yes, but it all depends on how you define "energy" for the occasion. 
Throughout the video, the concept of energy is redefined (e.g.: to edit 
people out), but even their original definition is somewhat 
special-purpose, just like it usually is in image processing... I mean 
that there is no standard definition for it in image processing.



Maybe I sould just do it.


You should do it because you will not hear about anyone that has actually 
tried it, and you want to know what it is really like, not what I think it 
will do. I still recommend that you do it on an actual score instead of 
(or in addition to) a spectrogram.


 _ _ __ ___ _  _ _ ...
| 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] Seam carving audio

[Chris McCormick]

On Tue, Jul 08, 2008 at 02:53:56AM -0400, Mathieu Bouchard wrote:
> On Mon, 9 Jun 2008, Chris McCormick wrote:
> 
> >Something struck me whilst out walking today; has anyone applied the
> >seam carving technique:
> >
> >
> >to FFT data to do a timestretch/timecompress that is more sensitive to
> >attack sounds and note lengths?
> 
> Compared to the "deleting 
> least important columns" technique that they show at 1:40, the Seam 
> Carving technique sweeps the distorsions under the carpet. After that, 
> don't wonder what the big lump under the carpet is.

Yes, that is the exact point of seam carving. I'm not sure why you're
putting a negative lumps-under-the-carpet slant on the idea.

> When applying the technique to the spectrogram of a song, you should hear 
> it many times more than you'd see it.

I take it this is speculation. I am interested to know if anyone has
tried it and listened to the results.

> Perhaps it can be used as an interesting special effect, supposing that 
> what you want to do is mess up the rhythm seriously and turn chords into 
> arpeggios in truly weird ways. However, it will work at the sine wave 
> level, which is somewhat less attractive than if it worked on notes.

Isn't part of what makes a note perceptible it's higher energy compared
to the surrounding space in the spectrogram? If this is the case, seam
carving would delete seams around the notes since they have less energy,
whilst preserving the sounds of the notes themselves. This might sound
like a mess, but I'd like to hear it.

Maybe I sould just do it.

Chris.

---
http://mccormick.cx

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

Re: [PD] mrpeach osc - pipelist question

[Martin Peach]

IOhannes m zmoelnig wrote:
> Martin Peach wrote:
 make [pipelist] accept lists without the list selector (aka
 meta-messages) then.
>>> i agree.
>> OK, the latest [pipelist] in svn pipes lists as well as meta-messages.
>>
> 
> the problem with this is that the object behaves "weird" if it is also 
> meant to have "special" messages.
> 
> e.g. [pipelist] had a special message "clear" (or so).
> now what happens if it pipes just _any_ message: will "clear" be piped 
> or will it clear the buffer?

It has 'clear' and 'flush'. I suppose (without trying it right now) that 
those two will be interpreted as messages to pipelist, since the 
'anything' method is called as a last resort by Pd when no method 
matches the selector.
Perhaps renaming them to 'clearpipe' and 'flushpipe' would reduce the 
possibility of confusion; it's unlikely that anyone would want to send 
those two messages for any other reason, except to be perverse, like 
sending a clear message to a second pipelist...


> whatever you chose, people will complain.
> 
> i was a bit hasty when i shouted "i agree"
> 
> 
> (the other, more clumsy solution was of course to use 
> [list]->[pipelist]->[list trim])
> 

Well now it handles lists as well as meta-messages, so you could do that 
as well, and send 'list clear' if you don't want 'clear' to be interpreted.

Martin


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

Re: [PD] print all abstractions and externals

[Claude Heiland-Allen]

Hi,

Yet another approach ;)

I've got a suite of bash scripts that help narrow down which externals 
are missing.  Here's a real-life-example:

--8<--
[EMAIL PROTECTED]:~/maximus/pdpatchinfo$ cat ../2007/d01234two/*.pd | 
./objs.sh | ./externals.sh pd-0.41-4.txt | ./externals.sh Gem.txt  | 
./abstractions.sh ../2007/d01234two/
0
1
analogue_adsr~
complex-mod~
expr
expr~
hilbert~
#in
mtx_.*
mtx_diag
mtx_mul
#out
repeat
#store
[EMAIL PROTECTED]:~/maximus/pdpatchinfo$
--8<--

Which reminds me I need gridflow, zexy and iemmatrix to run that patch, 
plus some objs that are bundled with pd, and a home-brewed external.

I patched one of my installed versions of Pd to print out every class 
registered with Pd during load time, which can then be massaged into a 
raw list of objects for each library (eg: Gem.txt).


Claude
-- 
http://claudiusmaximus.goto10.org


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

Re: [PD] print all abstractions and externals

[IOhannes m zmoelnig]

João Pais wrote:
> you mentioned 64bit, and the other things, do you know of any place 
> where to find a small reference about that? now I am curious. I usually 
> update the version anyway, but more for sport than after a 
> carefully-pondered reflexion (in the case of Pd).
> 

well, in theory it _should_ be in /src/notes.txt, but this is 
probably the worst maintained part of Pd :-(
also the CHANGELOG.txt gives some wee hints (but not very satisfactory 
either)
and generating a ChangeLog from the svn-commits helps even less.

so in short, i don't know of any place where to find out what actually 
changed, apart from reading pd-dev, watching the sf-tracker for which 
patches got included by miller and diffing the code.

i think that none of these options is nice.

fgmasdr
IOhannes


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

Re: [PD] print all abstractions and externals

[João Pais]

> i was trying to say that you are obviously not trying to run a native  
> 64bit system (with a 64bit kernel and running Pd as 64bit application)
>
> the good thing about amd64/emt64 is, that they can also run 32bit (i386).
>
> anyhow, if you want to run Pd in as a native 64bit app, you will need  
> Pd-0.41

ah, that not yet. it should take a while until I get to that (if I do).


>>> after all, if you don't need all the list-stuff and  
>>> multiple-dollarg-expansion ($1-$2), you might as well not notice a  
>>> difference between 0.39 and 0.40
>>  I can't even be sure of what you're talking about, so probably I don't  
>> (or maybe I would, if I was aware of it?). Were they properly  
>> documented somewhere?
>
> it's not necessarily a matter of documentation (though both have been  
> discussed on this list so many times, that at least the list-archives  
> should serve well as documentation :-)). what i wanted to say is, that  
> if you don't care for any _new_ feature, then it is clear that you will  
> not see a difference between a version w/ and one lacking these features.

I brought the documentation up, because I'm not aware of the newest  
features that should make me (or anyone?) choose one version to the other  
(having not had to stolper on them during work). I can spend the whole  
afternoon looking in the list for fragments of opinios, but is that really  
a viable solution?
you mentioned 64bit, and the other things, do you know of any place where  
to find a small reference about that? now I am curious. I usually update  
the version anyway, but more for sport than after a carefully-pondered  
reflexion (in the case of Pd).



>> their time [please don't bring up the "if they would really want it..."  
>> argument]. pd-van should check that out and try to catch up at some time
>
> i am not trying to start another religious war here.

me neither. I just see that kind of reply over and over, and I add this  
disclaimer now and then, just to make sure.

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

Re: [PD] print all abstractions and externals

[Luigi Rensinghoff]

Great !!!

Thats very helpful..

Is it diffcult to implement detecting abstractions within  
abstractions ???



That would be perfect

Cheers Luigi

Am 04.07.2008 um 13:20 schrieb Hans-Christoph Steiner:


I've made a patch that might be useful for others. In the attached
patch you can open a pd-file and the main window prints all the
abstractions or externals that you need to make the patch work. It
doesn't detect abstractions within abstractions though and it also
prints objects like [5] or [$1], I didn't find a solution for this
(small) problem yet. (I'd think it is bad pratice to use [5] in
sted of [5(  or am I wrong?)
I wanted to make a patch that copied all the necessary abstractions
and the file itself to a new folder but I ended up with this
simpler solution...


>---<

Luigi Rensinghoff
[EMAIL PROTECTED]
skype:gigischinke
ichat:gigicarlo




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

Re: [PD] print all abstractions and externals

[IOhannes m zmoelnig]

João Pais wrote:
>> by any chance, you are not running an amd64 system? (this is getting 
>> hot ground for me, as i am not so sure whether PdX actually does have 
>> some x86_64 patches incorporated; but chances are low)
> 
> my new desktop is a 64 d-core intel, I have windows and ubuntu there. 


i was trying to say that you are obviously not trying to run a native 
64bit system (with a 64bit kernel and running Pd as 64bit application)

the good thing about amd64/emt64 is, that they can also run 32bit (i386).

anyhow, if you want to run Pd in as a native 64bit app, you will need 
Pd-0.41

> 
>> after all, if you don't need all the list-stuff and 
>> multiple-dollarg-expansion ($1-$2), you might as well not notice a 
>> difference between 0.39 and 0.40
> 
> I can't even be sure of what you're talking about, so probably I don't 
> (or maybe I would, if I was aware of it?). Were they properly documented 
> somewhere?

it's not necessarily a matter of documentation (though both have been 
discussed on this list so many times, that at least the list-archives 
should serve well as documentation :-)). what i wanted to say is, that 
if you don't care for any _new_ feature, then it is clear that you will 
not see a difference between a version w/ and one lacking these features.

> their time [please don't bring up the "if they would really want it..." 
> argument]. pd-van should check that out and try to catch up at some time 

i am not trying to start another religious war here.



mfg.asdf
IOhannes

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

Re: [PD] print all abstractions and externals

[João Pais]

>> I meant the latest usable (which I have installed) builds of  
>> pd-extended, and the last version of  
>> pd-vanilla-without-documentation-about-data-strucutures-and-so-on (also  
>> being unfair).
>> I haven't being using pd too much these days for sound, but in the last  
>> builds of pd-ext I didn't notice anything that was behind pd-van.  
>> before I was using pd-van .41 because of the symbol grab feature in the  
>> data structures (which I only know about because I requested it, it's  
>> not documented). as this feature is now possible in the current build  
>> of pd-ext, I notice no differences between them.
>
> ok, but this seems to be a bit subjective evaluation.

it's not scientific at all, and I haven't been following the news.


> by any chance, you are not running an amd64 system? (this is getting hot  
> ground for me, as i am not so sure whether PdX actually does have some  
> x86_64 patches incorporated; but chances are low)

my new desktop is a 64 d-core intel, I have windows and ubuntu there. it's  
still new, so I didn't work much with it so far. in windows works well,  
but I can't get ubuntu to access my quite normal home network, so I didn't  
got further on that. I can do some testing, if you want (just tell me what  
to do).


> and you are probably also not very interested in audio-computation on  
> demand...

my stuff isn't the most demanding in terms of cpu. I either play in my  
trio www.endphase.net (our patches aren't that heavy), or for my private  
composition tools, which in these days do more information than audio  
processing. I never even opened up a vst plugin in pd so far, and I'm  
happy with latency of 70ms in windows for now (didn't fiddled enough in  
ubuntu to try to bring it lower than that).


> after all, if you don't need all the list-stuff and  
> multiple-dollarg-expansion ($1-$2), you might as well not notice a  
> difference between 0.39 and 0.40

I can't even be sure of what you're talking about, so probably I don't (or  
maybe I would, if I was aware of it?). Were they properly documented  
somewhere?
The one detail that made me stick to pd-van-.41 for a while was the  
"symbol" option in [struct] and the [set -symbol] feature (because of an  
important patch for me) - which I only know about because I asked for it  
(it's not documented, I think). Besides that I don't know exactly what are  
the benefits.


But in a general remark I would say that pd-ext is making a very big step  
in improving the quality of the interface and its integration in the  
system (I speak mainly of windows) - as also with the developper  
community. That's an important step for users that aren't willing to make  
a big effort to stick with pd or have better things to do with their time  
[please don't bring up the "if they would really want it..." argument].  
pd-van should check that out and try to catch up at some time as well (or  
just fuse into pd-ext, if there are no differences in quality - I'm not  
qualified to judge that).


João

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

Re: [PD] print all abstractions and externals

[IOhannes m zmoelnig]

João Pais wrote:
> I meant the latest usable (which I have installed) builds of 
> pd-extended, and the last version of 
> pd-vanilla-without-documentation-about-data-strucutures-and-so-on (also 
> being unfair).
> I haven't being using pd too much these days for sound, but in the last 
> builds of pd-ext I didn't notice anything that was behind pd-van. before 
> I was using pd-van .41 because of the symbol grab feature in the data 
> structures (which I only know about because I requested it, it's not 
> documented). as this feature is now possible in the current build of 
> pd-ext, I notice no differences between them.

ok, but this seems to be a bit subjective evaluation.

by any chance, you are not running an amd64 system? (this is getting hot 
ground for me, as i am not so sure whether PdX actually does have some 
x86_64 patches incorporated; but chances are low)

and you are probably also not very interested in audio-computation on 
demand...

after all, if you don't need all the list-stuff and 
multiple-dollarg-expansion ($1-$2), you might as well not notice a 
difference between 0.39 and 0.40


gasdr
IOhannes

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

Re: [PD] print all abstractions and externals

[João Pais]

> with "in parallel versions", do you mean the latest officially released  
> versions "Pd-0.41-4" vs "Pd-extended-0.39.3" or not-yet released  
> versions "Pd-0.42.0-test1" vs "Pd-extended-0.40-rc4"?

I meant the latest usable (which I have installed) builds of pd-extended,  
and the last version of  
pd-vanilla-without-documentation-about-data-strucutures-and-so-on (also  
being unfair).
I haven't being using pd too much these days for sound, but in the last  
builds of pd-ext I didn't notice anything that was behind pd-van. before I  
was using pd-van .41 because of the symbol grab feature in the data  
structures (which I only know about because I requested it, it's not  
documented). as this feature is now possible in the current build of  
pd-ext, I notice no differences between them.


> (admittedly the latter is a bit unfair, as Pd's 0.42 is imho not useable  
> at all while PdX's release-candidate is almost there; anyhow it's not  
> what i would call "parallel versions" yet)
>
> fgmasdr
> IOhannes
>



-- 
Friedenstr. 58
10249 Berlin
Deutschland
Tel +49 30 42020091
Mob +49 162 6843570
[EMAIL PROTECTED]
skype: jmmmpjmmmp
http://www.puredata.org/Members/jmmmp
IBM Thinkpad R51, XP, Ubuntu GG
Pd-Ext-0.39-2-t5, Pd Van 0.40-t2

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

Re: [PD] mrpeach osc - pipelist question

[IOhannes m zmoelnig]

Martin Peach wrote:
>>> make [pipelist] accept lists without the list selector (aka
>>> meta-messages) then.
>> i agree.
> 
> OK, the latest [pipelist] in svn pipes lists as well as meta-messages.
> 

the problem with this is that the object behaves "weird" if it is also 
meant to have "special" messages.

e.g. [pipelist] had a special message "clear" (or so).
now what happens if it pipes just _any_ message: will "clear" be piped 
or will it clear the buffer?
whatever you chose, people will complain.

i was a bit hasty when i shouted "i agree"


(the other, more clumsy solution was of course to use 
[list]->[pipelist]->[list trim])


fgmadsr
IOhannes

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

Re: [PD] Delete scalars

[Mathieu Bouchard]

On Sat, 14 Jun 2008, Miller Puckette wrote:


I'm thinking about making a message to "pointer" that deletes the object
after the pointed-to one (thus leaving the pointer itself unchanged) --
the gotch is that it would "stalify" all other pointers to the list, at
least as things are currently implemented.


So, why are singly-linked-lists so crucial to the design of Pd ?

 _ _ __ ___ _  _ _ ...
| 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] print all abstractions and externals

[IOhannes m zmoelnig]

João Pais wrote:
> Hi,
> I  guess new users use extended, since both are now in parallel versions.

with "in parallel versions", do you mean the latest officially released 
versions "Pd-0.41-4" vs "Pd-extended-0.39.3" or not-yet released 
versions "Pd-0.42.0-test1" vs "Pd-extended-0.40-rc4"?

(admittedly the latter is a bit unfair, as Pd's 0.42 is imho not useable 
at all while PdX's release-candidate is almost there; anyhow it's not 
what i would call "parallel versions" yet)

fgmasdr
IOhannes


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