Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
Same as Joel here, one-inlet [list]. Happy you found the bug ! I'm eager to test the next build for quantal 64. On 23/01/2013 05:28, Hans-Christoph Steiner wrote: Ok, I think found the issue, it was a stupid C string mistake on my part, here's the commit: http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended.git;a=commitdiff;h=7de958b3f4504e9504649944e015e5c13e28df33 Please test tomorrow's build and let me know if it fixes it for you. .hc On 01/22/2013 09:58 PM, Joel Matthys wrote: No, I get one inlet on list. Joel On 01/22/2013 07:15 PM, Hans-Christoph Steiner wrote: Do you get the right two inlet [list] if you run it like this: $ pd-extended -noprefs .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
[list] bug seems to be repaired. thanks. fk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
+1 Yay! Jb On 23 January 2013 13:42, Fero Kiraly fero.kir...@gmail.com wrote: [list] bug seems to be repaired. thanks. fk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
I just uploaded the packages to launchpad, once they're done, please test and report back :) My guess is around 4am GMT, around 6 hours from now. https://launchpad.net/~eighthave/+archive/pd-extended/+packages .hc On 01/23/2013 05:29 AM, batinste wrote: Same as Joel here, one-inlet [list]. Happy you found the bug ! I'm eager to test the next build for quantal 64. On 23/01/2013 05:28, Hans-Christoph Steiner wrote: Ok, I think found the issue, it was a stupid C string mistake on my part, here's the commit: http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended.git;a=commitdiff;h=7de958b3f4504e9504649944e015e5c13e28df33 Please test tomorrow's build and let me know if it fixes it for you. .hc On 01/22/2013 09:58 PM, Joel Matthys wrote: No, I get one inlet on list. Joel On 01/22/2013 07:15 PM, Hans-Christoph Steiner wrote: Do you get the right two inlet [list] if you run it like this: $ pd-extended -noprefs .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
export | grep LANG declare -x LANG=en_GB.UTF-8 declare -x LANGUAGE=en_GB:en $ export | grep LC_ julian@brooks:~/Desktop$ (nothing too) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
Hmm, there goes that idea... I thought it might be an encoding issue, but y'all are all using UTF-8 encoding. It doesn't seem Debian- or Ubuntu-specific, or specific to the way the package was built. I've tried to reproduce it on my Linux Mint Maya/amd64 laptop, a Linux Mint Maya/i386 laptop, two Debian/squeeze/amd64 boxes, and a Debian/wheezy/amd64 box. They all work fine. What if you do this, does it load properly and do you get the two inlet [list]? pd-extended -lib vanilla/list Any other ideas? .hc On 01/22/2013 04:10 AM, Julian Brooks wrote: export | grep LANG declare -x LANG=en_GB.UTF-8 declare -x LANGUAGE=en_GB:en $ export | grep LC_ julian@brooks:~/Desktop$ (nothing too) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
Hi again, With this I get pd-extended -lib vanilla/list oops: ALSA cards not reported in order? oops: ALSA cards not reported in order? priority 8 scheduling enabled. priority 6 scheduling enabled. open: /etc/pd/gem.conf: No such file or directory open: /home/julian/.pd/gem.conf: No such file or directory open: ./gem.conf: No such file or directory Still get this in the console: /usr/lib/pd-extended/startup/1.list.pd_linux: can't load startup library'! though [list] has 2 inlets. Going back to: pd-extended -stderr -verbose -noprefs -nrt I don't get the console error message but [list] has one inlet. With the suggested pd-extended_0.43.4~20130121-1~quantal_amd64 I've reverted back to the debian wheezy nightly build. Same results though I've once got this error on shutdown: 'pdsend errorname: error writing sock8: broken pipejulian@brooks :~/Desktop$' Though presume it's not related? It was a possibly dumb try but [vanilla/list] doesn't instantiate (you probably knew that already) Jb On 22 January 2013 16:28, Hans-Christoph Steiner h...@at.or.at wrote: Hmm, there goes that idea... I thought it might be an encoding issue, but y'all are all using UTF-8 encoding. It doesn't seem Debian- or Ubuntu-specific, or specific to the way the package was built. I've tried to reproduce it on my Linux Mint Maya/amd64 laptop, a Linux Mint Maya/i386 laptop, two Debian/squeeze/amd64 boxes, and a Debian/wheezy/amd64 box. They all work fine. What if you do this, does it load properly and do you get the two inlet [list]? pd-extended -lib vanilla/list Any other ideas? .hc On 01/22/2013 04:10 AM, Julian Brooks wrote: export | grep LANG declare -x LANG=en_GB.UTF-8 declare -x LANGUAGE=en_GB:en $ export | grep LC_ julian@brooks:~/Desktop$ (nothing too) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
Ok, I think found the issue, it was a stupid C string mistake on my part, here's the commit: http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended.git;a=commitdiff;h=7de958b3f4504e9504649944e015e5c13e28df33 Please test tomorrow's build and let me know if it fixes it for you. .hc On 01/22/2013 09:58 PM, Joel Matthys wrote: No, I get one inlet on list. Joel On 01/22/2013 07:15 PM, Hans-Christoph Steiner wrote: Do you get the right two inlet [list] if you run it like this: $ pd-extended -noprefs .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
Thanks so much! I know how frustrating it can be to track down problems in C strings. Joel On 01/22/2013 11:28 PM, Hans-Christoph Steiner wrote: Ok, I think found the issue, it was a stupid C string mistake on my part, here's the commit: http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pd-extended.git;a=commitdiff;h=7de958b3f4504e9504649944e015e5c13e28df33 Please test tomorrow's build and let me know if it fixes it for you. .hc On 01/22/2013 09:58 PM, Joel Matthys wrote: No, I get one inlet on list. Joel On 01/22/2013 07:15 PM, Hans-Christoph Steiner wrote: Do you get the right two inlet [list] if you run it like this: $ pd-extended -noprefs .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
Yip yip - same here: 0.43.4-extended-20130107 WARNING: 64-bit builds are still beta, some libraries are known to have serious issues (cyclone, maxlib, moonlib, moocow, pdp, bsaylor, etc.) /usr/lib/pd-extended/tcl/../startup/1.list.pd_linux: can't load startup library'! [list] has only one inlet. Debian Sid/Wheezy 64b. Best wishes, Julian On 21 January 2013 21:26, batinste dwanaf...@yahoo.fr wrote: Weirder and weirder. Pd-ext still cannot load 1.list.pd_linux. I get error: /usr/lib/pd-extended/startup/**1.list.pd_linux: can't load startup library'! but : ~$ ls /usr/lib/pd-extended/startup/ | grep list 1.list.pd_linux So i deinstalled the last auto-build of Pd-extended for ubuntu 12.10 x64 : ~$ sudo dpkg --purge pd-extended (Lecture de la base de données... 303007 fichiers et répertoires déjà installés.) Suppression de pd-extended ... Purge des fichiers de configuration de pd-extended ... dpkg : avertissement : while removing pd-extended, directory '/usr/lib/pd-extended/extra' not empty so not removed Traitement des actions différées (« triggers ») pour « hicolor-icon-theme »... Traitement des actions différées (« triggers ») pour « bamfdaemon »... Rebuilding /usr/share/applications/bamf.**index... Traitement des actions différées (« triggers ») pour « desktop-file-utils »... Traitement des actions différées (« triggers ») pour « gnome-menus »... Traitement des actions différées (« triggers ») pour « man-db »... Traitement des actions différées (« triggers ») pour « menu »... Traitement des actions différées (« triggers ») pour « shared-mime-info »... Traitement des actions différées (« triggers ») pour « ureadahead »... in the extra directory are ANN library and the missing earplug_data.txt. It shouldn't interfere with the rest. Then i removed preferences backups i did in my /home/me : .pdextended, .pdextended~, .pdextended.**thisoneactuallyworks, etc :) Then, downloaded Pd-0.43.4-extended-ubuntu-**quantal-amd64.deb from http://autobuild.puredata.**info/auto-build/latest/http://autobuild.puredata.info/auto-build/latest/and ~$ sudo dpkg -i Desktop/Pd-0.43.4-extended-**ubuntu-quantal-amd64.deb Sélection du paquet pd-extended précédemment désélectionné. (Lecture de la base de données... 295934 fichiers et répertoires déjà installés.) Dépaquetage de pd-extended (à partir de .../Pd-0.43.4-extended-ubuntu-**quantal-amd64.deb) ... Paramétrage de pd-extended (0.43.4-extended) ... Traitement des actions différées (« triggers ») pour « ureadahead »... Traitement des actions différées (« triggers ») pour « shared-mime-info »... Traitement des actions différées (« triggers ») pour « menu »... Traitement des actions différées (« triggers ») pour « man-db »... Traitement des actions différées (« triggers ») pour « bamfdaemon »... Rebuilding /usr/share/applications/bamf.**index... Traitement des actions différées (« triggers ») pour « desktop-file-utils »... Traitement des actions différées (« triggers ») pour « gnome-menus »... Traitement des actions différées (« triggers ») pour « hicolor-icon-theme »... and finally :~$ pd-extended -stderr -verbose input channels = 0, output channels = 0 Pd-0.43.4 (extended) compiled 09:20:08 Jan 20 2013 port 5400 TCL_LIBRARY=/usr/lib/pd-**extended/lib/tcl/library TK_LIBRARY=/usr/lib/pd-**extended/lib/tk/library wish8.5 /usr/lib/pd-extended/tcl//pd-**gui.tcl 5400 priority 6 scheduling enabled. Waiting for connection request... priority 8 scheduling enabled. /usr/lib/pd-extended/bin/pd-**watchdog ... connected opened 0 MIDI input device(s) and 0 MIDI output device(s). input channels = 0, output channels = 0 Fontconfig warning: /etc/fonts/conf.d/50-user.**conf, line 9: reading configurations from ~/.fonts.conf is deprecated. verbose(5): Using /usr/lib/pd-extended/startup as startup. verbose(4): Loading /usr/lib/pd-extended/startup/**0.libdir.pd_linux tried /usr/lib/pd-extended/extra/**libdir/libdir.l_ia64 and failed tried /usr/lib/pd-extended/extra/**libdir/libdir.pd_linux and succeeded verbose(3): libdir loader 1.9 verbose(3): compiled on Jan 20 2013 at 09:23:51 verbose(3): compiled against Pd version 0.43.4.extended verbose(4): Loading /usr/lib/pd-extended/startup/**1.list.pd_linux tried ./`Lp.l_ia64 and failed tried /home/batinste/pd-externals/`**Lp.l_ia64 and failed tried /usr/local/lib/pd-externals/`**Lp.l_ia64 and failed tried /usr/lib/pd-extended/extra/`**Lp.l_ia64 and failed tried ./`Lp.pd_linux and failed tried /home/batinste/pd-externals/`**Lp.pd_linux and failed tried /usr/local/lib/pd-externals/`**Lp.pd_linux and failed tried /usr/lib/pd-extended/extra/`**Lp.pd_linux and failed tried ./`Lp/`Lp.l_ia64 and failed tried /home/batinste/pd-externals/`**Lp/`Lp.l_ia64 and failed tried /usr/local/lib/pd-externals/`**Lp/`Lp.l_ia64 and failed tried /usr/lib/pd-extended/extra/`**Lp/`Lp.l_ia64 and failed tried ./`Lp/`Lp.pd_linux and failed tried
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
Definitely something odd is going on because when trying to load 1.list.pd_linux, it then tries to find `Lp.pd_linux which does not exist: Loading /usr/lib/pd-extended/startup/1.list.pd_linux tried ./`Lp.l_ia64 and failed tried /home/batinste/pd-externals/`Lp.l_ia64 and failed tried /usr/local/lib/pd-externals/`Lp.l_ia64 and failed tried /usr/lib/pd-extended/extra/`Lp.l_ia64 and failed tried ./`Lp.pd_linux and failed tried /home/batinste/pd-externals/`Lp.pd_linux and failed tried /usr/local/lib/pd-externals/`Lp.pd_linux and failed tried /usr/lib/pd-extended/extra/`Lp.pd_linux and failed tried ./`Lp/`Lp.l_ia64 and failed tried /home/batinste/pd-externals/`Lp/`Lp.l_ia64 and failed tried /usr/local/lib/pd-externals/`Lp/`Lp.l_ia64 and failed tried /usr/lib/pd-extended/extra/`Lp/`Lp.l_ia64 and failed tried ./`Lp/`Lp.pd_linux and failed tried /home/batinste/pd-externals/`Lp/`Lp.pd_linux and failed tried /usr/local/lib/pd-externals/`Lp/`Lp.pd_linux and failed tried /usr/lib/pd-extended/extra/`Lp/`Lp.pd_linux and failed What does this show you: ls -l /usr/lib/pd-extended/startup/1.list.pd_linux .hc On 01/21/2013 04:26 PM, batinste wrote: Weirder and weirder. Pd-ext still cannot load 1.list.pd_linux. I get error: /usr/lib/pd-extended/startup/1.list.pd_linux: can't load startup library'! but : ~$ ls /usr/lib/pd-extended/startup/ | grep list 1.list.pd_linux So i deinstalled the last auto-build of Pd-extended for ubuntu 12.10 x64 : ~$ sudo dpkg --purge pd-extended (Lecture de la base de données... 303007 fichiers et répertoires déjà installés.) Suppression de pd-extended ... Purge des fichiers de configuration de pd-extended ... dpkg : avertissement : while removing pd-extended, directory '/usr/lib/pd-extended/extra' not empty so not removed Traitement des actions différées (« triggers ») pour « hicolor-icon-theme »... Traitement des actions différées (« triggers ») pour « bamfdaemon »... Rebuilding /usr/share/applications/bamf.index... Traitement des actions différées (« triggers ») pour « desktop-file-utils »... Traitement des actions différées (« triggers ») pour « gnome-menus »... Traitement des actions différées (« triggers ») pour « man-db »... Traitement des actions différées (« triggers ») pour « menu »... Traitement des actions différées (« triggers ») pour « shared-mime-info »... Traitement des actions différées (« triggers ») pour « ureadahead »... in the extra directory are ANN library and the missing earplug_data.txt. It shouldn't interfere with the rest. Then i removed preferences backups i did in my /home/me : .pdextended, .pdextended~, .pdextended.thisoneactuallyworks, etc :) Then, downloaded Pd-0.43.4-extended-ubuntu-quantal-amd64.deb from http://autobuild.puredata.info/auto-build/latest/ and ~$ sudo dpkg -i Desktop/Pd-0.43.4-extended-ubuntu-quantal-amd64.deb Sélection du paquet pd-extended précédemment désélectionné. (Lecture de la base de données... 295934 fichiers et répertoires déjà installés.) Dépaquetage de pd-extended (à partir de .../Pd-0.43.4-extended-ubuntu-quantal-amd64.deb) ... Paramétrage de pd-extended (0.43.4-extended) ... Traitement des actions différées (« triggers ») pour « ureadahead »... Traitement des actions différées (« triggers ») pour « shared-mime-info »... Traitement des actions différées (« triggers ») pour « menu »... Traitement des actions différées (« triggers ») pour « man-db »... Traitement des actions différées (« triggers ») pour « bamfdaemon »... Rebuilding /usr/share/applications/bamf.index... Traitement des actions différées (« triggers ») pour « desktop-file-utils »... Traitement des actions différées (« triggers ») pour « gnome-menus »... Traitement des actions différées (« triggers ») pour « hicolor-icon-theme »... and finally :~$ pd-extended -stderr -verbose input channels = 0, output channels = 0 Pd-0.43.4 (extended) compiled 09:20:08 Jan 20 2013 port 5400 TCL_LIBRARY=/usr/lib/pd-extended/lib/tcl/library TK_LIBRARY=/usr/lib/pd-extended/lib/tk/library wish8.5 /usr/lib/pd-extended/tcl//pd-gui.tcl 5400 priority 6 scheduling enabled. Waiting for connection request... priority 8 scheduling enabled. /usr/lib/pd-extended/bin/pd-watchdog ... connected opened 0 MIDI input device(s) and 0 MIDI output device(s). input channels = 0, output channels = 0 Fontconfig warning: /etc/fonts/conf.d/50-user.conf, line 9: reading configurations from ~/.fonts.conf is deprecated. verbose(5): Using /usr/lib/pd-extended/startup as startup. verbose(4): Loading /usr/lib/pd-extended/startup/0.libdir.pd_linux tried /usr/lib/pd-extended/extra/libdir/libdir.l_ia64 and failed tried /usr/lib/pd-extended/extra/libdir/libdir.pd_linux and succeeded verbose(3): libdir loader 1.9 verbose(3): compiled on Jan 20 2013 at 09:23:51 verbose(3): compiled against Pd version 0.43.4.extended verbose(4): Loading /usr/lib/pd-extended/startup/1.list.pd_linux tried ./`Lp.l_ia64 and
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
Hey Julian, Can you run this and send me the results: $ pd-extended -stderr -verbose -noprefs -nrt .hc On 01/21/2013 04:37 PM, Julian Brooks wrote: Yip yip - same here: 0.43.4-extended-20130107 WARNING: 64-bit builds are still beta, some libraries are known to have serious issues (cyclone, maxlib, moonlib, moocow, pdp, bsaylor, etc.) /usr/lib/pd-extended/tcl/../startup/1.list.pd_linux: can't load startup library'! [list] has only one inlet. Debian Sid/Wheezy 64b. Best wishes, Julian On 21 January 2013 21:26, batinste dwanaf...@yahoo.fr wrote: Weirder and weirder. Pd-ext still cannot load 1.list.pd_linux. I get error: /usr/lib/pd-extended/startup/**1.list.pd_linux: can't load startup library'! but : ~$ ls /usr/lib/pd-extended/startup/ | grep list 1.list.pd_linux So i deinstalled the last auto-build of Pd-extended for ubuntu 12.10 x64 : ~$ sudo dpkg --purge pd-extended (Lecture de la base de données... 303007 fichiers et répertoires déjà installés.) Suppression de pd-extended ... Purge des fichiers de configuration de pd-extended ... dpkg : avertissement : while removing pd-extended, directory '/usr/lib/pd-extended/extra' not empty so not removed Traitement des actions différées (« triggers ») pour « hicolor-icon-theme »... Traitement des actions différées (« triggers ») pour « bamfdaemon »... Rebuilding /usr/share/applications/bamf.**index... Traitement des actions différées (« triggers ») pour « desktop-file-utils »... Traitement des actions différées (« triggers ») pour « gnome-menus »... Traitement des actions différées (« triggers ») pour « man-db »... Traitement des actions différées (« triggers ») pour « menu »... Traitement des actions différées (« triggers ») pour « shared-mime-info »... Traitement des actions différées (« triggers ») pour « ureadahead »... in the extra directory are ANN library and the missing earplug_data.txt. It shouldn't interfere with the rest. Then i removed preferences backups i did in my /home/me : .pdextended, .pdextended~, .pdextended.**thisoneactuallyworks, etc :) Then, downloaded Pd-0.43.4-extended-ubuntu-**quantal-amd64.deb from http://autobuild.puredata.**info/auto-build/latest/http://autobuild.puredata.info/auto-build/latest/and ~$ sudo dpkg -i Desktop/Pd-0.43.4-extended-**ubuntu-quantal-amd64.deb Sélection du paquet pd-extended précédemment désélectionné. (Lecture de la base de données... 295934 fichiers et répertoires déjà installés.) Dépaquetage de pd-extended (à partir de .../Pd-0.43.4-extended-ubuntu-**quantal-amd64.deb) ... Paramétrage de pd-extended (0.43.4-extended) ... Traitement des actions différées (« triggers ») pour « ureadahead »... Traitement des actions différées (« triggers ») pour « shared-mime-info »... Traitement des actions différées (« triggers ») pour « menu »... Traitement des actions différées (« triggers ») pour « man-db »... Traitement des actions différées (« triggers ») pour « bamfdaemon »... Rebuilding /usr/share/applications/bamf.**index... Traitement des actions différées (« triggers ») pour « desktop-file-utils »... Traitement des actions différées (« triggers ») pour « gnome-menus »... Traitement des actions différées (« triggers ») pour « hicolor-icon-theme »... and finally :~$ pd-extended -stderr -verbose input channels = 0, output channels = 0 Pd-0.43.4 (extended) compiled 09:20:08 Jan 20 2013 port 5400 TCL_LIBRARY=/usr/lib/pd-**extended/lib/tcl/library TK_LIBRARY=/usr/lib/pd-**extended/lib/tk/library wish8.5 /usr/lib/pd-extended/tcl//pd-**gui.tcl 5400 priority 6 scheduling enabled. Waiting for connection request... priority 8 scheduling enabled. /usr/lib/pd-extended/bin/pd-**watchdog ... connected opened 0 MIDI input device(s) and 0 MIDI output device(s). input channels = 0, output channels = 0 Fontconfig warning: /etc/fonts/conf.d/50-user.**conf, line 9: reading configurations from ~/.fonts.conf is deprecated. verbose(5): Using /usr/lib/pd-extended/startup as startup. verbose(4): Loading /usr/lib/pd-extended/startup/**0.libdir.pd_linux tried /usr/lib/pd-extended/extra/**libdir/libdir.l_ia64 and failed tried /usr/lib/pd-extended/extra/**libdir/libdir.pd_linux and succeeded verbose(3): libdir loader 1.9 verbose(3): compiled on Jan 20 2013 at 09:23:51 verbose(3): compiled against Pd version 0.43.4.extended verbose(4): Loading /usr/lib/pd-extended/startup/**1.list.pd_linux tried ./`Lp.l_ia64 and failed tried /home/batinste/pd-externals/`**Lp.l_ia64 and failed tried /usr/local/lib/pd-externals/`**Lp.l_ia64 and failed tried /usr/lib/pd-extended/extra/`**Lp.l_ia64 and failed tried ./`Lp.pd_linux and failed tried /home/batinste/pd-externals/`**Lp.pd_linux and failed tried /usr/local/lib/pd-externals/`**Lp.pd_linux and failed tried /usr/lib/pd-extended/extra/`**Lp.pd_linux and failed tried ./`Lp/`Lp.l_ia64 and failed tried /home/batinste/pd-externals/`**Lp/`Lp.l_ia64 and failed tried
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
Also, does it happen if you use the Ubuntu/oneiric package (should work for wheezy, you might want to use quantal or raring for sid): https://launchpad.net/~eighthave/+archive/pd-extended/+files/pd-extended_0.43.4%7E20130121-1%7Eoneiric_amd64.deb .hc On 01/21/2013 04:37 PM, Julian Brooks wrote: Yip yip - same here: 0.43.4-extended-20130107 WARNING: 64-bit builds are still beta, some libraries are known to have serious issues (cyclone, maxlib, moonlib, moocow, pdp, bsaylor, etc.) /usr/lib/pd-extended/tcl/../startup/1.list.pd_linux: can't load startup library'! [list] has only one inlet. Debian Sid/Wheezy 64b. Best wishes, Julian On 21 January 2013 21:26, batinste dwanaf...@yahoo.fr wrote: Weirder and weirder. Pd-ext still cannot load 1.list.pd_linux. I get error: /usr/lib/pd-extended/startup/**1.list.pd_linux: can't load startup library'! but : ~$ ls /usr/lib/pd-extended/startup/ | grep list 1.list.pd_linux So i deinstalled the last auto-build of Pd-extended for ubuntu 12.10 x64 : ~$ sudo dpkg --purge pd-extended (Lecture de la base de données... 303007 fichiers et répertoires déjà installés.) Suppression de pd-extended ... Purge des fichiers de configuration de pd-extended ... dpkg : avertissement : while removing pd-extended, directory '/usr/lib/pd-extended/extra' not empty so not removed Traitement des actions différées (« triggers ») pour « hicolor-icon-theme »... Traitement des actions différées (« triggers ») pour « bamfdaemon »... Rebuilding /usr/share/applications/bamf.**index... Traitement des actions différées (« triggers ») pour « desktop-file-utils »... Traitement des actions différées (« triggers ») pour « gnome-menus »... Traitement des actions différées (« triggers ») pour « man-db »... Traitement des actions différées (« triggers ») pour « menu »... Traitement des actions différées (« triggers ») pour « shared-mime-info »... Traitement des actions différées (« triggers ») pour « ureadahead »... in the extra directory are ANN library and the missing earplug_data.txt. It shouldn't interfere with the rest. Then i removed preferences backups i did in my /home/me : .pdextended, .pdextended~, .pdextended.**thisoneactuallyworks, etc :) Then, downloaded Pd-0.43.4-extended-ubuntu-**quantal-amd64.deb from http://autobuild.puredata.**info/auto-build/latest/http://autobuild.puredata.info/auto-build/latest/and ~$ sudo dpkg -i Desktop/Pd-0.43.4-extended-**ubuntu-quantal-amd64.deb Sélection du paquet pd-extended précédemment désélectionné. (Lecture de la base de données... 295934 fichiers et répertoires déjà installés.) Dépaquetage de pd-extended (à partir de .../Pd-0.43.4-extended-ubuntu-**quantal-amd64.deb) ... Paramétrage de pd-extended (0.43.4-extended) ... Traitement des actions différées (« triggers ») pour « ureadahead »... Traitement des actions différées (« triggers ») pour « shared-mime-info »... Traitement des actions différées (« triggers ») pour « menu »... Traitement des actions différées (« triggers ») pour « man-db »... Traitement des actions différées (« triggers ») pour « bamfdaemon »... Rebuilding /usr/share/applications/bamf.**index... Traitement des actions différées (« triggers ») pour « desktop-file-utils »... Traitement des actions différées (« triggers ») pour « gnome-menus »... Traitement des actions différées (« triggers ») pour « hicolor-icon-theme »... and finally :~$ pd-extended -stderr -verbose input channels = 0, output channels = 0 Pd-0.43.4 (extended) compiled 09:20:08 Jan 20 2013 port 5400 TCL_LIBRARY=/usr/lib/pd-**extended/lib/tcl/library TK_LIBRARY=/usr/lib/pd-**extended/lib/tk/library wish8.5 /usr/lib/pd-extended/tcl//pd-**gui.tcl 5400 priority 6 scheduling enabled. Waiting for connection request... priority 8 scheduling enabled. /usr/lib/pd-extended/bin/pd-**watchdog ... connected opened 0 MIDI input device(s) and 0 MIDI output device(s). input channels = 0, output channels = 0 Fontconfig warning: /etc/fonts/conf.d/50-user.**conf, line 9: reading configurations from ~/.fonts.conf is deprecated. verbose(5): Using /usr/lib/pd-extended/startup as startup. verbose(4): Loading /usr/lib/pd-extended/startup/**0.libdir.pd_linux tried /usr/lib/pd-extended/extra/**libdir/libdir.l_ia64 and failed tried /usr/lib/pd-extended/extra/**libdir/libdir.pd_linux and succeeded verbose(3): libdir loader 1.9 verbose(3): compiled on Jan 20 2013 at 09:23:51 verbose(3): compiled against Pd version 0.43.4.extended verbose(4): Loading /usr/lib/pd-extended/startup/**1.list.pd_linux tried ./`Lp.l_ia64 and failed tried /home/batinste/pd-externals/`**Lp.l_ia64 and failed tried /usr/local/lib/pd-externals/`**Lp.l_ia64 and failed tried /usr/lib/pd-extended/extra/`**Lp.l_ia64 and failed tried ./`Lp.pd_linux and failed tried /home/batinste/pd-externals/`**Lp.pd_linux and failed tried /usr/local/lib/pd-externals/`**Lp.pd_linux and failed tried
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
Strange, you're is trying a blank object name: verbose(4): Loading /usr/lib/pd-extended/startup/1.list.pd_linux tried ./.l_ia64 and failed tried /home/julian/pd-externals/.l_ia64 and failed tried /usr/local/lib/pd-externals/.l_ia64 and failed tried /usr/lib/pd-extended/extra/.l_ia64 and failed tried ./.pd_linux and failed tried /home/julian/pd-externals/.pd_linux and failed tried /usr/local/lib/pd-externals/.pd_linux and failed tried /usr/lib/pd-extended/extra/.pd_linux and failed tried .l_ia64 and failed tried .pd_linux and failed tried -meta.pd and failed error: /usr/lib/pd-extended/startup/1.list.pd_linux: can't load startup library'! What does this tell you: ls -l /usr/lib/pd-extended/startup/1.list.pd_linux .hc On 01/21/2013 06:06 PM, Julian Brooks wrote: Hey Hans, Apologies for the delay... $ pd-extended -stderr -verbose -noprefs -nrt input channels = 0, output channels = 0 Pd-0.43.4 (extended-20130107) compiled 06:37:26 Jan 7 2013 port 5400 TCL_LIBRARY=/usr/lib/pd-extended/lib/tcl/library TK_LIBRARY=/usr/lib/pd-extended/lib/tk/library wish8.5 /usr/lib/pd-extended/tcl//pd-gui.tcl 5400 Waiting for connection request... ... connected opened 0 MIDI input device(s) and 0 MIDI output device(s). input channels = 0, output channels = 0 verbose(5): Using /usr/lib/pd-extended/startup as startup. verbose(4): Loading /usr/lib/pd-extended/startup/0.libdir.pd_linux tried /usr/lib/pd-extended/extra/libdir/libdir.l_ia64 and failed tried /usr/lib/pd-extended/extra/libdir/libdir.pd_linux and succeeded verbose(3): libdir loader 1.9 verbose(3): compiled on Jan 7 2013 at 06:42:56 verbose(3): compiled against Pd version 0.43.4.extended-20130107 verbose(4): Loading /usr/lib/pd-extended/startup/1.list.pd_linux tried ./.l_ia64 and failed tried /home/julian/pd-externals/.l_ia64 and failed tried /usr/local/lib/pd-externals/.l_ia64 and failed tried /usr/lib/pd-extended/extra/.l_ia64 and failed tried ./.pd_linux and failed tried /home/julian/pd-externals/.pd_linux and failed tried /usr/local/lib/pd-externals/.pd_linux and failed tried /usr/lib/pd-extended/extra/.pd_linux and failed tried .l_ia64 and failed tried .pd_linux and failed tried -meta.pd and failed error: /usr/lib/pd-extended/startup/1.list.pd_linux: can't load startup library'! verbose(4): Loading extra in /usr/lib/pd-extended/startup/extra tried ./extra.l_ia64 and failed tried /home/julian/pd-externals/extra.l_ia64 and failed tried /usr/local/lib/pd-externals/extra.l_ia64 and failed tried /usr/lib/pd-extended/extra/extra.l_ia64 and failed tried ./extra.pd_linux and failed tried /home/julian/pd-externals/extra.pd_linux and failed tried /usr/local/lib/pd-externals/extra.pd_linux and failed tried /usr/lib/pd-extended/extra/extra.pd_linux and failed tried ./extra/extra.l_ia64 and failed tried /home/julian/pd-externals/extra/extra.l_ia64 and failed tried /usr/local/lib/pd-externals/extra/extra.l_ia64 and failed tried /usr/lib/pd-extended/extra/extra/extra.l_ia64 and failed tried ./extra/extra.pd_linux and failed tried /home/julian/pd-externals/extra/extra.pd_linux and failed tried /usr/local/lib/pd-externals/extra/extra.pd_linux and failed tried /usr/lib/pd-extended/extra/extra/extra.pd_linux and failed tried ./extra/extra-meta.pd and failed tried /home/julian/pd-externals/extra/extra-meta.pd and failed tried /usr/local/lib/pd-externals/extra/extra-meta.pd and failed tried /usr/lib/pd-extended/extra/extra/extra-meta.pd and succeeded verbose(3): libdir_loader: added 'extra' to the global objectclass path verbose(14): Loaded libdir 'extra' from '/usr/lib/pd-extended/extra/extra' verbose(4): Loading pdlua in /usr/lib/pd-extended/startup/pdlua tried ./pdlua.l_ia64 and failed tried /usr/lib/pd-extended/extra/extra/pdlua.l_ia64 and failed tried /home/julian/pd-externals/pdlua.l_ia64 and failed tried /usr/local/lib/pd-externals/pdlua.l_ia64 and failed tried /usr/lib/pd-extended/extra/pdlua.l_ia64 and failed tried ./pdlua.pd_linux and failed tried /usr/lib/pd-extended/extra/extra/pdlua.pd_linux and failed tried /home/julian/pd-externals/pdlua.pd_linux and failed tried /usr/local/lib/pd-externals/pdlua.pd_linux and failed tried /usr/lib/pd-extended/extra/pdlua.pd_linux and failed tried ./pdlua/pdlua.l_ia64 and failed tried /usr/lib/pd-extended/extra/extra/pdlua/pdlua.l_ia64 and failed tried /home/julian/pd-externals/pdlua/pdlua.l_ia64 and failed tried /usr/local/lib/pd-externals/pdlua/pdlua.l_ia64 and failed tried /usr/lib/pd-extended/extra/pdlua/pdlua.l_ia64 and failed tried ./pdlua/pdlua.pd_linux and failed tried /usr/lib/pd-extended/extra/extra/pdlua/pdlua.pd_linux and failed tried /home/julian/pd-externals/pdlua/pdlua.pd_linux and failed tried /usr/local/lib/pd-externals/pdlua/pdlua.pd_linux and failed tried /usr/lib/pd-extended/extra/pdlua/pdlua.pd_linux and succeeded verbose(3): pdlua 0.7.1 (GPL) 2012 Martin Peach, based on verbose(3): lua 0.6~svn (GPL)
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
ls -l /usr/lib/pd-extended/startup/1.list.pd_linux lrwxrwxrwx 1 root root 30 Jan 21 22:00 /usr/lib/pd-extended/startup/1.list.pd_linux - ../extra/vanilla/list.pd_linux On 21 January 2013 23:28, Hans-Christoph Steiner h...@at.or.at wrote: ls -l /usr/lib/pd-extended/startup/1.list.pd_linux ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
With the below Ubuntu package all seems better - list has 2 inlets once more:) Jb On 21 January 2013 22:12, Hans-Christoph Steiner h...@at.or.at wrote: Also, does it happen if you use the Ubuntu/oneiric package (should work for wheezy, you might want to use quantal or raring for sid): https://launchpad.net/~eighthave/+archive/pd-extended/+files/pd-extended_0.43.4%7E20130121-1%7quantal_amd64.deb .hc On 01/21/2013 04:37 PM, Julian Brooks wrote: Yip yip - same here: 0.43.4-extended-20130107 WARNING: 64-bit builds are still beta, some libraries are known to have serious issues (cyclone, maxlib, moonlib, moocow, pdp, bsaylor, etc.) /usr/lib/pd-extended/tcl/../startup/1.list.pd_linux: can't load startup library'! [list] has only one inlet. Debian Sid/Wheezy 64b. Best wishes, Julian On 21 January 2013 21:26, batinste dwanaf...@yahoo.fr wrote: Weirder and weirder. Pd-ext still cannot load 1.list.pd_linux. I get error: /usr/lib/pd-extended/startup/**1.list.pd_linux: can't load startup library'! but : ~$ ls /usr/lib/pd-extended/startup/ | grep list 1.list.pd_linux So i deinstalled the last auto-build of Pd-extended for ubuntu 12.10 x64 : ~$ sudo dpkg --purge pd-extended (Lecture de la base de données... 303007 fichiers et répertoires déjà installés.) Suppression de pd-extended ... Purge des fichiers de configuration de pd-extended ... dpkg : avertissement : while removing pd-extended, directory '/usr/lib/pd-extended/extra' not empty so not removed Traitement des actions différées (« triggers ») pour « hicolor-icon-theme »... Traitement des actions différées (« triggers ») pour « bamfdaemon »... Rebuilding /usr/share/applications/bamf.**index... Traitement des actions différées (« triggers ») pour « desktop-file-utils »... Traitement des actions différées (« triggers ») pour « gnome-menus »... Traitement des actions différées (« triggers ») pour « man-db »... Traitement des actions différées (« triggers ») pour « menu »... Traitement des actions différées (« triggers ») pour « shared-mime-info »... Traitement des actions différées (« triggers ») pour « ureadahead »... in the extra directory are ANN library and the missing earplug_data.txt. It shouldn't interfere with the rest. Then i removed preferences backups i did in my /home/me : .pdextended, .pdextended~, .pdextended.**thisoneactuallyworks, etc :) Then, downloaded Pd-0.43.4-extended-ubuntu-**quantal-amd64.deb from http://autobuild.puredata.**info/auto-build/latest/ http://autobuild.puredata.info/auto-build/latest/and ~$ sudo dpkg -i Desktop/Pd-0.43.4-extended-**ubuntu-quantal-amd64.deb Sélection du paquet pd-extended précédemment désélectionné. (Lecture de la base de données... 295934 fichiers et répertoires déjà installés.) Dépaquetage de pd-extended (à partir de .../Pd-0.43.4-extended-ubuntu-**quantal-amd64.deb) ... Paramétrage de pd-extended (0.43.4-extended) ... Traitement des actions différées (« triggers ») pour « ureadahead »... Traitement des actions différées (« triggers ») pour « shared-mime-info »... Traitement des actions différées (« triggers ») pour « menu »... Traitement des actions différées (« triggers ») pour « man-db »... Traitement des actions différées (« triggers ») pour « bamfdaemon »... Rebuilding /usr/share/applications/bamf.**index... Traitement des actions différées (« triggers ») pour « desktop-file-utils »... Traitement des actions différées (« triggers ») pour « gnome-menus »... Traitement des actions différées (« triggers ») pour « hicolor-icon-theme »... and finally :~$ pd-extended -stderr -verbose input channels = 0, output channels = 0 Pd-0.43.4 (extended) compiled 09:20:08 Jan 20 2013 port 5400 TCL_LIBRARY=/usr/lib/pd-**extended/lib/tcl/library TK_LIBRARY=/usr/lib/pd-**extended/lib/tk/library wish8.5 /usr/lib/pd-extended/tcl//pd-**gui.tcl 5400 priority 6 scheduling enabled. Waiting for connection request... priority 8 scheduling enabled. /usr/lib/pd-extended/bin/pd-**watchdog ... connected opened 0 MIDI input device(s) and 0 MIDI output device(s). input channels = 0, output channels = 0 Fontconfig warning: /etc/fonts/conf.d/50-user.**conf, line 9: reading configurations from ~/.fonts.conf is deprecated. verbose(5): Using /usr/lib/pd-extended/startup as startup. verbose(4): Loading /usr/lib/pd-extended/startup/**0.libdir.pd_linux tried /usr/lib/pd-extended/extra/**libdir/libdir.l_ia64 and failed tried /usr/lib/pd-extended/extra/**libdir/libdir.pd_linux and succeeded verbose(3): libdir loader 1.9 verbose(3): compiled on Jan 20 2013 at 09:23:51 verbose(3): compiled against Pd version 0.43.4.extended verbose(4): Loading /usr/lib/pd-extended/startup/**1.list.pd_linux tried ./`Lp.l_ia64 and failed tried /home/batinste/pd-externals/`**Lp.l_ia64 and failed tried
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
BTW - all the ubuntu installs give me dependency errors (asking for pulseaudio-utils). I really don't want pulseaudio. So have ignored it so far. Cheers for the super-quick-fix though. Best wishes, Julian ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
Nope, not fixed for me. Just re-installed the Ubuntu Quantal package, and I still get /usr/lib/pd-extended/startup/1.list.pd_linux: can't load startup library'! It does work after [import list] though. Joel On 01/21/2013 06:31 PM, Julian Brooks wrote: With the below Ubuntu package all seems better - list has 2 inlets once more:) Jb ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
Hey Joel, Are you on Debian or Ubuntu? i386/amd64? Can you run these two commands and send the log? pd-extended -stderr -verbose -noprefs -nrt ls -l /usr/lib/pd-extended/startup/1.list.pd_linux I'm running Linux Mint Maya amd64 (which is basically Ubuntu/precise) and I've never seen this... I wonder what it is... .hc On 01/21/2013 07:38 PM, Joel Matthys wrote: Nope, not fixed for me. Just re-installed the Ubuntu Quantal package, and I still get /usr/lib/pd-extended/startup/1.list.pd_linux: can't load startup library'! It does work after [import list] though. Joel On 01/21/2013 06:31 PM, Julian Brooks wrote: With the below Ubuntu package all seems better - list has 2 inlets once more:) Jb ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
I'm on Ubuntu Quantal amd64. $ ls -l /usr/lib/pd-extended/startup/1.list.pd_linux lrwxrwxrwx 1 root root 30 Jan 21 17:09 /usr/lib/pd-extended/startup/1.list.pd_linux - ../extra/vanilla/list.pd_linux I'm attaching the log. Joel On 01/21/2013 09:10 PM, Hans-Christoph Steiner wrote: Hey Joel, Are you on Debian or Ubuntu? i386/amd64? Can you run these two commands and send the log? pd-extended -stderr -verbose -noprefs -nrt ls -l /usr/lib/pd-extended/startup/1.list.pd_linux I'm running Linux Mint Maya amd64 (which is basically Ubuntu/precise) and I've never seen this... I wonder what it is... .hc On 01/21/2013 07:38 PM, Joel Matthys wrote: Nope, not fixed for me. Just re-installed the Ubuntu Quantal package, and I still get /usr/lib/pd-extended/startup/1.list.pd_linux: can't load startup library'! It does work after [import list] though. Joel On 01/21/2013 06:31 PM, Julian Brooks wrote: With the below Ubuntu package all seems better - list has 2 inlets once more:) Jb ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list input channels = 0, output channels = 0 Pd-0.43.4 (extended) compiled 21:59:17 Jan 21 2013 port 5400 TCL_LIBRARY=/usr/lib/pd-extended/lib/tcl/library TK_LIBRARY=/usr/lib/pd-extended/lib/tk/library wish8.5 /usr/lib/pd-extended/tcl//pd-gui.tcl 5400 Waiting for connection request... ... connected opened 0 MIDI input device(s) and 0 MIDI output device(s). input channels = 0, output channels = 0 verbose(5): Using /usr/lib/pd-extended/startup as startup. verbose(4): Loading /usr/lib/pd-extended/startup/0.libdir.pd_linux tried /usr/lib/pd-extended/extra/libdir/libdir.l_ia64 and failed tried /usr/lib/pd-extended/extra/libdir/libdir.pd_linux and succeeded verbose(3): libdir loader 1.9 verbose(3): compiled on Jan 21 2013 at 21:43:41 verbose(3): compiled against Pd version 0.43.4.extended verbose(4): Loading /usr/lib/pd-extended/startup/1.list.pd_linux tried ./.l_ia64 and failed tried /home/jwmatthys/pd-externals/.l_ia64 and failed tried /usr/local/lib/pd-externals/.l_ia64 and failed tried /usr/lib/pd-extended/extra/.l_ia64 and failed tried ./.pd_linux and failed tried /home/jwmatthys/pd-externals/.pd_linux and failed tried /usr/local/lib/pd-externals/.pd_linux and failed tried /usr/lib/pd-extended/extra/.pd_linux and failed tried .//.l_ia64 and failed tried /home/jwmatthys/pd-externals//.l_ia64 and failed tried /usr/local/lib/pd-externals//.l_ia64 and failed tried /usr/lib/pd-extended/extra//.l_ia64 and failed tried .//.pd_linux and failed tried /home/jwmatthys/pd-externals//.pd_linux and failed tried /usr/local/lib/pd-externals//.pd_linux and failed tried /usr/lib/pd-extended/extra//.pd_linux and failed tried .//-meta.pd and failed tried /home/jwmatthys/pd-externals//-meta.pd and failed tried /usr/local/lib/pd-externals//-meta.pd and failed tried /usr/lib/pd-extended/extra//-meta.pd and failed error: /usr/lib/pd-extended/startup/1.list.pd_linux: can't load startup library'! verbose(4): Loading extra in /usr/lib/pd-extended/startup/extra tried ./extra.l_ia64 and failed tried /home/jwmatthys/pd-externals/extra.l_ia64 and failed tried /usr/local/lib/pd-externals/extra.l_ia64 and failed tried /usr/lib/pd-extended/extra/extra.l_ia64 and failed tried ./extra.pd_linux and failed tried /home/jwmatthys/pd-externals/extra.pd_linux and failed tried /usr/local/lib/pd-externals/extra.pd_linux and failed tried /usr/lib/pd-extended/extra/extra.pd_linux and failed tried ./extra/extra.l_ia64 and failed tried /home/jwmatthys/pd-externals/extra/extra.l_ia64 and failed tried /usr/local/lib/pd-externals/extra/extra.l_ia64 and failed tried /usr/lib/pd-extended/extra/extra/extra.l_ia64 and failed tried ./extra/extra.pd_linux and failed tried /home/jwmatthys/pd-externals/extra/extra.pd_linux and failed tried /usr/local/lib/pd-externals/extra/extra.pd_linux and failed tried /usr/lib/pd-extended/extra/extra/extra.pd_linux and failed tried ./extra/extra-meta.pd and failed tried /home/jwmatthys/pd-externals/extra/extra-meta.pd and failed tried /usr/local/lib/pd-externals/extra/extra-meta.pd and failed tried /usr/lib/pd-extended/extra/extra/extra-meta.pd and succeeded verbose(3): libdir_loader: added 'extra' to the global objectclass path verbose(14): Loaded libdir 'extra' from '/usr/lib/pd-extended/extra/extra' verbose(4): Loading pdlua in /usr/lib/pd-extended/startup/pdlua tried ./pdlua.l_ia64 and failed tried /usr/lib/pd-extended/extra/extra/pdlua.l_ia64 and failed tried /home/jwmatthys/pd-externals/pdlua.l_ia64 and failed tried /usr/local/lib/pd-externals/pdlua.l_ia64 and failed tried /usr/lib/pd-extended/extra/pdlua.l_ia64 and failed tried ./pdlua.pd_linux and failed tried
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
Could all three of you who are affected by this issue send me the result of these two commands: $ export | grep LANG $ export | grep LC_ There seems to be some kind of odd unicode bug. Your system is also looking for the wrong thing: verbose(4): Loading /usr/lib/pd-extended/startup/1.list.pd_linux tried ./.l_ia64 and failed tried /home/jwmatthys/pd-externals/.l_ia64 and failed tried /usr/local/lib/pd-externals/.l_ia64 and failed tried /usr/lib/pd-extended/extra/.l_ia64 and failed tried ./.pd_linux and failed tried /home/jwmatthys/pd-externals/.pd_linux and failed tried /usr/local/lib/pd-externals/.pd_linux and failed tried /usr/lib/pd-extended/extra/.pd_linux and failed tried .//.l_ia64 and failed tried /home/jwmatthys/pd-externals//.l_ia64 and failed tried /usr/local/lib/pd-externals//.l_ia64 and failed tried /usr/lib/pd-extended/extra//.l_ia64 and failed tried .//.pd_linux and failed tried /home/jwmatthys/pd-externals//.pd_linux and failed tried /usr/local/lib/pd-externals//.pd_linux and failed tried /usr/lib/pd-extended/extra//.pd_linux and failed tried .//-meta.pd and failed tried /home/jwmatthys/pd-externals//-meta.pd and failed tried /usr/local/lib/pd-externals//-meta.pd and failed tried /usr/lib/pd-extended/extra//-meta.pd and failed error: /usr/lib/pd-extended/startup/1.list.pd_linux: can't load startup library'! .hc On 01/21/2013 09:46 PM, Joel Matthys wrote: I'm on Ubuntu Quantal amd64. $ ls -l /usr/lib/pd-extended/startup/1.list.pd_linux lrwxrwxrwx 1 root root 30 Jan 21 17:09 /usr/lib/pd-extended/startup/1.list.pd_linux - ../extra/vanilla/list.pd_linux I'm attaching the log. Joel On 01/21/2013 09:10 PM, Hans-Christoph Steiner wrote: Hey Joel, Are you on Debian or Ubuntu? i386/amd64? Can you run these two commands and send the log? pd-extended -stderr -verbose -noprefs -nrt ls -l /usr/lib/pd-extended/startup/1.list.pd_linux I'm running Linux Mint Maya amd64 (which is basically Ubuntu/precise) and I've never seen this... I wonder what it is... .hc On 01/21/2013 07:38 PM, Joel Matthys wrote: Nope, not fixed for me. Just re-installed the Ubuntu Quantal package, and I still get /usr/lib/pd-extended/startup/1.list.pd_linux: can't load startup library'! It does work after [import list] though. Joel On 01/21/2013 06:31 PM, Julian Brooks wrote: With the below Ubuntu package all seems better - list has 2 inlets once more:) Jb ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 1-inlet [list] : bug? WAS: enhance pd-extended with pd-l2ork featues ?
$ export | grep LANG declare -x LANG=en_US.UTF-8 declare -x LANGUAGE=en_US:en $ export | grep LC_ $ (ie nothing) -Joel On 01/21/2013 10:20 PM, Hans-Christoph Steiner wrote: Could all three of you who are affected by this issue send me the result of these two commands: $ export | grep LANG $ export | grep LC_ There seems to be some kind of odd unicode bug. Your system is also looking for the wrong thing: verbose(4): Loading /usr/lib/pd-extended/startup/1.list.pd_linux tried ./.l_ia64 and failed tried /home/jwmatthys/pd-externals/.l_ia64 and failed tried /usr/local/lib/pd-externals/.l_ia64 and failed tried /usr/lib/pd-extended/extra/.l_ia64 and failed tried ./.pd_linux and failed tried /home/jwmatthys/pd-externals/.pd_linux and failed tried /usr/local/lib/pd-externals/.pd_linux and failed tried /usr/lib/pd-extended/extra/.pd_linux and failed tried .//.l_ia64 and failed tried /home/jwmatthys/pd-externals//.l_ia64 and failed tried /usr/local/lib/pd-externals//.l_ia64 and failed tried /usr/lib/pd-extended/extra//.l_ia64 and failed tried .//.pd_linux and failed tried /home/jwmatthys/pd-externals//.pd_linux and failed tried /usr/local/lib/pd-externals//.pd_linux and failed tried /usr/lib/pd-extended/extra//.pd_linux and failed tried .//-meta.pd and failed tried /home/jwmatthys/pd-externals//-meta.pd and failed tried /usr/local/lib/pd-externals//-meta.pd and failed tried /usr/lib/pd-extended/extra//-meta.pd and failed error: /usr/lib/pd-extended/startup/1.list.pd_linux: can't load startup library'! .hc On 01/21/2013 09:46 PM, Joel Matthys wrote: I'm on Ubuntu Quantal amd64. $ ls -l /usr/lib/pd-extended/startup/1.list.pd_linux lrwxrwxrwx 1 root root 30 Jan 21 17:09 /usr/lib/pd-extended/startup/1.list.pd_linux - ../extra/vanilla/list.pd_linux I'm attaching the log. Joel On 01/21/2013 09:10 PM, Hans-Christoph Steiner wrote: Hey Joel, Are you on Debian or Ubuntu? i386/amd64? Can you run these two commands and send the log? pd-extended -stderr -verbose -noprefs -nrt ls -l /usr/lib/pd-extended/startup/1.list.pd_linux I'm running Linux Mint Maya amd64 (which is basically Ubuntu/precise) and I've never seen this... I wonder what it is... .hc On 01/21/2013 07:38 PM, Joel Matthys wrote: Nope, not fixed for me. Just re-installed the Ubuntu Quantal package, and I still get /usr/lib/pd-extended/startup/1.list.pd_linux: can't load startup library'! It does work after [import list] though. Joel On 01/21/2013 06:31 PM, Julian Brooks wrote: With the below Ubuntu package all seems better - list has 2 inlets once more:) Jb ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] small slice jockey bug report
Hans, thanks for pointing to possible solutions for this bug. I'm still working on a 0.42 / 0.43 compatible SliceJockey. A first test version should be ready very soon. Katja On Thu, Dec 20, 2012 at 3:30 AM, Hans-Christoph Steiner h...@at.or.at wrote: I'm using SliceJockey as a test patch for the 0.43.4 release (its really a great patch, I have to say again). There are still some issues with GUI redrawing freeing that SliceJockey illustrates well, I think I might have found the cause, so hopefully a fix is near. In the process I noticed a small bug. In [pd top] you're getting [window_name 1] to send the -topmost message to it. [window_name 1] refers to the window of the patch one level above, which is actually the [pd parameter-settings] subpatch. 0.43 now prints a big loud error about it. So you can either fix it in a 0.42 compatible way by using [window_name 2], or at least I think its 2, I'm not sure where that subpatch is. Or you can use the new handy [window_name] symbol arg: [window_name pd-SliceJockey.pd] .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [expr $f1 if...] bug?
Le 2012-01-31 à 16:07:00, Jonghyun Kim a écrit : Dear List, I found a bug: When I put this expressions, pd shut down... What's the problem? [expr] only supports 9 or 10 outlets at the same time, maximum, but this is not verified by [expr], which should just tell you about the limit, instead of crashing, and it's also not documented in the help. [#expr] does not have this limitation. You may find this external in GridFlow 9.13 or 9.14. The number of outlets is basically unlimited. (I don't recommend using the one that is in GridFlow 9.12) http://gridflow.ca/help/%23expr-help.html http://gridflow.ca/ You could also simply use several [expr] at once. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [expr $f1 if...] bug?
On 31/01/2012 16:07, Jonghyun Kim wrote: Dear List, I found a bug: My system: 0.43.1-extended-20111218 Ubuntu 11.04 qjackctl 0.3.7 metronome | | [ expr $f1; if ($f1 == 1, 1, 0); if ($f1 == 5, 2, 0); if ($f1 == 9, 3, 0); if ($f1 == 13, 4, 0); if ($f1 == 17, 5, 0); if ($f1 == 21, 6, 0); if ($f1 == 25, 7, 0); if ($f1 == 29, 8, 0); if ($f1 == 33, 9, 0); if ($f1 == 37, 10, 0); if ($f1 == 41, 11, 0); if ($f1 == 45, 12, 0); ] You could also use a [select] instead of [expr]. Something like | [sel 1 5 9 ...] | | | ... | [1( [2( [3( ... [t b] | [0( Just an idea.. Lorenzo When I put this expressions, pd shut down... The expr receive counts(like 1,2,3,4...and so on) from metronome. What's the problem? Thanks, Jong ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [expr $f1 if...] bug?
Le 2012-01-31 à 18:33:00, Lorenzo Sutton a écrit : On 31/01/2012 16:07, Jonghyun Kim wrote: expr $f1; if ($f1 == 1, 1, 0); if ($f1 == 5, 2, 0); if ($f1 == 9, 3, 0); if ($f1 == 13, 4, 0); if ($f1 == 17, 5, 0); if ($f1 == 21, 6, 0); if ($f1 == 25, 7, 0); if ($f1 == 29, 8, 0); if ($f1 == 33, 9, 0); if ($f1 == 37, 10, 0); if ($f1 == 41, 11, 0); if ($f1 == 45, 12, 0); You could also use a [select] instead of [expr]. Something like | [sel 1 5 9 ...] | | | ... | [1( [2( [3( ... [t b] | [0( Now that I think of it, with GridFlow (any version), you have this : [listfind 1 5 9 13 17 21 25 29 33 37 41 45] | [+ 1] To get a single index from 1 to 12, or 0 if not found. If you really need to send a zero for each time something is not found, however, you can do this : [#outer == (1 5 9 13 17 21 25 29 33 37 41 45)] | [# * (1 2 3 4 5 6 7 8 9 10 11 12)] | [#unpack 12] But because of the pattern of numbers involved (equally spaced), you could use [mod 4] and [div 4] to separate $f1 into two parts, one part that should be 1, and the other that should be between 1 and 12. That's quite a shortcut. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [expr $f1 if...] bug?
On 01/31/2012 06:33 PM, Lorenzo Sutton wrote: metronome | | [ expr $f1; if ($f1 == 1, 1, 0); if ($f1 == 5, 2, 0); if ($f1 == 9, 3, 0); if ($f1 == 13, 4, 0); if ($f1 == 17, 5, 0); if ($f1 == 21, 6, 0); if ($f1 == 25, 7, 0); if ($f1 == 29, 8, 0); if ($f1 == 33, 9, 0); if ($f1 == 37, 10, 0); if ($f1 == 41, 11, 0); if ($f1 == 45, 12, 0); ] You could also use a [select] instead of [expr]. Something like | [sel 1 5 9 ... ] | | | ... | [1( [2( [3( ... [t b] | [0( or something like: [expr int(($f1 + 3) * 0.25)] | [change 0] cheers, y -- yvan.voloch...@gmail.com http://yvanvolochine.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [expr $f1 if...] bug?
On 01/31/2012 07:33 PM, yvan volochine wrote: or something like: [expr int(($f1 + 3) * 0.25)] | [change 0] which of course is wrong cause it misses the else 0 part... y -- yvan.voloch...@gmail.com http://yvanvolochine.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [expr $f1 if...] bug?
- Original Message - From: Mathieu Bouchard ma...@artengine.ca To: Lorenzo Sutton lorenzofsut...@gmail.com Cc: pd-list@iem.at Sent: Tuesday, January 31, 2012 1:04 PM Subject: Re: [PD] [expr $f1 if...] bug? Le 2012-01-31 à 18:33:00, Lorenzo Sutton a écrit : On 31/01/2012 16:07, Jonghyun Kim wrote: expr $f1; if ($f1 == 1, 1, 0); if ($f1 == 5, 2, 0); if ($f1 == 9, 3, 0); if ($f1 == 13, 4, 0); if ($f1 == 17, 5, 0); if ($f1 == 21, 6, 0); if ($f1 == 25, 7, 0); if ($f1 == 29, 8, 0); if ($f1 == 33, 9, 0); if ($f1 == 37, 10, 0); if ($f1 == 41, 11, 0); if ($f1 == 45, 12, 0); You could also use a [select] instead of [expr]. Something like | [sel 1 5 9 ... ] | | | ... | [1( [2( [3( ... [t b] | [0( Now that I think of it, with GridFlow (any version), you have this : [listfind 1 5 9 13 17 21 25 29 33 37 41 45] | [+ 1] To get a single index from 1 to 12, or 0 if not found. If you really need to send a zero for each time something is not found, however, you can do this : [#outer == (1 5 9 13 17 21 25 29 33 37 41 45)] | [# * (1 2 3 4 5 6 7 8 9 10 11 12)] | [#unpack 12] This is where Pd users suffer. 1) Type 2) Notice how long it takes and how your wrist feels 3) Make 12 connections from [#unpack 12] to some message boxes. 4) Notice how long it takes and how your wrist feels -Jonathan But because of the pattern of numbers involved (equally spaced), you could use [mod 4] and [div 4] to separate $f1 into two parts, one part that should be 1, and the other that should be between 1 and 12. That's quite a shortcut. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [expr $f1 if...] bug?
On 31/01/2012 19:04, Mathieu Bouchard wrote: Le 2012-01-31 à 18:33:00, Lorenzo Sutton a écrit : On 31/01/2012 16:07, Jonghyun Kim wrote: expr $f1; if ($f1 == 1, 1, 0); if ($f1 == 5, 2, 0); if ($f1 == 9, 3, 0); if ($f1 == 13, 4, 0); if ($f1 == 17, 5, 0); if ($f1 == 21, 6, 0); if ($f1 == 25, 7, 0); if ($f1 == 29, 8, 0); if ($f1 == 33, 9, 0); if ($f1 == 37, 10, 0); if ($f1 == 41, 11, 0); if ($f1 == 45, 12, 0); You could also use a [select] instead of [expr]. Something like | [sel 1 5 9 ... ] | | | ... | [1( [2( [3( ... [t b] | [0( Now that I think of it, with GridFlow (any version), you have this : [listfind 1 5 9 13 17 21 25 29 33 37 41 45] | [+ 1] To get a single index from 1 to 12, or 0 if not found. If you really need to send a zero for each time something is not found, however, you can do this : [#outer == (1 5 9 13 17 21 25 29 33 37 41 45)] | [# * (1 2 3 4 5 6 7 8 9 10 11 12)] | [#unpack 12] But because of the pattern of numbers involved (equally spaced), you could use [mod 4] and [div 4] to separate $f1 into two parts, one part that should be 1, and the other that should be between 1 and 12. That's quite a shortcut. Ah true! I hadn't seen the pattern initially (I saw prime numbers for some reason...) So maybe one could simply use two counters with a mod 4 'driving' the second one... No? I mean: | [f 0] X [+ 1] | [mod 4] | [sel 1] | [f 1] X [+ 1] ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [expr $f1 if...] bug?
Le 2012-01-31 à 11:15:00, Jonathan Wilkes a écrit : From: Mathieu Bouchard ma...@artengine.ca [#outer == (1 5 9 13 17 21 25 29 33 37 41 45)] | [# * (1 2 3 4 5 6 7 8 9 10 11 12)] | [#unpack 12] This is where Pd users suffer. 1) Type 2) Notice how long it takes and how your wrist feels 3) Make 12 connections from [#unpack 12] to some message boxes. 4) Notice how long it takes and how your wrist feels I'm not actually advocating that type of solution. GridFlow is generally designed so that you put just one wire instead of N wires because you connect to just one object instead of N. This is done by grouping similar computations together in a kind of batch processing. It's a principle that comes from vector math (but extends well beyond vector-space theory). The principle can't be used all of the time. e.g. there's no way to use it with signals ; but there are also a lot of cases in the message domain for which it's impractical. I focus on the cases where it helps. It's not just shorter for the wrist or in time to write, it's also shorter in effort of reading, and in effort of modifying. For this case, it depends on what happens after [#unpack 12]. You could do away with [#unpack 12] and use [#to_l] or [#to_literal] or something else. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [expr $f1 if...] bug?
Yup, that sounds like a bug! Please submit a bug report and include this info :) .hc On Jan 31, 2012, at 10:07 AM, Jonghyun Kim wrote: Dear List, I found a bug: My system: 0.43.1-extended-20111218 Ubuntu 11.04 qjackctl 0.3.7 metronome | | [ expr $f1; if ($f1 == 1, 1, 0); if ($f1 == 5, 2, 0); if ($f1 == 9, 3, 0); if ($f1 == 13, 4, 0); if ($f1 == 17, 5, 0); if ($f1 == 21, 6, 0); if ($f1 == 25, 7, 0); if ($f1 == 29, 8, 0); if ($f1 == 33, 9, 0); if ($f1 == 37, 10, 0); if ($f1 == 41, 11, 0); if ($f1 == 45, 12, 0); ] When I put this expressions, pd shut down... The expr receive counts(like 1,2,3,4...and so on) from metronome. What's the problem? Thanks, Jong ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
That's exactly what happens, some minutes after clients start sending massive OSC stuff to my server, its GUI freezes but PD works ok and I can operate with sliders and number boxes, though I can't see anything.Frustrating :) Josep M From: h...@at.or.at To: ma...@artengine.ca Date: Sun, 7 Aug 2011 18:04:37 -0400 CC: pd-list@iem.at; m...@ucsd.edu; zmoel...@iem.at; martin.pe...@sympatico.ca Subject: Re: [PD] netsend/netreceive + GUI bug On Aug 7, 2011, at 5:19 PM, Mathieu Bouchard wrote: On Sun, 7 Aug 2011, Miller Puckette wrote: Here's a guess... if incoming (vanilla) netreceive traffic is swamping Pd, then since Pd prioritizes input from GUI above output back to GUI, the output never gets scheduled. If that were happening, you'd see the windows freeze but still be able to send Pd events from the GUI (hitting buttons in the patch, for instance.) That sounds like the same symptom as when there is an extra unquoted open-brace. What would it take to convince you to port your DD escaping code to Pd 0.43? :-D :-D :-D .hc Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
Speaking of workarounds what is wrong with clock_delay(0) implementation of disis_ netreceive when it uses existing facilities, has no noticeable overhead, does not drop packets our crash GUI, and is very easy to implement? Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net Jeppi Jeppi jepp...@hotmail.com wrote: That's exactly what happens, some minutes after clients start sending massive OSC stuff to my server, its GUI freezes but PD works ok and I can operate with sliders and number boxes, though I can't see anything. Frustrating :) Josep M From: h...@at.or.at To: ma...@artengine.ca Date: Sun, 7 Aug 2011 18:04:37 -0400 CC: pd-list@iem.at; m...@ucsd.edu; zmoel...@iem.at; martin.pe...@sympatico.ca Subject: Re: [PD] netsend/netreceive + GUI bug On Aug 7, 2011, at 5:19 PM, Mathieu Bouchard wrote: On Sun, 7 Aug 2011, Miller Puckette wrote: Here's a guess... if incoming (vanilla) netreceive traffic is swamping Pd, then since Pd prioritizes input from GUI above output back to GUI, the output never gets scheduled. If that were happening, you'd see the windows freeze but still be able to send Pd events from the GUI (hitting buttons in the patch, for instance.) That sounds like the same symptom as when there is an extra unquoted open-brace. What would it take to convince you to port your DD escaping code to Pd 0.43? :-D :-D :-D .hc Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
Hmm... I don't have a clear idea of what the scheduling policy or policies should be for incoming and outgoing network traffic. I think I need to figure that out first before starting to tweak netsend/netreceive (and pd~, which could share some code with netsend/receive if I could think things through better.) cheers Miller On Mon, Aug 08, 2011 at 12:58:06PM -0400, Ivica Ico Bukvic wrote: Speaking of workarounds what is wrong with clock_delay(0) implementation of disis_ netreceive when it uses existing facilities, has no noticeable overhead, does not drop packets our crash GUI, and is very easy to implement? Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net Jeppi Jeppi jepp...@hotmail.com wrote: That's exactly what happens, some minutes after clients start sending massive OSC stuff to my server, its GUI freezes but PD works ok and I can operate with sliders and number boxes, though I can't see anything. Frustrating :) Josep M From: h...@at.or.at To: ma...@artengine.ca Date: Sun, 7 Aug 2011 18:04:37 -0400 CC: pd-list@iem.at; m...@ucsd.edu; zmoel...@iem.at; martin.pe...@sympatico.ca Subject: Re: [PD] netsend/netreceive + GUI bug On Aug 7, 2011, at 5:19 PM, Mathieu Bouchard wrote: On Sun, 7 Aug 2011, Miller Puckette wrote: Here's a guess... if incoming (vanilla) netreceive traffic is swamping Pd, then since Pd prioritizes input from GUI above output back to GUI, the output never gets scheduled. If that were happening, you'd see the windows freeze but still be able to send Pd events from the GUI (hitting buttons in the patch, for instance.) That sounds like the same symptom as when there is an extra unquoted open-brace. What would it take to convince you to port your DD escaping code to Pd 0.43? :-D :-D :-D .hc Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
I have no idea if this is a relevant aside, but while chatting with someone about optimising a little embedded webserver the other day and I spotted this. http://www.monkey.org/~provos/libevent/ Whatever the policy tweaks, if any, maybe this offers some ideas regarding the implementation, not least of all because it unifies several kinds of IO at the same point, including stdio. Andy On Mon, 8 Aug 2011 10:57:15 -0700 Miller Puckette m...@ucsd.edu wrote: Hmm... I don't have a clear idea of what the scheduling policy or policies should be for incoming and outgoing network traffic. I think I need to figure that out first before starting to tweak netsend/netreceive (and pd~, which could share some code with netsend/receive if I could think things through better.) cheers Miller On Mon, Aug 08, 2011 at 12:58:06PM -0400, Ivica Ico Bukvic wrote: Speaking of workarounds what is wrong with clock_delay(0) implementation of disis_ netreceive when it uses existing facilities, has no noticeable overhead, does not drop packets our crash GUI, and is very easy to implement? Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net Jeppi Jeppi jepp...@hotmail.com wrote: That's exactly what happens, some minutes after clients start sending massive OSC stuff to my server, its GUI freezes but PD works ok and I can operate with sliders and number boxes, though I can't see anything. Frustrating :) Josep M From: h...@at.or.at To: ma...@artengine.ca Date: Sun, 7 Aug 2011 18:04:37 -0400 CC: pd-list@iem.at; m...@ucsd.edu; zmoel...@iem.at; martin.pe...@sympatico.ca Subject: Re: [PD] netsend/netreceive + GUI bug On Aug 7, 2011, at 5:19 PM, Mathieu Bouchard wrote: On Sun, 7 Aug 2011, Miller Puckette wrote: Here's a guess... if incoming (vanilla) netreceive traffic is swamping Pd, then since Pd prioritizes input from GUI above output back to GUI, the output never gets scheduled. If that were happening, you'd see the windows freeze but still be able to send Pd events from the GUI (hitting buttons in the patch, for instance.) That sounds like the same symptom as when there is an extra unquoted open-brace. What would it take to convince you to port your DD escaping code to Pd 0.43? :-D :-D :-D .hc Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Andy Farnell padawa...@obiwannabe.co.uk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
On Mon, Aug 8, 2011 at 12:26 PM, Jeppi Jeppi jepp...@hotmail.com wrote: That's exactly what happens, some minutes after clients start sending massive OSC stuff to my server, its GUI freezes but PD works ok and I can operate with sliders and number boxes, though I can't see anything. Frustrating :) I can confirm this behaviour. I have run into a similar situation over a year ago when I was sending audio over udp (using udpsend~/receive~ from mrpeach collection). However, the GUI would stop updating at different time intervals. Having become aware of this problem in a very short time before an event, my workaround was another instance of Pd running a complementary GUI (communicating, again, over udp/OSC but with lower data rate, maybe). Frustrating, indeed. I spoke with Martin about this briefly and promised to test more and try to put my finger on the problem but I never really got around to it. Anyways, this may not help but at least I'm glad to know I was not crazy when I experienced that. I have seen this both on MacOSX and Linux, pdextended 42.5 (iirc). ./MiS ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
If you are indeed talking about vanilla netsend and netreceive, the poll function is called during pd's main loop, not when something arrives at the socket. In x_net.c : sys_addpollfn(sockfd, (t_fdpollfn)socketreceiver_read, y); socketreceiver_read is in s_inter.c: void socketreceiver_read(t_socketreceiver *x, int fd) sys_addpollfunction schedules the function to be called each pass through Pd's main loop. Martin If that is the case, then it seems the bug lies elsewhere but is there nonetheless. The clock_delay workaround has fixed this in pd-l2ork permanently and I am yet to experience gui freeze that has been plaguing our setup way too often before the said workaround. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
Here's a guess... if incoming (vanilla) netreceive traffic is swamping Pd, then since Pd prioritizes input from GUI above output back to GUI, the output never gets scheduled. If that were happening, you'd see the windows freeze but still be able to send Pd events from the GUI (hitting buttons in the patch, for instance.) I haven't recreated the situation myself yet, but will do that at some point to try to get a better idea. At any rate, it's likely that incoming net traffic is also getting dropped - not a good scenario. Ideally there should be a some way for Pd to sense that so that the patch could send out requests to slow the flow down before it starts dropping packets. In the meantime, a possible workaround: send occasional pings to the receiving Pd, hav ethe Pd patch echo the pings back to tne sending patch, and have the sending patch not allow more than a certain number of other messages go out between pings. cheers Miller On Sun, Aug 07, 2011 at 11:56:45AM -0400, Ivica Ico Bukvic wrote: If you are indeed talking about vanilla netsend and netreceive, the poll function is called during pd's main loop, not when something arrives at the socket. In x_net.c : sys_addpollfn(sockfd, (t_fdpollfn)socketreceiver_read, y); socketreceiver_read is in s_inter.c: void socketreceiver_read(t_socketreceiver *x, int fd) sys_addpollfunction schedules the function to be called each pass through Pd's main loop. Martin If that is the case, then it seems the bug lies elsewhere but is there nonetheless. The clock_delay workaround has fixed this in pd-l2ork permanently and I am yet to experience gui freeze that has been plaguing our setup way too often before the said workaround. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
On Sun, 7 Aug 2011, Miller Puckette wrote: Here's a guess... if incoming (vanilla) netreceive traffic is swamping Pd, then since Pd prioritizes input from GUI above output back to GUI, the output never gets scheduled. If that were happening, you'd see the windows freeze but still be able to send Pd events from the GUI (hitting buttons in the patch, for instance.) That sounds like the same symptom as when there is an extra unquoted open-brace. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
On Aug 7, 2011, at 5:19 PM, Mathieu Bouchard wrote: On Sun, 7 Aug 2011, Miller Puckette wrote: Here's a guess... if incoming (vanilla) netreceive traffic is swamping Pd, then since Pd prioritizes input from GUI above output back to GUI, the output never gets scheduled. If that were happening, you'd see the windows freeze but still be able to send Pd events from the GUI (hitting buttons in the patch, for instance.) That sounds like the same symptom as when there is an extra unquoted open-brace. What would it take to convince you to port your DD escaping code to Pd 0.43? :-D :-D :-D .hc Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
On Wed, 3 Aug 2011, IOhannes m zmoelnig wrote: PS: just for clarity: i'm talking about the [netreceive] object in Pd-vanilla; things might be different in Pd-extended and other networking objects. e.g. iemnet will receive the data asynchronously, but then will pass it to Pd synchronously. I feel like we're not all using the same meanings for «synchronous» and «asynchronous». ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-08-02 22:44, Ivica Ico Bukvic wrote: This is however not the case whenever you have a high throughput traffic that arrives form various sources at unexpected intervals as the netreceive sends out its message whenever it receives it rather than waiting for the scheduler interrupt which means when that message lands in the middle of another tcl/tk message that is currently being parsed to be sent out to gui (something that commonly is unlikely to take place when the throughput is low but becomes increasingly more likely as the network traffic increases), you end up with garbage output that results in syntax error on the tcl/tk side and thus tcl/tk becomes unresponsive. This is best observed if you monitor pd-tcl/tk activity with debugger on. hmm, i don't know where you get this idea from, but to me, the code of Pd's networking infrastructure looks, as if a) all incoming traffic was polled for in the main thread b) all output of this traffic (to the Pd-patch) was propery protected by sys_lock() this basically contradicts your claims of network data being asynchronously fed into Pd's messaging cycle. of course there might be some bugs in the code, but i rather doubt that. fgmasdr IOhannes PS: just for clarity: i'm talking about the [netreceive] object in Pd-vanilla; things might be different in Pd-extended and other networking objects. e.g. iemnet will receive the data asynchronously, but then will pass it to Pd synchronously. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk44+RQACgkQkX2Xpv6ydvQk8gCfVOPQWNCAZLGrZacFetCKe4Lk M68An1+DhFuYETKGS+nUl+l/mBJRwjdn =++Nt -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
hmm, i don't know where you get this idea from, but to me, the code of Pd's networking infrastructure looks, as if a) all incoming traffic was polled for in the main thread b) all output of this traffic (to the Pd-patch) was propery protected by sys_lock() I am honestly not that familiar with this low-level aspect of pd. What I am however aware of is that the poll function responsible for receiving message (meaning when it arrives at the socket) inside netreceive immediately dispatches it to pd and its polling is linked not to pd's main loop but to the moment when the socket has received a packet which appears to be a part of any basic network socket example code available online and as far as I can see, I did not notice any relationship between its polling intervals and Pd's main loop. FWIW, The only difference in my implementation is that the received messages are forwarded to pd via clock_delay(0) which has fixed all such occurrences inside L2Ork which is quite network traffic heavy, and apparently has resolved problems for others as well. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
hmm, i don't know where you get this idea from, but to me, the code of Pd's networking infrastructure looks, as if a) all incoming traffic was polled for in the main thread b) all output of this traffic (to the Pd-patch) was propery protected by sys_lock() I am honestly not that familiar with this low-level aspect of pd. What I am however aware of is that the poll function responsible for receiving message (meaning when it arrives at the socket) inside netreceive immediately dispatches it to pd and its polling is linked not to pd's main loop but to the moment when the socket has received a packet which appears to be a part of any basic network socket example code available online and as far as I can see, I did not notice any relationship between its polling intervals and Pd's main loop. If you are indeed talking about vanilla netsend and netreceive, the poll function is called during pd's main loop, not when something arrives at the socket. In x_net.c : sys_addpollfn(sockfd, (t_fdpollfn)socketreceiver_read, y); socketreceiver_read is in s_inter.c: void socketreceiver_read(t_socketreceiver *x, int fd) sys_addpollfunction schedules the function to be called each pass through Pd's main loop. Martin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
Deffinitely having the GUI frozen after a while shouldn't happen...I don't get any error, it just freezes after some network activity.I use a number of network objects, besides netsend (udpreceive, mr peach osc objects...). I whish I could track/debug what's the cause :( Thanks anyway...!Josep M Date: Mon, 1 Aug 2011 15:25:30 -0400 Subject: Re: [PD] netsend/netreceive + GUI bug From: santorcuat...@gmail.com To: i...@vt.edu CC: jepp...@hotmail.com; pd-list@iem.at Hello, IMHE, netsend works perfectly in Linux, OSX and Windows, the only thing to keep in mind is the ip of the computer to control and call the variables are equal, they are sent and those received. BR José 2011/8/1 i...@vt.edu Quoting Jeppi Jeppi jepp...@hotmail.com: Hi,I would like to know whether there are any fixes to the current oddities regarding netsend/netreceive usage and GUI updates. When receiving massive OSC data from other laptops, our central patch gets frozen (only the GUI, it still works but it is unusable). This is a rather serious bug which prevents absolutely pd networking... Ivica's seems disis_netsend to solve it rather well, but it's only for linux. Any plans to incorporate such fixes into the canonical version?Thanks in advance!Josep M Those externals should work on all versions of Pd as they in and of themselves are not linux-specific. HTH Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- http://arselectronicachile.blogspot.com http://comunicacionnativa.blogspot.com/ http://www.myspace.com/santorcuato ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
Hello, IMHE, netsend works perfectly in Linux, OSX and Windows, the only thing to keep in mind is the ip of the computer to control and call the variables are equal, they are sent and those received. BR José This is however not the case whenever you have a high throughput traffic that arrives form various sources at unexpected intervals as the netreceive sends out its message whenever it receives it rather than waiting for the scheduler interrupt which means when that message lands in the middle of another tcl/tk message that is currently being parsed to be sent out to gui (something that commonly is unlikely to take place when the throughput is low but becomes increasingly more likely as the network traffic increases), you end up with garbage output that results in syntax error on the tcl/tk side and thus tcl/tk becomes unresponsive. This is best observed if you monitor pd-tcl/tk activity with debugger on. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
Quoting Jeppi Jeppi jepp...@hotmail.com: Hi,I would like to know whether there are any fixes to the current oddities regarding netsend/netreceive usage and GUI updates. When receiving massive OSC data from other laptops, our central patch gets frozen (only the GUI, it still works but it is unusable). This is a rather serious bug which prevents absolutely pd networking... Ivica's seems disis_netsend to solve it rather well, but it's only for linux. Any plans to incorporate such fixes into the canonical version?Thanks in advance!Josep M Those externals should work on all versions of Pd as they in and of themselves are not linux-specific. HTH Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
Hello, IMHE, netsend works perfectly in Linux, OSX and Windows, the only thing to keep in mind is the ip of the computer to control and call the variables are equal, they are sent and those received. BR José 2011/8/1 i...@vt.edu Quoting Jeppi Jeppi jepp...@hotmail.com: Hi,I would like to know whether there are any fixes to the current oddities regarding netsend/netreceive usage and GUI updates. When receiving massive OSC data from other laptops, our central patch gets frozen (only the GUI, it still works but it is unusable). This is a rather serious bug which prevents absolutely pd networking... Ivica's seems disis_netsend to solve it rather well, but it's only for linux. Any plans to incorporate such fixes into the canonical version?Thanks in advance!Josep M Those externals should work on all versions of Pd as they in and of themselves are not linux-specific. HTH Best wishes, Ico __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list -- http://arselectronicachile.blogspot.com http://comunicacionnativa.blogspot.com/ http://www.myspace.com/santorcuato ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netsend/netreceive + GUI bug
Hi, me again, IMHE, freezes when doing something wrong ... ie error in the ip or send a variable that does not exist, generally functions well, now, you could try with mr peach osc. José El 1 de agosto de 2011 15:25, José Luis Santorcuato Tapia santorcuat...@gmail.com escribió: Hello, IMHE, netsend works perfectly in Linux, OSX and Windows, the only thing to keep in mind is the ip of the computer to control and call the variables are equal, they are sent and those received. BR José 2011/8/1 i...@vt.edu Quoting Jeppi Jeppi jepp...@hotmail.com: Hi,I would like to know whether there are any fixes to the current oddities regarding netsend/netreceive usage and GUI updates. When receiving massive OSC data from other laptops, our central patch gets frozen (only the GUI, it still works but it is unusable). This is a rather serious bug which prevents absolutely pd networking... Ivica's seems disis_netsend to solve it rather well, but it's only for linux. Any plans to incorporate such fixes into the canonical version?Thanks in advance!Josep M Those externals should work on all versions of Pd as they in and of themselves are not linux-specific. HTH Best wishes, Ico __**_ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list -- http://arselectronicachile.blogspot.com http://comunicacionnativa.blogspot.com/ http://www.myspace.com/santorcuato -- http://arselectronicachile.blogspot.com http://comunicacionnativa.blogspot.com/ http://www.myspace.com/santorcuato ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] graph on parent bug and guis not updating
btw, the white toggle in the middle is the new display toggle. 2011/7/25 Alexandre Torres Porres por...@gmail.com hey people, I have this phase vocoder patch, some out there use it, and I'm updating it. check it at http://sites.google.com/site/porres/4b.zip One thing I wanted to do is to have a toggle to turn on/off the display of the recorded buffer/table. I done it alright, but with some problems. First, there is this kind of annoying bug that I'm not sure if it's been raised here. If the table was off the graph on parent area, it'd still be displayed on the parent patch. I had to force it to not be visible even outside the area, and it worked, but anyway, that's a bug... let me know if you need more info about it. Now, the other thing is that the sliders and the table/buffer will not properly work or display the values. I have to toggle on/off the buffer so it gets updated... but the sliders just die... and keep dead even if when I reopen it. But if I open the subpatch they come back to life! Well, I'm not sure now if the table was supposed to be updated on display in realtime when It's kinda big like this, is it? but none of the rest should be happening, right? thanks cheers Alex ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] graph on parent bug and guis not updating
oh, and the same issue actually happens on Pd-Vanilla as well 2011/7/25 Alexandre Torres Porres por...@gmail.com btw, the white toggle in the middle is the new display toggle. 2011/7/25 Alexandre Torres Porres por...@gmail.com hey people, I have this phase vocoder patch, some out there use it, and I'm updating it. check it at http://sites.google.com/site/porres/4b.zip One thing I wanted to do is to have a toggle to turn on/off the display of the recorded buffer/table. I done it alright, but with some problems. First, there is this kind of annoying bug that I'm not sure if it's been raised here. If the table was off the graph on parent area, it'd still be displayed on the parent patch. I had to force it to not be visible even outside the area, and it worked, but anyway, that's a bug... let me know if you need more info about it. Now, the other thing is that the sliders and the table/buffer will not properly work or display the values. I have to toggle on/off the buffer so it gets updated... but the sliders just die... and keep dead even if when I reopen it. But if I open the subpatch they come back to life! Well, I'm not sure now if the table was supposed to be updated on display in realtime when It's kinda big like this, is it? but none of the rest should be happening, right? thanks cheers Alex ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
On 2010-07-08 01:09, Hans-Christoph Steiner wrote: I guess there should be a third inlet for the signals? I see something like this: STDIN signals process name | || | || [process /usr/sbin/httpd] | || | || STDOUT STDERR status messages, like PID, current process name, state, etc. hmm, iirc process name is there mainly to override the process given as the argument. sending a new process name (e.g. /usr/sbin/apache2) into the last inlet surely won't start the new process, would it? for me starting a new process seems to be a very hot action. then i don't see a reason why we need different inlets for process name and signals, as both are there to control the the current/future process from outside. so i would basically simplify this to the attached interface. as for sending signals: even though i like signals very much, there is no such concept on w32 (or at least it is not readily available for the little programmer). personally i would hate to have the 5th object for the same task that is still highly platform dependent. #N canvas 277 80 961 366 10; #X msg 70 32 run /usr/sbin/apache2; #X obj 135 233 print STDOUT; #X obj 200 207 print STDERR; #X msg 200 151 1 2 3; #X text 253 149 - STDIN; #X obj 70 333 route PID status; #X text 83 311 process information; #X text 235 33 start a new process (stop/detach the old one first) ; #X msg 89 64 signal 9; #X text 157 63 send signal 9 (KILL) to the process; #X obj 70 184 process /usr/bin/sh; #X text 383 108 the 1st inlet is reserved for meta-controlling the process (starting \, stopping \, suspending \, ...); #X text 390 218 the 1st outlet is reserved for meta-information from the process (PID \, status \, ...); #X text 389 161 the other inlets are reserved for communication TO the process (there's only one more inlet that is connected to the process's STDIN); #X text 392 260 the other outlets are reserved for communication FROM the process (there's an outlet connected to the process's STDOUT and an outlet connected to the process's STDERR); #X connect 0 0 10 0; #X connect 3 0 10 1; #X connect 8 0 10 0; #X connect 10 0 5 0; #X connect 10 1 1 0; #X connect 10 2 2 0; smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
On Jul 8, 2010, at 3:30 AM, IOhannes m zmoelnig wrote: On 2010-07-08 01:09, Hans-Christoph Steiner wrote: I guess there should be a third inlet for the signals? I see something like this: STDIN signals process name | || | || [process /usr/sbin/httpd] | || | || STDOUT STDERR status messages, like PID, current process name, state, etc. hmm, iirc process name is there mainly to override the process given as the argument. sending a new process name (e.g. /usr/sbin/apache2) into the last inlet surely won't start the new process, would it? for me starting a new process seems to be a very hot action. then i don't see a reason why we need different inlets for process name and signals, as both are there to control the the current/ future process from outside. so i would basically simplify this to the attached interface. as for sending signals: even though i like signals very much, there is no such concept on w32 (or at least it is not readily available for the little programmer). personally i would hate to have the 5th object for the same task that is still highly platform dependent. Your example seems backwards to me. STDIN is definitely a hot action, and most likely the inlet that is going to be used the most. I imagine many users would never change the program that is being run. STDOUT will most likely be the main outlet used, i.e the result, so that really should be the first outlet. The process information is meta/info/status stuff like in [hid], [comport], etc. so it should be the right outlet like them. I could see combining the signal and process inlets into one second meta inlet, but it seems to me that since there are just two messages (run and signal), why not just make each have their own inlet and spare the patcher from having to build up messages as much. .hc 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2, by Mohja Kahf ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
personally i would hate to have the 5th object for the same task that is still highly platform dependent. I understand what you mean, but also understand that making such cross-platform object would require a large amount of effort or at least a group of people that can contribute for the different OSs out there. The fun side of being open source is also this one. As Ive said before I can try to help with this object from 16th up, but even so I'd never would do it for Windows, simply because I have no interest in it :) But once again, the beauty of open source is that if a thing is readable enough and easily extensible, it then can be altered to fit more operating systems. (beware that the differences between OSs will show at some point... that's something to consider*). * i.e.: I have no clue on how to run a process on the background of the shell in Win. Nor how to kill a process, and so forth... On Thu, Jul 8, 2010 at 8:30 AM, IOhannes m zmoelnig zmoel...@iem.at wrote: personally i would hate to have the 5th object for the same task that is still highly platform dependent. -- Pedro Lopes contacto: j...@radiozero.pt website: http://web.ist.utl.pt/Pedro.Lopes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
On 2010-07-08 18:24, Hans-Christoph Steiner wrote: Your example seems backwards to me. STDIN is definitely a hot action, STDIN is far from being a hot action definitely. it's entirely at the process's disposition, whether it will do something with the stdin or not. anyhow, whether it's backward or not depends on your pov. if you see [process] as an object that interacts with system-processes, then i think my approach is straight-forward. if you think of the object as being a representation of the process, and thus the process being just another Pd-object, then my approach looks backwards. it seems like I (IOhannes) see this object as an interface to the external world (ihde's external tool), whereas you (Hans-Christoph) see the ibject as a way to internalize functionality into Pd (ihde's tool as an extension) this basically means, that the question is not solveable :-) and most likely the inlet that is going to be used the most. or not. i prefer to not make too many assumptions about what the users are going to do, but rather try to make the interface consistent, regardless of what they are actually doing. i guess, people are using [shell] to startup an small script. and startup the script again. and again, not worrying to much about the output (mainly due to the fact how stdout/stderr are handled with [shell]). if [process] is gooing to replace [shell], then people are probably going to use the meta-inlets and -outlets most. so... anyhow, the proposed object is merely an extension to the current [shell]. you could even write an abstraction with the current [shell] and some small wrapper-script that is more or less doing the same as proposed. it probably would be a good idea to keep compatibility. I imagine many users would never change the program that is being run. STDOUT will most likely be the main outlet used, i.e the result, so that really should be the first outlet. The process information is meta/info/status stuff like in [hid], [comport], etc. so it should be the right outlet like them. i'm thinking more in terms of extensibility. it seems like we all agree on the meta-outlet being a [route]able-message. i think of the stdout and stderr as being messages without a given selector. putting the stderr and stdout before the meta, makes it hard to add new backtalk channels (e.g. pipes). its similar to [route] where the reject-outlet moves to the right, whenever you add new selectors. it's one of the behaviours that annoyed me most. (so that's an argument for both sides) I could see combining the signal and process inlets into one second meta inlet, but it seems to me that since there are just two messages (run and signal), why not just make each have their own inlet and spare the patcher from having to build up messages as much. hmm, what's harder to do: create one of those fuzzy messages, or fiddling with the tiny iolets? personally i think the former is simpler to do. in addition, i think that the former is simpler to read as well, as it is an implicit documentation) anyhow, i'm still convinced that creating and deleting a process (the guts of this object) is hotter than sending data to it, which it might or might not ignore. fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
On 2010-07-08 18:27, Pedro Lopes wrote: The fun side of being open source is also this one. As Ive said before I can try to help with this object from 16th up, but even so I'd never would do it for Windows, simply because I have no interest in it :) But once again, the beauty of open source is that if a thing is readable enough and easily extensible, it then can be altered to fit more operating systems. (beware that the differences between OSs will show at some point... that's something to consider*). * i.e.: I have no clue on how to run a process on the background of the shell in Win. Nor how to kill a process, and so forth... me neither. but i do know that there are no signals in w32 as we know them from un*x. if an object is designed around features not available on a certain platform, chances are low that the object will ever be available on this very platform, regardless of whether there is a team of experts waiting to port it or not. fmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
We have [ggee/shell], [motex/system], [flatspace/popen], and [moonlib/ popen], so I see little reason to make yet another or a replacement. Instead, the idea that is most interesting to me is to make an object that allows you to easily run externals processes as if they were pd objects. That's why STDIN, STDOUT, and STDERR would be the focus. .hc On Jul 8, 2010, at 12:48 PM, IOhannes m zmoelnig wrote: On 2010-07-08 18:24, Hans-Christoph Steiner wrote: Your example seems backwards to me. STDIN is definitely a hot action, STDIN is far from being a hot action definitely. it's entirely at the process's disposition, whether it will do something with the stdin or not. anyhow, whether it's backward or not depends on your pov. if you see [process] as an object that interacts with system- processes, then i think my approach is straight-forward. if you think of the object as being a representation of the process, and thus the process being just another Pd-object, then my approach looks backwards. it seems like I (IOhannes) see this object as an interface to the external world (ihde's external tool), whereas you (Hans-Christoph) see the ibject as a way to internalize functionality into Pd (ihde's tool as an extension) this basically means, that the question is not solveable :-) and most likely the inlet that is going to be used the most. or not. i prefer to not make too many assumptions about what the users are going to do, but rather try to make the interface consistent, regardless of what they are actually doing. i guess, people are using [shell] to startup an small script. and startup the script again. and again, not worrying to much about the output (mainly due to the fact how stdout/stderr are handled with [shell]). if [process] is gooing to replace [shell], then people are probably going to use the meta-inlets and -outlets most. so... anyhow, the proposed object is merely an extension to the current [shell]. you could even write an abstraction with the current [shell] and some small wrapper-script that is more or less doing the same as proposed. it probably would be a good idea to keep compatibility. I imagine many users would never change the program that is being run. STDOUT will most likely be the main outlet used, i.e the result, so that really should be the first outlet. The process information is meta/info/ status stuff like in [hid], [comport], etc. so it should be the right outlet like them. i'm thinking more in terms of extensibility. it seems like we all agree on the meta-outlet being a [route]able- message. i think of the stdout and stderr as being messages without a given selector. putting the stderr and stdout before the meta, makes it hard to add new backtalk channels (e.g. pipes). its similar to [route] where the reject-outlet moves to the right, whenever you add new selectors. it's one of the behaviours that annoyed me most. (so that's an argument for both sides) I could see combining the signal and process inlets into one second meta inlet, but it seems to me that since there are just two messages (run and signal), why not just make each have their own inlet and spare the patcher from having to build up messages as much. hmm, what's harder to do: create one of those fuzzy messages, or fiddling with the tiny iolets? personally i think the former is simpler to do. in addition, i think that the former is simpler to read as well, as it is an implicit documentation) anyhow, i'm still convinced that creating and deleting a process (the guts of this object) is hotter than sending data to it, which it might or might not ignore. fgmasdr IOhannes All information should be free. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
Yes of course, there's a lot of wheels out there, no need to reinvent it. Just combine a bit with the possibility of sending signals, STDIN, STDOUT, status and STDERR and we get ourselves a new car. On Thu, Jul 8, 2010 at 6:03 PM, Hans-Christoph Steiner h...@at.or.atwrote: We have [ggee/shell], [motex/system], [flatspace/popen], and [moonlib/popen], so I see little reason to make yet another or a replacement. Instead, the idea that is most interesting to me is to make an object that allows you to easily run externals processes as if they were pd objects. That's why STDIN, STDOUT, and STDERR would be the focus. .hc On Jul 8, 2010, at 12:48 PM, IOhannes m zmoelnig wrote: On 2010-07-08 18:24, Hans-Christoph Steiner wrote: Your example seems backwards to me. STDIN is definitely a hot action, STDIN is far from being a hot action definitely. it's entirely at the process's disposition, whether it will do something with the stdin or not. anyhow, whether it's backward or not depends on your pov. if you see [process] as an object that interacts with system-processes, then i think my approach is straight-forward. if you think of the object as being a representation of the process, and thus the process being just another Pd-object, then my approach looks backwards. it seems like I (IOhannes) see this object as an interface to the external world (ihde's external tool), whereas you (Hans-Christoph) see the ibject as a way to internalize functionality into Pd (ihde's tool as an extension) this basically means, that the question is not solveable :-) and most likely the inlet that is going to be used the most. or not. i prefer to not make too many assumptions about what the users are going to do, but rather try to make the interface consistent, regardless of what they are actually doing. i guess, people are using [shell] to startup an small script. and startup the script again. and again, not worrying to much about the output (mainly due to the fact how stdout/stderr are handled with [shell]). if [process] is gooing to replace [shell], then people are probably going to use the meta-inlets and -outlets most. so... anyhow, the proposed object is merely an extension to the current [shell]. you could even write an abstraction with the current [shell] and some small wrapper-script that is more or less doing the same as proposed. it probably would be a good idea to keep compatibility. I imagine many users would never change the program that is being run. STDOUT will most likely be the main outlet used, i.e the result, so that really should be the first outlet. The process information is meta/info/status stuff like in [hid], [comport], etc. so it should be the right outlet like them. i'm thinking more in terms of extensibility. it seems like we all agree on the meta-outlet being a [route]able-message. i think of the stdout and stderr as being messages without a given selector. putting the stderr and stdout before the meta, makes it hard to add new backtalk channels (e.g. pipes). its similar to [route] where the reject-outlet moves to the right, whenever you add new selectors. it's one of the behaviours that annoyed me most. (so that's an argument for both sides) I could see combining the signal and process inlets into one second meta inlet, but it seems to me that since there are just two messages (run and signal), why not just make each have their own inlet and spare the patcher from having to build up messages as much. hmm, what's harder to do: create one of those fuzzy messages, or fiddling with the tiny iolets? personally i think the former is simpler to do. in addition, i think that the former is simpler to read as well, as it is an implicit documentation) anyhow, i'm still convinced that creating and deleting a process (the guts of this object) is hotter than sending data to it, which it might or might not ignore. fgmasdr IOhannes All information should be free. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Pedro Lopes contacto: j...@radiozero.pt website: http://web.ist.utl.pt/Pedro.Lopes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
On Thu, 8 Jul 2010, IOhannes m zmoelnig wrote: On 2010-07-08 18:24, Hans-Christoph Steiner wrote: Your example seems backwards to me. STDIN is definitely a hot action, STDIN is far from being a hot action definitely. it's entirely at the process's disposition, whether it will do something with the stdin or not. It depends what one means by hot. Miller's Pd Intro doesn't develop the concept of hotness sufficiently enough to make some important distinctions, and this is what we are stumbling upon in this case. I realise now that I have tended to ignore Miller's definition in favour of my own intuitive concepts. I would call hot any message that goes beyond modifying the contents of the object, be it outputting by outlets, writing to a file, etc. But it still doesn't explain things like whether displaying something on screen can be considered a hot action. Perhaps hot vs cold is insufficient and we should use 3 or 4 words instead of 2. anyhow, whether it's backward or not depends on your pov. if you see [process] as an object that interacts with system-processes, then i think my approach is straight-forward. if you think of the object as being a representation of the process, and thus the process being just another Pd-object, then my approach looks backwards. That change of perspective is related to what I mean, too. In the end it depends on which border-crossings constitute the hot concept : if I only do sed s/foo/bar/ with stdin and stdout, I could call it cold from the perspective of whether inputting causes an immediate outputting, and then I'd say cold. But if I consider the overall use of that object over time, inlet messages eventually cause the outlet messages to be produced (albeit with a different timing), which may be called hot in the context of that patch, or cold in the context of the patch containing that patch (depending on whether those messages reach an [outlet]). And then if I do sed s/foo/bar/ /tmp/bar I'm doing something that can be considered hot or cold for various reasons including who will look at /tmp/bar, and what it is that we call an output. i prefer to not make too many assumptions about what the users are going to do, but rather try to make the interface consistent, regardless of what they are actually doing. do you have ideas for which words we could introduce in documentation, to replace the ambiguïty and insufficiency of the hot concept ? that's a topic I'm getting quite interested in. going to use the meta-inlets and -outlets most. so... Excuse me, what's a meta-inlet ? it seems like we all agree on the meta-outlet being a [route]able-message. which messages are not [route]able ? i think of the stdout and stderr as being messages without a given selector. what is a message without a selector ? Pd does not know this concept. And btw, why wouldn't we have this swiss-army [process] thingy work with byte values just like mrpeach's socket thingies would do ?... Do you think it would be natural, that the most flexible shell-tool would be in sync with the most flexible network-tools, for things as similar to each other as sockets and pipes are ? _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
I guess there should be a third inlet for the signals? I see something like this: STDIN signals process name | || | || [process /usr/sbin/httpd] | || | || STDOUT STDERR status messages, like PID, current process name, state, etc. .hc On Jul 4, 2010, at 12:04 PM, Pedro Lopes wrote: Exactly my point. Having a kill inlet or a kill message. I can make some prototypes from the 16th forth, nothing till then... work comes first! On Sun, Jul 4, 2010 at 3:56 PM, Mathieu Bouchard ma...@artengine.ca wrote: at. Make sure you add something for the child process ID, and have a kill (or general signal) feature. -- Pedro Lopes contacto: j...@radiozero.pt website: http://web.ist.utl.pt/Pedro.Lopes I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. --Bjarne Stroustrup (creator of C++) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
On Thu, 1 Jul 2010, Hans-Christoph Steiner wrote: I am thinking of the ideal version of this, an object that would give you an inlet for STDIN then two outlets for STDOUT and STDERR, plus a status outlet and an inlet to set what to run. It could be something like this: [process /usr/bin/python] Yes, it's a good idea. I sometimes dream of things like that. Make sure you add something for the child process ID, and have a kill (or general signal) feature. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
Exactly my point. Having a kill inlet or a kill message. I can make some prototypes from the 16th forth, nothing till then... work comes first! On Sun, Jul 4, 2010 at 3:56 PM, Mathieu Bouchard ma...@artengine.ca wrote: at. Make sure you add something for the child process ID, and have a kill (or general signal) feature. -- Pedro Lopes contacto: j...@radiozero.pt website: http://web.ist.utl.pt/Pedro.Lopes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
#!/bin/bash echo this goes to stdout echo this goes to stderr 12 (Which should have been obvious from the familiar pd -stderr 21) Yep I use a similar trick in UNIX find, like trying to find .pd files: - find / -name *.pd* -type f -print 2/dev/null I am thinking of the ideal version of this, an object that would give you an inlet for STDIN then two outlets for STDOUT and STDERR, plus a status outlet and an inlet to set what to run. It could be something like this: [process /usr/bin/python] Then you could send python bits to it via the first inlet, and receive the reply via the outlets. So something like a cleaner [shell]. NIce hc. That's an interesting object, sending messages in a simple way to a shell process running in the background should be fairly easy. Just didn't get what you mean by status outlet.. best regards, Pedro -- Pedro Lopes contacto: j...@radiozero.pt website: http://web.ist.utl.pt/Pedro.Lopes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
On Jul 2, 2010, at 3:47 AM, Pedro Lopes wrote: #!/bin/bash echo this goes to stdout echo this goes to stderr 12 (Which should have been obvious from the familiar pd -stderr 21) Yep I use a similar trick in UNIX find, like trying to find .pd files: - find / -name *.pd* -type f -print 2/dev/null I am thinking of the ideal version of this, an object that would give you an inlet for STDIN then two outlets for STDOUT and STDERR, plus a status outlet and an inlet to set what to run. It could be something like this: [process /usr/bin/python] Then you could send python bits to it via the first inlet, and receive the reply via the outlets. So something like a cleaner [shell]. NIce hc. That's an interesting object, sending messages in a simple way to a shell process running in the background should be fairly easy. Just didn't get what you mean by status outlet.. Want to implement it? :-D The status outlet would give you info like the name of the process running, whether its still running, etc. .hc Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
It could also be interesting to kill the process from pd. A bit of kill scripting is easy. About implementing, I can try to sketch something out.. but nothing earlier than the 16th... I have a deliverable to get ready until then! :( Best regards, Pedro On Fri, Jul 2, 2010 at 9:42 PM, Hans-Christoph Steiner h...@at.or.atwrote: On Jul 2, 2010, at 3:47 AM, Pedro Lopes wrote: #!/bin/bash echo this goes to stdout echo this goes to stderr 12 (Which should have been obvious from the familiar pd -stderr 21) Yep I use a similar trick in UNIX find, like trying to find .pd files: - find / -name *.pd* -type f -print 2/dev/null I am thinking of the ideal version of this, an object that would give you an inlet for STDIN then two outlets for STDOUT and STDERR, plus a status outlet and an inlet to set what to run. It could be something like this: [process /usr/bin/python] Then you could send python bits to it via the first inlet, and receive the reply via the outlets. So something like a cleaner [shell]. NIce hc. That's an interesting object, sending messages in a simple way to a shell process running in the background should be fairly easy. Just didn't get what you mean by status outlet.. Want to implement it? :-D The status outlet would give you info like the name of the process running, whether its still running, etc. .hc Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs -- Pedro Lopes contacto: j...@radiozero.pt website: http://web.ist.utl.pt/Pedro.Lopes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
On Thu, Jul 1, 2010 at 8:26 PM, Kim Cascone k...@anechoicmedia.com wrote: I like having the outlet on [shell] so I can pipe data to the console Yes, and moreover that system seems to freeze pd interface until you kill the process. Does it happen to you too? husk/luca ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
I am thinking of the ideal version of this, an object that would give you an inlet for STDIN then two outlets for STDOUT and STDERR, plus a status outlet and an inlet to set what to run. It could be something like this: [process /usr/bin/python] Then you could send python bits to it via the first inlet, and receive the reply via the outlets. So something like a cleaner [shell]. .hc On Jul 1, 2010, at 2:25 PM, Kim Cascone wrote: I like having the outlet on [shell] so I can pipe data to the console Hans-Christoph Steiner wrote: motex/system works for me: .hc On Jun 24, 2010, at 6:58 PM, Kim Cascone wrote: I send the following message to both the [popen] and the [shell] externals: [cd /usr/lib/pd/extra ls -al ~/Desktop/foobar.txt] when sent to [popen] it crashes Pd but sending it to [shell] worked fine below is the crash report (pd -stderr) after sending it to [popen] FYI: I got rid of the [moonlib] version of [popen] as well as its help file as you can see the flatspace one is being loaded === tried /usr/lib/pd/extra/flatspace/popen.pd_linux and succeeded *** buffer overflow detected ***: pd terminated === Backtrace: = /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb76deef8] /lib/tls/i686/cmov/libc.so.6[0xb76dd000] /lib/tls/i686/cmov/libc.so.6[0xb76dc28d] /usr/lib/pd/extra/flatspace/popen.pd_linux[0xb70e2b9f] pd(pd_typedmess+0x2ab)[0x80b71db] === Memory map: 08048000-08111000 r-xp 08:03 35809 /usr/bin/pd 08111000-08112000 r--p 000c8000 08:03 35809 /usr/bin/pd 08112000-08113000 rw-p 000c9000 08:03 35809 /usr/bin/pd 08113000-0852 rw-p 08113000 00:00 0 09f9f000-0a089000 rw-p 09f9f000 00:00 0 [heap] b42f3000-b4348000 r-xp 08:03 34905 /usr/lib/ liboil-0.3.so.0.3.0 b4348000-b4349000 r--p 00055000 08:03 34905 /usr/lib/ liboil-0.3.so.0.3.0 b4349000-b436 rw-p 00056000 08:03 34905 /usr/lib/ liboil-0.3.so.0.3.0 b436-b4362000 rw-p b436 00:00 0 b4362000-b4366000 r-xp 08:03 482419 /lib/libattr.so. 1.1.0 b4366000-b4367000 r--p 3000 08:03 482419 /lib/libattr.so. 1.1.0 b4367000-b4368000 rw-p 4000 08:03 482419 /lib/libattr.so. 1.1.0 b4368000-b436b000 r-xp 08:03 482538 /lib/libuuid.so.1.2 b436b000-b436c000 r--p 2000 08:03 482538 /lib/libuuid.so.1.2 b436c000-b436d000 rw-p 3000 08:03 482538 /lib/libuuid.so.1.2 b436d000-b4405000 r-xp 08:03 34677 /usr/lib/ libxvidcore.so.4.2 b4405000-b440f000 rw-p 00098000 08:03 34677 /usr/lib/ libxvidcore.so.4.2 b440f000-b4479000 rw-p b440f000 00:00 0 b4479000-b4502000 r-xp 08:03 33520 /usr/lib/ libx264.so.68 b4502000-b4504000 rw-p 00088000 08:03 33520 /usr/lib/ libx264.so.68 b4504000-b450b000 rw-p b4504000 00:00 0 b450b000-b4526000 r-xp 08:03 1406274/usr/lib/sse2/ libspeex.so.1.5.0 b4526000-b4527000 r--p 0001a000 08:03 1406274/usr/lib/sse2/ libspeex.so.1.5.0 b4527000-b4528000 rw-p 0001b000 08:03 1406274/usr/lib/sse2/ libspeex.so.1.5.0 b4528000-b4598000 r-xp 08:03 33499 /usr/lib/ libschroedinger-1.0.so.0.2.0 b4598000-b4599000 ---p 0007 08:03 33499 /usr/lib/ libschroedinger-1.0.so.0.2.0 b4599000-b459a000 r--p 0007 08:03 33499 /usr/lib/ libschroedinger-1.0.so.0.2.0 b459a000-b459b000 rw-p 00071000 08:03 33499 /usr/lib/ libschroedinger-1.0.so.0.2.0 b459b000-b45b8000 r-xp 08:03 36726 /usr/lib/ libopenjpeg-2.1.3.0.so b45b8000-b45b9000 r--p 0001c000 08:03 36726 /usr/lib/ libopenjpeg-2.1.3.0.so b45b9000-b45ba000 rw-p 0001d000 08:03 36726 /usr/lib/ libopenjpeg-2.1.3.0.so b45ba000-b45ce000 r-xp 08:03 33583 /usr/lib/ libopencore-amrwb.so.0.1.1 b45ce000-b45cf000 rw-p 00014000 08:03 33583 /usr/lib/ libopencore-amrwb.so.0.1.1 b45cf000-b45fc000 r-xp 08:03 33581 /usr/lib/ libopencore-amrnb.so.0.1.1 b45fc000-b45fd000 rw-p 0002c000 08:03 33581 /usr/lib/ libopencore-amrnb.so.0.1.1 b45fd000-b4609000 r-xp 08:03 35799 /usr/lib/ libgsm.so.1.0.12 b4609000-b460a000 rw-p b000 08:03 35799 /usr/lib/ libgsm.so.1.0.12 b460a000-b4645000 r-xp 08:03 36722 /usr/lib/ libfaad.so.0.0.0 b4645000-b4646000 ---p 0003b000 08:03 36722 /usr/lib/ libfaad.so.0.0.0 b4646000-b4647000 r--p 0003b000 08:03 36722 /usr/lib/ libfaad.so.0.0.0 b4647000-b464a000 rw-p 0003c000 08:03 36722 /usr/lib/ libfaad.so.0.0.0 b464a000-b4658000 r-xp 08:03 33922 /usr/lib/ libfaac.so.0.0.0 b4658000-b465b000 rw-p d000 08:03 33922 /usr/lib/ libfaac.so.0.0.0 b465b000-b46eb000 r-xp 08:03 36716 /usr/lib/ libdirac_encoder.so.0.1.0 b46eb000-b46ed000 rw-p 0009 08:03 36716 /usr/lib/ libdirac_encoder.so.0.1.0 b46ed000-b46ee000 rw-p b46ed000 00:00 0 b46ee000-b46fd000 r-xp 08:03 409348 /usr/lib/i686/ cmov/libavutil.so.50.16.0 b46fd000-b46fe000
Re: [PD] popen vs shell bug
Husk 00 wrote: On Thu, Jul 1, 2010 at 8:26 PM, Kim Cascone k...@anechoicmedia.com mailto:k...@anechoicmedia.com wrote: I like having the outlet on [shell] so I can pipe data to the console Yes, and moreover that system seems to freeze pd interface until you kill the process. Does it happen to you too? I haven't used [system] but what you describe does happen with [popen] as I indicated in my original post have you had similar troubles using [popen]? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
On Jul 1, 2010, at 2:35 PM, Husk 00 wrote: On Thu, Jul 1, 2010 at 8:26 PM, Kim Cascone k...@anechoicmedia.com wrote: I like having the outlet on [shell] so I can pipe data to the console Yes, and moreover that system seems to freeze pd interface until you kill the process. Does it happen to you too? husk/luca I was trying it using a trailing so that it becomes a background process, and it seems to work ok. .hc Mistrust authority - promote decentralization. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
On Jul 1, 2010, at 3:26 PM, Kim Cascone wrote: Husk 00 wrote: On Thu, Jul 1, 2010 at 8:26 PM, Kim Cascone k...@anechoicmedia.com mailto:k...@anechoicmedia.com wrote: I like having the outlet on [shell] so I can pipe data to the console Yes, and moreover that system seems to freeze pd interface until you kill the process. Does it happen to you too? I haven't used [system] but what you describe does happen with [popen] as I indicated in my original post have you had similar troubles using [popen]? That's the tricky part: ideally the process sent to popen/shell would finish within one Pd timeslice so that it remains deterministic and you know you can rely on the Pd's execution order. I think [shell] spawns a thread for the process, meaning that the reply is non- determinstic, so if you are relying on the reply from that process, you have to do some extra work to handle execution order. For example, just because you send a message to [shell] first, doesn't mean you'll get its reply first. .hc Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
interesting...I tried it by appending to the end of my little script and [popen] still crashed Pd Hans-Christoph Steiner wrote: On Jul 1, 2010, at 2:35 PM, Husk 00 wrote: On Thu, Jul 1, 2010 at 8:26 PM, Kim Cascone k...@anechoicmedia.com mailto:k...@anechoicmedia.com wrote: I like having the outlet on [shell] so I can pipe data to the console Yes, and moreover that system seems to freeze pd interface until you kill the process. Does it happen to you too? husk/luca I was trying it using a trailing so that it becomes a background process, and it seems to work ok. .hc Mistrust authority - promote decentralization. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
On 01/07/10 20:20, Hans-Christoph Steiner wrote: I am thinking of the ideal version of this, an object that would give you an inlet for STDIN then two outlets for STDOUT and STDERR, plus a status outlet and an inlet to set what to run. It could be something like this: [process /usr/bin/python] Then you could send python bits to it via the first inlet, and receive the reply via the outlets. So something like a cleaner [shell]. .hc I had a similar idea once, more along the lines of using Pd for hooking up pipes as a shell: https://code.goto10.org/svn/maximus/2007/pish/ I have no recollection any more of how far I got with that project, so it probably doesn't work let alone build... BTW/OT just yesterday I figured out how to redirect stdout to stderr in bash: #!/bin/bash echo this goes to stdout echo this goes to stderr 12 (Which should have been obvious from the familiar pd -stderr 21) Claude -- http://claudiusmaximus.goto10.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] popen vs shell bug
motex/system works for me: .hc system!.pd Description: Binary data On Jun 24, 2010, at 6:58 PM, Kim Cascone wrote: I send the following message to both the [popen] and the [shell] externals: [cd /usr/lib/pd/extra ls -al ~/Desktop/foobar.txt] when sent to [popen] it crashes Pd but sending it to [shell] worked fine below is the crash report (pd -stderr) after sending it to [popen] FYI: I got rid of the [moonlib] version of [popen] as well as its help file as you can see the flatspace one is being loaded === tried /usr/lib/pd/extra/flatspace/popen.pd_linux and succeeded *** buffer overflow detected ***: pd terminated === Backtrace: = /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb76deef8] /lib/tls/i686/cmov/libc.so.6[0xb76dd000] /lib/tls/i686/cmov/libc.so.6[0xb76dc28d] /usr/lib/pd/extra/flatspace/popen.pd_linux[0xb70e2b9f] pd(pd_typedmess+0x2ab)[0x80b71db] === Memory map: 08048000-08111000 r-xp 08:03 35809 /usr/bin/pd 08111000-08112000 r--p 000c8000 08:03 35809 /usr/bin/pd 08112000-08113000 rw-p 000c9000 08:03 35809 /usr/bin/pd 08113000-0852 rw-p 08113000 00:00 0 09f9f000-0a089000 rw-p 09f9f000 00:00 0 [heap] b42f3000-b4348000 r-xp 08:03 34905 /usr/lib/ liboil-0.3.so.0.3.0 b4348000-b4349000 r--p 00055000 08:03 34905 /usr/lib/ liboil-0.3.so.0.3.0 b4349000-b436 rw-p 00056000 08:03 34905 /usr/lib/ liboil-0.3.so.0.3.0 b436-b4362000 rw-p b436 00:00 0 b4362000-b4366000 r-xp 08:03 482419 /lib/libattr.so.1.1.0 b4366000-b4367000 r--p 3000 08:03 482419 /lib/libattr.so.1.1.0 b4367000-b4368000 rw-p 4000 08:03 482419 /lib/libattr.so.1.1.0 b4368000-b436b000 r-xp 08:03 482538 /lib/libuuid.so.1.2 b436b000-b436c000 r--p 2000 08:03 482538 /lib/libuuid.so.1.2 b436c000-b436d000 rw-p 3000 08:03 482538 /lib/libuuid.so.1.2 b436d000-b4405000 r-xp 08:03 34677 /usr/lib/ libxvidcore.so.4.2 b4405000-b440f000 rw-p 00098000 08:03 34677 /usr/lib/ libxvidcore.so.4.2 b440f000-b4479000 rw-p b440f000 00:00 0 b4479000-b4502000 r-xp 08:03 33520 /usr/lib/libx264.so. 68 b4502000-b4504000 rw-p 00088000 08:03 33520 /usr/lib/libx264.so. 68 b4504000-b450b000 rw-p b4504000 00:00 0 b450b000-b4526000 r-xp 08:03 1406274/usr/lib/sse2/ libspeex.so.1.5.0 b4526000-b4527000 r--p 0001a000 08:03 1406274/usr/lib/sse2/ libspeex.so.1.5.0 b4527000-b4528000 rw-p 0001b000 08:03 1406274/usr/lib/sse2/ libspeex.so.1.5.0 b4528000-b4598000 r-xp 08:03 33499 /usr/lib/ libschroedinger-1.0.so.0.2.0 b4598000-b4599000 ---p 0007 08:03 33499 /usr/lib/ libschroedinger-1.0.so.0.2.0 b4599000-b459a000 r--p 0007 08:03 33499 /usr/lib/ libschroedinger-1.0.so.0.2.0 b459a000-b459b000 rw-p 00071000 08:03 33499 /usr/lib/ libschroedinger-1.0.so.0.2.0 b459b000-b45b8000 r-xp 08:03 36726 /usr/lib/ libopenjpeg-2.1.3.0.so b45b8000-b45b9000 r--p 0001c000 08:03 36726 /usr/lib/ libopenjpeg-2.1.3.0.so b45b9000-b45ba000 rw-p 0001d000 08:03 36726 /usr/lib/ libopenjpeg-2.1.3.0.so b45ba000-b45ce000 r-xp 08:03 33583 /usr/lib/ libopencore-amrwb.so.0.1.1 b45ce000-b45cf000 rw-p 00014000 08:03 33583 /usr/lib/ libopencore-amrwb.so.0.1.1 b45cf000-b45fc000 r-xp 08:03 33581 /usr/lib/ libopencore-amrnb.so.0.1.1 b45fc000-b45fd000 rw-p 0002c000 08:03 33581 /usr/lib/ libopencore-amrnb.so.0.1.1 b45fd000-b4609000 r-xp 08:03 35799 /usr/lib/libgsm.so. 1.0.12 b4609000-b460a000 rw-p b000 08:03 35799 /usr/lib/libgsm.so. 1.0.12 b460a000-b4645000 r-xp 08:03 36722 /usr/lib/libfaad.so. 0.0.0 b4645000-b4646000 ---p 0003b000 08:03 36722 /usr/lib/libfaad.so. 0.0.0 b4646000-b4647000 r--p 0003b000 08:03 36722 /usr/lib/libfaad.so. 0.0.0 b4647000-b464a000 rw-p 0003c000 08:03 36722 /usr/lib/libfaad.so. 0.0.0 b464a000-b4658000 r-xp 08:03 33922 /usr/lib/libfaac.so. 0.0.0 b4658000-b465b000 rw-p d000 08:03 33922 /usr/lib/libfaac.so. 0.0.0 b465b000-b46eb000 r-xp 08:03 36716 /usr/lib/ libdirac_encoder.so.0.1.0 b46eb000-b46ed000 rw-p 0009 08:03 36716 /usr/lib/ libdirac_encoder.so.0.1.0 b46ed000-b46ee000 rw-p b46ed000 00:00 0 b46ee000-b46fd000 r-xp 08:03 409348 /usr/lib/i686/cmov/ libavutil.so.50.16.0 b46fd000-b46fe000 rw-p f000 08:03 409348 /usr/lib/i686/cmov/ libavutil.so.50.16.0 b46fe000-b4701000 rw-p b46fe000 00:00 0 b4701000-b473b000 r-xp 08:03 482466 /lib/libncursesw.so. 5.7 b473b000-b473c000 ---p 0003a000 08:03 482466 /lib/libncursesw.so. 5.7 b473c000-b473e000 r--p 0003a000 08:03 482466 /lib/libncursesw.so. 5.7 b473e000-b473f000 rw-p 0003c000 08:03 482466 /lib/libncursesw.so. 5.7 b473f000-b4744000 r-xp 08:03 35655 /usr/lib/libgdbm.so. 3.0.0 b4744000-b4745000 r--p
Re: [PD] HID double event bug
I understand it's called a debounce. Not sure precisely what's going on. But if you want to make sure only one gets through I always use a [sel 1] or [sel 0]. or of course [sel 0 1] followed by [del 10] which only accepts bangs, and delays the output by 10 milliseconds, which you won't notice. But when it recieves a bang before the previous one has outputted it restarts the sequence, result, only one message on each key on or key off. Hope this helps. Date: Tue, 15 Jun 2010 12:16:42 +0100 From: ja...@4thharmonic.com To: pd-list@iem.at Subject: [PD] HID double event bug I filed a bug report some time ago here: https://sourceforge.net/tracker/?func=detailaid=3002665group_id=55736atid=478070 Just tested this with Pd version 0.42.5-extended-rc2 on Ubuntu 10.04 and it's the same. Basically I get two events for each key press like this: [hid] opened device 4 (/dev/input/event4): AT Translated Set 2 keyboard print: key key_space 1 print: key key_space 1 print: key key_space 0 print: key key_space 0 Thought I'd mention here too as surely this is a bug? Not a major problem, but it means I always need an [alternate] object or similar. This then became a problem when working on a patch for two note chords when the key commands do not always arrive in the same order and some notes would stay on. James _ http://clk.atdmt.com/UKM/go/195013117/direct/01/ We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] HID double event bug
fromJames Dunn ja...@4thharmonic.comtoAndrew Faraday jbtur...@hotmail.com date15 June 2010 13:52subjectRe: [PD] HID double event bugmailed-by googlemail.com hide details 13:52 (3 minutes ago) Thanks for the reply. This isn't switch contact bounce as every key consistently generates two events for each key pressed down and for each key released. There are certainly ways around it in a patch but I was wondering if this was a bug that could be fixed? James On 15 June 2010 12:48, Andrew Faraday jbtur...@hotmail.com wrote: I understand it's called a debounce. Not sure precisely what's going on. But if you want to make sure only one gets through I always use a [sel 1] or [sel 0]. or of course [sel 0 1] followed by [del 10] which only accepts bangs, and delays the output by 10 milliseconds, which you won't notice. But when it recieves a bang before the previous one has outputted it restarts the sequence, result, only one message on each key on or key off. Hope this helps. -- Date: Tue, 15 Jun 2010 12:16:42 +0100 From: ja...@4thharmonic.com To: pd-list@iem.at Subject: [PD] HID double event bug I filed a bug report some time ago here: https://sourceforge.net/tracker/?func=detailaid=3002665group_id=55736atid=478070 Just tested this with Pd version 0.42.5-extended-rc2 on Ubuntu 10.04 and it's the same. Basically I get two events for each key press like this: [hid] opened device 4 (/dev/input/event4): AT Translated Set 2 keyboard print: key key_space 1 print: key key_space 1 print: key key_space 0 print: key key_space 0 Thought I'd mention here too as surely this is a bug? Not a major problem, but it means I always need an [alternate] object or similar. This then became a problem when working on a patch for two note chords when the key commands do not always arrive in the same order and some notes would stay on. James ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-extended 42 bug
On Mon, 26 Apr 2010, Alexandre Porres wrote: dont know if this is actually a bug, but here it goes if I create a subpatch and have an [inlet] and then create an [inlet~] to the left, the parent patch does not draw the corresponding data/audio inlet correctly, it has to be reopen or copied for that to happen... Minimise the parent window, and unminimise it. It will redraw the object correctly. The bug seems to be that only the _last_ inlet~ created will appear to be in the wrong position. Whenever you create a new inlet~, the previous one that wasn't in the right position will go to the right position... meanwhile, the actual inlets are in the correct order, because of the way wires are preserved, so, the only problem would be the look of the inlets. _ _ __ ___ _ _ _ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Weird mouse click bug
That sounds vaguely familiar. Its likely a bug in Pd or Wish. Which version are you using? I'm guessing 0.41.4, since the nightly builds now use wish85. Try a 0.42.5 build. .hc On Feb 7, 2010, at 1:49 AM, Jonathan Wilkes wrote: I'm on winxp, and I wonder if anyone else has run into the following problem: After working on a lot of different patches in pd-ext, and opening multiple patches at a time (say 18 at a time), there comes a point after about 20 minutes or so when I'm working in a patch and all the mouse bindings get wacky. For example, I might click the x on a window to close it, and instead of closing the window I get a number box hanging from the mouse. Or maybe I go to click File-Save and it brings up the audio settings. In fact, the only way I can get out of Pd at that point is to open the task manager and kill the wish84.exe. This doesn't happen every time I use Pd. If I'm working a lot in a day, it might happen once or maybe twice. I've never had anything like this happen in another program so I don't think it's my hardware. Any ideas? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list I hate it when they say, He gave his life for his country. Nobody gives their life for anything. We steal the lives of these kids. - Admiral Gene LeRocque ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] separator and texunits bug was: Re: (rectangular textures) Can't see what's wrong here]
Matteo Sisti Sette escribió: Is this really all [separator] does? Stupid question: Obviously it isn't (just had a look at the source code though I don't understand a line). But for what my patch does, it seems that replacing separators with a push and pop has no side effects, fortunately. -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] separator and texunits bug was: Re: (rectangular textures) Can't see what's wrong here]
I forgot to Cc the list; Cyrille's suggestion worked great :) Mensaje original cyrille henry escribió: use GEMglPushMatrix() and GEMglPopMatrix() Wow GREAT!!! Thanks so much! I replaced all [separator]s with the attached abstraction, I must confess I was a bit skeptical but it worked! -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com #N canvas 366 326 450 300 12; #X obj 202 126 GEMglPushMatrix; #X obj 149 62 inlet; #X obj 149 96 t a a a; #X obj 175 151 outlet; #X obj 149 176 GEMglPopMatrix; #X connect 1 0 2 0; #X connect 2 0 4 0; #X connect 2 1 3 0; #X connect 2 2 0 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gem.conf (was: Re: bug 2621932 appeared in version 0.42)
On Dec 11, 2009, at 9:17 AM, IOhannes m zmölnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Plessas wrote: Oh, and i just compiled Gem and at loading the lib it posts a message about gem.conf not being found. What is this file? A config file for Gem itself? exactly. i haven't found a way to use Pd's file-opening mechanisms without outputting an error if the file cannot be found. (but iirc, it only writes to stderr - if not using -verbose; so most people probably won't notice) it's meant as a replacement for all the weird envvariables that are in use now. you can use it set the single-context, default font, default window size and the like. the format is very simple (but different from Pd's rcfile/settings). one key/value pair by line. e.g. snip font.face /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf window.width 800 window.height 600 window.x 1024 window.y 0 window.border 0 /snip ideas on which things should be settable with this mechanism are welcome. mgfasdr IOhannes Why introduce a new method of configuration when you can do this all with Pd messages? It seems to me to overcomplicate things for a tiny gain. Gem is already complicated as it is, now there is yet another way to configure it: messages, env vars, and a special conf file. I don't see any reason why this all can't be handled by messages and a [loadbang]. .hc We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM-dev] crazy bug: all user actions executed twice
hi, yes this happened to me a while ago, can't remember what os. I am not sure I was using gem either. the reason i am so forgetful is that: -it probably it went away -or it is in a computer i don't often use. I'll let you know if I find it again. sorry for being unhelpful, but at least you know this has happened to someone. J On Thu, Dec 10, 2009 at 7:40 AM, Matteo Sisti Sette matteosistise...@gmail.com wrote: Hi, I write just to see if anybody has already seen this happaning and can give me some clue as how to avoid it. I am not even sure the problem is with GEM, but I have worked on much more huge patches in PD without gem and never seen anything similar. I am on Windows Vista with the latest PD Vanilla and the latest GEM. I have not been able to isolate the problem; if anybody with some possibility to debug it is willing to try the patch and find out something I can send it to him/her. So, the problem is, in some occasions, very frequently (usually after opening the main patch, closing it, and opening it again), every user action (e.g.: clicking on a bang or toggle, hitting some key INCLUDING ctrl+1 to create an object or introducing input into an object or message box, or even a save as) gets executed two or even more times. As you can imagine that fucks everything up. If I just open the patch and run it it works fine, but for even the smallest change that implies modifying some abstraction, I have to close PD, open it again, modify the abstraction I have to modify, save, close PD and open it again, since if I just save or even if I close all patches and open the main one again, everything is fucked up. It is impossible to work this way. Usually restarting the computer makes the bug disappear but then it is a matter of minutes before it starts showing again. I know that, if this is the first time you hear of it, you will hardly be hable to help, but my hope is that someone has observed this already and have been able to link it to a particular object or condition. By the way, I have checked that when this happens, NO duplicate pd.exe nor whish84 process exists (provided that task manager is reliable). Thanks in advance m. -- Matteo Sisti Sette matteosistise...@gmail.com http://www.matteosistisette.com ___ GEM-dev mailing list gem-...@iem.at http://lists.puredata.info/listinfo/gem-dev -- Jaime E Oliver LR joliv...@ucsd.edu www.realidadvisual.org/jaimeoliver www-crca.ucsd.edu/ www.realidadvisual.org 858 750 0924 (cel) 858 202 1522 (home) 9168 Regents Rd. Apt. G La Jolla, CA 92037 USA ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [polywavesynth] and [polygrainsynth] bug fix
hi againsome more comments 1) at first i also tried changing the ADSR sliders to a log setting, and totally understand what you mean about the low values and clicking. my workaround was just to change the range from 1-5000 to 5-5000. however, i think an even better solution is not the log function, but an exponential one. if you change the sliders to 0-1 range and then do: [r slider-value] | [pow 2] (or 3) | [* 5000] | [+ 1] then that gives the most user-friendly sliders in my opinion. 2) i understand that you can change the pan position and speed, but unless i'm mistaken, there is no way just to keep everything centre panned. i think a pan width slider would be helpful. however, maybe that's just something i want and wouldn't be that important for anyone else, so i might just put that on my own modified version. 3) not sure what was happening with the gain problem. perhaps svf~ puts out some gnarly peaks that are well above the -1 1 threshold, and that was making things sound weird when i changed volume. the problem seems fine now, because i deleted the gain section from the polywavevoice~ abtraction and put the gain directly onto the ouptut of polywavesynth~. the gain slider also had a really unusable range, so i also adjusted that into a more manageable range. i will definitely use this synth a lot from now on. today i was running it with an SH101 emulator i am making, and a modified sequenced version of frank's vosim~ abstraction, and some drum synths, and it was all sounding pretty sweet. really cool to be able to get some polyphony happening and do chords and stuff! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [polywavesynth] and [polygrainsynth] bug fix
hard off wrote: hi againsome more comments 1) at first i also tried changing the ADSR sliders to a log setting, and totally understand what you mean about the low values and clicking. my workaround was just to change the range from 1-5000 to 5-5000. however, i think an even better solution is not the log function, but an exponential one. if you change the sliders to 0-1 range and then do: [r slider-value] | [pow 2] (or 3) | [* 5000] | [+ 1] then that gives the most user-friendly sliders in my opinion. Be aware that that breaks the way state is currently saved for the ADSR; ADR values are stored as milliseconds, not as 0-1. That could be changed, but it would break all existing patches (I'm probably the only one for whom that causes problems -- still I try not to do it too often). The log setting is a pretty good compromise; thanks again for the idea. 2) i understand that you can change the pan position and speed, but unless i'm mistaken, there is no way just to keep everything centre panned. Just change the radio button from rnd (for random panning) to fix (for fixed position). Then, move the position slider to the center (or move it live for manual panning). Sorry that the controls are labeled so cryptically, but real estate is at a premium, and the web page documentation spells out the details. i think a pan width slider would be helpful. however, maybe that's just something i want and wouldn't be that important for anyone else, so i might just put that on my own modified version. Yeah, I thought of some other panning algorithms and enhancements besides random panning, too, but have punted this off to OSC control. You can do just about anything you can conceive of through the OSC input, as you are completely in control of what numbers you pass in. Most of my latest work with these two synths involves hooking up LFOs and other data generators to various controls through the OSC input. That said, I *do* plan to balance the panning a little better at some point. It's a simple-minded pan right now, not a balanced-power ratio, so there's a center hole effect. 3) not sure what was happening with the gain problem. perhaps svf~ puts out some gnarly peaks that are well above the -1 1 threshold, and that was making things sound weird when i changed volume. the problem seems fine now, because i deleted the gain section from the polywavevoice~ abtraction and put the gain directly onto the ouptut of polywavesynth~. Well, I'm glad you're not shy about customizing, but that change wipes out the possibility of phased-in preset changes (as when the global toggle is off). I've gone back and forth on this during the evolution of the instrument, and am really liking the current set up which allows local-per-voice gain changes, over-rideable with the global control, which causes all voices to be controlled instantly by the GUI and OSC. the gain slider also had a really unusable range, so i also adjusted that into a more manageable range. It is greater than unity gain above about 70% or so. This was done to match up with [polygrainsynth], which sometimes needs the extra gain. When you have a rack of these, with the two types mixed together, it's good to have the gain slider-range match, but otherwise, you're right that the gain slider could be better optimized for [polywavesynth]'s purposes. i will definitely use this synth a lot from now on. today i was running it with an SH101 emulator i am making, and a modified sequenced version of frank's vosim~ abstraction, and some drum synths, and it was all sounding pretty sweet. really cool to be able to get some polyphony happening and do chords and stuff! That's really great to hear, and I look forward to hearing some music made with it. Check out [polygrainsynth] if you get a chance. Thanks a million for the detailed feedback, Phil http://www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [polywavesynth] and [polygrainsynth] bug fix
Sorry for the self-reply, hard off pointed out a hole in the documentation to [polywavesynth] and [polygrainsynth]: Phil Stone wrote: hard off wrote: 2) i understand that you can change the pan position and speed, but unless i'm mistaken, there is no way just to keep everything centre panned. Just change the radio button from rnd (for random panning) to fix (for fixed position). Then, move the position slider to the center (or move it live for manual panning). Sorry that the controls are labeled so cryptically, but real estate is at a premium, and the web page documentation spells out the details. I double-checked, and it looks like I left out any explanation of how panning works from the web page docs. Oops. I'll remedy that very soon. Phil ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [polywavesynth] and [polygrainsynth] bug fix
yeah getting some quite lush sounds out of this polywavesynth now. says its only using 4% of my cpu as well, which is a bonus. haven't tried the grain one yet. a couple of things: 1) the message box going into the sssadpanel currently contains [example_presets/example1( but the folder is actually [Example_Presets], my system doesn't work with the change in capitalization. 2) it's hard to adjust the ADSR sliders at low values. particularly for attack, it is important to be able to choose values around 20ms or 50ms. so i think a log, or exponential scaling would be better for the ADSR sliders. 3) i had a look, and i can't figure out why, but it seems that the global gain is still somehow affecting the sound further up the chain. ie..when i adjust the global gain, the attack of the sound is also changing. still not sure where this is coming from, but maybe something connected to the adsr? 4) would be nice to have more control over the amount of panning. but yeah, there are lots of really good sounds possible with this, great synth!!! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [polywavesynth] and [polygrainsynth] bug fix
Thanks for the feedback, Mr. Off. :-) Seriously, I really appreciate it. (responses interleaved below). hard off wrote: yeah getting some quite lush sounds out of this polywavesynth now. says its only using 4% of my cpu as well, which is a bonus. haven't tried the grain one yet. Fast machine! This means you can use big voice numbers, like 64 (if you can find a use for that kind of polyphony). Alternatively, you can throw up multiple [polywavesynth]s and/or [polygrainsynth]s, for polytimbral polyphony, or fattened unison voices. a couple of things: 1) the message box going into the sssadpanel currently contains [example_presets/example1( but the folder is actually [Example_Presets], my system doesn't work with the change in capitalization. This is in [polywavesynth_example] -- good catch; I'll fix it on the next release. 2) it's hard to adjust the ADSR sliders at low values. particularly for attack, it is important to be able to choose values around 20ms or 50ms. so i think a log, or exponential scaling would be better for the ADSR sliders. This is such an excellent idea, I implemented it immediately (changed the sliders to log). Not nearly so much shift-dragging is necessary now. You have to watch out for attack/decay/release values of less than 11 msecs. or so, though. They can sound very clicky (although this may actually be desired in certain circumstances). Again, this will be available on the next release; it's easy to change on your own, though, and it has no ill effects. 3) i had a look, and i can't figure out why, but it seems that the global gain is still somehow affecting the sound further up the chain. ie..when i adjust the global gain, the attack of the sound is also changing. still not sure where this is coming from, but maybe something connected to the adsr? I don't understand what you mean here...the gain slider on the [polywavesynth] UI is interacting with the attack? Are you sure it's not clipping - it's easy to clip with higher gain settings. The more notes you hold down, the higher the output, so for big polyphony, you have to bring the slider down a bit. If I'm totally misreading what you're saying here, let me know. 4) would be nice to have more control over the amount of panning. Like all the controls, it's available via OSC: [an lfo, or anything else you like] | [/example/pan/position $1 | (connect to the rightmost inlet of [polywavesynth]) Similarly, you can change the pan lagtime with a message like /example/pan/speed 0.8. The OSC implementation of [polywavesynth] (polygrainsynth works the same way) is here: http://www.pkstonemusic.com/polyWaveSynth.html#osc but yeah, there are lots of really good sounds possible with this, great synth!!! Thanks again for the excellent critique. Phil http://www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [polywavesynth] and [polygrainsynth] bug fix
Yeah, I have to second that It's great to see stuff like this emerging.
.hc
On Nov 24, 2008, at 6:24 PM, Kyle Klipowicz wrote:
Very lovely! Your documentation is impeccable. This is truly an
great, full-functioning pair of synths. I will be sure to show it
off to my 7th grade Pd student.
~Kyle
On Wed, Oct 1, 2008 at 10:53 PM, Phil Stone [EMAIL PROTECTED]
wrote:
Hi again,
If you use either of these synthesizers, please grab the latest. The
previous versions moved gain to a global parameter. I should have
known better; this causes glitches in already-sounding notes when
presets change. I had a similar problem last year with
[polywavesynth],
but forgot about it.
This is the tradeoff to using [poly] to manage voices; if you want the
ability to change presets cleanly, most parameters (i.e., those stored
to make up the preset) can only be changed on new attacks. I haven't
thought of a way around this conundrum yet.
At any rate, the latest versions fix this issue. Sorry for any
inconvenience.
This leads to the web pages and download links for both synthesizers:
http://www.pkstonemusic.com/pd_code.html
Phil Stone
http://www.pkstonemusic.com
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - http://lists.puredata.info/
listinfo/pd-list
--
-
-
- --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - http://lists.puredata.info/
listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish.-William Carlos Williams
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] [polywavesynth] and [polygrainsynth] bug fix
Very lovely! Your documentation is impeccable. This is truly an great,
full-functioning pair of synths. I will be sure to show it off to my 7th
grade Pd student.
~Kyle
On Wed, Oct 1, 2008 at 10:53 PM, Phil Stone [EMAIL PROTECTED] wrote:
Hi again,
If you use either of these synthesizers, please grab the latest. The
previous versions moved gain to a global parameter. I should have
known better; this causes glitches in already-sounding notes when
presets change. I had a similar problem last year with [polywavesynth],
but forgot about it.
This is the tradeoff to using [poly] to manage voices; if you want the
ability to change presets cleanly, most parameters (i.e., those stored
to make up the preset) can only be changed on new attacks. I haven't
thought of a way around this conundrum yet.
At any rate, the latest versions fix this issue. Sorry for any
inconvenience.
This leads to the web pages and download links for both synthesizers:
http://www.pkstonemusic.com/pd_code.html
Phil Stone
http://www.pkstonemusic.com
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
--
-
-
- --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] [polywavesynth] and [polygrainsynth] bug fix
I finally had a chance to play with these, nice work! I just spent a happy hour by sticking this onto the polywavesynth: [metro 25] | [random 25] | [+ 55] | and other such simple things. It sounds nice when it's thick changing layers. .hc On Oct 2, 2008, at 12:53 AM, Phil Stone wrote: Hi again, If you use either of these synthesizers, please grab the latest. The previous versions moved gain to a global parameter. I should have known better; this causes glitches in already-sounding notes when presets change. I had a similar problem last year with [polywavesynth], but forgot about it. This is the tradeoff to using [poly] to manage voices; if you want the ability to change presets cleanly, most parameters (i.e., those stored to make up the preset) can only be changed on new attacks. I haven't thought of a way around this conundrum yet. At any rate, the latest versions fix this issue. Sorry for any inconvenience. This leads to the web pages and download links for both synthesizers: http://www.pkstonemusic.com/pd_code.html Phil Stone http://www.pkstonemusic.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] is this a bug?
Matteo Sisti Sette wrote: object on the left is saved as \\\$1-foo3 with four slashes!!! i love that one. If this is by design, I really don't understand it. i thikn the problem might be related to a generally different handling of DOLLARG (e.g. $1) vs DOLLSYM ($1-bla). apart from that, i never understood the reason for escaping the $ (that is: putting a backslash before it); i think it was originally meant to help the parser distinguis between real dollarg/dollsyms and spurious dollars. (e.g. bla$blu) i would suggest to remove all backslashes where they are not necessary (currently: everywhere) fgma.sdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] red dashed border bug (new color theme)
Nice! There are actually two cases where this happens that might be useful to distinguish. One is where the object can't be found, if it's not in the path. The other is where an object fails to instantiate, an example being [netrecieve] if a port is in use. On Sat, 10 Nov 2007 14:39:48 -0500 Hans-Christoph Steiner [EMAIL PROTECTED] wrote: Hey all, For anyone who's tried a recent build, I made objects that don't successfully create have a red border. Previously, they had dashed border with normal color, I added the red. The red part was a bit too eager so it was showing up when you are creating a new object, I think I fixed this by removing a seemingly extraneous itemconfigure command. Please test and let me know if that part is working for y'all. .hc All information should be free. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] red dashed border bug (new color theme)
Those are good ideas, but they would require substantial modification, which I am not quite ready to do. Right now, I am just adding color to existing modes. .hc On Nov 11, 2007, at 4:34 AM, Andy Farnell wrote: Nice! There are actually two cases where this happens that might be useful to distinguish. One is where the object can't be found, if it's not in the path. The other is where an object fails to instantiate, an example being [netrecieve] if a port is in use. On Sat, 10 Nov 2007 14:39:48 -0500 Hans-Christoph Steiner [EMAIL PROTECTED] wrote: Hey all, For anyone who's tried a recent build, I made objects that don't successfully create have a red border. Previously, they had dashed border with normal color, I added the red. The red part was a bit too eager so it was showing up when you are creating a new object, I think I fixed this by removing a seemingly extraneous itemconfigure command. Please test and let me know if that part is working for y'all. .hc - --- All information should be free. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zexy object urn bug?
Bosko Milakovic wrote: Hm. Is it possible that when it's done urn will just bang to second outlet without empty bang? technically it is simple. the problem is rather from a philosophical point of view: i rather not have objects trigger outlets from left to right. unless i have some simple and consistent idea how to deal with that, i won't change the current behaviour. fmgasdr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zexy object urn bug?
Bosko Milakovic wrote: Hi! I have a question about Zexy (2.1) object urn. I think there is a bug in the second outlet. In the help patch this is writen: when all the numbers have been drawn from the pool, the system is reset (the numbers are put back) and a bang is emitted via the second outlet But this is not true. Bang is emitted not on the last number from the pool (list) but on the first number of the next cycle! Hm. I'm using this object you are right. in my patch and it took me cca 2 hours to find why patch doesn't work:) but why did your patch refuse to work because of this? it would be good to have an example that proves that the behaviour should really be fixed (probably i am just to tired to think of one...) are there any built-in objects that behave like you are expecting [urn] to behave? (apart from outputting unique random numbers, that is) mfga.dr. IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zexy object urn bug?
Hi! From: IOhannes m zmoelnig [EMAIL PROTECTED] To: Bosko Milakovic [EMAIL PROTECTED] CC: pd-list@iem.at Subject: Re: [PD] Zexy object urn bug? Date: Tue, 27 Mar 2007 15:37:32 +0200 Bosko Milakovic wrote: Hi! I have a question about Zexy (2.1) object urn. I think there is a bug in the second outlet. In the help patch this is writen: when all the numbers have been drawn from the pool, the system is reset (the numbers are put back) and a bang is emitted via the second outlet But this is not true. Bang is emitted not on the last number from the pool (list) but on the first number of the next cycle! Hm. I'm using this object you are right. in my patch and it took me cca 2 hours to find why patch doesn't work:) but why did your patch refuse to work because of this? it would be good to have an example that proves that the behaviour should really be fixed (probably i am just to tired to think of one...) It's an important part of the patch where after urn generates n unique random numbers (n is always different) another abstraction expects bang to move forward and do some work... But it's important that bang comes after the last generated number from the pool, and not on the first of the new cycle. Then it's too late. are there any built-in objects that behave like you are expecting [urn] to behave? (apart from outputting unique random numbers, that is) I expected to be like second outlet from textfile object: on the end of sequence you get bang. That what I expected from urn because it was writen in help patch. Now I had to add counter to urn that counts every generated number and when it gets to n number, number is selected with [sel] which send bang It's not problem for me but I thought it would be good to have object like that. Thanks Bosko _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zexy object urn bug?
Bosko Milakovic wrote: Hi! are there any built-in objects that behave like you are expecting [urn] to behave? (apart from outputting unique random numbers, that is) I expected to be like second outlet from textfile object: on the end of sequence you get bang. That what I expected from urn because it was writen in help patch. obviously, if it's described in the help-patch it has to behave like that (that is why i don't describe features in the help-patches ;-)) would be ok (for everybody, not just you) if the empty bang had to be triggered separately (just like in [textfile])? e.g. [urn 3] would output 3 random numbers; when banged a 4th time, it would (only) output a bang at the right-hand side; when banging a 5th time it would output a random number again. this is somewhat weird, as banging the object 40 times will only give you 30 random numbers (but for those who don't care about the wraparound but really want 40 numbers instead, they could just feedback the 2nd outlet to the left inlet) it would be interesting to know whether there are objections from other users of this object. mfa.dr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zexy object urn bug?
On 3/27/07, IOhannes m zmoelnig [EMAIL PROTECTED] wrote: would be ok (for everybody, not just you) if the empty bang had to be triggered separately (just like in [textfile])? e.g. [urn 3] would output 3 random numbers; when banged a 4th time, it would (only) output a bang at the right-hand side; when banging a 5th time it would output a random number again. this is somewhat weird, as banging the object 40 times will only give you 30 random numbers (but for those who don't care about the wraparound but really want 40 numbers instead, they could just feedback the 2nd outlet to the left inlet) I think it would definitely be good for it to bang when it's done (not when it sends the first new number), but for me, any specific implementation would work that provides such a bang. ~David ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zexy object urn bug?
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote: obviously, if it's described in the help-patch it has to behave like that (that is why i don't describe features in the help-patches ;-)) would be ok (for everybody, not just you) if the empty bang had to be triggered separately (just like in [textfile])? e.g. [urn 3] would output 3 random numbers; when banged a 4th time, it would (only) output a bang at the right-hand side; when banging a 5th time it would output a random number again. IMO it would be best and most flexible, if the urn would not automatically refill when it's empty. And actually that's the way, two of the three (I checked it: Cyclone, maxlib and zexy have one) [urn]s work and I based my urne.pd abstraction on that approach as well. The right EOF outlet always can be used to refill the urn, so no functionality would be missed, if needed. this is somewhat weird, as banging the object 40 times will only give you 30 random numbers Like in Lotto: Playing 60 of 45 will only give you 45 numbers as well, but at least you always win! (but for those who don't care about the wraparound but really want 40 numbers instead, they could just feedback the 2nd outlet to the left inlet) it would be interesting to know whether there are objections from other users of this object. Which one? ;) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Zexy object urn bug?
From: IOhannes m zmoelnig [EMAIL PROTECTED] would be ok (for everybody, not just you) if the empty bang had to be triggered separately (just like in [textfile])? e.g. [urn 3] would output 3 random numbers; when banged a 4th time, it would (only) output a bang at the right-hand side; when banging a 5th time it would output a random number again. this is somewhat weird, as banging the object 40 times will only give you 30 random numbers (but for those who don't care about the wraparound but really want 40 numbers instead, they could just feedback the 2nd outlet to the left inlet) Hm. Is it possible that when it's done urn will just bang to second outlet without empty bang? _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
