Re: [PD-dev] representing parent patch levels as args
On Dec 8, 2008, at 12:21 PM, Claude Heiland-Allen wrote: > Hans-Christoph Steiner wrote: >> So I am just adding support to canvas_name and window_name for >> getting the names from other canvases besides the current one, >> i.e. parent, toplevel, etc. > > OK. > >> I am using the now standard numeric notation that is used in >> [getdir], iemguts, getdollarzero, etc. > > Care to give a brief description of that for those that don't > know? I'd be interested in adding something similar to pdlua, so > that .pd_lua(x) files can access the path(s) of their containing > patch(es), would make sense to have the same numbers. 0 = current patch 1 = parent 2 = parent's parent etc. One question I have is about the behavior when you specific more levels than exist. Like [canvas_name 99]. Should that be an error, warning? Should it give the toplevel? nothing? I am guessing it should give the toplevel, with a warning. >> What I am wondering is whether it is worth it to add symbol >> versions of those names too, like "parent" and "toplevel". > > this sounds useful at first, but if it's only two cases then maybe > it's not worth the hassle... Those are the two that will be most commonly used, IMHO, so it could be worth using. >> Or perhaps it would also be useful to be able to stick the name >> of a canvas there too, like 'pd-mysubpatch' or 'pd-canvas_name- >> help.pd'. > > Err, why would that be useful if the object is to get the name in > the first place (and also, what happens if there are 42 copies of > canvas_name-help.pd open...?) Currently you get "warning: pd-canvas_name-help.pd: multiply defined" and they all return the first instance of canvas_name-help.pd. That seems appropriate to me. >> What are people's thoughts on making that part of the standard >> technique of looking up these kinds of things? > > I think often numbers are nicer than names (eg, I'd hate to have to > type "greatgreatgreatgrandparent" instead of 5 or whatever it would > be). Agreed, I think a limited set of names, like "parent", "toplevel" and maybe "current" just to make things explicit. I forgot I had already implemented this, except for the "parent" and "toplevel" part: http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/ hcs/canvas_name.c?view=log http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/ hcs/window_name.c?view=log .hc > > > Claude > -- > http://claudiusmaximus.goto10.org 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-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-devel revival
On Dec 8, 2008, at 11:11 AM, Miller Puckette wrote: > Hi all, > > I've spent some time thinking about this. I had only limited > success pulling > code from the 0.39 "devel" because there were so many changes, > often with > rationales I didn't fully understand, that I wasn't confident about my > ability to maintain whatever I ended up with. However, I did > manage to > fold some of it back into 'vanilla'. Yeah, I hope we learned from that experience, it ended up being a fast-changing fork, as far as I could tell. I think it is important to keep things slow so that everyone involved can know what's going on. > On the other hand, u_main.tk is such a mess that I don't think of > it in > the same way as the rest of the Pd code at all - I'm much more > willing to > take "patches" on it even if I don't understand them :) > > A couple of details. First, I'm at work myself making a desire- > data-inspired > rewrite of all the dialog windows... maybe you shouldn't lose time > on that > till I have a chance to hack at it. I'm also planning rather soon > to add > a new text-editor-window feature. Do you have a target date for this release? I plan on working starting now and thru January on this. A key reason for me wanting to do this is to clean up and structure u_main.tk in a rational way. It's a mess with different people's coding styles, strange order, no "main()" equivalent, etc. Plus a lot of the code really avoids using Tcl the way it should be used, and dates to Tcl 8.3. This is be an opportunity to make clean Tcl code, switch to Tcl 8.5 (which has big improvements on all platforms), and make for an more easily extendable GUI. So honestly, I think it makes sense to first lay down this groundwork before changing elements like the properties panels. In the end, I think that these two parts could be developed in parallel though. I plan on focusing on the core structure of u_main.tk then working on the menus, key commands, window dressing and localization support. Then when there is a nice structure to build upon, I really want to focus on making the workflow as smooth as possible, like structuring a lot of the ideas from DesireData. Another thing I think is really worth exploring is replacing tkcmd.c with pure Tcl code. Then the GUI would be pure Tcl and easier to build and manage. Plus this should make handling charsets much smoother AFAIK for supporting non-ASCII chars. > Second, and this just occurred to me, I think it would be smart to > separate > the u_main.tk cide into several smaller files. They could simply be > concatenated by the makefile. This way people could work on different > parts of it with much less chance of their work colliding. I > should have > thought of this simple strategy years ago, hmm. I am not sure that this would have a big impact, but I wouldn't oppose it. Personally, I think the file should either be called 'pd.tk' or should be broken up into Tcl 'packages' organized around functionality. PortAuthority is a Tcl app that is structured like this (perhaps too much so, though). .hc > > cheers > Miller > > > On Sun, Dec 07, 2008 at 05:32:59PM +0100, [EMAIL PROTECTED] wrote: >> Hi all: >> >> Hope you are all well:) >> >> Some of us have been toying with the idea of working on the gui code >> (u_main.tk/pd.tk only, leaving the C code untouched) of Pd for a >> little >> while now. Starting with refactoring it and gradually adds new >> stuff in, >> and hopefully the changes will work its way to pd-vanilla. >> >> For this reason, we would like to revive the good old pd-devel as the >> working branch. as it would seem fitting to do so instead of >> making a new >> branch with a new name. >> >> So i guess this mail will act as the announcement for this new >> effort, as >> well as a discussion starter for many of us who would like to talk >> about >> the surrounding issues. and perhaps we could also revive the semi >> regular >> dev meetings we had on #dataflow too;) >> >> cheers >> >> chun >> >> >> >> >> ___ >> Pd-dev mailing list >> Pd-dev@iem.at >> http://lists.puredata.info/listinfo/pd-dev > > ___ > Pd-dev mailing list > Pd-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev If you are not part of the solution, you are part of the problem. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-devel revival
On 08/12/2008, at 19.33, [EMAIL PROTECTED] wrote: > Breaking down > u_main.tk sounds like a good idea. Perhaps we could discuss on the > possible ways to do it so we can experiment a little while the new > features are being completed. what do you think? I think that would be the best first step. I also think it's ok to take some time doing so before hacking away -- and i think that was what Hans meant about by "I think it is also good to start slowly and figure out to make this work". I don't have specific ideas for restructuring though. But hopefully you more skilled folks could start making proposal-like sketches to debate about. This is also the part that could lead to grumpiness, so it's properly a good idea to be open-minded and make flexible suggestions. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-devel revival
Hi all: > Hi all, > > I've spent some time thinking about this. I had only limited success > pulling > code from the 0.39 "devel" because there were so many changes, often with > rationales I didn't fully understand, that I wasn't confident about my > ability to maintain whatever I ended up with. However, I did manage to > fold some of it back into 'vanilla'. > > On the other hand, u_main.tk is such a mess that I don't think of it in > the same way as the rest of the Pd code at all - I'm much more willing to > take "patches" on it even if I don't understand them :) > thanks for your reply and letting us know what you think. We planed to make incremental changes anyway, so it should work quite well with making patches for vanilla. > A couple of details. First, I'm at work myself making a > desire-data-inspired > rewrite of all the dialog windows... maybe you shouldn't lose time on that > till I have a chance to hack at it. I'm also planning rather soon to add > a new text-editor-window feature. > > Second, and this just occurred to me, I think it would be smart to > separate > the u_main.tk cide into several smaller files. They could simply be > concatenated by the makefile. This way people could work on different > parts of it with much less chance of their work colliding. I should have > thought of this simple strategy years ago, hmm. hehe, am glad to hear that desiredata has some influence on people other then the ones involved with it;) Are those features close to be finished? if so, we could wait a bit till then and use the new release as our starting point. Breaking down u_main.tk sounds like a good idea. Perhaps we could discuss on the possible ways to do it so we can experiment a little while the new features are being completed. what do you think? cheers chun > > cheers > Miller > > > On Sun, Dec 07, 2008 at 05:32:59PM +0100, [EMAIL PROTECTED] wrote: >> Hi all: >> >> Hope you are all well:) >> >> Some of us have been toying with the idea of working on the gui code >> (u_main.tk/pd.tk only, leaving the C code untouched) of Pd for a little >> while now. Starting with refactoring it and gradually adds new stuff in, >> and hopefully the changes will work its way to pd-vanilla. >> >> For this reason, we would like to revive the good old pd-devel as the >> working branch. as it would seem fitting to do so instead of making a >> new >> branch with a new name. >> >> So i guess this mail will act as the announcement for this new effort, >> as >> well as a discussion starter for many of us who would like to talk about >> the surrounding issues. and perhaps we could also revive the semi >> regular >> dev meetings we had on #dataflow too;) >> >> cheers >> >> chun >> >> >> >> >> ___ >> Pd-dev mailing list >> Pd-dev@iem.at >> http://lists.puredata.info/listinfo/pd-dev > > ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] osc automatic routing
Forwind info wrote: > Hi all, > > Does anybody know if there is a way to automatically send an OSC message to > an internal PD messaging address which happens to be the same as the route > of the OSC message. > So for instance, an osc message arrives with route "/a/sample/route" and > value 50, I would like to automatically send the value of the message to the > internal message address of "/a/sample/route". > I would like to avoid having to explicitly patch this (using route and send > and receive) as there quite a few. something like this: "/foo/bar 1 2 3" or other arbitrary osc message | [t a a] |\ |[list split 1] (or [list]--"$1" would also work here) | : [list split 1] | : | | [send] requires a recent Pd for the settable send, if i recall correctly > I could be missing some basic pd knowledge ... > > thx in advance. > Conor hope this helps, Claude -- http://claudiusmaximus.goto10.org ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] representing parent patch levels as args
Hans-Christoph Steiner wrote: > So I am just adding support to canvas_name and window_name for > getting the names from other canvases besides the current one, i.e. > parent, toplevel, etc. OK. > I am using the now standard numeric notation > that is used in [getdir], iemguts, getdollarzero, etc. Care to give a brief description of that for those that don't know? I'd be interested in adding something similar to pdlua, so that .pd_lua(x) files can access the path(s) of their containing patch(es), would make sense to have the same numbers. > What I am wondering is whether it is worth it to add symbol versions > of those names too, like "parent" and "toplevel". this sounds useful at first, but if it's only two cases then maybe it's not worth the hassle... > Or perhaps it > would also be useful to be able to stick the name of a canvas there > too, like 'pd-mysubpatch' or 'pd-canvas_name-help.pd'. Err, why would that be useful if the object is to get the name in the first place (and also, what happens if there are 42 copies of canvas_name-help.pd open...?) > What are > people's thoughts on making that part of the standard technique of > looking up these kinds of things? I think often numbers are nicer than names (eg, I'd hate to have to type "greatgreatgreatgrandparent" instead of 5 or whatever it would be). Claude -- http://claudiusmaximus.goto10.org ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] osc automatic routing
Thx Claude, I'll check it out later. I really should get up to speed on PD basics... Conor On Mon, Dec 8, 2008 at 5:13 PM, Claude Heiland-Allen < [EMAIL PROTECTED]> wrote: > Forwind info wrote: > >> Hi all, >> >> Does anybody know if there is a way to automatically send an OSC message >> to >> an internal PD messaging address which happens to be the same as the route >> of the OSC message. >> So for instance, an osc message arrives with route "/a/sample/route" and >> value 50, I would like to automatically send the value of the message to >> the >> internal message address of "/a/sample/route". >> I would like to avoid having to explicitly patch this (using route and >> send >> and receive) as there quite a few. >> > > something like this: > > "/foo/bar 1 2 3" or other arbitrary osc message > | > [t a a] > |\ > |[list split 1] (or [list]--"$1" would also work here) > | : > [list split 1] >| : >| | > [send] > > requires a recent Pd for the settable send, if i recall correctly > > I could be missing some basic pd knowledge ... >> >> thx in advance. >> Conor >> > > hope this helps, > > > Claude > -- > http://claudiusmaximus.goto10.org > > ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] osc automatic routing
Hallo, Forwind info hat gesagt: // Forwind info wrote: > Does anybody know if there is a way to automatically send an OSC message to > an internal PD messaging address which happens to be the same as the route > of the OSC message. > So for instance, an osc message arrives with route "/a/sample/route" and > value 50, I would like to automatically send the value of the message to the > internal message address of "/a/sample/route". You could use a settable [send] for this: [dumpOSC] or whatever | [list split 1] | | | [s $0-rest-of-message] | [t b a] || |[s $0-sender-name] | |[r $0-rest-of-message] || [list] | |[r $0-sender-name] || [send] It's imperative that you use the [t b a] here, because the rest-of-message would be generated before the sender-name otherwise as there's right-to-left ordering in [list split]. In a non-ASCII-patch I'd use direct connections, not sends, but that would be hard to read in ASCII. Ciao -- Frank ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] osc automatic routing
Hi all, Does anybody know if there is a way to automatically send an OSC message to an internal PD messaging address which happens to be the same as the route of the OSC message. So for instance, an osc message arrives with route "/a/sample/route" and value 50, I would like to automatically send the value of the message to the internal message address of "/a/sample/route". I would like to avoid having to explicitly patch this (using route and send and receive) as there quite a few. I could be missing some basic pd knowledge ... thx in advance. Conor ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-devel revival
Hi all, I've spent some time thinking about this. I had only limited success pulling code from the 0.39 "devel" because there were so many changes, often with rationales I didn't fully understand, that I wasn't confident about my ability to maintain whatever I ended up with. However, I did manage to fold some of it back into 'vanilla'. On the other hand, u_main.tk is such a mess that I don't think of it in the same way as the rest of the Pd code at all - I'm much more willing to take "patches" on it even if I don't understand them :) A couple of details. First, I'm at work myself making a desire-data-inspired rewrite of all the dialog windows... maybe you shouldn't lose time on that till I have a chance to hack at it. I'm also planning rather soon to add a new text-editor-window feature. Second, and this just occurred to me, I think it would be smart to separate the u_main.tk cide into several smaller files. They could simply be concatenated by the makefile. This way people could work on different parts of it with much less chance of their work colliding. I should have thought of this simple strategy years ago, hmm. cheers Miller On Sun, Dec 07, 2008 at 05:32:59PM +0100, [EMAIL PROTECTED] wrote: > Hi all: > > Hope you are all well:) > > Some of us have been toying with the idea of working on the gui code > (u_main.tk/pd.tk only, leaving the C code untouched) of Pd for a little > while now. Starting with refactoring it and gradually adds new stuff in, > and hopefully the changes will work its way to pd-vanilla. > > For this reason, we would like to revive the good old pd-devel as the > working branch. as it would seem fitting to do so instead of making a new > branch with a new name. > > So i guess this mail will act as the announcement for this new effort, as > well as a discussion starter for many of us who would like to talk about > the surrounding issues. and perhaps we could also revive the semi regular > dev meetings we had on #dataflow too;) > > cheers > > chun > > > > > ___ > Pd-dev mailing list > Pd-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
