date:20061112


Yves Degoyon wrote:


well, i must say the first agressive message was not mine,
but like, 'pd is shit - i will buy a serious software'


dude, i never said 'pd is shit'. i think pd is awesome, i just don't think 
it's for me.



i just said ok for this,
but i didn't know you really tried on linux,
so it's a pity your usb card doesn't work,
could you give more details?


maybe when i can be bothered pissing around with it again. last time it 
swallowed two full days of my life that i'm never going to get back.


--
Damian Stewart
+64 27 305 4107

f r e y
live music with machines
http://www.frey.co.nz
http://www.myspace.com/freyed


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

Re: [PD] gate object changing type - ?


Hans-Christoph Steiner wrote:


Wow, that's a crazy bug.  If you are still willing, I'd like to help you 
get things building on Windows/MinGW.  And the best place to post good 
bug reports like this is the bugtracker:


http://puredata.org/dev/bugtracker


done

--
Damian Stewart
+64 27 305 4107

f r e y
live music with machines
http://www.frey.co.nz
http://www.myspace.com/freyed


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

Re: [PD] windows compile - one last try


Hans-Christoph Steiner wrote:


Damian, which CPU does your machine have?


it's a p4-m (NOT a pentium-M)

i haven't used the patch in question in ages and to be fair haven't really 
noticed too many other issues.. except for the one time i tried to 
live-code a patch with a *lot* of VU objects, which was not such a good 
idea in the first place anyway.


--
Damian Stewart
+64 27 305 4107

f r e y
live music with machines
http://www.frey.co.nz
http://www.myspace.com/freyed


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

Re: [PD] rradical/cyclone tosymbol crashes pd


Hans-Christoph Steiner wrote:


One place to start is using the nightly builds.


i had to downgrade back to my old version as the 2006-11-08 nightly didn't 
load a bunch of libs, some of which i appear to need for my patches the 
ones that failed were gem, fftease, hid, iemabs, iemmatrix, liblist, pdp, 
pidip, vasp, xsample, iemlib32, iem_t3_lib, iemlib1, mtx).


--
Damian Stewart
+64 27 305 4107

f r e y
live music with machines
http://www.frey.co.nz
http://www.myspace.com/freyed


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

Re: [PD] win32: toxy/widget issues


Hans-Christoph Steiner wrote:


And check the CVS for the ix widgets.


how do i do this? i know how to use CVS, i'm just not sure of which server, 
which module, or which version to use.


If that version is working fine, then we should probably use it in the 
Pd-extended release version.  Can you guys test it and see?


loading scale-test.pd with that version gives me this error:

can't read "::toxy::scale_isactive": no such variable
can't read "::toxy::scale_isactive": no such variable
while executing
"if {$::toxy::scale_isactive} {
pd [concat $target $sel $v \;]
}"
(procedure "::toxy::scale_command" line 2)
invoked from within
"::toxy::scale_command s97a490 _cb 0"
(command executed by scale)


--
Damian Stewart
+64 27 305 4107

f r e y
live music with machines
http://www.frey.co.nz
http://www.myspace.com/freyed


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

Panning with expr [was: Re: [PD] delay effects in PD: suggestions?]

2006-11-12 Thread Frank Barknecht

Hallo,
derek holzer hat gesagt: // derek holzer wrote:

> derek holzer wrote:
> 
> >Help me out here, cause I've been using that particular dirty-but-quick 
> >panner construction for years now. What is the difference between your 
> >version and mine? Seems like they both give a range from 0-1 to the left 
> >channel and the inverse of that to the right channel.
> 
> Never mind! I figured it out. There's one patch cable in the wrong 
> place in my version. If that were fixed, our maths would be the same.

Yes, it's the same. My version might be slightly faster because it
avoids a multiplication, but then it has a variable replacement in a
message box, which also is a bit costly. Normally I use something like

  [expr 1-$f1; $f1]

to do the splitting in one object but I once heard that you don't like
[expr]. (Just joking ;)

Using [expr] for panning has the advantage to allow for writing
alternative pannings in a very compact way like:

  [expr sqrt(1-$f1); sqrt($f1)]
  
  [expr cos(1.57 * $f1); sin(1.57 * $f1)]

Attached patch shows them all.

Ciao
-- 
 Frank Barknecht _ __footils.org_ __goto10.org__
