Re: [PD-dev] adding an inlet and outlet to [table]
Le 2012-02-26 à 20:38:00, Hans-Christoph Steiner a écrit : After some probing, I figured out what the table object is: its an instance of t_canvas/t_glist actually, with its own custom table_new() method. That's a pretty odd situation. I'm thinking I'll strip that out to make [table] an object in its own right, and then add inlets like [tabwrite] and an outlet like [tabread]. To be compatible with the current [table], this would need to support all of the methods of the canvases, just like tables already do. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] Filter design for iPhone
Le 2012-03-22 à 00:39:00, Ed Kelly a écrit : I'm anxious to know what limit is reached in the coefficients of the filter that causes the undefined result (NaN). I haven't seen the code, but I just want to make you notice that adding together -Infinity and +Infinity results in a NaN ; so does subtracting two infinities of the same sign. So, the NaN might happen when two expressions that are supposed to partially cancel each other, happen to both overflow, in different directions. There are various possible causes for NaN, but with formulas that only involve +, - and *, the possibilities are a lot more limited. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Problem with [iemnet/tcpclient]? (was: Sporadic crashes of Pd)
Le 2012-03-15 à 14:34:00, Roman Haefeli a écrit : I tried running it with valgrind, but then Pd doesn't crash anymore. Could it be, that the overhead added by valgrind makes Pd so slow, that it doesn't trigger anymore? Sometimes it's because the debugged programme becomes slower ; but sometimes it's that the debugged programme has a different thread-switching pattern that causes it to accidentally avoid the problem ; and sometimes it's because valgrind's malloc-patterns causes it to accidentally avoid the problem ; and so on. This stuff can get quite complicated. It's not by coïncidence that computer programming language designers really have spent a lot of time designing thorough memory-protection and lots of thread-safety measures. It's because troubleshooting bugs is really long and frustrating. For various reasons, memory protection is not enforced in C/C++/ObjC, and for various reasons, thread-safety is not enforceable (every thread-safety measure is a two-edged sword). __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Problem with [iemnet/tcpclient]? (was: Sporadic crashes of Pd)
Le 2012-03-13 à 14:52:00, Roman Haefeli a écrit : $ gdb -ex run --args pd-extended -noprefs -nrt -noaudio -stderr -open crashertest.pd Where did you find -ex ? I had been making a lot of pirouettes to get gdb to run commands that I wanted, which were not very good. I wanted to have -ex all those years. http://sourceware.org/bugzilla/show_bug.cgi?id=12756 __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Sporadic crashes of Pd
Le 2012-03-07 à 11:39:00, Roman Haefeli a écrit : From the many backtraces I collected, most of them look very similar: If the crashes vary and happen at seemingly random times, then there might be a single bug with different manifestations. If you patch takes a very low percentage of CPU, you may try running it with Valgrind, which might be able to find a cause for it, usually « Invalid Write », and sometimes might even be able to find a cause to the cause. However, it's also possible that there are several bugs at once, who knows... #2 0x00508b79 in iemnet__receiver_destroy () from /usr/local/lib/pd/extra/iemnet/libiemnet.so #3 0x08211148 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (What does the last line mean?) Something blew the backtrace. If it happens at #0, then it's possible that running unwanted code causes the stack to not be findable, but at #3, it's more like the stack is findable but got damaged, possibly by writing past the end of a C array on the stack (non-malloc). What can I do to help to track down the reason for those crashes? Would using valgrind reveal more useful information here? If the crashes are random-looking, or otherwise mysterious, Valgrind is always a good guess. Is it possible to tell from the backtraces, whether the cause is in Pd itself or in the externals used? From the backtrace of GDB, you can't be super sure. This points at a well-tested part of Pd. It would be a bit weird if it crashed here because of a bug in that part of pd, except if it happened in a test version of Pd that happened to have modifs in that area of the project. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] problem with routing mail to pd-dev ?
I just wrote a comment in « [grid] not working in pd-extended 0.43.1 » and it didn't go through to the pd-dev list. I'm wondering what the selection process is, for routing those comments to pd-dev. I wrote it while logged in to sourceforge (using my new account, not the one I used years ago). My other comment with the same account went through, today, some minutes before. https://sourceforge.net/tracker/?func=detailatid=478070aid=3497473group_id=55736 __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] problem with routing mail to pd-dev ?
Le 2012-03-06 à 17:58:00, IOhannes m zmoelnig a écrit : i'm not sure i fully understand your problem. since some time, hans has disabled the automatic email notifications of follow-ups in the Bugs tracker. i checked and it seems that in the Patch tracker, still has the notifications for follow-ups enabled. could that be the cause of your troubles? Well, I'm not going to say that I'm for nor against having such notifications, but those settings don't seem very consistent, and I cannot guess why this is set up in this manner. I would guess that most other subscribers of pd-dev have no idea either ? __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] fontwidth and nogui
Le 2012-02-19 à 10:05:00, Miller Puckette a écrit : It's hilarious - there's exactly one aspect of Pd run-time semantics that depends on screen location -- inlets/outlets of subpatches are numbered in left-to-right order on teh screen. To to thins someone has to call gobj_getrect() on the inlet/outlet, which then not only has to report the northwest corner but the entire rectangle, which depends on font size. You don't have to call gobj_getrect(), you need only te_xpix to figure out the order. But run-time semantics that depend on screen location is a bug. When it's like that by design, it's a bug by design, because there's a bug in the design. It's not as palpable as a bug in the implementation, which you can tell because the programme does not do as the design says. So people can argue endlessly about it, but you can still recognise that there's a problem with the design because people spend significant time talking about the gotcha, suggesting workarounds for the gotcha, teaching the gotcha, avoiding the gotcha, complaining about the gotcha ; and all along, things could have been better (unlike other things that look like a design bug but in which all solutions are equally annoying). It's also not hilarious... I mean, people who want to make fun of Pd may and will laugh about it, but for the users, it's not a big big fun. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] fontwidth and nogui
Le 2012-02-19 à 10:30:00, Miller Puckette a écrit : That it's painful doesn't make it any less funny to me. CROC Magazine's motto was : « C'est pas parce qu'on rit que c'est drôle », in the sense that just because we laugh doesn't mean it's funny. pages to explain the considerations that went, in 1987 or early 1988, That's the past. What do you want the future to be ? into the decision to arrange inlets/outlets that way but the circumstances were quite different from today's There were different circumstances, but I don't think that the forces at work and the goals are any different, when you just think about the ability to program something (anything) with Pd. Perhaps the ambient beliefs (zeitgeist) are different now. In any case, that's history, and Pd has always had the opportunity to switch people to a new inlet/outlet system with a new name... it has just never taken it. Many things are a lot harder to change than this. and seeing this particular unintended consequence (and the remoteness of its connection with the original situation) well, I just find it hilarious. I'll know never to make that particular mistake again :) How would you ever have the opportunity of ever making that mistake again ? I mean, apart from keeping the current meanings of [inlet] and [outlet] instead of migrating to a new system... Besides, why did you repeat the same design when rewriting MAX from scratch under the name PureData ? __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] fontwidth and nogui
Le 2012-02-19 à 17:46:00, Hans-Christoph Steiner a écrit : I think that the order of the [inlet]s and [outlet]s on the screen matching the order of the inlets and outlets on the abstraction that patch creates is a wonderful idea, which is the only thing that makes it impossible to just move chunks of patches around without wondering whether you might be changing semantics. So close to following a principle and so unable to apply it thoroughly. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
Le 2012-02-16 à 01:06:00, Rich E a écrit : I think it's something like a team developing on the same codebase; 2-3 people definitely gets the job done faster than 1, partly because it is easy to discuss your work (or in computing, synchronize). There are few parallels to be made from teamwork of developers, especially nowadays. The problems solved by computers are of a different nature than those solved by those who program them. Problems tend to separate in two wildly different parts : the part that the computer does ; and the part of figuring out what the computer should be doing. Often, the interactions between 2 people (or a few people) make a boost that is hard to have when working alone, because of the mental patterns involved, that often lead 2 people to catch more mistakes and do it more quickly than twice the speed of 1 person working alone. There is no such effect for parallelism within programmes. But 4, 10, or 60 people working on the same project, well that doesn't get you anything more than the first 3. At that point, you need to redesign into components (whether it's your project or code). Wait a minute, do you mean that the first 3 developers didn't design their programme into components in the first place ? What's a « component » here ? But also, projects are not all created equal, components aren't created equal, teams are not created equal, and developers are all different from each other. It's hard to find something general to say about projects in general (though it's easy to pretend to have found something). So, wild claims about 10 people not being better than 3 is some kind of fiction. I mean that although there are surely many cases in which it would be true, it largely depends on who you pick, in which kind of project, that has been structured in which way. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
Le 2012-02-13 à 21:15:00, Charles Henry a écrit : On 2/11/12, Mathieu Bouchard ma...@artengine.ca wrote: Depends on how you count it. You may also see it as a bunch of computers in which 0 computer can do task T in time N, but they can join together to form 1 (or more) computer(s) that can do task T in time N or less. In that sense, it's infinitely more powerful. This way of seeing it is much more important in realtime apps than in batch-compute-over-the-weekend apps. You just always lose on efficiency whenever you use several threads or multiple nodes. Do you understand what I say, or you just repeat what I was replying to ? If it's not going to be read, I may as well not write it. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpng12 fix for gridflow.pd_darwin
Le 2012-02-11 à 14:18:00, Hans-Christoph Steiner a écrit : I just downloaded gridflow-9.13-macosx104-i386.tar.gz and it was looking for libpng12 at @executable_path/../../lib/libpng.12.0.dylib. I don't know what happened... the current script gridflow/bin/build_osx_package uses install_name_tool -change $LIB $BUNDLED_PREFIX/$FILENAME where BUNDLED_PREFIX=/Library/Pd/gridflow/libs And I just looked at the same script in 9.13 and 9.12 tarballs and they do the same. I don't know what is @executable_path... nor how to set it, or not set it. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libpng12 fix for gridflow.pd_darwin
Le 2012-02-11 à 11:31:00, Hans-Christoph Steiner a écrit : I just tried loading gridflow 9.13 on Pd-extended 0.43 on Mac OS X 10.6.8, and it couldn't load because it was looking for libpng12.0.dylib inside of Pd-extended. The included dylibs are automatically included based on what the included objects are linked to, so they are not good to rely on, because they can change in a given version. GridFlow 9.13 binaries for OSX already comes with libpng12.dylib. GridFlow 9.13 source is slightly older, and doesn't include some fixes that I made when I built the binary package. I should really, really release the 9.14 source... So you can easily include libpng12.0.dylib in your gridflow package, here's how: It's been like that in SVN for no less than 12 months. I also vaguely remember trying to compile with libpng14 at first, but that must have been an older story... I don't remember what had gone wrong. It seems that either would work with GF (as long as libpng12 is recent enough), but the headers have to match the lib. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
Le 2012-01-26 à 14:45:00, Charles Henry a écrit : When talking about cluster computing, I had someone once ask: Is that a case where the whole is greater than the sum of its parts? It's less. Always less. Depends on how you count it. You may also see it as a bunch of computers in which 0 computer can do task T in time N, but they can join together to form 1 (or more) computer(s) that can do task T in time N or less. In that sense, it's infinitely more powerful. This way of seeing it is much more important in realtime apps than in batch-compute-over-the-weekend apps. It's like how one ninja turtle alone can't beat a certain evil monster, but with teamwork, they can. ;) __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
Le 2012-02-08 à 09:08:00, IOhannes m zmoelnig a écrit : another reason is, that with accessor-functions you can more easily stay binary compatible both backward and forward than with directly accessing the struct. Depends what you think can be changing in the future... sure you can do something like that with structs as well (typecast to different structs depending on the version of the Pd-host), but with accessors it comes for free (well, at least backwards compatibility) ok... then why not accessors, then. fine. Has anyone made a list of all (current) globals yet ? e.g. c++11 (c++? ever tried to compile Pd with a c++ compiler?) I did. I don't recall significant difficulties... it might have been i guess i was exaggerating the use of C++ reserved keywords as variable names and the like. C++ reserved keywords are easy to deal with. They're easy to search-and-replace, or #define away. Some other things are a bit more work, but that's quite tiny compared to most other cases of «translating» between very similar programming languages. In the eighties, people spent a LOT more time porting software from one version of Microsoft BASIC to another version of Microsoft BASIC that was incompatible simply because it was on a different computer brand. but the original suggestion sounded to me like: 'a solution for all our problems is to switch to new C++ features in a CC=g++ -fdo-what-i-want manner', and i wanted to object to that. Well, a good reason to «object» to that is simply that C++11 implementations are not ready for use, and even if they were, they'd be so new that they wouldn't be bundled with Ubuntu, Debian, Fink, MinGW nor XCode. Apart from the fact that this feature will not really cure the problem and will create new ones. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] broken msgs cause Tcl traces, how to debug it?
Le 2012-01-23 à 13:31:00, Hans-Christoph Steiner a écrit : The problem isn't related to sys_gui not enforcing full Tcl commands since the breaks don't happen along the lines of sys_gui command contents. I know that sys_gui doesn't enforce it, but that's not what I'm trying to say. I'm saying that it would be good if sys_gui could send extra data such as \0 terminators or size-of-upcoming command so that you don't need to run [info complete] at all in the tcl process. A TCP connection doesn't have actual breaks. This means that if you want breaks, you have to add them. Currently, the breaks have to be guessed by a combination of parsing and supposing that the OS's breaks will eventually match an end-of-statement before the RAM starts swapping or before the CPU goes quadratic. That's why I'm thinking about less implicit ways of ending statements. The only time I've seen a problem is when the commands are broken in the middle of a sys_gui post. And there are several ways to fix that, and I was speculating about one that we aren't usually thinking about, but that might save the effort of running [info complete] multiple times on the same data and any other kludges we have to combine it with so that [info complete] does the job, and other funny side-effects of an [info complete]-based strategy... the funny little detail is that when it breaks in the middle of a Tcl command, it is always exactly at the 48kb mark. exactly. This most probably has to do with the size of the buffers in the TCP lasagna of the Linux kernel or OSX kernel. Each OS has its own sizes, and in some of them, it's tunable, if you know how (either by playing with /proc or /sys, or by recompiling something with a modified config.h, if you're not lucky). A direct pipe (the pipe() command, no port number ; or a /tmp socket-file) has usually a different buffer size, iirc. In any case, you can't really rely on the buffer size being anything in particular, but the way it is now, it may affect Pd, especially in certain tough situations. Some OS setting I guess, or default, or whatnot. The -buffering on the sender side only controls when Tcl pushes data into the OS. It doesn't prevent the OS from packaging things as it likes Yeah, [fconfigure -buffering] is FOR OUTPUT ONLY. (If I said anything else, it's a mistake). However, [fconfigure -buffersize] controls the size of both the input and output buffers. An input buffer is always required for using [gets], but is not when using [read]. This is because it's extremely inefficient to look for a newline when the OS doesn't allow you to «unread» data. I'm talking about user-space buffers (the OS does the buffering it wants to have, but you don't have direct access to it). Hans-Christoph Steiner thommey: that seems doable, better than running [info complete] each time, I suppose Gotisch i guess i didnt know what i was talking about again The thing with the \\ is that it's not sufficient, because you also have to count the braces, and braces can be backslashed. (This corresponds to a mistake that I made in a previous mail.) __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] broken msgs cause Tcl traces, how to debug it?
Le 2012-01-23 à 14:00:00, Hans-Christoph Steiner a écrit :
if {[string index $cmd_from_pd end] eq \\} {
::pd_connect::pd_readsocket $cmd_from_pd
}
if {[catch {uplevel #0 $cmd_from_pd} errorname]} {
This is very wrong, because pd_readsocket calls itself recursively N
times, then doesn't return, which causes eval (uplevel) to be run N+1
times on the same chunk of statements.
This may cause «canvas create» to create very many duplicates of canvas
items, and such.
Is that right ?
__
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] broken msgs cause Tcl traces, how to debug it?
Le 2012-02-07 à 16:09:00, Hans-Christoph Steiner a écrit : This code has totally changed, I know, it was just in case you wanted to know. Your most recent mail didn't mention this bug (though it did say that you had removed the recursion). __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
Le 2012-01-14 à 13:04:00, Miller Puckette a écrit : The question I'd like to rais is this: would it suffice to make Pd instances be per-thread? This means I'd have to switch threads every time I want to send a message to pd. In my app, I have a main thread, and I have a pd-audio thread. The message-domain stuff currently runs in the main thread. I use either sys_lock or I switch to using a lock that's actually reentrant. This is easier than switching threads. Alternately, message-passing can happen using «mailboxes», but that's more complicated, and it means not being able to get an answer from pd right now, because it's async. Alternatively, one could use the C++11 standard thread_local keyword, although I believe that's not widely implemented yet. AFAIK, this standard in general is hardly supported at the moment, not just the thread_local keyword, and I'd rather have Pd's source start using C++83 features before it starts getting into C++11 land. To do this I'd replace all globals like static t_symbol *symhash[HASHSIZE]; with PDSTATIC t_symbol *symhash[HASHSIZE]; I'd rather have you put a separate lock inside gensym so that we don't have to call sys_lock and sys_unlock just for that. Then that hashtable can be shared between instances, in nearly all situations. Saves some RAM too. 1. external objects making explicit references to global storage (such as canvas_dspstate and cos-table in m_pd.h and much stuff in the more 'private' header files) would have to be recompiled to run per-thread. They'd still work fine with vanilla Pd. You don't need multiple copies of the cos-table, and you won't ever need. 4. supposing you use this to make a VST plug-in: what would happen if some stupid host app called all its VST plug-ins from the same thread? (I think it's normal for hosts always to make a new thread for every VST plug-in instance but I don't know if this is universal). Why is it normal to have one thread per plug-in ? As someone who doesn't know VST, this seems weird. Think of Pd as being a plugin interface of its own. Pd can schedule all of its plugins in the same thread and it's not a problem for working patches. It might be just some kind of infinite-loop-protection (a feature that Pd doesn't have). or some declspec horror in Miscoroft C. I don't know that name. Maybe you mean H.P.Lovecraft, which also ends with «ft». __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
Le 2012-01-14 à 22:16:00, Peter Brinkmann a écrit : * In many cases, the audio thread is beyond the control of the programmer. For instance, if you want one Pd instance per JACK client, or one Pd instance per audio unit in iOS, then you just register a callback, and you have no real idea which thread will ultimately invoke your callback. Even when you do have control over threading, as on Android, you have several reasons to want to split your app in several parts and have them communicate and that means either being able to call pd functions from any thread or inventing elaborate workarounds. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
Le 2012-01-16 à 09:43:00, IOhannes m zmoelnig a écrit : what is wrong with eliminating all directly accessible globals from the API (like pd_objectmaker) and provide accessor functions to get (thread safe) access to them? Or just structs. You'd have a t_pdglobal type containing all the global variables that should never be shared. And a separate section of the same struct could also list the global variables that could be shared, but might be not (e.g. if there's any reason to support both a single symtable and multiple symtables). afaik, the usual way to accomplish a concept of multiple instances is to aggragate all currently global variables into a context and extend the API so that each function has an additional parameter for this context. I mean that this context could be accessed directly if there's no reason to use accessors. But if locking has to be done before and after accessing (some of) those members, then it's nice to have a shortcut. this will obviously break API compatibility... a possible workaround would be to add a new function t_pdcontext*make_current(t_pdcontext*) that would change the running instance and all API calls would henceforth work on the current context. this would still need a global variable (the current context). the make_current call could update the legacy global variables to contain the current values. (this would only work as long as no code caches the values of these variables). how many of these variables are there ? That could be a lot of variables to be swapped around. e.g. c++11 (c++? ever tried to compile Pd with a c++ compiler?) I did. I don't recall significant difficulties... it might have been just the need to explicitly cast float to int, and something else involving void pointers... the job of making it compile with C++ wasn't a portion worth mentioning of the project I was working on (less than 1 %). It took less time than just getting rid of all of pd's unused variables just so that I could see my own mistakes easily. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
Le 2012-02-07 à 18:49:00, Mathieu Bouchard a écrit : Sharing gensym is useful so that one can prepare lists and messages without having to lock everytime. This can allow to run the audio thread on one processor while cooking up a big list on the other processor. Otherwise the non-audio thread will get blocked even though the audio thread never even looks at the symtable. ... and part of what I say also applies to single-instance multi-thread, such as this paragraph. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
Le 2012-01-19 à 10:11:00, IOhannes m zmoelnig a écrit : it seems like i was myself mixing instances and threading. indeed what i would prefer was, if i could use gensym() from another thread in a safe way. this has nothing to do with a global hashtable (and i don't see a reason why multiple instances should share a global hashtable) Now that I think of it, they can't. I momentarily forgot something obvious. This is because Pd's symtable is like an old LISP's symtable : the symtable isn't just a mapper of const char[] to t_symbol *, it's also giving you access to s_thing, which is the mechanism for naming [table], [value], [delwrite~], [receive], [send~], [catch~], and some more. In some other systems (Smalltalk, Ruby, etc), the symtable is just a set of permanent strings, and there are various vartables to hold the mappings of t_symbol * to t_pd * (I'm translating this in pd terminology). Nearly all languages have such a system because it allows them to avoid having to turn $0-myname into 1234-myname just to be able to read a puny local variable. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] broken msgs cause Tcl traces, how to debug it?
Le 2012-01-23 à 18:57:00, mescali...@gmail.com a écrit :
moreover, one should not trust [info complete] as an oracle knowing
exactly where a Tcl command ends and another begins. it just checks for
unbalanced brackets/quotes [1].
Right. But if only reading complete lines, then a trailing backslash is a
sign of an incomplete command. Apparently, [info complete \\] returns 1.
think about: .x8763 configure -text blah \n -command {blah…}
[info complete .x8763 configure -text blah] would return 1,
resulting in the evaluation of -command {blah…} as a separate
command.
But a \n wouldn't happen there, it would be a \\\n, I mean a single
backslash immediately followed by a newline, or else the whole thing would
be enclosed in more braces, brackets or quotes.
__
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
Le 2012-01-25 à 12:46:00, Peter Brinkmann a écrit : Threading is an implementation detail that users shouldn't have to worry about, If you sweep threading under the carpet, it makes the carpet turns into an evil mutant who will come back to eat you. I warned you. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] broken msgs cause Tcl traces, how to debug it?
Le 2012-01-22 à 21:54:00, Miller Puckette a écrit :
On Mon, Jan 23, 2012 at 12:45:09AM -0500, Mathieu Bouchard wrote:
That's called a newline... not preceded by a backslash. The thing
with fconfigure -buffering line is that it doesn't care about
backslashes, whereas eval does, and if you use both together, you
need to account for that difference.
Sorry, the problem is indeed more complex than just looking for
backslashes before newlines. It has to do with counting braces. The most
efficient way to do it would be a parser that keeps its own state so that
after returning from [info complete] you don't need to call it again from
scratch, but that does not exist in Tcl (it's possible that there's a Tcl
extension that you could compile for that, but I wouldn't know about it).
The way Pd is designed, sys_gui has never any obligation to contain a
whole statement, so there isn't much that you could do in sys_gui to help
the situation for all externals at once. If it were the case, you could
for example use nul-terminators ('\0' aka (char)0) to make the parsing
much easier on the receiving end.
However, if you make the assumption that any statement started within a
wb-function must be terminated in the same wb-function, then the caller of
the wb-function can call some kind of cleanup that adds a nul-terminator
iff number of bytes written by sys_gui = 0 (since last termination). Same
goes with t_guicallbackfn.
But there are a number of cases of sys_gui being called from elsewhere.
Considering end of t_clock run and end of t_pollfn run as being ends of
statement could help, as well as _setup function. Is there any other case
that wouldn't be covered by that ?
__
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] broken msgs cause Tcl traces, how to debug it?
Le 2012-01-22 à 21:16:00, Miller Puckette a écrit : Quick guess; the socket itself (at the OS level) has a fixed buffer size and if the sending process exceeds it it is suspended until the receiving process eats at least some of it. AFAIK, that's 4k or 8k for «unix» type (pipe or fs socket) and it might be 32k for TCP sockets. But code must not rely on specific buffer sizes. If you remove the [info complete] bracket from pd_readsocket, there are these intermittent Tcl stacktraces causes by messages from 'pd' to 'pd-gui' that get split in the wrong spot. yes, [info complete] is a potential major slowdown because it may reparse code many times while the amount of code increases. It's a n² time order thing. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] broken msgs cause Tcl traces, how to debug it?
Le 2012-01-22 à 21:16:00, Miller Puckette a écrit : There's not much way around this. One possibility (if indeed this is a serious efficiency issue) would be for Pd to append a done message to each batch up tcl to up-send. That's called a newline... not preceded by a backslash. The thing with fconfigure -buffering line is that it doesn't care about backslashes, whereas eval does, and if you use both together, you need to account for that difference. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] deadly leak
Le 2011-12-14 à 10:15:00, Ivica Ico Bukvic a écrit : So, the only way I can ensure in pd-l2ork that this never happens is that I enable global variable in canvas_new making sure that pd_new function is aware its next allocation is for a canvas. I also maintain a global single-linked list of previously allocated memory locations of canvases and check that the newly created canvas does not reuse old memory location. In DesireData, I had a concept called «zombies» that was quite similar to that. It would postpone deallocation of objects until it knew that the client (tcl/tk) would not confuse the dead object with the newer object. During that time, the object is destructed (the freemethod was called) but freebytes isn't called yet, and the class of the object is changed to ensure that every message received is reported as an error and doesn't crash. But it doesn't look like the duplicate messages are at all related to that kind of problem/solution. It looks like just a bug of forgetting to call pd_unbind in one place. Any such bug that also exists in pd-vanilla is unrelated to zombie-style solutions, as far as I can think of the problem. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] deadly leak
Le 2011-12-14 à 12:49:00, Ivica Ico Bukvic a écrit : So what part of the code specifically binds keyboard and mouse actions to a canvas? Look for the name as it appears in Tcl commands going to Pd. From what it looks like in commands to/from Tcl, you can see that it is a .x%lx format-string. You can find that this exact format string is used in editor_new (whereas all other cases use longer format strings intended directly for sys_vgui). This string is used as an argument to guiconnect_new, which calls pd_bind. Also, editor_free calls guiconnect_notarget which schedules guiconnect_free which calls pd_unbind. I thought this was never explicitly bound but is rather a result of tcl/tk simply reporting events within a specific canvas whose name was given to it by its memory allocation. Implicit binding is a DesireData-only feature, in which binbuf_eval handles a « no such object » error by reparsing the receive-symbol as a t_pd*, after checking that it exists (object_table-exists(target)) and that it's a non-zombie (object_table-get(target)). This allows for deleting the whole guiconnect business, including deleting the bug that we're talking about. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding standard install paths to the 'puredata' package
On Thu, 3 Dec 2009, Frank Barknecht wrote: Now that we have new players like maybe desiredata, they can and should use their custom directories if they need to, but this should not directly affect the old ones. Well, at some point 'vi' became 'vim' and that was reflected in the names of folders, but for desiredata I don't have much of a wish to keep things separate... the GUI externals will need a separate folder, but I don't see us separating the whole lot of externals just because of the 5% of them that need to be compiled differently. If ever I finish the API for deallocating symbols, though, it could be different, but this is all too hypothetical. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding standard install paths to the 'puredata' package
On Mon, 30 Nov 2009, Frank Barknecht wrote: Additionally, I'd like to Debianize the directory names (i.e. / usr/lib/puredata) What's un-Debian about /usr/lib/pd? the package name is not pd. alternatively, the package name could be changed, if there is no nameclash. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
On Fri, 27 Nov 2009, Hans-Christoph Steiner wrote:
FYI, it doesn't work on Mac OS X because it requires 8.5 and ttk, so this
couldn't be included in vanilla since Miller wants to continue to support
8.3, and it couldn't be included in Pd-extended until 0.43 since 0.42 doesn't
work on Mac OS X with 8.5
if {$::tk_version = 8.5} ?
_ _ __ ___ _ _ _ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)
On Fri, 27 Nov 2009, Ivica Ico Bukvic wrote: It appears the droid leaves me no choice here :-( the droids have won. humanity must surrender control. « I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. » -- Bjarne Stroustrup _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] updating 'puredata' package to 0.42.5
On Sat, 21 Nov 2009, Chris McCormick wrote: On Fri, Nov 20, 2009 at 01:24:18PM -0500, Mathieu Bouchard wrote: On Fri, 20 Nov 2009, Chris McCormick wrote: Maybe I am misunderstanding something, but if this is a question of being able to apt-get install vanilla Pd under Debian GNU/Linux, I would like to have that option rather than only having the option to install pd-extended. What's in pd-vanilla, that you can't have by installing pd-extended ? Your question is the wrong way around. I can't answer it like that because it contains built in assumptions which don't make sense to me. Ah, I see: you want questions that have a vanilla bias. I'm not sorry: I asked the question that I wanted to ask, the way I wanted to ask it. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] ATTENTION to all pd-list and pd-dev users!
If you have any mails that timed out after 1 or 2 days, you should re-send them, and now is the time! Note that it says Permanent failure in that case, and not Temporary failure (The latter of which means: it's still on auto-retry) Some mail servers auto-retry for only 1 day, some others auto-retry for 4 days. (I have no idea how many are one way or the other but I've seen both). When a mail is on auto-retry, it may take a few hours until the next retry. Some threads may be received in the wrong order, but fortunately, the Date: field still works, etc. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] bug when redrawing gop within gop inside a closed sub-patch
On Sat, 21 Nov 2009, Ivica Ico Bukvic wrote: /* I should have learned C++ */ Except that you would also arguably lose on efficiency, particularly when it comes to encapsulation that Pd is designed around... What are you talking about? If it's arguable, could you please argue about it, so that I can learn something new? In that case, though, which compilers are you talking about, and which elements of the language are you talking about? and that would go a long way towards improving legibility, e.g. all_present_objects.cords.visible. What would that piece of code mean? how would you use it? how would it fit with a C-Tcl/Tk architecture? can it be expressed as C code naturally enough? So is 40 hours used for a task that should've taken a fraction of that... «Should» ? If you have used those hours well, you have now 40 hours of experience with the Pd source code, and surely this reduces the time it takes you to find another bug in Pd, or another bug in any other C programme, or another bug in any other programme, even. Well, it would be nice if it took less time to write a programme, read a programme and debug a programme, but unless we really have a good list of time-savers that are demonstrably good, it's hard to claim how many hours it could have been, and even then, it heavily depends on one's experience and on one's reluctance. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] updating 'puredata' package to 0.42.5
On Sat, 21 Nov 2009, Chris McCormick wrote: I should note that Pd itself is not very modular in terms of the way it's distributed, it's just that there is not a lot of stuff in it. If (random popular interpreter) Python or Ruby or PHP were nearly as modular as Pd is, you'd need to download your for-loop statement from a third party, and then you'd have people arguing on the mailing-list that they should be able to run Ruby without a for-loop statement interpreter if they damn well please. Then you'd have at least five different representations for text strings, in which the only one considered standard is the one that is a big honking memory leak by design; and each of the non-leaking representations would be pushed for by a minority of specialists and rejected by a majority of them. THAT's modularity! I guess the difference is that when disk space is constrained I have the option to install or not install something with Python, whilst I don't really have that option with pd-extended. If you do an `apt-cache search python-` you will see a ton of stuff that you can optionally install. I think the Python VM and language strike the right balance with what hey choose to be 'batteries included' and what they leave out. Possibly pd-extended still needs to find that balance. Even though pd-extended is built as one set of things, there's nothing that prevents you from designing a scheme of .deb files that cuts that one set of binaries (made from a single make command) into a conveniently-compartmentalised system designed so that each package doesn't pull in too many other packages at once (recursively speaking). I don't know whether debian packaging really wants you to have one makefile per package, but if ever it's the case, you can probably fake it so as to avoid having to split a makefile-system that has an advantage at being all together. the package-splitting would be only there to avoid pulling too many deps at once, just to avoid apt-get install pd-extended telling you «the following 242 dependencies will be ADDED. Once installed it will take 3859 Megs. Do you want to continue? (Y/Y)». But seriously, so far, I don't recall being really annoyed by the number of deps in the pd-extended debs. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] bug when redrawing gop within gop inside a closed sub-patch
On Sat, 21 Nov 2009, Hans-Christoph Steiner wrote: On Nov 20, 2009, at 3:14 PM, Mathieu Bouchard wrote: Because objectboxes and messageboxes and atomboxes have become opaque, so the stacking order of wires does matter more. They have to stay on top in order to be more visible, yet the pd architecture is not sophisticated enough to allow pd to force all of its externals to draw all boxes _under_ the wires. Well, its easy enough to raise all wires. That's what Pd-extended does, but there are a couple bugs with that... Btw I don't mean that DD does anything in particular with it. It's just that with the sys_vgui() free-for-all, the Pd GUI itself has no knowledge of which canvasitems have been created last, and so it can't call the 'lower' method (of a tk canvas object) on those items. Using the DD API, it could be done using the same abstraction layer that is used for zoomability, but I don't think I have done anything about keeping boxes below wires. Given that, your raise all_cords is the best solution imho, as the Pd GUI has total control over wires, not boxes, therefore it's much easier to put wires over boxes than to put boxes below wires. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] updating 'puredata' package to 0.42.5
On Sat, 21 Nov 2009, Chris McCormick wrote: Ok, I'll answer your question as if you'd asked it like this: Why would you like the option of running pd-vanilla? Rather than the front-loaded question you asked me. What does «front-loaded» mean here?? 1. Pd is minimal whilst pd-extended is maximal. Hans has stated on list that he would like to include as many externals as possible in the distribution. I think this is a bad architectural decision which leads to complexity and bugs. I would rather run something which has an architecture I agree with. How to make pd-extended super stable: 1. download pd-extended 2. install pd-extended 3. delete .pdsettings 4. done that way you don't get any of the annoying externals. There are many things which Miller has not implemented which I wish he had, but there are far fewer things that he has implemented which I wish he hadn't. It's not that: there are possibly many features that one wish hadn't been implemented, but few of them really are impediments and even fewer are showstoppers or close to (i'm not talking about pd in particular). This may be outweiged down the track by evolutionary pressure, since pd-extended will be subjected to a lot more pressure than Pd will be, because Pd basically has a sole maintainer. You are confusing pressure and resistance. 4. I often want to run Pd on constrained devices and in constrained places. Getting it to do so is hard enough without the bloat that pd-extended experiences. What if I want to apt-get install Pd onto my router/gumstix/phone with an ARM based processor with 8MB of flash memory? What if I want to apt-get install Pd onto my toaster / microwave-oven / Apple IIc or BBC-Micro ? If you want that to happen, you may be a candidate for maintaining the «puredata» package in Debian! Of course, Free and Open Source Software is also about choice, Whose choice of what? You can choose to run the programme, choose to study how the programme works, choose to modify the programme to do whatever you want, choose to redistribute the programme, and choose to fork the project. What else do you want to choose about? and so it's always good to give users the choices they would like. There's nothing in the Free Software Definition that says anything like volunteers who happen to be served by users have to volunteer extra time to provide the users with the choices they like, for free. I shouldn't even have to justify my own preference for running pd-vanilla to you, Well, why are you replying to me? That's because you think it's worth it. beyond saying having pd-vanilla is a useful feature for me, and I would appreciate it if it was available to me as a choice. The issue is not whether you prefer pd-vanilla or whether you think pd-vanilla shall be the default in such a manner that all questions have to be biased in favour of pd-vanilla. The question is whether HCS would take on the job of maintaining the debian package for it. It works for me, is the worst kind of programmer mentality. What about the worst kinds of user mentality? (while we are at separating users and programmers again...) _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] bug when redrawing gop within gop inside a closed sub-patch
On Mon, 23 Nov 2009, Ivica Ico Bukvic wrote: This is IMHO the first valid argument against my suggested implementation you made so far and one I would agree with. This is because much of the rest was about peripheral issues such as what you think of pd itself, what can be done about pd itself, and about the wording you used against the current raise all_cords. If that's late for you, it's because your thread seemed to be about so much more than the bug in question. If you spend much of your mails talking about other issues, then this is what you can expect to get. It seems to me then that encapsulating raise all_cords call into a function and prepending it with your suggested check ought to solve most if not all of the problems associated with this bug. I didn't think about making it a function, but it wouldn't be a bad idea, given that it's currently done in two different places. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] bug when redrawing gop within gop inside a closed sub-patch
On Mon, 23 Nov 2009, Ivica Ico Bukvic wrote:
With what C++ provides for nesting structs, you can remove most
typecasts from Pd's code, including all the disguised typecasts (every
use of te_gobj, g_gobj, x_obj, x_gui, as well as many uses of g_pd).
Good idea. I'll try to give it a shot next time I mess with Pd source.
Ok, I'll give you an example to be sure:
typedef struct _text {
t_gobj te_g;
t_binbuf *te_binbuf;
t_outlet *te_outlet;
t_inlet *te_inlet;
short te_xpix, te_ypix, te_width;
unsigned int te_type:2;
} t_text;
can become:
typedef struct _text : struct t_gobj {
t_binbuf *te_binbuf;
t_outlet *te_outlet;
t_inlet *te_inlet;
short te_xpix, te_ypix, te_width;
unsigned int te_type:2;
} t_text;
so t_text (aka t_object) becomes a variant of t_gobj instead of just
containing a t_gobj. This means you never need to cast from t_text* to
t_gobj* anymore, and it means you never have to write te_g anymore, but it
means you can't write te_g anymore, and that's a little downside. However
it's normal that you still have to do explicit casts the other way around
because even though in this case a t_text is a t_gobj, it doesn't mean a
t_gobj is a t_text.
I use #ifdef to switch between the C and C++ versions of
these structs, in binary-compatible ways.
I'm sorry for the repeated typo of writing te_gobj instead of te_g.
_ _ __ ___ _ _ _ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] bug when redrawing gop within gop inside a closed sub-patch
On Mon, 23 Nov 2009, Ivica Ico Bukvic wrote: You need to cycle through cords of a visible canvas b/c even though a canvas is open they may not be placed in a visible part of that canvas. The bug is happening because a given pd canvas doesn't have a corresponding tk canvas. This happens when the canvas is said to be «closed». When a window is minimised, it's just useless to send the «raise» command, but it doesn't cause an error message. In the case of GOP, the canvas' contents is visible, but the associated tk canvas does not an id matching the pointer of the pd canvas. Of course lingering question is what is in the end faster in tcl/tk land: cycling through objects and refreshing them (which would be the cleaner thing to do) Why would it be the cleaner thing to do? It's not like simpler, smaller commands are full of doorknob viruses. Tk has the commands on groups of items so that it acts on groups of items, I don't know why we're supposed to avoid that feature and call it cleaner. or simply refreshing entire canvas and trusting that tcl/tk is implemented so efficiently that its execution offsets time required for redundant redraws. What about trusting that tcl/tk is implemented so efficiently that when you are picking each element in the manner that they are sorted already, and raising each of them separately to the top (thus changing the order of N cords N times in a row), tcl/tk would figure out that it has nothing to redraw?... I wouldn't even be sure that *any* toolkit would figure out that situation. Whereas for raise all_cords, tcl/tk guarantees it preserves the relative order of members of all_cords, so it is possible and likely that it will figure out that nothing has changed (but not certain). tcl/tk is notoriously inefficient but it's also very easy to make wrong guesses as to what will be done redundantly and what won't. If you are interested in accelerating your code Tk-wise, I could show you what I found about Tk's redrawing when I tried to modify tk/generic/tkCanvas.c. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] updating 'puredata' package to 0.42.5
On Sat, 21 Nov 2009, Hans-Christoph Steiner wrote: Funny, I never wanted to be a leader of this, I'd much prefer it if more people were involved in the work and the decision making. And thankfully, I'm not the only one who works on it. Others have contributed a lot as well. A hero is a kind of self-designated victim. Everybody waits for everybody else to do something, and then one of them gets annoyed by the situation and does something. From that moment on, everybody expects the one who has already given, to give again. I don't think everyone should use Pd-extended, or whatever. Its kind of ironic maybe that this thread started with me talking about doing pd-vanilla maintenance :). It's not ironic, not kind of and not maybe. We're talking about pd vanilla packaging, and chiefly two branches have ever been packaged, vanilla and extended, and then suddenly talking about extended would be ironic? What's wouldn't be ironic then? _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] updating 'puredata' package to 0.42.5
On Fri, 20 Nov 2009, Chris McCormick wrote: Maybe I am misunderstanding something, but if this is a question of being able to apt-get install vanilla Pd under Debian GNU/Linux, I would like to have that option rather than only having the option to install pd-extended. What's in pd-vanilla, that you can't have by installing pd-extended ? _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] bug when redrawing gop within gop inside a closed sub-patch
On Thu, 19 Nov 2009, Ivica Ico Bukvic wrote: So, if anyone is aware of the reason for its placement, it would be most helpful to learn more about that before making the final decision whether to keep/remove it. Because objectboxes and messageboxes and atomboxes have become opaque, so the stacking order of wires does matter more. They have to stay on top in order to be more visible, yet the pd architecture is not sophisticated enough to allow pd to force all of its externals to draw all boxes _under_ the wires. What things like x-x_obj.te_gobj.g_pd (to use your example) mean (e.g. struct structure and function of g_pd vs. te_gobj vs. x_obj etc.) You can look those up in m_pd.h. What kind of comment are you looking for? Where would they be placed? Suppose you are reading one function in particular. Where would be the comment that refers to the meaning of x-x_obj.te_gobj.g_pd ? In any case, the deepest meaning of x-x_obj.te_gobj.g_pd as it could be documented is: /* I should have learned C++ */ Unless I am mistaken (and please do correct me if I am wrong) this call is for both mapping and unmapping, yet the description suggests it is about mapping only. send your comments to Miller and see whether he cares. All that said, I may have very well missed something, so if there is a good resource that shows the code tree and basic API information, that would be certainly very helpful and most appreciated. Martin Peach wrote the most complete doc of the internals, but I don't recall whether it covers that or not. If it makes it more legible without breaking the code, I am all for it. Ok. Well, I did something like that in my branch, but that requires C++ and defining CPLUSPLUS_FACE before including m_pd.h. I would love to contribute more, but time is a precious commodity we are all short on. So, for the sake of making contributions easier, IMHO I think it would be a great idea to overhaul the code to the point where it is possible to make such contributions much more efficiently. I am hoping that this is what Hans is trying to do with the gui rewrite. Why hope?... Rewrite is just another name for not rewriting, GUI is just another name for less than half of the GUI, and hope is all too often a disease that makes one stand still. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] updating 'puredata' package to 0.42.5
On Thu, 19 Nov 2009, Hans-Christoph Steiner wrote: It seems that Günter is no longer updating the 'puredata' package, so I wanted to start the process of updating it. I am working on becoming a Debian Maintainer, so I can get direct upload access. This is what I would like to address: - improved puredata.desktop for file associations, etc. - built against Tcl/Tk 8.5 We don't need the «puredata» package, because we have the «pd-extended» package, and that's enough for essentially everybody. Why would you do it? _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] namespaces for send/receive
On Wed, 18 Nov 2009, Frank Barknecht wrote: If you use the route-approach, you can use settable routes (as an abstraction like sroute.pd in [list]-abs). But actually I have no idea why a settable receive should be necessary anyway? :) One example is the GFDP (GridFlow Documentation Project), which uses settable receives because it uses receive-symbols that are local to the toplevel patch they are in (an intermediate between global and the ordinary local). This value has to be output by an object, so it cannot appear directly in an [r] box, and the GFDP doesn't use that much dynamic patching... _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] auto-starting loaders
On Mon, 16 Nov 2009, Hans-Christoph Steiner wrote: It would be super userful to have an easy way to make the various loaders auto-load (Lua, Tcl, libdir, etc). I think it would be even more userful to have hexloader work for abstractions. I was thinking we could do the same with with loaders. So *-loader.pd_linux (or maybe *-loader.so) anywhere in the Pd path would be loaded at startup. You just have to put every loader in the -lib section of your pdsettings or pdrc. That's all. I'd really like to see more people using the pdlua, tclpd, Yeah, one thing that always annoyed me was that although it's extremely nice to have this support for a bunch of extra languages, there's scarcely anything significant that has been released for pd, that uses those languages. I mean, there are not many of those language libs that appear to have any more users than the author himself. It may be a sign of how those libs are used though: I suppose that they are more often used for project-specific code than otherwise. But generally, I think that they are underused. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] why not?
class_setpropertiesfn(text_class,(t_propertiesfn)0xDECAFFED); unsigned long *lol = (unsigned long *)text_class; int i=0; while (lol[i]!=0xDECAFFED) i++; *((char *)(lol+i+1) + 6) = 1; class_setpropertiesfn(text_class,0); _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] Max?
--- trunk/pd/doc/1.manual/1.introduction.txt2006/08/15 16:09:57 5609 +++ trunk/pd/doc/1.manual/1.introduction.txt2009/10/23 18:43:20 12653 @@ -2,7 +2,7 @@ A real-time graphical programming environment for live interactive computer music, Pd works on SGI machines, Microsoft Windows, -Linux, and Max OSX. +Linux, and Mac OSX. Pd is copyrighted, but is free for you to use for any reasonable purpose. See the file: ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Max?
On Fri, 23 Oct 2009, Mathieu Bouchard wrote: --- trunk/pd/doc/1.manual/1.introduction.txt2006/08/15 16:09:57 5609 +++ trunk/pd/doc/1.manual/1.introduction.txt2009/10/23 18:43:20 12653 @@ -2,7 +2,7 @@ A real-time graphical programming environment for live interactive computer music, Pd works on SGI machines, Microsoft Windows, -Linux, and Max OSX. +Linux, and Mac OSX. See also: http://lists.puredata.info/pipermail/pd-cvs/2003-11/000190.html http://lists.puredata.info/pipermail/pd-dev/2005-05/003993.html Here's the other one: --8cut-here8-- --- makefile.in (revision 12654) +++ makefile.in (working copy) @@ -118,7 +118,7 @@ $(PDEXEC): $(OBJ) $(BIN_DIR) cd ../obj; $(CC) $(LDFLAGS) $(DBG_CFLAGS) -o $(PDEXEC) $(OBJ) $(LIB) -#this is for Max OSX only... +#this is for Mac OSX only... $(BIN_DIR)/libPdTcl.dylib: $(GOBJ) $(GSRC) cd ../obj $(CC) $(CFLAGS) -dynamiclib -read_only_relocs warning \ -o $(BIN_DIR)/libPdTcl.dylib $(GOBJ) \ --8cut-here8-- _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] ATI + GridFlow + Gem + C++ + Linux = BOOM
On Thu, 15 Oct 2009, IOhannes m zmoelnig wrote: Mathieu Bouchard wrote: Thanks for doing this. I just tried it with Pd-0.42.5-extended-20091014-ubuntu-jaunty-i386.deb. cool (i guess you not only meant to say that you tried it, but also that the try was successfull) Oh. Yes. But I didn't try it with the fglrx libGL. (see below) It may still fail if any other extern (3DP, OSG, ...) ever links with libGL before libstdc++, while being loaded before GEM or instead of GEM. yes. as a matter of fact, the ATI-drivers should be fixed. In the end, it's not really an ATI-driver bug, because: 1. i discovered the bug on my computer that has a non-ATI graphics card, and couldn't get rid of the bug afterwards. I don't know what I did. the Xorg driver is called intel, not fglrx. I won't reinstall the OS to see whether I still have the bug that way. The crash is still related to loading libGL in particular in that case. 2. the root cause of the bug is always an incompatibility between different versions of gcc. there is no actual bug in the ATI source. there's nothing really wrong with ATI's source and makefiles. it's a GCC bug that propagated in ATI's binaries. Because I have the bug on my computer too, it also propagated into other binaries, it seems. But really, back then, it wasn't a bug yet, because the problem is one of forward-compatibility: the exception-system startup code of gcc 3.x has to support gcc 4.x, but doesn't, because of a change in gcc starting with 4.x... that's the info i could get from researching on my computer, web/google, and asking some people on IRC, and then putting everything together. but i'm not Sherlock Holmes, so it's not elementary to me, and i'm not sure i got everything right. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] ATI + GridFlow + Gem + C++ + Linux = BOOM
On Thu, 15 Oct 2009, IOhannes m zmoelnig wrote: i still believe that this is something that is not to be fixed with hacks, e.g. random linkeage against stdc++. instead it should be fixed somewhere upstream, be it gcc, binary drivers or whatever; btw. who is writing drivers in C++? (C++-externals like Gem don't do random linking against stdc++ since they require it anyhow) I don't know what it is that you call «random linkage». either you say -lstdc++ and it sets the order of -lstdc++ in the linkage list, or else you don't say it but it appears anyway as -lstdc++ implicitly because you used g++ as the compiler name instead of gcc. I can tell you that doing ldd on every version of Gem.pd_linux on my computer, new or old, says it is linked to libstdc++. It is definitely not your usual linkage problem and it evaded several times my logical reasoning about it, because I was making usual suppositions. But the problem is not one of symbol resolution, it's about the initialisation order of a global singleton, where only one version of the initialiser gets run... Yes, it is ultimately GCC's fault, but they won't fix it because they can't fix it because it's just too late and they can't do anything about it now that wouldn't make the problem more complicated, and then they wouldn't be able to propagate the fix because the problem has been bundled with a zillion linux distros before anyone realised that it was gonna be a problem (?). I know you are referring to the usual idea that something called a driver wouldn't be written in C++, but not only those driver-writers don't care about all the tradition and peer-pressure against writing drivers in C++, but also, those drivers have nothing to do with the Linux kernel, so it's pretty much outside of that culture. Afaik those video drivers are made of one-half XFree-format drivers, and one-half ELF-SO format drivers, so, it's 100% userspace. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] ATI + GridFlow + Gem + C++ + Linux = BOOM
On Thu, 15 Oct 2009, IOhannes m zmoelnig wrote: sorry for the confusion. with random linkeage i was referring to e.g. Pd-extended or 3dp linking with -lstdc++. these are pure C (any 3dpers forgive me, if 3dp is actually written in C++; i assume it is not), and should, imho, not link against stdc++. Well, all those shouldnots are somehow supposing that anything else that shouldn't happen is not happening. So in the end we get stuck with everybody else problems AND a long list of all the solutions we shouldn't use. So in the end, we end up having to tell the users to not move Gem away from the top of pdsettings/pdrc lest they pay the price for it, when there are more global solutions for it that could fix the problem forever. I wouldn't really advocate that 3DP or whatever else would link to -lstdc++ because then it doesn't fix the problem that people just can't reorder their pdsettings/pdrc lines as they please. So I'd rather link pd itself with libstdc++, and although it doesn't make any sense when trying to follow all rules, it does make perfect sense when you consider that to compensate from rules that have been broken you may as well break more rules. The problem is with a variable that is global to the whole pd process anyway, so with a certain logic, pd itself is the right place to fix the problem. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pd-extended broken link
sudo dpkg --install Pd-0.42.5-extended-20091014-ubuntu-jaunty-i386.deb installed /usr/lib/pd/doc/1.manual as a broken link to ../../../share/doc/puredata/1.manual aka /usr/share/doc/puredata/1.manual because /usr/share/doc/puredata doesn't exist. But all that dpkg ever said about it was: Selecting previously deselected package pd-extended. (Reading database ... 331523 files and directories currently installed.) Unpacking pd-extended (from Pd-0.42.5-extended-20091014-ubuntu-jaunty-i386.deb) ... Setting up pd-extended (0.42.5~cvs20091014-1) ... Processing triggers for man-db ... Processing triggers for shared-mime-info ... Unknown media type in type 'all/all' Unknown media type in type 'all/allfiles' Unknown media type in type 'uri/mms' Unknown media type in type 'uri/mmst' Unknown media type in type 'uri/mmsu' Unknown media type in type 'uri/pnm' Unknown media type in type 'uri/rtspt' Unknown media type in type 'uri/rtspu' Unknown media type in type 'fonts/package' Unknown media type in type 'interface/x-winamp-skin' _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] ATI + GridFlow + Gem + C++ + Linux = BOOM
On Sun, 23 Aug 2009, Hans-Christoph Steiner wrote: From my perspective, adding -lstdc++ has more problems than just making a simple libstdc++.pd_linux and loading that. For example, the Debian package will then require libstdc++. Requiring libstdc++ isn't what I call a «problem». If you mean the Pd-extended package that includes Gem... it already requires libstdc++ since a long time. I can't find an old Pd-extended debfile on my computer that doesn't list libstdc++ as a dependency. maintaining it. Someone else would have to step up on that front. The libstdc++.pd_linux could easily be included with Gridflow. Or using the libdir format like Gem perhaps, where it loads a shared library first as part of the process of loading the lib. Actually, I can't get the linking problem solved just by messing around with the GridFlow linkage. I can't seem to fix the problem by linking anything statically. It seems to be about whatever libstdc++ is started first, no matter whether it's linked statically inside a certain libGL, or linked dynamically from anywhere on the system. It boots the try/catch system used by the whole process, and then a throw compiled with a new gcc doesn't work with an old try/catch system, no matter how old is the compiler that compiled the try/catch commands. This is as far as I could guess what's going on. The bug may come back in the future, but if you always load libdir and Gem at the beginning of the loadlib list, then it will not come back (or else, it would be a different bug, certainly!). _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PdGuiRewriteTestBuilds
On Wed, 30 Sep 2009, Hans-Christoph Steiner wrote: Sometimes computers really suck Tsk. Let's not shift the blame away from the programmes. When it _is_ the programmes' fault, that is. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how to tell when a patch is finished loading
On Fri, 11 Sep 2009, Hans-Christoph Steiner wrote: On Sep 11, 2009, at 11:34 AM, Mathieu Bouchard wrote: Please try not to duck-tape yourself in a corner. Indeed. I am interested in establishing an API. aah, good! That's the ::loaded array. I find it a strange turn-around of our traditional opposition when I'm going to suggest that you could be using a longer name, but that's what it is. ::loaded doesn't say what kind of things are the loaded things in question, and sometimes it's good to imply the nouns, but only when the noun is super-obvious from context, or very vague (e.g. getStuff, getThing and getElement may as well be called just get). How it gets setup can then be easily changed without affecting things that use ::loaded. Some people would advise against using the 'trace' feature, saying it's ugly, but you don't have to listen to them. i'm not against it, and there's no reason not to use it apart from programmers who don't want to learn it or have other religious reasons against it (if it's not in JAVA it must be because it's evil, etc). The 'trace' feature can cause tremendous slowdowns, but only when you ask it to make tremendous effort. Tracing seldom-used vars doesn't cost much runtime. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how to tell when a patch is finished loading
On Fri, 11 Sep 2009, Hans-Christoph Steiner wrote: Well, I found a little hack way to do it. It turns out that 'pd' sends this proc when its done loading: pdtk_canvas_getscroll .x64b920.c Please try not to duck-tape yourself in a corner. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how to tell when a patch is finished loading
On Tue, 1 Sep 2009, Hans-Christoph Steiner wrote: just ping the client... depends a bit on the branch... miller: sys_gui(pd %s done \\;\n,rcv-s_name); hans: sys_gui(pdsend \%s done\\n,rcv-s_name); matju: sys_gui(netsend \%s done\\n,rcv-name); provided that you have done pd_bind((t_pd *)self,rcv); and a class_addmethod for the name done (the callback). Are there any existing methods? I stated it, therefore it exists. I suppose it depends on your school of ontology. I am actually thinking Tcl/GUI side. You can't get out of this question without thinking with both sides. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] cut/copy/paste from text in canvas (i.e. obj, msg, comment, etc)
On Tue, 1 Sep 2009, Hans-Christoph Steiner wrote: I was wondering if there was any reason why doing a copy when editing text needs to be sent to 'pd' at all. Just a tk_textCopy should do it, no need to send a message to 'pd' to have it reply to tell Tcl to do something. There is also tk_textCut and tk_textPaste which could be used, but they would then have to send a message to 'pd' to announce the change. Why look for reasons when you can just nuke the offending code. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] cut/copy/paste from text in canvas (i.e. obj, msg, comment, etc)
On Tue, 1 Sep 2009, Hans-Christoph Steiner wrote: On Sep 1, 2009, at 5:03 PM, Mathieu Bouchard wrote: Why look for reasons when you can just nuke the offending code. Sometimes there were good reasons to do strange things in the code. Yeah, I know that. Happens often, even. Also, sometimes there are dependencies... Ah. A few people use those commands in dynamic patching. But that's definitely not why it was implemented. I think it's more about Miller not wanting to learn enough of Tk... nevermind that Tcl/Tk was definitely the easiest GUI toolkit ever, at the time Miller started using it (and still competes favourably, but toolkits' ease of use change a lot with the programming language). _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Malloc Error occuring with PD 0.41.4
On Fri, 28 Aug 2009, james murray wrote: It steadily creeps up in memory used until I have approx 140 mb of free memory on the computer. And although I noticed that it occasionally flashed all the way down to only 6 - 9 MB of free memory at some points for a flickering moment, when it finally crashed it was listing free memory at around 133 mb. It took almost two hours for this to occur. This is a kind of bug called a Memory Leak. Look for those words, to find a tool that can look for those bugs. I don't know about OSX. I'd use Valgrind but I'm on Linux. The direct cause of the crash looks definitely like a mishandling of an Out-of-Memory situation, but everybody would agree that the solution to that is to fix the leak and not to improve the Out-of-Memory handler... When I didn't have Valgrind, I used to measure the memory usage over a long time, use it to figure out how much memory was lost per video frame, and use that information as a hint. But the hint can only be used by someone who has had a good overview of the program's code. It should also be noted that the amount lost will be a little bigger than the size of the offending allocation, as malloc needs some space for its own administration... (typically 4-16 bytes more per malloc call) _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] ATI + GridFlow + Gem + C++ + Linux = BOOM
Hi Hans, Could we please get Pd-extended to link the pd executable to libstdc++.so ? Afaik, this is a fix for a possibly wide category of problems but that is currently only known to affect GridFlow when loading GEM while the driver named fglrx is in use (ATI video). AFAIK, this problem affects any lib that uses the throw keyword in C++ code, whenever the ATI driver is loaded _before_ the standard library of C++, in which case it will provide its own version of a portion of the C++ standard library, which is incompatible (sort of like the DLL Hell on Windows). This driver is typically loaded by anything linked to OpenGL directly or indirectly (usually GEM, but could also be 3DP, OpenSceneGraph, etc) So, what I'm asking, is to link Pd itself to a library that it doesn't need, in order to force the bug out, so that this problem doesn't have to be addressed anywhere else. I believe that it is far easier to prevent this bug from the Pd executable than to make any kind of elaborate circus with the loading-order of pdsettings and pdrc and a little dummy .pd_linux (which has -lstdc++ without using it, and has an empty _setup). If you want, you can think of it as the first step for putting GridFlow in pd-extended. diff from Claude: --8cut-here8-- --- pd-0.41-4/src/makefile.in.orig 2008-03-15 00:03:00.0 + +++ pd-0.41-4/src/makefile.in 2009-08-23 18:55:35.0 +0100 -121,7 +121,7 @@ $(CC) $(CFLAGS) $(STRIPFLAG) -o $(BIN_DIR)/pdreceive u_pdreceive.c $(PDEXEC): $(OBJ) $(BIN_DIR) - cd ../obj; $(CC) $(LDFLAGS) $(DBG_CFLAGS) -o $(PDEXEC) $(OBJ) $(LIB) + cd ../obj; $(CC) $(LDFLAGS) $(DBG_CFLAGS) -o $(PDEXEC) $(OBJ) $(LIB) -lstdc++ $(BIN_DIR)/pd-gui: $(GOBJ) $(GSRC) cd ../obj; $(CC) $(INCLUDE) -o $(BIN_DIR)/$(GUINAME) $(GOBJ) $(GLIB) --8cut-here8-- _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] pd-toolkit first Release
On Wed, 19 Aug 2009, Hans-Christoph Steiner wrote: kbd_ctrl isn't the most memorable name, at least for my leaky mind. I am guessing kbd means keyboard? Maybe key_ctrl? Then it means both keyboard and 'key' as in important, like: the key object in my editing toolkit is key_ctrl. Then wouldn't kbd be better as it can't be confused with the other meaning of key that you are talking about ? :) kbd as an abbreviation is very common. The naming of the KBD tag in HTML is confusing though (something to do with typewriters). In almost all other cases, KBD is short for keyboard. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] file naming: pd.tcl, pd-gui.tcl, ?
On Tue, 18 Aug 2009, Hans-Christoph Steiner wrote: So I just changed the main Tcl file to 'pd-gui.tcl' following the old GUI binary name 'pd-gui'. In merging the code, Miller choose 'pd.tcl'. I don't have a strong preference either way, I'm fine just using 'pd.tcl'. I think others expressed some opinions, so I just wanted to see if anyone wanted to argue either way. no. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tooltips idea
On Mon, 17 Aug 2009, Chris McCormick wrote: On Sun, Aug 16, 2009 at 10:58:12PM -0400, Hans-Christoph Steiner wrote: Do you have a record of the original objection? I am just operating on memory. http://sourceforge.net/tracker/?func=detailaid=1056914group_id=55736atid=478072 Thanks. There is also the word tooltip somewhere in: http://artengine.ca/matju/pd-dev/dataflow-20050318-meeting.irc but that's only in some talk about the resampling feature of [inlet~]/[outlet~]. This is the only irc meeting log I have that talks about it, and afaict, msp only ever joined #dataflow for those meetings, so all he ever said on irc back then should be there. The logs of the last meetings aren't there, because i didn't organise them. (actually i had promised to put one of those logs on the web anyway, but someone else did it before i did). Almost all of the rest of the logs of what he said about pd should be in the pd-list and pd-dev mailing-list archives; however there are some other recordings that I don't have, much of them as audio, from pd conventions, etc., and also some discussions for which there is no recordings, also from the conventions. It's getting hard to put all of that data together and synthesise it. i used to store a lot of the relevant info in my head, but when i realised how little i ought to care about what msp says, compared to how much i did, i started forgetting. that's a good thing. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tooltips idea
On Sun, 16 Aug 2009, Hans-Christoph Steiner wrote: On Aug 16, 2009, at 10:46 PM, Mathieu Bouchard wrote: On Sun, 16 Aug 2009, Hans-Christoph Steiner wrote: So there has been a revived discussion of adding tooltip support to inlets/outlets, based on Günter's old patch. I think we should open up the discussion again to see if we can come up with a solution that Miller would accept. I believe his original objection was based on the fact that the patch added a record to the t_class struct. So I was thinking that instead of storing the tooltip data in t_class, it could be stored using a custom struct like t_inletdescription that was then added to object's class. so the new objection will be based on the fact that the patch added a record to the t_class struct?... i mean, this struct doesn't make any difference with the original objection. Do you have a record of the original objection? I am just operating on memory. When I said original objection, I meant the one you stated above, which may or may not be the same that msp actually said. I mean that if you add a t_symbol * in the t_class or if you add a t_inletdescription in the t_class or if you add a t_inletdescription * in the t_class, it's three times the same thing, which is to add a field in the t_class, which is what msp objected to, therefore your t_inletdescription proposal is not addressing msp's objection. I had this idea that the tooltips could be added as a function pointer to the class, such that the tooltip value could change according to the object and even according to the moment, instead of being stuck at one value per class; but this idea also doesn't address msp's objection. I say that because you said that makes sense since every instance should need the same data and perhaps my first reply about it didn't make you think about what else it could be. A big problem with the tooltips, is that t_inlets aren't made into classes the same way the t_objects are: most of the time, for a class of t_object, there are no custom t_inlet classes, and instead one of the four basic t_inlet classes are used. It makes the tooltip information shared for the first inlet and non-shared for the rest. this is an irregularity that has to be addressed somehow... _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tooltips idea
On Mon, 17 Aug 2009, Hans-Christoph Steiner wrote: On Aug 17, 2009, at 4:33 PM, Mathieu Bouchard wrote: A big problem with the tooltips, is that t_inlets aren't made into classes the same way the t_objects are: most of the time, for a class of t_object, there are no custom t_inlet classes, and instead one of the four basic t_inlet classes are used. It makes the tooltip information shared for the first inlet and non-shared for the rest. this is an irregularity that has to be addressed somehow... Ok, I miss remembered. It seems the original implementation attached the text to the t_inlet, and t_class was suggested as the preferred struct for that info. It looks like Chris switched the implementation to use t_class. If you read what I wrote at first, you'd realise that the original implementation didn't use only t_inlet, and that Chris didn't change that. I started a dev wiki page to keep track of the info, please expand on this. I already expanded on it on the pd-dev mailing-list today. Perhaps it will be read by someone someday... Frankly, if you don't read it on pd-dev, you won't read it on your wiki either. Like was mentioned at PdCon, this could be something like a Python PEP, or feature proposal. If the PEP thing was only mentioned at PdCon, then it's not gonna happen. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tooltips idea
On Mon, 17 Aug 2009, Mathieu Bouchard wrote: If you read what I wrote at first, you'd realise that the original implementation didn't use only t_inlet, and that Chris didn't change that. I mean I said that the original implementation used both t_class and t_inlet together (it's because of first inlet vs nonfirst inlet). I didn't talk about Chris' changes nor any other changes; but I say it now: nobody ever changed that aspect of the tooltips. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] getting rid of #/$ and sharptodollar()
On Mon, 17 Aug 2009, Hans-Christoph Steiner wrote: I'm hacking away on the array panel and generalized the panel stuff in the pd-gui and I ran into the sharptodollar() and mofo stuff in pdtk_array. It seems there has got to be a better way to do this, like properly escaping the $ on the Tcl side so Pd handles it properly. Can anyone think of a reason not to try this? Since I started talking about this ~5 years ago, two things changed: 1. in 2007.08.25, dd eliminated all of it and made it brace-proof, space-proof, backslash-proof, etc. 2. in 0.40, pd aggravated the situation by starting to support $1$2 as a dollsym everywhere except iemgui, where it blows up: error: #1$2: argument number out of range _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pure Data/gridflow/running flow_objects.c
On Wed, 5 Aug 2009, sisil mehta wrote: http://gridflow.ca/gallery/multiblob.png(the multiblob patch ) do i have to write the program for it? so is it available somewhere? Sisil. I'm finally adding examples/multiblob.pd based on the screenshot of occupants-video.pd found in that screenshot. However I cut out the mask made by [# ] for columns 312-319, because this was specifically for a camera that had a lot of noise in those columns. I'm also merging in some parts that were never seen, from later versions of the patch (after the screenshot that you know). One of the new features is the rotation of the crosses. I'm also cutting off some useless things from that patch, and I don't just mean the parts marked as unused, I mean object combinations that were detours that existed only because of the way I made the patch in the first place. Eventually, I might replace the thresholder by a complete colour detector. new screenshot at http://gridflow.ca/gallery/multiblob2.png new patch is at http://gridflow.ca/svn/trunk/examples/multiblob.pd (just use svn update) I made some changes after making the screenshot: crosses aren't square anymore (change in #make_cross.pd) and the selected areas are now dotted white with some kind of 1/6 stipple. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] puredata/gridflow/webcam driver=which are supported?
On Thu, 6 Aug 2009, sisil mehta wrote: with gridflow which webcam drivers are supported? i found that pwc and qc-usb are. i wanted to know whether uvc driver would be supported by gridflow.? [#in videodev] supports the V4L1 camera drivers that use one of the following formats: YUV420P, RGB32, RGB24, RGB565, and... that's all for now. [#in dc1394] supports black-and-white only. (I had a colour cam for a day but couldn't find how to make it work) [#in quicktimecamera] supports the Apple QuickTime driver interface. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pure Data/gridflow/running flow_objects.c
On Mon, 17 Aug 2009, sisil mehta wrote: @mathieu, Thanks a lot man...u just saved my internshipowe you one. BTW, take a white wall, shine a bright light all over it diagonally, and not on anything else. walk in front of the wall. you will appear relatively quite dark to the camera. then use [# ] instead of [# ] to select dark spots instead of bright ones. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tooltips idea
On Sun, 16 Aug 2009, Hans-Christoph Steiner wrote: So there has been a revived discussion of adding tooltip support to inlets/outlets, based on Günter's old patch. I think we should open up the discussion again to see if we can come up with a solution that Miller would accept. I believe his original objection was based on the fact that the patch added a record to the t_class struct. So I was thinking that instead of storing the tooltip data in t_class, it could be stored using a custom struct like t_inletdescription that was then added to object's class. so the new objection will be based on the fact that the patch added a record to the t_class struct?... i mean, this struct doesn't make any difference with the original objection. I guess the advantage of putting it into t_class is that there would only be one copy of it. Indeed. That makes sense since every instance should need the same data. Why does this make sense? I mean, how can you actually tell that every instance should need the same data? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] gridflow: logitech e2500 working in ekiga but not with gridflow?!!!(i used libv4l)
On Fri, 7 Aug 2009, sisil mehta wrote: [ 6389.806394] pd[31100]: segfault at 4 ip b74d95dc sp bf987c90 error 6 in libstdc++.so.6.0.10[b742+e4000] [ 6545.228881] pd[31220]: segfault at 461 ip b70d22eb sp bfa37830 error 4 in gridflow.pd_linux[b7058000+30b000] This is probably related to the ATI driver conflict we just talked about, unfortunately. The quick fix is to make sure Gem is not loaded (nor any other OpenGL thing), but when you actually need Gem to be loaded, it's a bit complicated. What the conflict does, is turn every error message of GridFlow into a crash. Therefore if you fix this, then you will see GridFlow's error messages correctly and will see what's wrong. (You can actually see those messages using gdb too, but it's a lot less cumbersome to remove the conflict first.) _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] GridFlow/#labeling
On Thu, 13 Aug 2009, sisil mehta wrote: I found a patch called pix-multiblob-help.pd in PD-extended. is it similar to the multiblob-for-gridflow patch that u had written? Well... yes and no. If you compared the help file with what I've told you about [#labeling], you would see that several features don't match: with [#labeling] you're supposed to do the threshold yourself (with [# =] or anything else); [#labeling] does not give you the min/max (bounding box) but [pix_multiblob] does not give you the variance. In my opinion the variance is a very useful measurement, but then that's why I wrote [#labeling] the way I did. Also, [#labeling] gives you the data in little pieces instead of a big table like [pix_multiblob] does. You'd think it would be more in GridFlow's style to put data in big chunks (which is the normal way to do things in GridFlow) but I made this an exception to make it easy to filter out unwanted blobs using [spigot]. For example, in multiblob.png you can see that it only keeps blobs that have at least 25 pixels. You could make any other filters you want: for example, you could keep only blobs that spread on a large amount of space (regardless of actual area of the blob); or you could keep directional blobs (long and narrow), which would keep narrow ovals and narrow rectangles, to reject circles and squares (which are as long as they are wide). I don't know what the iemmatrix offers for processing [pix_multiblob]'s output. Perhaps Johannes can give some examples. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] multiblob
On Wed, 12 Aug 2009, IOhannes m zmölnig wrote: the pd-list reaches a larger audience (people who are not interested in scons vs cmake cs autotools are likely to be not subscribed to pd-dev but only to pd-list) I think most people who write on pd-dev and are on-topic are also not interested in a debate between scons, cmake and autotools. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] multiblob
On Wed, 12 Aug 2009, IOhannes m zmölnig wrote: then, i don't know exactly what #labeling does, but i do know exactly what [pix_multiblob] does: it detects multiple blobs in an image and will give you the position, size and extent of each. #labeling gives you the area of each blob, the centre position of each blob, the variance of each blob (in xx, yy, and xy), and also it floodfills every blob in the original picture using a different colour (number). this is the default mode. the other mode of [#labeling] treats each scanline as a different picture with its own blobs, and outputs the blobs as a sequence of 2-vertex polygons. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Fwd: PureData/Gridflow/Camera
On Sun, 2 Aug 2009, sisil mehta wrote: Actually i'm a newb... i had some of the following questions: for using the camera do i need to add some path to the file-path section? does the [#camera] object create? GridFlow adds two hidden lines to the file-path section, as soon as -lib gridflow is really loaded (without any undefined symbol). do i need to change over to pwc? or keep using v4l? pwc itself is a driver, whereas v4l1 and v4l2 are protocols. the pwc driver talks with an app using v4l1. there are some pwc-specific options in the [#camera] patch, which you can enable using the pwc toggle, but only if you know that the driver is pwc. don't try using the pwc options of [#camera] with cameras that don't go thru the pwc driver. which one is required for webcam, mine is :creative integrated webcam. Well, if you want to know which driver is being loaded for your camera, try this command: lsmod | grep videodev in my case, this shows: videodev 33408 1 pwc v4l1_compat13700 1 videodev which means: videodev is a driver used by the pwc driver, and v4l1_compat is a driver used by the videodev driver. in the videodev line, you should have the drivers for any usb cameras you are using at the moment, plus drivers for any pci cards and pc-cards you have for that (TV input cards, etc.) Ultimately i need to use #labeling , but i cant even find it...i have the newest version of gridflow. this is a separate issue. or two. first, you can test [#labeling] without a camera, so you can fix your camera problems separately from your [#labeling]. BTW, if you use the gridflow cvs, please consider switching to the gridflow svn. I'm thinking about shutting down the gridflow cvs to make sure people who want the most recent gridflow don't trick themselves into thinking the cvs is the most recent. basically, I have replaced cvs by svn, but I left the cvs there just in case. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] trouble installing PWC driver
On Sun, 2 Aug 2009, sisil mehta wrote: make -C /lib/modules/2.6.24-23-generic/build SUBDIRS=/home/sisil/Desktop/pwc-10.0.12-rc1 modules make[1]: Entering directory `/usr/src/linux-headers-2.6.24-23-generic' CC [M] /home/sisil/Desktop/pwc-10.0.12-rc1/pwc-if.o In file included from /home/sisil/Desktop/pwc-10.0.12-rc1/pwc-if.c:69: /home/sisil/Desktop/pwc-10.0.12-rc1/pwc.h:28:26: error: linux/config.h: No such file or directory You need to have installed and configured the kernel sources in order to be able to compile a kernel driver. For example you need the linux/config.h file mentioned above. Once you got past the basics of compiling drivers, you may go to http://lists.saillard.org/mailman/listinfo/pwc for driver-specific help. This is assuming that you need to compile a kernel driver in the first place. It's not really fun, so, most people get a precompiled set of drivers (that includes pwc.ko) and they don't touch any form of kernel source code. AND this is assuming that pwc is the driver you need. There are at least four generations of QuickCams. pwc was most popular some years ago, but then Logitech switched to using the UVC protocol, so now, you need to load uvcvideo.ko if you have those cams. QuickCam Pro 4000 are the last cams of the main series to be PWC (Philips chip). Some lower-priced series continued with PWC for a while (well, they still were sold in 2007 and I didn't check after that). _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Gridflow/How to patch PWC
On Sun, 2 Aug 2009, sisil mehta wrote: I have linux kernel 2.6.24-23 generic. I downloaded pwc 10.0.12 rc1 and as per their website( http://www.lavrsen.dk/foswiki/bin/view/PWC/InstallationStandAloneModuleKernel2x6) it says : Patch the module You might need to patch the module if you have kernel 2.6.22 or higher. Applies to version pwc-10.0.12-rc1: http://www.xs4all.nl/~carlo17/pwc/index.htmlhttp://www.xs4all.nl/%7Ecarlo17/pwc/index.html i'm new to linux. so cansomeone help me with this?I didnt really understand how to do this. First look whether you already have the driver loading automatically when plugging the camera. In any case, here are some useful commands: lsusb lsmod modprobe pwc locate pwc.ko _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Gridflow/How to patch PWC
On Mon, 3 Aug 2009, Mathieu Bouchard wrote: On Sun, 2 Aug 2009, sisil mehta wrote: I have linux kernel 2.6.24-23 generic. I downloaded pwc 10.0.12 rc1 and as per their website( http://www.lavrsen.dk/foswiki/bin/view/PWC/InstallationStandAloneModuleKernel2x6) it says : Patch the module You might need to patch the module if you have kernel 2.6.22 or higher. Applies to version pwc-10.0.12-rc1: http://www.xs4all.nl/~carlo17/pwc/index.htmlhttp://www.xs4all.nl/%7Ecarlo17/pwc/index.html i'm new to linux. so cansomeone help me with this?I didnt really understand how to do this. First look whether you already have the driver loading automatically when plugging the camera. In any case, here are some useful commands: lsusb lsmod modprobe pwc locate pwc.ko And I say that because you don't need to patch the module if you already have a precompiled module. you don't even have to load the module if it gets loaded automatically. Any linux user who's been around for a while will have spent a lot of time trying to compile a module, and then finally try to load it, just to see the message module already loaded because the module was really already loaded since before the user even thought about downloading the module's source... Linux is not what it was in the nineties. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] GridFlow/#labeling
On Sun, 2 Aug 2009, sisil mehta wrote: I just can find the #labeling file? i have gridflow 0.9.4 has it been replaced by some other file?? [#labeling] doesn't have a help file. This external is inside gridflow/base/flow_objects.c , so you just have to load gridflow as a whole ( -lib gridflow ) and you have it. there's an example patch at http://gridflow.ca/gallery/multiblob.png [#labeling] has four outlets: outlet 3 gives the amount of pixels in the blob outlet 2 gives a mean vector (where the centre of the blob is) outlet 1 gives a covariance matrix (how much a blob spreads) those outlets are sent to repeatedly for each blob, and then once of: outlet 0 gives an indexed color version of the original binary picture by replacing every 1 by the blob number (numbered from 2 upwards). [#labeling 1] is a variant that has two outlets: outlet 1 gives two-sided polygons made of all horizontal segments in a picture. outlet 0 is the same as before, except all blobs are horizontal lines because all scanlines are considered separate. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PureData/Gridflow/Camera
On Sun, 2 Aug 2009, Alexandre Castonguay wrote: I just tried it with a logitech camera and I get a hard crash. You can't just say a logitech camera here. say which kind of camera. the kind means the driver that has to be used with it. That means that Logitech isn't a kind of camera, but PWC (Philips) is. I know that UVC cameras don't work with GridFlow because V4L2 isn't supported by GridFlow and V4L1 isn't supported by UVC. Before PWC there were the QC-USB cameras, of which you have at least one (perhaps a bunch) and we already used the parallel port QuickCam in the nineties, so that makes 4 completely different drivers (qce-ga was the only former name of the qc-usb driver). _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pure Data/adding _path for gridflow
On Sat, 1 Aug 2009, sisil mehta wrote: I am having trouble running any of the gridflow exmaples on PD. my gridflow directory is located at /usr/lib/pd/extra/gridflow. I created the .pdrc file in /home I am a newb to this.So how do i add the CPLUS_INCLUDE_PATH for gridflow? also what is LIBRARY_PATH and LD_LIBRARY_PATH and what is this path supposed to be? Sisil. Yes, CPLUS_INCLUDE_PATH is recognised by GridFlow. LIBRARY_PATH is parallel to C_INCLUDE_PATH and CPLUS_INCLUDE_PATH, but instead of putting the include folders in it, you put the lib folders. LD_LIBRARY_PATH is normally exactly the same. It is used when running programs, whereas LIBRARY_PATH is used for compiling programs. When you compile programs for your own computer and have only one OS, then those two variables should have the exact same content. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pure Data/adding _path for gridflow
On Sat, 1 Aug 2009, sisil mehta wrote: hello, i have just compiled gridflow from cvs and get a : /usr/lib/pd/extra/gridflow/gridflow.pd_linux: /usr/lib/pd/extra/gridflow/gridflow.pd_linux: undefined symbol: _ZN9CPPExtern8m_holderE gridflow: can't load library and i don't know what to do... This is because you compiled GridFlow with GEM support, so GEM has to be loaded before GridFlow in .pdrc or .pdsettings or else you could recompile GridFlow without GEM support. It will be like this until GridFlow's GEM support becomes a separate external. context : laptop toshiba a10 / ubuntu dapper / gcc 4.0.3 / gridflow from cvs do you mean svn, or cvs? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] trouble installing PWC driver
On Tue, 4 Aug 2009, sisil mehta wrote: u mentioned about using the uvc driver, but i actually ws using gridflow in puredata which requires the pwc driver.(unless there is a way to avoid that and use uvc . is there?) Johannes Zmölnig just mentioned (on pd-dev) some way of doing it, which I have not tried yet. This is because UVC supports V4L2 but not V4L1, and GridFlow supports V4L1 but not V4L2, so you need an adaptor. I knew about an adaptor for the other way (V4L1 driver, V4L2 program) but not this way (V4L2 driver, V4L1 program). GridFlow does not require the PWC driver. It supports some features that are only in the PWC driver, but that's optional. It supports V4L1 in general (I used it with Brooktree devices and QC-USB devices in the past). I believe that a device is either requiring the PWC driver or the UVC driver, and you don't have a choice. for example, the QC Pro 4000 supports only PWC, and the QC Pro 5000 supports only UVC. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pure Data/adding _path for gridflow
On Sat, 1 Aug 2009, Claude Heiland-Allen wrote: sisil mehta wrote: hello, i have just compiled gridflow from cvs and get a : /usr/lib/pd/extra/gridflow/gridflow.pd_linux: /usr/lib/pd/extra/gridflow/gridflow.pd_linux: undefined symbol: _ZN9CPPExtern8m_holderE gridflow: can't load library did you compile gridflow with Gem support? if so, you need to load -lib Gem before -lib gridflow oh yes, but I've also got that message when using conflicting versions of GEM: e.g. compile with source that has m_holder, and then try to run with another GEM that doesn't have m_holder. I think it was even possible to get this with same version numbers, e.g. early 0.90 versions aren't compatible with late 0.90, and thus have to be treated like it's 0.89... but I don't really recall. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PureData/Gridflow/Windows
On Sun, 2 Aug 2009, sisil mehta wrote: Pure Data does work on windows. However will the gridflow libs work on windows as well? it's several times harder than getting it to work on Macintosh, and it's already somewhat harder on Macintosh than on Linux. what if i use cygwin. GridFlow is more friends with Cygwin than with anything else on Windows, but I don't know how much PureData is friends with Cygwin on Windows. Has anyone tried this before (i'm a newb...so any help is appreciated) GridFlow on Windows is not for the faint of heart... until someone makes a package, and/or sends me the appropriate fixes so that GridFlow becomes easier to compile. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] trouble installing PWC driver
On Tue, 4 Aug 2009, sisil mehta wrote: hmm, But in gridflow when running the camera-help.pd , it mentions the need for either a tv source or it mentions: for webcams you need to have a pwc module loaded. Yeah it still says that. I don't recall who wrote that, but the doc is wrong and was always wrong, because PWC came after QC-USB and we used both drivers at the same time for a while... I last tried QC-USB as recently as 2008, with an old Lego Mindstorm camera. AFAIK, QC-USB was always supported since the day it started working, and that was a while before we even knew what PWC was. if there is a way to use v4l2 (which enables use of uvc cams) is it stable and safe? I've already said all that I know. Please stay on the forums, it may help you. I say that because you often reply in private, and it's not really appropriate, for most cases where people start posting in public. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] uDMX pd external crashes pd
On Tue, 30 Jun 2009, Georg Werner wrote: i asked michael eggers (the developer of uDMX) and he did answer very quickly. if anybody needs it here is my .dll file for win32 and the udmx.c. cheers georg floatinlet_new((t_object *)x, (t_float *)x-channel); //assigns float in inlet 2 directly to channel inlet_new(x-p_ob, x-p_ob.ob_pd, gensym(float), gensym(ft1)); Isn't that a matter of using the ampersand in front of x-channel ? What you use as a t_float * must be at least a pointer to something that can be used as a float... but this can be pretty much only t_float or t_word or aliases for either of them. So probably the (t_float *) cast shouldn't be there at all and there should just be the ampersand that it would need anyway... unless x-channel is really a pointer to the variable... I haven't seen the source code of this. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] vanilla+libs build maintainer
On Fri, 12 Jun 2009, Hans-Christoph Steiner wrote: Anyone want to maintain the vanilla+libs/main+libs nightly builds? They are broken and I am feeling overwhelmed with maintainence work. So if no one wants to do it, I'll remove it from the nightly builds. I don't understand: what is there to fix in vanilla+libs that isn't covered by fixes to pd-extended and to vanilla? And then what's the difference between vanilla+libs and main+libs, if any? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] request - PdLab Farm Machine
On Fri, 5 Jun 2009, Hans-Christoph Steiner wrote: Ok, Matju and you should be in all the systems now. Please remember, any time I spend supporting these systems is time away from me working on Pd. So please be gentle. I think that you still haven't told me what the username is? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] request - PdLab Farm Machine
On Tue, 9 Jun 2009, Hans-Christoph Steiner wrote: On Tue, 09 Jun 2009 14:47 -0400, Mathieu Bouchard ma...@artengine.ca wrote: On Fri, 5 Jun 2009, Hans-Christoph Steiner wrote: Ok, Matju and you should be in all the systems now. Please remember, any time I spend supporting these systems is time away from me working on Pd. So please be gentle. I think that you still haven't told me what the username is? Because I thought you'd RTFM ;) 'pddev' As I said on IRC, it was just a PEBKAC. http://puredata.info/docs/developer/WindowsXPI386 But that's a SNAFU. my screenshots of my login attempts: http://artengine.ca/matju/pics/losedows.png http://artengine.ca/matju/pics/microsoftitis.png BTW I would enjoy having a MinGW nightly build on that machine, now that the Linux builds aren't bad. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] request - PdLab Farm Machine
On Fri, 5 Jun 2009, Hans-Christoph Steiner wrote: Ok, Matju and you should be in all the systems now. Please remember, any time I spend supporting these systems is time away from me working on Pd. So please be gentle. Well, it also means that I won't be bugging you for things you won't have to help me for. So, hopefully, you would even be saving a bit of time, overall. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] more builds
On Wed, 3 Jun 2009, Hans-Christoph Steiner wrote: Since the build farm is a Pd resource, you need to post to pd-dev@iem.at in order to request access. That way pd devs can see the request, respond if they want, and we have a record of it. On Wed, 3 Jun 2009, Mathieu Bouchard wrote: On Tue, 2 Jun 2009, Hans-Christoph Steiner wrote: If you want shell access to the build machines, you only need to give me an SSH key. That goes for any of you. http://puredata.info/docs/developer/PdLab here is my public key. Tell me which machines you will grant me access to, and what is the username. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec id_dsa.pub Description: Binary data ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [select] to make zexy's pack/unpack
On Sun, 5 Apr 2009, Hans-Christoph Steiner wrote: I really like the idea of zexy's pack/unpack, it seems more pd-ish to me than the vanilla versions. I was wondering if anyone has considered doing a similar thing with [select] to make it more flexible in terms of mixing symbols and floats. Here's an illustration of the issue I am talking about: I made one like that some years ago. You know where its source code is. http://artengine.ca/desiredata/gallery/select-mixed.png _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
