Re: [PD-dev] Which one is the correct repository to submit patches for externals code?
On 04/05/2014 03:05 PM, Rafael Vega wrote: I found and fixed a bug in oggread~ that is windows specific. The fix is a one liner in oggread~.c (details in previous thread). I thought the central place for externals code was the SVN community repoat [1] but the comments below confuse me. Can someone please confirm which one is the correct place to submit a patch? we are talking about two different things: the central place for externals code and the correct place to submit a patch. the SVN is the first one, but you are looking for the second one: reporting bugs and fixes is done through the patch tracker at http://bugs.puredata.info (which is an easy to remember URL pointing to the sf patch tracker). while technically every dev-member of the pure-data sf-project can write to the entire SVN, the *policy* is that only the maintainer of a package commits to their code. fgmrdsa 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 howto errata
On 03/24/2014 06:54 PM, Jonathan Wilkes wrote: Here's errata for the first part of the tutorial on building externals: thanks. i'll update the tex files. gfmr 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] Destructor in external classes
On 03/24/2014 02:56 PM, Antoine Villeret wrote: hello, the free method seems to be called when the object is deleted from the canvas. is there a similar method called on Pd quit ? no. see http://sourceforge.net/p/pure-data/patches/82/ fgsdr 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] Question about multi-arch Mac OS X - is 32-Bit still around?
On 02/23/2014 01:46 AM, Dan Wilcox wrote: Just to confirm what Iohannes, et al. already know. pix_filmDarwin, pix_movieDarwin, pix_recordQT, pix_videoDarwin need to be updated to use the newer Apple APIs: QTKit or AVFoundation. I've done an AVFoundation app already and we're using QTkit in the updated OpenFrameworks code, so I can probably reuse bits here and there. ohoh just to make sure: [pix_filmFoo] is long dead. Gem now uses a plugin system to access the various platform dependent components. so what needs to be done is writing the following plugins: - videoQtKit - filmQtKil - recordQtKit check Gem/plugins/ for examples. mfdars IOhannes PS: sorry, not much time right now to elaborate signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Question about multi-arch Mac OS X - is 32-Bit still around?
On 02/23/2014 03:58 PM, Dan Wilcox wrote: So would we remove those older implementations or transfer the other OS implementations into newer plugins? Or has that already been done for Linux Win? it has already been done for all platforms (also on OSX - e.g. videoDarwin, filmQT,...) what is missing are plugins for QtKit. the source tree still contains the *unused* code for e.g. pix_filmDarwin.cpp... fgasdrm 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] Question about multi-arch Mac OS X - is 32-Bit still around?
On 2014-01-11 01:08, Thomas Mayer wrote: So: Is 32-Bit on Mac OS X still around? due to QuickTime issues, Gem on OSX is still 32bit only. this means that whoever wants to run Gem on OSX, will need to use a 32bit version of Pd and not being able to run a 64bit-only purest json. admittedly this is an issue of Gem, but little can be done about it. gfmdsar 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] Inputs and outputs connected
On 2013-11-19 17:26, Pierre Guillot wrote: Hi, I would like to know the inlets and outlets which are connected to my object. check [canvasconnections] in iemguts. This information could be useful in the dsp method. hmm. in general i would say that your object design is somewhat broken if you use the connection information in your dsp method. fgmdsar 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] Problem with renaming setup functions
On 2013-11-14 23:44, Thomas Mayer wrote:
Hello,
I am currently documenting and refactoring the code of PuREST JSON to be
consistent, but I seem to be unable to rename setup function from
setup_json0x2dencode to json_encode_setup, as after renaming, I get the
following error:
error: load_object: Symbol setup_json0x2dencode not found
json-encode
error: ... couldn't create
i'm not sure what you want to acchieve.
it seems that you are creating an object [json-encode], which (since it
is not loaded yet) will make Pd look for a file named json-encode.dll
and once it found it, it will look in the dll for an entry function
named setup_json0x2dencode.
Pd will *not* look for the function json_encode_setup().
Pd uses the library name to calculate the setup function name; a library
foo must provide a setup-function foo_setup(). a library with weird
characters, like foo-bar must provide a setup-function
setup_foo0x2dbar(). there is no way to tell Pd that it should use
foo_setup() for the library foo-bar.
so if you do want to use the new setup-function you must:
- rename the resulting dll to json_encode
- use [json_encode] in the patch.
void json_encode_setup(void) {
json_encode_class = class_new(gensym(json-encode),
so which name do you want: json-encode (as the class-name suggests) or
json_encode as the setup-function name suggests?
gfmdsar
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] bang-help.pd revision
On 08/26/13 22:25, Jonathan Wilkes wrote: Can someone with svn access make the attached change to doc/pddp/bang-help.pd for me? committed. I get the following error when I try: svn: Commit failed (details follow): svn: Authorization failed It doesn't prompt me to enter my password, and I don't feel like going on a walk through the internet to figure out what little detail Sourceforge has changed to make it harder for me to get work done. have you relocated your working directory to the new SVN root, as described at [1]? #X obj 465 20 pddp/pddplink http://wiki.puredata.info/en/bang -text what's the status of pdpedia? the link above gives me 404. [1] http://puredata.info/Members/zmoelnig/news/subversion-relocation 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-extended exectuable - packaging for Debian
On 08/13/13 23:39, Hans-Christoph Steiner wrote: Ideally, the pd-extended build system would name the executable properly, but it currently does the wrong thing. For the packaging, I think the best thing to do right now is to use a debian/install file to install the file as usr/bin/pd-extended. I think the line in debian/install would look like this: usr/bin/pd usr/bin/pd-extended this unfortunately does not work. you will end up with a file `/usr/bin/pd-extended/pd` the way it is handled in the `puredata` package is by using the standard configure option `--program-transform-name='s/pd$$/puredata/` another way would be to override the dh_auto_build target and do the renaming there. a totally untested snippet: snip override_dh_auto_build: dh_auto_build cp bin/pd bin/pd-extended /snip As for basing the pd-extended package off of the 'puredata' package, I think that is not a good idea. The pd-extended package will generate a single package called pd-extended. The puredata package generates lots of sub packages [...] ah yes, i was really mainly referring to `debian/rules` fgmsdr 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-extended exectuable - packaging for Debian
On 08/11/13 15:03, Kaj Ailomaa wrote: Never mind. I found an option during configuration to solve this problem. whatever you are doing, you might also want to check out how we do this in the puredata package (where pd is renamed to puredata) fmdsr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [pure-data:patches] #513 automake build fixes
--- ** [patches:#513] automake build fixes** **Status:** open **Labels:** puredata 0.45 **Created:** Tue Jul 02, 2013 10:37 AM UTC by IOhannes m zmölnig **Last Updated:** Tue Jul 02, 2013 10:37 AM UTC **Owner:** Miller Puckette after the latest updates in the puredata git repository (0.45.0test), the automake build-system is broken, since files have been removed from the source-tree. the attached patchset fixes this (so Pd can be build with automake again), and it also adds new files (mostly help-patches) to its install and dist targets. (hmm, seems i cannot attach multiple files at once, so i created a tgz; there are 3 patches in there: 0001 fixes the broken build system (and adds the new help-patches), 0002 and 0003 make sure that the *other* buildsystem is included in the tarballs created by make dist) --- Sent from sourceforge.net because pd-...@lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/patches/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] Makefile error in library template v1.0.14
(moving this over to pd-dev) On 06/15/13 09:21, Joel Matthys wrote: Hi Hans. The Makefile fails for Android on Linux 64 bit. I tracked it down to line 149: $(NDK_BASE)/toolchains/$(NDK_ABI)*-$(NDK_COMPILER_VERSION)/prebuilt/$(NDK_UNAME)-x86) should be: $(NDK_BASE)/toolchains/$(NDK_ABI)*-$(NDK_COMPILER_VERSION)/prebuilt/$(NDK_UNAME)-x86*) will this work if multiple toolchains are installed at the same time? (multiarch). fg,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] Fwd: SourceForge Project Upgrade
On 06/04/13 08:59, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 so while we were busy making a lazy consensus on how to deal with the sf upgrade plans, sourceforge has upgraded the repositories for us. afaik, this changes all the links to checkout/update (SVN) and clone/pull (GIT). in practice this means, that all developers should relocate their repository URLs (that is: tell their local checkout of the new location). this is how i did it, and it was rather painless: $ cd ~/src/svn/pure-data/ $ svn relocate https://svn.code.sf.net/p/pure-data/svn/trunk/ gfmsdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] info classes
On 03/08/2013 21:48, Jonathan Wilkes wrote: It is currently difficult to control audio settings programmatically from within a patch. Users might want to do the follow not really, as there has been the mediasettings library around for about two years. i think it already gives you access to all the stuff you want to do. fgmasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] building toxy
On 02/28/2013 23:25, András Murányi wrote: Hi list, I've recently built miXed/toxy for pd-l2ork successfully but now I've run into errors with pd-extended. The errors concern tot. I've noticed that they are not the same version (see the diff below), however copying the l2ork one over the extended one doesn't solve the problem but triggers different errors. Could there be an easy way out? btw, [tot] is incompatible with Pd=0.43 (be it PdX or Pd-vanilla). tot does low-level interaction with Pd's old-style GUI, which simply doesn't work any more with the new GUI. fgmadsr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] building zexy on Windows outside of pd-extended
On 02/18/2013 21:07, Hans-Christoph Steiner wrote: As far as I can tell, zexy is unbuildable on Windows unless you have the complete Pd source and you have built that source. zexy has been built on windows since 1999, without having the need to build Pd yourself. that was long before i started to use autotools, and there are still a number of build systems included in zexy that are exclusively useable on w32. c:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../../mingw32/bin/ld.exe: cannot find pd.dll collect2.exe: error: ld returned 1 exit status but i'll have a look at this. fgamdsr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Win32 - unicode support for files, with public API for externals
On 12/18/2012 04:40, Hans-Christoph Steiner wrote: I think this approach works. thanks The patch you provided seems totally untested, as in not even compiled on GNU/Linux or Mac OS X. It includes the _close() function in sys_close() which only works on Win32 and it gives this warning when building on Mac OS X: thanks for the compliments :-) i can assure you that the code is tested as in compiled without warning on gcc-4.7.2 on a debian/gnu linux (wheezy/sid) system and has been field-tested and shown to be able to load externals that the old code has not been able to load. however, you are of course right that the use of _close() is indeed an oversight, which only did not trigger a problem so far, as sys_close() is nowhere used yet. s_path.c: In function ‘sys_open’: s_path.c:450: warning: ‘mode_t’ is promoted to ‘int’ when passed through ‘...’ s_path.c:450: warning: (so you should pass ‘int’ not ‘mode_t’ to ‘va_arg’) s_path.c:450: note: if this code is reached, the program will abort the patch includes some comments pointing to an online discussion of the problem. to summarize: using mode_t in va_list will always trigger some problems. either we accept the warning (the code will never be reached, since a runtime-test will use a va_arg(..., int) instead) or we move the test to configure (autoconf). since i am the only one who seems to like autoconf, i decided for the less invasive solution. (I attached the patch for reference, it doesn't seem to be up on the patch tracker any more.) it seems that the patch has moved to the bug tracker. i moved it back to patches [1]. fgmasdr IOhannes [1] https://sourceforge.net/tracker/?func=detailaid=3596865group_id=55736atid=478070 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Patches-3584286 ] Win32: fix mouse wheel scrolling by setting the scroll incr
On 12/16/2012 21:01, SourceForge.net wrote: I've been marking bug reports as fixed when I add a patch that fixes the bug. i would expect that any patch that addresses a given bug will fix it, so marking the reports as fixed seems to be somewhat unnecessary. i guess the original idea of fixed is something along the lines of this is already fixed in current beta (as opposed to out-of-date which would mean this has been fixed 3 release cycles ago). We've been using Accepted as the status for when a page as been. so resolution would become a state machine, where a ticket could undergo several states until it finally is accepted to a Pd-vanilla release? i believe that this is probably too complicated for practical uses. fgmsdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] separate the audio-backends
On 12/09/2012 17:31, Hans-Christoph Steiner wrote: Would it be possible to provide an alternative implementation for the same API as a built-in using this? So for example, an alternate Jack or ALSA implementation in a loadable module? (iirc) the current implementation allows us to overwrite/override a given backend by simply registering another backend of the same name. so es, you could provide a bug-fixed jack-implementation without touching the pd-code. and of course, you could provide 3 different jack implementations (e.g. with different features sets) at the same time, by just using different API-names. fgmadsr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] can't seem to get new build system to work
On 11/22/2012 04:31 AM, Miller Puckette wrote: To pd-dev - I might be missing something... under Fedora 17 (the newest I believe), when I try to build Pd using the new build system I get: This is off a clean git checkout. Are there build-system patches out there that I should be applying first, or anyway, what am I missing? intall libtool. (this is only needed on people using the git-version; for any releases, configure should be pre-generated by the other, so libtool is no longer needed) fgmasr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] clearing out old build system
On 11/20/2012 04:44 AM, Hans-Christoph Steiner wrote: On Nov 19, 2012, at 5:20 PM, IOhannes m zmölnig wrote: On 11/19/2012 07:33 PM, Hans-Christoph Steiner wrote: The new build system will never work for MSVC, why? what keeps you from using autotools with msvc? I have no particular objection to someone doing it, i was merely trying to point out that a statement like the new build system will never work on MSVC is not right. fgmasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] canvasdelete search method
On 11/20/2012 09:33 PM, Jonathan Wilkes wrote: Basically combining the core functionality of the find method with the delete method. as you already noticed, the desired functionality can be achieved with 2 separate objects, one for deleting one for finding. in general i would think twice to implement any object that combines rather than implementing the different parts and let the user combine. fgmadr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] clearing out old build system
On 11/19/2012 07:33 PM, Hans-Christoph Steiner wrote: The new build system will never work for MSVC, why? what keeps you from using autotools with msvc? (sure, autotools require mingw/cygwin to run the bash-script (and once you installed mingw/cygwin, installing gcc is easy enough), but whether your compiler is gcc or msvc shouldn't matter) fgmasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] may have figured out scope
On 11/19/2012 09:28 PM, Jonathan Wilkes wrote: - Original Message - What does [local foo] do different than [declare foo]? I assume with your i would mainly object to [declare foo] because it seems to impose a hierarchy between the things you can [declare] and pushing global/local namespaces to the top, without any good reason. i'd thus go for something like [declare -localvar foo]. I'm not removing $0-- as I said my solution is backwards compatible. Replace canvas name .xblah with $0 in what I wrote and it works exactly the same. you are talking a lot about canvas, which in my understanding means, that you could have a variable that is local to a subpatch. currently $0 is local only to an abstraction and is shared between subpatches. is there a specific reason for this or is it just a slip of words? One more question that applies to any system of scoping-- how do you apply it to the message box? I forgot about that aspect when I wrote the OP. for me message local applies to local for a specific message (that is: [1, 2( | [$0-$1( could evaluate to 2352-1 and 4321-2. i see little use to that, which is probably the reason why $0 doesn't expand at all in messages. i also don't know exactly what the problem is you are envisioning. something like that? abstraction [declare -localvar read] [; filereader read /tmp/bla.txt( [r filereader] | [textfile] /abstraction and having two abstraction/s in your patch and clicking on the msgbox in one of them resulting in [textfile]: no method for local 'read' in the other??? fgasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Mouse pointer disappears over pdp windows...
On 10/25/2012 06:31 PM, Hans-Christoph Steiner wrote: The output method Im concerned with is pdp_glx but I remember same problem exists for pdp_xv... #1 i guess that the vanishing cursor is a feature rather than a bug (ever watched a visual performance where a system-alert popped up on the screen? mouse-pointers can be similarily embarassing... #2 have you tried the [cursor 0( message to [pdp_glx]/[pdp_xv]? fgasmdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] non-2^n blocksizes (was Re: [ pure-data-Feature Requests-3578019 ] I'd like to...)
On 10/23/2012 06:30 PM, Miller Puckette wrote: Hi all - block sizes in subpatches are restricted to being a power of two multiple or submultiple of the containing patch. So the only context in which a non-power-of-two blocksize is allowerd is if it's specified in the top-level patch. Then, of course, dac~ and adc~ will no longer work as they need block size of 64. yes, i'm aware of that. i only wanted to say that in real live, i haven't been able to construct a patch that would do non-power-of-two processing, even if it was in a top-level patch without any fancy input/output. e.g. claude's example patch doesn't do non-power-of-two block-processing but instead falls back to the next greater 2^n blocksize. so if somebody (miller?) could post a simplistic patch that really does block-processing with an odd number of samples, that would be great. fgmadsr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] converting OSCx to a template library
On 10/20/2012 01:26 AM, Hans-Christoph Steiner wrote: I'm not going to take on the maintenance of those patches, so just copying them into Pd-extended is not an option. I'm think Pd-extended should have an 'oscx' compatible library , and 'oscx' is already there, tested, etc. etc means known to be buggy unmaintained. i'm not arguing against OSCx because of it's architectural flaws but because it's not working as it should. mfgdsrt IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] converting OSCx to a template library
On 10/20/2012 04:17 PM, Hans-Christoph Steiner wrote: I'd happily ditch it if there was a drop in replacement. For example, I've had many students come to me with the most popular Processing-- Pd starter patch, and its based on oscx. If it wasn't include, that patch would not work at all. So buggy but working is still better than not at all. so what is wrong with my patches? they _are_ drop-in replacements. if those students use PdX (with [initbang]) one could even writen [OSCroute] wrapper. gsmdft IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] converting OSCx to a template library
On 10/19/2012 06:08 AM, Hans-Christoph Steiner wrote: Any objections? Shall I go with lazy consensus on this one? .hc On 10/16/2012 07:17 PM, Hans-Christoph Steiner wrote: Hey all, I was tired of dealing with a cryptic ./configure, so I converted OSCx to be based on the Library Template. THis is currently in the pd-extended/0.43 branch. Anyone have any objections of me removing the old OSCx and replacing it with the 'oscx' library? why would you want to keep OSCx alive? i would rather entirely remove this buggy and un-maintained (as in: upstream, not within PdX) library from any distribution. and i don't get the point of replacing OSCx by oscx. fgmadrs IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] converting OSCx to a template library
On 10/19/2012 03:02 PM, Hans-Christoph Steiner wrote: and i don't get the point of replacing OSCx by oscx. Every other library folder in externals/ is all lower case. which is a good rule for all new libraries. imho, it's a bad idea to change a given name of an old library that is still widely used. mfdg IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] converting OSCx to a template library
On 10/19/2012 03:02 PM, Hans-Christoph Steiner wrote: why would you want to keep OSCx alive? i would rather entirely remove this buggy and un-maintained (as in: upstream, not within PdX) library from any distribution. Its still widely used and still the easiest way to use OSC, albeit in a limited way. If someone makes comparably easy way to use OSC, then I see no reason to keep this one. here's 2 abstractions that implement OSCx's [sendOSC] and [dumpOSC] in terms of vanilla/mrpeach objects. [OSCroute] cannot really be implemented in vanilla due to it's multi-outlet nature. otoh, [routeOSC] is compatible with [OSCroute] (apart from the name). #N canvas 640 221 450 300 10; #X obj 50 90 udpreceive \$1; #X obj 50 112 unpackOSC; #X obj 50 134 outlet; #N canvas 266 80 631 300 check-2nd-arg 0; #X obj 149 33 loadbang; #X obj 149 55 symbol \$2-foo; #X obj 149 77 t s b; #X obj 217 121 makefilename %c2-foo; #X msg 212 20 bang; #X obj 149 149 select symbol; #X obj 237 168 t b; #X msg 181 98 36; #X obj 237 240 print dumpOSC; #X msg 237 219 2nd argument (\$1) not supported in this implementation ; #X obj 237 190 list prepend \$2; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 2 0 5 0; #X connect 2 1 7 0; #X connect 3 0 5 1; #X connect 4 0 1 0; #X connect 5 1 6 0; #X connect 6 0 10 0; #X connect 7 0 3 0; #X connect 9 0 8 0; #X connect 10 0 9 0; #X restore 257 105 pd check-2nd-arg; #X connect 0 0 1 0; #X connect 1 0 2 0; #N canvas 733 197 450 300 10; #X obj 9 47 inlet; #X obj 174 195 udpsend; #X obj 174 167 packOSC; #X msg 164 113 disconnect; #X obj 164 91 t b; #X obj 9 91 t a b; #X obj 9 69 route connect disconnect; #X obj 9 113 list prepend connect; #X obj 9 135 list trim; #X obj 9 157 t a; #X obj 174 257 outlet connectionstate; #X obj 260 228 outlet bundleDepth; #X connect 0 0 6 0; #X connect 1 0 10 0; #X connect 2 0 1 0; #X connect 2 1 11 0; #X connect 3 0 9 0; #X connect 4 0 3 0; #X connect 5 0 7 0; #X connect 5 1 3 0; #X connect 6 0 5 0; #X connect 6 1 4 0; #X connect 6 2 2 0; #X connect 7 0 8 0; #X connect 8 0 9 0; #X connect 9 0 1 0; ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] converting OSCx to a template library
On 10/19/2012 08:21 PM, Hans-Christoph Steiner wrote: That's good to have, please post and maintain that somewhere, like maybe in the 'osc' lib. But its not yet a replacement because at the very least its not deployed. i honestly dunno what you mean here. imho, if you want to make changes to the OSCx library, you should rather replace the externals with the patches i sent than replacing the autoconf stuff with template/Makefile and renaming the folder (obviously, once that is done there is exactly no reason to keep autoconf stuff so template/Makefile (or even a stripped down version if you think it too bloaded) is enough. this would deploy those objects to all PdX-0.43 installations (if this is what you mean by deploy). i figure, that the replacement patches have less bugs than the external versions. starting yet another library doesn't make sense to me (esp. since the 2 objects are almost 100% compatible (the only thing missing is multicast-group support, and i wonder whether anybody uses that). adding those patches to mrpeach/osc (if this is what you refer to as the 'osc' lib) is imo not a splendid idea either, as mrpeach/osc is blissfully unaware of the transport layer. (if martin thinks differently, he should go and add those patches) fgmsdra IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] iemguts on windows 2
seems like i missed some pd-mails in the past few days... On 06/06/2012 08:23 AM, IOhannes m zmoelnig wrote: apart from that, i think the right way would be to build Pd using the autotoolchain. afair, some tweaks are required (alas!), which ought to be documented in the mailinglist archives (look out of patco and mingw) i pushed some changes for mingw to my pd-vanilla git clone on github [1] please note that i re-based my original changeset onto the new master of miller, and had to resolve some conflicts which i couldn't test right now. fgmasdr IOhannes [1] https://github.com/umlaeute/pd-vanilla/tree/mingw ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Patches-3494768 ] verbose() leaves blank lines when filtered out in Pd window
On 02/27/12 19:34, Hans-Christoph Steiner wrote: If post(), error(), etc. are your examples, then verbose() should have no level argument, just the fmt, then it could post at level 4. That makes sense to me. If verbose() is meant to post messages at varying levels, then it should use the same numbering scheme as everything else, i.e. it's the other way round. if you insist on that, then logpost() should have the same numbering scheme as everything else: logpost(0)==post() logpost(1)==verbose(1) logpost(-1)==error() fgmadsr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] zexy 2.2.6?
On 01/28/12 03:45, Hans-Christoph Steiner wrote: Any word on this? I'd like to import zexy into the pd-extended/release branch now, but if you're going to do a 2.2.6 release soon, I probably can wait. thanks for the reminder. no i don't think that i will spend much time in the next days for a more elaborated 2.2.6 release of zexy. changes since 2.2.5 are rather small, the biggest change is actually that the build system is now more consistent (that is: i made autotools do what i expect it to do) iirc, there were some more fixes for possible bugs that never showed up but where detected by some analyser, but that's probably it. since no real features were added since 2.2.5, i do not necessarily felt the need to make a 2.2.6 release. however, right now it says 2.2.6 everywhere and if it makes you happy to have the hottest zexy in pdx you can brand it as 2.2.6 :-) the current SVN snapshot (which already says 2.2.6) is considered stable, so taking a snapshot will actually be 2.2.6. fmgasdr IOhannes PS: oh, and please don't add random release numbers to files like zexy-meta.pd; i reverted that change ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how to load shared code for libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/29/2011 04:35 PM, Hans-Christoph Steiner wrote: These things are really all by design. This makefile template is not trying to be all things to all people, but instead provide the easiest solution for 98% of the cases. By not handling that 2%, it can be make much simpler for everyone else. - SHARED_SOURCE is lib$(LIBRARY_NAME).c, if you need multiple files, you need to modify things but why is it then that the SHARED_SOURCE is assigned with ?=, indicating that the user should be able to set the files to whatever fits their needs? why is it not documented? - the shared lib name is deliberately standardized, therefore its not settable the thing is, it is _not_ standardized, it uses whatever SHARED_SOURCE is set to (and replaces .c by .$EXT), which is settable, and therefore can be set to multiple source files, making the template/Makefile simply not work. it is exactly my suggestion to standardize it to lib$(LIBNAME).$(EXT). This means that a dev can easily tell whether a lib contains a shared lib, and where its source code is. Its self-documenting once you know it. You just look at the file system, and you know where things are. what is wrong with my suggestions? i really have the feeling, that it is mainly rejected because the suggestion comes from me (e.g. not trying to be all things to all people basically boils down to please don't fit into IOs little world) mfgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6tsAIACgkQkX2Xpv6ydvTTAQCgzDzTF5H8kD2m6tC1z86qZJBU z2UAnjvqmqUEepOu15iRGSMCf2SRuwLc =T8AA -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how to load shared code for libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/30/2011 09:13 PM, IOhannes m zmölnig wrote: it is exactly my suggestion to standardize it to lib$(LIBNAME).$(EXT). to be more precise, my suggestion basically contains exactly 2 suggestions: - - rename *_SOURCE to *_SOURCES (for consistency) - - standardize the shared library name to lib$(LIBNAME).$(EXT) that is all. if it helps, try to forget that with these changes I could use the template Makefile as is. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6tsj4ACgkQkX2Xpv6ydvTwYgCdE4KAMMVZWfD2uMncxOgpn1+1 1esAoKKl4HJYsIk922pB1bCzg7eDiMCk =xiGT -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] building iemnet on Windows and OS X
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/28/2011 09:58 PM, Roman Haefeli wrote: Hi Hans, IOhannes I don't have a clue what MSG_DONTWAIT is. I think I need some help (from IOhannes?) to get this one fixed. it's a (linux-specific?) extensions for non-blocking socket receivers. the problem should be fixed now (by only using MSG_DONTWAIT if it is available) Altough I had the same error once on Linux (I didn't do 'make clean'), it doesn't happen in the Linux autobuilds, probably because the pd/src directory is clean at the time of externals build. Hints/help is appreciated. hmm, i think the problem is a stupid error-checking condition in gcc, that guarantuess that you only specify directories as include directories. i have never seen this on linux, so it might be an osx specific feature. a simple fix would be to remove the '-I$(PD_INCLUDE)/pd' stanza. i'm a bit reluctant to commit this, as i would first like to understand why the compiler thinks it an error when specifying an include-directory that is a file (but not, if you specify an include-directory that is non-existant) fgmadrs IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6rpZ4ACgkQkX2Xpv6ydvRr/QCfZqvyzy4XFepFP6ucpdmJ6Hj+ uNAAn2Ya6AeNclfmL87goP5BAzsof0WG =OSPY -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how to load shared code for libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2011 01:29 AM, Hans-Christoph Steiner wrote: I committed the change to tkwidgets and the template/Makefile. i tried to use the new template/Makefile for this feature and noticed a few issues: - - object sources are called SOURCES, whereas shared sources are called SHARED_SOURCE (singular); same goes for SHARED_HEADER for consistency sake, i propose to use plural throughout. - - the output name of the shared lib cannot be simply overridden (it derives from the value of SHARED_SOURCE) - - using multiple C-files for the shared code, doesn't really work: it tries to create a shared library from each C-file (so if you SHARED_SOURCE=foo.c bar.c, you will end up with both foo.so and bar.so, and your objecctclass will link against all those. it seems like you only used a single C-file library, but i guess a number of libs will also want to use multiple C-files for building a single library, which should then be linked to all objectclasses. (this get's you all the features from creating a shared lib from each SHARED_SOURCE file, and additionally allows the shared code to share code with itself) therefore i propose a few small amendments to template/Makefile: - - rename SHARED_SOURCE to SHARED_SOURCES - - rename SHARED_HEADER to SHARED_HEADERS - - build all shared sources into a single library - - as default name, use lib$(LIBRARY).so for this library - - allow the user to easily override this name, if they want to mdfgt IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6sDQYACgkQkX2Xpv6ydvQ0NwCfdueDX+0KTaI9sWqlf4c0oCjT 4r4AoLfBVdAVi2qryleXQEKFVomDDeZ/ =Nn0u -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-double: how to selectively build external libs for development?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2011 06:31 PM, Hans-Christoph Steiner wrote: If pd/src/m_pd.h is the only thing that loads pd/src/config.h and m_pd.h does #include config.h, this is not a problem. GCC looks for headers requested with #include file first in the directory containing the current file. http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html please keep in mind that it should work not only on gcc. config.h is the standard name for the header generated by ./configure. I think they probably have thought of the above issues. sure. i think you misunderstood me. i'm totally fine with Pd using config.h for the normal configuration output. however, i am strongly opposed to distributing and installing a generic config.h as generated by configure. no sane project i know does this. the only project i ever encountered where a generated config.h file was shipped was libavifile on debian. it severaly broke other builds that used autoconf/config.h so to reiterate: please do ship a file that contains the correct PD_FLOAT_PRECISION define. please never ship a file that contains generic autoconf definitions from the build machine, like HAVE_SYS_IOCTL_H. therefore, please do NOT put the defines for PD_FLOAT_PRECISION into the same file as the generic defines as HAVE_SYS_IOCTL_H. fmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6fE3gACgkQkX2Xpv6ydvRI8wCeMJZ+Kb/lfdWMTnQQmxAYUNmV vckAoNpOOKMnJQEHh1wLrgDP7SkfXp6j =re6+ -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Mac OS X 10.5 vs zexy's autogen.sh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/05/2011 11:03 PM, Hans-Christoph Steiner wrote: Perhaps your zexy scripts are modifying the build environment? It first why do you think so. have you read my email? fmsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6Oq34ACgkQkX2Xpv6ydvSO1wCgsb7qgpWLr/6Gf0I9O6DwjfmF 8dQAoPWp5gi5kkS+sJKvcRaFi2vjmvdX =wtKD -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] double precision Pd: .patch files, tests and benchmarks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/05/2011 12:40 PM, katja wrote: On Tue, Oct 4, 2011 at 11:38 AM, IOhannes m zmoelnig zmoel...@iem.at wrote: the proper way is to use CPPFLAGS=-DPD_FLOAT_PRECISION=64, But now you undo the CPPFLAGS as defined in the makefile. I didn't know how to add to the CFLAGS from the command line, but found a solution here: http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_66.html#SEC65 It requires a small adaptation to the makefile. Instead of: CFLAGS = comes: override CFLAGS += . Now you can add to CFLAGS from the command line, like so: make CFLAGS=-DPD_FLOAT_PRECISION=64 Note that the CFLAGS in the makefile now have precedence and you can only add to it from the command line, not override it. i don't get the point here, since CPPFLAGS is not set in the Pd Makefiles, so setting them to outside should have no weird sideeffects, whereas CFLAGS does. ah, on closer inspection it seems like you are building Pd with the old autoconf system (pd/src/configure.ac generates pd/src/makefile), whereas i am using (and talking about) the newer autotools based build system (pd/configure.ac generates pd/src/Makefile) afaik, this is the build-system used in the nightly builds (apart from w32) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6MshUACgkQkX2Xpv6ydvQkHwCg5ld9exXjKmAsIHbbINmPJZkp kxIAn1bEYE/kKTVCsXM3D0zKLMqXr+So =UNU0 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Mac OS X 10.5 vs zexy's autogen.sh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/05/2011 09:18 PM, Hans-Christoph Steiner wrote: On Oct 5, 2011, at 12:45 PM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-10-05 18:16, Hans-Christoph Steiner wrote: On Oct 5, 2011, at 4:05 AM, IOhannes m zmoelnig wrote: The logfile I see says its set to: PATH=/usr/bin:/bin:/usr/sbin:/sbin:/sw/bin:/sw/sbin http://autobuild.puredata.info/auto-build/2011-10-05/logs/2011-10-05_03.15.09_darwin_macosx105-i386_pd-extended.txt the same logfiles also says: PATH: /sw/bin:/usr/bin:/bin:/usr/sbin:/sbin:/sw/bin:/sw/sbin Ah, I see, where you post it in zexy/autogen.sh. But the build environment has: PATH=/usr/bin:/bin:/usr/sbin:/sbin:/sw/bin:/sw/sbin yes, i was trying to explain that (zexy's, but also Pd's) autogen.sh prepends the /sw/bin/ to the path manually. which suggests that your libtool setup is broken :-) you could try comparing the ./libtool generated on your machine and the one generated on the PdLab machine. seems so, I did a reinstall and 'svn up' and it now builds on my machine. ah cool so at least OSX world is happy again :-) vmadf IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6MswkACgkQkX2Xpv6ydvT4yQCeMUN2pt5dUtRmXg4wo5JVIBjd zBAAn0Vh/NyktKwaKbQJHaeGwP+MvI6i =4aqE -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Patches-3417757 ] better install instructions to pix_opencv
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/2011 10:00 PM, lluis gomez i bigorda wrote: hi list, it's a long time hope you all are doing well :) sorry no previous experience with Tracker: just a question, what's the suposed way to act in such a tracker task ? I went to the patch view and just changed the Resolution field as Accepted ... it's supposed Tracker should apply the patch automatically ? or I must download the patch and make the commit myself? you have to download the patch, apply it to the sources, (inspect the changes) and commit it yourself. the patch tracker is really only to have a central place where people can give you chores... fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6LaK8ACgkQkX2Xpv6ydvQPpACeJk/xzUWDgP7dDLXU51GUIbYi MboAn1mgRoVnSM06xYp+oSUaRV9fKAFz =Qdz6 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] zexy: libtool: link: only absolute run-paths are allowed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/30/2011 08:23 PM, Hans-Christoph Steiner wrote: I tried --disable-rpath, but it said it wasn't a ./configure option. Its a recommended thing for MinGW: the --disable-rpath flag comes from the macro AC_LIB_RPATH (currently not used in zexy, hence it doesn't work) AC_LIB_RPATH seems to be shipped with gettext, and iirc there have beensome issues with gettext on some systems (of the PdLab??) if you think it is ok to havve this additional dependency, i might just add the macro. gmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6HQnYACgkQkX2Xpv6ydvThKwCffXLu7VlT+H8qu+bdTZ8NnrAq 31sAniUv1sAym+q/6yoE3Wk2WfiIJtDS =ZGgV -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] patch tracker licenses (was Re: Unit tests)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2011 10:43 PM, Jonathan Wilkes wrote: Pd Vanilla is 3-clause BSD, and according to IOhannes so is the stuff on the patch tracker. just for clarification: i did not intend to say that. instead i wanted to say that stuff in the patch tracker is (assumed to have) the same license as the code it is applied to, unless explicitely stated. mfgasdr IOhannes PS: some more examples (though it's probably clear anyhow) if you create a patch for Pd-vanilla and you don't mention a special license anywhere, you are implicitly licensing your stuff under BSD-3 (Pd-vanilla's license) if you create a patch for zexy, you are implicitely licensing your stuff under GPL-2+. if you create a patch for Pd-extended, things are a bit more complicated, and i would assume that the implicit license applies to the part you are actually patching. there is hardly any code that is Pd-extended specific, as PdX is mainly a collection of loads of packages. adding to the confusion is, that there are patches (form the patch-tracker) that are in Pd-extended but not upstream (Pd-vanilla or some externals) e.g. my initbang patch is included (afaik) in PdX but not vanilla, but it is really a patch for vanilla and thus implicitely licensed under BSD-3 rather than GPL-3+. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6FkgMACgkQkX2Xpv6ydvS4BQCfecSXIMtbKISQOhqr7Au8iOgP 39YAnio2P3Ik8eCZxnITSOp34lF6TU8w =BDZv -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] symlinks in zexy svn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/30/2011 04:50 PM, Hans-Christoph Steiner wrote: Now I see the root of the unfold-help.pd issue, zexy relies on symlinks that are checked into svn. That'll work fine on UNIX, but is very unpredictable in Windows. For example, a Windows svn client might check them out by copying them. A cygwin svn client might check them out directly, but then cygwin has its own symlink format which is compatible with Windows shortcuts. Then MinGW does not have a native SVN client packaged, so if you will get different results depending on whether you use a Windows or Cygwin svn client in MinGW. which is arguably a bug in cygwin... i was relying on the svn documentation [1] that claimed that on windows syminks would be checked out as (copy) files. I think the build system should create the links using $(LN_S). That i switched the build-system to that after i gt your original email about unfold. will work in a consistent fashion in all of the above situations. On Windows/MinGW, it'll always copy, on Cygwin it'll make the special Cygwin symlinks, and on UNIX it'll make standard symlinks. how is this consistent fashion? it will hopefully get us working with the current setup on your build machines, but will break for cygwin compilations (if i understand your explanations correctly) mgasdr IOhannes [1] http://subversion.apache.org/faq.html#symlinks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6F208ACgkQkX2Xpv6ydvTdTwCfV6E1rdxbDVzrH15h+E4fCzpw /kkAoIKOHZA/BHdMnCkNCp0Zg3P0PYMY =oPPw -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] symlinks in zexy svn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/30/2011 05:17 PM, Hans-Christoph Steiner wrote: platform. I'm not sure how Cygwin's svn handles symlinks, all I am saying is that managing symlinks in SVN is not really useable if you want to target Cygwin and/or Windows. afaik, managing symlinks in SVN is fully possible if you want to target windows (proper), as you will then get copies of the files (no symlinks, no shortcuts, no emulations), which is what i expected and which would have done no harm. It is consistent on each platform, i.e. MinGW builds will be the same no matter how they were checked out. Its definitely not consistent across platform. well, i guess that with this constraint, managing symlinks in SVN is consistent on each platform as well. afaik, mixing mingw and cygwin is to be considered across platforms, which is where our problems come from (because the checkouts (including symlinks) where done with cygwin and the builds done with mingw (not knowing how to handle cygwin's symlinks) anyhow, nevermind. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6F3zEACgkQkX2Xpv6ydvTrxgCg6mm9g34guWuN3ii7ZGJBwom7 fI8An0afVRqUAz7BifYPKSKIsjRhDDhC =/du9 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] zexy: libtool: link: only absolute run-paths are allowed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/30/2011 05:20 PM, Hans-Christoph Steiner wrote: So with all the hassle over symlinks, there is a different issue stopping things on MinGW. This seems to be the exact same issue as Gem was having. You can see the environment of the build in the build log, if that's useful. would it be possible to get the svnversion in the logs? fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6F4TwACgkQkX2Xpv6ydvSwxACgx1iYBnpuUbXyd6YSPtHgoErc DV4Anj+bidMhMfxJvb3A9MS/SmyZO3xZ =EifS -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] zexy: libtool: link: only absolute run-paths are allowed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/30/2011 05:20 PM, Hans-Christoph Steiner wrote: So with all the hassle over symlinks, there is a different issue stopping things on MinGW. and how does this relate (e.g. timewise) to your other mail saying Zexy installing .a instead of .dll on MinGW? this gave me the impression that at least one compilation succeeded (though it produced a static binary rather than a shared library) fgmar IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6F4bUACgkQkX2Xpv6ydvS57ACgr62d4sTxmxbljl0aI0WXl7XD 7YAAoN2TQJ6+uGdhTf5KFCNwGPUq0oBF =iF0/ -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] zexy: libtool: link: only absolute run-paths are allowed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/30/2011 06:08 PM, Hans-Christoph Steiner wrote: pddev@windowsxp-i386:~$ svn --version svn, version 1.6.1 (r37116) compiled Apr 11 2009, 12:07:06 thanks. however, i actually was trying to ask for the svn-revision of externals/ (which you get by running svnversion within this directory), in order to be able to check which commits are already in action when the build is running. Its the same issue as with Gem. So running it from the command line alone without setting any variables, it builds. another reason to fix it properly. But running in the whole build, where lots of variables like DESTDIR, prefix, etc. are set, it doesn't work. does running from the command line mean: $ cd externals make zexy or does it mean $ cd externals/zexy ./autogen.sh .configure make e.g. is the problematic environment within externals/Makefile or within the entire build system? if the latter, do you have any recommendations how to start such a build (preferably with only the zexy part, so we don't have to wait for ages) in a debugging session? fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6F64UACgkQkX2Xpv6ydvSXUgCfQxPQznBmPG0yGevBwYbujgTV r60AnAqmV0pIOs4Xp6XkQdE/RNG3Djfa =d0Zh -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how to load shared code for libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/28/2011 03:07 PM, Hans-Christoph Steiner wrote: Ah, ok, that changes things. So you are sure there isn't a way to make this work? on, i'm not sure. i only reported issues i came across. If so, do you think there are other shared library techniques you think could work? i hope, but i do not know. Otherwise, it looks like we are back to my original manual dlopen() proposal. i'm still no friend of this. i'm afraid that all real-life solutions that involve dlopen(), will require significantly more code to be crammed into each external (only to make this work) than will be put into the shared code library. which would make the entire attempt futile. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6EFQEACgkQkX2Xpv6ydvQcvQCgwSJMhcdwtNWxQb7LGQErvasj vwoAniMZ3STo6PqzBrziFTj8xmPvhyyE =9DAJ -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how to load shared code for libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/26/2011 06:52 PM, Hans-Christoph Steiner wrote: IOhannes and I were discussing how to load shared code for a libdir on IRC. The sticking point is that Mac OS X seems to require dylibs to have a hard-coded path. IOhannes posted a test lib to try to work out how to do it using DYLD_LIBRARY_PATH: http://iem.at/~zmoelnig/OSX/test.tgz So here are my results from Mac OS X 10.5.8: creating a [test] object: - /private/tmp/test/tmp/test.pd_darwin: dlopen(/private/tmp/test/tmp/test.pd_darwin, 10): no suitable image found. Did find: /private/tmp/test/tmp/test.pd_darwin: unknown required load command 0x8022 test ... couldn't create hans@dhcp-10 tmp $ ~/code/pd-extended.git/src/pd -noprefs -lib test --- ./test.pd_darwin: dlopen(./test.pd_darwin, 10): no suitable image found. Did find: ./test.pd_darwin: unknown required load command 0x8022 test: can't load library just to clarify a bit: the binaries posted under the link above were compiled under OSX-10.6, without any precautions for backward compatibility. they don't work on 10.5, nor 10.4 i also put the same set of binaries online, but this time compiled under 10.4, and they work and function as expected under 10.4 and 10.6 (and i expect them to work on 10.5 as well) on w32, the search paths for dll's should be modifiable via the %PATH% environment, whereas on linux (and most i think BSD and hurd) the envvar in question is LD_LIBRARY_PATH after the technical details, let's step back and have a look at what this is all about: the main motivation is to be able to bundle shared code and 3rd party libraries with externals. the dynamic linkers of the various OSs, will automatically search for dylinked libraries your external depends on, in various places (e.g. /usr/lib). this is great if you have an easy way to install the needed library into this place (e.g. a dependy-informed installer system like debian's apt). it's not so great, if you don't have such a system, and the user is expected to find and download the given dependencies and put them into your system's search path. even if an external ships with all dependencies, they still have to be installed in the correct places, which makes installation more complicated than just dragging a folder onto your desktop. why? because your OS's dynamic linker doesn't look for 3rd party libraries in weird places like a folder on your desktop. now the idea, hans and me came up with, was to make Pd tell the OS to look into those places. e.g. if library foo.pd_darwin gets installed into ~/Library/Pd/foo/, then it would be nice, if the dynamic linker would search for any depending libraries in the ~/Library/Pd/foo/ directory. likewise bar.pd_linux (installed in ~/my-externals/pub/) might have it's dependencies searched for in ~/my-externals/pub/. if both foo and bar depend on libdudelsack, and both provide a libdudelsack.dll in their homedirectories, then of course we want both libraries to choose their correct one. so the idea is, to modify the automatic search path of the dynamic linker whenever a library is loaded. example: the user installs the frotzel library, by downloading it, and unzipping it into /usr/local/pd-externals/ now, if the user requests a new object [frotzel], Pd will search for a matching binary and eventually find frotzel.l_ia64 in /usr/local/pd-externals/frotzel/ before dlopen()ing this binary, it will read the LD_LIBRARY_PATH variable, push it to some stack, and then add /usr/local/pd-externals/frotzel/ at the beginning of the LD_LIBRARY_PATH. it will then dlopen() the frotzel.l_ia64 binary, and the linker discovers, that it has to load the libknurbel.so library, which it will (magically) find in /usr/local/pd-externals/frotzel/ because all dependencies are fullfilled, [frotzel] will successfully be loaded and will work. after fortzel.l_ia64 has been successfully loaded, we no longer need to search for libraries in /usr/local/pd-externals/frotzel/, and therefore the original content of LD_LIBRARY_PATH is restored (popped from the stack). the exact name of LD_LIBRARY_PATH is system dependent, but it seems that LD_LIBRARY_PATH, DYLD_LIBRARY_PATH and PATH cover most systems. fasdmrt IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6Ax4MACgkQkX2Xpv6ydvTbrQCePMZCWLbqBNAGe18J5Lbwj2a4 aLIAn25HcmduV4mJgMUG+dH/XOJHWjCL =07As -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/19/2011 08:33 PM, Patrice Colet wrote: hello, I've attached the patches that make working libtools with msys, but there is something I couldn't resolve, all the PD__CHECK shows synthax errors so those lines are under comments, maybe you could help with this? which syntax errors? did you run autogen.shh (or equivalent) to get the macros in m4/ included in your aclocal.m4? the diff is made with files from git repository, could you also suggest an easy git manager, or an url to find some documentation for windows, thank you. i found TortoiseGIT very easy to use (esp. if you are used to TortoiseSVN and the like) please also note, that there is no makefile.am in Pd's tree, there is only Makefile.am: many filesystems are case-sensitive mfgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5P7XoACgkQkX2Xpv6ydvRqMgCdE0DEwwEjjJMLVyIrOQziKypW Qd8AoNc/mwbgq85LQ2hY7anKFciwqtMT =C1L9 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] preparing phasor~Co. for double precision Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2011 01:04 PM, katja wrote: Since I am not familiar with this part of Pd code, my proceedings are slow and I've not found the time to scan s_audio_jack.c, s_audio_alsa.c etcetera for similar issues. Yet, on the dsp side of things, I feel we're close to a properly functioning double precision Pd. i had correct output using double precision samples using (iirc) ALSA and jack, back then when i started the patch set (which eventually made it into Pd-0.42), so that shouldn't be a problem. looking at the code, the relevant changes are definitely there for jack; and alsa will most likely work if it's not trying to do mmap() - if the device does support mmap we might have problems. distributed as stable release, whenever that will happen. And this protection must preferably be backwards compatible, in such a way that old Pd installations from the 'single only era' can not accidentally load new double precision classes. totally true. fmgsadr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk40D24ACgkQkX2Xpv6ydvSWVACg2WVSLxH+BdHmOF4dlLqmkxwm yDEAoIwLp9IWpRUFSlpovmtTDr2sjnQl =F4Hv -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] preparing phasor~Co. for double precision Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/28/2011 02:15 AM, katja wrote: I was looking for a suitable spot in the code to do this. First looked at dac~, but since there may be many dac~s instantiated this is not most efficient. Then I found sys_send_dacs(), where the integrated sample values are checked for max absolute value. It is however not possible to do a simple typecast here because samples are just stored back into *sys_soundin and *sys_soundout which are type t_sample. Maybe dac~ should integrate samplevalues in an intermediate vector of type t_sample. And then, in sys_send_dacs(), integrated samples could be checked, cast to float and stored into *sys_soundout vector of type float. And something similar for the input. That's what I'll try. imho, the only sensible place to do this is the actual audio backend code (s_audio_*.c), since your audio backend might support double floats (e.g. jackd is prepared for that already, though i don't known whether anybody ever used it that way). you don't want to do the calculations in double, then convert to single only to output as double, do you? fgmadr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4xMXsACgkQkX2Xpv6ydvRedACeLQ+kcKMaXRwz4n6p2Dquje4P 118AoKXn+0TMlRKSO7VPrc9HOZO/Vu88 =X+v+ -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] preparing phasor~Co. for double precision Pd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/27/2011 11:11 PM, Hans-Christoph Steiner wrote: like you've covered that already. As for 64-bit floats to output, a quick hack to get things working is to just hammer samples down to 32-bits... i don't think that's such a great idea. loads of problems (mainly with granular synthesis or other applications where you want to access large tables sample accurately in the signal(!) flow) can simply be fixed by making signals be 64bit too. and then, quite some infrastructure code makes no clear separations between t_float and t_sample, so it might be simpler to make Pd use doubles throughout and not just for one type of numbers. gfasdrm IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4wh34ACgkQkX2Xpv6ydvQAnwCeNee8gJz1xUgo5IorIB9JPLXg fD0AnidU8L4v1WB1VZpQADshUZ5BlUko =RzYs -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] async callback?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/21/2011 09:26 PM, Louis-Philippe wrote: Hi PD-Dev Peoples, I was wondering how I should deal with async callbacks inside an external? What I have in mind: 1. message sent to external inlet 2. external proceed to trigger some blocking io with async callback 3. external sends trigger status on outlet 4. ticking continues 5. the blocking io answers with the callback 6. the external sends result to outlet as result of callback anybody has a take on these? i use this quite a lot, most prominently probably in Gem (which has a big code-base; a good start would be Gem/Workerthread.cpp and Gem/SynchedWorkerThread.cpp) and in iemnet (much smaller; in C) the callback-code usually looks like: 1. push the data retrieved async into a (threadsafe) queue 2. notify Pd to do a sync callback using clock_delay(x, 0) note that clock_delay itself is not threadsafe (there is a patch in the sftracker), so you have to protect it using sys_lock() and sys_unlock() 3. when Pd calls back within the main thread, pop the data from the queu and send it to the output a more (too) naive way would be to just run outlet_foo() from within the async callback and protect that with sys_lock()/sys_unlock(); which is usually less performant as the above, esp. if the async callback might be called quite often. a more elaborate way would be to reduce the calls to clock_delay() even further (as you don't need to call it again, if it has already been called and not reacted upon yet) in general you have to be aware, that virtually all functions in Pd are not threadsafe (e.g. don't use gensym() from within your async callback!), and the only way to deal with that is using the BIG KERNEL LOCK with sys_lock() / sys_unlock() fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4q03IACgkQkX2Xpv6ydvTmjACgrea3jIOAnM8LbKl4KEvjrZZl ZdYAn3owpmIY7ydzYgAlnudX5fntqo0F =QZQ6 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] replace spaces in list class names with hyphens
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/14/2011 11:55 PM, Jonathan Wilkes wrote:
I've got a working tooltip prototype going, and I just noticed that all the
list classes screw up things on the tcl side, because with list append (for
example) it suddenly looks like there is one more arg to the proc.
Are there any other objects that have a space in the creator name? If not,
could we just make it official that creator names can't have spaces, and
change all the list foo creators objects to list-foo?
This would be transparent to the user*, since they can still type list foo
and list_new will instantiate the right class. (Although going forward I
would suggest using list-foo as it is the standard for all the listabs
abstractions.)
while i was always opposed to using object names with spaces [1], i
don't think that we should forbid it at all. i would rather have the GUI
side have an idea of what is the object name and what are the arguments
(e.g. create {list split} {1} rather than text list split 1) than to
add arbitrary limitations.
some externals use proxy objects for full-fledged non-first inlets,
and those proxies tend to have hard to type names as well. how do your
tooltips deal with those?
gfmasdr
IOhannes
[1]
https://sourceforge.net/tracker/index.php?func=detailaid=1544083group_id=55736atid=478072
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4f984ACgkQkX2Xpv6ydvTpDQCcDJRCiMa6Ai9IYvFNp84wJCJY
EyMAoIhuOhVq2Sra+Uhi8DOpZ8az1cLg
=XO7J
-END PGP SIGNATURE-
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pdextended 0.43.1 and vista
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/01/2011 08:40 AM, Patrice Colet wrote: needs to figure out how to do the final linking using g++ to link the C ++ ASIO files and C files from the rest. why not using cc for compiling portaudio files, because you need a c++ compiler to compile c++ code. and you need a c++ linker to link with c++ objects (such as the portaudio objects) the trick to use g++ for linking, is to use a dummy .cpp file, so autotools will automatically choose g++. something like: snip nodist_EXTRA_pd_SOURCES= if PORTAUDIO nodist_EXTRA_pd_SOURCES += dummy.cpp endif /snip fgmsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4NjoEACgkQkX2Xpv6ydvTuOACdFHGNF2qVQz+TbvgjXDHSisjH YHQAnjK/SViMF1aXY51Bi59UmgezhFxR =u+vA -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] signal nan values
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/22/2011 01:31 PM, Andrew Hassall wrote: or could it just be other problems with the audio setup (I still haven't got the pd audio settings correct on ubuntu, but it still manages to process input from the mic). given that valgrind produces an error each time lpcsynthesis_tilde_perform() is called and that hundreds if not thousands of people do not experience spurious crashes with their Pd that are related to (improper) soundcard settings, i would say it is your code (or whoever wrote lpcsynthesis_tile_perform()) fgmadr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2xlUkACgkQkX2Xpv6ydvRNqQCfVCy7CMQFrRP4Mgvx1NVyl1xQ nNsAnj2mVM9z/Row1qN/xeJGZrfYhZY9 =OiXz -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] working pd-ext 0.43 build on windows?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/12/2011 01:46 AM, Hans-Christoph Steiner wrote: Part of the idea is that people can make CPU-optimized versions of 'vanilla' and load them as they need them. So they shouldn't be locked in to using 'vanilla', or I would have just left those objects built-in. i think a better approach (than to have no [f] object) would be, to automatically load the std library until explicitely requested not to do so. e.g. add a -nostdlib flag to disable loading of the vanilla library. this seems to be perfectly in line with the current set of flags, and minimizes problems with 99% of the users fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2ktFoACgkQkX2Xpv6ydvQ9lgCfXVFk4y+IGUzv8j702XNKmaFe AZgAniRcxWSlSAh9vuC+8x1mkq9c4xEo =sv01 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] working pd-ext 0.43 build on windows?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/13/2011 05:11 PM, Hans-Christoph Steiner wrote: That is not quite a good analogy. The existing method was there: a folder that was searched by default called path/to/pd/extra. You did not need to specify -path path/to/pd/extra. ~/pd-externals is just another folder in that same list of folders to search. i think it is a good analogy. objects are loaded by default (vanilla set of objects). afair, you never needed to import vanilla to create [f]. however, what my analogy is really about is, that there is a startup flag -nostdpath which will _prevent_ path/to/pd/extra to be searched for objects. hence my suggestion to load vanilla by default, and add a flag -nostdlib to prevent loading of this if you need to. removing the core objects from Pd seems a more aggressive assault to people's workflows than having them manually add some standard search paths. either you do make exceptions or you don't. I want nothing aggressive or assaulting. i appreciate that and i admit that using both aggressive and assault was a bit of an overshoot. The idea is to solve problems like: - wanting use a SIMD-optimized version of the core objects for things that need it a) i fully understand and support this. b) i don't understand how my suggestion breaks with your idea. you can always do a -nostdlib -lib chocolate to replace vanilla with stracciatella. c) i don't understand how this is not possible with current Pd. as has been shown numerous times that you can simply override existing objects. cf. zexy's [pack] and gf's [print]. basically it seems that you are proposing something complicated to achieve something that is just there. - ability to use the new GUI/editor features while maintaining compatibility with older versions of Pd (i.e. steps towards the separation of the editor and the runtime). i'm all in favour of separating editor and runtime, and providing cool features. i fail to see how this is accomplished by forcing people to load core objects (and in fact leaving them with a bare, non working (for about all of the people) version of Pd) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2l2OQACgkQkX2Xpv6ydvTiWwCfau5m8eVO0nBFgBOx+X9+653w lkkAoIoOI7PJHDdjHsF5ck+ShSjmjp97 =RNDe -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] svn-repository general question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/19/2011 10:58 AM, Ingo Randolf wrote: and... another post... ;) i have a question to the svn-repository... in the subfolder ./trunk/pd i can read the INSTALL.TXT file... which tells me to make a ./configure in /trunk/pd/src ... this INSTALl.txt is a) outdated b) meant for the source release(!) rather than an SVN-snapshot the latter means: it is considered bad style to put anything generated (mostly binaries, but also scripts, like configure) into VCS. hence configure (which is generated from configure.ac) is missing in the SVN. to generate everything needed in order to run configure (btw, nowadays this is in .../pd rather than .../pd/src) just run (in .../pd): $ ./autogen.sh fgasdrt IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1fq2sACgkQkX2Xpv6ydvRumACeN/HeNCS/kNSSkUU34HnlvR9m Xy0An2C7HGUzs7j2gAFEg85KelHs2yLb =Kh1U -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] svn-repository general question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/19/2011 05:29 PM, Ingo Randolf wrote: Hello thank you for the answer. b) meant for the source release(!) rather than an SVN-snapshot the latter means: it is considered bad style to put anything generated (mostly binaries, but also scripts, like configure) into VCS. hence configure (which is generated from configure.ac) is missing in the SVN. so, since autogen.sh is also a script, it is not included in the svn-snapshot...? ah no, you got me wrong. scripts can are often included in the VCS, but only if they are original code, and are _not_ generated automatically. configure is such a generated script (it is generated from configure.ac and some additional m4-macros using autoconf) autogen.sh, otoh, is an original script (not-generated), hence it is included in the svn. where do i get those scripts from...? copying them from a source-release? copying the snapshot-sources into a source-release?? no. the idea is that the VCS includes all the source code, and you can generate everything with the right tools (gcc, autoconf,...) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1gCqMACgkQkX2Xpv6ydvQOWQCeJeGla6Pyn6S46+R10KBzk2Ra EEAAoNdvwhgDSLIa23bruIVsBgbfIlXM =qlqa -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Access to PD SVN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/2011 01:56 AM, David Doukhan wrote: Hum... it seems my account has not been added yet... added now. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1NFCoACgkQkX2Xpv6ydvQZ4wCeLqx66fvTw5KjLxMvf2JcLLGS rHgAn0f6uqV/6aPabfyUc5PJmU7OaCmi =teG5 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] about [tcpserver] (mrpeach and iemnet)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/09/2010 10:28 PM, Roman Haefeli wrote: @ IOhannes Though I like this 'stable'/reliable behaviour of iemnet's [tcpserver], I wonder what happens, if it keeps sending data to the unreachable client. Will it just go on and buffer everything until the whole RAM of the computer is consumed? If so, wouldn't it be more wise to just disconnect that client at some point in order to avoid the box running out of memory? you can query the fillstate of the buffer from within the patch and act upon that: if you prefer to disconnect after 300MB (because of the 2.5GB memory you have, 2GB are only swap), or if you rather go and crash or whatever...it's up to you. fgmsadr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0B/QYACgkQkX2Xpv6ydvRTTgCfQDHGkqJ0dY+PqMjHYyNNAe7n QWoAoPTwqZoea4qC3G+KbgQ2W61fWRLt =QHsl -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] about [tcpserver] (mrpeach and iemnet)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/10/2010 04:54 PM, Hans-Christoph Steiner wrote: A 300 MB network buffer! That sounds scary. i thought i made it quite clear that it is up to the user what they want. i find it far more scary to tell people what the might want (e.g. network buffers that are 1MB big, because some upstream author thought that i might get scared if it was any bigger. fgmadr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0CcD8ACgkQkX2Xpv6ydvRKJwCggLYsNWNOJu7B8Z9PWVbtyhly WbQAnR9hRQMdC91UzrvJAV73MG+dWbbB =7ABL -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing non-free code from pure-data SVN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/08/2010 09:10 PM, Hans-Christoph Steiner wrote: So the question is: should we remove pidip and unauthorized from the pure-data SVN? are there any problems already? are we talking about bullying and bashing on the sole grounds of as far as i understand? first, i would leave all code within the repository, until someone who has a claim complains. after that, the first code i would want to remove is all the unrelated code in /vendor and /source. fgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz/7UEACgkQkX2Xpv6ydvQbsQCgiqtwy1/2oLPl0gZfwisqQ+nC GisAn2ARZuDvx9ud16Pq9wSCGDHdOlJ0 =P7rh -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] general makefile question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/01/2010 06:16 PM, Hans-Christoph Steiner wrote: On Dec 1, 2010, at 12:00 PM, IOhannes m zmoelnig wrote: this is such a fundamental thing that i'm sure there has to be an elegant solution to this but i never came across one. the PD_LDFLAGS seems a bit like a kludge to me. What optimization do you need to include in LDFLAGS? I can't think of optimization being a general term here for whatever tweaks the user sees fit. with CFLAGS these are definitely optimizations, with LDFLAGS i don't know. any. I think the best source of info for this would be to see what Debian builders set as LDFLAGS. the thing is, some of them (e.g. CDBS) do set LDFLAGS to (nothing). this is when i discovered the problem when trying to cdbs'ify pd-arraysize, because the build would fail. (never mind my cdbs'ifying that; i'm trying to build a common cdbs-snippet for more easy packaging in debian) But if you really want to have all the possibilities for overriding things, then go with autotools, especially with automake. They generate makefiles that have lots of room for customization. From my point of view the Makefile template was never intended to work in all situations, only simple libraries that don't have special dependencies. i'm really not trying to use autotools here, as that is definitely an overkill in most situations. however, afaict, CFLAGS and LDFLAGS are commonly meant to be settable by the user, so setting those should not break the build system. the problem also is not template Makefile centric (though i stumbled over the problem with the template Makefile in this special case; however, in the past, i have stumbled over this problem with other Makefiles as well) autotools will kind of automatically take care of those things, but since this is such a common case, i do believe that there must be a elegant, vanilla make solution for the problem. i'm really not trying to invent problems but to solve them. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz2mbQACgkQkX2Xpv6ydvRwYQCfXBBpruTCwkcVTlOt8MYPuGyB W/gAnR+wNjlTFYBcpIQsfInG5kC72Wb1 =03k5 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] split out 'osc' and 'net' from 'mrpeach'?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/2010 10:17 PM, Martin Peach wrote: On 2010-11-28 15:57, Roman Haefeli wrote: That's another reason they should be in net instead of mrpeach: it seems that having my name on the folder inhibits others from improving the objects, so we end up with multiple parallel incompatible objects, in this case with the same names. a) my intention when writing iemnet was to maintain compatibility with mrpeachnet (with silently dropping things which i find either ugly hackz to circumvent problems in the current implementation (e.g the unblock message) or things that have nothing todo with networking (the possibility to directly send the contents of files) in most cases they should thus be exchangeablee b) my intention as a debian packager was to provide both packages as pd-iemnet and pd-mrpeachnet, not making any of those the canonical library. i still think thaat both share sufficient parts of their interface to make them be called compatible, so i would also make both of them provide pd-net, allowing people to use them as net/udpsend (if they can stick to the common API) or as mrpeach/net/udpsend if they cannot live without sending entire files directly. i haven't done the actual packaging yet (given my currently available time...) mfgasdr IOhannes PS: and yes, i agree that the packages should be grouped by functionality. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzzdBMACgkQkX2Xpv6ydvRAcACgh5rCtzrMvXKXpVQMaiTTwU2M GXgAn12FQsOYbvME/5gbbnPBwZvRpf+a =4uOC -END PGP 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/22/2010 12:52 AM, Hans-Christoph Steiner wrote: To be pedantic, I'd say its _derived_ from the Makefile library template, not really based on it since you have organized the files into different directories. But it does seem to build as universal on Mac OS what has my kernel and directory layout to do with whether the build system is based on it or derived from it? if i change the LIBRARY_NAME from template to foo, does this qualify already as _derived_ rather than _based upon_? the only changes to the makefile are: - - changed the names and files to mine - - added a VPATH - - added a HELPPATCHES so, that's exactly 2 extra lines (VPATH, HELPPATCHES) compared to proper template-Makefile based libraries. fdsdrtm IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxxDjIACgkQkX2Xpv6ydvSl7gCdEnhlRht3hRXYePiFBTWMDjXF WjkAnRgF4lxA6hAUEk/wKpXgaImJU/TU =UlHp -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] svn commit rev.13794 (debian files)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/15/2010 12:00 PM, pd-cvs-requ...@iem.at wrote: -- Message: 4 Date: Sat, 14 Aug 2010 21:02:41 + From: eighth...@users.sourceforge.net Subject: [PD-cvs] SF.net SVN: pure-data:[13794] trunk To: pd-...@iem.at Message-ID: e1oknsh-0008iv...@sfp-svn-1.v30.ch3.sourceforge.com Content-Type: text/plain; charset=UTF-8 Revision: 13794 http://pure-data.svn.sourceforge.net/pure-data/?rev=13794view=rev Author: eighthave Date: 2010-08-14 21:02:39 + (Sat, 14 Aug 2010) Log Message: --- applied Felipe Sateler's feedback on the pd-motex package to these packages Modified Paths: -- trunk/abstractions/footils/list-abs/debian/changelog hi hans, so do you plan to maintain debian/ files in both the pure-data svn and the pkg-multimedia repositories? what's the good use of that? fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxoK6sACgkQkX2Xpv6ydvQdvwCePEtCVNS4sJ7i4/+FMOk0M2Sm w1QAmwU6gv0RxVeveVQn7NhkIEKoGQWt =JJUn -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] svn commit rev.13794 (debian files)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/15/2010 08:36 PM, Hans-Christoph Steiner wrote: If you look a little closer, you'll see that motex has been submitted to Debian pkg-multimedia, and it no longer has a debian/ folder in pure-data SVN. i see (i haven't looked that closely) but since i guess you want to package all those libraries with pkg-multimedia as well, i'm still wondering whether it helps the confusion :-) far IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxoNMEACgkQkX2Xpv6ydvREVACg8vUJqN3OYd8ca4kDpf5+O9Yf z+wAnAxg4TWYEIy7l0ud/0K7OVYaVx/s =4Iw6 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] debian installation paths for Pd(X)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 2010-06-09 at 22:09 -0400, Hans-Christoph Steiner wrote: Until we get the 'puredata' package installing its extra stuff in a separate dir from /usr/lib/pd, then its tricky to make 'pdextended' use /usr/lib/pd. But once that's separated, its easy. hmm, i'm not sure i fully understand the need. - - external-packages (e.g. pd-wiimote), have to install somewhere, the obvious place would be /usr/lib/pd/extra (for both puredata and pdx) - - puredata provides almost no externals (and they could be factored out into separate packages): expr~, fiddle~/sigmund~, pd~,... (~10) so what's the bug advantage, if puredata installs into /usr/lib/puredata and also searches /usr/lib/pd/extra (since /usr/lib/puredata/extra is virtually empty)? with pdx it is (currently) a bit different as it comes with so many externals, and we want to avoid conflicts with pd-externals (and simil.) installing to .../puredata has the theoretical advantage of allowing to install externals that are known to not work with PdX, and thus won't interfere, if PdX was looking in /usr/lib/pd/. i think this is rather theoretical (currently i don't know of any such external), but at least it allows for this possibility. thus it's probably more elegant and cleaner. is it worth the effort? mfgas.r IOhannes PS: sorry if i started a new thread for an already existing one; it's actually a reply to a private email from roman, turned into pd-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwRG3MACgkQkX2Xpv6ydvSxlgCg00P3sZEYoBGcpY7DXNkwO3nc khYAnjBrRZAXnNKAfmEb80gHYiJzAYxM =T+ew -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] mrpeach/tcpserver one last lingering bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roman Haefeli wrote: Hi all posting. However, I thought it's worth mentioning those as well, so that forces might be joined. I have the impression, that similar problems are sure worked on twice on two completely different ends. that was the reason for forking of mrpeach in the 1st place: to be able to work on completely different ends without having clashes. at some place, we should see how far the different ends go, how they overlap and whether we can/should merge again. fgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvi2wYACgkQkX2Xpv6ydvQv0gCg5yjCOIIHP0IP4dTLw2ONKD8e 46UAn1ZbzWYcXkJIblE0cXIy8WQaUVwQ =B5e7 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] mrpeach/tcpserver question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ivica Ico Bukvic wrote: Martin, Just tried the latest version and the problem with stuck port persists, suggesting that either Ubuntu is doing something funny or that the destructor is to blame. if you quit Pd, the destructors are not properly called for externals. this is a rather serious issue reported on the sf-tracker soome years(?) ago, but a fix never made it into Pd proper. fgmasr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvcUzEACgkQkX2Xpv6ydvRLBACfSxzFqaEjqDFFaiRNytP+ANAq 6ysAoOIM2knNWDyYC8oJ4Ka5ARCeR8sJ =w7IG -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] gui-rewrite, apple_events.tcl imports pdtk_post?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans-Christoph Steiner wrote: IOhannes probably overlooked that line when he was working on the new post stuff. I haven't looked at that code, so its just a guess. If you want to commit to the pd-gui-rewrite branch, I say go ahead. i haven't touched that file but i think it's safe to remove it (which i have done now) no idea why anything should not compile: that's tcl code i have also changed the interface more towards what i think hans really wants... mfgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkulFdcACgkQkX2Xpv6ydvRgnACfYV/bYe1x2cFFsp8i314++1sW v8kAoPQe/dhIEM53MC+n9CuBQOay/BUt =bRne -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] seeking advice on Pd gui overhaul
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arnout Engelen wrote: On Tue, Feb 23, 2010 at 07:46:32PM -0500, Ivica Ico Bukvic wrote: Hence, I personally feel going after JUCE or Qt still allows Pd to be as platform-agnostic as Pd currently is (with the exception that these are AFAIK using GPL as opposed to BSD license) This could be an issue: unless the new GUI would be decoupled from Pd (which is a bit of a muddy discussion), using a GPL GUI library would only be allowed well, if the new gui follows the path of the old gui, then pd-gui and pd-core are two entirely different applications, communicating over a network socket. i don't think the GPL can do anything here (e.g. make all internet explorers grabbing pages from an apache2 server violate the GPL) personally i think the way to go is: #1 clean up the communication between pd-core and pd-gui; (i like to see the pdguirewrite as a preparation for this step) once the interface between pd and pd-gui is sufficiently clean (e.g. no more tcl/tk commands are sent over the wire), then you can implement the gui in whatever toolkit you like (and see whether it really makes a difference) #2 provide a mechanism so an external can hook into the gui-communication (replacing sys_vgui() and friends) this would allow to replace the current networked communication by e,g. a multithread-based one, which would make using shared memory and the like a lot simpler (with the malus of not being able to run pd-core and pd-gui on different machines any more (think peerdata)) gmsdf IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuFkhAACgkQkX2Xpv6ydvSYQQCdHGWOWFM+tNb6YtkZ4gh10Owr teoAnAgFmC5sV+EOC9/JmJu+At6+MgZH =fAUS -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] using t_time for clock functions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans-Christoph Steiner wrote: Another thing Günter did in PDa is introduce t_time for the clock functions instead of using 'double' directly. Any reason not to include t_time in vanilla? can't think of one. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks+T68ACgkQkX2Xpv6ydvQnqgCgz1Ez+LqPOvkTFs0aXP5zvgO4 7AAAnjizZmrjxvsOTcVmjq6zdHb+JcXB =qgUh -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] t_sample vs t_float in PDa vs vanilla
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans-Christoph Steiner wrote: I am attempting a merge of the PDa integer code with Pd-vanilla 0.43. Vanilla now mostly had the t_sample/t_float stuff ironed out, but there are a few minor differences between the two that I am not sure of. Here's the first that is in a bunch of places, including in d_arithmetic.c: vanilla: t_float g = *(t_float *)(w[2]); PDa: t_sample g = ftofix(*(t_float *)(w[2])); It seems to me that 'g' should be t_sample, not t_float. Any ideas? g is the scalar argument given to the object (or set via a message). when i tried to clean up the t_sample / t_float code, the decisions i made where based on where the values come from: - - a sample within a signal vector is always t_sample - - a number in a message is always t_float - - a number in an object's argument should always be t_floatarg. the idea is, that that the signal and the messages might have different numeric types (as is the case in PdA) now t_float and t_floatarg are certainly mixed up often. but i tried to get the line between t_sample (signal) and t_float (not signal) right. therefore g is t_float and not t_sample in the first place. it should _then_ be converted into a t_sample, before the actual arithmetic is being done on the incoming signal (of t_samples). this could be done in one line, but it probably should not, for readability's sake. fgasmr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks+UU8ACgkQkX2Xpv6ydvT37ACg6QeSWGFXAtXv7C/VI6Tp8pL4 H4IAoNZ9BtB+Bp6xKc6O9pQLHeUYsxmm =Sa26 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] t_sample vs t_float in PDa vs vanilla
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans-Christoph Steiner wrote:
Here's the code in question, from PDa:
ah which reminds me of the thing i forgot in my last email: please add
line numbers when you refer to a sepcific line in a file.
snip
d_arithhmetic.c:
t_float g = *(t_float *)(w[2]);
/snip
is a bit vague for my taste (ever tried to grep for int i :-))
So based on your comments, it would go something like this, which seems
needlessly verbose and wasteful of CPU cycles:
[...]
out[0] = f0 + ftofix(g); out[1] = f1 + ftofix(g); out[2] = f2 +
ftofix(g); out[3] = f3 + ftofix(g);
i guess you are not trying to be nasty on purpose :-)
i can't see how your interpretation makes the code more readable.
i was trying to say something along:
code
t_int *scalarplus_perf8(t_int *w)
{
t_sample *in = (t_sample *)(w[1]);
t_float g_f = *(t_float *)(w[2]);
t_sample g = ftofix(g_f);
[...]
out[0] = f0+g; out[1] = f1+g; out[2] = f2+g; out[3] = f3+g;
/code
this would take as much cycles as
t_sample g = ftofix(*(t_float *)(w[2]));
but separate the code for getting the value and making it a sample.
fgasdmr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAks+WUQACgkQkX2Xpv6ydvQWPACgymwWzv4hAPJ+Y10QXSsLl9+3
HowAoMnCzbBi/kAyZ+LEzhf2khzxHerc
=gy6T
-END PGP SIGNATURE-
___
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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris McCormick wrote: On Fri, Nov 20, 2009 at 01:48:44AM -0500, Hans-Christoph Steiner wrote: The 'puredata' package is already in Debian and Ubuntu and has been for a while. That's pd-vanilla. Oh! I assumed that that was the 'puredata' package you were referring to which Günter is no longer updating. Sorry for the misunderstanding, carry on. ?? hans is talking about the puredata package in Debian which Günter is no longer updating[*] and which is in fact pd-vanilla. mfasdr IOhannes [*] in fact, Debian 'puredata' is 0.41.4, which is about as recent as the latest Pd-extended release. so the package is not really outdated (unlike the gem package in debian); however it seems clear that günter does no longer find the time to update the packages himself. probably he could sponsor the uploads into mainline. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksGZywACgkQkX2Xpv6ydvQ+9QCgxnLDU8fPFb6qzpqaAoZsfrzR KaQAnjOQcGF5+mnJUnKiG0vYzg8t1esr =Mncx -END PGP SIGNATURE- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. for what it is worth, there is an updated version on mentors.debian.net: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=puredata it's lintian clean (unlike the old package) and fixes some pending bugs - improved puredata.desktop for file associations, etc. - built against Tcl/Tk 8.5 without these additions though. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksFlXIACgkQkX2Xpv6ydvQHvgCg2HvfxPSvIVSPT77LQvwhDFFe iTYAn2UE4EhI0YM/XcRFOzPzoGyaJail =exVy -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] namespaces for send/receive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans-Christoph Steiner wrote: Why not have settable receives? iirc, the problem is that you can easily make Pd crash with settable receives. fgmar IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksETO4ACgkQkX2Xpv6ydvRDEwCfZno+azCeK6rT3EANV2Mshb0f dF4An3Zx85QXsag300tSIg0srPlr+Jn/ =OQTs -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PdGuiRewriteTestBuilds
Steffen Juul wrote: Thanks for your reply! Ok. The following is what i have and seam to be the latest and greatest in the Fink repo. And judging by http://puredata.info/dev/PdGuiRewrite that should suffice. read below. $ which autoconf /sw/bin/autoconf $ autoconf --version autoconf (GNU Autoconf) 2.59 Written by David J. MacKenzie and Akim Demaille. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. then re-run autogen and autoconf and configure. and tell us whether the problem persists. So i don't know. I'l try to start from scratch. affter a bit of googling i found http://list.sipfoundry.org/archive/sipxtapi-dev/msg02134.html this somehow suggests that 0.59c would have the very macro, but 0.59-5 would not. seems you are right at the problematic version :-) apart from that i have no idea why the AC_TYPE_INT16_T check is there at all. i guess it has been autogenerated by some higher versioned autotools. i don't think it is needed anywhere within the source code, so just delete the offending lines in configure.ac (157-161), rerun autogen.sh and see whether the problem is still there. mfgaasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PdGuiRewriteTestBuilds
IOhannes m zmölnig wrote: would not. seems you are right at the problematic version :-) meaning that you do seem to have a problematic version of autoconf, rather than that i stand corrected, what i said about problematic versions was nonsense. sorry for the wording. gmasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] multiblob
hi again. because i had to rant so much, i forget the 2nd part of my (real) answer... IOhannes m zmölnig wrote: I saw some patches like pix_multiblob_help.pd in pd-extended. Would it be similar to the one in the link?? you can achieve something like this with [pix_multiblob]. but the itself patch will of course be very different. GridFlow is a very generic framework for handling grids (arrays of arrays of arrays ... of arrays of numbers), whereas Gem is more targeted at graphics and some image (2d arrays of pixels) manipulation. 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. mfg,asdr IOhaannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Finished iemguts' [canvasselect] and a max-toolbox-like proof of concept
Luke Iannini wrote: Yo all, My usual caveat applies: that I'm as nearly unconscious as I always am when I'm releasing public works :) I had a flight today which gave me a chance to finish up [canvasselect] (by merging in some code from zexy's tabdump in my usual naive fashion to make it output index-lists rather than just post() the currently selected objects (thus, IO, you should probably double check my work :) )), and then put it to work starting to create some patching-assist functionality similar to max-toolbox. I'm pretty excited for what can come out of this! wow sounds great! i will try it out asap. i kind of abandoned work on [canvasselect] after i realized that it did not seem to work as i liked (e.g. you cannot select something in a closed patch). that's why there were post()s inside rather than useful output... IOhannes, do you know if it's possible to get and set the coordinates of arbitrary objects simply by index, much like [canvasposition] can do now but including externals etc. where you can't place a [canvasposition] object? yes, i know this and it is on my todo list (it's not hard to do, i just did not find the time yet), i'm planning a separate class of objects like [canvas...] that operate on _other_ objects rather than self. http://lad.linuxaudio.org/events/2009_cdm/Saturday/18_Zmoelnig/index.html Back soon with more... really glad that you like it, mf.asdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] packaging pd and friends WAS: GIT repo
Claude Heiland-Allen wrote: [...] couldn't have said it better. mfg.adsr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] gavl and gmerlin-avdecoder in Fink and on build machines
Hans-Christoph Steiner wrote: Through the labors of August and some contributions from Luke and me, there are now libgavl1 and gmerlin-avdecoder1 for Fink. We are working on getting readanysf~ compiling nicely. Now that leads me to wonder: how about getting Gem on Mac OS X to use gavl and gmerlin-avdecoder? I think it'll have much better codec support than Quicktime. how not to? which complications do you expect? Check out all of the codec libs that are included. obviously these is exactly not the point of having a plugin-architecture... These will all then automatically be included in Pd-extended: thanks for your efforts. gmasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] library finding it's own path?
Martin Peach wrote: Have a look at the source for [mrpeach/which] in svn. I took some code from Pd internals and it calls some more, but maybe not _way_ too much. thanks for the hints, but this is even more ugly (no harm intended) than what i already have. i really want to be agnostic about which extension the library has (just image miller adds a new extension; or hans removes .l_i386 from PdX and i will actually find the wrong binary) i currently create a fake instance of myself and check the c_externdir in this object.. fsa IOhannes What's missing from it is a way to know if a name refers to an internal. Martin ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] library finding it's own path?
martin.pe...@sympatico.ca wrote: thanks for the hints, but this is even more ugly (no harm intended) than what i already have. i really want to be agnostic about which extension the library has (just image miller adds a new extension; or hans removes .l_i386 from PdX and i will actually find the wrong binary) Well it's the same 'ugly' code that Pd itself uses. I simply copied the extension list from Pd source. you got me wrong. i know that it is copied from Pd sources and i have no problem with how Pd implements this. however, i want to find out where Pd got the file from, and just trying to do the same as (a specific version of) Pd and hope to end up with the same result is what i consider ugly. (if i want to know what you get by multiplying 54234*6533 then it is no use to calculate it myself; either of us can make an error in the calculation and then my result will tell me nothing about yours) I guess you could just access the list directly and then not worry about it changing in the future. The code for [which] tries all possible extensions for the current OS and opens the first one that exists. Pd does the same thing, or at least the version in svn does. that is the problem. when running [which] with an older version of Pd (say: 0.39) and you have concurrent .pd_linux and .l_i386 lying around, then you might eventually get the wrong result (as you find .l_i386 for which Pd-0.39 doesn't care at all) Probably if the relevant functions were exposed in m_pd.h they could all be used in situ. yep, this is along the lines i was thinking. my approach with querying the class about it's externdir member is very much what i want (and do), it's only that this can only be found in private headers. (resulting in both compile-time and compatibility problems). you could have a look at my code at https://pd-gem.svn.sourceforge.net/svnroot/pd-gem/trunk/Gem/src/Base/GemSetup.cpp i was wondering whether i have overlooked a way to query private members of a class. probably we can tell miller into something like int class_getmember(t_class*c, t_symbol*id, t_atom*result); which would allow the developers to access existing private members (the funtion would return an error-code if the id did not name an existing member (or at least one that Pd knows about) this seems to be more elegant than adding a bunch of functions like char* class_getname(t_class*c) mfgasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] library finding it's own path?
IOhannes m zmölnig wrote: Well it's the same 'ugly' code that Pd itself uses. I simply copied the extension list from Pd source. you got me wrong. i know that it is copied from Pd sources and i have no problem with how Pd implements this. however, i want to find out where Pd got the file from, and just trying to do the same as (a specific version of) Pd and hope to end up with the same result is what i consider ugly. that is not to say that your code does not make sense for your [which]. e.g. you can query the location of not-yet-loaded externals, something which i am totally uninterested for my current goal (but which nevertheless has its merits) fgmasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] error: maximum object loading depth 1000 reached
Hans-Christoph Steiner wrote: IOhannes, Mind if I remove this patch for this release? I think that the 1000 line already loaded dump is currently too common, for whatever reason, and since this functionality isn't currently in use, as far as I know, I think it makes sense to keep this patch out until the whole abstraction loader thing is figured out. yes of course, no problem. fgmasdr IOhannes I am fine with adding it back in whenever its needed. .hc 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Patches-2746054 ] hard-code default user-install paths
Hans-Christoph Steiner wrote: On Apr 9, 2009, at 6:21 AM, IOhannes m zmoelnig wrote: shouldn't it be a folder Pd as well? (to avoid confusion) There was extensive discussion on this topic in the past, and there was agreement on ~/pd-externals/. Check the archive for details. the topic mainlyy focused on ~/.pd vs ~/pd and i follow all the arguments back then. however, what i really wanted to ask (and what i actually did ask; i only eventually got caught by ~/.pd and wrote a bit too lengthy on that...; however i did mention that it had been discussed before :-)) is why both w32 and osx have a .../Pd folder whereas on linux it is .../pd-externals. why is it not ~/pd ? re-reading the entire thread from back then does not kindle the impression that any agreement was made for ~/pd-externals (though there was agreement not to hide the directory) fgmadr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] grill svn:externals and anonymous access
Hans-Christoph Steiner wrote: Hey Thomas and fans of svn:externals, If you are going to add an svn:external to the pure-data repository, make sure there is anonymous access. Can we at least agree on that? yes. totally. fgasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Using operator on t_symbol?
B. Bogart wrote: Hey all, A gphoto function expects a variable argument in the following form: char myvar[] = 10; function(myvar); But I'd like to pass a symbol argument from PD. function(arg-s_name); does not work. (no errors, the value just does not get set.) What is the proper way to get the address of the s_name part of a t_symbol? never ever change the value of a symbol. they are constants. you will get crashes and everything. if you have a function that wants to change strings, you have to use stings and not symbols. (convert a symbol to a char[]; modify it; call gensym() on the new string) fgamdsr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] a52dec-devel installed on Fedora build server
Hans-Christoph Steiner wrote: could you do the same for the planetCCRMA machine? Sorry, that's the same thing. It's Fedora/PlanetCCRMA. ah ok. i was over-enthusiastically looking at the log-files and noticed that the error was still there, so i thought... anyhow, we have a fedora/ccrma build from the last 24h, so everything should be fine again. thanks gmdat IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