#N canvas 58 29 967 485 10;
#X floatatom 261 160 5 0 0 0 - - -;
#X obj 261 222 expr sqrt(1-$f1) \; sqrt($f1);
#X floatatom 261 263 5 0 0 0 - - -;
#X floatatom 375 260 5 0 0 0 - - -;
#X obj 264 134 hsl 128 15 0 1 0 0 empty empty empty -2 -8 0 10 -262144
-1 -1 5750 1;
#X msg 261 113 0.5;
#X floatatom 75 161 5 0 0 0 - - -;
#X floatatom 75 264 5 0 0 0 - - -;
#X floatatom 147 262 5 0 0 0 - - -;
#X obj 78 135 hsl 128 15 0 1 0 0 empty empty empty -2 -8 0 10 -262144
-1 -1 6350 1;
#X msg 75 114 0.5;
#X obj 75 223 expr 1-$f1 \; $f1;
#X floatatom 486 159 5 0 0 0 - - -;
#X floatatom 486 262 5 0 0 0 - - -;
#X floatatom 579 259 5 0 0 0 - - -;
#X obj 489 133 hsl 128 15 0 1 0 0 empty empty empty -2 -8 0 10 -262144
-1 -1 6350 1;
#X msg 486 112 0.5;
#X msg 644 110 bang;
#X floatatom 644 157 10 0 0 0 - - -;
#X obj 644 133 expr 2*atan(1);
#X text 691 111 M_PI/2;
#N canvas 0 0 450 300 apply_pan 0;
#X obj 67 157 *~;
#X obj 104 158 *~;
#X obj 68 55 inlet~;
#X obj 162 88 inlet;
#X obj 207 88 inlet;
#X obj 68 203 dac~;
#X obj 67 111 *~;
#X obj 133 120 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X connect 0 0 5 0;
#X connect 1 0 5 1;
#X connect 2 0 6 0;
#X connect 3 0 0 1;
#X connect 4 0 1 1;
#X connect 6 0 0 0;
#X connect 6 0 1 0;
#X connect 7 0 6 1;
#X coords 0 -1 1 1 85 50 1 100 100;
#X restore 36 336 pd apply_pan;
#N canvas 0 0 450 300 apply_pan 0;
#X obj 67 157 *~;
#X obj 104 158 *~;
#X obj 68 55 inlet~;
#X obj 162 88 inlet;
#X obj 207 88 inlet;
#X obj 68 203 dac~;
#X obj 67 111 *~;
#X obj 133 120 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X connect 0 0 5 0;
#X connect 1 0 5 1;
#X connect 2 0 6 0;
#X connect 3 0 0 1;
#X connect 4 0 1 1;
#X connect 6 0 0 0;
#X connect 6 0 1 0;
#X connect 7 0 6 1;
#X coords 0 -1 1 1 85 50 1 100 100;
#X restore 222 341 pd apply_pan;
#N canvas 0 0 450 300 apply_pan 0;
#X obj 67 157 *~;
#X obj 104 158 *~;
#X obj 68 55 inlet~;
#X obj 162 88 inlet;
#X obj 207 88 inlet;
#X obj 68 203 dac~;
#X obj 67 111 *~;
#X obj 133 120 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1
1;
#X connect 0 0 5 0;
#X connect 1 0 5 1;
#X connect 2 0 6 0;
#X connect 3 0 0 1;
#X connect 4 0 1 1;
#X connect 6 0 0 0;
#X connect 6 0 1 0;
#X connect 7 0 6 1;
#X coords 0 -1 1 1 85 50 1 100 100;
#X restore 447 337 pd apply_pan;
#X obj 692 413 *~ 0;
#X obj 718 371 hsl 128 15 0 127 0 0 empty empty empty -2 -8 0 10 -262144
-1 -1 11700 1;
#X obj 715 389 dbtorms;
#X obj 691 217 noise~;
#X obj 691 243 bp~ 1000 12;
#X obj 692 438 s~ \$0-noise;
#X obj 448 311 r~ \$0-noise;
#X obj 223 314 r~ \$0-noise;
#X obj 37 310 r~ \$0-noise;
#X obj 486 221 expr cos($f1) \; sin($f1);
#X text 258 73 Square-root based panning;
#X text 471 87 Equal power panning;
#X text 24 92 Linear with hole in middle;
#X text 95 21 Three simple panning methods;
#X text 688 192 Test signal;
#X obj 729 302 metro 250;
#X obj 692 347 *~;
#N canvas 0 0 540 524 vead 0;
#X obj 281 314 vline~;
#X obj 158 65 max 0.1;
#X obj 258 65 max 0.1;
#X text 156 22 attack (ms);
#X text 256 22 decay (ms);
#X text 86 22 trigger;
#X obj 87 45 inlet;
#X obj 158 45 inlet;
#X obj 258 45 inlet;
#X obj 144 467 outlet~;
#X obj 87 65 b;
#X obj 87 308 vline~;
#X text 129 283 attack;
#X text 317 285 decay;
#X msg 87 261 1 \, 0 \$1 0 \, 1 0 \$1;
#X msg 281 261 0 \, 1 0 \$1 \, 0 \$2 \$1;
#X obj 87 195 f 3;
#X msg 21 261 1;
#X obj 21 239 loadbang;
#X obj 281 361 expr~ pow($v1 \, 6);
#X obj 88 359 expr~ 1 - pow($v1 \, 6);
#X obj 87 215 pack 3 150;
#X connect 0 0 19 0;
#X connect 1 0 16 1;
#X connect 2 0 21 1;
#X connect 6 0 10 0;
#X connect 7 0 1 0;
#X connect 8 0 2 0;
#X connect 10 0 16 0;
#X connect 11 0 20 0;
#X connect 14 0 11 0;
#X connect 15 0 0 0;
#X connect 16 0 21 0;
#X connect 17 0 11 0;
#X connect 18 0 17 0;
#X connect 19 0 9 0;
#X connect 20 0 9 0;
#X connect 21 0 15 0;
#X connect 21 0 14 0;
#X restore 729 326 pd vead;
#X obj 729 280 tgl 15 0

Re: Panning with expr [was: Re: [PD] delay effects in PD: suggestions?]

2006-11-12 Thread derek holzer


Hey Frank,

Frank Barknecht wrote:


I once heard that you don't like [expr]. (Just joking ;)


I failed every math class I ever took, which might explain my aversion 
to [expr]! ;-)



Attached patch shows them all.


Thanks for this. Did I mention lately that you rock?

d.
--
derek holzer ::: http://www.umatic.nl
---Oblique Strategy # 55:
"Do the last thing first"

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

Re: [PD] Gem in -nogui mode?

2006-11-12 Thread Marius Schebella

I used pdp in -nogui mode for video in, but did not try video out. but I 
used gem without a windowmanager once, which seems for me the easiest 
solution for your setup.

marius.

Hans-Christoph Steiner schrieb:


How about something like PDP?  What if you just want to write video 
directly to the screen?  I suppose that would also use OpenGL to speed 
things up.


.hc



There is no way to peace, peace is the way.   -A.J. Muste



___
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] [zexy] [symbol2list]: bug (on windows)

2006-11-12 Thread Roman Haefeli

i checked, if recent windows-builts still have that error by using
[symbol2list] from pd-extended, since this is build directely from cvs.
and the error did not occur. anyway, it would be good to provide an
updated binary on the iem-ftp-server.

