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
Re: Panning with expr [was: Re: [PD] delay effects in PD: suggestions?]
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] [zexy] [symbol2list]: bug (on windows)
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: 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
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: [PD] delay effects in PD: suggestions?
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?]
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 stdio.h
#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] GGEE/state
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
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 ___ PD-list@iem.at
Re: [PD] CPU cost II
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
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
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
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] desiredata 0.39.A.pre2
How about putting out some binaries too? Its still not easy to build DD. First off, there is no mention of installing portaudio in the INSTALL.txt. Then after that, it dies here on Mac OS X 10.4: gcc -Os -faltivec -maltivec -fnested-functions -fasm-blocks -DPD - DDL_OPEN -DNEWHASH -DLOCKFREE -DPABLIO -DUNISTD -DPA_USE_COREAUDIO - DMACOSX -DUSEAPI_JACK -DUSEAPI_PORTAUDIO -DPA19 -DNDEBUG - DHAVE_ALLOCA -DPD_INTERNAL -I/Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tcl.framework/Headers -I/usr/include/tcl8.4 - Isrc -Iportmidi_osx -Iportmidi_osx/pm_common -Iportmidi_osx/porttime - Iportmidi_osx/pm_mac -Iportaudio/include -Iportaudio/src/common -c -o src/s_midi_pm.o src/s_midi_pm.c src/s_midi_pm.c: In function 'sys_do_open_midi': src/s_midi_pm.c:52: error: too few arguments to function 'Pm_OpenInput' scons: *** [src/s_midi_pm.o] Error 1 scons: building terminated because of errors. The compile farm would automate this process. .hc On Nov 12, 2006, at 7:25 PM, Mathieu Bouchard wrote: -- 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 [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] desiredata 0.39.A.pre2
Hans-Christoph Steiner wrote: How about putting out some binaries too? Its still not easy to build DD. First off, there is no mention of installing portaudio in the INSTALL.txt. Then after that, it dies here on Mac OS X 10.4: My *guess* (not having an OS X machine) is that you didn't set portaudio=0 From http://desiredata.goto10.org/wiki/QuickStart : scons desire=1 debug=1 wall=1 portaudio=0 Hopefully it is something as simple as this Claude gcc -Os -faltivec -maltivec -fnested-functions -fasm-blocks -DPD -DDL_OPEN -DNEWHASH -DLOCKFREE -DPABLIO -DUNISTD -DPA_USE_COREAUDIO -DMACOSX -DUSEAPI_JACK -DUSEAPI_PORTAUDIO -DPA19 -DNDEBUG -DHAVE_ALLOCA -DPD_INTERNAL -I/Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tcl.framework/Headers -I/usr/include/tcl8.4 -Isrc -Iportmidi_osx -Iportmidi_osx/pm_common -Iportmidi_osx/porttime -Iportmidi_osx/pm_mac -Iportaudio/include -Iportaudio/src/common -c -o src/s_midi_pm.o src/s_midi_pm.c src/s_midi_pm.c: In function 'sys_do_open_midi': src/s_midi_pm.c:52: error: too few arguments to function 'Pm_OpenInput' scons: *** [src/s_midi_pm.o] Error 1 scons: building terminated because of errors. The compile farm would automate this process. .hc On Nov 12, 2006, at 7:25 PM, Mathieu Bouchard wrote: -- 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 [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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] desiredata 0.39.A.pre2
Here, here! I second that. I still can't compile vanilla pd on OSX now, because I tried compiling DD over a year ago...you can get hypnotized by that #dataflow channel!~Kyle On 11/13/06, Claude Heiland-Allen [EMAIL PROTECTED] wrote: Hans-Christoph Steiner wrote: How about putting out some binaries too?Its still not easy to build DD.First off, there is no mention of installing portaudio in the INSTALL.txt.Then after that, it dies here on Mac OS X 10.4:My *guess* (not having an OS X machine) is that you didn't set portaudio=0From http://desiredata.goto10.org/wiki/QuickStart : scons desire=1 debug=1 wall=1 portaudio=0Hopefully it is something as simple as thisClaude gcc -Os -faltivec -maltivec -fnested-functions -fasm-blocks -DPD -DDL_OPEN -DNEWHASH -DLOCKFREE -DPABLIO -DUNISTD -DPA_USE_COREAUDIO -DMACOSX -DUSEAPI_JACK -DUSEAPI_PORTAUDIO -DPA19 -DNDEBUG -DHAVE_ALLOCA -DPD_INTERNAL -I/Library/Frameworks/Tk.framework/Headers -I/Library/Frameworks/Tcl.framework/Headers -I/usr/include/tcl8.4 -Isrc -Iportmidi_osx -Iportmidi_osx/pm_common -Iportmidi_osx/porttime -Iportmidi_osx/pm_mac -Iportaudio/include -Iportaudio/src/common -c -o src/s_midi_pm.o src/s_midi_pm.c src/s_midi_pm.c: In function 'sys_do_open_midi': src/s_midi_pm.c:52: error: too few arguments to function 'Pm_OpenInput' scons: *** [src/s_midi_pm.o] Error 1 scons: building terminated because of errors. The compile farm would automate this process. .hc On Nov 12, 2006, at 7:25 PM, Mathieu Bouchard wrote: -- 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 [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___PD-list@iem.at mailing listUNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list-- http://theradioproject.comhttp://perhapsidid.blogspot.com(()()()(()))()()())((())(())()((( ))(___())(()))___(((000)))oOO ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
