Re: [PD-dev] VBAP SVN commit access request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 hi, On 2014-04-29 23:12, Jonathan Wilkes wrote: So that leaves eighthave or zmoelnig. Those are the two developers I referred to with Hans? IOhannes? and they evidently haven't responded to your inquiry. indeed, sorry for the delay. i plainly forgot about the request. anyhow, i have now added you (zacksettel) to the Developers' group which should grant you write permissions to the svn repository. keep in mind that while you technically can write to any place in the entire svn tree, you should restrict yourself to your directories. fgdmasr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTYKgWAAoJELZQGcR/ejb4me0P/R/9dAFMmqNwcQA9/gT6zn6N t/3MzwZFDhqiC3UcDyyXTVBzZQCVqa+LmmKR1pujTOk7ZnnNFgQkoNCpvTDpsZoA X2TzTpAGKSRfzdHRc+h0s3jcZ3hrpVMq9Fz5zIAS7uDRKq/RV0CW88Hgz132x2zy NJwahQqGxIB6q8lI7uvCifnXF32SZk0LMIS7Ec8xc4wyY5681Z1jrB/muuPrwLTQ 43F4rjHSs2hBqt318vTDg+kzHRDFFvit0QT7IXo3z6MFOnsTLwKQDbGSYWRzBc4z ColpM8GUHJ6rW0jIA9SOzZrnaq+xRKJTcOCZephds/Ljptaxz1rTakcoxnJrKDcN MWP3JwOgftMNlCyzB9SI70wssx97HkFfwsklHANbzJlcK1eQ+HfDLg7eIDnP8JTA qy8TUnD9xiUBE3nKnQufm/lX2C+s1YXMNE3ulFjH2nIyKYkymA1CHbSmJQOWUNur ADPH7sNwqF3999i8tnXlHHgI8QxXpROnG5DfdUq6ijU/n9I1AETqhDrNvu9T6Ptp 37thPMv5rQdbDcmfgP41sEFpPFqMz7lMXEamWR44WAo8Kqi3yStGcTP6XxiCIol+ FM5TXaEuERrt+fK8OZoZlFMNBmSheWFReyZsXyBijaZLgRlMlpmOVHgkGYQLI/CZ WRDxrU+jj/DdxO+BrX3b =eob3 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Requesting SVN commit access
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-02-26 04:57, Martin Peach wrote: I think that sending and receiving on the same port is not an intended use of the UDP protocol, which was designed for throw and forget messaging. how come? how does DNS (after all, a central service in the internet) work with this assumption? UDP works fine with as a challenge/response system (less so as client/server, given that there is no notion of a connection), and for responses you need o be able to send messages somewhere. for whatever reasons, many hardware manufacturers have the idea that sending/receiving on the *same* port is a good idea. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTDaorAAoJELZQGcR/ejb4rfgQAIPEiBRhdvB70ciSHpQlaaLU UfBfe+b1WMNx7sHYlSatzRV7hml2Qor3uZtH//7FVgn0I3868fQVlBYXYhZZjDRp y6FfSgyU13M01/Qqjy1rmO2p+JVZYOmITIJqArMatWpo13oaBST8nAb5ZWt2sltM OJa4iLTCZz9ysjyk+WakXsj6qYH9dUNA5BMtEVeFfWY4yquAqhStPV12r7dcP8UU i8myFGpaLAO4v+zsx7uEhycXwS0Z0uklyYsVK/IuEWUwbwBw23fuiI5Pmes6r+n+ Nm09raqtlIj2zof0p2DxG+BvWEj7f9iTM3fGbPhlILaYRdviyPAtE+9w9f2roTxn 1aLy+G10SzRs2LSTlG4wotwowS5HTLmRXTeLp5grnK1DMx2bJPtu+J4mvzTuwfb1 7xJOwh8NoEcox4N7dABubAJ7Btt/VP0youZewaS3FWDm2t7QgP4RfYZq1kbpt/x+ lUft6qQ+J48DlWK6qdK/4lP+3vqsKd8wXffcrn4GQ4oSO7XFtZeGtjSJLMYvB+IV N+zEdLUkeQwcF7YyUm6kB8N87y4k+mbAiOqiN42i6bXJUG5tmrslGGnxV5Ou04uw URls1w2RZhlyCbbngsla7+SbsFY8bQsO01VpxE7vZVe50yUgPyghAzAfAlqzsXlj sYIDjn+IFnqisZEmhZik =of+H -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Requesting SVN commit access
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-02-26 04:57, Martin Peach wrote: how come? how does DNS (after all, a central service in the internet) work with this assumption? UDP works fine with as a challenge/response system (less so as client/server, given that there is no notion of a connection), and for responses you need o be able to send messages somewhere. for whatever reasons, many hardware manufacturers have the idea that sending/receiving on the *same* port is a good idea. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTDaolAAoJELZQGcR/ejb4VtgP/AkEy3zIz0X1trSYIeODnWsM uYKxuNtxxF/g2ztIEnOusWeA4n4dZs7I7G4lnl8p7xFYnXQrRdDAHWcBaS1jy9vy nVd2A422gOAyXukAkVz+Fp2OIpWzQCLCXTZjs/kHZ42SFaeEz8eni7WdedCEv2F/ kPLPfOmkkMo19jCoijyQfTK6dI3u8o4gbeTczTgCWKcnu8kzc1oNag+Tcp0og60A +xmIYw9dgdH/RbZaPvy3f/7l+IXNgwXx10QQzI4kWVel4H7XYSpH0sgj6DN12n3N t51NhpDiHlCT/bbsSmLk6JxxJWjl1NYbdD+zxvl/wNjdbjU4TIP+8Jq+QiNFyhDk UlThYu9BTpv4YFNbDXiHPda9Y67QWAh4RWKhLn+49nMlwDEpkGowSpIXwXGwuDOj AUicvsRJcL+vjs/anA9aP7VfcLJNm86NMdH0TzcY7PRkFrLjwwyGbTaR0gsuIZtI U8oA4IHbe6kleTp6t8frziZhhuAKak4/vtgzRo+DAxP31SEM4zEGt3qr758hFezP mCaEeYdUtGeZqAPiLu+DPRQksWlxKzYI3TC5LIdRJYPwQxomOe4CDD9lzm8/tMLf j8niIXrUoACcvbsRvmdMqXP2pZvP29E0/iRQT4bCd0mpiS+Eqc6zR8QZGq+fMx4O ENfrT/PIxTLY6n3QZ/WL =wWmp -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Requesting SVN commit access
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 (taking this back to the list) On 2014-02-26 14:55, Martin Peach wrote: On 2014-02-26 03:47, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-02-26 04:57, Martin Peach wrote: how come? how does DNS (after all, a central service in the internet) work with this assumption? UDP works fine with as a challenge/response system (less so as client/server, given that there is no notion of a connection), and for responses you need o be able to send messages somewhere. for whatever reasons, many hardware manufacturers have the idea that sending/receiving on the *same* port is a good idea. I see; but for DNS with [udpsend] and [udpreceive], it should work since one [udpsend] can send to port 53 of the DNS server and a separate [udpreceive 53] will receive its replies. it seems i was a bit unclear here, and thus two separate things got mixed up: - DNS is a bi-directional protocol: you send a query (from a random port N) to a DNS-server (on port 53), and the server sends a response from port 53 to that port N. - hardware-manufacturers like the idea that the receiving port is the same as the sending port. DNS does not have this limitation of using the same port (thus you can query a DNS-server on localhost without stepping on your own ports). so having both [connect dns.server 53(-[udpsend] + [udpreceive 53] is not sufficient to query a DNS-server. The problem seems to be that [udpsend] will assign itself a random port to which the remote device will send replies, but [udpsend] doesn't know its own port number. well, but that's only half of the solution (for the DNS-problem): even if [udpsend] had a notion of it's sending port, it would discard all messages arriving on this port. but it still *listens* on (and thus blocks) this port, so you cannot tell a [udpreceive] to (also) use it. fg,asd IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTDf0gAAoJELZQGcR/ejb4+3gP/jHgX0wRrIBNPPMC92+y8ssL dokmoX/tQa5ZYhPwcUg68xwORPKzldql2PsMx1hY19ud9kzoIbFXmfy/uBk9mTNX VATEb2d7vMY5lk3/iGApefl+gnugm9rCPyD88J80U/Q5gRDBUvCFH1hbtABXccRA AXRGRcZ5C9pMYPlCE6R0O4EF0553Dudscsitu2/wMx+hpqAfdS51bIbwSd6vU56I CGIc3QIohipwnQmhMQ9EAdFD/i3zxXg2xuC5HzHpc/Q4hipsuw0169V19pn6ucFM yx6iKW2j6P60QW3D7y8betwyBOmRfgpyF9ip4AkDvWqZuzfng0YxAWco3v9rDpvZ PITxRicLL50EyemI1rms6mPiw6nWmATfbYSQBPGdxTG/J6vUBlijNdrl1FdEIv0n 7dyLOLMk4rmfGivSrKFBsX2JcicPPapUv9grpm4d277mIn+oFhMVurfWHHp5DiPJ m66KkWMYwiAqK1+TjMzI+PI9yK+3gYZy54ExXi8/xxlZjC1F8nNHNv0ti2z+uk/Z DUERnsE42nzZ2pxNKTsSkaNv3GHMAFe0H7MRsdUD5+3CrtqBuHLpyJIQxjEHmP/4 /BGNhFJXiGnK+MOb84/8kq2W0QkYoIvF2LDdUUV/qNbj1Z0b0Ft1cRJjBwELX5Is iDAK9hFfnmz7uzdFkVur =s8u4 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Multiple Instance of pdlib
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-02-23 20:46, Dan Wilcox wrote: Any further updates on this front? If a consensus is made, we could outline a roadmap and move to the task of implementation. At this point, I think breaking externals would be less of an issue if said breakage would be manageable via about find/replace. I'd be willing to handle that, at the least. i was going to ask something along these lines as well, but more libpd specific: when i (last) looked into the libpd API, i noticed that libpd works on a global namespace as well...what i mean is, that the API (at least the C-API, i haven't checked the others) does not allow to specify an instance of pd. the current API looks like: snip void libpd_init(void); int libpd_process_float(int ticks, const float *in, float *out); // ... /snip obviously with this API it will *never* be possible to initialize multiple instances of libpd. so i would have expected something along: snip typedef struct libpd_ libpd_t; libpd_t*libpd_init(void); int libpd_process_float(libpd_t*instance, int ticks, ...); // ... libpd_deinit(libpd_t*instance); /snip now obviously we *currently* cannot have multiple instances of pd (afaiu, that's what dan's question is about). but i fail to see why libpd doesn't provide the API for this, even if the instance pointer would not be used (until Pd does support multiple instances). e.g. the application programmer would have to check that libpd_init() returns non-NULL anyhow, and in the current implementation it would always return NULL but the first time being called. this would have allowed for a transition to multiple instances without having to change the API... ghsdft IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTCwfjAAoJELZQGcR/ejb4uDsQAIrdZNgHX4zFytnGCjeG/PkB UVbyXLy6EJwLNd15sFcO1u9VG6LWWC3LB7pSmw5DDoGhpnVcr4vCtNtRNX1hLFqy n8WAI8IKyzioQlno1ed29Cjb9T0n2IKHZryHqPTobukURKmAWh4ZwQxGe7yM8AbM 6e+KyZb3JZHb7IVbf6DqqnPlb9hlLz7TP7f5SgDzY0TJGAbmSsfLha1SVoblZjY5 VzEQ3jl3rhblmWVmEFmHDR+LIBCJkKwGmPG0r3N8dbhvMFMFWVFtZCEKujbStvzz cKvzjtgwtEL6n3kcw2eRHttCpZOnGsd/RW59r/68Pa+a2UvOhKdff0MELUSqm2Iu rOjwl58mBtkXdtrqlgNPu2ZmdSNmwaw8OJizz2ttlX+r1CiBQPhEAzmRDYdtMN4V QTDad5wKCW4l/eaSTX4+z/Dn3qZJ9X6CmQjc+fX2OgrTnWPe1P1Q0FpZ4ZuVHbGB DYdFD5dJp/DU2OygQg6MO4h25VfalQ++MAujC5EPUxKkXZjOAsS8Nt29EFgC7mCc QLeB/zlGbRNI7iRfrHI6zWANuPIvLuomHmhnc1UhkLZNPxFJ+GVkEfK+nyWq+rEG n7751NYxGOdI5D8X3CZHuVOmmlRAqBceaEkH0gtJumr/o2k/GvN8kWjKQFSCncuc /phnie1+8fSV7MlZ1rVr =wrR6 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Multiple Instance of pdlib
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013-12-11 20:38, Rob Bairos wrote: Sorry, Im pretty new to this code, whats an extern in pdlib? the same as in proper Pd: an external aka plugin that is, a pre-compiled object loaded on-demand at runtime. Does it make more sense for the instance structure to be a set of structures? if we go that route, i'd suggest to use a structure of pointers to structures (so the separate structures can be more easily extended without breaking binary incompatibility). fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJSqXiCAAoJELZQGcR/ejb4LBgP/1wayhKsCdBOX8in1tklqISK gNR8ChKtsJX5Zju2oqBI7BL5VfIg1NdciWO1hAUhM4HLWG4Wd1/8oICFez+Nggu9 zmYa/lxxIk6XDuKtVCCRfCPYu3WTKbujwd1c7GVcnM2RSNInwwRuHn5wXhsi5HuC 60GtX086gPDwMtLNB3D8YjJxhhgnydP4SV4OUfxVW7USOpwsxQIPzPGInX7ukEE5 Tet+LCYKv27ojbZshJ5jYOp+zaK1vl7gx1Tu7NSGZbpo0pk1tQrXWy+KUlrvgRGL zA/YUe280NWhf8JPBh9VMDCSXpRfU2LJkrrXIWStl/dphX0jj88nSjPu4qpuzFtJ fAY13Noatjy357IvTh5i8YxZhX/Ryp5iuem0O/dzJJelD6KQQ97qYNXTTitcSWd8 bq3nyFoswi8KLt1svil/Ukd9/BAF1jNuNxGGKbpnMfkist+S616kvLd4Luo1exvd NLo86trvie3SMsnTH9itGFOBP9DwKCp3FvNwo/50kS8ubZSbXjmwPjnAGSoD9fNA scZElHJxlXISUA/ah4XTv+0RtPNjjyJhvsMjm18fzdjinziyizYw7n0SLlelCy1U sqsbWlXQYKVS4HG2H5qM6QFZgb9ov+B/z5NVkcyn85C5LXIgL6BrTVk/anWQrbeD P4d0RlArbWhCqWDrOLnn =UyCi -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] compiling Gesture Variation Follower (was Re: (no subject))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013-11-06 13:56, Bas Kooiker wrote: Hey List, I'm new here, so let me first introduce myself. welcome! for future emails, it would help to set a subject of the email, so people can find your mail more quickly in their preferred mail client (or the list archives). g++ -rdynamic -shared -L/cygdrive/c/Program Files/pd/src -L/cygdrive/c/Program Files/pd/bin -o gvf.dll gvf.o ../src/GestureVariationFollower.o -lc -lpd /usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../x86_64-pc-cygwin/bin/ld: skipping incompatible /cygdrive/c/Program Files/pd/bin/pd.dll when searching for -lpd /usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../x86_64-pc-cygwin/bin/ld: skipping incompatible /cygdrive/c/Program Files/pd/bin/pd.dll when searching for -lpd /usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lpd collect2: fout: ld gaf exit-status 1 terug Makefile:270: recept voor doel 'gvf.dll' is mislukt make: *** [gvf.dll] Fout 1 on w32 you usually need to link against pd.dll. on your system, the linker can find pd.dll, but it considers it incompatible. most likely this is because on w32 pd (both pd-extended and pd-vanilla), are usually only built for 32bit architectures, whereas you seem to build for 64bit (x86_64-pc-cygwin). you should either get yourself a 32bit cygwin or compile a 64bit version of Pd yourself. mgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJSekWJAAoJELZQGcR/ejb4kycP/0Z4flo/mSRkNZFPte/Gv3mP o+vu4znYCIuxoDec4QKVf8v4wPrCdlvlHG8z31OgNDBqpRwEVNjWIMrCtYvrVuVV Mcw9r6s9mdzub78LVQykDbL8wIDyRjvthSfv5vK2/mlhyMBdD2dzV0CCV2h6s5fr gQMM02+fmw0oqQHujExbrqc3ix+cbM51yZIKlQduBoA5h95wigl1NvAAZYjSn6aR qlQbQ4Oh3yQrGjBUumZQVsm82c34Dx2C8pvSCW3wBgmg/l18iLKMqO6pzUeodRRz rltYygf3QRpwt6MbioUjM8CyaHRY75A0+qP+88JtXliTVDEcAbypA2S10lZzylie 10ugRzXFcmaMNpkr48uu8QzdRXmdE7M/8SZIrveYXiGJctHaeBhiYeiS9972SYd9 1WuUcI2MACpEVwdAkXWQ1jpIrj6J0bpJ1WxjKvcaCA3f7vPpQVYkrxaSZ8uGyzYm 8llcaFGXw0r4O86vnN6lqoXv0wLxhtJfSXdeleFMVQ0CsVeesYcF6pOKtex+ON56 F6L5P9lD58Jqv2UzDzswVBtg6EEER6K3mUTnHpn3gl507tgZAbOc7AMq9Km1FLGM iinuscVKTMVxTQngBQj1ZMY4drxs7tnVSrkh04dK7zOg8RU3bowxocMs2nlquq1p gnHX4+VkbIhZylffO7u8 =TjrR -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] compiling Gesture Variation Follower
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013-11-06 15:52, Bas Kooiker wrote: Oh yeah, I forgot about that. Will do next time! Getting cygwin 32 worked! I succefully built the dll. But now the library can't be loaded in Pd. The dll is created in the folder Build/CYGWIN_NT-6.1-WOW64/. Does the WOW64 mean it is still a 32 vs 64 bit problem? hard to tell. WOW64 is actually the wrapper for running 32bit applications on 64bit windos, so it should be corrct. un unix there is a utility called file, which should tell you what the file is. if file exists for cygwin, you *should* get something like this: $ file Build/CYGWIN_NT-6.1-WOW64/gvf.dll Build/CYGWIN_NT-6.1-WOW64/gvf.dll PE32 executable (DLL) (GUI) Intel 80386, for MS Windows but ther ecan be numerous reasons why the loading fails. do you get any specific errors? fgmasr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJSembDAAoJELZQGcR/ejb43iQQAIGfAOyV6A0EW1T8WNvpXUoE 9TEMCTTn/o7PSTP5b56uG59rdgoSI2CwkvIRj4eWiL0B8eiaZqO1yXl0YcPuuJCW xcBMUDclSUKUrCQ5mQGusQILAXIDIX8P6PR2/dv3mhuG5eScKt3dAFaHa9BO33Sv UtumZ5BUpEOCKrJ1Ux00+em4WUsfxiSw2L6KfK5iFVIw7RAxNCtP+4MzCs9INvT5 roQmnSs4XFuQ+0ZKhixlLQvgPDVIeug6/HE4FkJBenYC0NyEf+gtXgSniVwsiJ55 OzhgtJsrZGg1L0fH+hqD9Z/ugUKdyPvM34LC3qL6zDBStK6MPjhWCTaK2gj4gB9H v2CrJnkfK/XmU/FeZeZlsXFjIPfnMEDj4ns/XKO4QSWQXhOBN6NV8osD5i97Dsk3 jW9vRZzv8PsMmuciL4jXP4hp3KdBNisZykbO4XAot1yV8hfplI3gosNSnJlL3J8J ObpE5UKXtOhXoovYc92aPy4bZWSH1uIjrrDkjMvCUJ4gMnsx2XVd9r6JPjWjW7mJ rWsn/uhUASvPF9j7QNgmbNQhx9ttVpG8VgnJGx/S98tRh3fDX4i9Oj+ni01DrcaD +Mcs/WDvUJ+dPnRCiB+ug0rqrV12QFWh3FvyIN75R81U21n6/fWnlK6fkSwW83jW sxxcEryGJs4CDAKl3RKe =dzgE -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] compiling Gesture Variation Follower
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2013-11-06 17:42, Bas Kooiker wrote: 'file' gives me exactly that output indeed. Pd says nothing more than: C:/Program Files (x86)/pd/startup/gvf: can't load startup library'! So that's pretty useless. start Pd with -verbose. start Pd from the cmdline, so you also catch errors printed to the stderr/stdout. while there, start Pd with -noprefs, so you don't get interaction from other libraries loaded at startup) don't put the library in a startup folder, but load it explicitely with -lib C:\path\to\gvf (put the dll into a path without spaces or other weird characters). fgasmdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJSenSqAAoJELZQGcR/ejb4v1EP/RVlYI+952j1x3E5E3pw9qqF NB5veGHGqgI9RpsE57bHLbni12pJ1Vsb3rkBDW6vIcb6dF8juBFLIHDmw9980/PR RjtSVYZoAAzhMNaPTD0se8yXUTeKcoAZ+kizyC2P4THH5LtfnSmvjaJm4c9E+ik8 uTwuEOPHLJDVzrhazvbUEBkWSkCzPNvw2XI/pVlEQSaV8bHh7iMhW0OVAxskWBDb JxiqAeva1QfxF4ze3oX7jcjvyEqi6D2eQUo+dYxudrKXRMyIfVxBJH8YOZQZ/wIp B8PGF6B5+wpobfzWz3ApojjAjFYbeSdwGt/7uLSRhlbVE3N++Rkc3l3DVquPKDvr TcJWIsCxiyodVGo341MwlGUmYFswyA7NTA9WD8QCeAvjVJQ2k7neHNl4Dn/TcQdo y9+tbn8bwp8xXd6XlXKyuhQ5ifA05XjHQYHYB3SVszkgo+UjKa7DVqdMedfAgFK1 sfSeVAjDZE/g0oYnDCL7NeuwHQWr4M7iJmps8OoIJ1Hxd5XqaQHbQamiY0h71jWn F/DXOZfIwzgm0k5dngVMfwx5VFE68kp1tF8csYY/schfCfPBU0WLb3pQFm+sC90x d7ZqHnufvRp91lMFSw4o7TTgt5zfUyziQNRSeLeFtnI1zQHas22naDGnO2E4V1Jj bn7LN46FHSq/slVIbHqb =POvD -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Window strange behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 (re-including the pd-dev list; i prefer if you reply to the list rather than me, unless it's personal). On 2013-10-09 10:25, Pierre Guillot wrote: Hi, Thank you for the tips, I'll try this. Do I have to give the file with the external ?I want to create a kind of template for the GUI externals that allows developers to manage complex behavior and to realize complex drawing. So I don't if it's a really good idea to have to put another file with an external until it's not in the Pd distribution. This template tries to answer the questions of GUI creation ( post in : http://puredata.info/Members/hans/new-editing-features-of-pd-extended-0-43-now-in-beta.). First, I want to create a good template that works with Tcl/Tk then I'll adapt the code to Juce and if it works, i'll try the other platform. that's the exact reason why i would recommend separating the gui drawing code from the Pd-fiels, preferably in separate *files*: you should be able to replace the GUI-implementation without having to touch the Pd-object implementation. but yes, that means that you have to distribute multiple files. i don't see any problems with that. (any libdir conformant external will anyhow consist of multiple files bundled within a directory). but then, it also means that you *can* ship multiple GUI-implementations with a single installer. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJSVRWOAAoJELZQGcR/ejb4zNMP/iyI5JZNBHm0g8m4mjBbSRCq lyGkrvDBMQu3uy6/awSrzE9gta6yPZAN5ZKyQZ8W9ZJtZb7iQyuUYm1O0Cvsm+FZ LbwwhAtXmv9PE43IdqnKX9ZXPLbCa3XcAcqtMt8NjsmpmhPyROoBfAhnPo3HD9sB 24hbPhmufdTn9/CiFYFFdBgQd+I9YrPq3JSRPrfWjvlpXXrvYj6X/oSdjJ0dV6oD OJZjO3FwnpQaTJLSh5OtBWDklXnCtlSgfPw5vqUOUP8MfkG2sVHk1N8MoUBvuLBj CGaE8WqPmIPrfr7Lst9kjmSbNmyx2aV/FaX6acfAdK7T4/eKQPhVzZ4VwJctI1BM Y4cd5/gSmoowpoZhIOY0C7Of/QXnKTYJ9suWX/sgm8t5H0tlQkqo6koR2/aRSiip Vxruz7iV3X7r2SFLjKMSFas6ZoVvmOZq5yQNdWRfJVOrz+EN4fldU5s8O05+TTeX Yv+w/QEzYlXve4h5aw9O1YwaWuzkq+bH7vsJi0HnbNqdhwC2qZRMtwNAuM+RpoaO AHu//oXRzrQbD/+IT6DClz4oc8pz1vfuiGY8GOWHCckCrjVIiaPF8P4OT9TVlEdu h/5LRTuGJuafsiSrBiP4tGo0FzMpBlgzT1pKP+DnPTvKmZ3L4nhDn4gizizvrJbl j9A3coMwfEQpuxYf3dm2 =eTtM -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Window strange behavior
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2013-10-07 21:53, Pierre Guillot wrote:
Hi, I've got a strange behavior in my patch with my GUI externals.
First, I create a canvas :
sys_vgui(canvas %s -borderwidth 0 -width %d -height %d \n,
x-e_drawing_id-s_name, (int)x-e_rect.width,
(int)x-e_rect.height);
unrelated to your actual problem, but how about putting all the tcl/tk
code into an external file ('ebox_window.tcl') which defines a few
functions that simplify the actual code you have to send via sys_vgui?
then initialize it via something like
sys_vgui(source /path/to/ebox_window.tcl)
fgmasd
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJSVBbtAAoJELZQGcR/ejb4Oh8P/RDiZVp3LObGlFHSVfI7sWpN
kgx9SWqxxvCc6H3jPkNgLTRthnYl+DUUlvT+6K2L0x9jpDm7XOLvHBX0I8ln9Skq
dOS2YsO8/0R94XR7cECO+2wBHevbwrbv6WPvX2Z2EDNbiCpWYvGfZjk9U29LpT2n
8rhTXBcA/ReNlhRrryiUdJZTffrXYAWAA3I9J+oW2p2JWzYBVjSVj2XZAcVCFhYJ
6uxmIKVyEbogZLJQDWA1hh/zq71KAY0n1eoarAlVADNpi/hMViu0N/mNG/2lRy1S
W9uryfcYR/sSc2pSS5LM2RHHfF/aiPNzRuBfixGY7RVNuuXPx4iZlVzzFI4W6FHX
tOIxN99u9L3UtbnyIQAn2RJeZ5O/8+t8wMUzY50WHCLOZBU/SoT3n8HZx893zWBc
Kfks3j6dI5mne12cQUF5xyYVByAVKFkkZ8s4BLeGCqvb90O7fQ5zJEBTmHjSYHDp
FIV1Mm1Gsuk2D8aQ/wNMrn+xKevsBu/P7Wv2fxj8/ydDudCgVeRmTyiq/hGlYOdI
Imk/SYE652UoCRHM9iZP962coieHTdUYGfeuMJOB5Sa1x37vR5HLSJeLEldgv7Mz
ELyZ1HBfeGao9n23yqWMBMww9Nd+/e50U2HkPfFHbsEFOc/1EzlxiIh8CnbbLnO8
zVvRgeJXDFTT1DLQh0KN
=L+nl
-END PGP SIGNATURE-
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] wrong ELF header loading tcl file
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2013-10-07 17:19, Orm Finnendahl wrote:
Hi,
trying to load a tcl file in a custom extern's setup routine with:
sys_vgui(load /home/orm/img.tcl;\n);
I get the following error when loading that extern in a pd
session:
(Tcl) UNHANDLED ERROR: couldn't load file /home/orm/img.tcl:
/home/orm/img.tcl: invalid ELF header while executing load
/home/orm/img.tcl (uplevel body line 1) invoked from within
uplevel #0 $docmds
The extern has been built with the following flags:
gcc -fPIC -DPD -g -O2 -funroll-loops -fomit-frame-pointer -Wall -W
-Wshadow -Wstrict-prototypes -Werror -Wno-unused -Wno-parentheses
-Wno-switch -I/usr/include -I/home/orm/work/install/pd-0.44-3/src
-I/usr/local/include -L/usr/local/lib -o img.o -c img.c
It's on a 64bit linux with custom pd-0.44-3. There is obviously a
32-bit/64-bit incompatibility but I have no clue who is causing
this and how to fix it. Can anybody help?
the problem is not the extern ('img.pd_linux') but rather the tcl-file
'img.tcl', or even more rather the way you try to load it.
assuming that /home/orm/img.tcl is an ordinary tcl script file
(text!, not binary), then you shouldn't use the load command to load
it; according to the tcl-docs:
load - Load machine code and initialize new commands.
is this really what you want?
or would you rather have something like the source command:
source - Evaluate a file or resource as a Tcl script
fgamsdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJSUt9sAAoJELZQGcR/ejb4ttQQAJRDIaP4Cl99TrPTtKLoCTYI
qofZVJBs99bE05kBCq+adiwwtXLaYwAmbyQSuszz/N/gHLTQQUKg/B9MujpRWkre
CU5hXQWXfcUiZ/sVHKNfMYzlYE4R9vbXqL7zSa7rJRSZhPOzjs/LZOy5J03511jf
lteYAlxU98RTxf/deVEn1dbsN8Z6t3bF2V12HlfUMPJDCnqY5OEPWpUfAy/Onw4i
IT+/o4s/zf6injKv5Xo8CGM2foJSuMDmvNHxpNvGYgqzFa2PYePI5ohefAUkzly2
1swnGEcqVn+mPAG57rQQ+VmQCdxSRgjWjG04umwI1jZsltBqbuh3c+FPvV9aitvP
ebMvkoMkFQrxOz0vUrIcGJ3F6JE3XV9XC69SfZKz9eL6hyodvITBXqYmf5J3AEAw
LsC7N31R+x2PbZgbNyucGfotBM+pbbhmPJBCFUB/VBuSbTgiCiv37QA7dbDtWz0z
vf++PSk/5k1RJjy3svscOz1gAULBbEdlnYgTExxeCr9L4dFQWQ8bpw7YMxZaFHz0
jPg4nfp+B4pFnlNXkceLq/gFFxlNRqbFqSA7w2xHvWP7esm6qDBbypmfw99UsGtI
idsn5Oz/cpW6PK9vcIuuebhTUq0PPcEjh5ysDzNSafzxzmRp/uNOLEDaaRJk6TzL
fD1vo6e8cWVYuxxWjeg5
=GB/t
-END PGP SIGNATURE-
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how to create second inlet that accepts both floats and symbols
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-07-18 18:41, Ivica Ico Bukvic wrote: inlet_new apparently redirects elsewhere, so one could potentially do what list_append does (if I am understanding the code correctly), but is there an easier way to do this? basically you ahve two options: - - allow lists at the second inlet, and check whether the list has only one argument of type A_FLOAT or A_SYMBOL: /* creating the inlet */ inlet_new((t_object*)x, (t_pd*)x, gensym(list), gensym(list2)); /* adding a method for the 2nd inlet */ class_addmethod(classptr, list2Method, gensym(list2), A_GIMME, 0); - - if you want to allow *any* message, you need to create a proxy object that will act as a receiver for the messages sent to the given inlet. this is what the [list] family does (but also some other objects, e.g. iemlib's [any]) - - IIRC, when using flext, you get inlets that allow any message for free (that is: proxy objects are handled transparently) gasrd IOhannes PS: i was having troubles understanding your actual question. would you mind putting a the question itself into the body of the email? my MUA only displays part of the subject, at least where i usually look for it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHoIBwACgkQkX2Xpv6ydvSWDACeONzcol5Hbx1LPHyTg3MzKLw6 TO8AnjJOeRZ4XnSXffbBbwpitnilHb7F =U1t+ -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] how to create second inlet that accepts both floats and symbols
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-07-18 19:04, IOhannes m zmoelnig wrote: basically you ahve two options: - allow lists at the second inlet, and check whether the list has only one argument of type A_FLOAT or A_SYMBOL: /* creating the inlet */ inlet_new((t_object*)x, (t_pd*)x, gensym(list), gensym(list2)); ah i forgot: this obviously will only work if the first inlet of the object need not accept all messages on it's own behalf, as the list2 selector will be reserved for the 2nd inlet. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHoKzcACgkQkX2Xpv6ydvSi9gCeLnp6wsE644eaYsmwFYPAGrfP wosAnRUCr9jOJ6ho++oBIYoSNHA36NV+ =Q4WI -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [pure-data:patches] #513 automake build fixes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-07-04 23:47, yvan volochine wrote: On 02/07/13 12:37, IOhannes m zmölnig wrote: ** [patches:#513] automake build fixes** [snip] after the latest updates in the puredata git repository (0.45.0test), the automake build-system is broken, since files have been removed from the source-tree. the attached patchset fixes this (so Pd can be build with automake again), and it also adds new files (mostly help-patches) to its install and dist targets. as of today's master (c19e7c4), build is still failing here at `./configure` with the following error: config.status: creating Makefile config.status: error: cannot find input file: `portaudio-2.0.pc.in' configure: error: ./configure failed for portaudio using 3.9.8-1-ARCH, automake-1.14 and gcc-4.8.1 you did run `autogen.sh` prior to everything, did you? fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHae50ACgkQkX2Xpv6ydvTKnwCfRof8tEVap6PlSPjN3fL7t0+r zrYAoJR8oJ//gLOWDeZYaZVf56flkmUC =kn+8 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] SIGPIPE on iemnet's tcpserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-07-04 13:55, Antoine Villeret wrote: 2013/7/3 IOhannes m zmoelnig zmoel...@iem.at On 2013-07-03 17:33, Antoine Villeret wrote: so it could be difficult to use a server which doesn't accept more than one connection... no that's not what i meant. you can have as many connections as you want, but they cannot be maintained at the same time. simple example: - both clientA and clientB send a a query to the server - to complicate things, they do so at exactly the same time - but since IP is a serial protocol, they will somehow arrive one after each other - let's assume clientB was faster - [udpserver] will output the query from clientB - if the server-patch now immediately responds to that query, the response will be sent back to clientB - then [udpserver] will output the query from clientA. - [udpserver] will forget everything about clientB - if the server-patch responds immediately to that query, the response will be sent back to clientB - if you later send something from the server, it will still be sent to clientB (because clientB is the last known connection) so in this case, if I understand correctly, udpserver never send an answer to clientA ? no, it does send and answer back. I have to disconnect clientB *before* connecting clientA ? no. UDP doesn't know about connections. but how clientA will know this is time to connect ? should it try until the connection is accepted ? again, UDP is connection-less so there is no connection. i think the main problem here comes from the use of the symbol connect for interfacing with e.g. [udpsend]. this message is named connect mainly for consistency with the tcp/ip objects. anyhow, when you connect a client to server, the client will open a socket for this connection. the server won't know anything about this connection, but it will receive data on a it's listening socket. it can use the socket to send data back (if you have routers/switches/... inbetween, this sending back will only work for a limited amount of time). since the server doesn't know anything about the connection-state of the clients, you don't have to disconnect anything. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHVZt0ACgkQkX2Xpv6ydvS1DQCg3OWfgTqDbH6P52s+1S5FOoJt q3IAn3fxytsJlhVAmepjfXsakZIYGFiT =djBg -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] SIGPIPE on iemnet's tcpserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-07-03 15:58, Antoine Villeret wrote: sorry I was not clear enough I need a server : listening on one port and sending data to client on different port i first use only udpsend/udpreceive and the 'server' was sending to a multicast group, each client join this group and receive all the data this is not possible with unicast while I can't listen several time on one port but multicasting need a working network interface (the computer need to be in a network) i don't think so. but multicast doesn't solve your problem, just as broadcast doesn't solve it. *cast works on an the IP-level, it allows you to address multiple hosts with a single packet. but afaiu, you want to address multiple applications on a single host, which is not so trivial, as each application needs a separate (receiving) port. and there is no multiportcast. so on a single host you have to address each application directly. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHUMD8ACgkQkX2Xpv6ydvTeGwCg8RgxCCzGiUnPAnCCQGIRIZyp QUgAoNrrfQTaViIcg58r5Tsb7Cnvln08 =V9PY -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] SIGPIPE on iemnet's tcpserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-07-03 16:12, IOhannes m zmoelnig wrote: i guess you meant [tcpserver] instead of [udpserver]. in any case, i'm thinking about removing the multi-client feature of iemnet's [udpserver] just to make sure: i did mean [udpserver] (which does not exist in mrpeach/net) in this mail. fgmadsr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHUMc8ACgkQkX2Xpv6ydvRxMQCfbA2cV46KuZNa2ihrn1CqYXLq 0DIAnRdUGfG43AIjtL2OsecJmErZhkhG =QW+N -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] SIGPIPE on iemnet's tcpserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-07-03 17:33, Antoine Villeret wrote: so it could be difficult to use a server which doesn't accept more than one connection... no that's not what i meant. you can have as many connections as you want, but they cannot be maintained at the same time. simple example: - - both clientA and clientB send a a query to the server - - to complicate things, they do so at exactly the same time - - but since IP is a serial protocol, they will somehow arrive one after each other - let's assume clientB was faster - - [udpserver] will output the query from clientB - - if the server-patch now immediately responds to that query, the response will be sent back to clientB - - then [udpserver] will output the query from clientA. - - [udpserver] will forget everything about clientB - - if the server-patch responds immediately to that query, the response will be sent back to clientB - - if you later send something from the server, it will still be sent to clientB (because clientB is the last known connection) so you can have as many connections as you want, but they have to be handled atomically - on after another. you cannot have clientA and clientB connect to the server, and make the server send info to both simultaneously. instead you have to adapt a query/response scheme, where each client asks the server for piece of information. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHUSAkACgkQkX2Xpv6ydvQ7dQCfWd6Ms++xbvpFYHMUArPILPeA fA8AoOo0uQuuQnJV5FBafbRsggXOqtzx =29SY -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] SIGPIPE on iemnet's tcpserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-07-03 17:44, Martin Peach wrote: Well [udpreceive] should be able to receive from many different senders, no? (It's a bug if not...) Based on what the [udpreceive] receives, route your replies to one or more [udpsend]s based on info in the incoming packets, or set the port of a single [udpsend] before sending. th problem with [udpsend]/[udpreceive] is, that you need a [udpreceive] for each client that wants to receive data, which means possibly a lot of different ports, i all [udpreceive]s are sitting on the same host. [udpclient]/[udpserver] allows to have all this with a single known listening port. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHUSLgACgkQkX2Xpv6ydvQNegCgsajUa/8ymMet0oicFIRKxYRZ 8aQAmwcPmpU/pZACSkpwjw88QHYCTMBw =qNOr -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] width control breaks parsing with [textfile]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-07-03 17:58, Miller Puckette wrote: Just to stir the pot, as it were :) - The 'f' message is intended to mean 'format' and could be expanded to specify font style and size, and/or other formatting info (perhaps even to suppress carriage return on semi, think of that!) hmm, how about calling it.. format then? there are quite a number of fs in Pd world, and i think every single one means float. (or maybe even use __format to mark it as a 'private' message) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHUSzcACgkQkX2Xpv6ydvRZYACfdrXF++yvTVAFkA93NdgNcV2T ZFcAoLtP6qjB90g6ZDzmrkQMnatTBbfF =0KiF -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [pure-data:patches] #513 automake build fixes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi miller, On 2013-07-02 12:37, IOhannes m zmölnig wrote: after the latest updates in the puredata git repository (0.45.0test), the automake build-system is broken, since files have been removed from the source-tree. as much as i personally love autotools, i'm not convinced that the current situation is any good. having two independent build-systems is bound for trouble, as they will always slightly diverge. if the automake based system is too complicated and thus not used by upstream (that is: you), there is little use in keeping it lying around. i'm not sure whether the alternative build-system works on all platforms though. gmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHSrpQACgkQkX2Xpv6ydvTQEwCeLMWUrjGXmcgaPHdI9HFwhYya J5cAnRXtJhXLlf3InOzPDEpUBVfLZVkK =yy3X -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] SIGPIPE on iemnet's tcpserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-07-02 13:39, Antoine Villeret wrote: I realize that with iemnet's version of tcpclient/tcpserver, if two client connect at the same time to server, only on receive data not the other, that's a different bug, please report it. (please also report *this* bug in the sourceforge bugtracker for pure-data) so I put a timeout to disconnect the client if no answer was received in a certain time and then reconnect i first make this with iemnet's tcpserver and I got a SIGPIPE on the server side (see my previous post) while I got SIGSEGV on the client side, here is the gdb backtrace : [New Thread 0x7fff7bfff700 (LWP 4478)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffc8ff9700 (LWP 4477)] 0x00472963 in clock_set () (gdb) watchdog: signaling pd... tip: when running Pd in a debugger, always use -nrt. general remark: to get a backtrace, please run bt in the debugger (after the crash). I think in the server side a signal(SIGPIPE, SIG_IGN); could help but I don't know where to put it (in tcpserver.c ? in iemlnet_sender.c or somewhere else ?) i don't think this is a good solution. i would prefer something along the lines of setsockopt(SO_NOSIGPIPE) and/or send(..., MSG_NOSIGNAL) - a solution that does not have side-effects on the entire Pd. also I tested it with the mrpeach's version, it doesn't crash but the GUI hangs gdb doesn't tell anything, it continue to show thread creation and exiting also I'm using iemnet's first because it has a [port( method to change the binding port on the fly and I made a rebinding routing to choose an available port in a certain range both in server and in client side to prenvent connection error if port is still used after a crash for example I don't know how to go further with this, But I really need a reliable server for some project and for now I just have an headache :-) please tell me how i can help fixing this (and please note that I don't know anything on tcp communication...) btw, my experimental repository for iemnet is at [1]. i added the MSG_NOSIGNAL flag (currently this is linux only), and the server does not crash anymore, but the clients still do. fgmasdr IOhannes [1] https://github.com/umlaeute/pd-iemnet -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHSxSoACgkQkX2Xpv6ydvRiAwCgrn20fLBsSDaDxDODerVSEGiw AG0An0u5PY21NryZawi/JdH3U02NOYAe =mQ4d -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] width control breaks parsing with [textfile]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-06-29 15:43, Roman Haefeli wrote: I don't know any solution off-hand and I also don't know whether Pd was designed with the possibility in mind to read patches with [textfile]. I just want to have it mentioned. And yes, it does break some of my patches (not that this would be a reason not go forward and change Pd's file format). since my personal preferences for those , appendices to objects go into the direction of using them for messages that the object itself can understand(e.g. #X obj 100 100 readsf~, open foo.wav; ) i'd rather vote for keeping meta-messages (e.g. those that tell the GUI-renderer which color the object should have) separate. e.g. #X obj 100 100 readsf~; #G width 10; oh btw, i really don't see a reason to use cryptic 'f' selectors, when we could use meaningful names like width. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHRfl0ACgkQkX2Xpv6ydvRhVwCg6Rc8o/AGHKAmYAjOxuxXE0SG uEoAoLe4cy6BEikkMIsytCFRFi294cPm =WYqL -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-06-19 22:06, Hans-Christoph Steiner wrote: What do you gain by removing in? I think we really need to stop wasting time on little details like this, and instead work towards real fixes. i think the biggest gain would be to not have to discuss this over and over. which i think would be a big improvement. if the function of the code was obvious, we wouldn't have to discuss it either. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHCp3EACgkQkX2Xpv6ydvT/XwCfenPQ1cxBPIrqH/mp7B+AptwY OXEAnRElcQcUcZrOUhx1dvXa4XW1dHFm =8T3/ -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] remove tk scaling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-06-18 19:39, Hans-Christoph Steiner wrote: In general, removing bits of code willy-nilly is a bad idea. sure. In this case, So follow what the comment there says: This guarantees that patches will be pixel-exact on every platform. this obviously hints at some underlying problem. still it would be great to have more references in the comments, e.g. without this, objectbox sizes will be off by one on *BSD platforms, cf. http://bugs.puredata.info/42 and http://wiki.tcl.tk/666) the vc-log doesn't reveal a lot here (the line in question has been added in commitish b23a763e import new tcl code from devel :-() the situation has become a bit better, now that 3rd party contributions (anybody but miller) use git for smaller commits. in any case, i strongly suggest that each non-obvious addition to the code should be backed up by evidence. this is time-proven code that guarantees the same behaviour on all platforms, and your addition has not been tested is a bit of a show-stopper wehn it comes to new development. nevertheless, here is some discussion that backs up *not* removing the line: http://lists.puredata.info/pipermail/pd-list/2007-11/056834.html ghsmdf IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlHBYMoACgkQkX2Xpv6ydvRb7wCg2GyOFll5FGdvg9U59l3hTvvh ZzoAn2zxVoaLrmzfsUflZAPhCqbwbxg8 =sdfC -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] Fwd: SourceForge Project Upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 so while we were busy making a lazy consensus on how to deal with the sf upgrade plans, sourceforge has upgraded the repositories for us. afaik, this changes all the links to checkout/update (SVN) and clone/pull (GIT). someone might want to update all the information in the wikis. fgmasdr IOhannes - Original Message Your svn repository in upgraded project pure-data is now ready for use. Old repository url: http://pure-data.svn.sourceforge.net/svnroot/pure-data New repository checkout command: svn checkout --username=zmoelnig svn+ssh://zmoel...@svn.code.sf.net/p/pure-data/svn/ pure-data-svn You should do a checkout using the new repository location. The old repository is read-only now. For more detailed instructions on migrating to your new repo, please see https://sourceforge.net/p/forge/community-docs/Repository%20Upgrade%20FAQ/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlGtkGoACgkQkX2Xpv6ydvRm9QCfS+6r184K5To9V/Qv20Dxp3Fm pBEAniCBgZJcABcpwfopfRmocDSGwAp6 =JxvM -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-06-02 08:51, Jonathan Wilkes wrote: Of course these are just the latencies in the settings-- I haven't done the actual measurements yet. it would be interesting to have actual measurements. everything else is wild speculation. fgmadsr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlGsP/8ACgkQkX2Xpv6ydvTNBQCg0TM1dreW18efrby4GyaEJGfk c2UAniL6+zW7ZbLqZjlGHqzueTSs7JUz =H2oS -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-05-29 06:12, Jonathan Wilkes wrote: what works for me so far is: - - run jack as the native backend on my desktop (jackd gets autostarted at login, and is running throughout my session) How do you configure jack to start at login? i configre my desktop (xfce) to start qjackctl at startup, and configure qjackctl to start jackd at startup. setting up was pretty easy by installing the pulseaudio-module-jack (on debian),and uninstalling all the other pa backends. Why is it necessary to uninstall those other backends? probably not necessary but mainly a precaution to not accidentally run a backend i don't want to use. personally i would prefer to *not* pull in additional dependencies if possible. afair, d-bus is notorious for pulling in an entire desktop environment. it does not depend on an entire desktop environment. i dimly remember some discussion (on LAD, iirc) why having jack with d-bus enabled by default was a bad idea. maybe things have improved since then. one of the problems of Pd i see is, that all the audio backends are linked into the main binary. so if you have a binary with jack/dbus support, you *must* install jack/dbus or you will not be able to use Pd at all (even if you don't care for audio at all). I must be reading different documentation than you because AFAICT jack d-bus is a user-facing option for how to get JACK to interact with the system. Recommending it as the preferred way to connect doesn't require any backend coding. maybe it's not clear from what i've written so far: i personally do not use jack/d-bus (or i am not aware of it). i was under the impression that it would require some linking against a different libjack, but it seems like that is all wrong. obviously i have absolutely no problems against *recommending* a given setup that works with the given Pd-binaries. sorry if i gave the wron impression That's a fine goal, as it would solve the problem about requiring JACK/ALSA dependencies even if the user doesn't want audio. But given a limited amount of time and money, well i have done a prototype of said plugable audio (and midi) backend support for Pd-0.43, and it's available on github. code was only tested on linux and some users reported problems with the portaudio backend (which i had problems to reproduce, since i never use the portaudio backend (as it comes with Pd-vanilla) since i cannot remember that it ever worked for me...but then i didn't try that often after initial disappointments, being quite happy with what alsa and jack had to offer directly) fgnsdart# IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlGlq20ACgkQkX2Xpv6ydvRgHgCfSz2SN0ZOaN0IerBPxfeqExLD 1ywAnj6AI9rpWupkl61sO/ta08mHN3PY =FmUR -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-05-29 17:21, Jonathan Wilkes wrote: Ok, sounds like you have two things: a) code that adds support for pluggable audio/midi backends, and b) a pluggable portaudio backend. i have two things: - - code (API+ implementation) that adds support for pluggable audio/midi backends - - converted all the existing backends to use the new API (though they are still linked statically into the Pd-binary) the code was only updated to Pd-0.43, and i haven't updated it to Pd-0.44. Does the backend have to be written differently than the s_audio_*.c stuff to be pluggable? not really . the idea was to have an API that builds on top of the current implementation of s_audio_... (which is pretty consistent throughout the various backends) so it's mainly adding a few wrapper functions that register a given backend to the core. you can have a look at it at [1] fgamsdr IOhannes [1] https://github.com/umlaeute/pd-vanilla/tree/mediabackends -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlGmH4sACgkQkX2Xpv6ydvT+7wCfWYaKMLM6/sRRr7uEmJ5J0nm6 MloAn1gy1AjjvRw6PcwMOUCXTYpJvkkE =CHEe -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-05-29 17:49, Jonathan Wilkes wrote: - - converted all the existing backends to use the new API (though they are still linked statically into the Pd-binary) What did you have to convert? check the git logs. (or read my answer on does the backend have to be written differently?) Also-- you mentioned people had tested Portaudio as pluggable backend. Have you tested using a known configuration (like with the ALSA backend) with your changes? sigh. yes, i usually do test my code. ALSA and jack seemed to work *as good* as the original (built-in) version. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlGmLEoACgkQkX2Xpv6ydvTu7gCgpFgsK97SRhHmA52KZqqGoYDF yJcAn1tsiAzT0ibq5/dPuKHj9m63zZfM =Uo2T -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] jack dbus?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-05-28 07:08, Jonathan Wilkes wrote: Ok, quick restatement of the problem: How does one get Pd to just run in GNU/Linux for casual/sporadic use cases? Like 1 fire up Pd to patch an idea with Firefox/music player/other stuff sitting in the background 2 audio from online tutorial while patching in Pd with audio 3 some dude screwing around in Ubuntu with it, learns enough to get interested in fairly low latency to process some guitar sounds, possibly live Cases 1 and 2 could benefit from having a PulseAudio backend in Pd, but case 3 would still be a pain because at the point that the guitarist cares about latency he/she is back to screwing around with audio settings (either directly through ALSA or with JACK). (If I'm wrong and Pulse can cover use case 3 I'd like to hear about it, but from what I've read Pulse is not designed with realtime audio processing as a goal.) what works for me so far is: - - run jack as the native backend on my desktop (jackd gets autostarted at login, and is running throughout my session) - -- obviously Pd will always use the jack backend - - run pulseaudio *on top of jack*. - -- thus any pulseaudio-aware application (like firefox) can simply play back - -- i can route pulseaudio-apps into Pd (not that i ever needed this in real life) i really think that this is the way to go: have any consumer-framework sit on top of a pro framework, rather than the other way around (e.g. have pulseaudio provide a virtual alsa-device) setting up was pretty easy by installing the pulseaudio-module-jack (on debian),and uninstalling all the other pa backends. So, I'm curious about this: http://trac.jackaudio.org/wiki/JackDbusPackaging Specifically the D-bus only JACK route. _If_ it works reliably (and of course that's a big if) then it gives the best of both worlds: all cases 1,2, and 3 above are covered by the JACK server automatically starting and Pulse getting out of the way for it. Moreover, Pulse clients get routed to JACK with what I take are sane defaults. So, if you have Pd running through JACK with this setup and then you open up a youtube video in Firefox, Pulse will automagically make a connection to JACK for it and (I'm guessing) hook it up to the output. Any thoughts on this? personally i would prefer to *not* pull in additional dependencies if possible. afair, d-bus is notorious for pulling in an entire desktop environment. one of the problems of Pd i see is, that all the audio backends are linked into the main binary. so if you have a binary with jack/dbus support, you *must* install jack/dbus or you will not be able to use Pd at all (even if you don't care for audio at all). I'm thinking if we could build up a body of knowledge on this approach it would be the easiest way to get worry-free audio setups with GNU/Linux distros that wouldn't give new users headaches. Plus it would scale up: if they learn and care about insanely low latencies, they are already using JACK so it's just a matter of firing up qjackctl or whatever and configuring the audio server they've been using. from a technical perspective, i think that the way to go is to support as many (pro and consumer) audio backends as possible, but always make this a runtime-choice (that is: make audio backend support in Pd a loadable mechanism) fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlGkXBgACgkQkX2Xpv6ydvRxOgCg7sHPrM2tsFzx3n9hKmxUquvY lcYAoOU+IvT1vEi8vQdexgI7Te4qIW/C =y+ic -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Gui plugins management (Was: I have 3 broken installs)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-03-27 22:06, Jonathan Wilkes wrote: I think what Hans means is that it's very simple and easy for him to maintain as the Pd-Extended guy. Got a handy plugin for managing plugins? Throw it in this directory. Is it pretty stable? He'll throw it in the distro. Not maintaining it anymore? He can just remove it from the distro. In none of those scenarios does Hans end up with new functionality in the core of the GUI that he is now forced to maintain or remove altogether. i'm not talking about PdX. i'm talking about Pd (vanilla): just like the loading of externals is managed in Pd-core, the loading of gui plugins should be managed by Pd-gui. and managing should not translate to automatically loading whatever is there. i don't think that a simple plugin manager is too complicated (and needs too much maintainance attention). what's more: if you don't like it, you can always create a pluginmanager-plugin and tell the default pluginmanager to _only_ load the new pluginmanager-plugin, which in turn can do a nicer job. the problem we are facing right now, is that a lot of gui-plguins get activated automatically, and i have no choice to disable that. at least without switching to my favourite filesystem browser, search for the offending plugin (while the documentation only mentions 2 paths where the plugins can be installed, there are really 3-4 that are always searched, not counting the paths added with -path, so where the hell should i start searching? how am i to guess that the file wurdel.tcl is really the plugin that colorizes all text light-green?) and move it out of the way (after asking my sysadmin for the root-password, since that plugin really was installed somewhere i am not allowed to change files). an intermediate way could be: - - keep the current behaviour of loading all gui-plugins - - only install a _single_ guiplugin by default, that in turn loads gui-plugins from _another_ search path. - - people can download a more sophisticated guiplugin (plugin-manager) and replace that load-all-plugins plugin. (not really ideal, as it kind of perverts the documentation, where to install plugins; also the load-all-plugins is most likely installed with root priviliges, so again i have to ask my sysadmin to replace it) similar, though slightly better: - - only automatically load a specially-named plugin (e.g. autoloaded-plugin.tcl) that handles the loading of the other plugins. - - ideally Pd-gui would only try to load a single plugin of that name (so if you have ~/pd-externals/autoloaded-plugin.tcl and /usr/local/lib/pd-externals/autoloaded-plugin.tcl and /usr/lib/pd-extended/autoloaded/plugin.tcl it will only load the one in ~/pd-externals) - - in case this special plugin is not available, revert to the default behaviour of loading all plugins in all search-paths (this would allow to have the old behaviour, but to be easily able to override this behaviour if you don't like it) all these require to modify the pd-gui. but so does any bugfix (and i'm pretty sure that the solution to bugs is to fix, even if the bugfix might not see much maintenance by the original submitter afterwards) gfmasdrs IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlFUImEACgkQkX2Xpv6ydvQ5LQCcDptr+iliwPpKMxGvwUpj5jG3 fAMAn0ZxmVOwY2NVHj6zjh95lVqCoSbT =8epp -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Gui plugins management (Was: I have 3 broken installs)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-03-27 21:12, Hans-Christoph Steiner wrote: I think that a -noplugins flag is a no brainer, that should be included. I'm still on the fence about adding the ability to disable plugins via the interface. The model so far for installing and disabling externals, plugins, etc. is putting them in the user-installed folder or moving them out of that folder. Its very simple and easy to maintain. definitely not. i find myself cursing everytime i want to use/not use a given gui-plugin. moving files around is _not_ a way to configure your system. at least i know of no system that is configured like that; not that there *are* some system settings that work like that (`find /etc -type d -name *.d) but those are not for user-preferences that might change today *and* tomorrow. also, there might be a reason why Pd-extended switched from loading all libraries by default to a scheme, where the user has to explicitely enable a given feature. taking your gui-plugins argument to PdX, we could have simply told the users to just move all the objects/externals they don't want to use to a save place (and turn off the couldn't find errors) I have no objections for adding the possibility to allow plugin management in a plugin, but I'm not sure about including it by default. it's simply not possible to unload a given plugin with a plugin that is loaded afterwards. (at least not until all the gui-plugins implement an unloading mechanism). if we have the opportunity to get a built-in gui-plugins management instead of the last-files i'm all for it (as the latter can be easily implemented as a plugin, unlike the former) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlFTViAACgkQkX2Xpv6ydvRlKwCePi9YMhKSniXe0dQOu0uUtuSM HP4AoOyMXRQLwb8BbEBgJW1IGupAOr8T =592W -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] info classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-03-11 04:30, Jonathan Wilkes wrote: not really, as there has been the mediasettings library around for about two years. No, it's still difficult to control audio settings programmatically in Pd Vanilla, Pd-l2ork, and Pd-extended. Users shouldn't have to fish around for and compile an external library just because they'd rather have ALSA sent to a canvas instead of the console. probably true, but i don't know how you can fix this. it seems like your obvious solution is to include [pdinfo] into Pd-vanilla, Pd-extended and Pd-l2ork. you can also simply include [audiosettings] and [midisettings] into Pd-vanilla, Pd-extended and Pd-l2ork. the advantage of the 2nd solution is that it is already there and a few people are already using it, whereas your proposal gives exactly the same functionality but is (afaict) not already there. and [pdinfo] sounds like a query-only object rather than an object that can control Pd. gfmsdt IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlE9lI8ACgkQkX2Xpv6ydvRtVQCfS40Xo6Ur1rrkD1ss9vH6BH0a txwAoNhqDGw6YnkyKm5oqDPXIIosVKmm =yR8F -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] iemnet crashes on Windows XP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-03-07 11:14, Roman Haefeli wrote: Hi all I only noticed now that many of the iemnet classes crash Pd on Windows XP. The problem seems specific to Windows XP. The crashes cannot be reproduced on Windows 7. thanks. could you post a bugreport at sf? fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlE4ackACgkQkX2Xpv6ydvR5HgCg3/TVVOhKxmA2zVv7CqtOJL5p FN4AnRlmRfnPUcJZwAvJC0qdXVtCPvYf =zXpT -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] new IP address for macosx105-i386.pdlab.puredata.info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-31 04:17, Hans-Christoph Steiner wrote: The IP address has changed for macosx105-i386.pdlab.puredata.info its now: 184.75.101.123 thanks. i've updated the DNS entry. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEKPlYACgkQkX2Xpv6ydvSMyQCfeZNVy2SQg0symNvaZAQOGvdo cd4AoOEsOgv8bJhoz8j2w1tgaj5v2y4m =yl4F -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] ssh access to MacOSX106-x86_64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-22 19:52, Hans-Christoph Steiner wrote: chaos.medien.uni-weimar.de is the actually hostname of that machine and 141.54.159.89 is the IP. MacOSX106-x86_64.pdlab.puredata.info just maps to puredata.info, so that's not right. just for the record. macosx106-amd64.pdlab.puredata.info points to 141.54.159.89. there was no DNS-record for macosx106-x86_64.pl.pd.i, that's why it resolved to the fallback address (puredata.info). i have now added macosx106-x86_64 as an alias to macosx106-amd64 to the DNS. i'm *not* very regularily monitoring subpages [1] to see whether new hosts have appeared or disappeared, or whether their IP address or name have changed. i very much rely on the people forwarding this info to me, so i can add it to the DNS. i'm aware that this has not been made explicit anywhere (esp. not on [1]), which probably explains why nobody does it. fgamsr IOhannes [1] http://puredata.info/docs/developer/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEA+CEACgkQkX2Xpv6ydvQP2ACfQC5wWQMUaUa1B8lGn8Uf60/N iy4AnRmAJfS0ITLmqIiKlpWtTO3awFMd =f+F8 -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD-ot] Xcode and some commands
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-14 12:50, Alexandros Drymonitis wrote: Hi all, hi. this is probably best targetted at pd-dev (pd-list), but anyhow... I'm trying to install some externals in Pd vanilla. Till now I've managed to install the Gem library. But now I'm trying to install zexy, but opening Pd with the '-lib zexy' flag from the command line is not enough. Trying to follow the installation guidelines of the library, I'm facing some problems. Trying to run './bootstrap.sh; ./configure; make' I get the following errors: ./bootstrap.sh: line 3: aclocal: command not found checking for gcc... no checking for cc... no checking for cl.exe... no configure: error: in `/Applications/Pd-0.44-0.app/Contents/Resources/extra/zexy-2.2.4/src': configure: error: no acceptable C compiler found in $PATH See `config.log' for more details -bash: make: command not found I have Xcode, version 4.5.2 installed in my /Applications directory (I've been told in the past I need to have developer tools in order to be able to run some commands), but that won't do the job..maybe it's quite obvious, but my knowledge on this is extremely limited. Any ideas? Obviously I have OS X. My version is 10.8.2, upgraded since I have quite an old laptop. i cannot help you in detail (some other devs might be more osx-savy, though), but i will try to give some generic hints. it seems like your system cannot find a number of needed things, namely - - a valid compiler (gcc) - - a valid make - - working autotools (e.g. aclocal) at least the former two should be installed when you have XCode properly installed. either you missed something when installing (e.g. only copied XCode app, but forgot to run the installer), or you have to add some paths to your PATH variable. try locating the make binary (e.g. `find / -name make`) and add that path to your PATH. autotools used to come with xcode, but it seems that they are not shipping it any longer (confirm [1]). you might have luck using a package-manager like fink. fgasdrm IOhannes [1] http://jsdelfino.blogspot.co.at/2012/08/autoconf-and-automake-on-mac-os-x.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlD0BRMACgkQkX2Xpv6ydvTyHwCgvDNVxboc0fWpO8UfWVCtQMoj +pcAoNR8SCx4CEerQL/EAmUKbcyWkAgQ =BZPs -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] from t_symbol to t_class
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-13 18:50, Jonathan Wilkes wrote: but adding/revising code inside class_new would retain 100% binary compatibility, whereas adding members to public structures is a 100% guarantee to break binary compatibiliy. And if I just put the struct inside m_class.c but not in m_pd.h is that enough to keep it from being exposed? yes, that shouldn't be a problem. i was mainly concerned about your plans to extend the existing t_symbol (but i might have misunderstood your suggestion). Another questions-- inside class_new when I add a class/symbol pair to the list (I suppose by calling a function to add an entry to the list), I need to walk the current list to see if that symbol has already been added and overwrite the old class pointer with the new one, right? And if so, won't this searching add to the patch load time? yes. obviously, all code that you add will eventually take some ime to execute. however, i wouldn't worry too much about that before it becomes obvious that it takes too long...Pd already handles quite a number of linked lists that are searched linearily. e.g. calling class_new() already checks, whether the new class is already in the long list of objectclasses registered with pd_objectmaker, and this is not the reason why it takes long to load large patches. otoh, it would of course be nice to abstract these hashtable-like structures away, in something like std::map; this would make it easy to switch to a different algorithm (eg. binary trees) once we find that a linear search is the bottleneck. fgasmdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlD0Bz0ACgkQkX2Xpv6ydvT0ggCg0h1nqbsPzsuKTUhxa+yd4Khk 9G4An1nt6vfPlQj3lMLf4+M0j9PJbk5F =J5Ry -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD-ot] Xcode and some commands
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-14 19:04, Alexandros Drymonitis wrote: Ok, installing command line tools did help, but didn't do the whole job. I tried to install fink, and to be honest I'm not sure if everything went well. I tried to install the zexy library again and now I get these errors: ./bootstrap.sh: line 3: aclocal: command not found (IOhannes recommended fink for this one) configure: error: m_pd.h is desperately needed! install pd and/or use --with-pd=/path/to/pd/ or --includedir=/path/to/pd/src/ and ./zexy.h:51:10: fatal error: 'm_pd.h' file not found Any ideas on this one? you probably should read the error message. it clearly says that it you should install Pd and/or use the --with-pd flag to tell configure where it can find m_pd.h (which is Pd's main header file) fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlD0SS4ACgkQkX2Xpv6ydvSDeQCg4R0UI9Tb921+bdZYOyfPmGME /kEAnj8JUwgWQLd6nVugDGhuZ/r5cA2M =YVry -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] autobuild: fribidi support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-10 16:48, András Murányi wrote: On Wed, Jan 9, 2013 at 3:11 PM, Hans-Christoph Steiner h...@at.or.atwrote: Does Gem 0.93.4 in Pd-extended have support for this lib? ah, i only answered hans on the chat, so: bidi-support was added to Gem/git this monday, so no, Gem-0.93.4 as found in Pd-extended does not support it. Well, today's Pd-extended in lucid-amd64 built alrite without it, most libraries Gem uses are optional, so builds will succeed even if they library in question is missing (though the resulting binary will obviously not be able to use the nifty gimmicks from libXY) but I've installed it now anyway. thanks. adfmsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDu498ACgkQkX2Xpv6ydvQMIACcCw0SOGlZPWMFLYD4Ff2y7gx8 UcwAoO0ahMdWsTu5p2xK9Vuu/dg11oqv =QBOR -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] stackoverflow tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-09 02:18, Thomas Mayer wrote: OK, so here is the question (and the tag): http://stackoverflow.com/questions/14226869/how-to-keep-audio-and-video-gem-synchronised On 08.01.2013 23:05, Hans-Christoph Steiner wrote: Anyone on Stack Overflow with more than 1500 reputation? If so, please create a puredata or pd tag, you need at least that many points to be allowed to do so. http://stackoverflow.com/privileges/create-tags thanks for creating that tag. coincidentially, i have been procrastinating in the last few days and trrying to raise my score to 1500 in order to do exactly that: create a [puredata] tag (after i found a question that was Pd related and was tagged [pure] and [data]) The question is, I guess, should the official tag be 'puredata' so we can beat IBM to the punch, or 'pd'. I think 'puredata' is clearer. i guess creating a synonym would be a good idea. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDtLSMACgkQkX2Xpv6ydvSpAwCg4YBft7yAASPseuC4dPgz9nhU 82AAoLkPKWutehD7VL/DpXFfAmmj6fo8 =zW7C -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] jenkins: macosx105-powerpc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 quick question: is the osx10.5-ppc machine gone for good, or is it likely to return? the machine seems to be online, but i cannot login to it any more (Permission denied (publickey)). also jenkins hasn't built on that machine for a while now. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDtZdwACgkQkX2Xpv6ydvTGxwCgkujMzUXdTydGfu2nKMCgEuq8 QQkAoMlGOcyUe8YgfVS8GvdMqkLCldVi =gCFi -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] autobuild: fribidi support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi. recently i have added bidirectional text rendering support to Gem (this basically means that arabic and hebrew strings will be correctly rendered right-to-left). however, this depends on the libfribidi library [1]. since there exist packages for debian and fink (though those are a bit outdated), would it be possible to install them on the autobuild servers? fgasdmkr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDtbXIACgkQkX2Xpv6ydvRQ4gCfSJicoUFrfS8zjFQJjc4k4teO 5poAoKqWdUqeNdClx5PvkOUkA/ro14Uq =HRUA -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] autobuild: fribidi support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-09 14:15, IOhannes m zmoelnig wrote: hi. recently i have added bidirectional text rendering support to Gem (this basically means that arabic and hebrew strings will be correctly rendered right-to-left). however, this depends on the libfribidi library [1]. since there exist packages for debian and fink (though those are a bit outdated), would it be possible to install them on the autobuild servers? fgasdmkr IOhannes [1] http://www.fribidi.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDtbYsACgkQkX2Xpv6ydvTc8ACffcHOiYwI5WnxYhrMk/T5wOzn SSoAoO9fAdY76tAsGudqJaECxUrpjLlx =GCSK -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] help patch bug reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-12-20 15:27, Hans-Christoph Steiner wrote: Hey Jonathan, I'm guessing that you're the one filing all the bug reports about help patches. I'm wondering what your goal is with filing them. It seems that you're also committing stuff to the same help patches? of course i cannot speak for jonathan, but it seems like the help-patch edits remove the TODO found in [pd META] - as these TODOs are now tracked in the bugreport tickets: moved doc errors from META subpatch to svn tracker actually i think having these tickets in the sf-tracker is a good idea. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDTM+cACgkQkX2Xpv6ydvTiRgCdFONctusJ6hGKnWh0dEHWDhWb pKAAoPE8UoAu7DKlQ8nXVOyiD9kIlR6V =t7BP -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Win32 - unicode support for files, with public API for externals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 the recent commit 78b81aa3cb90 on the puredata/master branch breaks ABI compatibility with externals compiled for Pd-0.43. the problem is that the sys_close() symbol is removed for non-w32 platforms. therefore all the externals on non-w32 that (already) use sys_close() (at least i have written a couple of them) will fail to load with a new version of Pd, unless they are recompiled. this makes packaging externals for e.g. Debian a nightmare, as it basically should trigger a .so-name change, but since we are linking against the application instead of an ordinary library, all the tools that would detect such an incompatibility will fail. so please revert the #define sys_close close stanzas. instead i would ask you to provide sys_open() (and friends) implementations in s_path, even for platforms where they are mere wrappers around the system functions. it also makes the header-file much easier to read (i don't think anything in a public header-file but function decorations should be ifdef'ed) fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDO7BgACgkQkX2Xpv6ydvTMIQCfYM+ifUeF2H3Bgh/o5C4S2vuz kBEAnjfhlPz5jlU1KEIoZbAumtYF++B7 =maMx -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Win32 - unicode support for files, with public API for externals
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-12-17 10:55, IOhannes m zmoelnig wrote: this makes packaging externals for e.g. Debian a nightmare, as it basically should trigger a .so-name change, but since we are linking against the application instead of an ordinary library, all the tools that would detect such an incompatibility will fail. this is not only theoretical, but already happened: the Gem binary as currently packaged in Debian cannot be loaded anymore with the git/master version of puredata. so please revert the #define sys_close close stanzas. instead i would ask you to provide sys_open() (and friends) implementations in s_path, even for platforms where they are mere wrappers around the system functions. i created a patch on sourceforge that implements sys_f?(open,close) on all platforms and thus re-establishes binary compatibility. the new functions are simply wrappers around the system open/close functions. the open wrappers also use sys_bashfilename (like the w32 version), which should be quite a noop on non-w32 platforms for now. see: https://sourceforge.net/tracker/?group_id=55736atid=478072 fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDO/G8ACgkQkX2Xpv6ydvQXIgCdFle8ob8Lxjr5kDWIP70vDAnk ydAAoN2GQfXZT/gPKxIIJIxeakY+k/Yb =icDB -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] autotools on Mac OS X WAS: Build failed in Jenkins: pure-data » macosx106 #164
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-12-10 22:17, Hans-Christoph Steiner wrote: I'm CC'ing pd-dev since this is good to have in the public and on the record. yes, definitely. thanks. i'm moving it from pd-list to pd-ev though. I think the problem was that Fink's 'autoconf' was installed but not Fink's 'automake-1.10'. So we need to decide to either go full native or full Fink for the autotools. The minimum build env I support is 10.5, so that means: i think this explains the problem and suggests the correct solution. If things need newer versions than that, then I say we just use all of the Fink packages. Then we could have: personally i think it is a good idea to have the build farm provide both native and fink environments. for PdX, fink is probably the way to go, but for single externals it could be interesting to build it on the native platform as well. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDG8EcACgkQkX2Xpv6ydvQlhQCgo02KBadGwAwX0GdUu4e8hHOM Zv8AoNiVmkveL2MRjyRj4+b/WqvnDyya =xCsH -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] adding a built-in [change] object to the built-in GUI objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-12-03 18:10, Jonathan Wilkes wrote: It'd be even better to use a modern GUI toolkit that has simple tools to implement bleeding edge UX technology from the past 15 years. Stuff like hyperlinks. :) if hyperlinks is the criterion, then i don't see any problems with tcl/tk. fgasdmr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlC83a4ACgkQkX2Xpv6ydvRrYwCg4GEd95Nns/+NYfxLTBwLL02y VckAoNH7DA9MPFwGcpfGYAXNohrI7Q8k =0weM -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Patches-3591846 ] portaudio fixes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-12-03 19:05, SourceForge.net wrote: Comment By: Miller Puckette (millerpuckette) Date: 2012-12-03 10:05 Message: I tried this and got: [...] ... is there any way you can supply a patch that doens't add trailing white space to 1/2 ot the Pd source? thanks M hi miller. for what it is worth, my usual workflow now includes a whitespace checker, so i don't incidentally submit patches with whitespaces any more (i simply enabled the pre-commit hook in my .git/hooks/). this has been active for some time now (on all machines i currently develop on) otoh, the trailing whitespace in _this_ patch was intended, in order to keep the portaudio sources as untouched as possible. the portaudio source base doesn't seem to care at all, whether they have lines ending with whitespace or not. afaict, your original portaudio import also contains trailing whitespace (at least that's how i discovered that in order to keep the patch-set minimal, i should preserve the trailing whitespaces). if you would prefer, i could prepare another import of portaudio without trailing whitespaces. fg,asdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlC87K4ACgkQkX2Xpv6ydvT5lQCeIVbZtcj0X2r49wxIiSDW4LR3 dFAAn1T2CUMbw1SLCRIA0nVT7/Qid98V =3CjY -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Patches-3591846 ] portaudio fixes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-12-03 19:49, Miller Puckette wrote: Aha... so all the whitespace trouble was their fault, not yours :) Anyhow, it's on the tracker, but you can get the one I was using: http://crca.ucsd.edu/~msp/tmp/pa_snapshot_20121031.tgz but I'd sort of rather not haul all the examples, tests, qa, and wierd APIs into the Pd tree if there's any smooth way to avoid that - can it be done by making minor adjustments to makefiles in Pa insteadby any chance? yes, i think this should be possible as well. do you have a particular reason to use the 2012-10-31 snapshot rather than the one from tonight? i could try to make your import work as well (i cannot fully remember what was the reason your import broke the build; i think it was mainly due to some forgotten build-files, which are usually gitignored because they are generated; in the case of portaudio i think we have to make some exceptions to the never add generated files to the VCS rule) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlC89ZYACgkQkX2Xpv6ydvRJCACfa9T8GtvlNdUG+dX2JBAv0fSC KSUAoM5Xz7dJbPiq58rt4F500uxOkRCp =EbYz -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] separate the audio-backends
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-10-31 04:11, Hans-Christoph Steiner wrote: I think this would be super valuable. libpd already has an implementation of parts of this idea, but making fully separate modules would be quite nice. Have you talked with Peter Brinkmann at all? It would be nice to have these efforts synced up since they seem to have the same aim. i haven't talked with peter about this recently. anyhow, i cleaned up the code a bit and pushed it to my github fork. check it out at [1]. currently MIDI has not been touched yet. also the preferences system (including startup flags) would need some slight modifications (e.g. use something like -audioapi jack rather than -jack; and use symbolic values (audioapi: jack) in the .pdsettings file as well, rather than some weirdo numbers (audioapi: 42 anyone?) fgmasdr IOhannes [1] https://github.com/umlaeute/pd-vanilla/tree/mediabackends -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCQ9AIACgkQkX2Xpv6ydvQhQgCdF+C0QXLfVk1HUM2+ki1YaaqA 1LUAn34WVKXiVJcxPFnlLx7+D2hPrDz8 =F8km -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] non-2^n blocksizes (was Re: [ pure-data-Feature Requests-3578019 ] I'd like to...)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2012-10-24 02:56, Miller Puckette wrote:
I think the most nearly correct thing to do would be to change the
signal structure to add an ?allocated-size field, and put what is
now calcsize in the s_n field of the signal.
m_pd.h
typedef struct _signal
{
int s_n;/* number of points in the array */
t_sample *s_vec;/* the array */
t_float s_sr; /* sample rate */
int s_refcount; /* number of times used */
int s_isborrowed; /* whether we're going to borrow our array */
struct _signal *s_borrowedfrom; /* signal to borrow it from */
struct _signal *s_nextfree; /* next in freelist */
struct _signal *s_nextused; /* next in used list */
int s_vecsize; /* allocated size of array in points */
} t_signal;
/m_pd.h
now i haven't recently checked the mechanics how all these variables
are used internally, but according to the comments i would have
guessed that, s_vecsize is the allocated-size field, and s_n is
the actual (to-be-computed) vectorsize.
I'm not 100% sure I can change the size of the signal structure
without breaking binary compatibility with older objects.
i think that t_signal is used by reference everywhere, which would
grant binary compatibility, as long as you only add the end of the struct.
However, there's other stuff I want to add (to support objects
being able to detect when there's no signal connected to an
input). I think when I make that change I can
more important for me would be fields to separate
overlap/resampling/samplerate.
PLEAASE!
try making the non-power-of-two thing work too. But I'm not sure
anyone will ever use it - there are other ways to process images
these days :)
there have been other ways to process images before...
i still would love to see non-2^n blocksizes, ideally allowing
reblocking to sub-patches if one blocksize is an integer multiple of
the other.
mfgasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlCHl58ACgkQkX2Xpv6ydvRsDwCg0PdpIpSJWG8BSV8BzjKhyIYQ
hnMAnjOpUesgkuagN8gxTkVuil+HYvmu
=iFUL
-END PGP SIGNATURE-
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] non-2^n blocksizes (was Re: [ pure-data-Feature Requests-3578019 ] I'd like to...)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-10-24 09:24, IOhannes m zmoelnig wrote: On 2012-10-24 02:56, Miller Puckette wrote: I'm not 100% sure I can change the size of the signal structure without breaking binary compatibility with older objects. i think that t_signal is used by reference everywhere, which would a quick grep over the entire externals-svn for signal_t without a trailing '*' seems to confirm this assumption (note however, that my grep does not catch any dereferences, so the check might be incomplete) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCHm00ACgkQkX2Xpv6ydvQnvQCg6EQYIBAB+3JDbjSxe8fNLUiE R3oAoIn4EhZNjIq6eqVbtMzWVUsxJN3m =A2Wr -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] non-2^n blocksizes (was Re: [ pure-data-Feature Requests-3578019 ] I'd like to...)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2012-10-24 02:56, Miller Puckette wrote:
I think the most nearly correct thing to do would be to change the
signal structure to add an ?allocated-size field, and put what is
now calcsize in the s_n field of the signal.
attached is my somewhat simplistic attempt to make non-2^n blocksizes
work.
i have run some basic help-patches with it and it seems to work fine
(though i expect problems with e.g. fft-objects in non-2^n mode).
fgmasdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlCHqHcACgkQkX2Xpv6ydvTlcwCgmczoV5OY5vBM0+AlF+ReOa2o
LcoAmwcYa6HUxuiU53NonrksunqxseIf
=9IT/
-END PGP SIGNATURE-
From 66e1578b0a9500e754a82f2cc948be6fabb2e6fa Mon Sep 17 00:00:00 2001
From: IOhannes m zmoelnig zmoel...@iem.at
Date: Wed, 24 Oct 2012 10:18:38 +0200
Subject: [PATCH] allow non 2^n blocksizes
---
src/d_ugen.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/src/d_ugen.c b/src/d_ugen.c
index 1ed3960..a282ec4 100644
--- a/src/d_ugen.c
+++ b/src/d_ugen.c
@@ -427,7 +427,7 @@ void signal_makereusable(t_signal *sig)
signal whose buffer and size will be obtained later via
signal_setborrowed(). */
-t_signal *signal_new(int n, t_float sr)
+t_signal *signal_new(int n, int calcsize, t_float sr)
{
int logn, n2, vecsize = 0;
t_signal *ret, **whichlist;
@@ -464,7 +464,7 @@ t_signal *signal_new(int n, t_float sr)
ret-s_nextused = signal_usedlist;
signal_usedlist = ret;
}
-ret-s_n = n;
+ret-s_n = calcsize;
ret-s_vecsize = vecsize;
ret-s_sr = sr;
ret-s_refcount = 0;
@@ -475,7 +475,7 @@ t_signal *signal_new(int n, t_float sr)
static t_signal *signal_newlike(const t_signal *sig)
{
-return (signal_new(sig-s_n, sig-s_sr));
+return (signal_new(sig-s_vecsize, sig-s_n, sig-s_sr));
}
void signal_setborrowed(t_signal *sig, t_signal *sig2)
@@ -739,7 +739,7 @@ static void ugen_doit(t_dspcontext *dc, t_ugenbox *u)
if (!uin-i_nconnect)
{
t_float *scalar;
-s3 = signal_new(dc-dc_vecsize, dc-dc_srate);
+s3 = signal_new(dc-dc_vecsize, dc-dc_calcsize, dc-dc_srate);
/* post(%s: unconnected signal inlet set to zero,
class_getname(u-u_obj-ob_pd)); */
if (scalar = obj_findsignalscalar(u-u_obj, i))
@@ -779,10 +779,10 @@ static void ugen_doit(t_dspcontext *dc, t_ugenbox *u)
if (nonewsigs)
{
*sig = uout-o_signal =
-signal_new(0, dc-dc_srate);
+signal_new(0, 0, dc-dc_srate);
}
else
-*sig = uout-o_signal = signal_new(dc-dc_vecsize, dc-dc_srate);
+*sig = uout-o_signal = signal_new(dc-dc_vecsize, dc-dc_calcsize, dc-dc_srate);
(*sig)-s_refcount = uout-o_nconnect;
}
/* now call the DSP scheduling routine for the ugen. This
@@ -874,7 +874,7 @@ void ugen_done_graph(t_dspcontext *dc)
t_block *blk;
t_dspcontext *parent_context = dc-dc_parentcontext;
t_float parent_srate;
-int parent_vecsize;
+int parent_vecsize, parent_calcsize;
int period, frequency, phase, vecsize, calcsize;
t_float srate;
int chainblockbegin;/* DSP chain onset before block prolog code */
@@ -917,11 +917,13 @@ void ugen_done_graph(t_dspcontext *dc)
{
parent_srate = parent_context-dc_srate;
parent_vecsize = parent_context-dc_vecsize;
+parent_calcsize = parent_context-dc_calcsize;
}
else
{
parent_srate = sys_getsr();
parent_vecsize = sys_getblksize();
+parent_calcsize = parent_vecsize;
}
if (blk)
{
@@ -987,7 +989,7 @@ void ugen_done_graph(t_dspcontext *dc)
if ((*sigp)-s_isborrowed !(*sigp)-s_borrowedfrom)
{
signal_setborrowed(*sigp,
-signal_new(parent_vecsize, parent_srate));
+signal_new(parent_vecsize, parent_calcsize, parent_srate));
(*sigp)-s_refcount++;
if (ugen_loud) post(set %lx-%lx, *sigp,
@@ -1068,7 +1070,7 @@ void ugen_done_graph(t_dspcontext *dc)
{
if ((*sigp)-s_isborrowed !(*sigp)-s_borrowedfrom)
{
-t_signal *s3 = signal_new(parent_vecsize, parent_srate);
+t_signal *s3 = signal_new(parent_vecsize, parent_calcsize, parent_srate);
signal_setborrowed(*sigp, s3);
(*sigp)-s_refcount++;
dsp_add_zero(s3-s_vec, s3-s_n);
--
1.7.10.4
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Feature Requests-3578019 ] I'd like to...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-10-18 10:16, Claude Heiland-Allen wrote: ..know if it is possible to use other than 2^n-blocksizes?! Not for audio connected to a dac~, but for offline stuff it works (some buggy objects might not cooperate). You know, I've read about that, and now I wonder if the info or the implementation is bugged.. Works for me following the somewhat-cryptic guidance in [switch~]'s help, see attached. hmm, but it seems that the actually computed blocksize is rounded to the next power-of-2. in your example, the actual blocksize is not 12345 but 16384 samples (simple check: make your table big enough to hold 15000 samples, and use [tabsend~] instead of [tabwrite~] -- triggering DSP will fill the entire table with noise; resizing the table to e.g. 2 shows that [tabsend~] only writes the first 16384 samples) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCGxHIACgkQkX2Xpv6ydvSZagCgipLpyjwFw/nS2mmmQLvUJPvy cW8An2gJ4Hlesc+6EyGpjhNFA6ML61xc =YkTd -END PGP SIGNATURE- ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Fwd: Pure Data Computer Music System and the New SourceForge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-10-08 23:39, Hans-Christoph Steiner wrote: Looks like we'll eventually have to upgrade to the new SourceForge. Anyone know anything about the new one Allura? thanks for taking this up (i just wanted to write a similar email). while i don't know much about the allura either, i have decided to run a test upgrade on one of my other sf-projects. hopefully i will know more after the upgrade took place (it is currently in state upgrade scheduled) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBzywQACgkQkX2Xpv6ydvQlgACdGvUo/mB10wQpzd8LPEeKXbNo 4w4AoPJgw02Jj1BA2cL7hnTRvaXDvsfS =w/rW -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] [PD-announce] pd 0.43-3 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-04 21:12, Miller Puckette wrote: Also... I think OSS/MIDI is the only API now that lets you spit out arbitrary byes over the MIDI line -- all the others 'protect' you. i'm not saying that i want to remove OSS-MIDI. i'm saying that i want to allow the user to remove OSS-MIDI, if they don't care for it. to repeat: my patch is about adding more audio systems without touching the Pd-core. it's not about removing unused backends (though about making them optional) fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/1QYEACgkQkX2Xpv6ydvSuIQCfZleTIcbYgsQBC8jI2iM99847 iXkAnjc9bVENLrSKLJo7NHQRMSRd2q6b =fo0d -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] [PD-announce] pd 0.43-3 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-03 23:11, Miller Puckette wrote: Hi all, Pd version 0.43-3 is available on http://crca.ucsd.edu/~msp/software.htm cool. I'm ready to start hacking on 0.44. The most urgent thing seems to be for me to go back and work on the audio system (and perhaps tweak MIDI a bit more too). i have a project lying on my hardisk for 1 year (iirc, shortly before the 0.32.0 release), that is related to that: separating the audio system(s) from Pd-core. background: currently Pd supports a number of audio-backends. while these backends are mainly separated into several source files (e.g. s_audio_alsa.c for ALSA), there is a lot of theoretically backend-agnostic code (s_audio, s_midi, s_main) cluttered with #ifdef USEAPI_ALSA and the like. this makes the current code badly readable and thus maintainable, it also makes it hard to add new audio systems as backends (and the more you add, the more complicated the codebase gets). more background: currently all audio backends are linked to the main Pd binary. if your version of Pd is compiled for alsa, jack, OSS and portaudio (the default on debian), you have quite a number of dependencies. (as maintainer of the puredata debian package i prefer to keep necessary dependencies at a minimum). furthermore, Pd supports outdated/deprecated backends like OSS (both audio and midi). in practice i haven't used OSS-midi for a number of years (and i doubt whether it is actually still supported by the mainline kernels), and i used OSS-audio only seldomly in very specific setups. from this i follow, that the majority of people have to fight their way through a lot of dead options that are more confusing than helpful, and which should probably be removed in most cases. suggestion: so what i ended up doing, was separate the audio-backends from the pd-core code a bit more, in a similar way to how Pd's object registration works. the means that people could write new audio-backends and load them on-demand, just like externals. it also means that Pd's non-audiosystem codebase has only a minimum of #ifdef USEAPI_ALSA (there's only one, when it comes to loading the internal audio-system at startup). all this also applies to MIDI. if there's interest, i could cleanup the patches (and make them work again with 0.43.3) and submit them for review. if there's confusion, i could try to try again and explain what i want. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/z9ewACgkQkX2Xpv6ydvRvMwCgv2NPmX2Hx9wZSubBHA3mKpRd IrkAoJbWuNJF1Gu2X7Vg1T+f1NHUdBbi =fPn6 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] open_via_path / close file - WIndows CRT problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-03 15:19, Thomas Grill wrote: Hi all, when trying to trace a bug in one of my externals i came across what could be an issue in the PD API. The header m_pd.h exposes the function open_via_path which can be used in externals to search file in the PD search path. On success it opens the file and returns a file handle, which can in turn be used by the external code. This doesn't seem to be a problem on Unix-based systems. On Windows, under certain circumstances [1], PD and the external use separate copies of the CRT, meaning that passing the file handle and using POSIX-style file functions between dynamically linked binaries is not really possible. The file handle would not be valid in the external. This happens when at least one party is linked with the threaded static CRT, which is the default with PD and most externals. Now, i'm wondering how this problem can have been hidden for so long. Are there no externals using open_via_path and running under Windows? This must be a problem for all script loader externals relying on the PD path, like my py/pyext external. Am i doing something wrong, or is there a known solution/workaround etc.? Pd-0.43 introduced sys_close() in order to have the same CRT implementation open and close the file. prior version of Pd lack this function and therefore there a number of file-handle leakage bugs were reported. fgadsrm IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/y9jwACgkQkX2Xpv6ydvQlCQCfVC3tPyHV7WejqPLquyBKM+4K bFoAn2tFSBlkjSwvm0EoPdKAuw4tftlB =Vcs6 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] open_via_path / close file - WIndows CRT problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-03 15:40, IOhannes m zmoelnig wrote: Pd-0.43 introduced sys_close() in order to have the same CRT implementation open and close the file. prior version of Pd lack this function and therefore there a number of file-handle leakage bugs were reported. sp the workaround is actually to use open_via_path() to get the full patch of the file you want to open, sys_close() the filehandle and then use the full-path to open the file yourself. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/y+EkACgkQkX2Xpv6ydvTkCwCfRvO9WVlNjg2/AZ0unQgs6qYs xLkAnAwTrGl7B/uqClNFrJP0o1VDzEpc =oSId -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] building pd-extended for debian squeeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-06-13 01:41, Tedb0t wrote: Hi all, I just completed building pd-extended on an ARM system. I had to fix a bunch of dependencies, but I eventually got it all the way through. (It ended with linux_make install succeeded!) After that I did make package which worked too. However, it didn't seem to actually install pd-extended into the expected default directories (/usr/local). After I installed from the package it had created, everything worked normally, but I just wanted to see if make install was supposed to actually install or not. i'm not sure whether i understood what you are actually asking (or if you are asking anything at all) nevertheless, two notes: - - usually a debian package should _not_ install into /usr/local, but directly into /usr. /usr/local is for those that don't use debian packages - - if you are interested into what a package installs, you could do... to get a list of files installed by an already installed package: $ dpkg -L packagename to get the contents of a package prior to instaling it $ dpkg -c archivename.deb you could also simply extract the package to a place of your choise with $ dpkg -x archivename.deb /tmp/foo/ fgamsdr ioHANNES -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/YQkcACgkQkX2Xpv6ydvT2ZgCg2u5F9JlnwngUD+z8ZbV8ym9u vN4An2aXyB2EHgTrRHiph+m0iQJLpvOj =0v2F -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] building pd-extended for debian squeeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 please always reply on-list! On 2012-06-13 18:27, Tedb0t wrote: Sorry?this is my question: After make install, should pd-extended exist in /usr/bin or usr/local/bin? Mine did not. what? /usr/bin? /usr/local/bin? both? none? looking at the linux_make/Makefile, the install target has a default DESTDIR=./build depending on whether you build for .deb or not you should therefore end up with files in ./build/usr/ or ./build/usr/local/ fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/YwfgACgkQkX2Xpv6ydvTpEgCgk66XGePKUH0QnSt/PgYufIXF YQUAn1nZfqK0lP1XljWatOEWwADce9kL =4U1R -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Feature Requests-3531000 ] Proposal for an alternative file format
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-06-03 22:30, s p wrote: That's a very good point, ... it's a good idea to specify GUI infos, for better interoperability, but it should be explicitly said that this is optional information gui information (e.g. spatial layout) is not always optional, sometimes it is mandatory (as in: the patch's behaviour depends on the layout) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/MWwwACgkQkX2Xpv6ydvTy1gCg2juSEq0oF38t3TDzxR09j9OR NN8An1psFQlz0VzhBcUTjdGPsc2sXD1x =ek/u -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] macosx104-powerpc is online
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-04-05 20:10, Hans-Christoph Steiner wrote: Thanks to Greg Pond, we now have a macosx104-powerpc box online and running builds via jenkins and the Pd-extended auto-build script. The whole Fink setup is still building, so that's not in place yet. But now this leads to the question: do we want to maintain things on Mac OS X 10.4? I think we can build easier on 10.5, and it'll still run on 10.4 or maybe even older. We could have this build server running Mac OS X 10.5 instead of 10.4. do we have a 10.5 powerpc machine? personally, i'm more interested in powerpc than 10.4 fgmasr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk994f8ACgkQkX2Xpv6ydvQO2QCfRfvRG+w+XCcOYeO1XiC4fVKH 3nAAn27osRMm/LzWfJA/6Ft9rDZrLA9S =AMB3 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] problem with routing mail to pd-dev ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-03-06 17:46, Mathieu Bouchard wrote: I just wrote a comment in « [grid] not working in pd-extended 0.43.1 » and it didn't go through to the pd-dev list. I'm wondering what the selection process is, for routing those comments to pd-dev. I wrote it while logged in to sourceforge (using my new account, not the one I used years ago). My other comment with the same account went through, today, some minutes before. https://sourceforge.net/tracker/?func=detailatid=478070aid=3497473group_id=55736 i'm not sure i fully understand your problem. since some time, hans has disabled the automatic email notifications of follow-ups in the Bugs tracker. i checked and it seems that in the Patch tracker, still has the notifications for follow-ups enabled. could that be the cause of your troubles? fgmasdr IOhannes PS: on the pd-dev side no special routing is done (apart from allowing all mails coming from sourceforge) PPS: i'm pretty sure that the not/appearance of your mail has anything todo with your new account -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9WQjIACgkQkX2Xpv6ydvRpfQCeMrzcfKx854IUb/RoNiRGrnMk jWwAn3tI/RoWoBQwSSRHXn6ZRjtV6hDI =FKte -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pbo transfert WAS: GEM passing output image later.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-02-29 10:52, Cyrille Henry wrote: Le 29/02/2012 09:34, IOhannes m zmoelnig a écrit : and both [pix_texture] and [pix_snap] allow for asynchronous DMA-transfers already (though i only added PBO-tarnsfers to [pix_snap] a week ago or so). it's not really documented anywhere (yet), but you can send a [pbo $1( message to both these objects to specify the number of PBOs to use (with 0 being the default behaviour) Do you mean that since last week pix_snap should be lot's faster than it use to be? the default behaviour is still the same (pbo==0) this is mainly because i found that the optimal setting varies greatly from machine to machine. e.g. on my netbook with fglrx drivers, the old non-pbo method is somehow faster... on my desktop (with some old nvidia card), using PBOs is faster. i'd like to understand a bit more the use of single / multiple PBO : what happens if 2 pix_video / pix_texture use the same PBO : will it be slower than using 2 different PBO? (since 2nd pix_texture have to wait for the PBO to be free in order to use it)??? each [pix_texture] will use their own set of PBOs. when using more PBOs, you basically get a ring-buffer: while the current image is uploaded using PBO(n), PBO(n-1) is displayed, so the upload has one frametick to complete. it also means, you get a delay when using 1 PBOs. i haven't done any benchmarking with multiple image-sources (though the PBO support for [pix_texture] was implemented in order to get reasonable speed when displaying multiple hires videos for an installation) same question with a pix_video / pix_texture and a pix_snap : is using 2 PBO lot's faster than using the same PBO (default behaviour)? just try it :-) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9OCY8ACgkQkX2Xpv6ydvRf7gCfWiihXE5UH+15Nvpo4HA09tKo Q5wAnRXfUhdc6IrhWkHOsKzo3KrF9uh7 =wCyQ -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Patches-3494768 ] verbose() leaves blank lines when filtered out in Pd window
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-02-28 16:03, Hans-Christoph Steiner wrote: Yes, I object. Like I said in the bug tracker and this thread, I think the offset should either remain the same or be the same as the rest. may i ask why? what makes 4 better than 3? fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9M7VoACgkQkX2Xpv6ydvTRdwCgsxoUMeCeLH8NTcHacKFgx3mS iwcAnjnGX4VfaQYiJBOSFvv4ScTi5VPc =am3c -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Patches-3494768 ] verbose() leaves blank lines when filtered out in Pd window
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 i move that to the list, as it makes discussion easier. On 2012-02-27 15:32, SourceForge.net wrote: Comment By: Hans-Christoph Steiner (eighthave) idea to change to loglevel+4 to loglevel+3. Either leave verbose()'s custom level numbering the same, or make it the same as the Pd window, error(), logpost(), etc.. I still really think the +4 on the loglevel doesn't make sense. i totally agree that +4 doesn't make sense at all. i wonder though what you mean by leave verbose()'s custom level numbering the same. the same as what? from the start of verbose() (which was long before the custom loglevels of logpost()) the idea was as follows: verbose() should be used for messages that are more verbose (==less important) than post(). you can increase verbosity by passing one or more -verbose arguments to the cmdline. when raising verbosity, you will suddenly see messages that you did not see with a lower verbosity. verbose(0) is meant to be a default (low) verbosity, that is still less important than post() keep in mind that this was all before the loglevel stuff; from that pov it would make no sense at all to have verbose(1) to be more important than post() and verbose(3) to be less important than post(). instead, all ordinary (that is: 0) verbose-levels are always considered less important than the show always post. this should still hold true! furthermore, verbose(0) was meant to have a similar verbosity than post() (but - again - never a higher priority). somebody (while i remember you saying that the arbitrary number '4' was introduced by me after much fighting with you and miller, i still cannot remember that; what i can remember is that i wanted verbose() to use the loglevel implementation) introduced a random offset of 4, which makes verbose(0) to only output things if you switch the loglevel to all, rather than debug, which is precisely the loglevel for which verbose() was meant. the only reason i see to keep verbose() at +4 is to discourage it's use. (which might be what you want, if you think that loglevel() is more easily understandable) leaving our differences aside, what i think could be an interesting change in semantics here, is to output all verbose() messages at loglevel:=3 (debug) though still apply the filtering based on verbosity. e.g. both verbose(0, foo) and verbose(1, bar) will show at debug level, but the latter will only show up if the user manually raised the verbosity with the -verbose flag to at least 1. and yes, it makes sense to differentiate between a gui-loglevel and a system-verbosity, if you generate loads and loads of messages for debugging which you normally would like to never see on the wire between pd pd-gui. g fasdmr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9LnfoACgkQkX2Xpv6ydvQp6ACgyXpUe5tlt02EWXEXn+KKljf/ DoQAoPNxLBHmQTFCd5Y7+xBHexfeS7sH =jTRm -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] Pd-installation on jenkins/debian-stable-amd64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 it seems like on the debian-stable-amd64 host of the build-farm, the Pd-headers have been uninstalled. at least, Gem build#71 (2011-12-22 10:00:51) succeeded, whereas the next build#527 (2012-02-19 22:01:47) failed, because out of a sudden it cannot find the Pd-headers any more. logging into the machine revealed, that the pd-extended package is installed, which provides headers in /usr/include/pdextended but: - - no compatibility header m_pd.h in /usr/include/ (like the puredata-dev package in debian does) - - `pkg-config --cflags pdextended` returns -I/usr/local/include/pd, which does not exist at all. - - `pkg-config --cflags pd` fails as well as `pkg-config --cflags puredata` would it be possible to have Pd-headers installed in a default location on _all_ auto-build machines? ideally, this would be somehow compatible with the header location on ordinary machines. would it also be possible to not have to assume builds against Pd-extended? fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9Dh/wACgkQkX2Xpv6ydvTQUACg3JGHJkUG7k5Bl2y+k/X92uJC z5IAniPXffHjoo/OjLtWvMCeHgkptAc/ =SbfI -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd-installation on jenkins/debian-stable-amd64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-02-21 13:03, IOhannes m zmoelnig wrote: - `pkg-config --cflags pdextended` returns -I/usr/local/include/pd, which does not exist at all. - `pkg-config --cflags pd` fails as well as `pkg-config --cflags puredata` which also leads to the questions: - - should both puredata-dev and pd-extended provide a puredata.pc? (like they do now for the pd executable); i don't know whether this is considered very bad style or not, but on my system, i have no .pc file that is handled by update-alternatives - - should /usr/include/m_pd.h be handled likewise, using update-alternatives? again, i'm not sure whether this is good style and cannot find such a thing on my system gasdmr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9DiSoACgkQkX2Xpv6ydvRqRgCfS/ZRwh/L2MW3W0sfUcm8JAwk /nkAoNCzCuOy/6xSi+8p0iPUkNwSePZ8 =SGtN -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd-installation on jenkins/debian-stable-amd64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-02-21 17:15, Hans-Christoph Steiner wrote: - - should /usr/include/m_pd.h be handled likewise, using update-alternatives? again, i'm not sure whether this is good style and cannot find such a thing on my system Pd-extended's headers are in /usr/include/pdextended only. If anything depends on them, that should be explicit, i.e. #include pdextended/s_stuff.h. This also allows for a parallel installation of the puredata headers, so no need to mix the two up. hmm, but this will prevent the external to be buildable without having a full installation of pdextended (e.g. both the external-code and pd-extended are only available as a vcs-checkout) is this by design? while auto-building pd-extended, do you add an include-path that allows pdextended/m_pd.h to be included? it also means, that you cannot make an external that builds for both pd-vanilla and pd-extended without some #ifdef trickery and user interaction (or some build-system (like autoconf) that detects whether pd and/or pd-extended is present). finally, the pdextended.pc pkg-config snippet is nevertheless broken. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9DxZoACgkQkX2Xpv6ydvQ/1QCeN4Q9OFXTezbVvZmhfIzoawwW c4kAoMEplGqK/8nt1tsltN3DCV7AUIyC =R6Jv -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd-installation on jenkins/debian-stable-amd64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-02-21 17:20, Hans-Christoph Steiner wrote: I reinstalled 'puredata' on debian-stable-amd64, sorry about that, I don't know what happened there. The build systems are mean to have the Pd-vanilla headers installed. thanks. I'm happy to install packages and put apps into /Applications. But in order to keep the systems clean for building, I will not put anything include /usr/local. if you refer to my complaint about -I/usr/local/include/pd, then i need to clarify: the pd-extended installation installs a pkg-config snippet pdextended.pc which claims that - in order to compile e.g. an external - - you should add -I/usr/local/include/pd to the compiler flags. either you should fix pdextended.pc to contain (e.g.) -I/usr/include, or remove it alltogether. If you don't want to build against Pd-extended, then don't point to those headers. The Makefile template points to Pd-extended on Mac OS X and Windows because Pd-vanilla does not provide headers in the standard packages. really? i remember that Pd-vanilla includes the full sources (including all headers) on both w32 and osx. fmgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9Dx2AACgkQkX2Xpv6ydvTfFgCgmUnOBj7mh5iV3PJWUGi8CROs 3goAoK3AQneSz5e+gj9inwIalUZg5/W3 =hSi0 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Pd-installation on jenkins/debian-stable-amd64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-02-21 17:40, Hans-Christoph Steiner wrote: Pd-vanilla does provide the sources, but there are two issues: - it does not include the include/pd/ subdir for headers i don't think this is an issue. externals have traditionally included m_pd.h rather than pd/m_pd.h. the suggested way is therefore, to add -I/path/to/pd/headers (e.g. -I/usr/include/pd) to your CFLAGS and continue to use m_pd.h - on Mac OS X, the app has the version number in it, so using those for headers would make the Makefile dependent on a particular version of the Pd.app. true. i usually end up symlinking Pd-foo.bar.app to Pd.app... fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9DyqQACgkQkX2Xpv6ydvSkugCfSqukJlrVjAGuSmSt5yXB6BKU h7oAmwZEwzZCAldEE3T+nLkGek3cpr5q =bKtW -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-02-08 00:36, Mathieu Bouchard wrote: I mean that this context could be accessed directly if there's no reason to use accessors. But if locking has to be done before and after accessing (some of) those members, then it's nice to have a shortcut. another reason is, that with accessor-functions you can more easily stay binary compatible both backward and forward than with directly accessing the struct. sure you can do something like that with structs as well (typecast to different structs depending on the version of the Pd-host), but with accessors it comes for free (well, at least backwards compatibility) this will obviously break API compatibility... a possible workaround would be to add a new function t_pdcontext*make_current(t_pdcontext*) that would change the running how many of these variables are there ? That could be a lot of variables to be swapped around. right, peter already convinced me, that having a single legacy context that is used directly is more appropriate. e.g. c++11 (c++? ever tried to compile Pd with a c++ compiler?) I did. I don't recall significant difficulties... it might have been i guess i was exaggerating the use of C++ reserved keywords as variable names and the like. sure, this is easy to fix. but the original suggestion sounded to me like: 'a solution for all our problems is to switch to new C++ features in a CC=g++ -fdo-what-i-want manner', and i wanted to object to that. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8yLWIACgkQkX2Xpv6ydvQ0WQCfZhPu9t9QQkH9JpNxBBAXTIj/ WZgAn0B+LDuech7oIf4DUw8Ktt1R7Gif =n9ct -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] float handling in [binfile] for UTF-8 handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-01-31 00:52, Hans-Christoph Steiner wrote: That does make more sense, so something like [bytes2utf8], etc. utf8 is always a list of bytes. if you get values 255 than it is not utf-8; do you mean unicode points? fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8nqSsACgkQkX2Xpv6ydvTX9wCgkLEiBOSk4HVLcc2+ZRX45xL3 WToAoNWMdCm9ycykaDOruwCflvE+uaFz =xMfz -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] float handling in [binfile] for UTF-8 handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-01-31 15:41, Martin Peach wrote: On 2012-01-31 03:41, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-01-31 00:52, Hans-Christoph Steiner wrote: That does make more sense, so something like [bytes2utf8], etc. utf8 is always a list of bytes. if you get values255 than it is not utf-8; do you mean unicode points? The same idea could be used for unicode, converting pairs of bytes into single numbers, taking care of endianness. yes, something like [1] which does it the other way round (and doesn't care about endianness) and btw, isn't utf-8 agnostic of byte-endianness? at least [2] suggests this. mfgasdr IOhannes [1] https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/iem/unicode/utf82codenumber.pd [2] http://en.wikipedia.org/wiki/Byte_order_mark#UTF-8 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8oBjgACgkQkX2Xpv6ydvR0yQCgt9xhKaqpGqaiH830SDuW6YIH b+kAn3dDS5UjYBINE2OZkIhhSlHE65d8 =EkZE -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [ pure-data-Bugs-3481366 ] Ubuntu 11.11 + Gem = big problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-01-29 22:15, SourceForge.net wrote: I use Ubuntu 64 bit on a pc with intel i7. Until yesterday Ubuntu 10.10 + Puredata + Gem worked well. Today i upgrade Ubuntu to 11.4 and 11.11. When i open Puredata, it say: usr/lib/pd/extra/Gem/Gem.pd_linux: /usr/lib/pd/extra/Gem/Gem.pd_linux: undefined symbol: _ZN6Magick5ImageC1EmmRKSsN10MagickCore11StorageTypeEPKv I think this is a bug of Ubuntu 11.11 because Puredata 0.43.0-4 and gem 0.92.3-2 has worked until yesterday. is that the ordinary ubuntu packages for puredata and gem? you might want to upgrade those packages as wellpackages. e.g. precise has an updated gem package (0.92.3-2build1) rebuilt for libmagickcore4, which will most likely fix your problem. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8mVjEACgkQkX2Xpv6ydvQodACePawIeeDIXUR50ok10Ut+v66k PFwAnR60z5ltVUaRdpUufw1/efq23RKg =WV0y -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] libjpeg-turbo - anyone tried it?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-01-19 04:28, Hans-Christoph Steiner wrote: Has anyone tried this? It seems like it would be very valuable for Pd applications, since Motion JPEG is the standard codec: http://libjpeg-turbo.virtualgl.org/ libjpeg-turbo is a derivative of libjpeg that uses SIMD instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and decompression on x86, x86-64, and ARM systems. On such systems, libjpeg-turbo is generally 2-4x as fast as the unmodified version of libjpeg, all else being equal. i switched to libjpeg-turbo on one of my windows build machines for Gem a week or so ago :-) i haven't done any benchmarking, but it opens jpegs just fine :-) the reason i switched is that it was easier to use with mingw than the outdated libjpeg found in GemLibs... fgamsr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8X2O0ACgkQkX2Xpv6ydvR4eACgpRUPriYoME/of3436ZRhYpnm KswAoNwvxPva5OQy9jc0mXpXztnOq/Fa =eqqO -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-01-19 07:09, Peter Brinkmann wrote: On 2012-01-14 22:04, Miller Puckette wrote: To do this I'd replace all globals like what is wrong with eliminating all directly accessible globals from the API (like pd_objectmaker) and provide accessor functions to get (thread safe) access to them? e.g. i would prefer if the symhash stayed global and instead access to it (via gensym()) was thread safe. I'd rather not have any shared global state at all because that would significantly reduce the possible performance gains from concurrency (Amdahl's Law). it seems like i was myself mixing instances and threading. indeed what i would prefer was, if i could use gensym() from another thread in a safe way. this has nothing to do with a global hashtable (and i don't see a reason why multiple instances should share a global hashtable) right now, only #1 is possible at all and it takes some effort on the thread host (the external) to not fuck Pd's heap. i think Pd should be more helpful in this respect: a way to make Pd thread-safe is to eliminate global variables and if they can't (or shan't) be eliminate them properly protect them against parallel access. As far as libpd is concerned, I would prefer not to have any synchronization inside Pd itself --- libpd can be used in a wide variety of settings, with lots of different approaches to concurrency, and so it's impossible to make any assumptions about threading at this level. what are the actual drawbacks if e.g. clock_delay() could be used from any thread (in an external)? which assumptions are made that might not hold true in all your use cases? my main reasoning is, that thread synchronisation is a re-curring problem that imho should not be re-implemented whenever it is needed. also a earlier attempts to fix this, using the great BIG kernel lock (aka sys_lock()), proved (at least for me) to be inadequate, as they slow down the entire processing significantly. however, maybe i'm asking too much and what i really want is to have a standardized possibility to send messages to a Pd-instances without having to worry about threading (i use all the clock-stuff i keep mentioning mainly for doing exactly this: implementing a thread-safe message queue to send data from a worker thread back to Pd) Of course, as you point out, Pd itself requires some synchronization in its interaction with externals, so there's a bit of a conflict there. My favorite solution would be to refactor Pd so that it has an audio library much like libpd at its core. Then Pd would be able to do all the synchronization it needs without affecting other applications that use the same library. i have to admit i'm a bit unsure where you would draw the separation. Pd uses common infrastructures for a lot of things on different system levels: e.g. the message system is used to communicate between objects, to let the gui talk to the pd-core, to open a patch (instantiate it's objects),... while i think this is one of the strengths of Pd, i also think that this is probably the biggest problem when attempting a refactor as you describe it (but again: i might totally miss the point here) The solution I have in mind would add an extended API that has a context parameter everywhere. In order to maintain compatibility with current code, there would be a global legacy context, and the functions in the current API would simply invoke their new counterparts with this global context. yes that's what i wanted to say (and please forget about the make_global() idea; having a single global legacy context is of course much easier fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8X3jgACgkQkX2Xpv6ydvTbmwCfZgKiMlP9xG3t9hRagZu2oPkt XyIAoMF3uwuevcUsunjj0Q5BPfywnxqj =UInL -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] per-thread storage in Pd in support of pdlib - discussion?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 i think there are 2 use cases for multi threading. #1 access a single instance of (lib)pd from multiple threads #2 allow multiple instances of (lib)pd to co-exist in global memory. right now, only #1 is possible at all and it takes some effort on the thread host (the external) to not fuck Pd's heap. i think Pd should be more helpful in this respect: a way to make Pd thread-safe is to eliminate global variables and if they can't (or shan't) be eliminate them properly protect them against parallel access. On 2012-01-14 22:04, Miller Puckette wrote: To do this I'd replace all globals like what is wrong with eliminating all directly accessible globals from the API (like pd_objectmaker) and provide accessor functions to get (thread safe) access to them? e.g. i would prefer if the symhash stayed global and instead access to it (via gensym()) was thread safe. i guess the main reason for not doing this is performance(?) otoh, the subject indicates that you are more talking about case #2. in this case what is needed is to replace the global state by a per-instance state. i would rather _not_ tie the concept of instance to the concept of thread (even though in practice they might often be interchangeable). afaik, the usual way to accomplish a concept of multiple instances is to aggragate all currently global variables into a context and extend the API so that each function has an additional parameter for this context. this will obviously break API compatibility... a possible workaround would be to add a new function t_pdcontext*make_current(t_pdcontext*) that would change the running instance and all API calls would henceforth work on the current context. this would still need a global variable (the current context). the make_current call could update the legacy global variables to contain the current values. (this would only work as long as no code caches the values of these variables). of course this doesn't really solve the problem of concurrent access to multiple instances of (lib)pd. in this case an extended API that has an explicit reference to the currently used API should help. anyhow, i would strongly suggest not to use some compiler magic that might or might not be supported for older (and newer) compilers available on the market for (lib)pd itself. e.g. c++11 (c++? ever tried to compile Pd with a c++ compiler?) is supported only by fairly new compilers (and afaik, that support is only partially, even on g++) fgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8T40AACgkQkX2Xpv6ydvRY2QCgjiMPHvSK5OgL5o6TlWk+JVkc b9gAnjM0qd81axcEpk4aSYH5nRqe2w1A =O7F+ -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] small l2ork install suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-01-16 01:15, Hans-Christoph Steiner wrote: include/Base/ These are the Gem headers, they should be in the 'gem' package, but I DoH! i wa absolutely convinced that i got that right for the 0.93.3 package. i even closed the relevant debian bug (#582555) only do discover, that i forgot to actually add the headers... i'll fix that asap... fgmasdf IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8T5V8ACgkQkX2Xpv6ydvQ6lQCg3LPk4cmCncn/8vn+FQ7VC6V2 vP0An1G/qY3xyxzOrDcUOafQtjLVndki =vHqL -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] small l2ork install suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-01-16 09:52, IOhannes m zmoelnig wrote: On 2012-01-16 01:15, Hans-Christoph Steiner wrote: include/Base/ These are the Gem headers, they should be in the 'gem' package, but I DoH! i wa absolutely convinced that i got that right for the 0.93.3 package. i even closed the relevant debian bug (#582555) only do discover, that i forgot to actually add the headers... i'll fix that asap... and as you can see, i'm so excited about this that i even switched off my basic spell checker... fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8T5g0ACgkQkX2Xpv6ydvSMLwCfdNsLcjUTfk4Y/vV+R1WCupJ6 NBwAoPLyywCZLSJ+iDEaBD2BiNTiNYwl =yb4P -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] help compiling pd 0.43 on Windows 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-29 18:29, katja wrote: On Tue, Nov 29, 2011 at 5:37 PM, Hans-Christoph Steiner h...@at.or.at wrote: The new build system doesn't need the makefile.dependencies, and that has always been a bit of a mystery. Ah, so I'm not the only one being puzzled, happy you say so. I'm intensely frustrated after spending five days to get things working with mingw. Todays it's like this: when compiling pd-double with makefile.mingw, makefile.dependencies does actually get produced, but then comes 'no rule to make am--refresh. Stop.' when entering extra/. you shall decide to either use makefile.mingw or the new autotools system. you shall never mix the two. especially, you shall not run ./autogen.sh and then try to compile using makefile.mingw thus: remove all traces from the autotools build system (namely any generated files, like GNUmakefile) mfgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7VHjsACgkQkX2Xpv6ydvR3yQCeMooyROl+yVUbKmP/S62FwRRk P/IAn0CRa9hGvTR5khg391uWxs0EKPk9 =vQM4 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] buildbot/jenkins: q about hosts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-08 18:13, Hans-Christoph Steiner wrote: jenk...@macosx105-i386.puredata.info it seems jenkins is still sending with this identity. could you change that to jenk...@macosx105-i386.pdlab.puredata.info I like the name standard that we used for the hfbk.net machines, i.e. personally, i would associate pdlab with a workshop rather than a build farmbut then, i don't care so much and used that domain... debian-testing-amd64.pdlab.puredata.info -- debian-testing-amd64.pdlab.hfbk.net debian-stable-amd64.pdlab.puredata.info -- debian-stable-amd64.pdlab.hfbk.net macosx105-i386.pdlab.puredata.info -- 160.79.59.149 debian-stable-amd64.pdlab.puredata.info -- 128.238.56.50 i thought debian-stable-amd64.pdlab.puredata.info is debian-stable-amd64.pdlab.hfbk.net (which is 193.174.241.140) ubuntu-lts-amd64.pdlab.puredata.info -- 128.238.56.55 according to the wiki, ubuntu-lts-amd64 is muranyia.dyndns.org; according to the wiki, 128.238.56.55 should be ubuntu-lts-i386 ubuntu-current-amd64.pdlab.puredata.info -- 128.238.56.53 according to the wiki, 128.238.56.53 is ubuntu-current-i386 if i log into these machines, they claim to be i386 (both in hostname and $(uname -m)) windowsxp-i386.pdlab.puredata.info -- 128.238.56.60 done. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7KG6cACgkQkX2Xpv6ydvTzTACfTiSt57VCSq6/QhSBll0Oo8DF 9xMAn0rpZ/T14dZQp26spCBnYEn+BtgH =CAe1 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] webcam color balance from gem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 02:07, Ricardo Fabbri wrote: Hi, would there be a straightforward way to adjust the hardware color balance of a webcam through GEM? Do you have experience in getting/setting those attributes with the PS3 eye webcam which has been used in a lot of Pd projects? perhaps installing a new driver with more controls? I am under Ubuntu 11.10 64bit with a 3.0.0-12 kernel. I am also trying to develop/improve v4l2 handling in gem and pdp, but I'd like to get some of the community input and wisdom first. you can adjust each and every ctl available via the v4l2 driver from within Gem. see the [pd properties] subpatch in the help for pix_video. the ps3eye gives me 10 controls with stock drivers (none of them dealing with color correction, if they are labelled correctly). i haven't tried the patch at [1] for a long time, but i remember having good results back then (i mainly needed it the patch for being able to adjust the imagesize/framerate, but it seems that it also allows some color correction) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7EwKQACgkQkX2Xpv6ydvRu1wCgsU5vX2ya7ilhDW6CoJjWUbJ6 3ncAn1/DWFmjCugudBy61kYteqG1L9Jt =N3Gw -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] webcam color balance from gem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 09:25, Ricardo Fabbri wrote: thanks. ps: you referred to [1] but I see no link. doh, [1] http://bear24rw.blogspot.com/2009/11/ps3-eye-driver-patch.html fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7ExuUACgkQkX2Xpv6ydvSmQwCfTMe+S9U3iBfokyYrQ/8jGkzX d1QAoMNeutHmuPTszj/TRc3juNFBb5wM =nE4/ -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] a true Pd-double autobuild finally available for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-17 18:44, Hans-Christoph Steiner wrote: Woo hoo! 32-bit ints in Pd! Well done, thanks for your hard work on this :). 32bit ints? more like 52bit ints. fgmadr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7FS2IACgkQkX2Xpv6ydvQY/ACgg8QzBBhfxYVOu9/lUrdgYryG jx0AoIx+/UzKa46xhJca1b21D3W60ojw =IELt -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] getting double fixes into extra/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-10 16:26, Hans-Christoph Steiner wrote: Even better would be to fix the new build system. One of the reasons I removed extra/ from Pd-extended and made it a separate library is because of the brokenness of the build system. IOhannes, since you wrote the current build system in extra/, could you tackle this? It doesn't work on Mac OS X, it creates .la and .lo files, but not .pd_darwin. I also seem to remember no MinGW support. on OSX, it creates .d_fat files. at least that is what i get on jenkins [1] there's also a mingw branch on my github clone of pd-vanilla [1], that fixes a number of build issues on mingw, e.g. linking with g++ when building asio. (though, iirc, it still doesn't produce dlls for the externals) fgmasdr IOhannes [1] https://160.79.59.149:8443/job/pure-data/all=macosx106/ws/pure-data/usr/local/lib/pd/extra/bonk%7E/ [2] https://github.com/umlaeute/pd-vanilla/tree/mingw -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk679kIACgkQkX2Xpv6ydvSCHACgqJFcLcNHAVbBZoF9R55nKBPK YFQAoMepV8dfHzpJqf5zTLNhbJwajRXX =ZhZ8 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] getting double fixes into extra/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-10 17:57, Hans-Christoph Steiner wrote: That is 'make install' doing that, not 'make'. 'make install' is only supposed to install the files, not generate them. indeed. make generated the .d_fat files, and make install copied them to location i pointed you too, so you can see that the files have been generated. And it should really use .pd_darwin. There is no reason to have multiple file endings in Mac OS X, the universal file format handles that. indeed there is no reason, hence i use .d_fat which i think has been the default for Pd for years. fgamndr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk68BvwACgkQkX2Xpv6ydvSYdACg45ok85t3qxUA94JrZL6A9+23 etYAoMHcxrvrVgqwDv2aihakB88StPze =V72g -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] getting double fixes into extra/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-10 18:21, Hans-Christoph Steiner wrote: On Nov 10, 2011, at 12:16 PM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-10 17:57, Hans-Christoph Steiner wrote: That is 'make install' doing that, not 'make'. 'make install' is only supposed to install the files, not generate them. indeed. make generated the .d_fat files, and make install copied them to location i pointed you too, so you can see that the files have been generated. There are no .d_fat files here: https://160.79.59.149:8443/job/pure-data/all=macosx105/ws/extra/ or here: https://160.79.59.149:8443/job/pure-data/all=macosx105/ws/extra/bonk~/ https://160.79.59.149:8443/job/pure-data/all=macosx105/ws/extra/bonk~/.libs/ Only pd~.d_fat gets generated by 'make'. Shall I file a bug report? And it should really use .pd_darwin. There is no reason to have multiple file endings in Mac OS X, the universal file format handles that. indeed there is no reason, hence i use .d_fat which i think has been the default for Pd for years. Currently the only thing that is released as .d_fat is the Pd vanilla extra files. Everything else uses .pd_darwin, even Gem ;) the build system was done for Pd-vanilla, therefore the extension used by Pd vanilla was chosen. i usually try to avoid smuggling ideological things into the code base by means of a side-effect of another patch. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk68CjMACgkQkX2Xpv6ydvTVVQCfQPIyEsiDM5OcMfWv+kTN6QwL Qg4AoJIIP3+cCUcf44rhdXV1bC+stRAf =Z0kU -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] buildbot/jenkins: q about hosts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ola! since i don't know any better place to ask, i'll ask here... debian-testing-amd64.pdlab.hfbk.net - --- for whatever reasons, this machine has /tmp (where jenkins creates the workspaces) mounted as tmpfs (that is, as mmapped disk). due to memory limitations, this means, that /tmp is 200MB large. this is a bit small for a build-server that usually does not delete workspaces. it's definitely too small for building Gem, where the extracted source alone takes abot 53MB i'd suggest to configure it the same as debian-stable-amd64.pdlab.hfbk.net, where /tmp is part of the /-partition. chaos.medien.uni-weimar.de - -- i seem to have great troubles to get the OSX10.6 (chaos.medien.uni-weimar.de) machine build a build without fink. mainly because autoreconf seems to find the fink-installed libtool when creating the build-scritps, but then wants to use the non-fink version. my approach was to remove the /sw/bin and /sw/sbin from the PATH, which works fine on the console of the given machine. if somebody could shed i light on how the fink installation differs on the macosx106 machine from the one on the macosx105 machine, i'd be grateful. the build log can be found at [1] jenk...@macosx105-i386.puredata.info - while i am all for using domain names within puredata.info, it would be great if the hostname could be more specific, ideally referencing to autobuild, buildbot or jenkins i'd suggest names like macosx105-i386.buildbot.puredata.info i'll happily add those names to the puredata.info DNS server, if i get the IPs. fgmasdr IOhannes [1] https://160.79.59.149:8443/job/Gem/all=macosx106/7/console -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk65BSEACgkQkX2Xpv6ydvQo0ACfQwVGcJIFLrW79kvpcetD7IZ0 uokAoKqVy1R4EcRD4jRCiBEzQu9xkU83 =Pjs7 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] buildbot/jenkins: q about hosts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-08 11:32, IOhannes m zmoelnig wrote: chaos.medien.uni-weimar.de -- i seem to have great troubles to get the OSX10.6 (chaos.medien.uni-weimar.de) machine build a build without fink. mainly because autoreconf seems to find the fink-installed libtool when creating the build-scritps, but then wants to use the non-fink version. my approach was to remove the /sw/bin and /sw/sbin from the PATH, which works fine on the console of the given machine. if somebody could shed i light on how the fink installation differs on the macosx106 machine from the one on the macosx105 machine, i'd be grateful. the build log can be found at [1] it seems like i was able to resolve this issue, by deleting all workspaces associated in any way to the build, thus forcing ltversion.m4 to be properly recreated. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk65B2EACgkQkX2Xpv6ydvQSYQCg4vMqK673ju71l5Jpr2YPArlk v1UAoKb+spr8KGQDt4HawHrtfmjZhTw+ =OlRK -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] help with PdLab:w32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-02 22:07, Hans-Christoph Steiner wrote: Ah, ok, I think I fixed that. I forgot that the msys home tree is separate from the rest. seems to work ok, thanks for the fix. fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6yZgkACgkQkX2Xpv6ydvSZwACcCdvuSkaTOTpWCaYL3tbApUdl rlAAoOunJmROi3YSaDcE/4jFyfHHRtnZ =Pug4 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] gem, pdp, gridflow, pidip
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-02 03:57, Hans-Christoph Steiner wrote: Wow, that effects.zip patch is simple yet quite nice. I had some fun with that. One possibility for using combinations of Gem, PDP, and Gridflow together is to use Syphon. It unfortunately only Mac OS X because only that OS currently let's you easily access the graphics card like that. But basically it lets you share data between apps while keeping it on the GPU, so its very fast. Its all open source, there is a syphonserver for Gem. So Gem would need a syphon client, then PDP and Gridflow would need a syphon client and server. how are pdp and GridFlow to profit from the tremendous speedup due to all staying on the GPU memory? iirc, both GF (apart from gf.gl) and pdp (apart from 3dp) are geared towards CPU processin. So if you want to to create a syphon link between GF and pdp, you would first need to transfer the data from GF to the gfx card's memory and then transfer it again to the main memory for pdp to use it. this is potentially a lot slower than sharing the data within main memory. mind, that i really think that syphon is a cool project, but it is not a magic performance booster for connecting any data source with any other data sink. the really interesting part for connecting pdp/gf/gem is that the syphon interface is well defined, and when adding support to one framework you don't have to care (nor know) about the other frameworks. fgadrt IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6xA78ACgkQkX2Xpv6ydvTpPQCgv+zK8HcQ9HZT6iFnTtMgizX8 pb0AnRG7IOEfnVn7c9ry1uPqrm5mbI30 =8MN1 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] help with PdLab:w32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 while i have access to the w32 build machine in the PdLab i have a hard time getting anything useful to compile. this is mainly, because i cannot access the binaries built by the pd-extended autobuild, and i don't want build the whole shebang myself. what is the preferred way to get anything going on that machine? fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6xQaQACgkQkX2Xpv6ydvQidACeIDI31SIfpvXCor13C/Z8n4O8 thMAnj2rcatu1p9tAAgyd+XwYuTpp9d9 =D5ej -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] help with PdLab:w32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-02 14:43, Hans-Christoph Steiner wrote: I assume you need access to the binaries for the linking. You can point your PD_PATH to /home/pd/auto-build/pd-extended/pd and as long as last night's build succeeded in building the core of Pd-extended, there will be binaries there. It should be read everyone. unfortunately not. i looked at the autobuild-logs and the externals/Makefile to see how things are built there; attached (make.log) is what i got when trying to build externals/windowing in exactly the same way as the autobuild. (the make.log shows problems with header files, which are of course quite easy to overcome; unfortunately i get the same problems when linking) Or you could just copy the pd-extended/pd folder somewhere in the pddev account and keep a location account. well, no; attached (copying.log) is the output when i try to do the copy. Or even check out pure-data.git, and build it there. that would be a good idea, but: - - the machine is a bit slow; compiling Pd takes ages - - i still haven't spent enough time to get a usable build, even when i did find a bit of time to try to compile Pd myself. - - i'd rather spend my time in getting my broken code to work than to fix things which already appear to work anyhow fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6xTj0ACgkQkX2Xpv6ydvT1bwCfdD1SJI4M7ogI+vEaGcNhhVYM 5+kAoIrSMW3lUlDRrNf5F5knMi7I6B5l =bDoX -END PGP SIGNATURE- make CFLAGS=-DPD -DHAVE_G_CANVAS_H -I/home/pd/auto-build/pd-extended/pd/src -Wall -W -ggdb -I/home/pd/auto-build/pd-extended/externals/Gem -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)' PD_PATH=/home/pd/auto-build/pd-extended/pd PD_INCLUDE=/home/pd/auto-build/pd-extended/pd/src gcc -I/home/pd/auto-build/pd-extended/pd/src -DPD -DVERSION='0.1.1-svn' -mms-bitfields -DPD -DHAVE_G_CANVAS_H -I/home/pd/auto-build/pd-extended/pd/src -Wall -W -ggdb -I/home/pd/auto-build/pd-extended/externals/Gem -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)' -O3 -funroll-loops -fomit-frame-pointer -o bartlett~.o -c bartlett~.c bartlett~.c:22:18: fatal error: C:/MinGW/msys/1.0/home/pd/auto-build/pd-extended/pd/src/m_pd.h: Permission denied compilation terminated. make: *** [bartlett~.o] Error 1 $ cp -r /home/pd/auto-build/pd-extended/pd/ tmp/ cp: cannot open `/home/pd/auto-build/pd-extended/pd/asio/ASIOSDK2/common/asio.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/asio/ASIOSDK2/host/asiodrivers.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/asio/ASIOSDK2/host/pc/asiolist.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/portmidi/pm_common/pmutil.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/portmidi/pm_common/portmidi.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/portmidi/pm_win/pmwin.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/portmidi/pm_win/pmwinmm.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/portmidi/porttime/porttime.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/portmidi/porttime/ptwinmm.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/src/closebang.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/src/d_arithmetic.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/src/d_array.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/src/d_ctl.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/src/d_delay.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/src/d_fftroutine.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/src/d_fft_mayer.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/src/d_filter.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/src/d_global.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/src/d_osc.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/src/d_resample.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/src/d_soundfile.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/src/d_ugen.o' for reading: Permission denied cp: cannot open `/home/pd/auto-build/pd-extended/pd/src/e_dac.o' for
Re: [PD-dev] help with PdLab:w32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-11-02 16:30, Hans-Christoph Steiner wrote: I forced everything in the 'pd' account to be read everyone, hope that helps. thanks. i guess this will only become active after the next autobuild run, correct? for now, i still have: $ ls -lha /home/pd/auto-build/pd-extended/pd/src/m_pd.h - -rwx-- 1 pd None 26K Nov 2 03:32 /home/pd/auto-build/pd-extended/pd/src/m_pd.h fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6xaIoACgkQkX2Xpv6ydvRsHACgh70SqZ8/ooe9ij4SCbibbXLp AfsAoLuqT6ZEwPa8UsJQkIzsp5PAzuL+ =wMHG -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