as for now, i found an uggly, but obviously working solution for the
netpd-windows-package:
i added [symbol2list] from pd-extended and let it be  loaded before zexy
is loaded with -lib symbol2list. 


On Sat, 2006-11-11 at 02:21 +0100, Roman Haefeli wrote:
> hi all
> 
> attached is a patch, that shows a bug of the [symbol2list]-object. when
> there is a digit at the begining of a symbol or right after a
> delimiter-character, [symbol2list] converts that part to a
> number-element  instead of a symbol-element.
> 
> example:
> 
> [symbol 4abc.pd(
> |
> | [symbol .(
> |  | 
> [symbol2list]
> |
> 
> gives: 
> 4 pd
> instead of:
> list 4abc pd
> 
> i found this bug only in the provided binary from:
> 
> ftp://ftp.iem.at/pd/Externals/ZEXY/zexy-nt-2.1.zip
> 
> it seems to work correctly in the cvs-version of zexy (built on linux).
> don't know, if this is an os-specific issue or if the provided binary is
> not built on the same source from cvs. 
> 
> roman
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list



___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de


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

Re: [PD] GGEE/state

2006-11-12 Thread Federico

Hans-Christoph Steiner ha scritto:
> 
> On Nov 11, 2006, at 11:04 AM, Frank Barknecht wrote:
> 
>> Hallo,
>> Federico hat gesagt: // Federico wrote:
>>
>>> i see here [state] only saves floatatoms and symbolatoms
>>
>> ... which IMHO is too limited in the long run. Because I needed to
>> save more than that (especially arbitrary lists) I developed Memento
>> and SSSAD.
> 
> I don't know if you've done this already, but it would be really nice to
> have a suite of basic GUI objects that already have state-saving
> built-in, (SSSAD, memento, whatever).  Something like a GOP vslider with
> the state-saving in it.  Then it would be really easy for people to
> build GUIs that have state-saving incorporated.

yeah that's a nice idea!

and now the hidenameongop patch
(https://sourceforge.net/tracker/index.php?func=detail&aid=1516869&group_id=55736&atid=478072)
should be in 0.40...

i must switch soon :D

ciao
Federico

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

Re: [PD] win32: toxy/widget issues

2006-11-12 Thread Patco

Damian Stewart a écrit :

And check the CVS for the ix widgets.
how do i do this? i know how to use CVS, i'm just not sure of which
server, which module, or which version to use.

For browsing CVS:

http://pure-data.cvs.sourceforge.net/pure-data/extensions/gui/ix/

For downloading:

In a shell (msys under win32)
Log in first:
cvs
-d:pserver:[EMAIL PROTECTED]:/cvsroot/pure-data log

And

cvs -z3
-d:pserver:[EMAIL PROTECTED]:/cvsroot/pure-data

co extensions/gui/ix

Don't forget that ix widgets requires some tk libs, read the readme.
If that version is working fine, then we should probably use it in
the Pd-extended release version. Can you guys test it and see?

loading scale-test.pd with that version gives me this error:

can't read "::toxy::scale_isactive": no such variable
can't read "::toxy::scale_isactive": no such variable
while executing
"if {$::toxy::scale_isactive} {
pd [concat $target $sel $v \;]
}"
(procedure "::toxy::scale_command" line 2)
invoked from within
"::toxy::scale_command s97a490 _cb 0"
(command executed by scale)

The problem doesn't come from the external but from the setup.wid file,
there is something to fix in it:

# FIXME
set ::toxy::scale_isactive 1

This line is apparently erroneous.

PatCo.

___
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses
http://fr.answers.yahoo.com

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

Re: [PD] GGEE/state

2006-11-12 Thread Frank Barknecht

Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

> I don't know if you've done this already, but it would be really nice  
> to have a suite of basic GUI objects that already have state-saving  
> built-in, (SSSAD, memento, whatever).  Something like a GOP vslider  
> with the state-saving in it.  Then it would be really easy for people  
> to build GUIs that have state-saving incorporated.

This really is rather trivial to do for standard GUI elements.
Attached are vslider, hslider and tgl extended for SSSAD. They will
look best on pd-0.40.

However as I said before, I don't think that it's only GUI objects
that can profit from state saving and not all GUI objects in a patch
do need their state to be persistent.

Ciao
-- 
 Frank Barknecht _ __footils.org_ __goto10.org__

sssad-gui.tgz
Description: GNU Unix tar archive
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] GGEE/state

2006-11-12 Thread Patco


Hi,
Frank Barknecht a écrit :


However as I said before, I don't think that it's only GUI objects
that can profit from state saving and not all GUI objects in a patch
do need their state to be persistent.
  

Yeah,
I think server side state saving is more flexible than client side (GUI) 
state saving.


If a slider has several functions that could be switched with a 
radiobutton, this kind of state saving becomes useless.
I think people prefers having a little bunch of GUI objects that can do 
a lot of things rather than a lot of GUI object that can only do one thing,

the CPU too.

Patco.





___ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com



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

Re: [PD] rradical/cyclone tosymbol crashes pd



On Nov 12, 2006, at 7:12 AM, Damian Stewart wrote:


Hans-Christoph Steiner wrote:


One place to start is using the nightly builds.


i had to downgrade back to my old version as the 2006-11-08 nightly  
didn't load a bunch of libs, some of which i appear to need for my  
patches the ones that failed were




gem,


Not auto-building on windows (yet?). Use the binary from an old install.


fftease,


Just needs to be added to the build system. Or use the binary from an  
old install.



hid,


Never existed on Windows, try [hidin]


iemabs, iem_t3_lib, iemlib1


These are all in "iemlib"


iemmatrix, mtx


These are included in the "flatspace" library for now.


liblist,


Built-in, this is obsolete.


pdp, pidip,


These never worked on windows


vasp, xsample,


No one has gotten the flext-based externals building as part of the  
nightly builds.  Its just a matter of someone doing the work.  Or use  
the binary from an old install



iemlib32


Don't know anything about that one.

.hc




"[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] win32: toxy/widget issues



On Nov 12, 2006, at 7:22 AM, Damian Stewart wrote:


Hans-Christoph Steiner wrote:


And check the CVS for the ix widgets.


how do i do this? i know how to use CVS, i'm just not sure of which  
server, which module, or which version to use.


Lots of useful stuff here:

http://puredata.org/docs/developer

.hc



If that version is working fine, then we should probably use it in  
the Pd-extended release version.  Can you guys test it and see?


loading scale-test.pd with that version gives me this error:

can't read "::toxy::scale_isactive": no such variable
can't read "::toxy::scale_isactive": no such variable
while executing
"if {$::toxy::scale_isactive} {
pd [concat $target $sel $v \;]
}"
(procedure "::toxy::scale_command" line 2)
invoked from within
"::toxy::scale_command s97a490 _cb 0"
(command executed by scale)


--
Damian Stewart
+64 27 305 4107

f r e y
live music with machines
http://www.frey.co.nz
http://www.myspace.com/freyed





Looking at things from a more basic level, you can come up with a  
more direct solution... It may sound small in theory, but it in  
practice, it can change entire economies. - Amy Smith




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

Re: [Pd] OT: this is the kind of interface I want

Actually, the most difficult thing to do is make it work well in the real world.  Making it work isn't too difficult, there are lots of working variations, including the Pd-powered reacTable.  But video tracking is really limited.  You have to have completely steady lighting conditions (notice the lights were turned off in that demo).I used that exact table interface at NIME at IRCAM.  It is certainly nifty, but it needs work to work in the real world.  The problem with video tracking is that there is no way to to track your finger, instead it just tracks shadows.  What happens is if the video tracking looses track of your finger for one instant, then it thinks you picked up your finger and put it back on the table. That can definitely screw up your actions.  And unfortunately which ever video tracking system thing I have seen, that exact thing happens quite frequently.Then there are multitouch sensors, which probably more reliably track your finger, but they are quite slow, so they work fine for moving sliders and pressing buttons, but for drawing or musical control, they are quite limited.  I think that using pressure sensors will probably be the better way, over video tracking, but don't hold your breath either way.  Plus, more importantly, I haven't seen any killer apps for this yet, that's key.  Sure, its nifty to wiggle images around and zoom and navigate, but that's a really simple app.  Try making photoshop with that, where the interface "just disappears"  I don't think humans could remember enough gestures to map all the functions in Photoshop, so a menu would probably be necessary.If you want to see a real killer demo, check  out the 1968 demo of Doug Engelbart's Augmentation Research Center.  That's a real demo.  They basically showed up when many people were still using punchcards, and interactive computing was just beginning to take hold.  They should a actual, functional system with hyperlinks, a basic GUI, the mouse, video conferencing, custom computer furniture, etc. when most people were excited to be using the terminal:http://sloan.stanford.edu/mousesite/1968Demo.htmlI guess I am just sick of the amount of hype these days.  All these "media labs" put so much energy into hype, instead of making better things.There, that's my rant..hcOn Nov 8, 2006, at 1:02 PM, Kyle Klipowicz wrote:I think that the most difficult (and useful) thing to do would be some sort of book keeping to track individual fingers.  Maybe some sort of gloves or fingertip sensors?  That would make things very flexible.It sounds neat that you're doing an implementation.  Please post any satisfying results to the list! ~KyleOn 11/8/06, Thomas Grill <[EMAIL PROTECTED]> wrote: Am 08.11.2006 um 05:46 schrieb Kyle Klipowicz:I KNEW this had to have something to do with Jeff Han.  Brilliant technology.  As I understand it, Apple Computer has gotten involved financially with this.  I'd love to see it implemented! Actually this is fairly easy to implement. There are a number of descriptions floating around in the net.Basically you need a transparent acrylic panel, IR emitters, a beamer and a fast camera, minor drilling and assembling skills and a multi-blob video tracker. I'm currently trying to build such a system.greetings,Thomas --Thomas Grillhttp://g.org  -- http://theradioproject.comhttp://perhapsidid.blogspot.com(()()()(()))()()())( (())(())()((())(___())(()))___(((000)))oOO___PD-list@iem.at mailing listUNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list  Access to computers should be unlimited and total.  - the hacker ethic ___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: Panning with expr [was: Re: [PD] delay effects in PD: suggestions?]



On Nov 12, 2006, at 7:27 AM, Frank Barknecht wrote:


Hallo,
derek holzer hat gesagt: // derek holzer wrote:


derek holzer wrote:

Help me out here, cause I've been using that particular dirty-but- 
quick
panner construction for years now. What is the difference between  
your
version and mine? Seems like they both give a range from 0-1 to  
the left

channel and the inverse of that to the right channel.


Never mind! I figured it out. There's one patch cable in the  
wrong

place in my version. If that were fixed, our maths would be the same.


Yes, it's the same. My version might be slightly faster because it
avoids a multiplication, but then it has a variable replacement in a
message box, which also is a bit costly. Normally I use something like

  [expr 1-$f1; $f1]

to do the splitting in one object but I once heard that you don't like
[expr]. (Just joking ;)

Using [expr] for panning has the advantage to allow for writing
alternative pannings in a very compact way like:

  [expr sqrt(1-$f1); sqrt($f1)]

  [expr cos(1.57 * $f1); sin(1.57 * $f1)]

Attached patch shows them all.


I put these three panning algorithms into objects in the "pan"  
library, and added another odd one devised by a guy named gogins, and  
included a GOP panner.


They are in the "pan" library in Pd-extended, or in CVS:

http://pure-data.cvs.sourceforge.net/pure-data/externals/hcs/pan/

.hc



News is what people want to keep hidden and everything else is  
publicity.  - Bill Moyers




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

Re: [Pd] OT: this is the kind of interface I want

2006-11-12 Thread Arie van Schutterhoef

 >The problem with video tracking is that there is no way to to track your
>finger,
-It lacks the physical contacts.

>instead it just tracks shadows.  What happens is if the video tracking
>looses >track of your finger for one instant, then it thinks you picked up
>your finger >and put it back on the table. That can definitely screw up
>your actions.  And >unfortunately which ever video tracking system thing I
>have seen, that exact >thing happens quite frequently.
-If you want to control things in concert, this is clearly something you
can do
 without.

>Then there are multitouch sensors, which probably more reliably track your
>>finger, but they are quite slow, so they work fine for moving sliders and
>>pressing buttons, but for drawing or musical control, they are quite
>limited.  
-Lemur seems to be 'performable', because at least there is no free space the
 surface and your fingers.

>I think that using pressure sensors will probably be the better way,
-FSR's are still very usable.

over video tracking, but don't hold your breath either way.  Plus, more
>importantly, I haven't seen any killer apps for this yet, that's key. 
Sure, >its nifty to wiggle images around and zoom and navigate, but that's
a really >simple app. 
-I guess that's what 'modern video art realtime processing' is all about...


>I am just sick of the amount of hype these days.  All these "media labs"
>put so >much energy into hype,
-The 'medium is the message', no matter how crappy this al in one is.

>instead of making better things.
-Takes too much time and needs a longer attention-span than generally people
 are capable of. No typing, just connecting virtual wires to virual boxes.

AvS






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

Re: [PD] GGEE/state


On Sun, 12 Nov 2006, Patco wrote:

Frank Barknecht a écrit :

However as I said before, I don't think that it's only GUI objects
that can profit from state saving and not all GUI objects in a patch
do need their state to be persistent.
I think server side state saving is more flexible than client side (GUI) 
state saving.


Even in the version of pd that has the most client-side code, all visual 
properties that are to be saved in a patch, are still stored server-side.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] windows compile - one last try


On Mon, 13 Nov 2006, Damian Stewart wrote:

maybe when i can be bothered pissing around with it again. last time it 
swallowed two full days of my life that i'm never going to get back.


That's a rather crude way to do the accounting of your time. How can you 
be so sure that you didn't do or understand anything in those two days 
that is going to be useful later on? At this point, you just don't know.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: Panning with expr [was: Re: [PD] delay effects in PD: suggestions?]

2006-11-12 Thread wind




> Attached patch shows them all.


thanks also for that;
keeps me away from some weired [line]-constructions, which 
made me laugh somehow...   
just subscribed new to the list, and wanted to say hello to everybody;
j ,.



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

Re: [PD] delay effects in PD: suggestions?

2006-11-12 Thread [EMAIL PROTECTED]

Hi Derek, Frank,

Thanks, it was helpful.

Alberto




Hi Alberto,

[EMAIL PROTECTED] wrote:
> before re-inventing the wheel, do you have suggestions
> for (feedback) delay effects already available in PD like
> "ping-pong" delay, multi-tap delay, "cross" delay
> etc?

All of these are easily built using [delwrite~], [delread~]
and [vd~].
See attached patch from my workshop examples.

d.

--
derek holzer ::: http://www.umatic.nl
---Oblique Strategy # 54:
"Do something sudden, destructive and unpredictable"


Alberto Zin

http://puredata.org/Members/AlbertoZ


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

Re: [Pd] OT: this is the kind of interface I want


On Sun, 12 Nov 2006, Hans-Christoph Steiner wrote:

If you want to see a real killer demo, check out the 1968 demo of Doug 
Engelbart's Augmentation Research Center.


Yes, I often mention that one.

They should a actual, functional system with hyperlinks, a basic GUI, 
the mouse, video conferencing, custom computer furniture, etc.


AFAIK, he invented a lot of things: not only the mouse, but also 
undo/redo, copy/cut/paste, and foldable trees; also it might have been the 
first implementation of hyperlinks, but the concept is usually attributed 
to Vannevar.



when most people were excited to be using the terminal:


BTW, back then, a "terminal" usually didn't have a monitor. If you had 
one, then what you had had to be called "Video Terminal" (VT) to make sure 
that people knew that you had those newfangled monitors. Else, terminals 
were usually typewriters equipped with a serial port. This explains some 
things in computer history, like how old UNIX "plain text" often used the 
backspace code (0x08) to mean "superimpose two characters", and especially 
in combination with underscore to mean underline.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: Panning with expr [was: Re: [PD] delay effects in PD: suggestions?]

2006-11-12 Thread Frank Barknecht

Hallo,
[EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote:

> > Attached patch shows them all.
> 
> thanks also for that;
> keeps me away from some weired [line]-constructions, which 
> made me laugh somehow...   
> just subscribed new to the list, and wanted to say hello to everybody;

Welcome on board!

Regarding [line]: let me add that my examples are deliberately
simplified and don't have [pack 0 10][line~] after the [expr]
outlets only because of that. Normally I always use [line~] or [line~]
when multiplying a float number with a signal to avoid clicks.

Ciao
-- 
 Frank Barknecht _ __footils.org_ __goto10.org__

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

Re: [PD] gate object changing type - ?


On Fri, 10 Nov 2006, Hans-Christoph Steiner wrote:

Krzysztof thought it might be related to -mms-bitfields option in MinGW. 
I think the bugs have occured using with and without that field. 
Currently, cyclone and family are set to compile without -mms-bitfields.


I think that for that kind of problem it could be a good idea to have a 
new call in m_pd.h in which an external states to pd what its 
interpretation of m_pd.h's structs is, so that pd can detect problems. 
e.g. m_pd.h could contain a statement-like macro and a function decl:


#define pd_begin_setup() pd_make_sure(sizeof(t_text))
EXTERN pd_make_sure(size_t sizeof_text);

And then every external would call pd_begin_setup() as soon as it enters 
its own setup function, in order to make sure that the external is 
binary-compatible.


I'm not 100% satisfied with the idea, but I think that it could really 
help categorize some bugs better. This case seems to be win32-only, 
though, so I don't think that I can reproduce it (?). Are there similar 
options on Linux for struct alignment? If there are, they must be super 
rare.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] gate object changing type - ?


On Sun, 12 Nov 2006, Mathieu Bouchard wrote:

I think that for that kind of problem it could be a good idea to have a new 
call in m_pd.h in which an external states to pd what its interpretation of 
m_pd.h's structs is, so that pd can detect problems. e.g. m_pd.h could 
contain a statement-like macro and a function decl:

#define pd_begin_setup() pd_make_sure(sizeof(t_text))
EXTERN pd_make_sure(size_t sizeof_text);


Actually, we don't need pd to check it for us, and we don't even need to 
call a function to get the size of a class. E.g.


#include 
#include "m_pd.h"
#include "m_imp.h"

extern t_class *text_class;

void sanity_setup (void) {
  post("t_text is %d bytes according to pd", text_class->c_size);
  post("t_text is %d bytes according to me", sizeof(t_text));
}

So if text_class->c_size != sizeof(t_text) then the externals compiled 
with the same options as this external will not be compatible with the pd 
that loaded -lib sanity.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] CPU cost II


