[PD-dev] Re: [PD] building HID from the CVS, errors
David Merrill wrote: Hello all, hi. i am redirecting this to pd-dev, since i hope this mail will lead to some further dev-specific discussion and hopefully to some usable build system. Has anyone else had a problem trying to compile an external from the CVS source? I just checked out the externals dir from CVS, and wanted to compile the latest [hid], so after reading the README in the hid directory, I typed: make INCLUDE=/usr/lib/pd/src PDEXECUTABLE=/usr/bin/pd ..and got the following: --paste-- [...] --end paste-- Why would the build want a /sigpack, and /zexy directory? And am I missing a Makefile.buildlayout file? to compile hid (and i guess, any of hans's externals) you need the entire pd-cvs (at the very least you need the packages module) downloaded from sourceforge. i agree that this is _very annoying_ at the least. my solution to compile something as simple as [folder_list] was to NOT use hcs's build system at all (i really just wanted to have to download not more than 1MB to get this single object), but instead compile the object with: gcc -g -O2 -I. -DPD -fPIC -export_dynamic -shared -o folder_list.o -c folder_list.c gcc -export_dynamic -shared -o folder_list.pd_linux folder_list.o -lm -lc you might try something similar with hid, although things are a bit more complicated here. that's basically the answer to your question, the rest is what i draw as a conclusion: SO: i see the need for a grand unified build system for things like pd-extended. but i am not totally sure, whether everything should be sacrificed to pd-extended. naturally, hans has the right to do anything with his code, including forcing anyone trying to build the sources from his part of the repository with any build system he likes. nevertheless, i would recommend a system that would make the best of the two worlds: be able to take advantage of the general pd-extended build system and (at the users option) be able to not have to use the pd-extended build system (probably at the cost of having to do some manual configuration if the maintainer doesn't want to maintain to configuration systems) the simplest solution that comes to my mind is, that one of the 2 systems uses a differently named makefile. since pd-extended's build-system is more likely to be called from a parent makefile (because somebody wants to build the entire pd-extended build-system), i suggest to name this Makefile.extended (or Makefile.buildsystem) anybody wishing to build using the extended build system, would call make -f Makefile.extended. other users would just do a make. a more sophisticated method would use a Makefile.extended and a Makefile.simple. the ordinary Makefile would first check for the existence of the extended build-system and if present, it would use Makefile.extended, else it would use Makefile.simple. if test -e ../../packages/Makefile.buildlayout then # cool, we can use the extended build system make -f Makefile.extended else # simple fallback make -f Makefile.simple fi what do you think? mfg.adsr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] argcargv and dollarexpansion
IOhannes m zmoelnig wrote: just to revive this discussion: i have submitted a patch to the tracker, which enables the expansion of $# (argc) and $@ (argv). [$#( could be considered as an implementation of [list length] (and vice versa) which basically means, that [$#( is redundant, as soon as there is a [list lenght]. the latter would be more robust regarding incoming messages. i just did it for completeness. $@ is more useful, as it allows you to pass variable argument lists to nested abstractions. all other implementations i could think of have the problem that they only work with 1st level abstractions, like iemlib's [dollarg]. which makes me think, that $@ is really a MUST. mfg.asdf IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] configuration : .pdrc, preference dialog... s-lang
Mathieu Bouchard wrote:
On Mon, 28 Aug 2006, Hans-Christoph Steiner wrote:
If you already know the intricacies of Mac OS X, for example, why
should you have to learn some other random thing? Mac OS X and Debian
illustrate this concept very clearly. In Debian _all_ packages are
configured to fit in with the Debian paths and scripts. That means
once you learn how to setup one Debian package, you can apply that
knowledge to any other Debian package.
How does .pdsettings fit in any way with Debian ?
how does it not?
debian-packages usually are configured via files in both /etc/
(system-dependent) and ${HOME}/ (user-dependent).
however, every time i ask for this feature, i only get a a Pd is not
for real systems answer ;-)
mfga.sdr
IOhannes
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Re: PD-cvs Digest, Vol 19, Issue 9
Mathieu Bouchard wrote: The following message from pd-cvs has no cvs log. Is this normal? Modified Files: ringbuffer.c ringbuffer.h Log Message: Many bug fixes isn't Many bug fixes a cvs log? if you are wondering, why there have been no diffs between r1.11 and r1.12 in the mail, then i'd say it is because there are none to show. probably someone added a newline at the end of the file, or the linebreak has changed (CR,LF), which should be normally handled gracefully by the cvs implementation, but might be not working 100% correctly. mfgasr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [once] default closed...
hi. Hans-Christoph Steiner wrote: IOhannes stuck [once] into the purepd library. I started that library true as a DEVELOPMENT library to explore ideas of how to implement things in sorry, i had no idea you intended it like that. i always thought that purepd would be a replacement for often-used externals in plain pd, and that it was meant to be a community effort. i was mistaken here. Pd. IOhannes replaced my code with [once] without asking me. That's hmm, which code are you talking about? did i _replace_ your code of [once] with (my) [once]? i don't think so. did i replace your code of [oneshot] with one using (my implementation of) [once]? this is true (but the logfiles of [oneshot] state, that it is meant as a pd-ified version[s] of existing object[s]; the only known [oneshot] object (at that time) is in MarkEx/Gem, and the original pd-ified object did not properly implement that's behaviour. i thought i was fixing a bug...) bad CVS etiquette. But [once] was an improvement on what was there. I thanks for the roses. want to improve it further but you guys are blocking me. So here's what I say: purepd will remain a DEVELOPMENT library. If you want a static, unchanging [once], please include it elsewhere, like zexy. If you want a place to freely explore implementing things in Pd, please include it in the purepd library. Then as interfaces and ideas get solidified, they can be moved elsewhere. an this from someone who is known for advocating standard behaviour of objects. purepd is a very catchy name for a mere sandbox. mfg.adr. IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Using PD just as an API
Jarbas Jacome wrote: Brothers, is it possible to use PD just as code API, without using its GUI? I mean, for example, create a program with a completely diferent GUI for PD? Or make a program without interface at all. Any good example of something like that? pd -nogui seriously, there have been numerous efforts and solutions to use different guis for pd. basically there are 2 different approaches: the simple one is using FUDI/OSC to remote control an invisible pd; personally i use this a lot with remote-controlling pd with another pd; projects that use other toolkits include GriPD and the 2 browser plugins for pd. the other approach tries to have a better separation between audio-kernel and pd-gui (which unfortunately are very much interdependent in the current state of the pd codebase); the most notable of these projects is DesireData. try searching the archives on these topics... mf.gadrs IOhannes Thank you. j.jR. ___ 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] missing file from pd-MAIN and fftw version
Hans-Christoph Steiner wrote: It would be very nice to have FFTW in Pd, its really much much faster. .hc On Sep 25, 2006, at 10:38 PM, Miller Puckette wrote: Well, I started coding for fftw-2, then found out it had already been replaced with fft-3, then decided that perhaps I should just wait for fftw-4 or 5. I didn't like the way it was done in devel (with lots of fftw-specific stuff in d_fft.c). last week frank and me were invited to a radio show (tech talk) about pd: we finally came to a point where the moderators got very confused, why fftw was NOT used in pd. so after a little generic explanation, frank and me looked at each other, and answered: well, pd is very flexible: you could write an external that does fft's using fftwwait...hmmm...why has nobody done this yet? and that is the question: why do we necessarily need the fftw based fft-objects in plain pd and cannot use externals? so i ripped the fftw-code out of tim's patch and checked it into the cvs as /externals/fftw/. the objects are called [fftw~], [ifftw~], [rfftw~] and [rifftw~] currently it seems like the code it is not really working, the only object that produced any reasonable result was [rfftw~]; i guess this can be easily fixed, but i don't have the time right now to investigate this any further. so the only drawback is see is: the objects are called [fftw~] instead of [fft~]; but lo and behold, i vaguely remembered krzysztof magic in cyclone, where a newly loaded class raises itself over an already existing class. while he is using it to overwrite objects from other externals (e.g. iemmatrix's [matrix~]), i don't see any reason why this should not work with internals. et voila, does this not sound good? mfg.adsr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] corelibs, build system
corelibs is currently broken due to a renaming of pd/src/d_mayer_fft.c to pd/src/d_fft_mayer.c while i updated the corelibs/generate.sh script to handle this, it still does not really work with the autobuild-system. the reason for this is (imo) the very complicated stacking of Makefiles (externals/Makefile vs. externals/corelibs/Makefile) which makes it impossible for a make-noob like me, to generate the .c files in the makefile while calling make in /externals (it does work fine when i do just make in externals/corelibs. the reason is, that CORELIBS_OBJECTS is evaluated before the files are generated (which would result in NO objects, since there should be no .c files before generation) a simple solution would be, to call make -c corelibs/ generate and then make -C corelibs/ from the externals/Makefile. obviously this does not work, since externals/corelibs/Makefile has no logic and instead uses externals/Makefile with the corelibs target (which would make my idea quite recursive). then again there is the horror of touching externals/Makefile at all: this huge file makes it quite hard/impossible to work on / fix several targets at the same time. e.g. yesterday i first worked on corelibs, then noticed that zexy won't build as it should, so i had to revert all the changes i had done to the Makefile (since it didn't yet work properly) so i could start fixing the zexy-build (which i understand better, and which i was pretty sure to be able to fix). so i ask this again: would it not be better to have the build-logic for each directory in a separate Makefile (which could be edited separately)? these Makefile could make use of a generic(!) Makefile which (e.g.) lives in externals/ this generic Makefile MUST NOT have any intelligence about the separate destination targets (e.g. no different logic for building corelibs or hid; just a generic build target); if such intelligence is needed, it should live in the projects subdirectory (externals/corelibs/Makefile) i would also like to know the exact reason for the pwd-magic (i just never ever needed such thing in any makefile i wrote, so i'm curious) mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] missing file from pd-MAIN and fftw version
Tim Blechmann wrote: what makes you think, that this is similar in text-based languages? i think script language here did not mean text-based language (ignoring the etymology of script), but rather interpreted language. mfg.adsr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] scripts/nightly-build.sh
excerpt from scripts/nightly-build.sh
snip
# GNU/Linux
if [ ${UNAME} == Darwin ]; then
cd packages/linux_make
fi
/snip
it would be nice if such magic would be documented ;-)
mfg.adsr.
IOhannes
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
[PD-dev] autobuild logs
hi all, hi hcs would it be possible to do the rsync without the verbose (-v) flag? even though rsync's manpage says that --delete s oh so dangerous and to be used with care, i think that this care has already been taken. so for me, this verbosity is really annoying in the logs. mfasdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] corelibs, build system
Hans-Christoph Steiner wrote: did not ask at all. d_mayer_fft.c is the name of the file in 0.39.2. You have broken compilation for Pd-extended. because corelibs IS broken, even without my changes (which tried to fix what was going on) Check the build logs from the auto-build farm for the past 2 months. I had been building fine on every platform. This is really, really i do not doubt that pd-0.39-2 has built fine. however, times are a-changing, like the pd source code, and d_mayer_fft.c is nowadays called d_fft_mayer.c what i did (try to) do, was to modify your build system in a way, that it could handle both cases. (and the build system has serious problems with this) mdf.adsr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] corelibs, build system
Hans-Christoph Steiner wrote: what i did (try to) do, was to modify your build system in a way, that it could handle both cases. (and the build system has serious problems with this) Is this urgent? well no, but pd-0.40.1 is out now... How about waiting until we get the 0.39.2 Pd-extended release out, then we can switch externals/corelibs to work with 0.40 with no need for kludges to support 0.39.2. i see. i was interested in making both work at the same time, while you were interested in making a release asap. i think both standpoints are valid. (i don't try to prove that i was right, i just try to explain why i did what i did) mfga.dsr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-1371511 ] declaration of `y1' shadows a global declaration
SourceForge.net wrote: Comment By: Mathieu Bouchard (matju) Date: 2006-10-18 09:47 Whatever about calling functions y0,y1,yn, they've been there since almost the beginning of unix. They're Bessel functions defined in math.h. You won't be able to move them out of it. oh, i see. i didn't know that bessel-functions are in math.h. nevertheless i think it was a very stupid thing to call them y1() or the like in the first place (but i agree, that this cannot be changed any more). This suggests that the -Wshadow warning is of questionable use. I'd turn it off, personally. right, that was suggestion c) which mysteriously vanished. fma.dr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-1371511 ] declaration of `y1' shadows a global declaration
Hans-Christoph Steiner wrote: I think its a really bad idea to name functions using names that have existing in standard headers for decades, especially when that header is i do not recall any function in pd with a name y1(). it is a simple stupid variable, with a _quite_ descriptive name (e.g. upperleft_y would be more descriptive) used in the same project. So must more C devs since gcc warns of this condition by default. The warning should stay so that we don't get more such conditions. well, having variable shadowing others is not the end of the world. one of the benefits of variable shadowing is locality. at the same time this is it's curse. after all, we have been discussing to get a similar mechanism into pd for ages (think namespaces without prefixes!). maybe we should rethink this. fixed soon doesn't seem like the good solution to me. Instead it should be set to Postponed, later, Remind, Wont Fix, something that communicates why its being ignored and makes it easy to find in the future. i am with you. mfga.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] Re: zexyconf.h conflicts
Hans-Christoph Steiner wrote: I am getting conflicts just my using your build stuff. Could you remove zexyconf.h from CVS since its dynamically generated? Otherwise this will require manual intervention after automatic builds. RCS file: /cvsroot/pure-data/externals/zexy/src/zexyconf.h,v retrieving revision 1.3 retrieving revision 1.4 Merging differences between 1.3 and 1.4 into zexyconf.h rcsmerge: warning: conflicts during merge cvs update: conflicts found in zexy/src/zexyconf.h C zexy/src/zexyconf.h i see. this is indeed a problem. the reason why zexyconf.h is checked in, is that you can also build zexy with M$VC without running configure first: in this case nobody will create the zexyconf.h file, which - imho - makes building overcomplicated (i don't think it is an option to tell people to copy zexyconf.h.in to zexyconf.h and edit to their needs). the issue here was, that incidentially a generic zexyconf.h has been overwritten in the past by a generated file. i have to read the CVS manual, to see how to exclude checked in files from being updated. another solution might be, to run make distclean before doing CVS updates, which will remove the generated files. mfgg.ar IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] Re: zexy build error on Windows XP/MinGW
Hans-Christoph Steiner wrote: gcc -DPD -O3 -funroll-loops -fomit-frame-pointer -mcpu=i586 -mtune=pentium3 -I/home/pd/auto-build/pd-extended/pd/src -W -ggdb -mms-bitfields -DMSW -DNT -D'O_NONBLOCK=1' -D'srand48(n)=srand((n))' -D'drand48()=((double)rand()/RAND_MAX)' -D'bzero(p,n)=memset(p,0,n)' -o /home/pd/auto-build/pd-extended/externals/build/src/lpt.o -c /home/pd/auto-build/pd-extended/externals/build/src/lpt.c In file included from C:/msys/1.0/home/pd/auto-build/pd-extended/externals/build/src/lpt.c:2: C:/msys/1.0/home/pd/auto-build/pd-extended/externals/build/src/../../zexy/src/lpt.c:51:25: sys/ioctl.h: No such file or directory this was due to the wrongly checked in zexyconf.h (which had linux-parallelport-device support enabled). i thought i had fixed this yesterday. mf.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] Re: config.h enhancements
hi Hans Steiner wrote: Just a thought: Miller has started, just barely, to use a config.h generated by ./configure in pd/src. How about adding the stuff that you have in zexyconf.h there? Then every library can benefit. For now, we can just use patches in the Pd-extended build until Miller accepts them. I was planning on starting to make the externals/Makefile stuff use pd/src/config.h anyway, instead of doing a separate ./configure for externals/ in theory i second this. in parctice there are 2 caveats: a) this would actually mean, that people would either change pd's configure.in (which is not possible dues to ACLs) or they would have to patch pd before building an external (which is not acceptable for me, since building against pd-vanilla is really a must for me) b) in zexy and Gem i use some customized m4-modules which i find really cool and would hate to abandon (but i understand if somebody would not want to use them). i think that they are much more elegant than simply using uname's output to decide which flags to use. so i'm sure that i would want to change the configure.in to make it fit to my aesthetics which might break everything, and we surely don't want that. (most likely this is pure vanity, but...) mf.asdr IOhannes PS: btw, i was forwarding all of your personal emails to pd-dev (since i consider them to be of archive-able value); i hope this is ok for you. ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-1609736 ] [pix_movie] and [pix_film] only play solid colors
SourceForge.net wrote: This also happens on Ubuntu, so its not OS-specific. I guess I forgot to mention that. The above Dell Dimension is running Ubuntu Dapper. Is there a certain set of ./configure options to try? please check whether this is related to rectangle-textures (by using [mode 0/1( messages to [pix_texture]/[pix_movie]. mfg.asd.r IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] slowing down dsp function inside perform loop
Georg Holzmann wrote: Hallo! since pd-0.40 you can do DSP-on-demand, by banging the [switch~] object. i have not tested, but it might be, that this DSP-operation is in the message queue. what do you mean by that ? by what? there are 2 parts which might be problematic. mfg.adr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] branch-v0-39-2-extended created
Hans-Christoph Steiner wrote: FYI: I created a release branch called branch-v0-39-2-extended last night following the instructions here: http://puredata.org/docs/developer/Branching I will be making commits to all sections of that branch in order to fix things and get things working. Hopefully, these changes can make it into MAIN too. (So far I have committed pdp and pidip fixes) fine. one quick note: i have just (today) added moocow's pdstring objects to the flatspace library, so that they can be included in pd-extended. obviously i was late; but i really would love them to be added. so it would be nice if you could add this addition to your commits. mf.asr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] mrpeach/net/tcpserver
i just discovered a bug in mrpeach/net/tcpserver the break in mrpeach/net/tcpserver.c:420 effectively makes the broadcast message useless. is there any reason for this? can i change the file? mfg.adr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] mrpeach/net/tcpserver
[EMAIL PROTECTED] wrote:
I get:
if(argc 2)
on line 420, so I don't get it...
oops, you are totally right. vi tells me it is line #459, but by
(x)emacs tells me it is line #420.
this is what you get, when you are trying to be overly cool and just
provide a bare minimum on information...
But whatever it really is, go ahead and change it if you think it works.
diff -u -r1.3 tcpserver.c
--- tcpserver.c 28 Nov 2006 16:42:30 - 1.3
+++ tcpserver.c 12 Dec 2006 08:45:00 -
@@ -443,14 +443,12 @@
static void tcpserver_broadcast(t_tcpserver *x, t_symbol *s, int argc,
t_atom *argv)
{
int client;
-
/* enumerate through the clients and send each the message */
for(client = 0; client x-x_nconnections; client++) /* check
if connection exists */
{
if(x-x_fd[client] = 0)
{ /* socket exists for this client */
tcp_server_send_bytes(client, x, argc, argv);
-break;
}
}
}
the original code would send the data to the first valid client and then
stop the broadcast (by break'ing the loop).
imo, broadcast here means send to _all_ valid clients.
since i think it fixes a bug i will change it.
i was just wandering whether this clause was there on purpose (e.g.
because the system usually locked up or something; i haven't encountered
any problems yet)
mfga.sdr
IOhannes
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] branch-v0-39-2-extended created
Hans-Christoph Steiner wrote: On Dec 11, 2006, at 11:45 AM, IOhannes m zmoelnig wrote: Hans-Christoph Steiner wrote: FYI: I created a release branch called branch-v0-39-2-extended last night following the instructions here: http://puredata.org/docs/developer/Branching I will be making commits to all sections of that branch in order to fix things and get things working. Hopefully, these changes can make it into MAIN too. (So far I have committed pdp and pidip fixes) fine. one quick note: i have just (today) added moocow's pdstring objects to the flatspace library, so that they can be included in pd-extended. obviously i was late; but i really would love them to be added. so it would be nice if you could add this addition to your commits. Yup, its in there. cool thanks. mfa.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] iem16 compilation problem on osx
Thomas Grill wrote: Am 16.01.2007 um 16:13 schrieb Georg Holzmann: Hallo! i already submitted patches for this and other issues with IEM sources to the patch tracker a while ago. IEM stuff doesn't correctly deal with Mac/Intel endianness at the moment. hm ... I can't find that patches (maybe I'm blind ;) ... are you sure that you have submitted them ? http://sourceforge.net/tracker/index.php?func=detailaid=1604140group_id=55736atid=478072 http://sourceforge.net/tracker/index.php?func=detailaid=1604134group_id=55736atid=478072 http://sourceforge.net/tracker/index.php?func=detailaid=1604133group_id=55736atid=478072 well not really, since these patches are against iemlib, and not iem16. here at the iem we have the bad habit to prepend everything with iem which makes people mix them up anyhow, if georg will incorporate the changes as you propose them in your patches i'll be happy. else i will have to it myself. mfga.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Cross-compiling for Windows on Debian
Frank Barknecht wrote: Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: /usr/lib/gcc/i586-mingw32msvc/3.4.5/../../../../i586-mingw32msvc/bin/ld: cannot find -lpd collect2: ld returned 1 exit status make: *** [rvbap.dll] Error 1 Oops, do I read this correctly, that on Windows (or *for* Windows) I need to have some kind of pd.dll to compile an external? And that means, I need to cross-compile Pd first? yes and no. you do need to link against pd.lib you don't need to crosscompile. just get a binary-version for w32 of pd (i usually use miller's pd) and add the path to the pd.lib to your linker-flags: -L/tmp/w32/pd/bin As the clock is ticking for me, I would be really thankful if someone with a working Windows-compilation-setup could compile rvbap.dll for me. I would offer iemmatrix comes with explanations on how to cross-compile it on debian for w32. a really big beer for this, if I can get a hold of rvbap.dll before tomorrow, tuesday, 15:00 GMT+1. ;) forget everything i wrote above. and wait a minute :-) mfgadsr .IOhannes Ciao ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Cross-compiling for Windows on Debian
Frank Barknecht wrote: Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote: Oops, do I read this correctly, that on Windows (or *for* Windows) I need to have some kind of pd.dll to compile an external? And that means, I need to cross-compile Pd first? Hm, sorry for talking to myself, but it seems I could use a pre-compiled binary from Miller's site (I would have preferred a to use a current pd-extended compiled with GCC, but I couldn't find a zip-file. Are there only installers?) Anyways with pointing gcc to the pd.dll inside of that, rvbap.dll finally built and I could even load it running pd.exe with Wine. Seems I'll drink the beer on my own. ;) argh...too late mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] string type for pd
Martin Peach wrote: Thomas Grill wrote: Hi Martin, many thanks for your initiative, it is greatly appreciated! yes, me too! The [str] object contains the other functions, you can see them in str.c in /externals/mrpeach/str. i think that if pd provides the infrastructure, then it also should provide the objects. (e.g. when miller has to accept a patch anyhow, then there should also be a direct benefit to core pd) Should they be public? I was thinking of an object like [list] which has selectors for various functions. please don't! why? apart from that: looking forward to look at it! great. mfg.adr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Fwd: Request for dev access
carmen wrote: I'd also still be interested in getting us over to Subversion, if there is still a supportive group for this? I've maintained several SVN repos now, and feel a bit more up to the task of organizing the project. there are definitely a lot of supporters for this. i think the main problem (were we stopped last time) was to find a directory layout. otoh, the beauty about svn is, that the directory layout can be changed... i'd be more interested in moving us over to Git, so i can stop getting these emails. why would these emails stop more if we were using Git than they would if we were using svn? personally i'd like to investigate about SVK (even though i have no experience with that) what do we need. a webpage to register repos? no. we could use either sourceforge's SVN or host our own at puredata.info. the good thing about the 1st is, that we don't have to care about hardware, backups and the like (even if we only means me) the bad thing is that sourceforge is really overloaded. the good thing about the 2nd is, that the repository is under our full control. we can also use the puredata.info accounts to access the repository (this is already set up) the bad thing is, that we have to take full control over the repository. of course we could also use other hosts (but then each dev has to sign up at yet another website). mfga.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Fwd: Request for dev access
Frank Barknecht wrote: Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: hardware, backups and the like (even if we only means me) the bad thing is that sourceforge is really overloaded. the good thing about the 2nd is, that the repository is under our full control. we can also use the puredata.info accounts to access the repository (this is already set up) This is set up? Way cool! You know, I'm actually getting a bit worried please note that the only thing that is set up is, that the users from puredata.info are accessible for other services (like SVN). subversion itself has not really been setup (apart from some simple testings, proving that the authentication works). furthermore we still would need a way to administer the authorization. (i think you are right about that) fmasdr. IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] tcl 8.5 help browser bug and a fix
Frank Barknecht wrote: Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote: I wonder if the old-fashioned idea of just using the file browser should be available as at least an option... Yes! ;) me too mnfg.ydr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] compile partconv~ for intelmac
hi. Luigi Rensinghoff wrote: Hi Developers, in particular Inte-Mac Users ;-) well probably i shouldnt even try, but i would like to test partconv on an intel mac. So i am trying to compile it myself, which, well...i dont really have enough background knowledge. good (i mean, the fact, that you are trying to compile yourself) cc -bundle -undefined suppress -flat_namespace -o partconv~.pd_darwin partconv~.o /usr/local/lib/libfftw3f.a -lc -lm i686-apple-darwin8-gcc-4.0.1: /usr/local/lib/libfftw3f.a: No such file or directory make: *** [partconv~.pd_darwin] Error 1 ... i was just going to say: install fftw3, but then... So i installed fftw3 with fink because it was missing, but now i encounter the next stop ... i saw that you already did so. did you install the devel-packages of fftw3? (might be called libfftw3-dev or so). if so, did it put a libfftw3f.a file somewhere? if it went to /usr/lib/ instead of /usr/local/lib/ just edit the makefile and replace all occurences of /usr/local/lib/libfftw3f.a by /usr/lib/libfftw3f.a (or wherever the fftw3-dev packages put the .a-file) apart from that, i noticed that i wasn't able to compile partconf~ right now, because i do not understandt the build system. fmgasdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Separating GUI from the engine in PD
Pierpaolo Marcon wrote: I'm trying to put Pd on a DSP processor, but I need to separate completely the Pd engine from the GUI. Does anybody knows if it is available on the web the Pd engine code? (without GUI) pd -nogui will launch pd without gui (no X or whatsoever needed) pd -guiport will connect pd to an already running gui via a network socket (btw: it would be a very cool feature if pd could connect to a remotely running gui, but to my knowledge this is currently not implemented) nevertheless i guess, that on your dsp you will want to run pd without an ip-stack. mfad.sr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] vbap in cvs
Georg Holzmann wrote: Hallo Peter+Hans! Yeah, they aren't hurting anything, they've been there a looong time. So might as well keep them. Yes, but IMHO the cvs is not here for binaries ! (and then why only vbap?) i agree with georg that they should be removed. they should be zipped and put on the sourceforge release page though, so people can download them somewhere. apropos: is it ok, if releases of single externals/libraries are put on the sourceforge release page? or is there some policy that would forbid that (e.g. only few people are allowed actually release managers; if they release only there packages (e.g. because they don't have time or energy to put other people's stuff online), this would make an bias towards their packages which does not reflect the aliveness of the CVS) mfga.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] developer access ?
Luigi Rensinghoff wrote: Hi developers, i am working on a cleaned version of a mac OSX extended Installer and i am almost there. Is thee a place where i can put it so that others can download it ??? Do i need dev-acces for that (sourceforge, wiki-page) ? just if you haven't noticed: i have added you to the pd-devs a few weeks ago. (right after you posted your accountname) if you don't really need it, i will happily remove you again ;-) mfg.adsr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] developer access ?
Luigi Rensinghoff wrote: Are you sure? I think you mean Luke Iannini, not Luigi Rensinghoff. oh, might be; sorry for the confusion...but the subject was so similar... Hm sorry guys... i am talking about a file that is 70 MB. And for some reason the ftp acces doesnt work. I tried all kinds of compinations. Do i need dev access for that ? no, BUT: puredata.info is still not the place where you should store such amounts of data. uploading it to the website will store the data within the database system (instead of the filesystem) leading to degradation of the webservice of puredata.info please do not do that. we are currently trying to find a solution to this problem, so that file-uploads are not stored within the zodb database but instead are just saved as normal files. (georg, move on!) even then, the we cannot guarantee that everybody can store large amounts of data (currently there are 1880 members of puredata.info; we are not google who can offer 2GB mailbox space for everybody, unless people are willing to donate...) the right place to upload such things would be the sourceforge release system. Just to be sure: ftp://[EMAIL PROTECTED]:8021/pd/pd/Members/soundgigi/soundgigi should be the URL no. ftp has been locked. use webdav-ssl: webdavs://[EMAIL PROTECTED]/Members/soundgigi (for smaller data...) mfg.as IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] iem_matrix
just to make sure: iem_matrix is totally deprecated in favour of iemmatrix. it should not be added to the pd-extended build-system. instead it should be removed from the pd-extended build-system. (i don't want to break the build-system so i won't do it ;-)) sooner or later i will remove it from the repository; just now it is there for legacy reasons. mfa.sdr IOhannes [EMAIL PROTECTED] wrote: -- Message: 7 Date: Sun, 18 Mar 2007 20:43:14 + From: Georg Holzmann [EMAIL PROTECTED] Subject: [PD-cvs] externals/iem/iem_matrix/src matrix_orthogonal.c, 1.2,1.3 matrix_pinv.c, 1.2, 1.3 spherical_line.c, 1.2, 1.3 To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Update of /cvsroot/pure-data/externals/iem/iem_matrix/src In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv437/iem/iem_matrix/src Modified Files: matrix_orthogonal.c matrix_pinv.c spherical_line.c Log Message: added iem_matrix to the pd-extended build system Index: spherical_line.c === RCS file: /cvsroot/pure-data/externals/iem/iem_matrix/src/spherical_line.c,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 *** spherical_line.c 14 Dec 2006 20:09:35 - 1.2 --- spherical_line.c 18 Mar 2007 20:43:12 - 1.3 *** *** 4,7 --- 4,10 iem_matrix written by Thomas Musil (c) IEM KUG Graz Austria 2002 - 2006 */ + #include m_pd.h + #include math.h + /* -- spherical_line -- */ Index: matrix_orthogonal.c === RCS file: /cvsroot/pure-data/externals/iem/iem_matrix/src/matrix_orthogonal.c,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 *** matrix_orthogonal.c 14 Dec 2006 20:09:35 - 1.2 --- matrix_orthogonal.c 18 Mar 2007 20:43:12 - 1.3 *** *** 4,7 --- 4,8 iem_matrix written by Thomas Musil (c) IEM KUG Graz Austria 2002 - 2006 */ + #include m_pd.h /* -- matrix_orthogonal -- */ Index: matrix_pinv.c === RCS file: /cvsroot/pure-data/externals/iem/iem_matrix/src/matrix_pinv.c,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 *** matrix_pinv.c 14 Dec 2006 20:09:35 - 1.2 --- matrix_pinv.c 18 Mar 2007 20:43:12 - 1.3 *** *** 4,7 --- 4,9 iem_matrix written by Thomas Musil (c) IEM KUG Graz Austria 2002 - 2006 */ + #include m_pd.h + /* -- matrix_pinv -- */ *** *** 401,405 int n_ls=x-x_n_ls+x-x_n_phls; int n_ambi=x-x_n_ambi; ! int n_ambi2=2*n_ambi; int i, j, k; double *vec1, *beg1=x-x_transp; --- 403,407 int n_ls=x-x_n_ls+x-x_n_phls; int n_ambi=x-x_n_ambi; ! int n_ambi2=2*x-x_n_ambi; int i, j, k; double *vec1, *beg1=x-x_transp; -- Message: 8 Date: Sun, 18 Mar 2007 20:43:14 + From: Georg Holzmann [EMAIL PROTECTED] Subject: [PD-cvs] externals Makefile,1.135,1.136 To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Update of /cvsroot/pure-data/externals In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv437 Modified Files: Makefile Log Message: added iem_matrix to the pd-extended build system Index: Makefile === RCS file: /cvsroot/pure-data/externals/Makefile,v retrieving revision 1.135 retrieving revision 1.136 diff -C2 -d -r1.135 -r1.136 *** Makefile 18 Mar 2007 10:43:02 - 1.135 --- Makefile 18 Mar 2007 20:43:11 - 1.136 *** *** 125,129 # WARNING! this MUST be all on one line because the automatic package # building scripts rely on it being that way. ! LIB_TARGETS = boids bsaylor creb cxc cyclone deprecated ekext ext13 flatspace flib freeverb ggee hardware hcs hidio iem_ambi iem_bin_ambi iemlib jasch_lib loaders mapping markex maxlib mjlib motex mrpeach msd oscx pan pddp pdogg pmpd sigpack smlib toxy unauthorized vbap zexy pdcontainer adaptive iem_delay iem_roomsim iem_spec2 iem_tab flashserver iemgui iem_adaptfilt iemmatrix iemxmlrpc iem16 earplug # this is for libraries that don't compile (yet) on all platforms --- 125,129 # WARNING! this MUST be all on one line because the automatic package # building scripts rely on it being that way. ! LIB_TARGETS = boids bsaylor creb cxc cyclone deprecated ekext ext13 flatspace flib freeverb ggee hardware hcs hidio iem_ambi iem_bin_ambi iemlib jasch_lib loaders mapping markex maxlib mjlib motex mrpeach msd oscx pan pddp pdogg pmpd
Re: [PD-dev] iem_matrix
Georg Holzmann wrote: Hallo! just to make sure: iem_matrix is totally deprecated in favour of iemmatrix. it should not be added to the pd-extended build-system. instead it should be removed from the pd-extended build-system. (i don't want to break the build-system so i won't do it ;-)) Yes I know - but I need it to get quite some examples working for the linux audio conference ... I did not look into is so deep - is it possible to make patches with iemmatrix, which we can use instead of iem_matrix ? (then we could put them in the iemmatrix/alias folder to keep the backward compatibility ...) i think all of the iem_matrix objects are covered by iemmatrix. basically all objects in iem_matrix are specialized versions of [mtx_*~]. however, i believe that [mtx_*~] is now so optimized, that you will not gain anything from using the specialized versions, but you lose a lot of flexibility. noteable is probably the [matrix_diag_mul~] group of objects, which is is nothing more than zexy's [multiline~], but requires people to know about matrix math. mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] zexy with regex in Pd-extended ?
Hans-Christoph Steiner wrote: Sure, I thought it was already. regex.h is already installed on all of the auto-build machines. I guess someone just needs to fix the compilation. A bug report would probably be good to keep track of it. hmm, this is very weird: zexy's configure does find the regex.h file (at least in the debian-testing-i386_pd-extended-release log of today), so [regex] should definitely be in. which exact version of pd-extended are you using? (nightly build? which day?) fmasdr. IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] vbap in cvs
Hans-Christoph Steiner wrote: It would be good to keep the sourceforge page uncluttered, and adding all these sections would make it much more cluttered than it already is. But I do think it's a good idea to post the binaries one a website and remove them from CVS. i don't think that this would clutter the sourceforge page. there is already a number of external packages in the download section, most of them seem to be unmaintained. (which kind of invalidates your argument about using wiki for stuff that does not get updated on a regular basis) the current sections are, in order of appearance: pd-devel (outdated? - last mid 2005) pd-extended (early 2006) pd-externals (OUTDATED - early 2003) pd-gem (early 2003) pd-osc (outdated - 2002) pure-data (uptodate - end 2006) i believe, that this page would be more useful if there were lots of uptodate packages. however, an example for an unstructured download page with lots(!) of packages (currently over 80!), is the plone-collective (projectname: collective) found at http://sourceforge.net/project/showfiles.php?group_id=55262 now this is _really_ a one-stop shop for loads of things. while the list is long, it is still managable to find what you need if you know what you are looking for. if you do not know what you are looking for, then everything with more than one package will get you lost. i agree though, that the puredata download page could and should be structured (which it is currently not). since sourceforge orders packages alphabetically, one would just have to find a naming scheme, where: pd-vanilla is at the top, pd-extended is prominent too, pd-externals are grouped together (though distinguishable via package names!) somewhere below. pd-develdesiredata could go next to pd-extended and pd-vanilla (if desired). i don't think that pd-devel/desiredata should go _before_ pd-vanilla and pd-extended. so i would think of something like (annotations in ()) - pd - pd-extended - pd-external-ann - pd-external-osc - pd-external-zexy - pure-desiredata - pure-devel a probably nicer way would be: - pure-data - pure-data-extended - pure-desiredata - pure-devel - pure-ext-ann - pure-ext-osc - pure-ext-zexy i don't know whether it is possible to rename already release package-sections, but i guess not (like so many things on sourceforge). (but after a check i see, that it is possible to hide packages, so one could eventually fake a renaming by hiding the original one and creating a new one) How about puredata.info for random things that won't be regularly updated? There is the download wiki exactly for things like this. i do not agree here. the download wiki is a place to get information. the sourceforge release system is a place to get stuff. as said before, i would prefer if large amounts of data would not be hosted at puredata.info (yet). the sourceforge release system provides a world-wide distributed, redundant, high-bandwidth download system, something we could _never_ provide on our own. so why not use it? mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] External compilation linux-windows
Nicolas Montgermont wrote: It seems mingw32msvc can't find any pd function... but the linux to linux part works well (see attached) Do someone understand where is the error? Or better, already have a makefile to cross compile? Sorry if it's stupid, I'm not really used to makefiles... you have to link against pd.lib. have a look at iemmatrix, there is a description how to cross-compile it with mingw. mfgas.dr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] zexy: ~, ~, ==~ not working on osx: hexloader problem?
moved this to pd-dev... Hans-Christoph Steiner wrote: On Apr 18, 2007, at 11:19 AM, IOhannes m zmoelnig wrote: how should i proceed? Hmm, I like the idea of encapsulating the hexloader code, but I think if the hexloader is a separate loader, then the other loaders won't benefit from its translation of non-alphanumeric ASCII. I think the way the loader stuff is implemented, it is just a failover, if the first loader fails, then the next one tries. I think that the classname should be the filename not only for objects written in C and Pd, but also any other language. i agree, but i don't see a way to achieve this. even if the hexloader is in the pd-core there is still no way to use the hex-expansion from within other loaders. If you are rearchitecting this stuff, I would like to make a suggestion. What I would also like to see is that the hexloader is split into two naming schemes: file system, which would translate only / \ : * ?| and the setup function, which would do the whole translation. That would make the files a lot more readable. this is basically a good idea. the reason why i did not go the entire way is that i am not sure whether '/ \ : * ?|' is the entire set of forbidden characters on all filesystems. the way i am currently (in the new hexloader loader) doing it, is just trying to expand the classname in several ways and then trying _all_ expansions (including the original classname) as both filenames and setupnames. adding another expansion is just trivial. i don't see any real reason for differentiation between filenames and setup-routines as long as the entire set is tested. (e.g. with class v* i am now doing a test for v*_setup() in v*.l_i386 and v0x2a.pd_linux even though v*_setup() is not a valid functionname in C. i don't think that there is any harm in this. If the loader is the route you end up taking, the CVS directory hierarchy sounds good to me, feel free to move the libdir loader to it's own folder, or leave it. i think i'll move it and hope to not break things. mfga.sdr IOhanens ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] sysloader problem
hi miller, all. i am currently having troubles implementing the hexloader as a system-loader. while things work rather straightforward in external/library land, it stops being trivial when it comes to loading abstractions via a system-loader. (this is needed since the hexloader mainly applies a different objectname-filename mapping, which should eventually work for abstractions too) the problem is, that in the context of the loader, i have no idea about the arguments for the object instance. unfortunately abstractions do not have the abstract class vs instance separation like binary objects, so the only way to instantiate them seems to be to directly evaluate them with the arguments available in some context. ultimately it would be good if patches would be loaded with the same mechanism as other externals within the pd core (this is: with a separate patch_loader() that is registered just like the lib_loader()) a temporary workaround would be some way to access the arguments passed to a yet-unknown object from within the loaders. mfasd.r IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] add_string_support.patch
Hans-Christoph Steiner wrote: I just noticed this in the build logs. Looks like the patch isn't applied at all. I think the problem is that there is a relative path in the filenames, while the working ones just have the filename, i.e. this doesn't work: |--- pd/src/g_text.c 4 Oct 2006 19:35:06 - 1.15 |+++ pd/src/g_text.c 12 Feb 2007 03:45:43 - This works: --- g_rtext.c 6 Sep 2004 20:20:34 - 1.4 +++ g_rtext.c 14 Dec 2005 03:59:31 - .hc Applying /home/pd/auto-build/pd-extended/packages/patches/ add_string_support.patch can't find file to patch at input line 8 Perhaps you used the wrong -p or --strip option? so perhaps you used the wrong -p or --strip option... try -p 2 fmga.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] opencv motion tracker external HELP!
Nose Hair wrote:
I think I figured it out. It looks like I have to use t_symbol *sym
instead of t_symbol sym and the outlet has to be x-outlet_new(x-
x_outlet0, *sym). That seemed to work. The weird problem I am
having now it I get an error with the return(void *)x; I get error:
return-statement with a value, in function returning 'void'.
in the function declaration you seem to declare your function like:
void funname(...)
which means that you do not intend to return anything.
then in the function body you do return something of type (void*);
this is illegal.
even you replace void with int (or any other type) this would be
illegal: a pointer to an object is not the same as an object of that type.
with void things are a bit more complicated (conceptually, not
practically): (void) is synonymous for 'nothing', whereas (void*) is
synonymous for 'pointer of undefined type'
Now I see return(void *)x; on almost all the external codes so I
don't get it. I am also getting an error on the void your_class_setup
(void) { part too.
most likely you have unmatched pairs with your paranthesis.
use an editor that does paranthesis highlighting and parantheses based
indentation to track this down. (or just read your code carefully ;-))
mfg.asd
rIOhannes
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
[PD-dev] iem16 troubles
[EMAIL PROTECTED] wrote: -- Message: 4 Date: Wed, 30 May 2007 04:32:12 -0400 (EDT) From: [EMAIL PROTECTED] (Pd User) Subject: [PD-cvs] autobuild: pd-extended macosx104-powerpc 2007-05-30 03.15.04 To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] /Users/pd/auto-build/pd-extended/externals/iem16/src/iem16_table.c:213: note: LOOP VECTORIZED. /Users/pd/auto-build/pd-extended/externals/iem16/src/iem16_table.c:204: note: vectorized 1 loops in function. /Users/pd/auto-build/pd-extended/externals/iem16/src/iem16_table.c:75: note: LOOP VECTORIZED. /Users/pd/auto-build/pd-extended/externals/iem16/src/iem16_table.c:75: note: vectorized 1 loops in function. /Users/pd/auto-build/pd-extended/externals/iem16/src/iem16_table.c:148: note: not vectorized: stmt not supported: D.3479_62 = (short int) D.3478_61 /Users/pd/auto-build/pd-extended/externals/iem16/src/iem16_table.c:148: note: vectorized 0 loops in function. cc -bundle -bundle_loader /Users/pd/auto-build/pd-extended/pd/bin/pd -L/sw/lib -o /Users/pd/auto-build/pd-extended/externals/iem16/src/tab16read.pd_darwin /Users/pd/auto-build/pd-extended/externals/iem16/src/iem16_array.o /Users/pd/auto-build/pd-extended/externals/iem16/src/iem16_table.o -lm -lc /usr/bin/ld: multiple definitions of symbol _table16_class /Users/pd/auto-build/pd-extended/externals/iem16/src/iem16_array.o definition of _table16_class in section (__DATA,__common) /Users/pd/auto-build/pd-extended/externals/iem16/src/iem16_table.o definition of _table16_class in section (__DATA,__common) collect2: ld returned 1 exit status just to reiterate myself: i can compile and run iem16 on linux and os-x as a _library_. splitting it up into single externals (for pd-extended) and declaring the table16_class as static (to avoid the above compile error), produces a binary that is useless. therefore, if iem16 is to be included in pd-extended, i suggest building it as a library. mfga.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] iem16 troubles
Georg Holzmann wrote: Hallo! just to reiterate myself: i can compile and run iem16 on linux and os-x as a _library_. yes, but also only if you NOT declare table16_class as static, which leads to the compile error on osx ... yes, sorry if this is unclear: the reason for all this is that table16_class must NOT be static in order to make the objects work. this (that is: NOT declaring table16_class as static) leads to the compile error on osx, if compiled with pd-extend's build-system as single externals (it compiles fine with _my_ buildsystem) the fix is NOT to make the class static (which breaks the object), but to fix the linkeage. (this is basically what georg is saying) fmga.sr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-1738708 ] won't open files with $0 in file name
IOhannes m zmoelnig wrote: still frank is right when he says you shouldn't upload filenames with spaces to the sf tracker... and i add that you shouldn't use filenames with spaces at all. (though you could try to name your directories AUX, which is fun too...) on rereading this, i want to add that you is no-one particular, but rather anyone. so you are rather suggesting that people should be able to File-Open here the you is someone special. fmga.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] changing netsend [was: automatically send lists with [udpsend]]
Frank Barknecht wrote: might be that my reasoning is not completely in-line with pd-vanilla (compare the send message to [netsend]) At first I thought, changing [netsend] so that it behaves the same would be cool as well, however [netreceive] differentiates between foo 1 and list foo 1. Hm, ... true. and there is almost[1] no way to prepend send to list a b c with native objects...: the result will most likely be send a b c which will become a b c after [netreceive] (actually after [netsend]) which is not list a b c. hmm, hmm... mfga.sdr IOhannes [1] of course it IS possible, but somehow awkward: | [route list ] | | | [list prepend send] | | [list prepend send list] | | | +-+ | [list trim] | ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] cleanup of CVS
Chris McCormick wrote: 1. IEM? (is this an option?) pros: cons: lots of work for IOhannes. 2. savanna.nongnu.org pros: cons: 3. Rent a dedicated server. pros: we have total control. cons: we have to install and set up. costs money. i do not fully understand the difference between 1. and 3. we could rent a dedicated server at the IEM :-) as for savanna: how is this different from just staying at sourceforge? mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] cleanup of CVS
Chris McCormick wrote: On Wed, Jul 04, 2007 at 11:50:00AM +0200, IOhannes m zmoelnig wrote: Chris McCormick wrote: 1. IEM? (is this an option?) pros: cons: lots of work for IOhannes. 2. savanna.nongnu.org pros: cons: 3. Rent a dedicated server. pros: we have total control. cons: we have to install and set up. costs money. i do not fully understand the difference between 1. and 3. we could rent a dedicated server at the IEM :-) We can? Ok. If we rent, we would need to evaluate the different options for price, features, etc. organizatorical i don't know whether this would be possible (from the university side). but puredata.info _is_ a dedicated server (not just a vhost or something). so the difference between 1 and 3 is, that the iem pays for #1 while somebody else would have to pay for #3. i have the impression (being administrator of this server), that we (that is: the pd-community) do have full control of puredata.info. obviously not everybody has root access to this machine, but i doubt whether it would be a good idea to give everyone root-access to a rented server (#3). I was under the impression that the IEM option was IEM donating server resources with yourself doing the administration. yes you are correct, but how does this differ from 3 (see above) as for savanna: how is this different from just staying at sourceforge? We know the SF sucks. Do we have evidence that Savanna sucks? i do not have evidence that savanna sucks. but i'd rather have evidence that it does not suck, before going there. Let's add an option: 4. Stay at sourceforge but transition to SVN. pros: easy. cons: SF sucks. honestly, i think it does not suck so badly. (they _did_ have hardware problems last year, which was unbearable; but this could happen to every hoster, be it savanna, iem or sourceforge.) i still vote for either staying at sf or going to iem. the main reason for this is the user-migration. somebody should come up with a good layout ofthe svn-repository (actually i think that this is the point where all the former attempts died) and finally one call for help to all those subversion/ldap experts out there: an administrative problem i do have at puredata.info is, how to handle permissions (that is: write-access to sub-branches of the repository) effectively. i would like to give a diffuse group of developers (which are all members of an LDAP-group) write access to the entire repository, except for some special branches, e.g. pd-vanilla, where only miller (and some admins) have write access. i guess the simplest way to acchieve the latter (special permissions on sub-trees) would be to just manage an access.conf file via the puredata.info homepage. for the former, does anybody know how to handle ldap-groups in subversion? is this possible at all?? mfga.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [pd-cvs]: externals/ggee/gui envgen.c, 1.10, 1.11 (Hans-Christoph Steiner)
[EMAIL PROTECTED] wrote:
Log Message:
added error report to [sustain( message
--- 203,209
{
if (f 0 f x-last_state)
! x-sustain_state = f;
! else
! post(ERROR: sustain value not betweem 0 and %f,x-last_state);
}
tip of the day:
there are 2 dedicated error-reporting messages in pd: error(%s,...)
and pd_error(x, %s,...) which should be used instead of post(ERROR:
%s,...)
the 2nd one being especially cool, as it allows to find the object that
threw the error.
vfg.mfg.fasr
IOhannes
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [pd-cvs]: externals/ggee/gui envgen.c, 1.10, 1.11 (Hans-Christoph Steiner)
IOhannes m zmoelnig wrote:
[EMAIL PROTECTED] wrote:
Log Message:
added error report to [sustain( message
--- 203,209
{
if (f 0 f x-last_state)
! x-sustain_state = f;
! else
! post(ERROR: sustain value not betweem 0 and %f,x-last_state);
}
tip of the day:
there are 2 dedicated error-reporting messages in pd: error(%s,...)
's|messages|functions|'
mfg.asdr
IOhannes
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] GPLv3
Hans-Christoph Steiner wrote: Hey all, I am thinking of changing my license to GPLv3. The only forseeable problem would be if people have taken out the or (at your option) any later version from the standard GPLv2 text, thereby tying the code to only the GPLv2. is there a reason for this switch? (apart from staying current) i haven't followed the discussion about GPLv3 in the last month, but last time i did it was _very_ controversial... mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PD-cvs Digest, Vol 29, Issue 11
[EMAIL PROTECTED] wrote: Message: 6 Date: Wed, 11 Jul 2007 17:34:40 + From: Martin Peach [EMAIL PROTECTED] Subject: [PD-cvs] externals/mrpeach/osc packOSC-help.pd, 1.6, 1.7 packOSC.c, 1.6, 1.7 unpackOSC.c, 1.3, 1.4 routeOSC-help.pd, 1.2, 1.3 To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Update of /cvsroot/pure-data/externals/mrpeach/osc In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv5352 Modified Files: packOSC-help.pd packOSC.c unpackOSC.c routeOSC-help.pd Log Message: unpackOSC now simply outputs (through the right outlet) a delay in milliseconds when it receives a timetag, as the timetag itself is not useable inside pd. The delay is zero when the timetag is in the past. Help patches have been updated to match. Also corrected a mistake in packOSC.c timetag calculation. cool feature, thanks martin. however, i have 2 remarks: the simple one: is it possible to set the current timetag within the [packOSC] and the [unpackOSC]? usually 2 osc-hosts should be synchronized via ntp, but who knows... otoh, this might be rather low priority... the more complicated one: 0 for past events is (imho) not a very good choice. how should we distinguish between bundles that have just arrived in time (where the natural delay is 0), bundles that are tagged immediately, and bundles that arrived too late. one solution might be to use negative delays: delaying objects, such as [delay] and [pipe] just ignore negative values (so they behave the same as when fed with 0), but the user has the option to determine whether the message arrived to late and can act accordingly (e.g. discard messages that should have happened yesterday) i haven't looked at the code, but what happens when a bundle is to be processed immediately: a delay of 0 is _not_ the same as no delay, as can be seen in: [bng] | [trigger bang bang bang] | | [print c] [print a] | [del 0] | [print b] which will result in c, a, b so if i am to honour the timetags (via [del] or whatever), my immediate messages will not be handled immediately (it sounds worse than it is: due to the nature of network traffic, we could always assume that the immediate bundle arrived a fraction of a second later...; nevertheless i think it might be very good if i could distinguish between the 3 types of timetags) mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PD-cvs Digest, Vol 29, Issue 11
Martin Peach wrote: one solution might be to use negative delays: delaying objects, such as [delay] and [pipe] just ignore negative values (so they behave the same as when fed with 0), but the user has the option to determine whether the message arrived to late and can act accordingly (e.g. discard messages that should have happened yesterday) OK, I'll put in negative delays. great. and i forgot to mention, that you can always connect the 2nd outlet to a [max 0] so you get the original behaviour. That's a difficult problem. What's the difference between zero and zero? I mean how does one tag no delay as being different from a delay of zero without adding another outlet? There's a problem with unpackOSC at the moment in that if no time tag is received there is no output on the second outlet, so you have to externally zero the delay line after every message. that is _good_ news, as it allows one to detect the absence of a timetag. (no message is a message too...) one could also use bang as a more explicit indicator, but then one would _have_ to acknowledge the type too. (it's not such a good idea to send the bangs to the right inlet of [del]; but then this would enforce people to really take care of the timetags (if used at all), which is not necessarily a bad thing) so i am happy with anything that allows me to distinguish between now and immediately. another question: in osc, timetags are per-bundle (not per message). is the scheduling information sent to the outlet for each message or only once for each bundle? fgmas.dör IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] recursion in Gem - a tutorial
Patrice Colet wrote: I tried to make DLLs of nrepeat and nnrepeat, but it seems I'm too ignoramus to find out how to proceed, I've entered those lines in the msys shell i haven't had a look at the tutorial files, but i was wondering why you couldn't build [nrepeat] (i haen't seen [nnrepeat] on the website, so i don't know what it does) with [repeat] or with the [s]/[r] idiom claude has proposed. see attached patch for a solution using zexy's [repeat]. mfgasdr IOhannes #N canvas 328 242 450 300 10; #X obj 84 52 inlet; #X obj 84 75 t a b; #X obj 84 103 repeat \$1; #X obj 84 144 t a b; #X obj 114 164 i; #X obj 144 204 + 1; #X obj 114 183 t f f; #X obj 114 232 outlet counter; #X obj 84 251 outlet count; #X msg 132 144 0; #X obj 142 52 inlet repititions; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 1 1 9 0; #X connect 2 0 3 0; #X connect 3 0 8 0; #X connect 3 1 4 0; #X connect 4 0 6 0; #X connect 5 0 4 1; #X connect 6 0 7 0; #X connect 6 1 5 0; #X connect 9 0 4 1; #X connect 10 0 2 1; ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] please add 'mokhov' to pure-data at SF.net
Serguei A. Mokhov wrote: Hi, hi serguei I will soon be completing my PD external(s) for the upcoming PDCon07. I would like to able to commit them to the PD repo once I am ready. For this, could you please add SF.net 'mokhov' to the project. as we (at least: i) do not know anything about you, it would be nice if you could introduce yourself, tell us what you are doing and why it would be especially important to have your external(s) in the cvs. (this is just the standard procedure how we handle things here: once you have submitted all the relevant information and no one objects, an admin will add you to the devs; this process of lazy consensus usually takes some days) mfg,asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pdstring's crashing
Bryan Jurish wrote: moin again, the fastest lurker on the list... the new code has been checked into cvs as externals/moocow/pdstring v0.04 ... let me know if it works (or doesn't)... and send me some sequence of inputs that reproduces the error if you can find one... thanks bryan. i have not been able to test your changes under our conditions, i'll tell you when i know more. mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] any2string problem
Hans-Christoph Steiner wrote: There is a glitch in any2string that is stopping Pd-extended from building: i fixed that yesterday. and it is rather a glitch in the assumptions the externals/build/src/ makes than in the pdstring, which just builds perfectly. mf.adsr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] PD externals/extras/OSC and RT and JACK
Hans-Christoph Steiner wrote: 3) I found the source to OSCx on SourceForge, but it looks ancient (i.e. from 2002), which includes it's own statically-linked (and very old) version of libosc. Is that really the latest release? I'm thrilled that PD makes working with MIDI so easy, but I am going to want to use OSC too. This part of your post really confuses me. The OSCx stuff works quite well. Why is it a problem that the code is old? probably because it is not maintained but buggy? By the way there is a new OSC implementation in the mrpeach folder, take a look if you are worried about OSCx. For the record though, I've been using sendOSC and dumpOSC for quite some time now and they work very well. i was fine with the OSCx objects, until i tried to send a big (not a _really big_ message, just _big_) message and it crashed. see my bug report on this. Hey, I am curious, does OSCx implement time tagging at all? IIRC, that's one of the advantages of mrpeach's OSC objects. and that is another reason why mrpeach's objects are more interesting. mgfa.frt IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] state-saving / properties in abstractions...
hi all. after talking to hans at the convention, i have created 2 new externals: [propertybang]: outputs a bang when you select the property menu-item for the abstraction that holds this object. [saveargs]: allows you to change the arguments of the abstraction that holds this object in the next save. these 2 objects allow a persistent property handling (and eventually a state-saving of abstractions a la iemgui-objects, though this might eventually be costy. the remaining question is: where to put these objects; they are not really zexy (since they depend on g_canvas.h, which is not yet found in zexy), and i have not found a general hack pd interna lib. suggestions? else i will probably ask thomas to include it into iemlib(2), as it somehow fits to the [dollarg] and [parentdollarzero] objects. fma.sr IOhannes PS: hans, i thought you would do the property-side of this. seems you are late :-) ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] state-saving / properties in abstractions...
Hans-Christoph Steiner wrote: Wow, awesome! You beat me to the whole thing. Can't wait to try them. iemlib is fine by me, as long as it doesn't restrict your access to them. since thomas is unavailable for the next 2 weeks, i just decided to put them into another new library iemguts which can now be found within the externals/iem folder. Basically all the libs are such random grab bags, I don't think it currently matters much. i wouldn't say that. some are, others aren't (at least some of my libs aren't :-)) mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] kiosk mode (was: Re: [ pure-data-Patches-1529010 ] kiosk-mode)
marius schebella wrote: great! can you explain how kiosk mode is invoked? is there a flag at start up, or can I change to kiosk mode during runtime? or is it a totally different version than the normal pd and I can only run either/or? can you send a screenshot how it looks? is it already included in one of the sources or do I have to patch the source code to get the kiosk version? marius. well, look at the tot-example tot-nomenu.pd the only thing you need is tot installed and then make clever use of it. attached is an example: nomenu-test.pd which get's rid of menu-bar and keyboard shortcuts by just adding the [nomenu] abstraction. mfg.asdr IOhannes #N canvas 128 254 589 317 12; #X msg 54 142 debug; #X msg 10 57 tot destroy .^.m \, tot bind .^.c Control-Key ; #X msg 41 92 tot global sz .: set sz [wm maxsize .^] .: wm geometry .^ [expr [lindex $sz 0] - 20]x[expr [lindex $sz 1] - 20]+20+20; #X obj 10 178 tot .parent; #X connect 0 0 3 0; #X connect 1 0 3 0; #X connect 2 0 3 0; #X connect 3 3 1 0; #N canvas 0 0 450 300 10; #X obj 194 194 nomenu; ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] cleaning up the list of developers
Tim Blechmann wrote: i am not really a fan of removing people from a project, but maybe one could distinguish between 'active' and 'retired' developers ... retired developers should loose their cvs access, but still kept in the sourceforge developer lists ... i agree with hans that i don't understand the reasoning behind this. the list of project participants should not be mistaken as an authors list (there are lots of contributors of pd-core, external- and abstraction- code who have never enroled in the pd-cvs) and deleting somebody from the list of project members is not an attempt to undo history. the repository logs will still hold the name of the original author. I propose that we leave Gerard van Dongen and Jamie Tittle on the list since they are still with us in spirit. i regret that i do not fully understand this request either. while both of them have contributed a lot and chances are high that they would be contributing if they were still with us, i do not see a point in treating them as if they were still among us. a usual clause for vereins-members (in morbid austria) is, that their membership ends with their death. personally, i would not want to do the removal of jamie or gerard just because they are no longer with us. but i have little problem in having their sourceforge accounts be part of an automated process. mfa.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] cvs access
David Plans Casal wrote: a documentation duplication can be found at http://puredata.info/dev/cvs, where the information is correct. Hrm. Perhaps we could merge? or is that page duplicated for a reason? no! you might break the carefully thought of layout :-) mfga.sdr IOhannes PS: i don't have objections but this will raise the question which site is the duplicate and this might not be easily solvable on this list... ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] kiosk mode (was: Re: [ pure-data-Patches-1529010 ] kiosk-mode)
Hans-Christoph Steiner wrote: On Sep 10, 2007, at 9:47 AM, IOhannes m zmoelnig wrote: That sounds quite handy. It should definitely be in some lib somewhere. well, it already is in some lib: toxy (my patch is really just one of the example-patches slightly modified) Unfortunately, it seems to have no effect on Mac OS X, which uses Cmd instead of Control, and the windows don't have menubars anyway. well, i guess it is trivial to remove the Cmd-bindings too (just in case). and i don't know how to remove the menubars of windows that do not have any :-) fmga.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] repository layout
hi. after the talk about svn at the pd-con, it seems like there is a general ok from the community, if somebody would be willing to perform the actual migration. actually i could be this volunteer. ad miller: there exist migration paths from both cvs and svn to git, so svn would do no harm before we can switch to git :-) about the structure: i have written down some ideas on how an svn-repository could be structured at http://puredata.info/Members/zmoelnig/pdcon07/SubVersion basically the layout keeps the same, but with svn-specifics like meta-directories trunk, tags and branches. ideally (for me) the layout of trunk would be: /trunk/pd/ /trunk/pd-devel/ /trunk/desiredata/ /trunk/externals/ /trunk/packages/ /trunk/scripts/ /trunk/doc/ differences to the current layout are: - moved abstractionsextensionsxguiFramestein into externals - desiredatapd-devel live beside pd (not in a separate branch) - htdocs is deprecated (but could as well move into doc) - supercollider has moved into scripts (i am not sure about this, but it seems to be the best place, since bash_completion is already in there; supercollider is no external, it is rather a set of sc3-scripts to ease the use of pdsc together) the layout of tags would be: /tags/pd-0.40-4/ /tags/pd-0.41-1/ /tags/desiredata-0.39-1/ /tags/zexy-2.1/ /tags/pd-extended-0.39.2-rc1 ... (that is: a _very_ flat structure of released code) the layout of branches would be almost the same as that of tags (but tagged revisions should not be touched any more, whereas branched revisions can be bug-fixed...) both branches/tags should only be used for: - releases (+maintenance) - legacy (discontinued) projects it is my believe that tagsbranches should mainly be used for people who want to checkout working code (!), rather than developers who want to try something out without interfering with the existing code-base (trunk) for quick experimental branches (e.g. if you want to implement a feature but do not want to spill the trunk), i would suggest a 4th meta-directory experimental, like: /experimental/pd-0.40-kiosk/ /experimental/pd-extended-0.39-newbuildsystem/ projects in experimental are not meant to be continued, but their changes should go back into the main trunk (either by merging into the original project or by living besides it) in any case, these experimental branches should be deleted when finished, in order to keep the directory-layour reasonably small. comments are highly welcome fgmasd.r IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] repository layout
Mathieu Bouchard wrote: On Tue, 11 Sep 2007, IOhannes m zmoelnig wrote: - moved abstractionsextensionsxguiFramestein into externals good thing, as long as abstractions does not become a subfolder of externals... but I would rather have it under a common name that isn't abstractions nor externals. I suppose that xgui and Framestein retain their folder, whereas abstractions, externals, extensions contents are merged together. this is basically correct: ./Framestein will become externals/Framestein ./abstractions/purepd/ will become ./externals/purepd ./abstractions/footils/list-abs will become ./externals/footils/list-abs - desiredatapd-devel live beside pd (not in a separate branch) If Thomas hasn't changed his mind, pd-devel is going to be obsolete soon. The latest changes still have to be picked up from there and moved somewhere else, such as sf.net patchtracker and the desiredata branch, but for all practical purposes, there will be no such branch. Let me also say that pd-devel very much deserves to be a branch (rather than a plain folder) because it has rather high mergeability with Miller's branch. yes this fits perfectly into my layout: once pd-devel is abandoned by all active developers (this is: thomas), the folder will be _moved_ from ./trunk/pd-devel to ./tags/pd-devel/pd-devel-versionnumber (or the like) all the revision history will stay intact while at the same time, nobody has to care about a dead pd-devel laying around in the trunk. if, at some point, somebody desides to re-start pd-devel (not that i think somebody would; but just as a theoretical example), the latest folder (from which one would like to start) would be _copied_ to the trunk. In contrast, for the new DesireData (since dec.2006), I no longer attempt mergeability of any part of it. There's no future goal of keeping any part of the code in sync with pd for any reason whatsoever. All the sync necessary is to be done using automated tests (no matter how much work that is, it's worth it) that is exactly why i do think that folders are so much better than tags. currently, desiredata is a branch of pd, implying a common code-base. a folder is just a folder, it doesn't imply very much. i believe that putting desiredata besides pd gives both of them a kind of equality. - supercollider has moved into scripts (i am not sure about this, but it seems to be the best place, since bash_completion is already in there; supercollider is no external, it is rather a set of sc3-scripts to ease the use of pdsc together) scripts is a vague name I'd get rid of. Also, gripd contains a high ratio of non-abstraction, non-external files. I don't know whether this ought to be taken into account when categorising projects... most stuff in scripts currently are scripts. supercollider would not necessarily fit in there (bash_completion is not a script either, that's what made me think of that) probably we should just create a new category misc _besides_ scripts, and put both supercollider and bash_completion (and probably gripd in there) both branches/tags should only be used for: - releases (+maintenance) - legacy (discontinued) projects for quick experimental branches (e.g. if you want to implement a feature but do not want to spill the trunk), i would suggest a 4th meta-directory experimental, like: /experimental/pd-0.40-kiosk/ I don't know why you want this. You say what people should do according to yourself, but you don't explain what's your motivation for it. my motivation behind all this is to keep it simple on the long run. however, i admit that this motivation might lead to over-complicated plans (which is bad). otoh, i think if there are some guidelines on where to put stuff, i guess people might happily accept them (even if these guidelines might seem to be sub-optimal on the first glance). finally, a suggestion implies discussion: i do not say what people should do according to myself, but i rather ask them whether they would like to do it my way; this is a difference btw, i find it herzerfrischend that you so readily discovered that there are only my projects in my proposal of an experimental folder. fmga.r IOhannes _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada ___ 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] repository layout
Hans-Christoph Steiner wrote: As for 'scripts', there needs to be a place for all the scripts needed to build Pd-extended. Whether that's also the place for bash_completion, etc, that's a separate question. but since it is the pd-repository rather than the pd-extended repository, it would probably be more appropriate to put all the scripts solely needed for pd-extended into /misc/pd-extended/ rather than /scripts/ i think bash_completion is in there, because scripts are often associated with sh (and bash), and because of lack of a better section. fmga.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] repository layout: tags
Hans-Christoph Steiner wrote: #TAGS:misc import (htdocs pd-msg aenv~ bsaylor susloop~ svf~ vadsr~ xgui zhzxh~) These tags are useful for handling imported code that is maintained elsewhere. thats what the documentation says. have you ever made any use of the useful thing? Does SVN handle this differently? yes and now. yes: you don't _have_ to create a tag and a branch whenever you import code. no: you can import code that is maintained elsewhere into a branch, a tag, the trunk (or just any other directory) yes: svn is able to handle references to external (svn!)repositories (which imo is better than blindly importing anything useful) so the answer is: you can do it like you did in cvs, but you can handle it more appropriate at your own judgement. There are more like this. Purging tags could be a tricky proposition. I think the purge list should be opt-in rather than opt-out to prevent losing important data. well yes, i would agree. but who remembers that there was a dacblocksize branch of pd? who works on this? will there ever be work done on this again? (fyi: dacblocksize is a branch i have made; the purpose of the branch has been reached (although the code never made it into pd); i have not worked on it for some years; i have no plans to work on it ever again (and if i did, i would have to start from the beginning anyhow); i have plainly forgotten that this branch ever existed; i would love to see it deleted) i hope that (more) people read more carefully in an opt-out process. (even though it could be really handled as an opt-in) finally, did i say purging? i should have said deleting (within the version control system, rather than purging outside it); no data will be lost: you can always go back to an older revision to retrieve the data) fmga.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] repository layout
Winfried Ritsch wrote: Hello, I just missed the pdconv, so how is the authorization for the repository planed ? Is it possible to restrict access to a subfolder ? no, since the plan is to stay with sourceforge for now, there is still no way to restrict write access to submodules (afaik). If so I would recommend to put the trunk, tags, branches as subfolder of projects which can be deligated rather then have a very long list of versions for each external, subexternal or else in one directory. I would prefer: so how do you like thomas grill's suggestion to do it like /trunk/pd/ /trunk/externals/iem/comport /tags/pd/pd-x.y /branches/iem/comport-x.y the problem with your suggestion i see is, that it is sometimes not really clear as to what is a subproject and what not. is it: /externals/iemlib/iemlib1/[trunk|branches|tags] or /externals/iemlib/[trunk|branches|tags]/iemlib1 ?? since it is easy to filter out trunk in path for automatic builds, this should not be a problem and everybody has freedom to organize his projects with tags and branches and subfolder before tags and branches. well yes, as i have said before this is possible. but what is the benefit above doing it as one big project in the first place, if everybody who wants to checkout more than HEAD of pd-vanilla has to resort to setup some filtering (or use meta-projects like svn:externals) and finally: cvs2svn automatically creates one big project, so everything else would be extra work :-) fmasdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] repository layout
Hans-Christoph Steiner wrote: Plus, what about adding Gem back to the main pure-data repository? why? - everything else is in that repository ? - makes for one checkout for everything see my random mentions of svn:externals - makes it easy to make branches and tags for the whole shebang see my random mentions of svn:externals - we are one big happy family :D true, we love each other but does this mean we have to live in the same house? mfga.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] repository layout
Hans-Christoph Steiner wrote: however, once we have moved to SVN i would like to make an experimental branch of pd-extended to re-work the entire build-system into small (managable) pieces that are modular and survive directory re-structuring. i know that you are not really interested in that, but probably others are :-) I am all for improving things, but it seems that this would need to happen before reorganizing the repository. doing this in an svn repository will be so much more easy. Otherwise we are without pd-extended builds until it happens. no not quite true. 1st of all, all the /externals would be compiled as usual. (nothing changes here, just some things get added) however /abstractions would be left out of pd-extended at first. then you could just move the abstractions/Makefile as a temporary hack to externals/Makefile.abstractions and call that from externals/Makefile (the same with other stuff, which i am currently unaware that it is in pd-extended: e.g. gripd(?)) this should be doable in one afternoon. That's not why I spent all my free time one summer building the Pd-extended and the auto-build farm. Switching to SVN is not a good enough reason for major breakage. i see your point. that is why i always opposed to a monolithic non-scalable build-system: it makes refactoring hard if not impossible. fmasdr. IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-1738289 ] View list listview broken for arrays with $0 in name
SourceForge.net wrote: Bugs item #1738289, was opened at 2007-06-16 12:06 File Added: array_viewlist.diff i was just wondering: when a bug-report gets a fix (e.g. a patch-file), should it be moved from the bugs section to the patches section or should it stay within the bugs. the question is: which one get's accepted more easily? i can imagine that it is not so much fun for e.g. miller to look through all bug-reports to see whether there is already a fix for it (if the bug is minor enough, miller would probably not care to fix it himself, but if a fix was ready at hand, why not apply it?) mga.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] ask for cvs access
federico wrote: just a question about how layout is organized in cvs... I think I'm going to create a directory in toplevel (say externals/ffgx) where to put my externs, but I would like to put also 'tclpd' in a separate directory in toplevel (externals/tclpd) cause I'm willing more people get involved in this is that ok? yes that's perfect. fgmasd.r IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] error handlers
Ed Kelly wrote: I think, IOhannes, if you could explain to me precisely how to use this function, I would be willing to (slowly) go through and make some changes. This is a massive hole in PD! i think you are mistaken on the powers of error(): this function is really just a version of post(), as it can only be used for printing an error message. a usage example: s=gensym(asdf); error(argh, got symbol '%s', s-s_name); will print something like error: argh, get symbol 'asdf' a better version of error() is the pd_error() function, which will allow you to the object that threw it via the find last error. use it like: pd_error(x, argh, get symbol '%s', s-s_name); where x is the pointer to t_yourclass Could PD or desiredata have a step-trace function, like MAX? i think desiredata has. and you can also use gdb... mgh.s IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] external questions
Atte André Jensen wrote: Hi I'm writing my second external, an arpeggiator called arp. I know I was encouraged to write it as an abstraction, but the exact features that I wanted seemed too overwhelming for a pd-newbie. Anyways, I have two questions: 1) Whenever I instantiate it in pd I get consistency check failed: class_addmethod: arp_bang: bad argument types in the pd console. However the external seems to work just fine. If someone clever could look at the code an spot the mistake, I'd be most happy! Basically I have four float-inlets where the first should also accept bang-messages. 1. most likely this is the culprit: class_addmethod(arp_class, (t_method)arp_bang, gensym(bang), A_DEFFLOAT, 0); with this code you say that arp_bang() expects a float as an argument. but arp_bang() does not!! (and btw, you already have added a bang-method with the class_addbang() for arp_bang() 2. it might be a better idea to use static for all functions that you don't want to export (all but the _setup() function(s)) 3. pd-dev is the list... :-) fmasd.r IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] external questions
Atte André Jensen wrote: Aha. So I should simply remove the above lines, right? right. To remove the risk of name clashes between my external and others, right? right. I'm now subscribed to that also, thanks! right. mfa.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] RE : [PD] Manual conversion of a Pure Data file in Max/MSP
CUNHA Claudio wrote: But I must to convert a PD patch in Max/MSP and the problem is that I am not the person who creates the PD patch... If I don't know the original order of the PD patch how can I use the triggers well, if the original Pd patch does not use triggers to explicitely define the execution order, then it is plainly buggy. so you are basically requesting a converter that fixes bugs for you. while this would certainly be a cool thing to have (the software society is waiting for ages for such a feature...), there is none. you might still get away with that (e.g. if you don't trigger any race conditions) ifthe converted patch is borken you have serveral options: - kick the upstream author to write patches with fewer bugs - fix the pd-patch by hand and submit the changes to the upstream author - fix the pd-patch by hand everytime the upstream author releases a new version - fix the max-patch by hand everytime the upstream author releases a new version i would go for one of the first two options, as they imply less work on the long run. if you are doing a one-time conversion, it doesn't really matter (but you might still want to kick the upstream author) mfga.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] can pdvjtools have a place in your cvs external repository?
[EMAIL PROTECTED] wrote: i just test graph on parents, and it' not working. the trick is basically to replace : now this is what i call a reason to use a repository and maintain the code :-) fmadsr. IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Gem question on pix_record
chris clepper wrote: I uncommented it which is the correct behavior compared to the original recordQT object. i don't know why it has been removed. however, why don't we just use a separate outlet (or a different message) to indicate the end of recording? i am not a very big fan of ambigous messages... mfgas.dr IOhannes btw: chris, could you please commit the rest of the min/max changes? ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] autobuild mysteries
Ed Kelly wrote: Haha! I hope subversion is more user friendly, but I guess it's just slightly different! no, this was one of the motivation to write subversion in the first place: to not distinguish between files and directories on the version-control level. fgmas.dr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] [PD]sys_vgui()?
Lluis Gómez i Bigordà wrote: hi list, just a question about sys_vgui() ... i'm trying to get some info about a widget on the pd canvas, but sys_vgui() is declared to retun void ... so i cannot get anything using this function ... there is another way to run tcl/tk scripts in the pd canvas and get the returned data of this scripts? the way to do this is via a callback function: with sys_vgui you call a function in the pd-gui process, which then can send back a message to a pd; you have to bind your object to a special receiver to receive this message. you will also be able to receive this message via a [r special receiver] object, there is no way to do an exclusive communication. fmasd.r IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] enabling compiler optimization/strict aliasing
Hans-Christoph Steiner wrote: mrpeach/osc/packOSC.c mrpeach/osc/unpackOSC.c i thought at least these 2 have been fixed with recent versions of osc, haven't they? fmader IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] [PD-announce] Pd-0.39.3-extended released!
Hans-Christoph Steiner wrote: Finally, it's done! The most polished release of Pd yet. We are further refining Pd into a truly powerful and usable programming platform. great and congratulations. does this also mean that the pd-0.39-extended bug's in the tracker are fixed and can be closed? [1815044] blosc~ (tilde missing) [1815041] freeverb~ (no sound) [1815039] FFT (broken on PPC) [1812195] IRC (on xp) [1772720] $0-array (crash) [1746207] only vanilla docs in help-browser [1732313] extra process (on osx dock) [1576865] namespace prefixes broken [...] and probably some more mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] removing inactive devs
finally, i would like to do the removal of inactive users from the long list of sf-developers. 12 users have never committed anything, 26 users have not committed anything within the last 2 years. i would like to send this email (of no one objects) to each of them, and after a one week period for objections from their side i wouldremove them. fmasd.r IOhannes here is the email text: Hi, you are a registered developer at the pure-data sourceforge project, which means that you have write access to the repository hosted there. our project currently has 67 developers, a lot of them being inactive. as one of the administrators of the project, i would like to reduce the number of developers to the active ones. since you haven't committed anything within the last two (2) years, you are considered to be inactive, and therefore i would like to remove you from the list of developers. if you ever feel like you need developer status (=write access to the repository) again, just send an email to the pd-dev mailinglist. (this is the main reason why i dare to send out this email: getting write access is so simple that people don't lose a privilige if they are removed from the list of developers) if you feel that this is totally unjustified, please tell me within the next week. mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] getting the classname in an class
Hans-Christoph Steiner wrote: On Oct 26, 2007, at 2:13 PM, Martin Peach wrote: Any specific suggestions? You mean casting as (entry_class) or something like that? you have to copy the struct definitions from whereever to your file. look at iem/iemguts/src/saveargs.c fmasdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] getting the classname in an class
Mathieu Bouchard wrote: On Sat, 27 Oct 2007, Hans-Christoph Steiner wrote: t_canvas *canvas = (t_canvas*)glist_getcanvas(glist); t_atom *ap = binbuf_getvec(canvas-gl_obj.te_binbuf); t_symbol *s = atom_getsymbol(ap); ah, you seem to have found the same thing that i just thought about and sent you, but you're doing it on the rendering canvas of a canvas. that is because the example i mentioned does exactly this: get the arguments of the parent. obviously it is simpler if you need your own args. nevertheless, it should show (among other things) how to solve hc's problem. sorry if it was confusing, it was just the 1st example that came to my mind (and [saveargs] being what it is, does nothing much besides the wanted functionality; but nothing much is not nothing) fgmadr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] working towards Pd-0.40.3-extended
Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: And as an experiment, I made a new autobuild called pd-main+libs, which is Pd straight from the HEAD of MAIN and the rest of Pd- extended. None of the patches are included tho, so it shouldn't be considered Pd-extended, though it's labeled that way (Pd-0.41.0- extended-20071027-debian-testing-i386.deb). Thanks, I will test later. NB: I'd suggest to drop autobuilding debs. All debs, as the currently are, are very wrong in lots of places (policy violations, package name with uppercase, installs to /usr/local, etc.). Instead of fixing this it's easier to test-install simple tar.gz files the only reasoning behind the .deb is to get the dependencies right. apart from that, i agree to frank. one hack to solve this would be to distribute pd-extended as .tgz and additionally provide a pd-extended-deps package (which conforms to the debian standards) or make the pd-extended package be standard-compliant, but install to /usr/lib/pd-extended/ rather than /usr/lib/pd mf.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] getting the classname in an class
Miller Puckette wrote: Hmm, well, the way Pd gets it is looking in the binbuf. But perhaps you need to look in the binbuf for the object you're looking at, not that of the containing canvas, no? Or, on the other hand. perhaps you're trying to get the name of the abstraction the object is part of? hmm, i think this is just a problem with the code i mentioned: i pointed hc to the [iemguts/saveargs] object, to look how to get the classname of _a_ class. the sole purpose of this object ([saveargs]) is to get (and set) the name (and arguments) of the abstraction it is living in. obviously this is _not exactly_ what hc is looking for, it is only something similar. copy-pasting will therefore not work, only reading and understanding :-) mfga.sdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] getting the classname in an class
Hans-Christoph Steiner wrote:
We have a winner! :D
darn, i just finished an example that works as well
fmasdr.
IOhannes
/**
*
* myname - implementation file
*
* copyleft (c) IOhannes m zm-bölnig-A
*
* 2007:forum::f-bür::umläute:2007-A
*
* institute of electronic music and acoustics (iem)
*
**
*
* license: GNU General Public License v.2
*
**/
/*
* this object is an example on how to retrieve the object's own name
* usage:
* + bang to print the object's name to the console
*/
#include m_pd.h
/* - myname */
static t_class *myname_class;
typedef struct _myname
{
t_object x_obj;
} t_myname;
static void myname_bang(t_myname *x) {
t_text t=(t_text)x-x_obj;
t_binbuf*b=t.te_binbuf;
if(b!=0) {
t_atom*ap=binbuf_getvec(b);
post(my name is '%s', atom_getsymbol(ap)-s_name);
} else {
post(hmm, i don't know my name);
}
}
static void *myname_new(void)
{
t_myname *x = (t_myname *)pd_new(myname_class);
t_text t=(t_text)x-x_obj;
t_binbuf*b=t.te_binbuf;
if(b!=0) {
t_atom*ap=binbuf_getvec(b);
post(my name is '%s', atom_getsymbol(ap)-s_name);
} else {
post(i don't know my name yet...);
}
return (x);
}
void myname_setup(void)
{
myname_class = class_new(gensym(myname), (t_newmethod)myname_new,
0, sizeof(t_myname), 0, 0);
class_addbang(myname_class, myname_bang);
}
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pdp's mmx support
Hans-Christoph Steiner wrote: I just saw that PDP has some MMX assembly (old school ;). Do you think it would be worth turning on, even tho MMX seems to be deprecated? why is MMX deprecated? especially, why do you consider MMX deprecated when there is no SSE2 code instead? mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] getting the classname in an class
Hans-Christoph Steiner wrote:
Perhaps atom_getsymbol(binbuf_getvec(x-x_obj.te_binbuf)) could be
defined in m_pd.h as something like class_getclassname
this is along the lines of what i tried to suggest in my initial reply
to this thread (in the sf-ticket)
in addition to that i would like to have something like:
static void myobj_nicesavefn(t_myobj*x, t_symbol**name, int*argc,
t_atom**argv) { }
and the developer can decide to set (name) and/or (argc,argv) or leave
them to their initial state.
all the binbuf-bibabo with the typestrings should really be hidden
behind this.
mfgas.dr
IOhannes
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pdp's mmx support
Hans-Christoph Steiner wrote: Well, AFAIK, there is no further development on MMX, while there is with there is: it is called SSE SSE. And it seems that SSE is meant to replace MMX, instead of complement it. Plus if IIRC, MMX has some serious drawbacks to it. It i don't know of any drawbacks of MMX. seems to be something like SSE v0 ;) as said above: it is (imho) still i don not see any deprecation in this. afaik, every processor that supports SSE3 (or whatever is current) also supports MMX. i have never read anything like it seems you are running MMX; please consider upgrading to SSE2 to the like mfg.asdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pdp's mmx support
Hans-Christoph Steiner wrote: Do MMX and SSE have different instruction sets? If so, is SSE preferred over MMX? yes they have different instruction sets: MMX can only handle integer values, while SSE can only handle floating point values. (only SSE2 added floating point support) SSE2 is generally preferred over MMX since you can handle even more data with single instructions (and/or other types) otoh, what do we want to prove with this? i remember well that i had to remove the automatic use of SSE2 instructions in Gem because upset users (the most prominent of them being you) demanded it, since not all hardware supported it at that time. virtually each and every x86 based machine has support for MMX though. there are still many machines around that do not have SSE2 support. fgmadsr. IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] getting the classname in an class
Hans-Christoph Steiner wrote: This looks good. How about storing the symbols somewhere to save some symbol table lookups? ??? why not? (one could also implement the storage function in MMX (or SSE2) to save another 3 cycles :-)) not that the idea is bad or something, but i don't think that this is something one should worry about now. fasdr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Fwd: [PD] patch for dollar sign fix in pd-extended?
Rich E wrote: Hi all, i still don't fully understand how this relates to the dollar sign fix patch in the subject. fmar. IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] removing inactive devs: done
hi i have removed some inactive developers from the sf-project. the list of devs shortened a bit, as 1 dev happened to get onto the list by accident and another one promised to do something in the near future. if i still have deleted somebody by accident, they should tell me so that they can be re-added (after all it was a long list on a website with a lot of clickadeeclack... :-) fmasdr. IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] # converted to $
Mathieu Bouchard wrote: On Wed, 7 Nov 2007, Hans-Christoph Steiner wrote: It seems that somewhere in Pd # chars are being converted to $ chars. I imagine this is support Max users who are used to #1 vars. But I don't know of any use of # in Pd and I would like to be able to use webcolors as symbols (i.e. #ffbb00). No, it has nothing to do with Max, it has to do with Miller using it as afaik, it was thomas musil who introduced the #/$ weirdness in the iemguis. matju, it would be nice if you would not start a flame war against miller at each and every single inconsistency found in pd-vanilla. he is not the only one who has written code in pd-vanilla, lots of sh!t has been thought of and implemented by others (like me). fmga.dsr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
