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.
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 matteosistisette@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 matteosistisette@gmail.com http://www.matteosistisette.com
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
I've had the same problem quite a lot of times. Normally I just close Pd, restart and everything is working fine again. I didn't manage to isolate the problem yet...
(working on Windows XP, Pd vanilla version 0.42.4, not using GEM)
Hans r
At 16:40 10/12/2009, you 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 matteosistisette@gmail.com http://www.matteosistisette.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Matteo Sisti Sette wrote:
I write just to see if anybody has already seen this happaning
happens here also sometimes. closing and reopening pd usually solves the problem. (ubuntu jaunty 32 bit, pd .42-5, gem loaded, but i think it happend also without gem)
and can give me some clue as how to avoid it.
unfortunatly not. it might have something to do with opening/closing large patches, but im not sure.
bis denn! martin
On Dec 10, 2009, at 1:16 PM, martin brinkmann wrote:
Matteo Sisti Sette wrote:
I write just to see if anybody has already seen this happaning
happens here also sometimes. closing and reopening pd usually solves the problem. (ubuntu jaunty 32 bit, pd .42-5, gem loaded, but i think it happend also without gem)
and can give me some clue as how to avoid it.
unfortunatly not. it might have something to do with opening/closing large patches, but im not sure.
bis denn! martin
I've never seen that bug in 0.42.5. Is there a bug report for it? If
either of you can find a way to reliably reproduce it, then its much
easier to fix.
.hc
"Making boring techno music is really easy with modern tools, but with
live coding, boring techno is much harder." - Chris McCormick
Do you have "graph on parent" enabled for the abstractions? If so see bug id# 2621932.
-Jonathan
--- On Thu, 12/10/09, Matteo Sisti Sette matteosistisette@gmail.com wrote:
From: Matteo Sisti Sette matteosistisette@gmail.com Subject: [PD] crazy bug: all user actions executed twice To: "PD list" pd-list@iem.at, gem-dev@iem.at Date: Thursday, December 10, 2009, 4:40 PM 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 matteosistisette@gmail.com http://www.matteosistisette.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Jonathan Wilkes escribió:
Do you have "graph on parent" enabled for the abstractions? If so see bug id# 2621932.
Thank you very much.
Yes I do use GOP and it definitely looks like that bug.
It's strange because in the past I have used huge lots of GOP without seing this... is it possible that it has appeared in some recent version?
Well I'll compare my patch with the one in the bug report, try some older version of pd, and see if I find out something.
Thanks again m.
Hi,
I have tested bug 2621932 with the reporter's patch, which reproduces the bug 100% of the time.
I have done the test on various PD versions and found out that it appeared on 0.42.0 All previous versions don't have the bug (at least not reproducible with the test patch), while all subsequent versions do have it.
This is the same version in which a feature was introduced such that when you create a new object with another one selected, a connection between the two is automatically created (btw am I the only one who thinks that feature is absolutely annoying?). Dunnow if it is a coincidence or if there may be a relation...
I hope this helps to fix the bug, which is almost a crasher (indeed in most cases it does eventually crash but what happens before the crash is even more dangerous).
Jonathan Wilkes escribió:
Do you have "graph on parent" enabled for the abstractions? If so see bug id# 2621932.
-Jonathan
--- On Thu, 12/10/09, Matteo Sisti Sette matteosistisette@gmail.com wrote:
From: Matteo Sisti Sette matteosistisette@gmail.com Subject: [PD] crazy bug: all user actions executed twice To: "PD list" pd-list@iem.at, gem-dev@iem.at Date: Thursday, December 10, 2009, 4:40 PM 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 matteosistisette@gmail.com http://www.matteosistisette.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
This is the same version in which a feature was introduced such that when you create a new object with another one selected, a connection between the two is automatically created (btw am I the only one who thinks that feature is absolutely annoying?).
after lots of moaning from various people (including me), miller has made this feature optional with one of the bugfix releases. jusst add "-noautopatch" to the startup options. (unfortunately you can only turn it on/off for the entire session and not on demand - i some situations it is really handy; often it is not)
fgmasdr IOhannes
IOhannes m zmölnig wrote:
made this feature optional with one of the bugfix releases. jusst add "-noautopatch" to the startup options.
Can i include it in the .pdrc file too?
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?
thank you! P
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Peter Plessas wrote:
IOhannes m zmölnig wrote:
made this feature optional with one of the bugfix releases. jusst add "-noautopatch" to the startup options.
Can i include it in the .pdrc file too?
of course. whichever method you prefer.
fasdr IOhannes
-----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
IOhannes m zmölnig a écrit :
-----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.
i created an empty file, and i stil have this error. i'm wondering what i can do wrong... any idea?
Cyrille
(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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksiVGUACgkQkX2Xpv6ydvQ0/ACfbs/APFVA6iva6eTLkTiGat2A A4wAniEbkttjiNidT5uNc3PexdKx1HvC =cZzA -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
cyrille henry wrote:
IOhannes m zmölnig a écrit : 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.
i created an empty file, and i stil have this error. i'm wondering what i can do wrong... any idea?
the reason for this is, that Gem looks in several places for the configuration file, and they are merged together. the locations (on a linux system) are: /etc/pd/gem.conf ~/.pd/gem.conf gem.conf (whatever that means; it doesn't know anything about a current canvas but it is searching Pd's path)
anyhow: apart from the annoying printout, this should have any effect on the running system.
mfgasdr IOhannes
Cyrille
the reason for this is, that Gem looks in several places for the configuration file, and they are merged together. the locations (on a linux system) are: /etc/pd/gem.conf ~/.pd/gem.conf gem.conf (whatever that means; it doesn't know anything about a current canvas but it is searching Pd's path)
ok. after creating a 3rd empty file, Gem did not create an error any more.
anyhow: apart from the annoying printout, this should have any effect on the running system.
yes, but i don't like annoying printout.
thanks
c
mfgasdr IOhannes
Cyrille
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkskxP8ACgkQkX2Xpv6ydvRfywCdEZJNG7NvUZs5o1wz+DtIjzp7 F9UAoOWx7RBGfJI8cOH/V/XPfwiuF5jE =4Dw3 -----END PGP SIGNATURE-----
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
Hans-Christoph Steiner a écrit :
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].
the nice thing is that you don't have to use it if you don't like it....
i will not use it because i also prefer the "everything in one patch" : you have less surprises when sharing patches. (that is also why i think a good patch is a patch that could start with -nopref flag on pd startup)
but i would understand someone that set gemwin framerate at 50 fps because the default 20 fps is a nonsense...
cyrille
.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
On Dec 13, 2009, at 3:11 PM, cyrille henry wrote:
Hans-Christoph Steiner a écrit :
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].the nice thing is that you don't have to use it if you don't like
it....i will not use it because i also prefer the "everything in one
patch" : you have less surprises when sharing patches. (that is also why i think a good patch is a patch that could start
with -nopref flag on pd startup)
I totally agree, we should be working towards everything in the patch,
and they should work with pd -nopref. Sure, no one has to use it, but
if someone does use it, and then you want to use their patch, then you
have to use
but i would understand someone that set gemwin framerate at 50 fps
because the default 20 fps is a nonsense...cyrille
Isn't that changed by doing [gemwin 50]? That doesn't seem so hard
that a gem.conf is needed.
.hc
http://at.or.at/hans/
Hans-Christoph Steiner a écrit :
On Dec 13, 2009, at 3:11 PM, cyrille henry wrote:
Hans-Christoph Steiner a écrit :
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].
the nice thing is that you don't have to use it if you don't like it....
i will not use it because i also prefer the "everything in one patch" : you have less surprises when sharing patches. (that is also why i think a good patch is a patch that could start with -nopref flag on pd startup)
I totally agree, we should be working towards everything in the patch, and they should work with pd -nopref. Sure, no one has to use it, but if someone does use it, and then you want to use their patch, then you have to use
it's the same problem than someone using pd pref file to load path and libs...
except that having a gemwin default size is not so important regarding to not having a lib when loading a patch.
but i would understand someone that set gemwin framerate at 50 fps because the default 20 fps is a nonsense...
cyrille
Isn't that changed by doing [gemwin 50]? That doesn't seem so hard that a gem.conf is needed.
when loading Gem examples, i don't bother to change it in order to try it. but i'm still annoy by the 20fps...
a nice use i see with this conf file is to change default video in device. so that you don't have change your patch if you change computer (1 with V4L and 1 with V4L2 webcam)...
Cyrille
.hc
http://at.or.at/hans/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
cyrille henry wrote:
a nice use i see with this conf file is to change default video in device. so that you don't have change your patch if you change computer (1 with V4L and 1 with V4L2 webcam)...
like that.
or whether you want to use threaded image loading or not. (i couldn't think of a way to not want that; till karmic...) ((right; we shouldn't use configuration to circumvent bugs))
anyhow, i believe that a patch should be as cross-platform as possible. so indeed something like "driver v4l2" is ugly since it is non portable.
i also believe that machine configuration should be machine configuration and not patch configuration.
fgmasdr IOhannes
IOhannes m zmoelnig wrote:
cyrille henry wrote:
a nice use i see with this conf file is to change default video in device. so that you don't have change your patch if you change computer (1 with V4L and 1 with V4L2 webcam)...
like that.
or whether you want to use threaded image loading or not. (i couldn't think of a way to not want that; till karmic...) ((right; we shouldn't use configuration to circumvent bugs))
anyhow, i believe that a patch should be as cross-platform as possible. so indeed something like "driver v4l2" is ugly since it is non portable.
i also believe that machine configuration should be machine configuration and not patch configuration.
What about this: Perhaps indicate the successful loading of those files in the post window instead of posting an error message when the files are not around. I routinely check the Pd window for errors at startup, and stumble accross the gem.conf "error" messages. Wait, hu? What's there? (relief) oh, only the new gem feature. :-) Since gem.config is an optional and probly very useful mechanism changing the way the file loading mechanism reports back might make the current "problem" much less of an issue?
Peter "2cents"
fgmasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mon, Dec 14, 2009 at 12:32 PM, Peter Plessas plessas@mur.at wrote:
What about this: Perhaps indicate the successful loading of those files in the post window instead of posting an error message when the files are not around. I routinely check the Pd window for errors at startup, and stumble accross the gem.conf "error" messages. Wait, hu? What's there? (relief) oh, only the new gem feature. :-) Since gem.config is an optional and probly very useful mechanism changing the way the file loading mechanism reports back might make the current "problem" much less of an issue?
From the usability perspective, that's trivial. Don't say error when there's
no error. What about "foreach error: no more elements in array"? :) Just think how many people feel alerted just when Make says "Nothing to do" :)) When there is no conf file found anywhere, that case could throw an error - of course only if at least one conf file is required or recommended.
Andras
Hans-Christoph Steiner wrote:
Why introduce a new method of configuration when you can do this all with Pd messages?
if you don't like it, don't use it.
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.
the conf-file is to replace the env-vars.
fgmasdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
This is the same version in which a feature was introduced such that when you create a new object with another one selected, a connection between the two is automatically created (btw am I the only one who thinks that feature is absolutely annoying?). Dunnow if it is a coincidence or if there may be a relation...
it might also be related to the introduction of the (somewhat annoying) [wrap] object. might be a coincidence though...:-)
fgmadr IOhannes
On Dec 11, 2009, at 9:21 AM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
This is the same version in which a feature was introduced such that when you create a new object with another one selected, a connection between the two is automatically created (btw am I the only one who thinks that feature is absolutely annoying?). Dunnow if it is a coincidence or if there may be a relation...
it might also be related to the introduction of the (somewhat
annoying) [wrap] object. might be a coincidence though...:-)
It would be good to have those additions documented. I started with
what I know:
http://wiki.puredata.info/en/History_of_new_objects_in_Pd-vanilla
Perhaps the page could be called just "new objects in Pd-vanilla".
There could also be "New objects in Gem", etc.
.hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
it would be nice to have *all* vanilla objects documented on one page. I am thinking of putting all objects right at the front page of wiki.puredata.info. very much the way processing does it. http://processing.org/reference/ marius.
Hans-Christoph Steiner wrote:
On Dec 11, 2009, at 9:21 AM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
This is the same version in which a feature was introduced such that when you create a new object with another one selected, a connection between the two is automatically created (btw am I the only one who thinks that feature is absolutely annoying?). Dunnow if it is a coincidence or if there may be a relation...
it might also be related to the introduction of the (somewhat annoying) [wrap] object. might be a coincidence though...:-)
It would be good to have those additions documented. I started with what I know:
http://wiki.puredata.info/en/History_of_new_objects_in_Pd-vanilla
Perhaps the page could be called just "new objects in Pd-vanilla".
There could also be "New objects in Gem", etc..hc
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ask and you shall receive: http://wiki.puredata.info/en/Category:vanilla
It needs a little updating, but its there as of version 0.41.
.hc
On Dec 13, 2009, at 7:33 PM, marius schebella wrote:
it would be nice to have *all* vanilla objects documented on one
page. I am thinking of putting all objects right at the front page
of wiki.puredata.info. very much the way processing does it. http://processing.org/reference/ marius.Hans-Christoph Steiner wrote:
On Dec 11, 2009, at 9:21 AM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matteo Sisti Sette wrote:
This is the same version in which a feature was introduced such
that when you create a new object with another one selected, a
connection between the two is automatically created (btw am I the only one who thinks that feature is absolutely annoying?). Dunnow if it is a coincidence or if there may be a relation...it might also be related to the introduction of the (somewhat
annoying) [wrap] object. might be a coincidence though...:-)It would be good to have those additions documented. I started
with what I know: http://wiki.puredata.info/en/History_of_new_objects_in_Pd-vanilla Perhaps the page could be called just "new objects in Pd-vanilla".
There could also be "New objects in Gem", etc. .hc ---------------------------------------------------------------------------- News is what people want to keep hidden and everything else is
publicity. - Bill Moyers _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess himself
of it. - Thomas Jefferson
This is the same version in which a feature was introduced such that when you create a new object with another one selected, a connection between the two is automatically created (btw am I the only one who thinks that feature is absolutely annoying?).
after initially having a hard time getting used to it, I now find it extremely helpful...
Jaime Oliver escribió:
This is the same version in which a feature was introduced such that when you create a new object with another one selected, a connection between the two is automatically created (btw am I the only one who thinks that feature is absolutely annoying?).
after initially having a hard time getting used to it, I now find it extremely helpful...
Imo it would only make sense as something you can enable and disable at any moment (without restarting pd).
By the way, the "connection failed" error message should be suppressed when generated by the autopatch.
Matteo Sisti Sette escribió:
Jaime Oliver escribió:
This is the same version in which a feature was introduced such that when you create a new object with another one selected, a connection between the two is automatically created (btw am I the only one who thinks that feature is absolutely annoying?).
after initially having a hard time getting used to it, I now find it extremely helpful...
Imo it would only make sense as something you can enable and disable at any moment (without restarting pd).
i think the connection failed is intended when you open a patch and conditions have changed, like when you remove a formerly connected inlet in an abstraction and it can not thereafter be connected. so pd reports that...
J
On Fri, Dec 11, 2009 at 5:28 PM, Matteo Sisti Sette matteosistisette@gmail.com wrote:
By the way, the "connection failed" error message should be suppressed when generated by the autopatch.
Matteo Sisti Sette escribió:
Jaime Oliver escribió:
This is the same version in which a feature was introduced such that when you create a new object with another one selected, a connection between the two is automatically created (btw am I the only one who thinks that feature is absolutely annoying?).
after initially having a hard time getting used to it, I now find it extremely helpful...
Imo it would only make sense as something you can enable and disable at any moment (without restarting pd).
-- Matteo Sisti Sette matteosistisette@gmail.com http://www.matteosistisette.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list