On Thu, 9 Nov 2006, Marius Schebella wrote:

for me that's a really important topic, I often run into problems with 
slow machines not fast enough to play patches.


With video this happens often, even on fast machines, and especially with 
GridFlow: e.g. it's not possible to use [#fft] at 30fps unless your 
resolution is really small.


I wonder if it is possible to calculate something like flops/ FLOating 
Point OPerations per object


It wouldn't be just a count of flops; that's a rather useless unit of 
measure unless you know that all your flops take the same amount of time, 
and what you care about is the time. In Numerical Analysis, 
multiplications and additions are usually counted separately, because 
they're expected to be in two different classes of speed.



and have a list for all the pd objects.


This would have to be parametrized according to some things, like length 
of list arguments, block size, and possibly a lot of arguments.


Things like [fft~] does more work per sample when the blocksize is larger; 
i suspect that fiddle's situation is at least somewhat similar, but I 
haven't tested.


GEM/PDP would be harder due to framesize differences and to how the [EMAIL PROTECTED] 
one is supposed to measure time spent on the GPU.


I expect GridFlow to be a lot harder to measure; e.g. while pix_convolve 
will take time that's about the size of the picture (in pixels) times 
the size of the kernel (in pixels), in GridFlow you should only consider 
the number of nonzero entries in the kernel (!!). And then [#convolve] 
has special options like "op" and "fold" which aren't in any other 
implementation of convolution that I've seen in pd, and that can change 
the run time radically. And then [#convolve] supports *any* number of 
channels, while [pix_convolve] is up to only 4. And so on...


it really would be great to know the benchmarks of different 
hardwaresystems. marius.


Even though it's impossible to get a complete picture about the speed of 
each class, I think that it's worth trying. However, this may require some 
modifications to Pd. It's possible to make benchmarks in pure pd, but this 
would require a big mess of [timer] and [t] objects in order to prevent 
sent messages to be counted as part of the object's running time. If it 
were done in C in a similar way, it would be much faster, which would be 
important in order to have sufficiently accurate figures.


Even then, I fear that it wouldn't be that accurate, when lots of short 
operations are made. In that case, a statistical profiler would be more 
appropriate.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] GGEE/state

2006-11-12 Thread Federico

Mathieu Bouchard ha scritto:
> On Sun, 12 Nov 2006, Patco wrote:
>> Frank Barknecht a écrit :
>>> However as I said before, I don't think that it's only GUI objects
>>> that can profit from state saving and not all GUI objects in a patch
>>> do need their state to be persistent.
>> I think server side state saving is more flexible than client side
>> (GUI) state saving.
> 
> Even in the version of pd that has the most client-side code, all visual
> properties that are to be saved in a patch, are still stored server-side.

global state saving would be also important for pd to support LASH.
with LASH a session could be stored to a file, and restored later.
that means: every program will reopen all its open documents, and every
document would restore its state

actually a bunch of programs support that (seq24, patchage, vkeybd,
muse, meterbridge, dino), would be great to see pd in that list...

and even if it is a complex task, having widgets save their state move
one step forward into that direction! ;)

