Re: [PD] sigmund list sort
On Sat, Feb 25, 2012 at 02:45:38PM -0500, Mathieu Bouchard wrote: Le 2012-02-25 à 09:34:00, Frank Barknecht a écrit : Yes, exactly. I often use data structures, well, as data structures and almost never use them for scores in a UPIC sense. What's UPIC ? I was referring to the UPIC composition tool by Iannis Xenakis (Unité Polyagogique Informatique du CEMAMu), that was one of the inspirations for the graphical score capabilities in data structures. See http://en.wikipedia.org/wiki/UPIC Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
On Fri, 2012-02-24 at 12:14 -0800, Jonathan Wilkes wrote: - Original Message - From: Roman Haefeli reduz...@gmail.com To: m.e.grimm megr...@gmail.com Cc: Jonathan Wilkes jancs...@yahoo.com; pd-list pd-list@iem.at Sent: Friday, February 24, 2012 2:57 PM Subject: Re: [PD] save search path 0.43 OSX On Fri, 2012-02-24 at 11:37 -0500, m.e.grimm wrote: I think the better way to fix those help-files is to use an [import] or [declare] object in the help patch. one prob I have found ... in a lib such as rtc the objects are not compiled externals but abstractions that rely on list-abs. how to deal with this? you can't really put [import list-abs] or [declare] in an abstraction ... well I guess you can buts that's not the way it should be done. Interesting that you say that. I always thought it is the very goal of using [import]: make any patch or abstraction resolve its own dependencies. In what way [import] shouldn't be used inside abstractions? (I specifically mention only [import] now, since [declare] has its own implications, though if it would be free of bugs, I'd mentioned it as well.) So we have [import] which isn't in vanilla, [declare] which you say has bugs, and using libname/ prefixes which works for both vanilla and extended. What am I missing? Many libraries come as multi-class externals, either because you compiled them yourself and this is the default setup designed by the developer or you get them as package (in Debian, for instance). For all those libraries, [libname/classname] will simply break. OTOH, [declare] already works now (in both, Pd-vanilla and Pd-extended) [1], or you could use [import] which you can easily install (for instance, in Debian there is already a package). I think, it's much easier to find a way to load a certain library (either with start-up flags, [declare] or [import]) than to have to edit a patch and make it work by replacing all occurences of [libname/classname] by [classname]. Roman [1] The one known bug in [declare] I was thinking about doesn't affect its functionality, it works fine, but when used within abstractions, it will add a bogus line in the parents patch file, when the parent is saved. People need to be aware of that when using [declare]. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
On Fri, 2012-02-24 at 15:16 -0500, Mathieu Bouchard wrote: Le 2012-02-24 à 20:57:00, Roman Haefeli a écrit : In what way [import] shouldn't be used inside abstractions? [import] is not very local, is it ? But it also works with multi-class externals. See my other mail. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
On Sun, 2012-02-26 at 11:49 +0100, Roman Haefeli wrote: On Fri, 2012-02-24 at 12:14 -0800, Jonathan Wilkes wrote: - Original Message - From: Roman Haefeli reduz...@gmail.com To: m.e.grimm megr...@gmail.com Cc: Jonathan Wilkes jancs...@yahoo.com; pd-list pd-list@iem.at Sent: Friday, February 24, 2012 2:57 PM Subject: Re: [PD] save search path 0.43 OSX On Fri, 2012-02-24 at 11:37 -0500, m.e.grimm wrote: I think the better way to fix those help-files is to use an [import] or [declare] object in the help patch. one prob I have found ... in a lib such as rtc the objects are not compiled externals but abstractions that rely on list-abs. how to deal with this? you can't really put [import list-abs] or [declare] in an abstraction ... well I guess you can buts that's not the way it should be done. Interesting that you say that. I always thought it is the very goal of using [import]: make any patch or abstraction resolve its own dependencies. In what way [import] shouldn't be used inside abstractions? (I specifically mention only [import] now, since [declare] has its own implications, though if it would be free of bugs, I'd mentioned it as well.) So we have [import] which isn't in vanilla, [declare] which you say has bugs, and using libname/ prefixes which works for both vanilla and extended. What am I missing? Many libraries come as multi-class externals, either because you compiled them yourself and this is the default setup designed by the developer or you get them as package (in Debian, for instance). For all those libraries, [libname/classname] will simply break. OTOH, [declare] already works now (in both, Pd-vanilla and Pd-extended) [1], or you could use [import] which you can easily install (for instance, in Debian there is already a package). I think, it's much easier to find a way to load a certain library (either with start-up flags, [declare] or [import]) than to have to edit a patch and make it work by replacing all occurences of [libname/classname] by [classname]. For completeness, let me add that it doesn't matter with abstraction libraries whether you use [import libname] or [libname/classname]. So in that specific case with the rtc lib and list-abs I agree with you that [libname/classname] is fine. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] C++ for reusable dsp lib - or better use C?
On Sun, Feb 26, 2012 at 11:49 AM, Jamie Bullock jamie.b.bull...@gmail.com wrote: I follow your work with interest, and this sounds like a promising new development. I think writing generic routines, e.g. in the form of a shared library that can then support bindings for various contexts is a good one since it enables your work work to have benefits beyond Pd. This was the approach I took with libxtract, which you may be interested in from a feature extraction perspective. Also, have you looked at BBcut for SuperCollider at all? Sounds like you're trying to do a similar thing and it may be worth looking at how Nick Collins has solved some of the problems. I'd love to see a libBBcut or similar. I guess the key challenge is handling timing and scheduling for the real-time cut n paste without duplicating functionality already provided by Pd, SC or whatever. Thanks for your pointers, Jamie. I had not come across your libxtract project yet. It's very rich in functionality. And Nick Collins yes, he brings a lot of interesting signal analysis work to the realtime / open source community, but seems to forget Pd for some reason. With a lot of useful projects already available (also think of Aubio), it may seem a bit weird that I feel a need to add yet another new lib. But it was the better-than-expected quality and efficiency of pitch tracker [helmholtz~] which made me think that I could contribute something. It shall be a compact library, not focusing on width but on depth: quality, robustness and efficiency of a few procedures which I consider essential for real time cut paste. Algorithmic recomposition won't be part of it, that can be done in patches. My lib will mainly deliver cuepoints and pitch reports. But some 'customers' for this sort of data must live together with the analysis in one Pd class, where they can share the time index associated with the analysis process. A PSOLA pitch shifter for example. Or a signalcuepoint recorder like [slicerec~]. In the end, analysis and processing procedures must be integrated in that one lib to get access to the time index. This 'central clock' is the key challenge indeed. It's cycle depends on the largest buffer size associated with the procedures, and for efficiency it must always be a power of two. Other cycles can be found by bitmasking the central clock. Well I've handled it in [slicerec~], it is a matter of upscaling the principle to more complex interactions. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
Le 2012-02-26 à 11:50:00, Roman Haefeli a écrit : On Fri, 2012-02-24 at 15:16 -0500, Mathieu Bouchard wrote: Le 2012-02-24 à 20:57:00, Roman Haefeli a écrit : In what way [import] shouldn't be used inside abstractions? [import] is not very local, is it ? But it also works with multi-class externals. See my other mail. But it's not very local, is it ? Where does it import symbols to ? A big global namespace. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bonk~
i must have been blind. now i can find it on the listed publications. sorry for the noise. m. Am 25.02.2012 um 19:59 schrieb Miller Puckette: It's on http://crca.ucsd.edu/~msp/Publications/icmc98.ps .. the exact URL doesn't appear on the Pd vanilla help file for bonk~, which just points to my home page. cheers Miller On Mon, Feb 20, 2012 at 04:26:16PM +0100, Max wrote: Shall i remove the reference to the paper mentioned in the bonk~ helpfile or does it still exist somewhere? m. Am 15.02.2012 um 05:59 schrieb Miller Puckette: .. one small comment - the 'minvel' message might not be functioning in recent versions - I have to check this. cheers Miller On Tue, Feb 14, 2012 at 11:47:49PM -0500, William Brent wrote: Hi Joe, When you're searching for a good minvel setting, you should watch the 2nd number in the list from bonk's right outlet. Then play a few sample notes on the instrument you're trying to track to get a sense of typical velocities. The threshold setting is a little less intuitive. To find the best values for that, you have to get a sense of how the sum of growth in all frequency bands is changing over time. I made the attached patch to explain this in a class, and it might be helpful for you. You'll have to download my [tabletool] extern for it to work though, which you can get here: http://williambrent.conflations.com/pages/research.html#tabletool On Fri, Feb 10, 2012 at 10:23 AM, joe higham joehig...@hotmail.com wrote: Hi @ PD List Just a quick question to ask if someone could help me with the bonk~ object I'd be most grateful : a) Some more 'plain' information about bonk~ and it's 2 outputs. I've (naturally) read the 'help' patch on the object. b) How can I control (more precisely) the input level of this object? I did look at the terminal using a [print] object to see if I could control things a little better but, I haven't really understood the problem, and therefore the solution. I've also tried using [thresh( and [minvel( but they seem a little 'hit or miss' due to my lack of knowledge. Thanks in advance Joe (Higham) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- William Brent www.williambrent.com “Great minds flock together” Conflations: conversational idiom for the 21st century www.conflations.com ___ 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-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] libpd, the book!
Thanks for the kind words, everybody! About prerequisites, you will need to know the basics of Java or Objective-C, e.g., basic syntax as well as terms like class, object, method, and inheritance. I'm also assuming that readers have some basic knowledge of Android or iOS development, as well as a working development setup. If you know how to write simple apps for Android or iOS, then you're ready to tackle this book. Cheers, Peter On Sat, Feb 25, 2012 at 2:57 AM, Ichabod icha...@gmail.com wrote: I see the table of contents lists a chapter called Prerequisites. What exactly are the prerequisites in terms of knowledge of programming languages? Thanks, Stefán ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] libpd, the book!
Brilliant! I've just ordered my copy now. I can't wait to read it! Cheers, - martin On 24 February 2012 01:42, Peter Brinkmann peter.brinkm...@googlemail.com wrote: Hi, I'm happy to announce the release of my book on mobile audio development with libpd: http://shop.oreilly.com/product/0636920022503.do The ebook version is available now; printed copies will be available from amazon.com next week. Cheers, Peter ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ 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] C++ for reusable dsp lib - or better use C?
Le 2012-02-22 à 13:51:00, Jonathan Wilkes a écrit : It looks old and unmaintained, and I doubt it supports the newest version of Qt which has introduced the graphics view stuff What's the graphics view stuff ? If Qtcl works well, it could be a possible path for speeding up the GUI, by replacing Tk entirely, but keeping Tcl (which is easier than changing everything at once). But there are other paths (the ones I suggested recently). The only other path I remember is patching Tk to make it more efficient, but you still wouldn't get zooming with that. I also mentioned the use of binary protocols, but it depends how much the binary protocol removes the Tcl dependency. A light use of binary elements means efficiently cutting the stream into Tcl commands to be run, and also ability to transmit raw data (array coords, images) at higher speed. But if that path is followed further, then... well, there are dozens of possible ways of making things more modular and it's not necessary to enumerate every possible way of doing so. Tk zooming can be achieved using a TkCanvas wrapper that filters all coordinates. I'd use poe.tcl and follow a structure similar to Chun's TkZinc wrapper experiment and «def Canvas item» at once. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] C++ for reusable dsp lib - or better use C?
Le 2012-02-25 à 09:55:00, Andy Farnell a écrit : Shortcuts made because a language is compact and elegant only pay off where you write millions of lines of code. Who knows, maybe they don't pay off ever. :-P You don't need to spit out that kind of gratuitous nonsense. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] C++ for reusable dsp lib - or better use C?
Le 2012-02-25 à 23:44:00, katja a écrit :
I do not use STL functionality, libstdc++ seems to be required for other
functions as well, and vanilla Pd can't load a C++ object without it.
If you really want to avoid libstdc++, I think that you can do something
like :
#include malloc.h
static inline void *operator new (unsigned int n) {return malloc(n);}
static inline void operator delete (void *p) {return free(p);}
and add -fno-rtti to the flags (to disable the typeinfo feature). If you
encounter anything else, just ask me and I'll try to find it.
__
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] OT - C++ for reusable dsp lib - or better use C?
Le 2012-02-25 à 14:29:00, Phil Stone a écrit : IMO, Pd *approaches* this potential of live-coding, but isn't there yet. The edit/play dichotomy, The Edit/Play modes are there just to allow more different mouse commands. It's not really a feature of the engine, it's just for switching between two sets of mouse behaviours in the GUI, because there are not enough buttons. I also like programming in word languages, For what I presume you call a non-word language, Pd has quite a large vocabulary of words in it. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_openni crash Pd
Le 25/02/2012 17:13, Matthias Kronlachner a écrit :
Am 25.02.12 16:08, schrieb Jack:
Le 25/02/2012 14:39, Matthias Kronlachner a écrit :
Am 24.02.12 20:15, schrieb Jack:
Le 24/02/2012 18:41, Mathieu Bouchard a écrit :
Le 2012-02-24 à 18:10:00, Jack a écrit :
Here the output with valgrind when i create the gemwin :
Are there any « Invalid write » messages before getting there ?
Also note that GEM 93 and GEM 92 are quite binary-incompatible,
therefore an external has to be compiled with the right set of .h
files.
There were also at least two more intermediate steps for those who
used SVN versions of GEM 93. For example, GridFlow supports GEM 92
and two early kinds of GEM 93 but doesn't work with the final GEM 93.
I'm talking about this because :
Address 0x735ef68 is 0 bytes after a block of size 32 alloc'd
at 0x4025315: calloc (vg_replace_malloc.c:467)
by 0x80B8710: getbytes (in /usr/bin/pd)
Looks like an object has an unexpected size, which hints at
possible mismatching struct{} definitions.
__
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 -
Montréal, QC
Here the output of valgrind before i create the gemwin, it seems
there is no trace of 'invalid write' :
==2417== HEAP SUMMARY:
==2417== in use at exit: 10,269,451 bytes in 14,507 blocks
==2417== total heap usage: 44,542 allocs, 30,035 frees,
46,723,012 bytes allocated
==2417==
==2417== LEAK SUMMARY:
==2417==definitely lost: 14,663 bytes in 50 blocks
==2417==indirectly lost: 8,291 bytes in 488 blocks
==2417== possibly lost: 1,525 bytes in 56 blocks
==2417==still reachable: 10,244,972 bytes in 13,913 blocks
==2417== suppressed: 0 bytes in 0 blocks
==2417== Rerun with --leak-check=full to see details of leaked memory
==2417==
==2417== For counts of detected and suppressed errors, rerun with: -v
==2417== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482
from 11)
==2418==
==2418== HEAP SUMMARY:
==2418== in use at exit: 10,269,451 bytes in 14,507 blocks
==2418== total heap usage: 44,542 allocs, 30,035 frees,
46,723,012 bytes allocated
==2418==
==2418== LEAK SUMMARY:
==2418==definitely lost: 14,663 bytes in 50 blocks
==2418==indirectly lost: 8,291 bytes in 488 blocks
==2418== possibly lost: 1,525 bytes in 56 blocks
==2418==still reachable: 10,244,972 bytes in 13,913 blocks
==2418== suppressed: 0 bytes in 0 blocks
==2418== Rerun with --leak-check=full to see details of leaked memory
==2418==
==2418== For counts of detected and suppressed errors, rerun with: -v
==2418== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482
from 11)
==2419==
==2419== HEAP SUMMARY:
==2419== in use at exit: 10,269,451 bytes in 14,507 blocks
==2419== total heap usage: 44,542 allocs, 30,035 frees,
46,723,012 bytes allocated
==2419==
==2419== LEAK SUMMARY:
==2419==definitely lost: 14,663 bytes in 50 blocks
==2419==indirectly lost: 8,291 bytes in 488 blocks
==2419== possibly lost: 1,525 bytes in 56 blocks
==2419==still reachable: 10,244,972 bytes in 13,913 blocks
==2419== suppressed: 0 bytes in 0 blocks
==2419== Rerun with --leak-check=full to see details of leaked memory
==2419==
==2419== For counts of detected and suppressed errors, rerun with: -v
==2419== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482
from 11)
==2420==
==2420== HEAP SUMMARY:
==2420== in use at exit: 10,269,451 bytes in 14,507 blocks
==2420== total heap usage: 44,542 allocs, 30,035 frees,
46,723,012 bytes allocated
==2420==
==2420== LEAK SUMMARY:
==2420==definitely lost: 14,663 bytes in 50 blocks
==2420==indirectly lost: 8,291 bytes in 488 blocks
==2420== possibly lost: 1,525 bytes in 56 blocks
==2420==still reachable: 10,244,972 bytes in 13,913 blocks
==2420== suppressed: 0 bytes in 0 blocks
==2420== Rerun with --leak-check=full to see details of leaked memory
==2420==
==2420== For counts of detected and suppressed errors, rerun with: -v
==2420== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 482
from 11)
Thanx for your help.
++
Jack
hi!
did you try the examples included in openni and nite? are they
working? (eg. Sample-NiSimpleViewer, Sample-SceneAnalysis)
if you just create the gemwin without starting rendering is it still
crashing?
matthias
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Hello Matthias,
I don't have a kinect today. I will try later.
Creating the gemwin without the rendering doesn't crash Pd. (It was a
mistake to said that in my first email).
Thanx for your help.
ah ok, you tried it without kinect?
i just found a bug if there is no kinect available and you want to use
handtracking it crashed.
but i fixed that. so at least in osx there is no problem now to use
pix_openni without a kinect
Re: [PD] OT - C++ for reusable dsp lib - or better use C?
Le 2012-02-25 à 17:49:00, Hans-Christoph Steiner a écrit : I agree that instant feedback is very important, that's a big reason why I use Pd. I wonder if he's ever used Pd. Pd has been providing a lot of that experience for almost 2 decades now. The one thing in it that Pd does not provide is the ability to click on the generated image in order to see which code is generating that part of the image. That would be a nice feature to have. But I can't see how you would generalize beyond drawing pictures. It can't even generalise to all images. There's an OpenGL feature whether if you get a mouse position, you can tell the OpenGL engine to find any geos that contain that (x,y) location while drawing the next frame. I forgot what the name is and I never used it. But this can't possibly tell you anything about the construction of Gem pixes or GridFlow grids, in which solutions range from complicated to impossible, especially because a lot of objects modify all pixels in the image at once, but also because even for more localised edits of images, the objects currently don't track that info and it would take lots of work to make them do so... or create an image diff tool that would be very slow. Most ~-objects also operate on the whole signal. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] C++ for reusable dsp lib - or better use C?
Le 2012-02-22 à 08:42:00, IOhannes m zmoelnig a écrit : On 2012-02-22 06:46, Mathieu Bouchard wrote: So, are you switching GEM away from MSVC, or are you going to make a C API so that GEM can actually collaborate with other Pd-based frameworks that want to read its data on Windows ? well, yes; i'd like to Well, let's say that this interface is only for supporting pixes in other frameworks without having to go through [pix_data] and [pix_set]. What would you put in it ? Some kind of permanent interface for getting/setting xsize, ysize, csize, upsidedown, type and format ; something to see whether there's a pix at all, something for creating one, and some explanation of how newimage/newfilm is supposed to work... And a try/catch in every wrapper to protect against exception problems between MSVC and GCC. Or else just discontinuing the MSVC edition... which thing do you mean when you say that you would « like to » ? __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] OT - C++ for reusable dsp lib - or better use C?
On 2/26/12 10:29 AM, Mathieu Bouchard wrote: Le 2012-02-25 à 14:29:00, Phil Stone a écrit : IMO, Pd *approaches* this potential of live-coding, but isn't there yet. The edit/play dichotomy, The Edit/Play modes are there just to allow more different mouse commands. It's not really a feature of the engine, it's just for switching between two sets of mouse behaviours in the GUI, because there are not enough buttons. That's a good point, but the other problem I mentioned -- audio dropouts during editing, especially if the dsp graph needs recompiling -- is still a deal breaker for live *performance* coding (unless one embraces the glitches). Now, if by 'live', one just means highly interactive, I'll grant Pd that. That's more what I'm concerned with anyway -- a rapid connection between idea and execution, not necessarily doing programming in front of an audience. I also like programming in word languages, For what I presume you call a non-word language, Pd has quite a large vocabulary of words in it. I'm pretty sure you, and most readers of this list, understand the distinction I am making between graphics-dominated and text-dominated programming environments. Perhaps the scare quotes should be a tip that I'm not speaking in exactitudes at that moment. :-) Don't think that your points about the liveness of Pd are lost on me, though. I've been thinking about it a great deal since watching that video yesterday, and realized the very interactiveness the guy in the video was bragging about is something we take for granted. Number boxes change values instantly! Wow! I was excited, however, by the capability of changing underlying code by manipulating the product. Pd even nudges into that territory with its bastard son dynamic patching, but it's not particularly intuitive. Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] OT - C++ for reusable dsp lib - or better use C?
Le 2012-02-26 à 10:53:00, Phil Stone a écrit : On 2/26/12 10:29 AM, Mathieu Bouchard wrote: Le 2012-02-25 à 14:29:00, Phil Stone a écrit : I also like programming in word languages, For what I presume you call a non-word language, Pd has quite a large vocabulary of words in it. I'm pretty sure you, and most readers of this list, understand the distinction I am making between graphics-dominated and text-dominated programming environments. Perhaps the scare quotes should be a tip that I'm not speaking in exactitudes at that moment. :-) I know, but I still think that it was worth mentioning, just like I'd doubt that Pd is that much graphics-dominated... I know the distinction you're trying to make, and the graphics part of Pd is what we notice the most, but there's an awful (or awesome) lot of text in there. It's nice like that, though. I wouldn't trade a language to get a bucketful of icons. More often than not, one word is worth a thousand pictures. We won't be able to find what % of importance the graphics have in Pd in comparison to plain-text languages, but this time, I just want to point out that graphics in Pd look like they're dominating only because we're used to have text take nearly all the room. I don't necessarily have good replacement adjectives to provide you with. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
On Feb 26, 2012, at 11:50 AM, Mathieu Bouchard wrote: Le 2012-02-26 à 11:50:00, Roman Haefeli a écrit : On Fri, 2012-02-24 at 15:16 -0500, Mathieu Bouchard wrote: Le 2012-02-24 à 20:57:00, Roman Haefeli a écrit : In what way [import] shouldn't be used inside abstractions? [import] is not very local, is it ? But it also works with multi-class externals. See my other mail. But it's not very local, is it ? Where does it import symbols to ? A big global namespace. Yup, binary objects will be imported into the global namespace. Abstractions will be local though. .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
Re: [PD] MIDI input problems in PD
Hi, I have the same problem. It affects several computers running XP, Vista or Win7 and several Midi controllers; either connected to a RME multiface or through USB (Korg NanoPad / Berinhger BCR2000 or BCF2000 / Akai LPD8). Mostly using CC, hardly Midi-notes. And most of the time I go through Midi-Ox and a virtual midi port (midi yoke) to merge all controllers before sending to Pd. Midi-Ox checks for looping and should be able to prevent it and my patches try to limit looping and Midi data flow too. It does look like there is some overflow of the midi I/O buffers. I tend to limit the flow of data outgoing with [speedlim] and have a separate sessions of Pd for the control/GUI and audio with the audio/midi properties set differently between the two sessions. For me it happens after big rushes of data: if I instantiate all the parameters of a BCR2000 at once (over 100 parameters) at the same time as updating the GUI in Pd it's not that hard to overload the midi buffers and create this problem and it doesn't take two hours to crash then... :) And if you send a lot of stuff from the controllers too then it can lead to the same issue. I'm not sure it's only the flow of midi data, but it could be the Midi data plus a lot of processing in Pd, especially with GUI objects moving in response to the Midi input. Re-instantiating the Midi-settings seems to flush the buffers, but sometimes it takes a reboot to make the problem go away once everything is stuck. Cheers Pierre-Olivier On 26/02/2012 08:28, Ingo wrote: I had the same problem with Windows XP and a RME Hammerfall DSP card using only the normal [notein], [ctlin], [toutchin] and [pgmin] for a sampling synth. I don't think it's the midi interface. RME has some of the best drivers - very stable. Sometimes after a certain amount of time it started playing notes by itself and didn't seem to stop anymore. It sounded like notes or melodies that I had been playing before. Nothing random. Could it be possible that midi data is written into a buffer that does not get emptied anymore? Then something might trigger reading out that buffer? I couldn't recreate why it happened. Most of the time it didn't do it but every once in a while it did. I had no problem ever running Nuendo for days on that same machine programming midi. The same Pd patch was doing fine on a Linux computer after switching to Linux. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Miller Puckette Gesendet: Sonntag, 26. Februar 2012 00:04 An: Villa Anna Cc: pd-list Betreff: Re: [PD] MIDI input problems in PD I haven't seen this problem, but I have to admit I don't think I ever ran MIDI into a Windows machine for more than 2 hours at a time (back when I acually used MIDI Windows itself wasn't stable enough to run for that long at a time :) It's hard to know whether this is the MOTU driver misbehaving in windows 7 or something with Pd itself - my only suggestion would be to try either (1) switching interfaces to something more modern than 828MKII or (2) try using some other software to see if the problem is specific to PD. cheers Miller On Sat, Feb 25, 2012 at 11:03:32AM +0100, Villa Anna wrote: Dear list, I have problems with Midi input in PD. I use Windows 7 and make use of a Motu 828MKII soundcard. I receive MIDI via a polytouchin object (make use of FSRs and a coridium armmite to translate pressure on the FSRs to Midi messages). All goes fine in the beginning, but sometimes after a while (f.e. 2 hours) my Midi input starts to be random (FSRs trigger that are not supposed to be triggering). If I restart PD everything is back to normal. Any idea what the cause of this problem might be? It's an installation project so it is difficult to restart everything from time to time. Thanks in advance for your help! Laura ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
Le 2012-02-26 à 14:11:00, Hans-Christoph Steiner a écrit : On Feb 26, 2012, at 11:50 AM, Mathieu Bouchard wrote: Where does it import symbols to ? A big global namespace. Yup, binary objects will be imported into the global namespace. Abstractions will be local though. Oh, yes, because abstractions are never listed as part of pd_objectmaker : only externals are. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] C++ for reusable dsp lib - or better use C?
On Sun, Feb 26, 2012 at 01:15:33PM -0500, Mathieu Bouchard wrote: You don't need to spit out that kind of gratuitous nonsense. Thanks. You take it from here, I'll put me feet up. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] MIDI input problems in PD
Drat, I can't reproduce this yet... I don't have any real MIDI devices, just USB keyboards that fake MIDI, so perhaps I need to track down an old-fashioned MIDI device somewhere :) M On Sun, Feb 26, 2012 at 08:15:32PM +0100, Pierre-Olivier Boulant wrote: Hi, I have the same problem. It affects several computers running XP, Vista or Win7 and several Midi controllers; either connected to a RME multiface or through USB (Korg NanoPad / Berinhger BCR2000 or BCF2000 / Akai LPD8). Mostly using CC, hardly Midi-notes. And most of the time I go through Midi-Ox and a virtual midi port (midi yoke) to merge all controllers before sending to Pd. Midi-Ox checks for looping and should be able to prevent it and my patches try to limit looping and Midi data flow too. It does look like there is some overflow of the midi I/O buffers. I tend to limit the flow of data outgoing with [speedlim] and have a separate sessions of Pd for the control/GUI and audio with the audio/midi properties set differently between the two sessions. For me it happens after big rushes of data: if I instantiate all the parameters of a BCR2000 at once (over 100 parameters) at the same time as updating the GUI in Pd it's not that hard to overload the midi buffers and create this problem and it doesn't take two hours to crash then... :) And if you send a lot of stuff from the controllers too then it can lead to the same issue. I'm not sure it's only the flow of midi data, but it could be the Midi data plus a lot of processing in Pd, especially with GUI objects moving in response to the Midi input. Re-instantiating the Midi-settings seems to flush the buffers, but sometimes it takes a reboot to make the problem go away once everything is stuck. Cheers Pierre-Olivier On 26/02/2012 08:28, Ingo wrote: I had the same problem with Windows XP and a RME Hammerfall DSP card using only the normal [notein], [ctlin], [toutchin] and [pgmin] for a sampling synth. I don't think it's the midi interface. RME has some of the best drivers - very stable. Sometimes after a certain amount of time it started playing notes by itself and didn't seem to stop anymore. It sounded like notes or melodies that I had been playing before. Nothing random. Could it be possible that midi data is written into a buffer that does not get emptied anymore? Then something might trigger reading out that buffer? I couldn't recreate why it happened. Most of the time it didn't do it but every once in a while it did. I had no problem ever running Nuendo for days on that same machine programming midi. The same Pd patch was doing fine on a Linux computer after switching to Linux. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Miller Puckette Gesendet: Sonntag, 26. Februar 2012 00:04 An: Villa Anna Cc: pd-list Betreff: Re: [PD] MIDI input problems in PD I haven't seen this problem, but I have to admit I don't think I ever ran MIDI into a Windows machine for more than 2 hours at a time (back when I acually used MIDI Windows itself wasn't stable enough to run for that long at a time :) It's hard to know whether this is the MOTU driver misbehaving in windows 7 or something with Pd itself - my only suggestion would be to try either (1) switching interfaces to something more modern than 828MKII or (2) try using some other software to see if the problem is specific to PD. cheers Miller On Sat, Feb 25, 2012 at 11:03:32AM +0100, Villa Anna wrote: Dear list, I have problems with Midi input in PD. I use Windows 7 and make use of a Motu 828MKII soundcard. I receive MIDI via a polytouchin object (make use of FSRs and a coridium armmite to translate pressure on the FSRs to Midi messages). All goes fine in the beginning, but sometimes after a while (f.e. 2 hours) my Midi input starts to be random (FSRs trigger that are not supposed to be triggering). If I restart PD everything is back to normal. Any idea what the cause of this problem might be? It's an installation project so it is difficult to restart everything from time to time. Thanks in advance for your help! Laura ___ 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] MIDI input problems in PD
Le 2012-02-26 à 13:11:00, Miller Puckette a écrit : I don't have any real MIDI devices, just USB keyboards that fake MIDI, That's a matter of ontology. What is reality ? I mean the real reality. Politically correct Wikipedia instead calls USB an « Alternative hardware transport » for (real) MIDI. http://en.wikipedia.org/wiki/MIDI#Alternative_hardware_transports __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] MIDI input problems in PD
I was using MIDI OX as well. I wonder if Laura did. If yes, it could be related to MIDI OX as well. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Miller Puckette Gesendet: Sonntag, 26. Februar 2012 22:11 An: Pierre-Olivier Boulant Cc: PD-List Betreff: Re: [PD] MIDI input problems in PD Drat, I can't reproduce this yet... I don't have any real MIDI devices, just USB keyboards that fake MIDI, so perhaps I need to track down an old-fashioned MIDI device somewhere :) M On Sun, Feb 26, 2012 at 08:15:32PM +0100, Pierre-Olivier Boulant wrote: Hi, I have the same problem. It affects several computers running XP, Vista or Win7 and several Midi controllers; either connected to a RME multiface or through USB (Korg NanoPad / Berinhger BCR2000 or BCF2000 / Akai LPD8). Mostly using CC, hardly Midi-notes. And most of the time I go through Midi-Ox and a virtual midi port (midi yoke) to merge all controllers before sending to Pd. Midi-Ox checks for looping and should be able to prevent it and my patches try to limit looping and Midi data flow too. It does look like there is some overflow of the midi I/O buffers. I tend to limit the flow of data outgoing with [speedlim] and have a separate sessions of Pd for the control/GUI and audio with the audio/midi properties set differently between the two sessions. For me it happens after big rushes of data: if I instantiate all the parameters of a BCR2000 at once (over 100 parameters) at the same time as updating the GUI in Pd it's not that hard to overload the midi buffers and create this problem and it doesn't take two hours to crash then... :) And if you send a lot of stuff from the controllers too then it can lead to the same issue. I'm not sure it's only the flow of midi data, but it could be the Midi data plus a lot of processing in Pd, especially with GUI objects moving in response to the Midi input. Re-instantiating the Midi-settings seems to flush the buffers, but sometimes it takes a reboot to make the problem go away once everything is stuck. Cheers Pierre-Olivier On 26/02/2012 08:28, Ingo wrote: I had the same problem with Windows XP and a RME Hammerfall DSP card using only the normal [notein], [ctlin], [toutchin] and [pgmin] for a sampling synth. I don't think it's the midi interface. RME has some of the best drivers - very stable. Sometimes after a certain amount of time it started playing notes by itself and didn't seem to stop anymore. It sounded like notes or melodies that I had been playing before. Nothing random. Could it be possible that midi data is written into a buffer that does not get emptied anymore? Then something might trigger reading out that buffer? I couldn't recreate why it happened. Most of the time it didn't do it but every once in a while it did. I had no problem ever running Nuendo for days on that same machine programming midi. The same Pd patch was doing fine on a Linux computer after switching to Linux. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Miller Puckette Gesendet: Sonntag, 26. Februar 2012 00:04 An: Villa Anna Cc: pd-list Betreff: Re: [PD] MIDI input problems in PD I haven't seen this problem, but I have to admit I don't think I ever ran MIDI into a Windows machine for more than 2 hours at a time (back when I acually used MIDI Windows itself wasn't stable enough to run for that long at a time :) It's hard to know whether this is the MOTU driver misbehaving in windows 7 or something with Pd itself - my only suggestion would be to try either (1) switching interfaces to something more modern than 828MKII or (2) try using some other software to see if the problem is specific to PD. cheers Miller On Sat, Feb 25, 2012 at 11:03:32AM +0100, Villa Anna wrote: Dear list, I have problems with Midi input in PD. I use Windows 7 and make use of a Motu 828MKII soundcard. I receive MIDI via a polytouchin object (make use of FSRs and a coridium armmite to translate pressure on the FSRs to Midi messages). All goes fine in the beginning, but sometimes after a while (f.e. 2 hours) my Midi input starts to be random (FSRs trigger that are not supposed to be triggering). If I restart PD everything is back to normal. Any idea what the cause of this problem might be? It's an installation project so it is difficult to restart everything from time to time. Thanks in advance for your help! Laura ___ 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 -
Re: [PD] MIDI input problems in PD
I had the same problem without Midi-Ox too. pob On 26/02/2012 22:28, Ingo wrote: I was using MIDI OX as well. I wonder if Laura did. If yes, it could be related to MIDI OX as well. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Miller Puckette Gesendet: Sonntag, 26. Februar 2012 22:11 An: Pierre-Olivier Boulant Cc: PD-List Betreff: Re: [PD] MIDI input problems in PD Drat, I can't reproduce this yet... I don't have any real MIDI devices, just USB keyboards that fake MIDI, so perhaps I need to track down an old-fashioned MIDI device somewhere :) M On Sun, Feb 26, 2012 at 08:15:32PM +0100, Pierre-Olivier Boulant wrote: Hi, I have the same problem. It affects several computers running XP, Vista or Win7 and several Midi controllers; either connected to a RME multiface or through USB (Korg NanoPad / Berinhger BCR2000 or BCF2000 / Akai LPD8). Mostly using CC, hardly Midi-notes. And most of the time I go through Midi-Ox and a virtual midi port (midi yoke) to merge all controllers before sending to Pd. Midi-Ox checks for looping and should be able to prevent it and my patches try to limit looping and Midi data flow too. It does look like there is some overflow of the midi I/O buffers. I tend to limit the flow of data outgoing with [speedlim] and have a separate sessions of Pd for the control/GUI and audio with the audio/midi properties set differently between the two sessions. For me it happens after big rushes of data: if I instantiate all the parameters of a BCR2000 at once (over 100 parameters) at the same time as updating the GUI in Pd it's not that hard to overload the midi buffers and create this problem and it doesn't take two hours to crash then... :) And if you send a lot of stuff from the controllers too then it can lead to the same issue. I'm not sure it's only the flow of midi data, but it could be the Midi data plus a lot of processing in Pd, especially with GUI objects moving in response to the Midi input. Re-instantiating the Midi-settings seems to flush the buffers, but sometimes it takes a reboot to make the problem go away once everything is stuck. Cheers Pierre-Olivier On 26/02/2012 08:28, Ingo wrote: I had the same problem with Windows XP and a RME Hammerfall DSP card using only the normal [notein], [ctlin], [toutchin] and [pgmin] for a sampling synth. I don't think it's the midi interface. RME has some of the best drivers - very stable. Sometimes after a certain amount of time it started playing notes by itself and didn't seem to stop anymore. It sounded like notes or melodies that I had been playing before. Nothing random. Could it be possible that midi data is written into a buffer that does not get emptied anymore? Then something might trigger reading out that buffer? I couldn't recreate why it happened. Most of the time it didn't do it but every once in a while it did. I had no problem ever running Nuendo for days on that same machine programming midi. The same Pd patch was doing fine on a Linux computer after switching to Linux. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Miller Puckette Gesendet: Sonntag, 26. Februar 2012 00:04 An: Villa Anna Cc: pd-list Betreff: Re: [PD] MIDI input problems in PD I haven't seen this problem, but I have to admit I don't think I ever ran MIDI into a Windows machine for more than 2 hours at a time (back when I acually used MIDI Windows itself wasn't stable enough to run for that long at a time :) It's hard to know whether this is the MOTU driver misbehaving in windows 7 or something with Pd itself - my only suggestion would be to try either (1) switching interfaces to something more modern than 828MKII or (2) try using some other software to see if the problem is specific to PD. cheers Miller On Sat, Feb 25, 2012 at 11:03:32AM +0100, Villa Anna wrote: Dear list, I have problems with Midi input in PD. I use Windows 7 and make use of a Motu 828MKII soundcard. I receive MIDI via a polytouchin object (make use of FSRs and a coridium armmite to translate pressure on the FSRs to Midi messages). All goes fine in the beginning, but sometimes after a while (f.e. 2 hours) my Midi input starts to be random (FSRs trigger that are not supposed to be triggering). If I restart PD everything is back to normal. Any idea what the cause of this problem might be? It's an installation project so it is difficult to restart everything from time to time. Thanks in advance for your help! Laura ___ 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 -- ~Pierre-Olivier Boulant ~ -o- www.puffskydd.net
Re: [PD] [PD-announce] Pd 0.43-2 test 1 released
unfortunately not entirely (i could only test the git version (rev: bb91ad26e16), due to my bad internet connection). i still get a tcl error, when trying to change the number of items of an [hradio] in a closed subpatch [1]. see attached patch that illustrates the problem. it would be great if this minor annoyance could somehow be fixed. You may want to try out pd-l2ork's version of iemgui objects that in addition to offering resize/move hooks also take care of unnecessary redraws. I suspect merging those source files with core pd should be relatively seamless as they've been for the most part edited as independent entities. Cheers! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] pdlua and tclpd: now embedded in Pd-extended 0.43
There are two new, easy ways to write objects for Pd: tclpd by Federico Ferri and pdlua by Claude Heiland-Allen, Frank Barknecht and Martin Peach. Both are now included in Pd-extended 0.43 and are automatically loaded at startup. That means you can write a script in Lua or Tcl and have that script be a true object in Pd. Both pdlua and tclpd provide the large majority of the Pd externals API, and you can even write GUI objects using tclpd. Tcl and Lua both excel at handling strings, one thing that Pd is not the best at, so if you have a project that needs to parse or manage a lot of strings, then you have a new approach. There are some other ways of using other languages to write objects for Pd: pyext for Python and pdj for Java. These two are different in a key way than pdlua and tclpd. pyext and pdj allow you to load scripts into an object called [pyext] or [pdj]. tclpd and pdlua let you create full Pd objects that are completely transparent to the user. You create an object written in tclpd or pdlua just like any other Pd object, and those objects can have their own help patch too. Both pdlua and tclpd come with a lot of examples, go to the Help Browser and find them in the list of libraries there. I also started writing the 'tclfile' library to bring the Tcl file API to Pd: http://puredata.info/downloads/tclfile .hc ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] -rt startup flag ignored
Hey Edgar, Try a nightly beta build of 0.43, I think this should be fixed: http://autobuild.puredata.info/auto-build/latest/ .hc On Feb 23, 2012, at 4:49 PM, Edgar Berdahl wrote: Hi, I believe that the -rt flag is still ignored in extended version 0.42.5. To debug this, I am using my own version of ps which lists the threads and also RTPRIO priorities: ps -eLo pid,class,rtprio,ni,pri,pcpu,stat,comm --sort -rtprio Depending on your kernel settings, it might be harder for you to verify this, but I imagine you might find in the source code where it parses flags in .pdextended that it simply doesn't check for -rt. If I start pd with -rt specified neither in ~/.pdextended nor on the command line, I get these priorities: PID CLS RTPRIO NI PRI %CPU STAT COMMAND 1299 TS - 0 19 19.8 RLl pd 1299 TS - 0 19 0.0 SLl pd 1299 FF 57 - 97 2.1 SLl pd 1299 TS - 0 19 0.0 SLl pd but if I start with -rt flags field of ~/.pdextended I get the same realtime priority for all the pd threads! PID CLS RTPRIO NI PRI %CPU STAT COMMAND 1263 TS - 0 19 23.3 RLl pd 1263 TS - 0 19 0.0 SLl pd 1263 FF 57 - 97 1.8 SLl pd 1263 TS - 0 19 0.0 SLl pd (I even tried putting -rt in two different places in flags) However, if I start using -rt on the command line I get the following priorities, for which all of the pd threads have at least RTPRIO 6: PID CLS RTPRIO NI PRI %CPU STAT COMMAND 1237 FF 6 - 46 30.9 SLl pd 1237 FF 6 - 46 0.0 SLl pd 1237 FF 57 - 97 1.1 SLl pd 1237 FF 6 - 46 0.0 SLl pd and then I don't get dropouts anymore. So for me, it is essential to use this option. For the time being, my workaround is simply to put this shell script in ~/bin to add -rt to the flags every time the user calls pd: #!/bin/bash # # Shell script to make pd always start with -rt, no matter what # the user types. /usr/bin/pd -rt $* Warm regards! - Edgar PS. See also: http://lists.puredata.info/pipermail/pd-list/2006-08/041087.html ___ 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
[PD] ANN: pd-l2ork 20120226 snapshot now available
This release includes following fixes: *MyCanvas does not become invisible if it is partially visible in GOP mode *copy-paste from console does not work with the ctrl+c shortcut *Proper focusing out of the selection (where typing into .printout console makes problems for textedfor objects) *Resizing window when text is hidden still prevents resizing below the text size *GOP resize hooks should be visible only if no object is selected *when re-saving prototype abstraction it disappears on the parent canvas *disis_wiimote does not re-detect motion plus every time when re-connecting and re-enabling the extension (partially fixed (needs update to libCwiid, will be updated soon)--for the time being, easiest thing is to enable extension twice; NB: this will not be necessary once the libCwiid is updated) *image and other non-vanilla objects do not translate with the GOP *ggee objects button and image updated, gcanvas disabled as it has too many bugs to be worth fixing (IMO) *implemented gop legacy redraw *selection as part of the infinite undo (for those tricky selections that take a while to do and can be messed up with a single mis-click) NB: ctrl+a is currently ignored, mainly because it is easy to do but will be likely addressed in the next release L2Ork now also supports builds for both 32-bit and 64-bit Linux systems and can be downloaded from the usual place: http://l2ork.music.vt.edu/main/?page_id=56 Bug reports are in high demand, so get busy and let me know of any potential hiccups. -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Mac OS X/PowerPC builds needed
So the Mac OS X PowerPC machine from the build farm has died. The hard drive is intact, so all the data is there. I also have much more limited time for maintaining the PdLab machines. So I'm looking for someone to host the Mac OS X PowerPC builds. It can be really any recent PowerPC Mac. The old machine was a 300MHz G4. Can anyone take this on? I'd hate to see Mac OS X/PowerPC dropped from the supported platforms since they are still quite capable machines. .hc We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork 20120226 snapshot now available
Any chance of these fixes being submitted upstream? These two in particular seem useful and probably easily applicable: *image and other non-vanilla objects do not translate with the GOP *ggee objects button and image updated .hc On Feb 26, 2012, at 8:52 PM, Ivica Ico Bukvic wrote: This release includes following fixes: *MyCanvas does not become invisible if it is partially visible in GOP mode *copy-paste from console does not work with the ctrl+c shortcut *Proper focusing out of the selection (where typing into .printout console makes problems for textedfor objects) *Resizing window when text is hidden still prevents resizing below the text size *GOP resize hooks should be visible only if no object is selected *when re-saving prototype abstraction it disappears on the parent canvas *disis_wiimote does not re-detect motion plus every time when re-connecting and re-enabling the extension (partially fixed (needs update to libCwiid, will be updated soon)--for the time being, easiest thing is to enable extension twice; NB: this will not be necessary once the libCwiid is updated) *image and other non-vanilla objects do not translate with the GOP *ggee objects button and image updated, gcanvas disabled as it has too many bugs to be worth fixing (IMO) *implemented gop legacy redraw *selection as part of the infinite undo (for those tricky selections that take a while to do and can be messed up with a single mis-click) NB: ctrl+a is currently ignored, mainly because it is easy to do but will be likely addressed in the next release L2Ork now also supports builds for both 32-bit and 64-bit Linux systems and can be downloaded from the usual place: http://l2ork.music.vt.edu/main/?page_id=56 Bug reports are in high demand, so get busy and let me know of any potential hiccups. -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list 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
[PD] pd mentioned in squarepusher interview
right at the very end of this 10 minute interview, Tom mentions PD (while showing off his reaktor patches, though :p ) http://www.thecreatorsproject.com/en-uk/creators/squarepusher ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: pd-l2ork 20120226 snapshot now available
Any chance of these fixes being submitted upstream? These two in particular seem useful and probably easily applicable: Not really. Please see below: *image and other non-vanilla objects do not translate with the GOP This is because pd-l2ork moves GOP objects by tag (as of sometime in January), including arrays and scalars, which makes moving them vastly faster. This change is gargantuan and requires widgetbehavior to be expanded by one additional call. This latest addition simply makes sure that the system falls back on the old erase/redraw whenever gop is moved in case one of its displayed objects does not support the added widgetbehavior (this was the case with non-gop objects but now gop is supporting the same fallback method as well and thus ensuring that all properly working legacy objects are supported). So, no, porting this upstream means a lot more changes than just this. It also does not affect upstream since it does not support moving gop objects by tag. *ggee objects button and image updated Ditto for this one as it also includes aspects that incorporate the aforesaid widgetbehavior. Long story short, the fundamental question is whether the core pd devs are conducive to the idea of overhauling g_canvas.h and breaking binary compatibility which is the only way you'll get these kinds of changes in without rewriting a lot more than what has gone into this (which is already a pretty decent chunk). Best wishes, Ico .hc On Feb 26, 2012, at 8:52 PM, Ivica Ico Bukvic wrote: This release includes following fixes: *MyCanvas does not become invisible if it is partially visible in GOP mode *copy-paste from console does not work with the ctrl+c shortcut *Proper focusing out of the selection (where typing into .printout console makes problems for textedfor objects) *Resizing window when text is hidden still prevents resizing below the text size *GOP resize hooks should be visible only if no object is selected *when re-saving prototype abstraction it disappears on the parent canvas *disis_wiimote does not re-detect motion plus every time when re- connecting and re-enabling the extension (partially fixed (needs update to libCwiid, will be updated soon)--for the time being, easiest thing is to enable extension twice; NB: this will not be necessary once the libCwiid is updated) *image and other non-vanilla objects do not translate with the GOP *ggee objects button and image updated, gcanvas disabled as it has too many bugs to be worth fixing (IMO) *implemented gop legacy redraw *selection as part of the infinite undo (for those tricky selections that take a while to do and can be messed up with a single mis-click) NB: ctrl+a is currently ignored, mainly because it is easy to do but will be likely addressed in the next release L2Ork now also supports builds for both 32-bit and 64-bit Linux systems and can be downloaded from the usual place: http://l2ork.music.vt.edu/main/?page_id=56 Bug reports are in high demand, so get busy and let me know of any potential hiccups. -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list 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] Mac OS X/PowerPC builds needed
Does anyone use Power PC for audio work anymore? Also, is there a 10.7 machine? The latter seems more in demand. cheers, Rich On Mon, Feb 27, 2012 at 12:56 PM, Hans-Christoph Steiner h...@at.or.atwrote: So the Mac OS X PowerPC machine from the build farm has died. The hard drive is intact, so all the data is there. I also have much more limited time for maintaining the PdLab machines. So I'm looking for someone to host the Mac OS X PowerPC builds. It can be really any recent PowerPC Mac. The old machine was a 300MHz G4. Can anyone take this on? I'd hate to see Mac OS X/PowerPC dropped from the supported platforms since they are still quite capable machines. .hc We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ 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] ANN: pd-l2ork 20120226 snapshot now available
Great! One question: what is implemented gop legacy redraw about? -Jonathan - Original Message - From: Ivica Ico Bukvic i...@vt.edu To: pd-list@iem.at; linux-audio-u...@lists.linuxaudio.org; pik...@piksel.no Cc: Sent: Sunday, February 26, 2012 8:52 PM Subject: [PD] ANN: pd-l2ork 20120226 snapshot now available T his release includes following fixes: *MyCanvas does not become invisible if it is partially visible in GOP mode *copy-paste from console does not work with the ctrl+c shortcut *Proper focusing out of the selection (where typing into .printout console makes problems for textedfor objects) *Resizing window when text is hidden still prevents resizing below the text size *GOP resize hooks should be visible only if no object is selected *when re-saving prototype abstraction it disappears on the parent canvas *disis_wiimote does not re-detect motion plus every time when re-connecting and re-enabling the extension (partially fixed (needs update to libCwiid, will be updated soon)--for the time being, easiest thing is to enable extension twice; NB: this will not be necessary once the libCwiid is updated) *image and other non-vanilla objects do not translate with the GOP *ggee objects button and image updated, gcanvas disabled as it has too many bugs to be worth fixing (IMO) *implemented gop legacy redraw *selection as part of the infinite undo (for those tricky selections that take a while to do and can be messed up with a single mis-click) NB: ctrl+a is currently ignored, mainly because it is easy to do but will be likely addressed in the next release L2Ork now also supports builds for both 32-bit and 64-bit Linux systems and can be downloaded from the usual place: http://l2ork.music.vt.edu/main/?page_id=56 Bug reports are in high demand, so get busy and let me know of any potential hiccups. -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ 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] ANN: pd-l2ork 20120226 snapshot now available
Great! One question: what is implemented gop legacy redraw about? Great question. Since January pd-l2ork by default moves gop/array/scalar groups of objects via tag. In layman terms this means instead of having to redraw entire gop object every time it is moved even by one pixel (e.g. dragging gop with mouse would generate dozens of these events per second), moves it all with a single tcl command. This newly implemented feature however did not account for objects that do not support moving by tag (mainly 3rd party gui externals that do not have moving by tag implemented). This has made gop displacing with such objects embedded not work properly for the said objects. So, now if you have a gop object that also includes one of the said 3rd party gui externals, it falls back gracefully to the old way of redrawing the gop object which is terribly inefficient but at least it works seamlessly for both cases. From L2Ork's perspective, we use almost exclusively built-in iemgui objects for all our needs with the ggee/image being one notable exception that has been also updated and cleaned-up for this release, including support for moving with tag. To give you some perspective just what kind of a difference this makes performances-wise, make a gop object that has iemgui/vanilla objects only, and then create another with the ggee/button object (for instance) and observe the difference. For a really fun experience try running pd-l2ork with -d 1 debugging enabled to see the console printout difference. Hope this helps! P.S. if there is an exhaustive list of 3rd party gui externals and their breakdown between those that are well supported and those that are not, this would be particularly helpful as I could then try to tackle them one-by-one until they've all been revamped. NB: text objects and other 3rd party externals that don't have custom guis are supported out-of-box even prior to the aforesaid fix. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Japanese Pure Data book is out now.
Hi, Thank you for many people having curiosity to this Pd Recipe Book even it is written in Japanese. I feel truly honored :) All the contents including articles, interviews, diagrams, etc. are officially controlled under copyrights of the author and the publisher. So I am afraid I can not handle it only by myself, now. If any English publishers officially give any offers of translation for the publication, it is welcome. However, I know there are so many excellent English texts about Pd. Cheers, Sei Matsumura 2012年2月25日6:39 Mathieu Bouchard ma...@artengine.ca: Le 2012-02-24 à 20:56:00, Julian Brooks a écrit : On 24 February 2012 17:44, Mathieu Bouchard ma...@artengine.ca wrote: Le 2012-02-24 à 10:53:00, Julian Brooks a écrit : So in a wonderfully circular twist: Any chance of an English ebook translation (preferably free, of course)? Why aim for just free, when you can aim for getting paid to read it. You offering? Or do I have to wait for that fantasy academia post. No, I'm just thinking that you could apply as a reviewing consultant for the English translation of the book. (DISCLAIMER : this email does not count as an endorsement of any kind. It also does not count as the opposite of one. I am not responsible for any use anyone makes of this email, including but not limited to... et cætera) __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ 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] pd mentioned in squarepusher interview
Le 2012-02-27 à 11:14:00, i go bananas a écrit : right at the very end of this 10 minute interview, Tom mentions PD (while showing off his reaktor patches, though :p ) I don't know whether you get the same subtitles as I do, but in the French subtitles, it says « PD, Reactor ou Maximus P ». Maximus P ?? lol __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd mentioned in squarepusher interview
ha ha, that's not a bad guess though. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
