Re: [PD-dev] alsa midi device numbers
On 06/07/2013 06:34 AM, Jonathan Wilkes wrote: I'm trying to track down a bug in my preferences dialog code for midi. In Pd Vanilla 0.43: If I choose Media - Hardware-Midi it brings up a dialog what's Hardware-Midi? If I choose Media - Alsa-Midi it brings up a dialog If I choose Media - Hardware-Midi, close the dialog, then choose Media - Alsa-Midi I get insane device numbers in errors to the Pd console: i don't see this error with Pd-vanilla. how does the vanilla property box handle device numbers differently than yours? couldn't open MIDI input device 2054 couldn't open MIDI output device 1836017711 opened 0 MIDI input device(s) and 0 MIDI output device(s). I suppose to be on the safe side, for both audio and midi I should not assume that devices will be numbered contiguously from 0-n. Still, these weird device numbers will probably cause errors. Unfortunately I don't have a midi device so I can't test it. if your hardware MIDI device is OSS, you can load a loopback driver to get a software device. fmasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd-ext Submitting new relase
On 05/17/2013 09:02 PM, João Pais wrote: I think I did it, https://puredata.info/downloads/jmmmp-1/releases/0.2 for some reason I can't add new stuff to http://puredata.info/downloads/jmmmp, so when I tried to make a new project, it created the folder jmmmp-1. any objections if i change that back to /jmmmp/ before the link spreads? fgamrd IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Not a PD bug [Re: Pd-dev Digest, Vol 94, Issue 33]
On 02/01/2013 05:43 PM, Rastko wrote: As regards my posting below, (GEM fails on Win Server...), I discovered it is a bug in Windows, not in GEM. Apparently, none of my window-mode OpenGL applications work. I have read that it is because I don't use the Aero desktop theme. I tried enabling the Theme service, and selecting an Aero desktop theme, and IT WORKED. thanks. that is very valuable information. fafr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] small regression regarding window placement
On 02/01/2013 10:10 PM, Hans-Christoph Steiner wrote: I say remove that bit entirely and let the GUI handle figuring out where the window should go. yes! fgadm IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Question about error in external
On 01/18/2013 10:41 AM, Thomas Mayer wrote: Hello, while I am working on PuREST JSON, I have gotten an interesting error, but only on Windows: Two of my objects do not load correctly with the message: load_object: Symbol rest_setup not found On Linux, this works without any problems, as do the other objects in Windows. What is different with [rest] and [oauth] objects? Both are using a lot on w32 you have to explictely export symbols from a dll, in order to be able to use them from another dll (e.g. pd). either with the /export linker-flag or with the __declspec(dllexport) attribute. gfmasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD-ot] Xcode and some commands
On 01/14/2013 07:16 PM, Alexandros Drymonitis wrote: You're right, sorry for this one. Still the aclocal: command not found remains, damn it! well, what do you get, when trying to compile? fgamsdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD-ot] Xcode and some commands
On 01/14/2013 09:15 PM, Alexandros Drymonitis wrote: I think the problem is that the aclocal command can't be found. I've been looking at some forums and I read that this command is not included in xcode anymore. Tommorow I'll try to figure it out. what is the error you are getting? fgamsr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] from t_symbol to t_class
On 01/12/2013 11:56 PM, Jonathan Wilkes wrote: a t_class *s_class? Would that affect performance? it would break binary compatibility. there's no good reason to add hash-like lookups to t_symbol (your only reason is convenience). and avoiding code duplication. i think that breaking binary compatibility is more important than code duplication, but ... Then searching for an existing class would be easy-- just do a gensym and check if its s_class exists. but checking whether a class exists, is as simple as calling zgetfn on pd_objectmaker. i think this is _quite_ easy. Well yes. I meant searching for a class and _returning_ a class pointer. ...which only means that the current interface (using zgetfn with pd_objectmaker) is inadequate to your problem. So without adding/revising code inside class_new, is creating an instance the only way to get access to the class attributes? unfortunately yes. but adding/revising code inside class_new would retain 100% binary compatibility, whereas adding members to public structures is a 100% guarantee to break binary compatibiliy. i think it is one of Pd's greater weaknesses, that so many data structures are exposed (rather than opaque). if we had more accessor-functions, there would be less need to worry about binary compatibiliy. fgamsdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] from t_symbol to t_class
On 01/12/2013 12:04 AM, Jonathan Wilkes wrote: In C would I just make a struct with fields of t_symbol, t_class, and a pointer to link to the next one? Yeah, a linked list would work fine, probably not as efficient as the c++ hash structure (but lots easier to maintain). One nit-to-pick: Use a t_class pointer, which is a t_pd. Hm... since the code to add new classes to the list will probably end up looking exactly like the code to add symbols to the symbol table, what if I just bloat the _symbol struct by adding a t_class *s_class? Would that affect performance? it would break binary compatibility. there's no good reason to add hash-like lookups to t_symbol (your only reason is convenience). true, there's an s_thing there, but that's mainly for performance reasons (looking up symbol-class mappings is usually outside a performance critical path)(and having s_thing in t_symbol is very ugly) Then searching for an existing class would be easy-- just do a gensym and check if its s_class exists. but checking whether a class exists, is as simple as calling zgetfn on pd_objectmaker. i think this is _quite_ easy. fgmasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] from t_symbol to t_class
On 01/04/2013 07:19 AM, Miller Puckette wrote: I think you're safe calling vmess() to pass no arguments to clip_new (for example) - the worst that can happen is the return value (the global newest is zero. If not it's a proper Pd object you can use zgetfn() on to test it for messages. Main problem I see with this is that some classes like select and list are actually several classes that share a name (and which one gets created depends on the arguments sent to vmess()) also, what happens if the object in question accesses some hardware ressource? e.g. [pix_video] will try to grab an available video-source, potentially locking a hardware device. in theory this should not be aproblem, as the object will hopefully be freed by [classinfo] asap, but in practice it might have all kinds of side-effects, starting from short lockups of Pd to launching rockets. gmfad IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libraries with debug symbols
On 02/03/2012 01:30 PM, Roman Haefeli wrote: Hi Is there a way to compile libraries from svn with debug symbols using the template Makefile _without_ editing the Makefile? I can pass CFLAGS=-g to make, but the resulting externals are still stripped. looking at the latest template Makefile, it seems that externals are only stripped on installation. if you can live without make install, you will get un-stripped binaries. if you cannot live without make install, setting STRIP to something harmless should do the trick: $ make clean $ make install STRIP=true CFLAGS=-g fgmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd_free vs canvas_vis
On 11/19/2011 05:39 PM, Ivica Ico Bukvic wrote: I guess this is mainly for the Pd devs, Jonathan and I have been working on trying to have patch close itself through the script. However, even in the newest Pd the problem persists in that if one invokes menuclose via patch it crashes pd. I suspect this is because the closure happens while Pd is still traversing the tree and then trips up on newly deallocated memory pool invoked by the pd_free. Initially, I designed a workaround where pd_free is enqueued on the guiqueue and invoked a bit later ensuring that it is called after the tree navigation has ended. This works in most cases but not all. Intermittently this will crash Pd when using Jonathan's Nav abstraction which closes the current patch and also opens a new patch (navigation abstraction would be used to go between help files always keeping only one patch open at a time). Attached is Jonathan's abstraction. So, now I started investigating further and it seems that canvas_vis(x,0) closes the patch without any problems and without having to delay anything but this is not enough in and of itself to actually deallocate the actual t_canvas x and other instantiated objects associated with the canvas. So, how could one go about to implement this feature? you could just use [canvasdelete] from iemguts. send a bang to [canvasdelete] and it will delete itself sand a bang to [canvasdelete 1] and it will delete the containing abstraction. that is, it will not close an opened patch (es opposed to an abstraction contained within a patch), but it should be simple to add this functionality to the existing framework. famsdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] iemlib help patch revisions
On 08/28/2011 07:23 PM, Jonathan Wilkes wrote: Is that the correct email address? yes it is. mgfasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tracker spam
On 08/05/2011 05:08 PM, Hans-Christoph Steiner wrote: How about turning off anonymous posting on the bug/patch/feature trackers? The spam rate is increasing, and the anonymous bug reports are either people who forgot to login, or otherwise quite low quality. i don't see a point in doing so. the spam rate is really low. there are 8 spam issues in all 3 trackers, 4 of which have been posted in 2011, and 4 have been posted in 2010. i wouldn't call that excessive. you have deleted for of them, i deleted the rest, so the main work was on my side :-) so please leave the bug tracker open. fgmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] recentfiles_list explanation
On 03/15/2011 10:15 PM, Yvan Volochine wrote: On 3/15/11, Hans-Christoph Steiner h...@at.or.at wrote: On Tue, 2011-03-15 at 03:45 +0100, Yvan Volochine wrote: I'm trying to get recentfiles written to ~/.pdsettings and I think I'm missing something obvious. [snip] Hey Yvan, It's great that you are taking this on, its definitely useful. I think that it might make more sense to create a separate GUI-only preference system. Its something that I had planned on trying, but hadn't found the time, so it'd be great if you beat me to it! This way it would be a lot easier to deal with, you can do everything from Tcl. hi, well I'm trying.. a separate GUI-only preference system would mean a separate dot file then (like .pdgui) ? why not make a ~/.pd/ folder and put your preferences for your plugin in there? this woul dallow for less clutter in the home-directory and bundle all the pd-related settings nicely together. and so far, this would contain only recentfiles right ? ~/.pd/recentfiles.conf would always only contain recentfiles configuration. fgamsdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] signal external behaviour changes without changing code
On 02/18/2011 04:16 PM, Andrew Hassall wrote: I'm writing a 2 externals for PD as part of my 3rd dissertation for a computer science degree. They are both signal externals, they are part of the LPC (linear predictive coding) algorithm, 1 to analyse the signal (create the filter coefficients and filter the incoming signal to give the source signal) and 1 to resynthesize the signal (using the filter coefficients to filter the source signal). However I've created both externals and sometimes when the items are created they behave as expected and work perfectly, but more often they do not work as intended without reading further on, i want to make sure you are aware of the fact, that Pd might give you the same pointer to both input and output signals. thus, if you write something into the output signal vector, you might invalidate the input signal (fix: make sure you read all the input samples before you overwrite them) fgmadsr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd 0.43 test4: Canvas Position
On 01/22/2011 12:02 AM, Hans-Christoph Steiner wrote: It was changed to work on GNOME/metacity, which is the default on Fedora, Debian, Ubuntu, Mint, etc. So it is by far and away the most common. iirc, gnome is only widespread in the US, whereas europe (and esp. german speaking communities) used to favour KDE. this if course it under constant flux, but i wanted to point out that by far and away the most common is a very subjective and usually point of view which i strive to avoid. fgmadrs IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] general makefile question
On 12/02/2010 09:40 PM, Hans-Christoph Steiner wrote: On Dec 2, 2010, at 3:11 PM, Bryan Jurish wrote: Maybe I'm misreading this thread, but wasn't there something like: something like 'PD_LDFLAGS=-Wl,--export-dynamic -shared $(LDFLAGS)' and then consequently using $(PD_LDFLAGS) in the linking stage? yes, this would be my suggestion. Sorry for the complaint, the bug in question cost me a full day of time re-doing really unfun stuff. That's a full day of my free, unpaid time. Code has bugs, therefore it needs testing, that's all I'm saying. sure. however, in order to properly test, it would be great to have a test defined (even if it only was an instruction like, apply your changes to library X (because this uses feature A) and library Y (using feature A B), then run $ make $ make clean $ make install $ make uninstall $ make install DESTDIR=/tmp $ make uninstall DESTDIR=/tmp $ make dist and see if all this succeeds. doing a thorough test on the template Makefile without having a test defined, is probably taking more time then a full day (and yes, i do a lot of work in my free unpaid time as well) So I say take the template Makefile and go nuts with it, fix all the bugs add features, but do it in a branch, thoroughly test it, and then we take it from there. i switched the build-system of iem/syslog to my modded version of the template Makefile and afaict, everything works: https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/iem/syslog/Makefile everything excludes the 'uninstall' target (non-existant it seems) and an unnecessary complicated procedure to install into /usr/lib/pd/extra (though i won't change that for now) sidenote: in this makefile i am using ALL_*FLAGS rather than PD_*FLAGS; i have no opinion whatsoever on the exact prefix of the variables; ALL_* is suggested on the Gnu standards page, and PD_* being more Pd than Pd-external. probably PDEXT_ would be a proper prefix. @IOhannes: sorry about my bogus += suggestion; posted without testing it first :-/ np. it's what i would have suggested myself as well, just to find out that it didn't work. i prefer one person to find out and communicate, to two persons having to go through all steps to find out. mgfasd IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] general makefile question
On 12/03/2010 05:44 PM, András Murányi wrote: If you want to test it on various platforms at once, please msg me and we can easily set it up in buildbot (which is not the effective autobuild system yet, but it's quite worked out). We will just need to have the stuff available in some kind of repo. thanks for the offer. the syslog external/library that uses the modded Makefile is already in the repository. nevertheless, i don't know what to test :-( fgkasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Debian packaging: multi-object/single-file libraries or single-object/multiple-files libraries?
On 11/12/2010 05:24 AM, Hans-Christoph Steiner wrote: On Nov 11, 2010, at 10:23 PM, Jonathan Wilkes wrote: I'm new to Debian and to linux, and have two noob questions: 1. If package A has an abstraction that depends on an object from package B, is package B automatically installed when I install package A? If the package has the correct Depends: set, then yes. For binary libraries, there are tools to do it. For abstractions, its a manual process, but I suppose we could script it. and if something was missed, it would be a bug, that you could report and that can easily be fixed (given that a lot of packages are packaged right now, it might be that there is too little time to check everything manually) 2. If package A has a help patch that uses an object from package B, is package B automatically installed when I install package A? Same as above. there has been some discussion about this, and the consensus was, that help-patch dependencies should be treated as not-hard-dependencies. this would allow advanced users to override the dependency, e.g. _allowing_ to install a library like pd-mapping without having to install pd-pddp. but in general, a user who does not want to tweak their pkg-manager settings, will get a fully functional library. fm,asdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] run-up to release 0.43
On 08/19/2010 02:06 AM, Miller Puckette wrote: I'll try not to add new features but just fix bugs for the next 2 weeks -- here is one bug (+ fix): pd -version prints garbage. https://sourceforge.net/tracker/?func=detailaid=3050371group_id=55736atid=478072 mgfasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] run-up to release 0.43
On 08/21/2010 06:32 PM, IOhannes zmölnig wrote: On 08/19/2010 02:06 AM, Miller Puckette wrote: I'll try not to add new features but just fix bugs for the next 2 weeks -- here is one bug and of course there are several simple bugfixes still pending in the tracker: e.g. 2806049: [bugfix] renamed arrays do not get used by dsp 2835752: floor, ceil functions in expr misdeclared those are really simple, about 2 lines code each. gmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] template Makefile
i cleaned up the template Makefile (externals/template/Makefile) a bit. namely i switched to using $@, $ and $^, which makes a lot of things way more elegant. other cleanups: removed the SOURCES_android since this is not used anywhere and is misleading use PD_PATH where appropriate added SOURCES_LIB for .c files holding shared functions use HELPPATCHES to enumerate -help.pd (usually this info is gathered automatically; the average user will never see that) these changes should make zero difference to the user experience of the templ Makefile. remaining questions: DIST PATH: why does the makefile enforce the manual and examples to be examples/ resp. manual/ folders _in the source directory_ ? i understand that they should be laid out standardized in the install directory, but why in the source folder? why not just: MANUAL = doc/manual.pdf manuals/anothermanual.pd and install that into .../$(LIBRARY_NAME)/manual/ INSTALL PATH why the heck is the default installation path: $(libdir)/pd-externals ?? i cannot remember that this was agreed on by anybody but hans. i do remember that ~/pd-externals was discussed (and i still would prefer ~/.pd/extra/ over this unnecessary homedirectory cluttering), but $(libdir)/pd-externals is news to me. instead i do remember, that $(libdir)/pd/extra was meant to be the canonical name for all flavours of Pd (e.g. with PdX and pd-vanilla, in debian pd-vanilla would look into both /usr/lib/puredata/extra and /usr/lib/pd/extra, whereas PdX would look into /usr/lib/pd-extended/extra and /usr/lib/pd/extra (in this order)) i also find, that a related patch has made it into puredata.git. unfortunately, it is inconsinstent with the template Makefile, as puredata.git has hardcoded /usr/local/lib/pd-externals/ whereas the tmpl uses $(libdir)/pd-externals which could well be /usr/lib/pd-externals/ which in turn is never ever searched by Pd. in case, i haven't said it yet: i don't like this. ,asdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] iemguts build issues WAS: dynamic patching: getting info on objects
On 08/17/2010 01:59 AM, Hans-Christoph Steiner wrote: Try using the template Makefile yourself, it should be pretty easy to plug in: http://puredata.info/docs/developer/MakefileTemplate Basically, you just need to list the C files in the right place, at the top. for what it is worth, iem/iemguts/Makefile is now template-based, so it should build on a numbe of platforms wihtout too much hazzle. fgmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] 0.43 meetup on IRC?
hi On 07/15/2010 10:33 PM, Hans-Christoph Steiner wrote: We are kind of meeting now a bit, but we should do it tomorrow if you can IOhannes. obviously i was safe and sound at home last eveneing when you tried to IRC. i'm leaving for hols on monday and will probably be offline tomorrow and the day after tomorrow as well, so today would be a perfect chance to meet up at IRC (for more than 2 weeks) 19:00UTC is ok i would prefer 18:00UTC though... fgmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] pd-gui 0.43: fixed position/size
hi all, i'm wondering why the geometry (position/size) of the main pd-window is hard-coded in the new gui. pdwindow.tcl:257 wm geometry .pdwindow =500x400+20+50 tcl figures out the needed size of the window quite fine for me, but what annoys me a bit is that the window position is hardcoded. window managers are usually quite good at finding out, where there is still place for new windows. starting several instances of Pd will all force the main window to be on the same position. the reason why it annoys me most, is that when i start it Pd, the window is always hidden behind my terminal (yakuake). if there is no really good reason, i would opt for removing this line. fgmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] 0.43 startup procedure and vwait WAS: [PATCH 06/10] fixed race-condition in the audio/midi API initialization
On 07/15/2010 04:46 PM, Hans-Christoph Steiner wrote: The vwait timeout would not be needed if we can rely on 'pd' to actually fully die when it exits/crashes. On Mac OS X at least it is often doesn't completely crash and the process just sits there doing who knows what. If this happens on startup, pd-gui's exec call will not return, and pdtk_pd_startup won't be called and pd-gui will just sit and wait forever, giving us a zombie pd-gui. The vwait stuff wouldn't be needed if we can rely of pd to exit completely on all platforms. Just removing the vwait stuff is just replacing one problem with another. sure. i'm only talking about the race-condition. whether the vwait is there for other things is entirely beyond my scope. iirc, this is the title of this thread as well. Relax, no one is suggesting fixing a race condition with a timeout. Can you describe how to reproduce the race condition? What's actually racing? Did Miller's changes fix it? i did not experience any problem with miller's changes so far (which does not mean that the race-condition is gone, it just didn't show up) racing was between pd-gui and pd: if the latter was to late, either pd-gui would timeout or the media menu would be initialized wrongly (no audio/midi APIs available) leaving all this aside, i still think that it is a good idea for Pd to be able to change the dynamic entries of the menu at any time. if the available APIs change, Pd could update the menu accordingly (sounds like a stupid idea? but if jackd is running, then the only really available API would be jack (OSS, ALSA, portaudio being all blocked by jackd; ich jackd stops, other APIs would become available again) gfmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] worth to create external?
Lorenzo wrote: Hi list, I'm already on the pd-list. I signed up to the pd-dev as I'm starting to look into some (simple) external development. cool. please note that pd-dev has the same netiquette as pd-list, that e.g. asks you to not hijack another thread for your unrelated postings. see http://puredata.info/community/lists/Netiquette#Threads First, though, I thought it would be wise to ask when is it really worth to write an external vs using directly pd abstractions considering the various c/b? Is this in some way 'measurable'? yes. relate the time spent writing one solution (including learning to actually do it plus doing big-fixes) to its relevant benefits (does it work? what's the performance? is it portable? ...) and compare the scalars you get for the various solutions :-) fgmadr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pix_multiblob mem leak
Gerrie Roos wrote: Hi! It looks like pix_multiblob is leaking about 4kB/frame/blob. Anybody else seen this? I'm in a bit of a tight spot. I've got an installation coming up on 18 March and my extensive pd patch is now running out of memory every couple of hours. Would love to check out the source code and try fix it myself but since I've never done any pd dev it will put me back a couple of days (at the least). I'll buy you beer! Windows XP SP2 Pd version 0.41.4-extended what Gem version is this? does the problem exist with the latest and greatest Gem (0.92.2)? (if not, i claim the beer :-)) thanks for sending an example patch; it's pretty generic, and i do not see any memleak occuring here (using the alea.mpg example film). however, the bug might be related to the number of blobs found and the image format, neither of which i can reproduce; could you put the clock.avi online somewhere so i can download it? or: how does your patch behave with homer.avi? fmadrs IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] videogrid + pd-extended 0.42.5
lluis gomez i bigorda wrote: hi all, yes, we say here esoteric bug cause we cannot understand at all why if Gem is linked against libavifile it beaks our ffmpeg code. videogrid is not linked against libavifile !!! that's crazy? or not? not necessarily, since most of those video decoding backends like ffmpeg, libavifile, gmerlin, quicktime4linux are plugin based and use each other as backends. so the interrelations between all those are somewhat messy... and more, if we load videogrid before Gem the crash desapears. why the lib load order can change behaviors of a library in that way? maybe some namespace conflict? yes. i guess that libavifile comes with an ffmpeg-plugin which will be initialized on loading and which (due to the way ffmpeg is not released) conflicts with the ffmpeg version installed on the computer. anyone can put a bit of light on this please? we are just belivers of almighty pd wisdom. you know ... :) a similar problem occured with libstdc++ and ati/radeon drivers a while ago. i don't think there is a generic solution for such problems (hmm, on w32 you have to bundle your library with all it's dependencies; maybe this is the solution;; maybe not) gfmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Ignoring '5401': doesn't look like a Pd-file
Hans-Christoph Steiner wrote:
one could use the new ::pdwindow::verbose{} rather than post{}.
but really the underlying problem should be fixed sooner than later.
Warnings that happen every time rapidly become meaningless, and
therefore a pointless annoyance. Much better is to fix the underlying
problem:
yes, this is what i was saying.
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revrevision=12996
this is what should have been done to fix the problem, and which i
didn't find time to do.
so in the end, it worked out exactly as i imagined:
- i added a more verbose output
- the new output hinted at a problem in the arg parsing
- someone got annoyed by the output
- the underlying problem was fixed
so i'm not sure whether there is a problem with the way i did.
so the next meaningless, and therefore a pointless annoyance to fix is:
WARNING: Font family 'Courier' not found, using default (courier)
let's see who makes the race
mfgasdr
IOhannes
signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pdwindow as syslog
Hans-Christoph Steiner wrote:
Hey IOhannes,
I was just looking thru your pdwindow.tcl procs. It seems to me that
those procs should just go all the way and implement a syslog-style
system with the same levels. Then the Pd window could have a little
dropdown menu on the lower left to select which level to show.
the pdwindow::verbose{} functionality is modelled after pd's verbose()
functionality.
assuming that most Pd devs will have more experience with Pd's posting
mechanisms than with a platform depending syslog functionality, it made
way more sense to use verbose than syslog.
if the only reason to change the name to syslog is, that the mechanism
reminds you remotely on that used by syslog, i would kindly ask to
change it back.
Attached is my failed attempt at defining the functions. Also, about
the tags for colorizing things, I think your syslog level tags and the
alternating linecolor? tags should be applied to all lines, not
depending on which proc is used. Then different plugins or modes can
colorize the text. Otherwise, it'll be just a big mishmash of colors.
please bear in mind that english is not my mother tongue.
...oh, it seems like the linecolor? does not finish the sentence.
then, i don't see what you mean: the public functions are
::pdwindow::verbose{}, ::pdwindow::error{} ::pdwindow::post{} are the
public functions that all set the corresponding tags.
so my argueing is, that tags should be applied to all text (which they
currently are), depending on which category a text belongs to.
the category is given implicitly by the proc that is used to print the
message. thus the tags are depending on which proc is used.
what i did change was to only call the colorizing code for a tag once,
and not each time something was printed. (which is somewhat useless and
only adds additional ressources)
As for me, I think just a subtle alternating color per post, not
per-line. Then error posts would have a sublte red background.
sure
fgmasdr
IOhannes
signature.asc
Description: OpenPGP digital signature
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Scheduling to activate control objects
PSPunch wrote: Hi, I am working on a control rate object which outputs a value, only when a variable local to each instance is modified by another thread. Having not known how to achieve this, the object works fine, but only with a [metro] connected to it, polling for a variable change on each bang. I've looked into [metro] and [netreceive] which also output values without an external factor (inlet wise), but I kind of got lost in the code. Is there a simple way of achieving such an effect (i.e. by registering a callback), or does this require a reasonable understanding of the time scheduling mechanism inside Pd? have a look at the clock functionality. a clock is basically a scheduled callback. if you want it to happen repeatedly (like metro), you have to reschedule the clock within the callback. apart from that: why don't you just use [metro]? thus nobody has to learn how to start/stop the polling and to set the polling interval; instead they can just use an object which they already know (and if not will find that they should already know :-)) fgmnasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