ciao
Federico

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

Re: [Pd] OT: this is the kind of interface I want

2006-11-12 Thread Chuckk Hubbard

I'm envisioning a musical instrument akin to a keyboard that retunes
itself.  Wendy Carlos made something like this, I think, but I want
something more versatile.  Monzo lattices, maybe, for selecting notes,
and then separate commands for transposing the whole system of notes
to different roots.
Monzo:
http://tonalsoft.com/enc/l/lattice.aspx

I'd also like to try an instrument that displays its frequencies
linearly instead of logarithmically.  I could do that without one of
these interfaces, but I'd like to try playing it with some kind of
multiple-touch screen.
A pedal or two might help with this as well.

-Chuckk

On 11/12/06, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote:

Actually, the most difficult thing to do is make it work well in the real
world.  Making it work isn't too difficult, there are lots of working
variations, including the Pd-powered reacTable.  But video tracking is
really limited.  You have to have completely steady lighting conditions
(notice the lights were turned off in that demo).

I used that exact table interface at NIME at IRCAM.  It is certainly nifty,
but it needs work to work in the real world.  The problem with video
tracking is that there is no way to to track your finger, instead it just
tracks shadows.  What happens is if the video tracking looses track of your
finger for one instant, then it thinks you picked up your finger and put it
back on the table. That can definitely screw up your actions.  And
unfortunately which ever video tracking system thing I have seen, that exact
thing happens quite frequently.

Then there are multitouch sensors, which probably more reliably track your
finger, but they are quite slow, so they work fine for moving sliders and
pressing buttons, but for drawing or musical control, they are quite
limited.

I think that using pressure sensors will probably be the better way, over
video tracking, but don't hold your breath either way.  Plus, more
importantly, I haven't seen any killer apps for this yet, that's key.  Sure,
its nifty to wiggle images around and zoom and navigate, but that's a really
simple app.  Try making photoshop with that, where the interface "just
disappears"  I don't think humans could remember enough gestures to map all
the functions in Photoshop, so a menu would probably be necessary.

If you want to see a real killer demo, check  out the 1968 demo of Doug
Engelbart's Augmentation Research Center.  That's a real demo.  They
basically showed up when many people were still using punchcards, and
interactive computing was just beginning to take hold.  They should a
actual, functional system with hyperlinks, a basic GUI, the mouse, video
conferencing, custom computer furniture, etc. when most people were excited
to be using the terminal:

http://sloan.stanford.edu/mousesite/1968Demo.html

I guess I am just sick of the amount of hype these days.  All these "media
labs" put so much energy into hype, instead of making better things.

There, that's my rant.

.hc

On Nov 8, 2006, at 1:02 PM, Kyle Klipowicz wrote:

I think that the most difficult (and useful) thing to do would be some sort
of book keeping to track individual fingers.  Maybe some sort of gloves or
fingertip sensors?  That would make things very flexible.

It sounds neat that you're doing an implementation.  Please post any
satisfying results to the list!

~Kyle

On 11/8/06, Thomas Grill <[EMAIL PROTECTED]> wrote:
>
>
>
>
> Am 08.11.2006 um 05:46 schrieb Kyle Klipowicz:
>
> I KNEW this had to have something to do with Jeff Han.  Brilliant
technology.  As I understand it, Apple Computer has gotten involved
financially with this.  I'd love to see it implemented!
>
>
>
> Actually this is fairly easy to implement. There are a number of
descriptions floating around in the net.
> Basically you need a transparent acrylic panel, IR emitters, a beamer and
a fast camera, minor drilling and assembling skills and a multi-blob video
tracker.
> I'm currently trying to build such a system.
>
>
> greetings,
> Thomas
>
>
>
> --
> Thomas Grill
> http://g.org
>
>

--

http://theradioproject.com
http://perhapsidid.blogspot.com

(()()()(()))()()())(
(())(())()(((
))(__
_())(()))___
(((000)))oOO
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

Access to computers should be unlimited and total.  - the hacker ethic

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

--
"Far and away the best prize that life has to offer is the chance to
work hard at work worth doing."
-Theodore Roosevelt

___

Re: [PD] CPU cost II

2006-11-12 Thread chris clepper

On 11/12/06, Mathieu Bouchard <[EMAIL PROTECTED]> wrote:
GEM/PDP would be harder due to framesize differences and to how the [EMAIL PROTECTED]one is supposed to measure time spent on the GPU.With a profiler.http://www.gremedy.com/
http://developer.apple.com/graphicsimaging/opengl/profiler_image.html
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] PD not finding externals

2006-11-12 Thread Hector Centeno


Hello,

How can I make PD to look for externals inside sub-directories? It
finds them when they are right into the lib/pd/extra directory but not
the ones inside other directories inside this one. For example, I want
to use the externals inside the folder extra/bsaylor but I have to
move them out of their folder in order to PD to use them. I can see
that almost all the externlas are in the same situation and that's the
way the installer installs them. Am I missing something here? Do I
have to move everything manually?

Thanks!


Hector.

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

Re: [PD] PD not finding externals

2006-11-12 Thread Charles Henry


You can set other paths in the file menu or with command line options,
-path.  This keeps you from loading all of them at once.  You can set
the path to load just the ones you need.
Chuck

On 11/12/06, Hector Centeno <[EMAIL PROTECTED]> wrote:

Hello,

How can I make PD to look for externals inside sub-directories? It
finds them when they are right into the lib/pd/extra directory but not
the ones inside other directories inside this one. For example, I want
to use the externals inside the folder extra/bsaylor but I have to
move them out of their folder in order to PD to use them. I can see
that almost all the externlas are in the same situation and that's the
way the installer installs them. Am I missing something here? Do I
have to move everything manually?

Thanks!


Hector.

___
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] OT: this is the kind of interface I want


Hans-Christoph Steiner wrote:


Actually, the most difficult thing to do is make it work well in the
 real world.  Making it work isn't too difficult, there are lots of 
working variations, including the Pd-powered reacTable.  But video 
tracking is really limited.  You have to have completely steady

lighting conditions (notice the lights were turned off in that demo).


i'm working for a small New Zealand company called Lumen Digital at the
moment. we actually have a *very* robust finger-tracking system based on
OpenCV that we currently use for digital map interfaces, and one of our
future research projects could involve some sort of tracking-based music
interactive table.

the lighting conditions do have to be controlled to some degree, but in
our case it's not a matter of needing no external light cast over the
interface so much as it is in needing lighting that doesn't change too
much over the course of interaction. i've just completed install of our
table in a gallery which was lit in the vicinity of the table itself by
more than 16 halogen bulbs, which together generate a considerable
amount of spill and shadow, and through all this our tracker was able to
reliably track hands to within a few pixels accuracy on a 1536x1024,
roughly 3m x 2m projection.

(by the way, if anyone's looking for a job in digital museum
interactives and not averse to moving to beautiful New Zealand to do so,
we're looking for programmers at the moment, email me at
[EMAIL PROTECTED] or jared forbes at [EMAIL PROTECTED]
for details.)


I used that exact table interface at NIME at IRCAM.  It is certainly
nifty, but it needs work to work in the real world.  The problem
with video tracking is that there is no way to to track your finger,
instead it just tracks shadows.


not so. we track fingers, not shadows.


What happens is if the video tracking looses track of your finger for
one instant, then it thinks you picked up your finger and put it back
on the table. That can definitely screw up your actions.  And
unfortunately which ever video tracking system thing I have seen,
that exact thing happens quite frequently.


we currently get around that one by not actually detecting whether 
you're pressing on the table or not (although doing so would just 
involve a relatively simple capacitance sensor on the table surface). 
since our table allows for multi-hand tracking (we've tested with up to 
eight individual users using one or two hands around a 3mx2m table, and 
theoretically it could go higher) there's no reason why you can't have 
the right hand doing pointing the and left hand hovering near an active 
area (or two, or three) that vaguely corresponds to a mouse button 
click. the trick in our industry is to make it intuitive, so joe public 
can pick it up in literally five seconds.



Sure, its nifty to wiggle images around and zoom and navigate,
but that's a really simple app.  Try making photoshop with that,
where the interface "just disappears"  I don't think humans could
remember enough gestures to map all the functions in Photoshop, so a
menu would probably be necessary.


gestures are another thing all together. having done tonnes of research 
before starting to code this project, i ended up concluding that 
gestures were far too fragile a system for public use, and having a 
palette of active areas as described above might be better for multiple 
actions. i remember finding a kind of a system that involving pointing 
at a small list that, as you got closer to it, kind of expanded in scope 
so that you were able to zoom through a large tree of options by subtle 
variations in the direction you moved the mouse. something like this 
would be ideal.


--
Damian Stewart
+64 27 305 4107

f r e y
live music with machines
http://www.frey.co.nz
http://www.myspace.com/freyed

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

Re: [Pd] OT: this is the kind of interface I want

2006-11-12 Thread Claude Heiland-Allen

Damian Stewart wrote:
> i remember finding a kind of a system that involving pointing
> at a small list that, as you got closer to it, kind of expanded in scope
> so that you were able to zoom through a large tree of options by subtle
> variations in the direction you moved the mouse. something like this
> would be ideal.
> 

Something like this?

http://www.inference.phy.cam.ac.uk/dasher/



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

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

[PD] desiredata 0.39.A.pre2

-- Forwarded message --
Date: Sun, 12 Nov 2006 19:25:10 -0500 (EST)
From: Mathieu Bouchard <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: desiredata 0.39.A.pre2

Preview 2 of DesireData is now available. Since Preview 1 (august) the main 
changes are:

  * Chun did a *lot* of work on subpatches, GOP, and keyboard shortcuts.
  * I deleted a few thousand lines of C that we don't need anymore
  * Mario Mora updated the Spanish translations

http://artengine.ca/desiredata/download/desiredata-0.39.A.pre2.tar.gz

 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] CPU cost II

2006-11-12 Thread Marius Schebella

you are right, the big cpu eaters are graphics and fft-objects (which 
depend on the window size.)
but for example, when I plan to use a minimac, I would like to know how 
many videos can I add with which resolution.
I also know that with a good graphic card I can render more GEM objects 
than with some big cpus, but a crappy gfx card.
I was also thinking of having a [dsp] object interact with the framerate 
within a patch.

thanks, anyway for thinking about that problem!
marius.


Mathieu Bouchard schrieb:

On Thu, 9 Nov 2006, Marius Schebella wrote:

for me that's a really important topic, I often run into problems with 
slow machines not fast enough to play patches.


With video this happens often, even on fast machines, and especially 
with GridFlow: e.g. it's not possible to use [#fft] at 30fps unless your 
resolution is really small.


I wonder if it is possible to calculate something like flops/ FLOating 
Point OPerations per object


It wouldn't be just a count of flops; that's a rather useless unit of 
measure unless you know that all your flops take the same amount of 
time, and what you care about is the time. In Numerical Analysis, 
multiplications and additions are usually counted separately, because 
they're expected to be in two different classes of speed.



and have a list for all the pd objects.


This would have to be parametrized according to some things, like length 
of list arguments, block size, and possibly a lot of arguments.


Things like [fft~] does more work per sample when the blocksize is 
larger; i suspect that fiddle's situation is at least somewhat similar, 
but I haven't tested.


GEM/PDP would be harder due to framesize differences and to how the [EMAIL PROTECTED] 
one is supposed to measure time spent on the GPU.


I expect GridFlow to be a lot harder to measure; e.g. while pix_convolve 
will take time that's about the size of the picture (in pixels) times 
the size of the kernel (in pixels), in GridFlow you should only consider 
the number of nonzero entries in the kernel (!!). And then [#convolve] 
has special options like "op" and "fold" which aren't in any other 
implementation of convolution that I've seen in pd, and that can change 
the run time radically. And then [#convolve] supports *any* number of 
channels, while [pix_convolve] is up to only 4. And so on...


it really would be great to know the benchmarks of different 
hardwaresystems. marius.


Even though it's impossible to get a complete picture about the speed of 
each class, I think that it's worth trying. However, this may require 
some modifications to Pd. It's possible to make benchmarks in pure pd, 
but this would require a big mess of [timer] and [t] objects in order to 
prevent sent messages to be counted as part of the object's running 
time. If it were done in C in a similar way, it would be much faster, 
which would be important in order to have sufficiently accurate figures.


Even then, I fear that it wouldn't be that accurate, when lots of short 
operations are made. In that case, a statistical profiler would be more 
appropriate.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada



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

Re: [PD] PD not finding externals



I am guessing that you are using Pd-extended and that you did not  
read the included README.  There is a crucial step that is outlined  
in that README which will most likely solve this problem.


.hc

On Nov 12, 2006, at 3:53 PM, Hector Centeno wrote:


Hello,

How can I make PD to look for externals inside sub-directories? It
finds them when they are right into the lib/pd/extra directory but not
the ones inside other directories inside this one. For example, I want
to use the externals inside the folder extra/bsaylor but I have to
move them out of their folder in order to PD to use them. I can see
that almost all the externlas are in the same situation and that's the
way the installer installs them. Am I missing something here? Do I
have to move everything manually?

Thanks!


Hector.

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





  ¡El pueblo unido jamás será vencido!



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

Re: [PD] desiredata 0.39.A.pre2