Re: [PD] Numpad decimal outputs wrong character
Got it.
When I click the numpad decimal I get:
keypressed: KP_Delete .
Numpad enter:
keypressed: KP_Enter
(Note: after the word KP_Enter there's one of those little
rectangle characters)
Non-numpad Enter:
keypressed: KP_Enter
(Note: same as above)
Non-numpad Period:
keypressed: period .
-Jonathan
--- On Mon, 11/22/10, Hans-Christoph Steiner h...@at.or.at wrote:
From: Hans-Christoph Steiner h...@at.or.at
Subject: Re: [PD] Numpad decimal outputs wrong character
To: Jonathan Wilkes jancs...@yahoo.com
Cc: pd-list@iem.at
Date: Monday, November 22, 2010, 2:12 AM
You have to build it from source. The Tcl prompt is
under the Help
menu.
.hc
On Nov 21, 2010, at 7:47 PM, Jonathan Wilkes wrote:
--- On Mon, 11/22/10, Hans-Christoph Steiner h...@at.or.at
wrote:
From: Hans-Christoph Steiner h...@at.or.at
Subject: Re: [PD] Numpad decimal outputs wrong
character
To: Jonathan Wilkes jancs...@yahoo.com
Cc: pd-list@iem.at
Date: Monday, November 22, 2010, 1:30 AM
I can't find a version of 0.43 with the Tcl
prompt. The nightly
builds currently only have 0.42.
Sounds like a bug, try running this line in the
Tcl prompt
in 0.43:
bind all KeyPress {+pdtk_post keypressed:
%K
%A\n}
Then hit that key and reply with the results.
.hc
On Nov 9, 2010, at 2:46 AM, Jonathan Wilkes
wrote:
Hi,
I'm setting up a new
machine
running Hardy. It has a Dell 106-key
keyboard in which
the decimal on the number pad works fine with
everything (Ardour, Openoffice, Icecat, wish,
etc.)
_except_ Pd objects on a
canvas like object box, iemGUIs,
number/symbol/message
box, etc. However,
it does work in the Pd console, as well as
Properties
dialogues and any
tk widgets like [entry].
When I click the decimal key, [key] outputs
'127'. This is happening in
0.42-5 extended as well as Miller's
0.43-0test3. Any
ideas on what's going
on here?
Thanks,
Jonathan
___
Pd-list@iem.at
mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Mistrust authority - promote
decentralization. - the
hacker ethic
¡El pueblo unido jamás será vencido!
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
--- On Mon, 11/22/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at Date: Monday, November 22, 2010, 9:44 PM Attached is another example: 1. Select all the [clip] objects. 2. Move them so the [vsl] overlaps them. 3. Right-click the bottom [clip] and choose To front. It works as it should. 4. Now, with all the [clip] objects still selected, right-click on the same bottom [clip] and choose To back. It deselects all the other clips and only moves the bottom [clip] to the back. But shouldn't it instead move all the selected objects behind the [vsl]? You are correct. Just fixed this bug, changed the edit menu ordering and included to front/back options, added key shortcuts, added tidy up shortcut and increased its threshold which IMHO makes it much more usable. Regarding tidy up-- are you referring to XTOLERANCE, YTOLERANCE, and NHIST? If so, I posted a message awhile back with what seemed like some decent values, but in some cases it would swap the position of two objects in a row or column. Also, this behavior changed depending on the order in which those objects were created. (I have a feeling this is why those values are set so low.) If you post another tar.gz with your new tidy I'll see if I can reproduce this behavior. -Jonathan HTH ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Simple Subtractive Synth filter envelope
--- On Mon, 11/22/10, Claude Heiland-Allen claudiusmaxi...@goto10.org wrote: From: Claude Heiland-Allen claudiusmaxi...@goto10.org Subject: Re: [PD] Simple Subtractive Synth filter envelope To: pd-list@iem.at Date: Monday, November 22, 2010, 11:09 PM On 22/11/10 21:48, samuel rowe wrote: an envelope generator with ADSR vline~ is your friend here: 1 10, 0.5 100 10, 0 1000 2000 | [vline~] | [*~]\[osc~ 666] | [dac~] the output will not feed into the argument for a filter cutoff value. right. you can't connect signal outlets to message inlets: http://www-crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s4.2 Big problems with the text you are quoting: 1. 3rd paragraph, sentence one contradicts 3rd paragraph, sentence two. 2. The whole section is outdated because it doesn't mention the automatic conversion from float to signal. 3. The last paragraph/sentence of that section doesn't specify that the leftmost inlet of an abstraction cannot take both messages and audio (which is implied by paragraph 2, last sentence). 4. It is generally confusing to read in the first sentence that an xlet is either _for_ x or y, with y xlets accepting x some of the time. It might be clearer to just name the xlets: say xlets are _either_ control or signal xlets, then explain the difference (and that they are visually distinct). Here's a first attempt at a revision: 'There are two types of inlets and outlets in Pd: control and signal. Control inlets only accept messages, just as control outlets only output messages. Signal inlets accept audio, and may also accept messages; signal outlets, however, only output audio. Thus, it's an error to connect a signal outlet to a control inlet; usually this error is detected when the user tries to make the connection with the mouse (which will be prevented). Otherwise it is detected at sort time when audio is started or the network changed with audio running. For convenience, float messages arriving at a signal inlet will be converted to audio. Additionally, an object's leftmost signal inlet may accept other messages as well. Signal inlets/outlets, as well as signal connections, are visually distinct from control inlets/outlets.' -Jonathan and most of pd's filters (lop~, hip~, bp~, ...) expect messages for the parameters. the workaround is to use the raw filter objects to build more complex filters from poles and zeros. I made a resonant low pass filter using that method: http://lists.puredata.info/pipermail/pd-list/2007-11/056858.html [PD] pd filter with pole and zero Sat Nov 24 19:00:13 CET 2007 There are also externals with more filters (iemlib has many) and some abstractions out there somewhere. Good luck! Claude -- http://claudiusmaximus.goto10.org ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
--- On Tue, 11/23/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: RE: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: 'Jonathan Wilkes' jancs...@yahoo.com Cc: pd-list@iem.at Date: Tuesday, November 23, 2010, 2:27 AM Regarding tidy up-- are you referring to XTOLERANCE, YTOLERANCE, and NHIST? If so, I posted a message awhile back with I set it to 20 20 15 respectively and it seems to do the trick in tests I did so far. what seemed like some decent values, but in some cases it would swap the position of two objects in a row or column. Also, this behavior changed depending on the order in which those objects were created. (I have a feeling this is why those values are set so low.) If you post another tar.gz with your new tidy I'll see if I can reproduce this behavior. Oops, forgot to post this one, haven't I? :-) Same place, same links: http://l2ork.music.vt.edu/main/?page_id=56 Great, I'll play around with it a bit. -Jonathan HTH Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
--- On Tue, 11/23/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: RE: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: 'Jonathan Wilkes' jancs...@yahoo.com Cc: pd-list@iem.at Date: Tuesday, November 23, 2010, 2:27 AM Regarding tidy up-- are you referring to XTOLERANCE, YTOLERANCE, and NHIST? If so, I posted a message awhile back with I set it to 20 20 15 respectively and it seems to do the trick in tests I did so far. what seemed like some decent values, but in some cases it would swap the position of two objects in a row or column. Also, this behavior changed depending on the order in which those objects were created. (I have a feeling this is why those values are set so low.) If you post another tar.gz with your new tidy I'll see if I can reproduce this behavior. Oops, forgot to post this one, haven't I? :-) Same place, same links: http://l2ork.music.vt.edu/main/?page_id=56 Ok, this is looking familiar-- have a look at tidy-test.pd, select each group of objects one at a time and do 'tidy up': 1. Works as it should. 2. Objects are below the y-threshold, so they (understandably) collapse. 3. Works as it should. 4. Objects spaced 30 px apart vertically seem arbitrarily to no longer get tidy. 5. Horizontal row of objects gets tidy (with arbitrarily large space in between any two objects). Works as it should-- columns of objects should behave the same way. Now select all and tidy. Notice that #3 now gives different results. -Jonathan HTH Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
I forgot the attachment --- On Tue, 11/23/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: RE: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: 'Jonathan Wilkes' jancs...@yahoo.com Cc: pd-list@iem.at Date: Tuesday, November 23, 2010, 2:27 AM Regarding tidy up-- are you referring to XTOLERANCE, YTOLERANCE, and NHIST? If so, I posted a message awhile back with I set it to 20 20 15 respectively and it seems to do the trick in tests I did so far. what seemed like some decent values, but in some cases it would swap the position of two objects in a row or column. Also, this behavior changed depending on the order in which those objects were created. (I have a feeling this is why those values are set so low.) If you post another tar.gz with your new tidy I'll see if I can reproduce this behavior. Oops, forgot to post this one, haven't I? :-) Same place, same links: http://l2ork.music.vt.edu/main/?page_id=56 HTH Best wishes, Ico tidy-test.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
--- On Wed, 11/24/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Hans-Christoph Steiner h...@at.or.at Cc: pd-list@iem.at, 'João Pais' jmmmp...@googlemail.com Date: Wednesday, November 24, 2010, 12:10 AM Perhaps you'd be interested in my unreleased tkwidgets library, its in SVN. Basically, I am working on creating a framework to make it much easier to make GUI objects. Part of that framework includes things like resizing things with the mouse. I have that much working but its buggy still. Once that gets ironed out, I plan on making Pd versions of all the core Tk widgets, including the Tk canvas. In tkwdigets there is already a [text] object that works quite nicely, save a few bugs. I forgot to add, my experience with the iemgui code has told me that they would be very difficult to improve, hence the tkwidgets lib. Unfortunately, if it is not finished/stable, I am not interested in it as having to deal with Pd bugs in and of themselves is demanding enough on my time. On a flip side Scope~ external already has similar functionality which seems to me quite complete so it may be simply a matter of implementing that one (obviously it would only apply to iemgui objects as vanilla objects have no way of knowing their own size). Notice that both [cyclone/Scope~] and [flatspace/entry] have a bug: a sudden increase in height/width by about 5-10 pixels when you initially drag to resize. This makes it difficult if not impossible to make minor size changes (especially since there is no Properties dialogue). -Jonathan That said, I did spend most of today implementing Sarlo's feature as well as fixing buggy Tcl/Tk behavior (namely inability to show check marks in the edit menu which is so disheartening it is not even funny Wouldn't it be easier just to toggle the text for that menu option between Edit mode and Run mode? (That's what they're called in the manual.) --I really think Pd needs to wean itself away from the Tcl/Tk abomination even if that means losing a good chunk of its externals before it can thrive). How would you go about doing that? NB: I left out drop shadows part as it seems quite redundant. I also changed how the rest of the code behaves/looks to make it visually cleaner/more consistent. Apart from that latest update also includes edit menu highlighting (as 0.43 does to bypass Tcl/Tk buggy junk), improved shortucts for some of the calls, bugfix in the window list menu which for some reason omits parent window listing, and other minor cosmetic fixes (e.g. highlighting color changed to orange as I feel it is much easier on my eyes). If interested, check out the latest snapshot at the usual place: http://l2ork.music.vt.edu/main/?page_id=56 Cheers! ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
--- On Wed, 11/24/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: RE: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: 'Jonathan Wilkes' jancs...@yahoo.com Cc: pd-list@iem.at Date: Wednesday, November 24, 2010, 6:29 AM Notice that both [cyclone/Scope~] and [flatspace/entry] have a bug: a sudden increase in height/width by about 5-10 pixels when you initially drag to resize. This makes it difficult if not impossible to make minor size changes (especially since there is no Properties dialogue). Good to know. I will look into this when I get there. Currently working on accelerating iemgui objects as well as exposing them to sarlo's highlighting magic. Also notice that [flatspace/entry] has a nice cursor associated with resizing. Wouldn't it be easier just to toggle the text for that menu option between Edit mode and Run mode? (That's what they're called in the manual.) Sure. There are other options, too, like the one 0.43 and now l2ork version of 0.42 uses by changing option's background which works visually relatively well (albeit at the expense of consistency). This is however not the issue. The issue is finding out that after an hour of debugging the problem is not in you or your code but the toolkit you are using and in 2010 for a toolkit that has been around for more than a decade that is plainly sad. Another solution: you can also place a checkbutton labeled Edit mode directly on the menubar. Also, since we're talking about the menu changes: Since there is a Find menu, I think the Edit menu can be shortened by removing Find, Find again, and Find last error. How would you go about doing that? A: Ugly path: Isolate pd-gui hooks and port the entire thing to Qt. B: Better (albeit more time-consuming) path: clean-up code first so that all objects can utilize the same gobj_whatever calls and then do the A: (which at that point won't be nearly as ugly or difficult to maintain). FWIW, my first ever GUI app was RTMix I did back in 2001 and it was (and remains) the ugliest hack ever (basically I tried to learn how to program doing that app). Yet, the fact remains even in 2001 qt was way better than what Tk is today. Another advantage is avoiding socket bottlenecks as the entire thing could be done simply in C. License-wise it should be fine and cross-platform-wise miles ahead of Tcl/Tk. Heck, you could even throw in Qt for mobile devices for good measure since that is apparently hot item these days. That said, I need some more time working with Pd code before I can undertake this. Perhaps more importantly, I just need a generous, uninterrupted chunk of time to do this. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
--- On Wed, 11/24/10, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: RE: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Ivica Ico Bukvic i...@vt.edu Cc: 'Jonathan Wilkes' jancs...@yahoo.com, pd-list@iem.at Date: Wednesday, November 24, 2010, 11:54 PM On Wed, 2010-11-24 at 14:06 -0500, Ivica Ico Bukvic wrote: I just realize that there are two iemgui libs in a sense: there are the iemgui objects that have been included in Pd-vanilla for 10 years, those are the ones I was referring to. Then there is the new iemgui library in pure-data SVN, I know little about that one. Which one are you referring to? I am referring to the one that has been a part of pd for a long time. This is the one I just updated in the latest release so that moving of its widgets in edit mode is now a part of a single move-by-tag call. I am actually quite pleased how it works now. That sounds like something that should have been done a while ago. My big worry here is regression bugs. So we'll need to come up with a bunch of tests so we can make sure the faster code doesn't introduce bugs. I think the only place we are going to see big benefits for move code is in redrawing arrays, the drawing is pretty simple in most other GUI objects. FYI, 0.43 fixes this issue by changing the 'editmode' message so that 1 means editmode is on, and 0 means editmode is off. Before that, the 'editmode' message toggled edit mode. That's what made it so difficult to make the menu item checkbox work. These are the kinds of things that I have spent many many hours working to fix, so it makes me sad to see you reinventing the wheel. I am not reinventing wheel in this case but simply backporting your solution (unless you are referring to me wasting hours as you did on the Tcl widget bug as the actual reinventing of the wheel). Either way, the checkmark next to the checkbutton widget is simply buggy and does not show up when it should (e.g. when invoking the widget). This is the case even with 0.43 gui rewrite. The only way one can see that the option has been activated on 0.43 (and now on l2ork iteration of 0.42) is by the fact edit mode option in the menu has changed its background color to green (which actually does not look all that bad, even though it is inconsistent with general menu UI guidelines Tcl/Tk is supposedly trying so hard to enforce). Yeah, I hear you. I think the background color thing works well for GNOME, not sure about anything else tho. Changing the text between Edit Mode and Play Mode is a viable option for all platforms IMHO. If you do this please call it Run mode and not Play mode. It's run mode in the manual, as well as a lot of the docs, tutorials, and internal help patches. Peter Brinkmann, Peter Kirn, Miller and I all had a meeting recently to discuss the idea of making 'pd' a separate entity. My part is making pd talk to pd-gui using pd messages, then it should be pretty straightforward to making new GUIs in lots of different toolkits. As long as those messages are not something that needs to be sent via socket but can be also prototyped into direct function calls within C. Otherwise, the solution simply perpetuates the existing problem of socket and string parser saturation, resulting in very slow performance. Notice that even with l2ork iteration of pd-extended where everything vanilla now uses move-by-tag approach (in other words one call moves all selected widgets except for GOPs which are quite messy thus resulting in one call vs. potentially hundreds if not thousands) and which ostensibly approaches ideal performance via socket, it still gets relatively easily bogged down due to inherent overhead. I think there are advantages to having the GUI be a separate process, and it would be worth exploring other ways of havning pd and pd-gui talk. Shared memory is one idea. Plus for things like arrays, the data could be sent as binary thereby skipping the string parsing aspect. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
--- On Thu, 11/25/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: RE: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at Date: Thursday, November 25, 2010, 4:53 AM Also notice that [flatspace/entry] has a nice cursor associated with resizing. Noted. I will look into this once bug hunt is over. Thanks for the tip! Another solution: you can also place a checkbutton labeled Edit mode directly on the menubar. Yes, except personally I would prefer to keep the pd window as clean as possible. Also, since we're talking about the menu changes: Since there is a Find menu, I think the Edit menu can be shortened by removing Find, Find again, and Find last error. Done. This will be included in the next tarball (even though it goes against Msft/Apple design guidelines. Well, you could also go the other way and just get rid of the Find menu altogether. It's just the redundancy I'd like to get rid of the redudancy. :) -Jonathan Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
If I delete all the [clip] objects in the attached patch, it becomes much faster to select and move the toggle objects. Why is that? I mean, the number of selected objects is the same either way. Do the [clip]s get redrawn every time I move the selection? -Jonathan lots-of-objects.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
--- On Thu, 11/25/10, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Thursday, November 25, 2010, 5:39 AM On Nov 24, 2010, at 7:37 PM, Jonathan Wilkes wrote: --- On Wed, 11/24/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: RE: [PD] call for testers for L2Ork iteration of pd- extended (based on 0.42.x branch) To: 'Jonathan Wilkes' jancs...@yahoo.com Cc: pd-list@iem.at Date: Wednesday, November 24, 2010, 6:29 AM Notice that both [cyclone/Scope~] and [flatspace/entry] have a bug: a sudden increase in height/width by about 5-10 pixels when you initially drag to resize. This makes it difficult if not impossible to make minor size changes (especially since there is no Properties dialogue). Good to know. I will look into this when I get there. Currently working on accelerating iemgui objects as well as exposing them to sarlo's highlighting magic. Also notice that [flatspace/entry] has a nice cursor associated with resizing. Ah yes, I forgot about that cursor in entry. I actually started working on improving the [entry] widget, and that turned into the tkwidgets library. I really should get the tkwidgets stuff into some kind of usable release. Let me know if you do this. I've got a pd patch that is a fully functioning object-search GUI which is currently using toxy. I posted some screenshots a few weeks ago. I'll switch it over to use tkwidgets if you can get the library to do the following: 1) use tab key to give focus to the next widget in the patch 2) do nonlocal send/receive names like iemguis 3) have a message to set widget focus (so it can have focus on loadbang like Google's text entry, for example) 4) output entry string as a list so that, for example, typing 'float' will output 'list float'. (Actually it could also output it as a symbol-- just as long as it doesn't output an anything.) I think I also had a short list of general bugs posted a few weeks back. -Jonathan .hc Wouldn't it be easier just to toggle the text for that menu option between Edit mode and Run mode? (That's what they're called in the manual.) Sure. There are other options, too, like the one 0.43 and now l2ork version of 0.42 uses by changing option's background which works visually relatively well (albeit at the expense of consistency). This is however not the issue. The issue is finding out that after an hour of debugging the problem is not in you or your code but the toolkit you are using and in 2010 for a toolkit that has been around for more than a decade that is plainly sad. Another solution: you can also place a checkbutton labeled Edit mode directly on the menubar. Also, since we're talking about the menu changes: Since there is a Find menu, I think the Edit menu can be shortened by removing Find, Find again, and Find last error. How would you go about doing that? A: Ugly path: Isolate pd-gui hooks and port the entire thing to Qt. B: Better (albeit more time-consuming) path: clean-up code first so that all objects can utilize the same gobj_whatever calls and then do the A: (which at that point won't be nearly as ugly or difficult to maintain). FWIW, my first ever GUI app was RTMix I did back in 2001 and it was (and remains) the ugliest hack ever (basically I tried to learn how to program doing that app). Yet, the fact remains even in 2001 qt was way better than what Tk is today. Another advantage is avoiding socket bottlenecks as the entire thing could be done simply in C. License-wise it should be fine and cross-platform-wise miles ahead of Tcl/Tk. Heck, you could even throw in Qt for mobile devices for good measure since that is apparently hot item these days. That said, I need some more time working with Pd code before I can undertake this. Perhaps more importantly, I just need a generous, uninterrupted chunk of time to do this. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list [T]he greatest purveyor of violence in the world today [is] my own government. - Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
--- On Thu, 11/25/10, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Thursday, November 25, 2010, 5:40 AM On Nov 24, 2010, at 7:46 PM, Jonathan Wilkes wrote: --- On Wed, 11/24/10, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: RE: [PD] call for testers for L2Ork iteration of pd- extended (based on 0.42.x branch) To: Ivica Ico Bukvic i...@vt.edu Cc: 'Jonathan Wilkes' jancs...@yahoo.com, pd-list@iem.at Date: Wednesday, November 24, 2010, 11:54 PM On Wed, 2010-11-24 at 14:06 -0500, Ivica Ico Bukvic wrote: I just realize that there are two iemgui libs in a sense: there are the iemgui objects that have been included in Pd-vanilla for 10 years, those are the ones I was referring to. Then there is the new iemgui library in pure-data SVN, I know little about that one. Which one are you referring to? I am referring to the one that has been a part of pd for a long time. This is the one I just updated in the latest release so that moving of its widgets in edit mode is now a part of a single move-by-tag call. I am actually quite pleased how it works now. That sounds like something that should have been done a while ago. My big worry here is regression bugs. So we'll need to come up with a bunch of tests so we can make sure the faster code doesn't introduce bugs. I think the only place we are going to see big benefits for move code is in redrawing arrays, the drawing is pretty simple in most other GUI objects. FYI, 0.43 fixes this issue by changing the 'editmode' message so that 1 means editmode is on, and 0 means editmode is off. Before that, the 'editmode' message toggled edit mode. That's what made it so difficult to make the menu item checkbox work. These are the kinds of things that I have spent many many hours working to fix, so it makes me sad to see you reinventing the wheel. I am not reinventing wheel in this case but simply backporting your solution (unless you are referring to me wasting hours as you did on the Tcl widget bug as the actual reinventing of the wheel). Either way, the checkmark next to the checkbutton widget is simply buggy and does not show up when it should (e.g. when invoking the widget). This is the case even with 0.43 gui rewrite. The only way one can see that the option has been activated on 0.43 (and now on l2ork iteration of 0.42) is by the fact edit mode option in the menu has changed its background color to green (which actually does not look all that bad, even though it is inconsistent with general menu UI guidelines Tcl/Tk is supposedly trying so hard to enforce). Yeah, I hear you. I think the background color thing works well for GNOME, not sure about anything else tho. Changing the text between Edit Mode and Play Mode is a viable option for all platforms IMHO. If you do this please call it Run mode and not Play mode. It's run mode in the manual, as well as a lot of the docs, tutorials, and internal help patches. Right, I'm proposing changing it everywhere. run mode implies that things aren't running in edit mode, which is definitely not true. By that logic play mode implies that things aren't playing in edit mode, which is definitely not true either. Either way it takes a few seconds to notice that: [osc~ 420] | [*~ 0.1] |\ [dac~] is 'playing'/'running'/'producing music' regardless of which mode Pd is in (as long as DSP is turned on). Changing all instances of 'run mode' to 'play mode' is a lot of work for very little gain. Not changing anything is no gain, yet no work. (I would vote for the latter but given the context that seems like too much work.) -Jonathan .hc Peter Brinkmann, Peter Kirn, Miller and I all had a meeting recently to discuss the idea of making 'pd' a separate entity. My part is making pd talk to pd-gui using pd messages, then it should be pretty straightforward to making new GUIs in lots of different toolkits. As long as those messages are not something that needs to be sent via socket but can be also prototyped into direct function calls within C. Otherwise, the solution simply perpetuates the existing problem of socket and string parser saturation, resulting in very slow performance. Notice that even with l2ork iteration of pd-extended where everything vanilla now uses move-by-tag approach (in other words one call moves all selected widgets except for GOPs which are quite messy thus resulting in one call vs. potentially hundreds if not thousands
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
--- On Thu, 11/25/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: IOhannes m zmölnig zmoel...@iem.at Cc: pd-list@iem.at Date: Thursday, November 25, 2010, 7:18 PM thanks for sharing. a couple of very minor remarks: - - your webpage froze firefox/iceweasel on my eeepc the first time i accessed it; i assume this is due to the animated tagcloud. is there any conceptual reason for maaking a navigation aid eat 100% on 2 cores? I wish I had an answer for you as the cloud is pure javascript and it works just fine on my MSI wind U100 netbook (single core with hyperthreading, so I guess you could call it Intel's fake 2 cores) as well as on my Android phone (where it is somewhat slow but does not impede the rest of the webpage). I would love to hear from the others as well regarding this, because if this problem is more widespread I will look into altering/replacing it with something else. once i managed to download it, i only played a few minutes with it, so.. - - when releasing tarballs you should get rid of the .svn folders; these hold a copy of all files, so you could reduce the size of the unpacked bundle to about 50% Unfortunately in my case it had no difference whatsoever as I've not used svn on this branch in some time. I believe the binaries are what is causing the tarball to be as large as it is. At any rate, I will reupload it without the .svn folder. - - the magnifying glass (i think you all refer to the Patch cord viewer (or cord inspector how i would call it) by this term), is a very nice feature. what i find weird is, that i can only switch to cord viewing when in edit mode; Ctrl-r in Run-mode simple doesn't do anything; i would expect to switch my patch into run mode if needed Well, this is the way original Sarlo's code works, so I haven't given it much thought until now. Now that you brought it up, I feel like the current design makes more sense as the cord monitoring undoubtedly saps some of the CPU and as such one would probably not want to run it in runtime/performance mode anyhow. OTOH if you are looking to monitor what passes through the cords, this in and of itself suggests you are likely troubleshooting something and as such are looking to edit the patch anyhow, so based on these two observations alone I would say the current behavior makes sense. Then again, I may be missing something here in which case I would certainly like to hear opinions from others as well. All that said, I like your term better. - - the inlet highlighting (this looks more like a magnifying glass to me) is a nice idea but it doesn't really help yet. e.g. with objects that have more inlets then available width (e.g. [pix_info]) you still have the same problem as before (though a bit bigger); i also think that the magnification amount is a bit too small, but this might be due to my very small screen size (at first i wouldn't even notice a real difference then to the original connection cursor). it would probably be a good idea to let the user change the amount of magnification) Good idea. I'll add this to the todo (shouldn't be too hard--it really simply boils down to designing the edit menu and providing appropriate hooks). That said, what would be even better is simply adding a tooltip that reflects which inlet/outlet is selected and what it does. This was recently discussed and with the highlighting in place this would boil down to simply adding another two arrays to glist and filling them with per-object descriptors (this last part being the biggest pain as it would have to be added pd-wide). In the interim, it could simply check for null entries and ignoring those that have not been implemented. I think I'll take a stab at this one soon. Before you do, you should ask Miller what exactly his comments mean in: http://sourceforge.net/tracker/index.php?func=detailaid=1056914group_id=55736atid=478072 Also see: http://sourceforge.net/tracker/index.php?func=detailaid=2838176group_id=55736atid=478072 - - why is the default selection color orange/red? is this a pd-extended thing? for me this is very close to the error-indicating color red (e.g. when an object fails to create) Because I find it hard to discern between blue and black (selected vs. deselected) on such thin lines that constitute most of the gui and which occurs a lot more often than the red invalid objects. That said, I will up the width on the red objects which should solve this problem. I find the orange text _very_ difficult to read. - - something i think is only inherited from pd-extended, but whiich makes me shout out loud, is that when i start pd-l2ork it creates a pd-externals folder in my home directory. even if i don't do
Re: [PD] non-logical receives
You can set the receive-name of all iem-guis. Also, see [maxlib/remote] * -Jonathan * I found this using my Object Search path. --- On Fri, 11/26/10, Andrew Faraday jbtur...@hotmail.com wrote: From: Andrew Faraday jbtur...@hotmail.com Subject: [PD] non-logical receives To: pd-list@iem.at Date: Friday, November 26, 2010, 11:47 PM Hey All This might be a simple problem, but I can't see a way around it. I'm making a patch involving a grid of toggles (each in an abstraction, so they can have rules to control them individually, also to relay this grid to a grid of squares in gem). Basically I've already set up [s $1-$2-state], in each to send it's position to a named bus. I've also got r $1-$2-control to control each toggle remotely, but that's aside. I can use messages and non-logical sends to generate control messages, like so: [pack f f f]|[$1-$2-control $3 ( Which can change any of the toggles on my grid. So far, all well and good. ==However== What I really need is for each abstraction to be 'aware' of it's neighbors. So while each one has two arguments, (it's co-ordinates on the grid), I need them to have receives based on it's arguments and some arithmetic. I could generate the right string for this like [$1] [$2]| |[+ 1] [+ 1]| |[pack f f] |[$1-$2-state( But I don't know of an object I can set like this. I can't find a receive which can be set with a message (in the same way that the non-logical sends can be made in a message box, it's all very perplexing). As ever, help would be appreciated Andrew -Inline Attachment Follows- ___ 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] non-logical receives
Oops, [remote] does the opposite of what you want! See [receive13] -- though there's no help patch for it, sending a set message seems to work. -Jonathan --- On Sat, 11/27/10, Jonathan Wilkes jancs...@yahoo.com wrote: From: Jonathan Wilkes jancs...@yahoo.com Subject: Re: [PD] non-logical receives To: pd-list@iem.at, Andrew Faraday jbtur...@hotmail.com Date: Saturday, November 27, 2010, 12:01 AM You can set the receive-name of all iem-guis. Also, see [maxlib/remote] * -Jonathan * I found this using my Object Search path. --- On Fri, 11/26/10, Andrew Faraday jbtur...@hotmail.com wrote: From: Andrew Faraday jbtur...@hotmail.com Subject: [PD] non-logical receives To: pd-list@iem.at Date: Friday, November 26, 2010, 11:47 PM Hey All This might be a simple problem, but I can't see a way around it. I'm making a patch involving a grid of toggles (each in an abstraction, so they can have rules to control them individually, also to relay this grid to a grid of squares in gem). Basically I've already set up [s $1-$2-state], in each to send it's position to a named bus. I've also got r $1-$2-control to control each toggle remotely, but that's aside. I can use messages and non-logical sends to generate control messages, like so: [pack f f f]|[$1-$2-control $3 ( Which can change any of the toggles on my grid. So far, all well and good. ==However== What I really need is for each abstraction to be 'aware' of it's neighbors. So while each one has two arguments, (it's co-ordinates on the grid), I need them to have receives based on it's arguments and some arithmetic. I could generate the right string for this like [$1] [$2]| |[+ 1] [+ 1]| |[pack f f] |[$1-$2-state( But I don't know of an object I can set like this. I can't find a receive which can be set with a message (in the same way that the non-logical sends can be made in a message box, it's all very perplexing). As ever, help would be appreciated Andrew -Inline Attachment Follows- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -Inline Attachment Follows- ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
--- On Sat, 11/27/10, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Jonathan Wilkes jancs...@yahoo.com Cc: Ivica Ico Bukvic i...@vt.edu, pd-list@iem.at Date: Saturday, November 27, 2010, 4:54 PM On Wed, 24 Nov 2010, Jonathan Wilkes wrote: Another solution: you can also place a checkbutton labeled Edit mode directly on the menubar. Is this compatible with OSX ? I don't know. I actually tried three things: 1) Leaving the 'Edit mode' entry in the 'Edit' menu, setting -indicatoron to false, and toggling the label from 'Edit mode' to 'Run mode' 2) Doing a checkbutton with an indicator right on the menubar 3) Doing a checkbutton with the indicator off right on the menubar and toggling the label as in #1 above. I think 1 and 3 worked fine in osx. Actually I also tried a fourth thing: Destroy the menubar when in 'Run mode'. (Not sure how that would work on osx, but in Gnome it sure makes an obvious distinction between modes!) -Jonathan ___ | Mathieu Bouchard - Aix-en-Provence ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
The ctrl-Enter functionality is missing. In normal pd-ext 0.42-5 (on Hardy) I can: 1. Click ctrl-1 and type the name of the object. 2. Click ctrl-Enter to instantiate the object and have it selected. 3. Click ctrl-d and have a new, unconnected object which I can Shift-arrow where I want it, then click ctrl-Enter again to change the object name to something else. -Jonathan --- On Sun, 11/28/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...) To: András Murányi muran...@gmail.com Cc: PD List pd-list@iem.at Date: Sunday, November 28, 2010, 12:18 AM On Sat, 2010-11-27 at 20:44 +0100, András Murányi wrote: with today's build, i got this upon clicking a [tgl] in a nested GOP (couldn't reproduce it from scratch) Figured this one out--forgot to update one place in the g_numbox.c actually. It should be fine now. That said, there are still a few gop problems when using gop within gop and I've traced these down to the fact that tcl/tk tends to recycle window_names for some reason (not sure if this is a part of the undo/redo/cut/copy/paste system or native tcl/tk). Anyone has any idea? http://l2ork.music.vt.edu/main/?page_id=56 Cheers! ___ 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] zexy/demultiplex help patch
Here's a problem I've run into: 1. Launch Pd-ext. 2. Create new patch. 3. Create [demux]. 4. Notice console message. 5. Right-click and choose help. 6. Notice console error: couldn't find help patch. 7. No help patch for [demultiplex] either, but there is one for [zexy/demultiplex]. (Notice, however, that [zexy/demux] won't even create.) Now try the whole process, but in step 3 create [demultiplex] instead of [demux]. Now all the help patches are found (though zexy/demux still won't create). What's going on? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
Question about the cord inspector: is it feasible to make the font size scale with the 'Edit' menu font bomb dialogue? I know the whole font situation in Pd is problematic, but currently the font bomb dialogue is the only way to make patches readable when projecting them on a large screen. So it would be helpful to have the cord inspector be at the same font size as the rest of the patch. -Jonathan --- On Sat, 11/27/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...) To: András Murányi muran...@gmail.com, PD List pd-list@iem.at Date: Saturday, November 27, 2010, 9:45 PM Thx for the report. Let me investigate once I get back home. András Murányi muran...@gmail.com wrote: with today's build, i got this upon clicking a [tgl] in a nested GOP (couldn't reproduce it from scratch) *** buffer overflow detected ***: ./pd terminated === Backtrace: = /lib/libc.so.6(__fortify_fail+0x37)[0x7f7189d6d217] /lib/libc.so.6(+0xfe0d0)[0x7f7189d6c0d0] /lib/libc.so.6(+0xfd539)[0x7f7189d6b539] /lib/libc.so.6(_IO_default_xsputn+0xcc)[0x7f7189ce3d1c] /lib/libc.so.6(_IO_vfprintf+0x14c)[0x7f7189cb34ec] /lib/libc.so.6(__vsprintf_chk+0x99)[0x7f7189d6b5d9] /lib/libc.so.6(__sprintf_chk+0x7f)[0x7f7189d6b51f] ./pd[0x479cd4] ./pd(sys_pollgui+0xb8)[0x49ed78] ./pd(m_mainloop+0x84b)[0x4984db] ./pd(sys_main+0x225)[0x49d0b5] /lib/libc.so.6(__libc_start_main+0xfd)[0x7f7189c8cc4d] ./pd[0x414159] === Memory map: 0040-0050b000 r-xp 08:12 2769414 /home/muranyia/Download/pd/bin/pd 0070a000-0070b000 r--p 0010a000 08:12 2769414 /home/muranyia/Download/pd/bin/pd 0070b000-0070d000 rw-p 0010b000 08:12 2769414 /home/muranyia/Download/pd/bin/pd 0070d000-00b1d000 rw-p 00:00 0 01694000-0d33e000 rw-p 00:00 0 [heap] 7f71798b6000-7f71798b8000 r-xp 08:12 877193 /usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux 7f71798b8000-7f7179ab7000 ---p 2000 08:12 877193 /usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux 7f7179ab7000-7f7179ab8000 r--p 1000 08:12 877193 /usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux 7f7179ab8000-7f7179ab9000 rw-p 2000 08:12 877193 /usr/lib/pd-extended/extra/iemlib/add2_comma.pd_linux 7f7179ab9000-7f7179aba000 r-xp 08:12 459292 /usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux 7f7179aba000-7f7179cba000 ---p 1000 08:12 459292 /usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux 7f7179cba000-7f7179cbb000 r--p 1000 08:12 459292 /usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux 7f7179cbb000-7f7179cbc000 rw-p 2000 08:12 459292 /usr/lib/pd-extended/extra/tof/to_ascii_code.pd_linux 7f7179cbc000-7f7179cbd000 r-xp 08:12 880139 /usr/lib/pd-extended/extra/maxlib/divmod.pd_linux 7f7179cbd000-7f7179ebc000 ---p 1000 08:12 880139 /usr/lib/pd-extended/extra/maxlib/divmod.pd_linux 7f7179ebc000-7f7179ebd000 r--p 08:12 880139 /usr/lib/pd-extended/extra/maxlib/divmod.pd_linux 7f7179ebd000-7f7179ebe000 rw-p 1000 08:12 880139 /usr/lib/pd-extended/extra/maxlib/divmod.pd_linux 7f7179ebe000-7f7179ec2000 r-xp 08:12 1467325 /usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux 7f7179ec2000-7f717a0c1000 ---p 4000 08:12 1467325 /usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux 7f717a0c1000-7f717a0c2000 r--p 3000 08:12 1467325 /usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux 7f717a0c2000-7f717a0c3000 rw-p 4000 08:12 1467325 /usr/lib/pd-extended/extra/iemgui/iem_image.pd_linux 7f717a0c3000-7f717a0c7000 r-xp 08:12 911395 /usr/lib/pd-extended/extra/flatspace/popup.pd_linux 7f717a0c7000-7f717a2c6000 ---p 4000 08:12 911395 /usr/lib/pd-extended/extra/flatspace/popup.pd_linux 7f717a2c6000-7f717a2c7000 r--p 3000 08:12 911395 /usr/lib/pd-extended/extra/flatspace/popup.pd_linux 7f717a2c7000-7f717a2c8000 rw-p 4000 08:12 911395 /usr/lib/pd-extended/extra/flatspace/popup.pd_linux 7f717a2c8000-7f717a2ce000 r-xp 08:12 2762244 /usr/lib/pd-extended/extra/cyclone/switch.pd_linux 7f717a2ce000-7f717a4cd000 ---p 6000 08:12 2762244 /usr/lib/pd-extended/extra/cyclone/switch.pd_linux 7f717a4cd000-7f717a4ce000 r--p 5000 08:12 2762244 /usr/lib/pd-extended/extra/cyclone/switch.pd_linux 7f717a4ce000-7f717a4cf000 rw-p 6000 08:12 2762244 /usr/lib/pd-extended/extra/cyclone/switch.pd_linux 7f717a4cf000-7f717a4d6000 r-xp 08:12 2762328 /usr/lib/pd-extended/extra/cyclone/prepend.pd_linux 7f717a4d6000-7f717a6d5000 ---p 7000 08:12 2762328 /usr/lib/pd-extended/extra/cyclone/prepend.pd_linux 7f717a6d5000-7f717a6d6000 r--p 6000 08:12 2762328 /usr/lib/pd-extended/extra/cyclone/prepend.pd_linux 7f717a6d6000-7f717a6d7000 rw-p 7000 08:12 2762328 /usr/lib/pd-extended/extra/cyclone/prepend.pd_linux 7f717a6d7000-7f717a6d8000 r-xp 08:12 1630422
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
Small detail-- your 'Put' menu is tearoff-able. -Jonathan --- On Sun, 11/28/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...) To: András Murányi muran...@gmail.com Cc: PD List pd-list@iem.at Date: Sunday, November 28, 2010, 12:18 AM On Sat, 2010-11-27 at 20:44 +0100, András Murányi wrote: with today's build, i got this upon clicking a [tgl] in a nested GOP (couldn't reproduce it from scratch) Figured this one out--forgot to update one place in the g_numbox.c actually. It should be fine now. That said, there are still a few gop problems when using gop within gop and I've traced these down to the fact that tcl/tk tends to recycle window_names for some reason (not sure if this is a part of the undo/redo/cut/copy/paste system or native tcl/tk). Anyone has any idea? http://l2ork.music.vt.edu/main/?page_id=56 Cheers! ___ 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] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
Hi, Here are some scrolling observations: In the attached patch, drag the [pd] object far down into the bottom right-hand corner, so that you get some scrollbars to appear. Now, on the current pd-extended, you can scroll down to that object, and when you drag it back to its original location, the scrollbars respond in realtime so that the object swoops back up the patch until, finally, the scrollbars disappear. In your version the scrollbars don't react until you stop dragging and release the mouse button. Just an observation-- I suppose both methods have their strengths and weaknesses. I prefer the current Pd-ext behavior-- for example, if I happen to paste an object into another patch with a smaller window size, it makes it quick to drag it back up. But notice that once you drag the [pd] object back near its original position, the [f] object looks as if it's at (0,0), when it's really at (10,10). However, if you save the patch and reopen it the [f] will appear at its proper, original position-- (10,10). I think this is a bug, because it means any time one adds or takes away the scrollbars the absolute positioning of the objects on the canvas is temporarily lost, forcing the user to close and open to see the real positioning. -Jonathan scrolling.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
--- On Mon, 11/29/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...) To: Jonathan Wilkes jancs...@yahoo.com Cc: András Murányi muran...@gmail.com, PD List pd-list@iem.at Date: Monday, November 29, 2010, 8:34 AM On Sat, 2010-11-27 at 23:18 -0800, Jonathan Wilkes wrote: Hi, Here are some scrolling observations: In the attached patch, drag the [pd] object far down into the bottom right-hand corner, so that you get some scrollbars to appear. Now, on the current pd-extended, you can scroll down to that object, and when you drag it back to its original location, the scrollbars respond in realtime so that the object swoops back up the patch until, finally, the scrollbars disappear. In your version the scrollbars don't react until you stop dragging and release the mouse button. Just an observation-- I suppose both methods have their strengths and weaknesses. I prefer the current Pd-ext behavior-- for example, if I happen to paste an object into another patch with a smaller window size, it makes it quick to drag it back up. But notice that once you drag the [pd] object back near its original position, the [f] object looks as if it's at (0,0), when it's really at (10,10). However, if you save the patch and reopen it the [f] will appear at its proper, original position-- (10,10). I think this is a bug, because it means any time one adds or takes away the scrollbars the absolute positioning of the objects on the canvas is temporarily lost, forcing the user to close and open to see the real positioning. -Jonathan Both of these are actually a feature. I actually used to have real-time scrollbar updates but that simply bogged the cpu down too much, so I opted to updating them only once an object has stopped moving which in most if not all cases makes perfect sense. That makes sense. It will make cutting and pasting from a different window size a bit more difficult (because objects are pasted at the coords from the original patch) but unless pasting from the bottom corner of a 1000px canvas it shouldn't make much difference. The reason canvas is displaced in l2ork version is because our philosophy is if a patch can fit in a window, it should. Granted, it has some shortcomings like patches opening and then having to readjust as well as having them not (0,0)-centric which makes them potentially less compatible with vanilla version. That said, I believe this is a much better way of dealing with patches, and if one really wants to lock-in patch positioning, they should simply use a cnv (canvas) object whose name in many ways suggests exactly that. NB: repositioning of window upon load can be avoided only if the format of saving the patch also includes the top-left corner of the canvas, which current format does not support. Please note that l2ork's scrolling algorithm also accounts for all other operations, such as undo/redo/cut/copy/paste, even key presses that may extend the width of an object. Cheers! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...)
--- On Mon, 11/29/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] L2Ork pd-extended release candidate 1 now available (was: Re: call for testers...) To: Jonathan Wilkes jancs...@yahoo.com Cc: András Murányi muran...@gmail.com, PD List pd-list@iem.at Date: Monday, November 29, 2010, 8:53 AM OK, release candidate 2 is now up with following changes: [...] *cord inspector uses globally defined font size This is turning out to be a wonderful tool: [bang( | [f]x[+ 1] 1) Turn on cord inspector 2) In edit mode, mouse over one of the cords so the inspector appears. 3) Hold down ctrl to go into transient run mode 4) The inspector stays where it is. Awesome! Keep ctrl down and go click the bng and watch your data flow without the need for any number boxes or [print]! -Jonathan *removed xy stretch option from the font menu as it appears to be unstable *corrected text color on pd patcher Latest snapshot is available at: http://l2ork.music.vt.edu/main/?page_id=56 As always, feedback is most appreciated. Cheers! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
--- On Mon, 11/29/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at Date: Monday, November 29, 2010, 9:11 PM I think 1 and 3 worked fine in osx. Actually I also tried a fourth thing: Destroy the menubar when in 'Run mode'. (Not sure how that would work on osx, but in Gnome it sure makes an obvious distinction between modes!) -Jonathan In L2Ork iteration this functionality is available per-canvas and is toggled via l2ork_toggle_menubar abstraction. This way one can have a mix of guis having one and/or the other. Cheers! Ico Yes, I've been using a msg + [toxy] to do the same thing-- unfortunately you can see the menu getting deleted when you open the patch or make it visible again. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
Hi Ivica, Since you've been rooting around in the Pd source, I wanted to bring up an idea about canvas properties and get your opinion on it: If you look at the coords for a particular canvas, the 7th argument currently controls GOP status. 0 = no GOP 1 = GOP 2 = GOP + hide args But what if this argument were thought of as controlling canvas visibility in a more general way: -2 = no menu, no scroll -1 = no menu 0 = normal 1 = GOP 2 = GOP + hide args That way it's not necessary to use an abstraction to hide the menu, plus it can be set the way it should be set-- in the canvas properties menu. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
--- On Sun, 12/5/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Jonathan Wilkes jancs...@yahoo.com, Hans-Christoph Steiner h...@at.or.at Cc: 'PD List' pd-list@iem.at Date: Sunday, December 5, 2010, 3:33 AM Great suggestion! That might work quite nicely. We only have to make sure for legacy purposes that wherever in the old code this variable is being checked that it can gracefully handle values less than 0. That said, my top priority as of right now is further testing current code as well as continuing to work on my neck piece. Beyond that I would like to make all iem objects resizable via GUI, revamp the to-front and to-back algorithm so that it does not rely upon undo, followed by an infinite undo, and then tooltips, improved color picker, improve upon the tidy algorithm, and then weed through the documentation and externals and only keep those that are well maintained and are not redundant. Your suggestion might fit nicely somewhere inside here as well. And where does merging your changes in with pd-extended 0.43 fit into all this? I would also like to see Qt-ified (or better yet juce-ified) version of the whole thing. This will however have to wait. Long story short it might be a while before I make the next big push. In the meantime, as always, contributions will be most welcome provided they do not break the backwards compatibility. Cheers! Ico Jonathan Wilkes jancs...@yahoo.com wrote: Hi Ivica, Since you've been rooting around in the Pd source, I wanted to bring up an idea about canvas properties and get your opinion on it: If you look at the coords for a particular canvas, the 7th argument currently controls GOP status. 0 = no GOP 1 = GOP 2 = GOP + hide args But what if this argument were thought of as controlling canvas visibility in a more general way: -2 = no menu, no scroll -1 = no menu 0 = normal 1 = GOP 2 = GOP + hide args That way it's not necessary to use an abstraction to hide the menu, plus it can be set the way it should be set-- in the canvas properties menu. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
--- On Mon, 12/6/10, i...@vt.edu i...@vt.edu wrote: From: i...@vt.edu i...@vt.edu Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: Jonathan Wilkes jancs...@yahoo.com Cc: Hans-Christoph Steiner h...@at.or.at, 'PD List' pd-list@iem.at Date: Monday, December 6, 2010, 1:16 AM And where does merging your changes in with pd-extended 0.43 fit into all this? Not sure. I've submitted at least half-dozen patches into the sourceforge already and many more via mailing list and only a fraction of them have been looked at, and even less merged. Granted, some of them are somewhat controversial (e.g. revamping the scrolling algorithm), yet with such a low response rate one certainly feels discouraged in contributing further, The argument as I understand it is that all your patches apply to 0.42-5. So pick the simplest feature or bugfix you've implemented and submit it as a patch for 0.43. If you get feedback and/or it gets merged, end of discouragement. If you don't, then the development process is broken and needs fixing. If I knew how I'd do it myself. -Jonathan particularly considering just how time-consuming fragmenting improvements into sub-patches can be. OTOH, I do understand just how hard it can be for one to maintain code when there are a bunch of patches trickling in at all times--it's a full-time job in and of itself, particularly in respect to regressions. Yet, having spent good two weeks chasing exactly such regressions and IMHO improving editor experience to the point where both show-stopping as well as usability bugs have been by and large squashed, I certainly hope they will find their way eventually into the core Pd. The code produced so far has been clean and (apart from fprintf's for debugging purposes that are currently commented out awaiting further potential development) should be rather easy to merge into the main trunk. The real question is whether Hans, or perhaps more importantly Miller will find doing so to be of their interest. All that said, I think I'll continue to maintain a L2Ork variation until either its feature-set becomes synonymous with the core Pd package or there is no more reason to maintain it (and FWIW as of right now there are plenty, so I don't see me stopping the support anytime soon). Cheers! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Tip of the Day
Hi, What do people think of the little Tip of the Day windows that are in some software? Are they helpful? Annoying? Either way, I made one in Pd. Seems like this could be useful to beginners. And at the moment they're no longer useful one can just turn them off. (Or they could be turned off by default and live in the help window.) A prototype is attached. [hcs/folder_list] and [ggee/button] are the externals used. -Jonathan tip-o-day.tar.gz Description: application/gzip ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Tip of the Day
--- On Mon, 12/6/10, Lorenzo Sutton lsut...@libero.it wrote: From: Lorenzo Sutton lsut...@libero.it Subject: Re: [PD] Tip of the Day To: pd-list@iem.at Date: Monday, December 6, 2010, 9:28 AM Jonathan Wilkes wrote: Hi, What do people think of the little Tip of the Day windows that are in some software? Are they helpful? Annoying? My two cents. I think they are pretty useless and annoying, as randomly suggesting something doesn't add any help to the total beginner (did you know you can type ctrl+1 to create a new object?... well thank you but I'd really like to know how to make those cool sounds in pd like the videos I saw on youtube!) But I guess it's a matter of personal taste. Maybe, though, some of those tips could go in some sort of Pd quick tutorial or cookbook... but searchable and well indexed? I was trying to focus on matters of edition and odds and ends that are easy to overlook in such tutorials. Every one of the tips is covered somewhere in Pd's help docs, but they're all scattered about. As for searchable and well-indexed-- that's the idea of the META subpatch, which I've added to all the internal help patches as well as many external help patches, too. Not too long ago I posted a screenshot of a search patch I made that dynamically generates results in the form of link + object description. I've done the same for Miller's tutorials but I have no idea whether he'll include them or not. -Jonathan Lorenzo Either way, I made one in Pd. Seems like this could be useful to beginners. And at the moment they're no longer useful one can just turn them off. (Or they could be turned off by default and live in the help window.) A prototype is attached. [hcs/folder_list] and [ggee/button] are the externals used. -Jonathan ___ 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] Tip of the Day
--- On Mon, 12/6/10, Lorenzo Sutton lsut...@libero.it wrote: From: Lorenzo Sutton lsut...@libero.it Subject: Re: [PD] Tip of the Day To: Cc: Jonathan Wilkes jancs...@yahoo.com, pd-list@iem.at Date: Monday, December 6, 2010, 10:42 AM Original Message Subject: Re: [PD] Tip of the Day From: Jonathan Wilkes jancs...@yahoo.com To: pd-list@iem.at, Lorenzo Sutton lsut...@libero.it Date: 06/12/10 10:26 --- On Mon, 12/6/10, Lorenzo Suttonlsut...@libero.it wrote: From: Lorenzo Suttonlsut...@libero.it Subject: Re: [PD] Tip of the Day To: pd-list@iem.at Date: Monday, December 6, 2010, 9:28 AM Jonathan Wilkes wrote: Hi, What do people think of the little Tip of the Day windows that are in some software? Are they helpful? Annoying? My two cents. I think they are pretty useless and annoying, as randomly suggesting something doesn't add any help to the total beginner (did you know you can type ctrl+1 to create a new object?... well thank you but I'd really like to know how to make those cool sounds in pd like the videos I saw on youtube!) But I guess it's a matter of personal taste. Maybe, though, some of those tips could go in some sort of Pd quick tutorial or cookbook... but searchable and well indexed? I was trying to focus on matters of edition and odds and ends that are easy to overlook in such tutorials. Every one of the tips is covered somewhere in Pd's help docs, but they're all scattered about. As for searchable and well-indexed-- that's the idea of the META subpatch, which I've added to all the internal help patches as well as many external help patches, too. Not too long ago I posted a screenshot of a search patch I made that dynamically generates results in the form of link + object description. I've done the same for Miller's tutorials but I have no idea whether he'll include them or not. IMHO *that* is a very good idea.. searching for some library/external one doesn't always use and can't remember the exact name (including upper-lowecase mixes) can be a headache and often ends up with clumsy and not-so efficient find . -iname something in the /usr/lib/pd-extended dir :) I can't recall if there was some discussion on the list about help files best practices, ideally there should always be a comment or the object itself with a brief (meaningful) description like: [osc~] - cosine wave oscillator That would be: DESCRIPTION cosine wave oscillator So in my search patch you can type oscillator and get a match. You can also search for particular keys/values: @AUTHOR Miller Puckette returns all (well, most) of the internal objects, and @INLET_0 symbol @OUTLET_0 symbol gives you makefilename, openpanel, iemlib/splitfilename, iemlib/stripfilename, etc. Unfortunately there are A LOT of externals that have stop-gap help files without any descriptions (or even example patches). -Jonathan This way one could easily index externals and abstractions... abstractions are types of external-- at least I treat them the same by assuming they should all have their own help patches. (Although they do get tagged with the keyword abstraction so one could narrow a search that way.) I had hacked a python script to create a single html page of an extrernals dir a while back but it was pretty crude. Lorenzo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] new license for pidip and unauthorized WAS: pd-pidip into Debian
--- On Tue, 12/7/10, Andy Farnell padawa...@obiwannabe.co.uk wrote: From: Andy Farnell padawa...@obiwannabe.co.uk Subject: Re: [PD] new license for pidip and unauthorized WAS: pd-pidip into Debian To: pd-list@iem.at Date: Tuesday, December 7, 2010, 9:50 AM You could be forgiven. The effort to forge this confusion is one of the defining propaganda campaigns of the 21st Century. There are lawyers out there who don't know the difference. The difference between what and what? -Jonathan On Mon, 6 Dec 2010 20:54:19 -0500 (EST) Mathieu Bouchard ma...@artengine.ca wrote: On Mon, 6 Dec 2010, Hans-Christoph Steiner wrote: Its not illegal because its a not about laws, but rather copyright licenses, which is more like contracts, i.e. agreements between private parties. Right. I used the wrong word. I'm sorry. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC -- Andy Farnell padawa...@obiwannabe.co.uk ___ 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] new license for pidip and unauthorized WAS: pd-pidip into Debian
--- On Thu, 12/9/10, Pagano, Patrick p...@digitalworlds.ufl.edu wrote: From: Pagano, Patrick p...@digitalworlds.ufl.edu Subject: Re: [PD] new license for pidip and unauthorized WAS: pd-pidip into Debian To: Husk 00 hus...@gmail.com, Derek Holzer de...@umatic.nl Cc: pd-list PD-list@iem.at Date: Thursday, December 9, 2010, 2:29 PM i just recently had to re-write an important patch w/o grid and playlist~ because of this when i was starting out in linux i thought they were these cool advantages to switching but time and again they became an issue because i could not run it on windows [if that's all a student had] i think Yves' externals are very nice especially Grid, Grid is available on Windows version of Pd-extended. (At least the last time I checked, which I believe was with a release candidate of 0.42-5.) -Jonathan Playlist~ and cooled~ just wish there was not such an issue with using them and porting them for others in the end i used some pf Eric Lyon's objects that did not have a snarky political bent on them pp From: pd-list-boun...@iem.at [pd-list-boun...@iem.at] On Behalf Of Husk 00 [hus...@gmail.com] Sent: Thursday, December 09, 2010 5:42 AM To: Derek Holzer Cc: pd-list Subject: Re: [PD] new license for pidip and unauthorized WAS: pd-pidip into Debian On Thu, Dec 9, 2010 at 11:23 AM, Derek Holzer de...@umatic.nl wrote: Another problem with this lib is the lack of Windows binaries in PDx, I've run into this issue at workshops before. Obviously I am not fascist enough to ban windows from my workshops! ;-) You have many tools to don't run into problematic issue during workshops. I mean, always you will find an alternative to an object that suit your needs on your platform. The solution is not ban windows as not ban pidip or unauthorize. Is just talk about alternatives and possibilities, telling what you use and what people can use. Show (and tell about) the different flowers of our garden husk -- when Art become pratical we call it technology. When Technology become useless we call it Art www.estereotips.net ___ 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] Tip of the Day
Therefore my tip-of-the-day patch has at least one sign of civilization. -Jonathan --- On Thu, 12/9/10, Theron Trowbridge theron.trowbri...@gmail.com wrote: From: Theron Trowbridge theron.trowbri...@gmail.com Subject: Re: [PD] Tip of the Day To: pd-list@iem.at Date: Thursday, December 9, 2010, 8:10 PM That is why all civilized tip-of-the-day dialog boxes have a don't-do-that (again) button. -Theron ^ 2010/12/9 Hans-Christoph Steiner h...@at.or.at On Dec 6, 2010, at 4:33 PM, András Murányi wrote: 2010/12/6 Mathieu Bouchard ma...@artengine.ca On Mon, 6 Dec 2010, András Murányi wrote: Annoying for me, even if i'm interested in the software. But that's just me. For those who find it useful, this could be developed into something that can really be started up when pd starts - sounds like a plugin? :op One way is to rewrite it as a plugin, another is to make a plugin which loads the patch at startup. Either way i'd be happy to help you. Btw, it doesn't have to be a gui plugin, it can also be a regular -lib that doesn't contain any externals, but instead, just a single call to canvas_open or similar. Yea, but i cannot help Jonathan with that. What makes it make sense however, is that it starts up automatically. One can also modify his/her pd icon so that it starts up with the patch. And btw, lots of people use the word «plugin» to mean library or external, Honestly, you are to first to tell me this, but i'm not so old and haven't really been around the world so much. so, if by plugin, you mean gui plugin, you ought to be more specific. Sir I will be Sir. Let me add that i'd reserve the name 'plugin' for things that are pluggable into an API and that is something me and Hans may have a different view about - for him (afaiu) it's almost an API, for me hardly an API. Nevertheless, it's cool. (I won't define 'cool' for you :o) hehe, its the beginnings of an API, it definitely needs work. :) As for the Tip of the Day thing, they are common in software, so I guess that some people like them. I think the idea is good, but usually the way its presented is not the best. For example, when I start an app, I am usually focused on something that I need to get done, so I don't want to see a Tip of the Day screen. But perhaps there is another better time for that, or it could easily be an item on the Help menu. .hc 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 -Inline Attachment Follows- ___ 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] toxy/tot problems
Hi list, I looked in doc/examples/toxy/ and found tot-nomenu.pd. (Using the ctrl-b browser it's Pure Data/examples/toxy.) Great! But if I use [tot] to kill the menu of the main canvas instead of a subpatch, I get a big error message if I click on the Windows menu of the console: Error: invalid command name .x859e4c8.m.windows and if I click on details, I get this: invalid command name .x859e4c8.m.windows invalid command name .x859e4c8.m.windows while executing $name.m.windows add command (procedure menu_fixwindowmenu line 3) invoked from within menu_fixwindowmenu [lindex $i 1] (procedure pdtk_fixwindowmenu line 17) invoked from within pdtk_fixwindowmenu invoked from within .#mbar.#mbar#windows post 176 166 invoked from within $menu postcascade active (procedure tk::MenuButtonDown line 8) invoked from within tk::MenuButtonDown .#mbar (command bound to event) Also, if I open/close a [pd] object, I get the following error in the console: invalid command name .x859e4c8.m.windows Is there another object or set of objects in Pd that I can use to remove the menu without getting errors? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork PD first stable release now available
What's wrong with the about.pd patch? --- On Sat, 12/11/10, András Murányi muran...@gmail.com wrote: From: András Murányi muran...@gmail.com Subject: Re: [PD] L2Ork PD first stable release now available To: PD List pd-list@iem.at Date: Saturday, December 11, 2010, 9:53 PM On Thu, Dec 9, 2010 at 3:50 PM, Ivica Ico Bukvic i...@vt.edu wrote: Changes since release candidate 6: *added apply undo/redo (applies to vanilla objects with properties (e.g. gatom) plus currently as a test implementation only to the cnv object from the iemgui set--I will add it to other applicable imegui objects once the implementation is thoroughly tested). *added resize handle to the cnv object. *implemented auto-update of properties window (width/height and in cnv case also selection area width/height if the properties window is open). *fixed bug where autoconnect tries to auto-connect cnv objects. *fixed regression where gatom objects after being duplicated are only partially selected. *fixed bug where changing object properties did not result in canvas being dirty. Special thanks to all who have provided invaluable feedback in making this release as bug-free as possible! http://l2ork.music.vt.edu/main/?page_id=56 Best wishes, Ico Hey Ico, i think this is great. Now that you are releasing it, and have expressed your plan to fork from 0.42-5,what do think about: - having a separate .configfile (with special regard to the fact that some libs have to be recompiled for l2ork - now it uses .pdextended which means i'd need to change the config each time i start up the other app) - proudly updating the about box - eventually: giving the app a new name so it can fully coexist with pdextended and pd? Andras -Inline Attachment Follows- ___ 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] pd-pidip into Debian
The GPL doesn't restrict people from doing commercial business with the software (although v3 does try to restrict certain types of monkey business). -Jonathan --- On Sat, 12/11/10, Martin . blindmanona...@gmail.com wrote: From: Martin . blindmanona...@gmail.com Subject: Re: [PD] pd-pidip into Debian To: PD List pd-list@iem.at Date: Saturday, December 11, 2010, 11:25 PM +1 for including the line about military use in pd's license. That will make us all happy. And the military then has to use maxmsp. Though, I assume it means military institutions and not my own militant guerilla art. But, we could also conclude that war/military is commercial, at least in the sense that war is waged for profit, and thus GPL should do On Tue, Nov 23, 2010 at 5:46 PM, ydego...@gmail.com ydego...@gmail.com wrote: good!!! i'm free to do what i like now!!! yeh! sevy Hans-Christoph Steiner wrote: Ok, will do. I also have to remove pidip from Pd-extended based on this license. .hc On Nov 23, 2010, at 7:18 AM, ydego...@free.fr wrote: jooo, que espeso ... i told you 1 times not to package my stuff, that i'm happy with the packages of goto10... so [EOC] ciao, sevy Hans-Christoph Steiner wrote: Hey Lluis and Yves, I see that puredyne has packaged pidip, so it should be pretty easy to get it into Debian. The only problem is the license. If it was a straight BSD or GPL license, then it would be fine. The problem is this line: NOT FOR MILITARY OR REPRESSIVE USE !!! That isn't free according to the Debian Free Software Guidelines. .hc As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin 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 -Inline Attachment Follows- ___ 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] L2Ork PD first stable release now available
Well the current patch uses [hcs/version] to print out the version, so one could just change PD_TEST_VERSION in m_pd.h to L2Orkified. -Jonathan --- On Sun, 12/12/10, András Murányi muran...@gmail.com wrote: From: András Murányi muran...@gmail.com Subject: Re: [PD] L2Ork PD first stable release now available To: PD List pd-list@iem.at Date: Sunday, December 12, 2010, 1:13 AM Nothing is wrong with it, i just thought l2orkified version or something like that could be added... 2010/12/12 Jonathan Wilkes jancs...@yahoo.com What's wrong with the about.pd patch? --- On Sat, 12/11/10, András Murányi muran...@gmail.com wrote: From: András Murányi muran...@gmail.com Subject: Re: [PD] L2Ork PD first stable release now available To: PD List pd-list@iem.at Date: Saturday, December 11, 2010, 9:53 PM On Thu, Dec 9, 2010 at 3:50 PM, Ivica Ico Bukvic i...@vt.edu wrote: Changes since release candidate 6: *added apply undo/redo (applies to vanilla objects with properties (e.g. gatom) plus currently as a test implementation only to the cnv object from the iemgui set--I will add it to other applicable imegui objects once the implementation is thoroughly tested). *added resize handle to the cnv object. *implemented auto-update of properties window (width/height and in cnv case also selection area width/height if the properties window is open). *fixed bug where autoconnect tries to auto-connect cnv objects. *fixed regression where gatom objects after being duplicated are only partially selected. *fixed bug where changing object properties did not result in canvas being dirty. Special thanks to all who have provided invaluable feedback in making this release as bug-free as possible! http://l2ork.music.vt.edu/main/?page_id=56 Best wishes, Ico Hey Ico, i think this is great. Now that you are releasing it, and have expressed your plan to fork from 0.42-5,what do think about: - having a separate .configfile (with special regard to the fact that some libs have to be recompiled for l2ork - now it uses .pdextended which means i'd need to change the config each time i start up the other app) - proudly updating the about box - eventually: giving the app a new name so it can fully coexist with pdextended and pd? Andras -Inline Attachment Follows- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -Inline Attachment Follows- ___ 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] Pd refcards
This is basically help-intro.pd, right? -Jonathan --- On Sun, 12/12/10, Karim Barkati digital...@online.fr wrote: From: Karim Barkati digital...@online.fr Subject: [PD] Pd refcards To: PD List pd-list@iem.at Date: Sunday, December 12, 2010, 6:00 PM Hi all, I just laid out a one-sided pd refcard for my students and I'd like to share it ;-) There's one in english and one in french, and I uploaded them on : http://puredata.info/docs/manuals/pdrefcards Cheers, Karim ___ 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] Pd refcards
In terms of objects, what has been added? -Jonathan --- On Sun, 12/12/10, Pedro Lopes pedro.lo...@ist.utl.pt wrote: From: Pedro Lopes pedro.lo...@ist.utl.pt Subject: Re: [PD] Pd refcards To: Jonathan Wilkes jancs...@yahoo.com Cc: PD List pd-list@iem.at, Karim Barkati digital...@online.fr Date: Sunday, December 12, 2010, 10:31 PM A bit more I'd say :) On Sun, Dec 12, 2010 at 9:10 PM, Jonathan Wilkes jancs...@yahoo.com wrote: This is basically help-intro.pd, right? -Jonathan --- On Sun, 12/12/10, Karim Barkati digital...@online.fr wrote: From: Karim Barkati digital...@online.fr Subject: [PD] Pd refcards To: PD List pd-list@iem.at Date: Sunday, December 12, 2010, 6:00 PM Hi all, I just laid out a one-sided pd refcard for my students and I'd like to share it ;-) There's one in english and one in french, and I uploaded them on : http://puredata.info/docs/manuals/pdrefcards Cheers, Karim ___ 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 -- Pedro Lopes (MSc) contact: pedro.lo...@ist.utl.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] libraries in Pd-extended 0.43
As far as improving documentation, I'd say every object in Pd-ext should be documented clearly in a help patch that outlines: 1) what the object does 2) what its arguments are (and how they function) 3) what messages are accepted at each inlet, and output at each outlet (and the meaning of those messages, unless it's obvious) 4) _clear_ example patch 5) any related objects (esp. internal objects) If right-clicking Help for an object doesn't bring up a help patch, or if that help patch is just a placeholder, it should be considered a bug. -Jonathan --- On Mon, 12/13/10, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] libraries in Pd-extended 0.43 To: PD List pd-list@iem.at Date: Monday, December 13, 2010, 7:35 PM A long standing complaint of Pd-extended is that it is hard to know what all is in it and how it got there. Plus the old build system is a bug ugly whack thing that is not understandable We've made the library template and that's working well so far. We Here are some concrete steps to take on to help with this effort, either as the maintainer of a library, or just where you can help: - add a page to the the downloads page http://puredata.info/community/projects/software/ (this will become http://puredata.info/downloads soon).- add releases to the download page- improving documentation- making a Debian package- taking a pure:dyne package and getting it ready for submission to Debian- test releases- update the code in the Pd-extended release branch, once that is in place There is some developing documentation here, its not cast in stone yet: http://puredata.info/docs/AddingYourProjectToDownloadshttp://puredata.info/docs/LibrariesInPdExtendedhttp://puredata.info/docs/developer/GettingIntoPdextended There is a library template too. People aren't required to use this, but it makes things a lot easier IMHO: http://puredata.info/docs/developer/LibraryTemplate .hc On Mon, Dec 13, 2010 at 6:05 PM, Hans-Christoph Steiner h...@at.or.at wrote: Hey Alan, Thanks for the offer! Maintaining a library mostly means keeping track of the issues and seeing that they get addressed. Things range from making releases, posting releases, fixing bugs, accepting patches, etc. It can also mean doing all of the work, if you so choose. I will help out where I can, and I'm sure many others will too. You can take on any library you want, I always say its best to take on one that you feel personally invested in. .hc On Dec 13, 2010, at 5:25 AM, ALAN BROOKER wrote: Sevy, How is this a constructive comment? In fact, how is it even constructive criticism? Your proof of the saying that goes, You can either not say anything and risk people thinking your ignorant or you can open your mouth and prove it. Really I think you need to grow up, I am really surprised at just how immature you are. If you don't like the people on the list then subscribe. Maybe I am wrong however, if you have a grievance then put it forward in a sensible way so that things can be worked out? If there is something I can do let me know? I think to have bad feelings with anyone on this list is not a good thing. Hans, I may be able to maintain a some libraries and it is something I'm looking into, my programming experience is limited but would like to contribute. On Mon, Dec 13, 2010 at 3:58 AM, sevy ydego...@gmail.com wrote: this basically shows you have 3 collaborators and you call it a 'community' On Sun, Dec 12, 2010 at 9:03 PM, Hans-Christoph Steiner h...@eds.org wrote: One of the goals for Pd-extended 0.43 is to have all libraries have a maintainer, so Pd-extended isn't just a collection of lots of semi-working code. The end goal is to have a maintainer for all libraries that are included in Pd-extended. Here's the current list based on my knowledge: http://puredata.info/docs/LibrariesInPdExtended If you are interested in becoming the maintainer of any of the libraries that are currently lacking a maintainer, please add your name next to the library in question. Once you get the library up-to-date for Pd-extended, we can move it up to the maintained section on the top. Here's a rough sketch of the process of getting libraries into Pd-extended: http://puredata.info/docs/developer/GettingIntoPdextended .hc All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ 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] PD OOP?
Jmax Phoenix does this. If I recall correctly it breaks the nested list feature in Gridflow. But considering your [osc~ (pitch * 2)] example-- what would happen if you change the value of pitch? The value of the [osc~] object's argument is assigned to be the initial frequency only when the object is created, so it doesn't seem like it would have an effect unless you recreate the object. (I'm curious what Jmax Phoenix does in this regard.) -Jonathan --- On Mon, 12/13/10, Andrew Faraday jbtur...@hotmail.com wrote: From: Andrew Faraday jbtur...@hotmail.com Subject: [PD] PD OOP? To: pd-list@iem.at Date: Monday, December 13, 2010, 10:34 PM Hey All I've had a bit of a daydream about a further development in PD. Could an expression be placed into the arguments of an object, or even a named receive become part of expr I suppose the dream would be to have something like [osc~ (pitch * 2)] instead of [r pitch] | [* 2] | [osc~] or even [expr pitch * 2] | [osc~] And other such space-saving arguments. Does anyone know of anything like this to streamline pd? Or am I just dreaming here? Cheers Andrew -Inline Attachment Follows- ___ 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] libraries in Pd-extended 0.43
--- On Tue, 12/14/10, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] libraries in Pd-extended 0.43 To: Jonathan Wilkes jancs...@yahoo.com Cc: PD List pd-list@iem.at, Hans-Christoph Steiner h...@at.or.at Date: Tuesday, December 14, 2010, 3:04 AM On Mon, 13 Dec 2010, Jonathan Wilkes wrote: As far as improving documentation, I'd say every object in Pd-ext should be documented clearly in a help patch that outlines: I'd say every class in Pd-ext should be documented clearly in a help patch that outlines: You're right. I'm an object-o-phile. But do you find Related Objects troubling-- should it be Related Classes? 1) what the object does 1) what the class does In a lot of situations you need both. For something like canvas_class it doesn't make much sense to put all the details of what the class does in one giant help file-- for instance, to follow your GFDP model, you'd have one see also section that includes [inlet] (which relates to [pd] but not to [table]) as well as [tabread] or the Put menu array (vice versa). So you can have one help patch for the class that has links to individual objects. 5) any related objects (esp. internal objects) 5) any related classes (esp. internal classes) Ok so you do think it should say related classes. -Jonathan ___ | 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
[PD] 0.43 nightly build
I took a stab at using the 0.43 nightly build on Lenny. The package installed ok and here's what I found: * when I first ran pd, I got an error because it was looking for pd-gui.tcl et al in /usr/tcl, which didn't exist. So I copied everything from the /usr/lib/pd-extended/tcl and then it worked. * created [f] on a canvas, right-clicked and did Help. Couldn't find help patch. * tried Preferences-Path... and got a segfault. * no externals will create, no iemguis will create. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Objects vs Classes (was: libraries in Pd-extended 0.43)
--- On Tue, 12/14/10, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: [PD] Objects vs Classes (was: libraries in Pd-extended 0.43) To: Hans-Christoph Steiner h...@at.or.at Cc: Jonathan Wilkes jancs...@yahoo.com, PD List pd-list@iem.at Date: Tuesday, December 14, 2010, 3:23 PM On Mon, 13 Dec 2010, Hans-Christoph Steiner wrote: Pd doesn't really have classes like OOP (i.e. no inheritance), Inheritance is not an essential feature of OOP, if you consider how much this feature varies a lot from one OOP language to another, moreso than other features. The more essential features of OOP are data-abstraction, encapsulation, polymorphism, modularity, ... and in nearly all lists of typical OOP features, one is missing (but essential in practice) : the idea that multiple objects share a single class definition (that is, methods belong to classes, not directly to objects). Pd's abstractions are precisely that : one patch is a class, and each use of that patch as an objectbox in any another patch is an object. In short, there's a lot that programming languages have in common, that are typical OOP features, without having to even speak about inheritance. so I think it can be confusing to use that term. Confusing with what ? What's confusing is that you guys use one word for two things that are normally given two different names in every other language : object vs class in most cases, object vs prototype in some others, instance vs class, etc. The confusion comes from people who insist on using the word object to mean class. People have been saying objects for a long time with Pd and Max. In itself, that doesn't make it a good idea. The Pd/Max mentality of we're s completely different from everything else ! doesn't serve much more than egos. You've used this argument before. I don't remember exactly what the topic was-- maybe recursion-- and you made the point that pretty much verbatim-- that Pd is very different from everything else. I don't know, maybe you were talking about tactics (see below). In the end, problem-solving in Pd/Max is fundamentally similar to that of any other computer programming (in the strategies, not the tactics) It looks as if you a) wrote the we're-s-completely-different straw man, b) realized it might apply to yourself, and c) decided to give yourself an escape route by making an arbitrary division between strategies and tactics. (How is it that the Pd tacticians are reasonable people but the Pd strategists are egomanical?) -Jonathan so, any kind of isolationism is a manner of making it unnecessarily harder for other programmers to understand us, and vice-versa. If we adopted standard vocabulary, we could focus on real differences between Pd/Max and other languages, instead of terminology. ___ | 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] libraries in Pd-extended 0.43
--- On Tue, 12/14/10, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] libraries in Pd-extended 0.43 To: Jonathan Wilkes jancs...@yahoo.com Cc: PD List pd-list@iem.at, Hans-Christoph Steiner h...@at.or.at Date: Tuesday, December 14, 2010, 4:36 PM On Mon, 13 Dec 2010, Jonathan Wilkes wrote: You're right. I'm an object-o-phile. But do you find Related Objects troubling-- should it be Related Classes? well... yes In a lot of situations you need both. For something like canvas_class it doesn't make much sense to put all the details of what the class does in one giant help file Giant help files aren't much of a problem, but it would be more appropriate to introduce method-categories (as in Smalltalk) in order to avoid the mandatory quasi-alphabetical sorting. (GF sorts them like : bang float grid symbol pointer list, then all other names in alphabetical order, then any at the very end.) for instance, to follow your GFDP model, you'd have one see also section that includes [inlet] (which relates to [pd] but not to [table]) The t_class structure of [pd]/[table]/array/abstractions/patches is especially hairy. If a single t_class acts like it's many classes at once, it may make sense to document it as several classes anyway. However, pd will still refer you to a single help file for all those cases (except abstractions). Yeah, so currently I have links inside canvas-help.pd to table-help.pd, pd-help.pd, graph-help.pd, and a special note about Put menu arrays with a link to array-help.pd. array-help.pd is necessary to have there because triggering the help patch for the Put menu array is so obscure (I wonder if anyone here even knows what to click to get it.) The way a single t_class may act like several, is if it contains statements such as if (binbuf_getvec(x-te_binbuf)[0]==gensym(thatone)) ... Then it's looking up which alias has been used for the creation and varying the behaviour accordingly. (It could also be using multiple creators that store something to remember the same info, or have a single creator with multiple names, that stores its t_symbol *s in one way or another... I'm talking about all cases of a class acting like it's several) I mean that something can be called a class documentation-wise even though it might not be the case implementation-wise. What's important, then, is to structure the thought so that people can get the most out of those things, and not to document how the code is really written. But note that if you have a [table whatever] and a [s pd-whatever], you can do dynamic-patching instead of the [table], even though the [table] won't save the contents. You can try «obj 0 0 inlet» and «obj 0 20 outlet» and see that they really add inlets and outlets on a [table] object. Thus, in that manner, [inlet] and [outlet] are relevant to [table] objects. That's true, but just because it's possible to do that doesn't mean that [inlet] and [outlet] are relevant enough to show in the help patch for [table], any more than showing [list] in the help patch for [metro]. Also, it doesn't work the other way around-- [tabread], [tabwrite], etc. are not relevant to [pd]. ___ | 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] libraries in Pd-extended 0.43
--- On Tue, 12/14/10, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] libraries in Pd-extended 0.43 To: Hans-Christoph Steiner h...@at.or.at Cc: PD List pd-list@iem.at Date: Tuesday, December 14, 2010, 8:56 PM On Tue, 14 Dec 2010, Hans-Christoph Steiner wrote: I mean no disrespect. When you released 'unauthorized' under the GPL, you made a promise to your users that 'unauthorized' would remain free software. That is the meaning of the GPL. That's not the meaning of it. The meaning of the GPL (or any other public license) is that once you put something under the GPL, *that* version of the software can be used under the same license forever. However, the owners of the copyright can choose any other license they want for the existing software as long as they don't make them conflict (users get to pick the license they want in that case). The owners of the copyright can also stop distributing the GPL version, and make a series of versions under whichever other license, and that's why the FSF considers forking to be a most critical right : the right to continue to update a free version of any software that has been free. You know this, and in effect, by volunteering as the maintainer of «Unauthorized», you are forking it, or announcing a pending fork (waiting for a diff to apply). So did the software in question _always_ have the conflicting licenses, or was it originally just GPL and in a subsequent version the other license was added? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC -Inline Attachment Follows- ___ 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] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
--- On Wed, 12/15/10, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch) To: João Pais jmmmp...@googlemail.com Cc: pd-list@iem.at Date: Wednesday, December 15, 2010, 1:11 AM On Sun, 28 Nov 2010, João Pais wrote: I had a small look at [#many]. Do you think it would be better to use C-coded objects instead for this kind of complex gop abstractions? Well, you see, Pd *has* to grow more means to solve problems using abstractions, so, I'm making the bet that I can solve this problem with abstractions. I don't know whether it'd really take less time with C code, and if I did, I wouldn't end up with more means to solve problems using abstractions. (I wrote small externals to support [#many]). What makes you think that it would be better ? I use lots of abstractions with gop (from my library, specially [m-i] for midi input), and it seems to me that at some point I have so many abstractions, that my patches take longer to load. But I didn't do a real test to prove this. It seems that Pd on Windows takes several times more time instantiating abstractions than on Linux and OSX, especially with a full-blown path of 40 folders or so. This could be mostly fixed if Claude's abstraction-cache had been included in Pd, which can dramatically speed up abstraction-loading on all platforms, but probably especially on Windows (but I didn't check). Is this patch on the tracker? I can't find it. But this does not especially affect [#many], I'd guess. It would be a lot worse if [#many]'s elements could be abstractions, which is a planned feature. Then if you used a gop-abstraction name as the first arg of [#many], you'd trigger an insane number of lookups. This might be mitigated by specifying the absolute path to the abstraction when instantiating. This wouldn't be a bad idea to have an external that can lookup that, because as it is, [#many foo 16 16] can't see foo.pd in the folder of the patch that has [#many foo 16 16] in it, and that's more than annoying, so, this issue has to be tackled anyway. But apart from that... can you find any abstraction instances inside of [#many] ? I don't see any... so, it shouldn't be much longer to load. GridFlow's three big abstractions are [doc_h] (9k), [#many] (10k), and [#camera] (12.5k), and among them, [#many] is the only to not load any other abstractions. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC -Inline Attachment Follows- ___ 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] PD OOP?
I know Max has an [if] object that looks pretty much like your [if pitch...
etc.] example below.
-Jonathan
--- On Wed, 12/15/10, Andrew Faraday jbtur...@hotmail.com wrote:
From: Andrew Faraday jbtur...@hotmail.com
Subject: RE: [PD] PD OOP?
To: ma...@artengine.ca, jancs...@yahoo.com
Cc: pd-list@iem.at
Date: Wednesday, December 15, 2010, 1:53 AM
Hey There
You might want to have a look at Jamie Bullock's abstraction based
solution(which also went out on this list). Which was quite eloquent, if a
little limiting at first. It's a little way back from the dream of dropping
lines of OO code into pd but it's the kind of thing, when I find a syntax I
like for this, could be useful to streamline some of my patching.
I suppose what I'd really like is embedded ruby in pd, but that's either going
to be a case of some serious modification (a bit beyond me now) or possibly
shell scripts, something like
[loadbang]|[irb, pitch = 440, *other variables*(|[shell]
*number*|[pitch = $1{| [shell]
[pitch * 2{|[shell]|[osc~]
Although I suspect this may convolute issues more than solving them. Although
in theory it might simplify some logic blocks...
[if pitch 1,volume = .05,elsif pitch 5000,volume = .1,else,volume =
.15,end(|[shell]
I'm really not sure if this is worth pursuing or not. It might lead to some
impressive results, especially if I could define some methods in a ruby file
and call them via shell, meaning I could write a parallel ruby library for a pd
project.
The main problem I can see would be requesting live feedback from ruby. Would
probably have to poll a whole lot of variables quite regularly for irb to deal
with it.
All casting about ideas here, guys, but any ideas or guidance might be helpful.
Cheers
Andrew
Date: Tue, 14 Dec 2010 15:08:14 -0500
From: ma...@artengine.ca
To: jancs...@yahoo.com
CC: pd-list@iem.at; jbtur...@hotmail.com
Subject: Re: [PD] PD OOP?
On Mon, 13 Dec 2010, Jonathan Wilkes wrote:
Jmax Phoenix does this. If I recall correctly it breaks the nested list
feature in Gridflow.
Well, it's a bit more complicated. Back then, GridFlow's nested lists were
written using braces {}, but they weren't GridFlow's nested lists, they
were supported directly by jMax. I had to add the parentheses hack to
GridFlow so that I could port it to Pd.
the (pitch * 2) feature of jMax does it with variables only (such as [v])
(or constant-declarations, a jMax-only feature) and I think that this is
at creation time only, but I don't recall using it, anyway.
for some reason that I don't remember, the * that is supposed to be a
multiplication only within parentheses, was also considered a
multiplication sign outside of parentheses, where it was considered to be
a syntax error instead of a symbol. This is why I decided to ditch jMax
completely and go for Pd as much as possible. (But ditching jMax was going
to happen not long after that anyway, as IRCAM cancelled the project,
deleted the mailing-list archives, etc.)
But considering your [osc~ (pitch * 2)] example-- what would happen if
you change the value of pitch? The value of the [osc~] object's
argument is assigned to be the initial frequency only when the object is
created, so it doesn't seem like it would have an effect unless you
recreate the object.
It's not currently possible to know how to update it dynamically : the
creation arguments are only passed to creators (constructors), not
assigned in any explicit way to inlets or inlet/message combinations. The
first argument is not even consistently assigned to the second inlet.
As an example, if I implemented such a feature in GridFlow,
[# + (pitch * 2)]
Pd would read it as :
$1 = +
$2 = (pitch
$3 = *
$4 = 2)
GridFlow would reparse it as :
$1 = +
$2 = (pitch * 2)
But at that point, something is lacking, to say that the second argument
is assigned to the second inlet, and that the first argument corresponds
to a method named op instead.
___
| 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] L2Ork Pd update now available
segfault: 1. New patch. 2. Create [cnv]. 3. Save as test.pd 4. Right-click [cnv] and choose Properties. 5. Click Ok. Crash. (Hardy.) -Jonathan --- On Tue, 12/14/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: [PD] L2Ork Pd update now available To: pd-list@iem.at, l2ork-...@disis.music.vt.edu, l...@lists.linuxaudio.org, pik...@piksel.no Date: Tuesday, December 14, 2010, 6:28 PM Apologies for cross-posting. It appears a few more bugs snuck into the stable release. At the same time I felt like the rest of the iemgui objects could really benefit from the resizing via gui, hence another release. 20101214 Changelog: *implemented resizable options for all iemgui objects (some require different behavior than others (e.g. number2 resizes horizontally based on the number of characters, while vertical resize also adjusts font size as well as gui triangle preceding characters, thus resulting in changes in width as well as height--consequently the target size tries to be as close to the mouse cursor as possible while altering width, height, font size and number of characters visible) *changed the whole project naming scheme to reflect L2Orkified version (pdextended becomes pd-l2ork, install dir is /usr/local/lib/pd-l2ork, uses default.pdl2ork config file, reflects different version) *changed appearance and updated content of the about.pd patch *fixed regression where help files for core objects were erroneously replaced by incorrect pddp documentation *synced backport of the new browser and adjusted appearance to match the theme *fixed bug where pddplink failed to open related files *fixed resizable canvas so that it updates scrollbars after resizing, dirties the canvas, and properly relocates scale handle when moved As always, comments/feedback are most appreciated. http://l2ork.music.vt.edu/main/?page_id=56 Best wishes, Ico ___ 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] Plugin for 0.43 to have a gtk-looking open dialog
I think this is great. Is it going to become a normal part of Pd-extended? -Jonathan --- On Tue, 12/14/10, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] Plugin for 0.43 to have a gtk-looking open dialog To: Lorenzo Sutton lsut...@libero.it Cc: Pd-list@iem.at Date: Tuesday, December 14, 2010, 3:31 PM On Dec 14, 2010, at 6:05 AM, Lorenzo Sutton wrote: Original Message Subject: Re: [PD] Plugin for 0.43 to have a gtk-looking open dialog From: Hans-Christoph Steiner h...@at.or.at To: Lorenzo Sutton lsut...@libero.it CC: Pd-list@iem.at Date: 12/14/2010 12:41 AM On Mon, 2010-12-13 at 17:12 +0100, Lorenzo Sutton wrote: I eventually had a look into the GUI plug-in stuff and came up with this. It uses a zenity-inspired gtk binary to make the dialogue (not particularly finesse, but easier thank tcl/gtk). Source and binary as well as the tcl plugin here: http://puredata.info/Members/lorenzosu/gtk-open-plugin/gtk-open-plugin That's great! So much better than the crappy Tcl/Tk open panel. It would be great to have the save panel too. I added code so that the plugin finds pd_gtk_open in the searchpath, that's attached. I also think an install target for the Makefile would make it really easy to install: Hey thanks for that. I already have the binary for the save dialog, I just have to figure out how to make the plug-in. Now that I spend a couple hours with the GTK open panel, it felt so natural I was shocked when I removed the plugin. Looking forward to the save panel! install: install -d ~/pd-externals/ install -p -m644 gtkopen-plugin.tcl ~/pd-externals/ install -p -m755 $(PROGRAM) ~/pd-externals/ Ok.. but I think someone was raising the issue of a ~/pd-externals dir being created. Anyway it does make sense to distribute the plug-in I believe the objection you mention is that Pd-extended automatically creates ~/pd-externals. ~/pd-externals is the standard user-install path for Pd-vanilla and Pd-extended. No sudo or root access needed. .hc If you want to publicize this, you could add it to the GUI Plugins section of the new download page: http://puredata.info/community/projects/software/ http://puredata.info/docs/sitedocs/AddingYourProjectToDownloads I'll do that as soon as I have time, maybe once the save is done... An open without a matching save seems a bit strange atm :) Lorenzo .hc You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ 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] L2Ork Pd update now available
Narrowing it down: segfault only happens if you right-click and choose Properties _without_ having first selected the object. -Jonathan --- On Tue, 12/14/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: [PD] L2Ork Pd update now available To: pd-list@iem.at, l2ork-...@disis.music.vt.edu, l...@lists.linuxaudio.org, pik...@piksel.no Date: Tuesday, December 14, 2010, 6:28 PM Apologies for cross-posting. It appears a few more bugs snuck into the stable release. At the same time I felt like the rest of the iemgui objects could really benefit from the resizing via gui, hence another release. 20101214 Changelog: *implemented resizable options for all iemgui objects (some require different behavior than others (e.g. number2 resizes horizontally based on the number of characters, while vertical resize also adjusts font size as well as gui triangle preceding characters, thus resulting in changes in width as well as height--consequently the target size tries to be as close to the mouse cursor as possible while altering width, height, font size and number of characters visible) *changed the whole project naming scheme to reflect L2Orkified version (pdextended becomes pd-l2ork, install dir is /usr/local/lib/pd-l2ork, uses default.pdl2ork config file, reflects different version) *changed appearance and updated content of the about.pd patch *fixed regression where help files for core objects were erroneously replaced by incorrect pddp documentation *synced backport of the new browser and adjusted appearance to match the theme *fixed bug where pddplink failed to open related files *fixed resizable canvas so that it updates scrollbars after resizing, dirties the canvas, and properly relocates scale handle when moved As always, comments/feedback are most appreciated. http://l2ork.music.vt.edu/main/?page_id=56 Best wishes, Ico ___ 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] L2Ork Pd update now available
For example-- right-click on the top left-hand corner of cnv in run mode (since you can't select anything in run mode, this will ensure it's not selected). Then choose Properties. Now when I click Ok under these circumstances I get the segfault. -Jonathan --- On Wed, 12/15/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] L2Ork Pd update now available To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at, l2ork-...@disis.music.vt.edu, l...@lists.linuxaudio.org, pik...@piksel.no Date: Wednesday, December 15, 2010, 6:33 AM Can't reproduce over here. Are you running different libs and are they precompiled for l2ork? Also, after you've right-clicked you said cnv is not selected. At what point did you deselect it in the first place? Ico On Tue, 2010-12-14 at 19:35 -0800, Jonathan Wilkes wrote: segfault: 1. New patch. 2. Create [cnv]. 3. Save as test.pd 4. Right-click [cnv] and choose Properties. 5. Click Ok. Crash. (Hardy.) -Jonathan --- On Tue, 12/14/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: [PD] L2Ork Pd update now available To: pd-list@iem.at, l2ork-...@disis.music.vt.edu, l...@lists.linuxaudio.org, pik...@piksel.no Date: Tuesday, December 14, 2010, 6:28 PM Apologies for cross-posting. It appears a few more bugs snuck into the stable release. At the same time I felt like the rest of the iemgui objects could really benefit from the resizing via gui, hence another release. 20101214 Changelog: *implemented resizable options for all iemgui objects (some require different behavior than others (e.g. number2 resizes horizontally based on the number of characters, while vertical resize also adjusts font size as well as gui triangle preceding characters, thus resulting in changes in width as well as height--consequently the target size tries to be as close to the mouse cursor as possible while altering width, height, font size and number of characters visible) *changed the whole project naming scheme to reflect L2Orkified version (pdextended becomes pd-l2ork, install dir is /usr/local/lib/pd-l2ork, uses default.pdl2ork config file, reflects different version) *changed appearance and updated content of the about.pd patch *fixed regression where help files for core objects were erroneously replaced by incorrect pddp documentation *synced backport of the new browser and adjusted appearance to match the theme *fixed bug where pddplink failed to open related files *fixed resizable canvas so that it updates scrollbars after resizing, dirties the canvas, and properly relocates scale handle when moved As always, comments/feedback are most appreciated. http://l2ork.music.vt.edu/main/?page_id=56 Best wishes, Ico ___ 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] L2Ork Pd update now available
Another crasher: 1. Create an array from the Put menu. 2. Right-click and choose Open. 3. Inside the graph, click ctrl-1 4. Click to place the object box somewhere. Crash. -Jonathan --- On Wed, 12/15/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] L2Ork Pd update now available To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at, l2ork-...@disis.music.vt.edu, l...@lists.linuxaudio.org, pik...@piksel.no Date: Wednesday, December 15, 2010, 6:33 AM Can't reproduce over here. Are you running different libs and are they precompiled for l2ork? Also, after you've right-clicked you said cnv is not selected. At what point did you deselect it in the first place? Ico On Tue, 2010-12-14 at 19:35 -0800, Jonathan Wilkes wrote: segfault: 1. New patch. 2. Create [cnv]. 3. Save as test.pd 4. Right-click [cnv] and choose Properties. 5. Click Ok. Crash. (Hardy.) -Jonathan --- On Tue, 12/14/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: [PD] L2Ork Pd update now available To: pd-list@iem.at, l2ork-...@disis.music.vt.edu, l...@lists.linuxaudio.org, pik...@piksel.no Date: Tuesday, December 14, 2010, 6:28 PM Apologies for cross-posting. It appears a few more bugs snuck into the stable release. At the same time I felt like the rest of the iemgui objects could really benefit from the resizing via gui, hence another release. 20101214 Changelog: *implemented resizable options for all iemgui objects (some require different behavior than others (e.g. number2 resizes horizontally based on the number of characters, while vertical resize also adjusts font size as well as gui triangle preceding characters, thus resulting in changes in width as well as height--consequently the target size tries to be as close to the mouse cursor as possible while altering width, height, font size and number of characters visible) *changed the whole project naming scheme to reflect L2Orkified version (pdextended becomes pd-l2ork, install dir is /usr/local/lib/pd-l2ork, uses default.pdl2ork config file, reflects different version) *changed appearance and updated content of the about.pd patch *fixed regression where help files for core objects were erroneously replaced by incorrect pddp documentation *synced backport of the new browser and adjusted appearance to match the theme *fixed bug where pddplink failed to open related files *fixed resizable canvas so that it updates scrollbars after resizing, dirties the canvas, and properly relocates scale handle when moved As always, comments/feedback are most appreciated. http://l2ork.music.vt.edu/main/?page_id=56 Best wishes, Ico ___ 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] L2Ork Pd update now available
Plus some weirdness: [s2l] doesn't create. [symbol2list] does create, after which: [s2l] creates (?) -Jonathan --- On Wed, 12/15/10, Jonathan Wilkes jancs...@yahoo.com wrote: From: Jonathan Wilkes jancs...@yahoo.com Subject: Re: [PD] L2Ork Pd update now available To: Ivica Ico Bukvic i...@vt.edu Cc: pd-list@iem.at Date: Wednesday, December 15, 2010, 8:27 AM Another crasher: 1. Create an array from the Put menu. 2. Right-click and choose Open. 3. Inside the graph, click ctrl-1 4. Click to place the object box somewhere. Crash. -Jonathan --- On Wed, 12/15/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] L2Ork Pd update now available To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at, l2ork-...@disis.music.vt.edu, l...@lists.linuxaudio.org, pik...@piksel.no Date: Wednesday, December 15, 2010, 6:33 AM Can't reproduce over here. Are you running different libs and are they precompiled for l2ork? Also, after you've right-clicked you said cnv is not selected. At what point did you deselect it in the first place? Ico On Tue, 2010-12-14 at 19:35 -0800, Jonathan Wilkes wrote: segfault: 1. New patch. 2. Create [cnv]. 3. Save as test.pd 4. Right-click [cnv] and choose Properties. 5. Click Ok. Crash. (Hardy.) -Jonathan --- On Tue, 12/14/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: [PD] L2Ork Pd update now available To: pd-list@iem.at, l2ork-...@disis.music.vt.edu, l...@lists.linuxaudio.org, pik...@piksel.no Date: Tuesday, December 14, 2010, 6:28 PM Apologies for cross-posting. It appears a few more bugs snuck into the stable release. At the same time I felt like the rest of the iemgui objects could really benefit from the resizing via gui, hence another release. 20101214 Changelog: *implemented resizable options for all iemgui objects (some require different behavior than others (e.g. number2 resizes horizontally based on the number of characters, while vertical resize also adjusts font size as well as gui triangle preceding characters, thus resulting in changes in width as well as height--consequently the target size tries to be as close to the mouse cursor as possible while altering width, height, font size and number of characters visible) *changed the whole project naming scheme to reflect L2Orkified version (pdextended becomes pd-l2ork, install dir is /usr/local/lib/pd-l2ork, uses default.pdl2ork config file, reflects different version) *changed appearance and updated content of the about.pd patch *fixed regression where help files for core objects were erroneously replaced by incorrect pddp documentation *synced backport of the new browser and adjusted appearance to match the theme *fixed bug where pddplink failed to open related files *fixed resizable canvas so that it updates scrollbars after resizing, dirties the canvas, and properly relocates scale handle when moved As always, comments/feedback are most appreciated. http://l2ork.music.vt.edu/main/?page_id=56 Best wishes, Ico ___ 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] PD OOP?
What exactly would this (#4) look like in Pd? -Jonathan --- On Wed, 12/15/10, brandon zeeb zeeb.bran...@gmail.com wrote: From: brandon zeeb zeeb.bran...@gmail.com Subject: Re: [PD] PD OOP? To: PD List pd-list@iem.at Date: Wednesday, December 15, 2010, 1:51 PM In my experience with emulating OOP in Pd I've had moderate success. As a Java developer by day, I find myself attempting to recreate familiar patterns within Pd (ie: usually IoC and Flyweight in Pd). Main problems with recreating OOP in Pd are the following: Everything is globalNo control over abstraction (object) construction order and lifecycleNo introspection (although not required, very helpful, and don't tell me it's in some external, I don't care!) No concept of thisNo interfaces or abstract abstractions (to control inlet patterns)Unfriendly and inconsistent type system (it is cumbersome in real use, although I get over this by using [list]) and on and onIn most Pd patches, I see people using a few lookup tables again and again (ie: mtof). As this is a complete waste of memory, one can attempt the Flyweight pattern. However, doing so in Pd is a very dangerous game, as you will have NO idea which abstraction first created the table and thus have no control over retaining access to it. In my library I've dropped this approach in favor of something closer to IoC. Basic IoC is very possible, and indeed very rewarding. Very often I pass in other abstractions as object creation arguments. The most simple example of this in my library is my [bypass~] abstraction used to dynamically enable and disable a given abstraction. I use this EVERYWHERE to save CPU cycles in combination with another object to programmatically disable the sub-abstraction when the user selects a given value (ie: when the filter cutoff is at MAX with no resonance, disable the filter). In use: [bypass~ some_process~ 330 1 3 9] Where [bypass~] expects it's 1st argument to be an abstraction and the next 10 to be arguments to that abstraction. Every patch which uses [bypass]~ must have 1 signal inlet and 1 event inlet. Unfortunately, this interface can't be programmatically enforced. [bypass~] passes it's 1st two inlets to the sub-abstraction, while the 3rd is used to control [bypass~] I've attached [bypass~] and it's dependencies, have fun! ~Brandon -Inline Attachment Follows- ___ 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] PD OOP?
Well there is [sendcanvas] in iemguts. I'm not sure how related it is, but I sent Miller an idea (and maybe to this list) about adding a glist field to [struct] and having a subpatch that is a kind of template for that field. You could then define that structure as the template for an array field in another struct so that, for example, glists could be created and deleted simply by using [setsize]. Basically, think of a Put menu array, and each element is not just a float but also an abstraction instance with the y-value as the amplitude for an oscillator. -Jonathan --- On Wed, 12/15/10, brandon zeeb zeeb.bran...@gmail.com wrote: From: brandon zeeb zeeb.bran...@gmail.com Subject: Re: [PD] PD OOP? To: Jonathan Wilkes jancs...@yahoo.com Cc: PD List pd-list@iem.at Date: Wednesday, December 15, 2010, 3:04 PM Many options have been proposed over the years, my favorite thus far is [thiscanvas] http://lists.puredata.info/pipermail/pd-dev/2004-12/003430.html On Wed, Dec 15, 2010 at 8:34 AM, Jonathan Wilkes jancs...@yahoo.com wrote: What exactly would this (#4) look like in Pd? -Jonathan --- On Wed, 12/15/10, brandon zeeb zeeb.bran...@gmail.com wrote: From: brandon zeeb zeeb.bran...@gmail.com Subject: Re: [PD] PD OOP? To: PD List pd-list@iem.at Date: Wednesday, December 15, 2010, 1:51 PM In my experience with emulating OOP in Pd I've had moderate success. As a Java developer by day, I find myself attempting to recreate familiar patterns within Pd (ie: usually IoC and Flyweight in Pd). Main problems with recreating OOP in Pd are the following: Everything is globalNo control over abstraction (object) construction order and lifecycleNo introspection (although not required, very helpful, and don't tell me it's in some external, I don't care!) No concept of thisNo interfaces or abstract abstractions (to control inlet patterns)Unfriendly and inconsistent type system (it is cumbersome in real use, although I get over this by using [list]) and on and onIn most Pd patches, I see people using a few lookup tables again and again (ie: mtof). As this is a complete waste of memory, one can attempt the Flyweight pattern. However, doing so in Pd is a very dangerous game, as you will have NO idea which abstraction first created the table and thus have no control over retaining access to it. In my library I've dropped this approach in favor of something closer to IoC. Basic IoC is very possible, and indeed very rewarding. Very often I pass in other abstractions as object creation arguments. The most simple example of this in my library is my [bypass~] abstraction used to dynamically enable and disable a given abstraction. I use this EVERYWHERE to save CPU cycles in combination with another object to programmatically disable the sub-abstraction when the user selects a given value (ie: when the filter cutoff is at MAX with no resonance, disable the filter). In use: [bypass~ some_process~ 330 1 3 9] Where [bypass~] expects it's 1st argument to be an abstraction and the next 10 to be arguments to that abstraction. Every patch which uses [bypass]~ must have 1 signal inlet and 1 event inlet. Unfortunately, this interface can't be programmatically enforced. [bypass~] passes it's 1st two inlets to the sub-abstraction, while the 3rd is used to control [bypass~] I've attached [bypass~] and it's dependencies, have fun! ~Brandon -Inline Attachment Follows- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Brandon Zeeb ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
As for named variables, [rl] and [sl] are local. -Jonathan --- On Wed, 12/15/10, IOhannes m zmoelnig zmoel...@iem.at wrote: From: IOhannes m zmoelnig zmoel...@iem.at Subject: Re: [PD] PD OOP? To: pd-list@iem.at Date: Wednesday, December 15, 2010, 4:19 PM On 2010-12-15 15:38, brandon zeeb wrote: The point here refers to the common use of $0. This isn't necessarily a bad thing (and is actually helpful in most cases), but can make certain things a little more difficult with regards to true OOP. the point i was trying to make is: people usually argue that variables in Pd are global (even if you prefix them with $0), while they are really talking about _named_ variables and ignoring that Pd has a concept of passing data without naming variables at all that is entirely local. fgmasdr IOhannes -Inline Attachment Follows- ___ 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] L2Ork Pd update now available
--- On Wed, 12/15/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] L2Ork Pd update now available To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at, l2ork-...@disis.music.vt.edu, l...@lists.linuxaudio.org, pik...@piksel.no Date: Wednesday, December 15, 2010, 6:40 PM You're simply hiding the bug: 1. With the Properties dialogue open, go back and click somewhere on the patch to deselect the iemgui. (Btw-- there are times when this behavior is convienent, so please don't make the Properties dialogue force focus.) 2. Click Ok. 3. Still crashes. No crash in Pd-vanilla 0.43. That is because (afaik) vanilla 0.43 does not have apply undo at all. In other words apply actions that result from properties are simply ignored. In my case the way I am tracking items in undo is I seek selected items which now I realize is not the most robust way of doing so. That said, I did not make this fix to hide the bug but rather for the sake of consistency because I believe one needs to be in edit mode to edit, and getting properties for an object, particularly when there are many crammed near each other I believe one needs to select the item to reflect what they've selected, and then do operations that pertain to editing. I believe that allowing to edit items in this way while not in edit mode is essentially a bug from a usability perspective as it erases differentiation between performance (or whatever you will call it) and editing mode. All that said, I need to reconsider how to deal with undo and I have a pretty good idea now what needs to be done (e.g. by passing obj pointer to the undo in addition to the canvas pointer)... Actually I just used run mode as an example to ensure your GUI wasn't selected. The problem is that you can also deselect the GUI in edit mode while the Properties dialog raised. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork Pd update now available
If you look inside the externals/build/src folder you should see them. (I think they are all from zexy but not absolutely sure.) Isn't class_addcreator supposed to take care of this? -Jonathan --- On Wed, 12/15/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] L2Ork Pd update now available To: Jonathan Wilkes jancs...@yahoo.com Cc: Roman Haefeli reduz...@gmail.com, pd-list@iem.at Date: Wednesday, December 15, 2010, 6:42 PM On Wed, 2010-12-15 at 02:16 -0800, Jonathan Wilkes wrote: --- On Wed, 12/15/10, Roman Haefeli reduz...@gmail.com wrote: From: Roman Haefeli reduz...@gmail.com Subject: Re: [PD] L2Ork Pd update now available To: Ivica Ico Bukvic i...@vt.edu Cc: Jonathan Wilkes jancs...@yahoo.com, pd-list@iem.at Date: Wednesday, December 15, 2010, 10:22 AM On Wed, 2010-12-15 at 04:04 -0500, Ivica Ico Bukvic wrote: On Tue, 2010-12-14 at 23:47 -0800, Jonathan Wilkes wrote: Plus some weirdness: [s2l] doesn't create. [symbol2list] does create, after which: [s2l] creates (?) -Jonathan Is vanilla pd-extended not exhibiting this particular problem? Just checking before digging into code... It seems it is not, because it has a copy of 'symbol2list.pd_linux' renamed to 's2l.pd_linux' in extra/flatspace. Yeah, there's a whole bunch of aliases in externals/build that work the same way. Are there any other that exhibit this issue? s2l is missing because latest svn builds of pd-extended (and consequently pd-l2ork) drop support for flatspace. As you will notice pd-l2ork has no flatspace folder whatsoever. this can be fixed witha symlink addition to the install script but before I do that, can someone please send me a list of any other objects that are currently missing? Many thanks! Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork Pd update now available
--- On Thu, 12/16/10, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] L2Ork Pd update now available To: Ivica Ico Bukvic i...@vt.edu Cc: Jonathan Wilkes jancs...@yahoo.com, pd-list@iem.at Date: Thursday, December 16, 2010, 12:17 AM On Wed, 15 Dec 2010, Ivica Ico Bukvic wrote: So I guess what I'm saying is that community needs to decide whether to keep the long or short versions of those objects and convert the ones that arent accordingly. Ah, but who is the community, exactly ? I can tell you with 100% certainty that the community wants to keep whichever version they are currently using in their patches. In other words, 100% of the community wants their patches to work, which very likely means you have to keep both long and short versions. Btw-- other libraries have aliases, like iemlib which has its own workaround alias folder. Not sure about the other libraries, though. -Jonathan ___ | 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] PD OOP?
Would you make use of the following if they were included in Pd vanilla? * symbol2list * initbang and closebang * a way to read a text file that's guaranteed to not generate a bad argument error -Jonathan --- On Thu, 12/16/10, brandon zeeb zeeb.bran...@gmail.com wrote: From: brandon zeeb zeeb.bran...@gmail.com Subject: Re: [PD] PD OOP? To: Mathieu Bouchard ma...@artengine.ca Cc: PD List pd-list@iem.at Date: Thursday, December 16, 2010, 1:45 AM On Wed, Dec 15, 2010 at 6:49 PM, Mathieu Bouchard ma...@artengine.ca wrote: On Wed, 15 Dec 2010, brandon zeeb wrote: do you, really ? Why are people getting offended here? Am I getting offended ? How would you know, anyway ? Well, you're certainly argumentative :-/ Having to reinvent all that's outside of pd-vanilla is a more severe information overload. If your background is in software development, then you know that you should rely on libraries to get stuff done. I use Pd to help learn these basics, and I will use pd-extended when I've mastered the basics. But, as I said, many of what I consider to be basics are outside of pd-vanilla (while several things in pd-vanilla are rarely ever used by anyone). Relying on the pre-baked solution that is pd-extended doesn't make for a very rewarding learning experience. Yet, if I were being paid for this, I would definitely be making use of pd-extended because as you mentioned, my primary motivation would be getting stuff done. As a software developer, I'm keen on avoiding the reliance on superfluous dependency, and right now pd-extended is just that. With that in mind, what's the point in using a pre-baked filter if I haven't created my own It's so that you don't have to create your own. As I mentioned, I do want to create my own... to learn. Using IoC / Strategy, you create your abstraction and pass a symbol referencing the metronome you want to use. But you can also create the [metro] outside of the object, provided that you have an inlet in the abstraction that accepts the bangs, and zero, one or two outlets for connecting back to [metro] depending on needs. Isn't that IoC ? Yes, that would be a fine example when the payload is rather simple, and when tilde~ objects aren't involved (block delay!). Anything beyond 1 or two outlet/inlet pairs would probably be too cryptic for my uses, but the same would go for creation style IoC. In Java / Spring IoC psuedocode: No idea what Spring is... and it doesn't seem to be used in your pseudocode, does it ? Most Java classes used in Spring follow that example with setters for most dependencies. With regards to IoC, Spring is the agent that deals with creating objects, resolving setter and constructor dependency, and connecting them together. This is accomplished either through XML, annotations, or simple code (as in my example, where I'm instantiating the objects myself). -- Brandon Zeeb -Inline Attachment Follows- ___ 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] L2Ork Pd update now available
Hi Ivica, This may just be leftovers from a previous install: When I run pd by typing in '/usr/local/bin/pd-l2ork' it works fine. When I run it by typing pd-l2ork, I get: sh: /usr/bin/pd-gui: not found And it just waits there until I hit ctrl-c. Any hints? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD OOP?
--- On Thu, 12/16/10, Chris McCormick ch...@mccormick.cx wrote: From: Chris McCormick ch...@mccormick.cx Subject: Re: [PD] PD OOP? To: Mathieu Bouchard ma...@artengine.ca Cc: PD List pd-list@iem.at Date: Thursday, December 16, 2010, 5:40 AM On Wed, Dec 15, 2010 at 10:23:24AM -0500, Mathieu Bouchard wrote: IMHO, directing your criticism at pd-vanilla alone is extremely unproductive. You have to accept the fact that doing real work in Pd may require a lot of externals. It's sad, but it's like that. I wouldn't use Pd if it didn't have externals. Some platforms that Pd patches run on support very few externals. If you want to run your patches on a wide variety of platforms it is rational to avoid externals in order to avoid expending a great deal of extra effort. In many cases it is replaced by the effort required to make a hack to replace the functionality of the missing external. In the cases where a Vanilla hack is not possible, you are either forced to use an external, or you arbitrarily restrict yourself and shrug off the fact that there is no rational way to get features into Vanilla even if (everyone - 1) finds them useful/necessary. -Jonathan Salut, Chris. --- http://mccormick.cx ___ 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] PD OOP?
--- On Thu, 12/16/10, Chris McCormick ch...@mccormick.cx wrote: From: Chris McCormick ch...@mccormick.cx Subject: Re: [PD] PD OOP? To: Jonathan Wilkes jancs...@yahoo.com Cc: PD List pd-list@iem.at Date: Thursday, December 16, 2010, 8:32 AM On Wed, Dec 15, 2010 at 09:57:08PM -0800, Jonathan Wilkes wrote: --- On Thu, 12/16/10, Chris McCormick ch...@mccormick.cx wrote: From: Chris McCormick ch...@mccormick.cx Subject: Re: [PD] PD OOP? To: Mathieu Bouchard ma...@artengine.ca Cc: PD List pd-list@iem.at Date: Thursday, December 16, 2010, 5:40 AM On Wed, Dec 15, 2010 at 10:23:24AM -0500, Mathieu Bouchard wrote: IMHO, directing your criticism at pd-vanilla alone is extremely unproductive. You have to accept the fact that doing real work in Pd may require a lot of externals. It's sad, but it's like that. I wouldn't use Pd if it didn't have externals. Some platforms that Pd patches run on support very few externals. If you want to run your patches on a wide variety of platforms it is rational to avoid externals in order to avoid expending a great deal of extra effort. In many cases it is replaced by the effort required to make a hack to replace the functionality of the missing external. Yep. In my experience, the cost-benefit balance usually falls on the side of restricting myself to not using many externals, or hacking functionality back into abstractions, rather than trying to port externals to multiple platforms. You are welcome to spend your own time however you like. In the cases where a Vanilla hack is not possible, you are either forced to use an external, or you arbitrarily restrict yourself and shrug off the fact that there is no rational way to get features into Vanilla even if (everyone - 1) finds them useful/necessary. I guess I view it in a different way. Pd-msp is a constrained software environment. I choose to match my patching style to those constraints so that I don't have to do more annoying and time-consuming work. It's like writing a haiku. If you can't change the world, change yourself. Ommm. I am not sure that (everyone - 1) is fair. It is certainly not accurate. It is in the case of [initbang]. Everybody except Miller agrees that it would be a welcome addition to Vanilla. At least everything I've read on this list has been positive about [initbang], and confirmed the need for it to solve at least one specific issue which is creating variable inlets in an abstraction (as well as having other benefits). But it's not there, and it won't be there, so that's one issue that cannot be overcome by avoiding externals. (Or rather, avoiding a Pd-extended internal.) -Jonathan Of course you are quite welcome to do whatever you like and patch however you like, and even pretend that there are no good reasons for others to avoid externals. I will continue to optimise for my own laziness. :) Cheers, Chris. --- http://mccormick.cx ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] L2Ork Pd update now available
--- On Thu, 12/16/10, Roman Haefeli reduz...@gmail.com wrote: From: Roman Haefeli reduz...@gmail.com Subject: Re: [PD] L2Ork Pd update now available To: Ivica Ico Bukvic i...@vt.edu Cc: pd-list@iem.at Date: Thursday, December 16, 2010, 2:04 PM On Wed, 2010-12-15 at 23:41 -0500, Ivica Ico Bukvic wrote: AFAIK, a2l can be replaced by the vanilla [list]. Then I agree with your decision to drop aliases altogether. To me this discussion sounds like: Aliases are hard to implement when using the libdir format (which was not intended by original author anyway), so let's drop them. IMHO, that's a weak base for such a decision. Perhaps all libs should be looked over for redundant copies and only the most stable/polished iterations should be left in the final build. I agree, but I guess it's not that simple. How can one decide which classes are 'valuable' enough to keep and which aren't? There's much personal taste involved. Personally, I tend to be as restrictive as possible and I rather use [list prepend bla]-[list trim] instead of [whateverlib/prepend bla], although the vanilla-only approach requires two objects for what could be done with only one object when using an external. And still, if the decision is to include an external, which one of several flavours? It's not only about stability and cleanness, if all flavours are stable, but work slightly different from each other. Also, it's problematic to include modified libraries while keeping their original name. It would make the portability of patches much more complex, more complex than it is now. A patch using zexy in Pd-extended wouldn't necessarily work in Pd-l2ork. Stating that the patch is dependent on the zexy library would not be sufficient info to ensure that it works where zexy is installed. I tend to think, that the best option would be a transition to a reorganized library library, which uses names not based on authors but on functionality. I've tagged many libraries so far with a [pd META] subpatch that has a KEYWORDS tag, and I've got a object-search feature where, for instance, you can search for objects that play a soundfile (keyword soundfile), manipulate or store lists (list_op), take user input (user_input), and so on. You can also search for objects that manipulate lists and take user input, or objects that objects that take a symbol in the left inlet and output a list. The problem with reorganizing libraries is it's a lot of work for a minor convenience-- the person who is looking for list-manipulating objects is happy if you have libdir list_op, but then what about the person who wants to find that GUI object within the list_op library? I suppose it's a bit easier to sift through a 100 object library vs. 1500 objects, but it's still a waste of time. -Jonathan New patches could use the new, clean and stable libraries, while old ones would still work with old (current) libraries. Such a transition would allow to drop aliases, to drop superfluous object classes, and to create libraries with meaningful names. Although I'd be a strong supporter of this idea, I'm probably not the one to start this project. However, I'd happily migrate my patches to the new library library and I'd also participate in discussions. Is there a list of such objects and their similarities somewhere to start digging through all this. I don't think think so. Roman ___ 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] L2Ork Pd update now available
--- On Thu, 12/16/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: Re: [PD] L2Ork Pd update now available To: Roman Haefeli reduz...@gmail.com Cc: pd-list@iem.at Date: Thursday, December 16, 2010, 4:00 PM On Thu, 2010-12-16 at 14:04 +0100, Roman Haefeli wrote: On Wed, 2010-12-15 at 23:41 -0500, Ivica Ico Bukvic wrote: AFAIK, a2l can be replaced by the vanilla [list]. Then I agree with your decision to drop aliases altogether. To me this discussion sounds like: Aliases are hard to implement when using the libdir format (which was not intended by original author anyway), so let's drop them. IMHO, that's a weak base for such a decision. Actually, they are not hard at all. I already tried building the whole thing with aliases and it boils down to changing a few lines in the installer. That said, I've reverted it back as I philosophically agree with Hans. There is no reason for those aliases to exist other than backward compatibility. Then again, it is exactly this kind of backward compatibility (imho) that has been keeping Pd from evolving faster. At some point one simply has to leave some things behind to be able to move forward faster. And these aliases are such an easy fix that even in the context of backwards-compatibility it is a matter of a simple script updating your old patches and replacing object aliases with the original ones. It's also a matter of the developer writing a script to find all cases of the aliases in the current documentation and change the ones that have the deprecated name-- and if you're keeping the long name and discarding the short, to actually open each modified patch and make sure the new name doesn't collide with, say, a comment, or another object. But most importantly, making sure any externals that are abstractions have the correct name in their guts (which, if not correct, will adversely affect the mood of a user who just went to the trouble of making/running a script to use this flavor of Pd). -Jonathan Perhaps all libs should be looked over for redundant copies and only the most stable/polished iterations should be left in the final build. I agree, but I guess it's not that simple. How can one decide which classes are 'valuable' enough to keep and which aren't? There's much personal taste involved. Personally, I tend to be as restrictive as possible and I rather use [list prepend bla]-[list trim] instead of [whateverlib/prepend bla], although the vanilla-only approach requires two objects for what could be done with only one object when using an external. And still, if the decision is to include an external, which one of several flavours? It's not only about stability and cleanness, if all flavours are stable, but work slightly different from each other. Also, it's problematic to include modified libraries while keeping their original name. It would make the portability of patches much more complex, more complex than it is now. A patch using zexy in Pd-extended wouldn't necessarily work in Pd-l2ork. Stating that the patch is dependent on the zexy library would not be sufficient info to ensure that it works where zexy is installed. I tend to think, that the best option would be a transition to a reorganized library library, which uses names not based on authors but on functionality. New patches could use the new, clean and stable libraries, while old ones would still work with old (current) libraries. Such a transition would allow to drop aliases, to drop superfluous object classes, and to create libraries with meaningful names. Good points. Time permitting, I may put this on my todo 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] [PD-announce] Piksel video report: Sonification of IT censorship technologies
--- On Wed, 12/22/10, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] [PD-announce] Piksel video report: Sonification of IT censorship technologies To: Marco Donnarumma de...@thesaddj.com Cc: pd-list@iem.at Date: Wednesday, December 22, 2010, 8:02 PM On Mon, 20 Dec 2010, Marco Donnarumma wrote: If one can't reasonably hear the censorship in it, is it appropriate to advertise the work using such a title ? How would you define a 'reasonable listening of censorship'? Well, perhaps there isn't one that can be done with IP addresses. IP addresses don't mean much to people, even less than phone numbers do, because the DNS and WHOIS systems do their best to hide those numbers away from people. There are hardly any well-known IP addresses apart from 127.0.0.1 and 192.168.0.1, which are reserved for things outside of the internet anyway. Then there is the problem of putting numbers in any way that the numbers could be recovered (or recovered enough) from the data. In the case of IP addresses, anything one bit away is a totally distinct address, so, if such distinctions are hard to hear, you aren't really playing the IP address, but rather, a fragment of it. The way you play it, even if someone could make sense of MIDI notes as high as 255 (when even just 140 is above Nyquist...), there are 24 combinations that would sound the same (for most IP addresses), because in an IP address, the order of the bytes is important, which is not rendered as such (you'd be either preserving the order or doing anything else that amounts to doing the same). Thus there are many combinations of non-banned addresses that sound exactly the same as the banned ones. Both things led me to think that in this work, the IP addresses are secondary, the fact that they are banned addresses is secondary, and the concept of censorship is secondary. That said, I don't know how censorship could enter a music piece as music. Throw Beethoven's Eroica into a DAW and replace all the sforzandi with a 1000hZ sine tone. -Jonathan However, there are obvious ways to make it enter as lyrics : you write a song against censorship, and then it will get censored in China, and now it's doubly relevant to the topic of censorship. Sure, but in this case soundfile is only for online documentation, the work is exhibited as multichannel audio installation, the audience can interact with the software and read relevant information about the how/what/why. Ah, that's very nice. Will you put some of it online one day ? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC -Inline Attachment Follows- ___ 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] [PD-announce] Piksel video report: Sonification of IT censorship technologies
--- On Thu, 12/23/10, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] [PD-announce] Piksel video report: Sonification of IT censorship technologies To: Derek Holzer de...@umatic.nl Cc: pd-list@iem.at Date: Thursday, December 23, 2010, 2:51 AM On Thu, 23 Dec 2010, Derek Holzer wrote: This is a classic example of the ongoing (mis)communication(s) between artists and scientists. In this case, I think Mathieu is confusing the purpose of art with the purpose of a scientific paper. That's right, the purpose of art is to have no purpose. Thus spake Captain Haddock, as he explained why he had bought a large plexiglas sculpture of the letter H, in Tintin's (unfinished) opus 24 : http://www.decitre.fr/gi/16/9782203017016FS.gif ;) One's aim is to establish and demonstrate facts, the other to explore possibilities and inspire imaginative (and often non-linear) connections. That's a typical Romantic conception of it. Before that time, art and technique were largely interchangeable words (they still can be, depending on context), and a lot more people knew that the word «technique» comes from classical greek «τέχνη», which has several meanings including «art» and «craftsmanship». In Romantic times, an anti-scientific strand of artists took over, who were really obsessed by their emotions. Which strand of composers are you talking about? We are still under that influence, but the reason we're having this discussion is in part because there is a partial reconvergence of art and science happening these years. Some may call it a confusion. I think that it's pretty clear that to establish and demonstrate facts, one needs to explore possibilities and inspire imaginative (and often non-linear) connections. It's so intertwined, that it's necessary. Nevertheless, in the scientific culture, much of the «artsy» part of the job has been swept under the carpet although the job's greatest successes depends on it. (I guess that this would be why Einstein appears in that book about creativity that was mentioned some days ago) For me, far too much of this art-science stuff errs on the side of technical demonstration. If technical demonstration can be one of the many purposes of art, ... Gallery contents of the last century is one long argument that art can be anything at all and always escapes any definition. I too think that art errs a lot : someone needs to pee in Duchamp's urinal, imho. We just don't quite agree on which art is erring. Yet at once, I don't wish that Marco's work had been a technical demonstration ; it's not what I said. My wish is about valuing the possibility to sense the input through the output. That does happen to be a necessary feature of scientific visualisation and/or sonification, but it doesn't mean art can't have this feature. The flip side of that coin is that poetry is often unquantifiable (program me something sad says the media artist to their trusty technician) and causes segfaults in engineer-type brains ;-) It's more like program me something interesting and then the engineer-type brain suspects he's being asked to be the artist, and that the nominal artist is in fact some kind of curator except he gets the credit for the whole thing. But that's the worst case : usually it's a lot more pleasant than that, and the artists' requirements are usually very graspable. ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC -Inline Attachment Follows- ___ 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] [PD-announce] Piksel video report: Sonification of IT censorship technologies
--- On Thu, 12/23/10, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] [PD-announce] Piksel video report: Sonification of IT censorship technologies To: Jonathan Wilkes jancs...@yahoo.com Cc: Derek Holzer de...@umatic.nl, pd-list@iem.at Date: Thursday, December 23, 2010, 6:59 PM On Thu, 23 Dec 2010, Jonathan Wilkes wrote: --- On Thu, 12/23/10, Mathieu Bouchard ma...@artengine.ca wrote: In Romantic times, an anti-scientific strand of artists took over, who were really obsessed by their emotions. Which strand of composers are you talking about? I'm not very much talking about composers. I have the impression that Romanticism tended to have a separate meaning when it was only about music. I was thinking mostly about literature. Ok, so then which Romantic writers are you referring to who were writing anti-scientific stuff? -Jonathan I don't know what it meant in terms of how composers approached composition back then. If someone could tell me if there was any general change of techniques that is relevant to what I'm saying... I didn't study art history, so, I don't have enough background to talk so much more about it. ___ | 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] [PD-dev] how to detect if array has changed
If you clip, then you will no longer be able to tell the difference between an array wih values at max and min y and an array with y values that exceed the min/max y. Keeping outside elements visible gives visible feedback for patching errors that cause the outside elements. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] PD L2Ork 20101229 snapshot now available
I tried running the non-supreme burrito version by running ./pd-l2ork from the console and got an empty tk window with the following errors to the terminal window: tcl: /home/dude/Desktop/libmobiledevice/pd/bin/pd.tk: can't open script invalid command name pdtk_post invalid command name pdtk_post invalid command name pdtk_post invalid command name pdtk_pd_startup invalid command name pdtk_post invalid command name pdtk_post invalid command name pdtk_post invalid command name pdtk_post invalid command name pdtk_post -Jonathan --- On Wed, 12/29/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: [PD-dev] PD L2Ork 20101229 snapshot now available To: linux-audio-annou...@lists.linuxaudio.org, l...@lists.linuxaudio.org, l...@lists.linuxaudio.org, pd-list@iem.at, pd-...@iem.at, l2ork-...@disis.music.vt.edu, u...@disis.music.vt.edu, pik...@piksel.no Date: Wednesday, December 29, 2010, 9:57 PM Please excuse cross-posting. Dear friends and fellow FOSS enthusiasts, It is my great pleasure to share with the community a belated Holiday present :-) in a form of latest snapshot of L2Ork iteration of Pure-Data. Better than ever, the latest version comes with the following improvements: *implemented apply undo for array properties and partially implemented apply undo for graph-on-parent object properties (does not apply to abstractions or top-level windows currently until I figure out how to address the indexing of toplevel windows inside the glist as well as how to address to which window such an undo belongs). *properties are disabled when right-clicking on an abstraction as modifying its settings externally does not make sense when one does not see the actual contents inside it. So, to edit the properties of an abstraction, one has to open the actual abstraction. *fixed how new arrays are created so that they always fit within the specified boundaries. Please note arrays that have been already created in prior patches remain untouched in terms of graph auto-resizing (legacy code is provided in g_editor.c canvas_vis that deals with this if anyone wishes to convert their arrays but is incomplete in that it assumes all arrays require resizing--this is however unnecessary as simple recreation of said arrays or manual readjustment of their settings ought to do the trick. -This feature needs further testing--feedback is most appreciated. *fixed how arrays deal with moving array points via mouse by restricting them within the array bounds--this should work for all gui-driven array operations, while array alterations via snapshots and other external ways of manipulating arrays remain unbound so as to allow for traditional data-flow debugging--this may change down the road in part due to introduction of the magicGlass option and in part due to belief that data monitoring should only report ranges specified by the graph. -This feature needs further testing--feedback is most appreciated. *added new feature for arrays where they report a bang through the arrayname_changed send (if one is provided) whenever they have been altered by a mouse click'n'drag--this in conjunction with array graph auto-resizing makes arrays formidable alternatives for multisliders. -This feature needs further testing--feedback is most appreciated. *when an array subpatch is opened and resized, the array automatically now resizes to properly fill the window. -This feature needs further testing--feedback is most appreciated. *fixed where array was not visible after reopening the patch if any of its points touched upon y graph limits. *fixed couple of segfaults caused by gridflow incompatibility--more problems remain with gridflow library compatibility, likely due to widgetbehavior and possibly also magicGlass incompatibility. Further investigation is necessary. *fixed memory leak in the disis_phasor~ external where the destructor was never properly called and updated its documentation (available in the l2ork_addons package). *fixed highlighting of signal nlets where nlet would revert to non-signal appearance after being highlighted/connected. *reintroduced array listview (this was a regression in respect to pd-extended). *improved appearance of the array listview. *fixed a few broken links in the pddp documentation and added new l2ork-specific array features to the pddp documentation. Latest snapshot is available from the usual place: http://l2ork.music.vt.edu/main/?page_id=56 Complete changelog since 11/25/2010 is available here: http://l2ork.music.vt.edu/data/pd/Changelog Happy belated Holidays! Best wishes, Ico ___ Pd-dev mailing list pd-...@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -
Re: [PD] [PD-dev] PD L2Ork 20101229 snapshot now available
Ah, ok. --- On Thu, 12/30/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: RE: [PD-dev] PD L2Ork 20101229 snapshot now available To: 'Jonathan Wilkes' jancs...@yahoo.com, pd-list@iem.at Date: Thursday, December 30, 2010, 3:00 AM If you are trying to run the app without installing, then copy pd.tk from pd/src/ dir into pd/bin/ dir. I forgot to add this as it is actually not a part of the actual install. I will reupload another version that includes this but please understand this is not the default way of things. You will likely have a much better experience with doing actually make install and now that pd-l2ork exists in a separate path from the pd-vanilla and extended, it should happily coexist next to them. HTH, Best wishes, Ico -Original Message- From: Jonathan Wilkes [mailto:jancs...@yahoo.com] Sent: Wednesday, December 29, 2010 6:05 PM To: pd-list@iem.at; Ivica Ico Bukvic Subject: Re: [PD-dev] PD L2Ork 20101229 snapshot now available I tried running the non-supreme burrito version by running ./pd-l2ork from the console and got an empty tk window with the following errors to the terminal window: tcl: /home/dude/Desktop/libmobiledevice/pd/bin/pd.tk: can't open script invalid command name pdtk_post invalid command name pdtk_post invalid command name pdtk_post invalid command name pdtk_pd_startup invalid command name pdtk_post invalid command name pdtk_post invalid command name pdtk_post invalid command name pdtk_post invalid command name pdtk_post -Jonathan --- On Wed, 12/29/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: [PD-dev] PD L2Ork 20101229 snapshot now available To: linux-audio-annou...@lists.linuxaudio.org, l...@lists.linuxaudio.org, l...@lists.linuxaudio.org, pd-list@iem.at, pd-...@iem.at, l2ork- d...@disis.music.vt.edu, u...@disis.music.vt.edu, pik...@piksel.no Date: Wednesday, December 29, 2010, 9:57 PM Please excuse cross-posting. Dear friends and fellow FOSS enthusiasts, It is my great pleasure to share with the community a belated Holiday present :-) in a form of latest snapshot of L2Ork iteration of Pure-Data. Better than ever, the latest version comes with the following improvements: *implemented apply undo for array properties and partially implemented apply undo for graph-on-parent object properties (does not apply to abstractions or top-level windows currently until I figure out how to address the indexing of toplevel windows inside the glist as well as how to address to which window such an undo belongs). *properties are disabled when right-clicking on an abstraction as modifying its settings externally does not make sense when one does not see the actual contents inside it. So, to edit the properties of an abstraction, one has to open the actual abstraction. *fixed how new arrays are created so that they always fit within the specified boundaries. Please note arrays that have been already created in prior patches remain untouched in terms of graph auto-resizing (legacy code is provided in g_editor.c canvas_vis that deals with this if anyone wishes to convert their arrays but is incomplete in that it assumes all arrays require resizing--this is however unnecessary as simple recreation of said arrays or manual readjustment of their settings ought to do the trick. -This feature needs further testing--feedback is most appreciated. *fixed how arrays deal with moving array points via mouse by restricting them within the array bounds--this should work for all gui-driven array operations, while array alterations via snapshots and other external ways of manipulating arrays remain unbound so as to allow for traditional data-flow debugging--this may change down the road in part due to introduction of the magicGlass option and in part due to belief that data monitoring should only report ranges specified by the graph. -This feature needs further testing--feedback is most appreciated. *added new feature for arrays where they report a bang through the arrayname_changed send (if one is provided) whenever they have been altered by a mouse click'n'drag--this in conjunction with array graph auto-resizing makes arrays formidable alternatives for multisliders. -This feature needs further testing--feedback is most appreciated. *when an array subpatch is opened and resized, the array automatically now resizes to properly fill the window. -This feature needs further testing--feedback is most appreciated. *fixed where array was not visible after reopening the patch if any of its points touched upon y graph limits. *fixed couple
Re: [PD] [PD-dev] PD L2Ork 20101229 snapshot now available
Ah ok. Then don't bother-- I just already had an older Burrito version installed and was trying to just quickly test some of the changes. -Jonathan --- On Thu, 12/30/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: RE: [PD-dev] PD L2Ork 20101229 snapshot now available To: 'Jonathan Wilkes' jancs...@yahoo.com, pd-list@iem.at Date: Thursday, December 30, 2010, 3:00 AM If you are trying to run the app without installing, then copy pd.tk from pd/src/ dir into pd/bin/ dir. I forgot to add this as it is actually not a part of the actual install. I will reupload another version that includes this but please understand this is not the default way of things. You will likely have a much better experience with doing actually make install and now that pd-l2ork exists in a separate path from the pd-vanilla and extended, it should happily coexist next to them. HTH, Best wishes, Ico -Original Message- From: Jonathan Wilkes [mailto:jancs...@yahoo.com] Sent: Wednesday, December 29, 2010 6:05 PM To: pd-list@iem.at; Ivica Ico Bukvic Subject: Re: [PD-dev] PD L2Ork 20101229 snapshot now available I tried running the non-supreme burrito version by running ./pd-l2ork from the console and got an empty tk window with the following errors to the terminal window: tcl: /home/dude/Desktop/libmobiledevice/pd/bin/pd.tk: can't open script invalid command name pdtk_post invalid command name pdtk_post invalid command name pdtk_post invalid command name pdtk_pd_startup invalid command name pdtk_post invalid command name pdtk_post invalid command name pdtk_post invalid command name pdtk_post invalid command name pdtk_post -Jonathan --- On Wed, 12/29/10, Ivica Ico Bukvic i...@vt.edu wrote: From: Ivica Ico Bukvic i...@vt.edu Subject: [PD-dev] PD L2Ork 20101229 snapshot now available To: linux-audio-annou...@lists.linuxaudio.org, l...@lists.linuxaudio.org, l...@lists.linuxaudio.org, pd-list@iem.at, pd-...@iem.at, l2ork- d...@disis.music.vt.edu, u...@disis.music.vt.edu, pik...@piksel.no Date: Wednesday, December 29, 2010, 9:57 PM Please excuse cross-posting. Dear friends and fellow FOSS enthusiasts, It is my great pleasure to share with the community a belated Holiday present :-) in a form of latest snapshot of L2Ork iteration of Pure-Data. Better than ever, the latest version comes with the following improvements: *implemented apply undo for array properties and partially implemented apply undo for graph-on-parent object properties (does not apply to abstractions or top-level windows currently until I figure out how to address the indexing of toplevel windows inside the glist as well as how to address to which window such an undo belongs). *properties are disabled when right-clicking on an abstraction as modifying its settings externally does not make sense when one does not see the actual contents inside it. So, to edit the properties of an abstraction, one has to open the actual abstraction. *fixed how new arrays are created so that they always fit within the specified boundaries. Please note arrays that have been already created in prior patches remain untouched in terms of graph auto-resizing (legacy code is provided in g_editor.c canvas_vis that deals with this if anyone wishes to convert their arrays but is incomplete in that it assumes all arrays require resizing--this is however unnecessary as simple recreation of said arrays or manual readjustment of their settings ought to do the trick. -This feature needs further testing--feedback is most appreciated. *fixed how arrays deal with moving array points via mouse by restricting them within the array bounds--this should work for all gui-driven array operations, while array alterations via snapshots and other external ways of manipulating arrays remain unbound so as to allow for traditional data-flow debugging--this may change down the road in part due to introduction of the magicGlass option and in part due to belief that data monitoring should only report ranges specified by the graph. -This feature needs further testing--feedback is most appreciated. *added new feature for arrays where they report a bang through the arrayname_changed send (if one is provided) whenever they have been altered by a mouse click'n'drag--this in conjunction with array graph auto-resizing makes arrays formidable alternatives for multisliders. -This feature needs further testing--feedback is most appreciated. *when an array subpatch is opened and resized, the array automatically now resizes to properly fill the window. -This feature needs further testing--feedback is most appreciated
Re: [PD] help text not formatted very well?
What is the zoom menu? --- On Sat, 1/1/11, Andrew Faraday jbtur...@hotmail.com wrote: From: Andrew Faraday jbtur...@hotmail.com Subject: Re: [PD] help text not formatted very well? To: elmaster...@gmail.com, pd-list@iem.at Date: Saturday, January 1, 2011, 11:41 AM Have you used the zoom menu item in PD? This tends to make text larger without affecting the position of objects on screen. If you have, I'd just zoom out until it looks right. Actually, that might be worth trying anyway. Date: Fri, 31 Dec 2010 16:28:39 -0800 From: elmaster...@gmail.com To: pd-list@iem.at Subject: [PD] help text not formatted very well? Is there some setting I'm missing in terms of getting the help text to be formatted correctly? It's nice that they help is actual, working patches but it almost seems like either: a) whomever set them up didn't do a very tidy job of it b) my formatting is out of whack I usually have to drag things around just so I can read them. Also, all of the different 'put' options (object, message, number, etc.) overflow their respective containers as if the font is too big or something? Hardly a deal breaker but far from pretty. PEBKAC? -Aaron ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -Inline Attachment Follows- ___ 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] keyword/regexp search of documentation in a plugin
1 the results aren't clickable 2 you can't enter multiple non-contiguous terms 3 no control over AND vs. OR (or is there?) 4 doesn't differentiate between tutorial/example patches and object-help patches (what if I just want to find the object named 'gate'?) 5 most of the results don't fit into the window size 6 full text search makes it impossible to get useful results for 'float', array', 'list', etc. 7 can't search by inlet, object function, author, etc. (PDDP META tags) 8 non-friendly user interface 9 it doesn't seem to be searching the manual I've already got a pd patch that is well on its way to curing 1-8 (posted screenshots awhile back), but it requires toxy, which seems to have been removed from pd-ext, and there is currently no (non-buggy) tk 'entry' object in existence. -Jonathan --- On Wed, 1/12/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: [PD] keyword/regexp search of documentation in a plugin To: pd-list PD-list@iem.at Date: Wednesday, January 12, 2011, 7:10 AM Hey all, At the strong urging of Sofy Yuditskaya, I finally wrote up a quick interface for searching the Pd docs using a keyword or a regexp. Its in the form of an 0.43 plugin, so you can just drop it into your user-folder and you should get a Search item on the Help menu. Test it out and let me know how it works for you. .hc -Inline Attachment Follows- ___ 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] keyword/regexp search of documentation in a plugin
Remixed!
-Jonathan
--- On Thu, 1/13/11, Hans-Christoph Steiner h...@at.or.at wrote:
From: Hans-Christoph Steiner h...@at.or.at
Subject: Re: [PD] keyword/regexp search of documentation in a plugin
To: Jonathan Wilkes jancs...@yahoo.com
Cc: pd-list PD-list@iem.at
Date: Thursday, January 13, 2011, 6:00 PM
Attached is an updated version:
On Jan 12, 2011, at 9:13 PM, Jonathan Wilkes wrote:
1 the results aren't clickable
Which platform? They are for me on Ubuntu/maverick,
Mac OS X 10.5 and 10.6.
2 you can't enter multiple non-contiguous terms
Its a regexp really, so it doesn't really do keyword
searches. Ideally, this would use a search engine like
xapian, then it could do keyword searches. I just
added code to replace spaces in the searchtext with the
regexp code .* so that it'll search non-contiguous words,
but the first word will always be before the second in
search results.
3 no control over AND vs. OR (or is there?)
regexp
4 doesn't differentiate between tutorial/example
patches and object-help
patches (what if I just want to find the object named
'gate'?)
Hmm, that wouldn't be too hard to do, I guess it would be a
pull down menu of: object, message, comment, array, any.
5 most of the results don't fit into the window size
The window should be resizable.
6 full text search makes it impossible to get useful
results for 'float',
array', 'list', etc.
That sounds like fully typed searching, which would be very
nice, but much harder to do. My goal right now is to
get a basic search function working. Hopefully my code
is clear enough that others will make their own custom
search plugins. I could see simple search, regexp,
search engine, etc.
7 can't search by inlet, object function, author, etc.
(PDDP META tags)
Why not? This works for me: author.*steiner
8 non-friendly user interface
I spruced it up a bit with this latest version.
9 it doesn't seem to be searching the manual
Ah, I'll add .html to the file types it searches.
.hc
I've already got a pd patch that is well on its way to
curing 1-8 (posted
screenshots awhile back), but it requires toxy, which
seems to have been
removed from pd-ext, and there is currently no
(non-buggy) tk 'entry'
object in existence.
-Jonathan
--- On Wed, 1/12/11, Hans-Christoph Steiner h...@at.or.at
wrote:
From: Hans-Christoph Steiner h...@at.or.at
Subject: [PD] keyword/regexp search of
documentation in a plugin
To: pd-list PD-list@iem.at
Date: Wednesday, January 12, 2011, 7:10 AM
Hey all,
At the strong urging of Sofy Yuditskaya, I finally
wrote up
a quick
interface for searching the Pd docs using a
keyword or a
regexp. Its in
the form of an 0.43 plugin, so you can just drop
it into
your
user-folder and you should get a Search item on
the Help
menu.
Test it out and let me know how it works for you.
.hc
-Inline Attachment Follows-
___
Pd-list@iem.at
mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
“We must become the change we want to see. - Mahatma
Gandhi
# plugin to allow searching all the documentation using a regexp
# check the Help menu for the Search item to use it
package require Tk 8.5
package require pd_bindings
package require pd_menucommands
namespace eval ::dialog_search:: {
variable searchtext {}
variable count {}
variable search_history {}
variable history_position 0
variable object_state {1}
variable all_about_state {1}
variable tutorial_state {1}
variable other_state {1}
}
proc ::dialog_search::get_history {direction textwidget} {
variable search_history
variable history_position
incr history_position $direction
if {$history_position 0} {set history_position 0}
if {$history_position [llength $search_history]} {
set history_position [llength $search_history]
}
$textwidget delete 0 end
$textwidget insert 0 [lindex $search_history end-[expr $history_position - 1]]
$textwidget selection range 0 end
}
# TODO search type pulldown menu: object, message, comment, array, any
# TODO search filenames also
# TODO check line formatting options
# find_doc_files
# basedir - the directory to start looking in
proc ::dialog_search::find_doc_files { basedir } {
# Fix the directory name, this ensures the directory name is in the
# native format for the platform and contains a final directory seperator
set basedir [string trimright [file join $basedir { }]]
set fileList {}
# Look in the current directory for matching files, -type {f r}
# means ony readable normal files are looked at, -nocomplain stops
# an error being thrown if the returned list is empty
foreach
Re: [PD] pd quine?
Here's an attempt (without being totally sure I understand what a quine is...) -Jonathan --- On Fri, 1/28/11, Bryan Jurish jur...@uni-potsdam.de wrote: From: Bryan Jurish jur...@uni-potsdam.de Subject: Re: [PD] pd quine? To: Mathieu Bouchard ma...@artengine.ca Cc: pd-list List pd-list@iem.at Date: Friday, January 28, 2011, 10:50 PM exit(1) for now, although feel free to ask me again next week... ;-) On 2011-01-28 21:33:34, Mathieu Bouchard ma...@artengine.ca appears to have written: On Fri, 28 Jan 2011, Tedb0t wrote: The thought just occurred to me... Has anyone ever made a Pd quine? Sounds like an interesting challenge... Using Pd's save feature or not ? Pd has a natural advantage in that it contains such a feature, but if that feature is ruled out, then a self-replicating programme is probably a lot lengthier and complicated than in the average language... though this could an interesting challenge. will Bryan and Claude compete with each other on this one ? :) ___ | 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 -- Bryan Jurish There is *always* one more bug. jur...@uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list self.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd quine?
There's also doc/manuals/0.intro/50.pure_data_files, but the clone is missing the subpatch. -Jonathan --- On Sat, 1/29/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] pd quine? To: Jonathan Wilkes jancs...@yahoo.com Cc: Bryan Jurish jur...@uni-potsdam.de, pd-list List pd-list@iem.at Date: Saturday, January 29, 2011, 4:47 AM On Fri, 28 Jan 2011, Jonathan Wilkes wrote: Here's an attempt (without being totally sure I understand what a quine is...) That's it, precisely ! (almost all quines of other programming languages use standard-output instead, but that's a quite unimportant detail) ___ | 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] Am I alone?
--- On Sat, 1/29/11, Josh Moore kh405.7h3...@gmail.com wrote: From: Josh Moore kh405.7h3...@gmail.com Subject: [PD] Am I alone? To: pd-list@iem.at, chuck-us...@lists.cs.princeton.edu, cso...@lists.bath.ac.uk, m...@bek.no Date: Saturday, January 29, 2011, 9:16 PM Well in my opinion most electroacoustic shit is all surrealist/dadaist crap. [list I_agree Unsure WTF +1 Screw_you Welcome_to_the_list( | | [loadbang] | | | [random 6] | | | [+ 1] | | | [adddollar $1( |/ | / |/ [ ( | [print response] The people involved try too hard to be the electronic version of John Cage, it's quite annoying. [0, 0 273000( | [line~] | [dac~] In fact, I'm so against it that I'm going to come up with a parody album with actual good dance music that uses elements of the academic code geek norm with real electronic music that have titles like computer scientists make for very bad musicians and chainsaw in a cave, recorded 6 feet down In all seriousness though, i like the science. However, I believe that just because it's accepted academically doesn't mean that it will put you ahead of everyone else nor do I like/take part in the elitism that follows which is ten times worse. I read the CCRMA and IRCAM articles/publications, use Max, Csound, ChucK, and all of that jazz. I even read the Pd/Max/Csound/Chuck mailing lists too but I choose to make actual music with those tools. [1( Make Music | | [0( Read pd list | / |/ | [0.5( Warning: untested!!! (apparently) | / |/ [actual_music~] | [dac~] I use Renoise for sequencing because it can send open sound control data to the extra stuff, then I multitrack it in whatever DAW I feel like using that day whether it's Pro Tools, Live, Logic, DP, or whatever really. Most of what I make is just normal synthesis stuff, like what you would get out of a synth/workstation anyways but I like the fact that I made what I'm using, or heavily modified it if it was sampled. An off subjerct example but relative is the guys with modular synthesizers. You can go to youtube and see videos with these guys with big huge multithousand dollar Buchla synthesizers and they make this repetitive crap that sounds like it came from lost in space. Then, they just keep turning knobs and it's the same thing for five minutes. It's like, wtf is that trash nobody is going to listen to that... The technical ability to program synths is great, and I love people who take the time to be scientific about their sound but to me the whole entire point of music is about being technical with a control present. You can look at all of the great classical composers, marching band composers, composers/musicians on labels and find the same thing. If I was to go to school to study music and electronics, and figured out that I can get a plastic drum, destroy an alarm clock to make a contact microphone, and do some basic signal processing I can do much the same thing then I would be asking serious questions. I guess for someone who's learning, that stuff is fine but these big institutions who teach music already require one to take proper music courses in primary school yet we find 5 minute 20 hz drones everywhere with some white noise. Are the teachers assigning this stuff? Are they mad? I grew up in a super small area in Washington state and I've never been to college so I wouldn't know but what comes out of this circle is baffling. Perhaps it was just the way I was musically brought up, I don't know. I had a crazy band teacher in primary school who would flunk you if you didn't show up to any of the performances, and dock your grade if you didn't practice so many hours a week that had to be logged and signed by a parent. Plus, you had all the standard music theory stuff, tests on melodic, chromatic, harmonic scales, sometimes the odd ones too, inversions, chords, and so forth. My mom would listen to Van Halen, Stevie Ray Vaughn and Bluegrass music which in my opinion is very technical. I was into house and dance when I was in my preteens to late teens and my mother used to always say that stuff isn't music because it repeats too much. Eventually I saw her wisdom and started listening to lots of Prog Rock and Aphex Twin, Radiohead, Industrial Metal, and stuff like that and it totally changed my view. I think it's all too easy to get caught up in the technology behind production, and leave the good stuff out. Most of the stuff, including my own that's made with computers just doesn't have that same feel even after I spent 8 hours programming complex drum patterns note by note in a numeric based step sequencer. However, in my case my own musical control would be the simple math that makes up harmony and melody. Some however can defy this and still make good music, like Sonic Youth for instance or other people who have experimental music actually
Re: [PD] Am I alone?
Well, their ideas behind the music are their ideas behind the music. The music that results is the music that results. Composers tend to do a terrible job articulating what#39;s relevant in their own work. I#39;d take what a composer professes to be interested in with a grain of salt. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how can I clear [vd~]
--- On Tue, 2/1/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] how can I clear [vd~] To: Ingo Scherzinger i...@miamiwave.com Cc: pd-list@iem.at Date: Tuesday, February 1, 2011, 3:33 AM On Tue, 1 Feb 2011, Ingo Scherzinger wrote: Is it possible to clear the content of [vd~]? You should ask your question like «Is it possible to clear the content of [delwrite~] ?» because that's where the sound is kept. [vd~] and [delread~] are just read-heads that don't keep a copy of the sound. [delwrite~] doesn't seem to have a clear feature. This could be added with a little bit of C code, but otherwise, there is a workaround : you temporarily set all of your read-heads to a blank portion of the buffer instead of where they're supposed to be. Yes it's ugly, and no, it doesn't always work. The clear feature would be a better idea. Would the following do the same thing as a clear message? [r del_period] | [delread~ foo] | | [r clear] | | | [b] | |\ [r del_period] | | \ | | [0( [del] | | / | | [1( | |/ [*~ 1] ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC -Inline Attachment Follows- ___ 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] Am I alone?
But we're not talking about the man, we're talking about the music.
-Jonathan
--- On Tue, 2/1/11, Dominic Pflaum dompfl...@gmail.com wrote:
From: Dominic Pflaum dompfl...@gmail.com
Subject: Re: [PD] Am I alone?
To: Jonathan Wilkes jancs...@yahoo.com
Cc: Mathieu Bouchard ma...@artengine.ca, pd-list@iem.at
Date: Tuesday, February 1, 2011, 10:38 PM
Composers tend to do a terrible job articulating what's relevant in
their own work. I'd take what a composer professes to be interested in
with a grain of salt.
Perhaps in some cases but I certainly wouldn't make that a prescriptive
approach. Without understand that's Steve Reich was influenced heavily by tape
machinery, West African music, and Indonesian music, you can enjoy the music,
but you cannot fully understand the man. There are many other examples I could
give.
Dom
On Tue, Feb 1, 2011 at 8:34 AM, Jonathan Wilkes jancs...@yahoo.com wrote:
Well, their ideas behind the music are their ideas behind the music. The
music that results is the music that results.
Composers tend to do a terrible job articulating what's relevant in their own
work. I'd take what a composer professes to be interested in with a grain of
salt.
-Jonathan
From:
Mathieu Bouchard ma...@artengine.ca;
To:
Dominic Pflaum dompfl...@gmail.com;
Cc:
pd-list@iem.at;
Subject:
Re: [PD] Am I alone?
Sent:
Mon, Jan 31, 2011 4:25:08 AM
On Sun, 30 Jan 2011, Dominic Pflaum
wrote:
But in direct response to what you wrote, I believe there are some people who
are more interested in the ideas behind the music, than the actual sounds
produced; the sounds produced are almost a souvenir of the idea. It's not my
approach, but who am I to say others should not look at things that way?
That's alright, but can't they call it « ideas behind music » instead of
« music » ? or perhaps « ideas instead of music » ? ;)
___
| Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC
#yiv320851412 #yiv320851412avg_ls_inline_popup {padding:0px
0px;margin-left:0px;margin-top:0px;width:240px;overflow:hidden;word-wrap:break-word;color:black;font-size:10px;text-align:left;line-height:13px;}
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] how can I clear [vd~]
--- On Wed, 2/2/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] how can I clear [vd~] To: Jonathan Wilkes jancs...@yahoo.com Cc: Ingo Scherzinger i...@miamiwave.com, pd-list@iem.at Date: Wednesday, February 2, 2011, 6:22 AM On Tue, 1 Feb 2011, Jonathan Wilkes wrote: Would the following do the same thing as a clear message? If you don't need change the amount of delay while using it. Ah, right. It works because [delay] doesn't keep a queue of unsent bangs, it just forgets them, while [pipe] does make a queue (which wouldn't work in that circumstance). Yep. If you wanted to support variable delay (in the manner that [delread~] does) you'd need to use a [line] with a [] to figure out when to turn the delread~ back on. The other difference is that instead of sending a message to a single [delwrite~], you have to modify all [delread~]s that happen to read that delay-buffer. That's definitely a burden. Did you add your patch to the tracker? -Jonathan ___ | 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] Am I alone?
There must be some explanatory context missing from that quote because as it is, it looks like a flip play on words: There is no such thing as the Chicken Dance. The Chicken Dance is not a thing at all but an activity, something people do. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Am I alone?
--- On Wed, 2/2/11, patko colet.patr...@free.fr wrote: From: patko colet.patr...@free.fr Subject: Re: [PD] Am I alone? To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list pd-list@iem.at Date: Wednesday, February 2, 2011, 12:37 PM Music is something we can have permenantly in the mind, and this is actually hidden from anyone point of view, no one would be actually ridiculous by generating music with brain (Can you say that about chicken dance?). I chose the example of the Chicken Dance exactly because it is ridiculous, so I agree with you, but fail to see the relevance. Also-- what do you mean by point of view? If you mean a visualization of the activity, I suppose I could also say a dancer can imagine their own Chicken Dance in kinesthetic terms, quite separate from any sound or image. Tools have been developped to reproduce this music for sharing a projection around a consensus that is different following different social groups. We're just trying not to be alone. What do you mean when you say this music? If you play didjeridoo your brain will reproduce sounds of didjeridoo as well as melodies or any kind of language, where accurateness will depends of the the understanding of the mind that is trying to reproduce it. Listeners might need to be educated but I have some reasons to doubt about it, a baby for example would rather get comfortable with smooth, nice music that uses to follow the rules of intelligent structures rather than weird noises coming out from industrail machines or randomly tuned synthetisers (rather that things we are undergoing). At the other side, a too well educated listener might get bored when melodies always follow the same rules, like if we always take the same road, with same conditions, that's certainly why composers came to arrhythmia, dodecaphonism, serial and spectral music, for breaking the rules. But like in everything there is a need for an equilibrium. Breaking the rule for just breaking the rule have no interest if the rule have not been deployed along a musical piece, if the composer or the interpret don't navigate in and out of the rule, musicality can easyly loose it's interest to be listened. There is no interest to play out of tune if there is no tune at all. Also there is not idea *behind* music, music *is* the idea. It depends on how you define idea behind music. I believe matju means the process that led to music getting produced, or written, or whatever. In that case the idea is not the music. And anyway, anytime, music is the best. - Jonathan Wilkes jancs...@yahoo.com a écrit : Reasonable Kate: Have you ever heard of the Chicken Dance? Questionable Chris: There is no such thing as the Chicken Dance. The Chicken Dance is not a thing at all but an activity, something that people do. Sad irony: Chris ends up _not_ dancing that night. -Jonathan --- On Wed, 2/2/11, J. Simon van der Walt tedthetrum...@gmail.com wrote: From: J. Simon van der Walt tedthetrum...@gmail.com Subject: Re: [PD] Am I alone? To: pd-list@iem.at Date: Wednesday, February 2, 2011, 6:46 AM On 2 February 2011 03:13, Jonathan Wilkes jancs...@yahoo.com wrote: But we're not talking about the man, we're talking about the music. ‘There is no such thing as music. Music is not a thing at all but an activity, something that people do.’ Christopher Small (1998) ‘Musicking: The Meanings of Performing and Listening’ -- J. Simon van der Walt - Composer www.jsimonvanderwalt.com +44 (0) 7905 270 198 ___ 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 -- Patrice Colet ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] keyword/regexp search of documentation in a plugin
Hi Hans, Two questions: 1) widgets and text appear super tiny on winxp. But when I create a widget in the tcl shell, say, with grid [button .b -text Hello] the font size looks fine. So what exactly is happening in Pd to make things look too small in windows? (I remember this was a problem with the font bomb but I don't know what the solution was.) 2) What is the _ command? I.e.: button .b -text [_ Search] -Jonathan --- On Wed, 1/12/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: [PD] keyword/regexp search of documentation in a plugin To: pd-list PD-list@iem.at Date: Wednesday, January 12, 2011, 7:10 AM Hey all, At the strong urging of Sofy Yuditskaya, I finally wrote up a quick interface for searching the Pd docs using a keyword or a regexp. Its in the form of an 0.43 plugin, so you can just drop it into your user-folder and you should get a Search item on the Help menu. Test it out and let me know how it works for you. .hc -Inline Attachment Follows- ___ 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] how can I clear [vd~]
[delread~ patch_review_buffer ???] | | [crickets~] | | [!=~] | | [applause~] | | [*~] | \ | \ [dac~] --- On Wed, 2/2/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] how can I clear [vd~] To: Jonathan Wilkes jancs...@yahoo.com Cc: Ingo Scherzinger i...@miamiwave.com, pd-list@iem.at Date: Wednesday, February 2, 2011, 11:48 PM On Tue, 1 Feb 2011, Jonathan Wilkes wrote: Did you add your patch to the tracker? No, but now I did : http://sourceforge.net/tracker/?func=detailaid=3170987group_id=55736atid=478072 ___ | 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] keyword/regexp search of documentation in a plugin
I'm making some more changes, like removing the checkboxes and using a combobox for the genres. Also using a combobox to enter search terms which has the benefit of a more user friendly drop-down menu for a search history (plus less code). Also, I changed the search function so you can type: foo bar and it will match if both foo and bar appear in the document (regardless of order). -Jonathan --- On Sun, 2/6/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] keyword/regexp search of documentation in a plugin To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list PD-list@iem.at Date: Sunday, February 6, 2011, 11:29 PM Wow, that's really nice! The dynamic updating with the checkboxes is impressive. More features and better formatting. My only complaint is the No DESCRIPTION tag. message, I say it'd be better just blank. There is also a weird thing where I can't grab the scrollbar and move it, only scroll with the mousewheel. This is using Pd-extended 0.43 from 02-02 on Mac OS X 10.5/Intel. .hc On Jan 25, 2011, at 1:03 AM, Jonathan Wilkes wrote: Remixed! -Jonathan --- On Thu, 1/13/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] keyword/regexp search of documentation in a plugin To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list PD-list@iem.at Date: Thursday, January 13, 2011, 6:00 PM Attached is an updated version: On Jan 12, 2011, at 9:13 PM, Jonathan Wilkes wrote: 1 the results aren't clickable Which platform? They are for me on Ubuntu/maverick, Mac OS X 10.5 and 10.6. 2 you can't enter multiple non-contiguous terms Its a regexp really, so it doesn't really do keyword searches. Ideally, this would use a search engine like xapian, then it could do keyword searches. I just added code to replace spaces in the searchtext with the regexp code .* so that it'll search non-contiguous words, but the first word will always be before the second in search results. 3 no control over AND vs. OR (or is there?) regexp 4 doesn't differentiate between tutorial/example patches and object-help patches (what if I just want to find the object named 'gate'?) Hmm, that wouldn't be too hard to do, I guess it would be a pull down menu of: object, message, comment, array, any. 5 most of the results don't fit into the window size The window should be resizable. 6 full text search makes it impossible to get useful results for 'float', array', 'list', etc. That sounds like fully typed searching, which would be very nice, but much harder to do. My goal right now is to get a basic search function working. Hopefully my code is clear enough that others will make their own custom search plugins. I could see simple search, regexp, search engine, etc. 7 can't search by inlet, object function, author, etc. (PDDP META tags) Why not? This works for me: author.*steiner 8 non-friendly user interface I spruced it up a bit with this latest version. 9 it doesn't seem to be searching the manual Ah, I'll add .html to the file types it searches. .hc I've already got a pd patch that is well on its way to curing 1-8 (posted screenshots awhile back), but it requires toxy, which seems to have been removed from pd-ext, and there is currently no (non-buggy) tk 'entry' object in existence. -Jonathan --- On Wed, 1/12/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: [PD] keyword/regexp search of documentation in a plugin To: pd-list PD-list@iem.at Date: Wednesday, January 12, 2011, 7:10 AM Hey all, At the strong urging of Sofy Yuditskaya, I finally wrote up a quick interface for searching the Pd docs using a keyword or a regexp. Its in the form of an 0.43 plugin, so you can just drop it into your user-folder and you should get a Search item on the Help menu. Test it out and let me know how it works for you. .hc -Inline Attachment Follows- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list “We must become the change we want to see. - Mahatma Gandhi search-plugin.tcl The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] keyword/regexp search of documentation in a plugin
--- On Sun, 2/6/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] keyword/regexp search of documentation in a plugin To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list PD-list@iem.at Date: Sunday, February 6, 2011, 11:24 PM On Feb 6, 2011, at 4:19 PM, Jonathan Wilkes wrote: Hi Hans, Two questions: 1) widgets and text appear super tiny on winxp. But when I create a widget in the tcl shell, say, with grid [button .b -text Hello] the font size looks fine. So what exactly is happening in Pd to make things look too small in windows? (I remember this was a problem with the font bomb but I don't know what the solution was.) In order to make the patches all look/work the same on all platforms, Tk scaling is turned off. On Windows, this can mean small fonts, so you have to use the scaled fonts that are speced in pd-gui.tcl. How do I specify them? I don't see them specified at all in the code for the find dialog but the fonts look fine there. -Jonathan 2) What is the _ command? I.e.: button .b -text [_ Search] It marks text for localization. So if, for example, you are using Pd in German it'll read suchen rather then search. .hc -Jonathan --- On Wed, 1/12/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: [PD] keyword/regexp search of documentation in a plugin To: pd-list PD-list@iem.at Date: Wednesday, January 12, 2011, 7:10 AM Hey all, At the strong urging of Sofy Yuditskaya, I finally wrote up a quick interface for searching the Pd docs using a keyword or a regexp. Its in the form of an 0.43 plugin, so you can just drop it into your user-folder and you should get a Search item on the Help menu. Test it out and let me know how it works for you. .hc -Inline Attachment Follows- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] keyword/regexp search of documentation in a plugin
Ah, great. Thanks Hans. -Jonathan --- On Mon, 2/7/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] keyword/regexp search of documentation in a plugin To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list PD-list@iem.at Date: Monday, February 7, 2011, 12:14 AM On Feb 6, 2011, at 5:54 PM, Jonathan Wilkes wrote: --- On Sun, 2/6/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] keyword/regexp search of documentation in a plugin To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list PD-list@iem.at Date: Sunday, February 6, 2011, 11:24 PM On Feb 6, 2011, at 4:19 PM, Jonathan Wilkes wrote: Hi Hans, Two questions: 1) widgets and text appear super tiny on winxp. But when I create a widget in the tcl shell, say, with grid [button .b -text Hello] the font size looks fine. So what exactly is happening in Pd to make things look too small in windows? (I remember this was a problem with the font bomb but I don't know what the solution was.) In order to make the patches all look/work the same on all platforms, Tk scaling is turned off. On Windows, this can mean small fonts, so you have to use the scaled fonts that are speced in pd-gui.tcl. How do I specify them? I don't see them specified at all in the code for the find dialog but the fonts look fine there. -Jonathan Its done using classes and the option system. If you make the toplevel of your search like: toplevel .font -class DialogWindow It'll inherit stuff like that. .hc 2) What is the _ command? I.e.: button .b -text [_ Search] It marks text for localization. So if, for example, you are using Pd in German it'll read suchen rather then search. .hc -Jonathan --- On Wed, 1/12/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: [PD] keyword/regexp search of documentation in a plugin To: pd-list PD-list@iem.at Date: Wednesday, January 12, 2011, 7:10 AM Hey all, At the strong urging of Sofy Yuditskaya, I finally wrote up a quick interface for searching the Pd docs using a keyword or a regexp. Its in the form of an 0.43 plugin, so you can just drop it into your user-folder and you should get a Search item on the Help menu. Test it out and let me know how it works for you. .hc -Inline Attachment Follows- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne “We must become the change we want to see. - Mahatma Gandhi ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] keyword/regexp search of documentation in a plugin
Hi Hans, I think your find_doc_files proc is doing double duty-- for example, if cyclone/gate-help.pd matches the search terms, I get two results for it: 1) basedir is [path_to_pd]/extra/cyclone and filename is gate-help.pd 2) basedir is [path_to_pd]/extra/ and filename is cyclone/gate-help.pd Also, adding -class DialogWindow to the search window did the trick for the tiny fonts on winxp, except that ttk::combobox still has a tiny textarea (i.e., the dropdown menu). Any idea on either of these? -Jonathan --- On Mon, 2/7/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] keyword/regexp search of documentation in a plugin To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list PD-list@iem.at Date: Monday, February 7, 2011, 8:25 PM That's great, looking forward to it. I'm really happy to see you taking this and running with it, let me know if there are any blockers. Seems to me that its ready to be posted on the GUI plugins category of the download page: http://puredata.info/community/projects/software .hc On Feb 6, 2011, at 5:51 PM, Jonathan Wilkes wrote: I'm making some more changes, like removing the checkboxes and using a combobox for the genres. Also using a combobox to enter search terms which has the benefit of a more user friendly drop-down menu for a search history (plus less code). Also, I changed the search function so you can type: foo bar and it will match if both foo and bar appear in the document (regardless of order). -Jonathan --- On Sun, 2/6/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] keyword/regexp search of documentation in a plugin To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list PD-list@iem.at Date: Sunday, February 6, 2011, 11:29 PM Wow, that's really nice! The dynamic updating with the checkboxes is impressive. More features and better formatting. My only complaint is the No DESCRIPTION tag. message, I say it'd be better just blank. There is also a weird thing where I can't grab the scrollbar and move it, only scroll with the mousewheel. This is using Pd-extended 0.43 from 02-02 on Mac OS X 10.5/Intel. .hc On Jan 25, 2011, at 1:03 AM, Jonathan Wilkes wrote: Remixed! -Jonathan --- On Thu, 1/13/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: Re: [PD] keyword/regexp search of documentation in a plugin To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list PD-list@iem.at Date: Thursday, January 13, 2011, 6:00 PM Attached is an updated version: On Jan 12, 2011, at 9:13 PM, Jonathan Wilkes wrote: 1 the results aren't clickable Which platform? They are for me on Ubuntu/maverick, Mac OS X 10.5 and 10.6. 2 you can't enter multiple non-contiguous terms Its a regexp really, so it doesn't really do keyword searches. Ideally, this would use a search engine like xapian, then it could do keyword searches. I just added code to replace spaces in the searchtext with the regexp code .* so that it'll search non-contiguous words, but the first word will always be before the second in search results. 3 no control over AND vs. OR (or is there?) regexp 4 doesn't differentiate between tutorial/example patches and object-help patches (what if I just want to find the object named 'gate'?) Hmm, that wouldn't be too hard to do, I guess it would be a pull down menu of: object, message, comment, array, any. 5 most of the results don't fit into the window size The window should be resizable. 6 full text search makes it impossible to get useful results for 'float', array', 'list', etc. That sounds like fully typed searching, which would be very nice, but much harder to do. My goal right now is to get a basic search function working. Hopefully my code is clear enough that others will make their own custom search plugins. I could see simple search, regexp, search engine, etc. 7 can't search by inlet, object function, author, etc. (PDDP META tags) Why not? This works for me: author.*steiner 8 non-friendly user interface I spruced it up a bit with this latest version. 9 it doesn't seem to be searching the manual Ah, I'll add .html to the file types it searches. .hc I've already got a pd patch that is well on its way to curing 1-8 (posted screenshots awhile back), but it requires toxy, which seems to have been removed from pd-ext, and there is currently no (non-buggy) tk 'entry' object in existence. -Jonathan --- On Wed, 1/12/11, Hans-Christoph Steiner h...@at.or.at wrote: From: Hans-Christoph Steiner h...@at.or.at Subject: [PD] keyword/regexp search
Re: [PD] Need Help Understanding pack
Those jokes exist in English, too. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Need Help Understanding pack
It#39;s not inferred-- it#39;s stated directly as point #2 on the Order of Operations part, then reiterated: The application of these concepts appears frequently in Pd code. Plus there#39;s a whole section devoted to connection order that reads like a how to guide for patching by depending on the order in which the connections were made. Pd-ext should do multiple connections from an outlet in the reverse order from Vanilla, with the most recent connection sending data first, so that the only thing anyone can ever say about mutiple connections from one outlet is that they are used when you don#39;t care about the order of those operations. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
A false dichotomy is made between abstractions and externals. Also there are many externals that don#39;t include abstractions but are nonetheless compatible with Pd vanilla. word or symbol creates a false dichotomy. Also: it isn#39;t made clear what is special about list messages as opposed to, say, blueberry messages, which I define as starting with the word blueberry followed by zero or more atoms*. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] FLOSS book Lists chapter
--- On Sun, 2/13/11, Mathieu Bouchard ma...@artengine.ca wrote: From: Mathieu Bouchard ma...@artengine.ca Subject: Re: [PD] FLOSS book Lists chapter To: Jonathan Wilkes jancs...@yahoo.com Cc: Hans-Christoph Steiner h...@eds.org, pd-list@iem.at Date: Sunday, February 13, 2011, 5:46 PM On Fri, 11 Feb 2011, Jonathan Wilkes wrote: A false dichotomy is made between abstractions and externals. Such a false dichotomy is also used on the front page of http://puredata.info/ : « It is easy to extend Pd by writing object classes (externals) or patches (abstractions). » As well as in svn, where, for example, list-abs is in the abstractions folder, but there are plenty of libraries in externals that are made up only of abstractions. I say that even though at the implementation level, abstractions aren't classes, for the user, it works like a class. Also there are many externals that don't include abstractions but are nonetheless compatible with Pd vanilla. What part of the text are you referring to, in particular ? The last sentence states that list-abs doesn't require any externals so that it is compatible with vanilla Pd as well. BTW, http://en.flossmanuals.net/PureData/Abstractions talks about external patches, but given how external is being overwhelmingly used with a totally different meaning in Pd. (are newbies supposed to have to guess ?) word or symbol creates a false dichotomy. what about the occurrence of selector-word in the Messages page ? Yep, that, too. Also: it isn't made clear what is special about list messages as opposed to, say, blueberry messages, which I define as starting with the word blueberry followed by zero or more atoms*. mmm, blueberries. :) ___ | 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] in an abstraction or subpatch, what determines the order of inlets/outlets?
doc/2.control.examples/12.PART2.subpatch.pd (inside [pd eager-adder]) Also in: http://crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s7 Trivia: If you put a bunch of [inlet] objects at the exact same x position in a canvas, the order in which they were created (from most recent to least recent) corresponds to the left-to-right order of the subpatch's inlets on the parent patch. In other words: if you have: [inlet] [inlet] There's no way to tell by looking what the ordering is. So, obviously, don't do that, but also keep in mind that it's a good idea in general to keep all [inlet] objects in a horizontal row so one can quickly grasp their left-to-right order merely by looking at the patch: [inlet] [inlet] is much clearer than: [inlet] [inlet] [inlet] (Same for [outlet].) -Jonathan --- On Mon, 2/14/11, Morgan Packard mor...@morganpackard.com wrote: From: Morgan Packard mor...@morganpackard.com Subject: [PD] in an abstraction or subpatch, what determines the order of inlets/outlets? To: pd list pd-list@iem.at Date: Monday, February 14, 2011, 10:32 PM In other words, when I edit my subpatch, how can I tell which inlets/outlets in the subpatch correspond to which in box in the main patch representing the subpatch? I'm sure this is a common question, but a quick glance through the docs and on google didn't turn anything up. thanks, -Morgan -- Web: http://www.morganpackard.com Music/Art: Latest album: Moment Again Elsewhere iOS app Thicket available on iTunes store. -Inline Attachment Follows- ___ 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] in an abstraction or subpatch, what determines the order of inlets/outlets?
Hm, not sure-- maybe you've got multiple instances of the same abstraction open and are modifying a different one? To simplify, try testing it in a [pd subpatch]. You can actually see the wires to any connected objects in the parent patch change when you alter the horizontal placement of one [inlet] with respect to another. -Jonathan --- On Tue, 2/15/11, Richie Cyngler glitch...@gmail.com wrote: From: Richie Cyngler glitch...@gmail.com Subject: Re: [PD] in an abstraction or subpatch, what determines the order of inlets/outlets? To: Jonathan Wilkes jancs...@yahoo.com Cc: pd list pd-list@iem.at, Morgan Packard mor...@morganpackard.com Date: Tuesday, February 15, 2011, 3:40 AM Correct me if I'm wrong but this doesn't work for me. They stay in order of creation, the abstraction object doesn't change when I move the horizontal alignment of the inlets in the subpatch. As seen here: On Tue, Feb 15, 2011 at 9:01 AM, Jonathan Wilkes jancs...@yahoo.com wrote: doc/2.control.examples/12.PART2.subpatch.pd (inside [pd eager-adder]) Also in: http://crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s7 Trivia: If you put a bunch of [inlet] objects at the exact same x position in a canvas, the order in which they were created (from most recent to least recent) corresponds to the left-to-right order of the subpatch's inlets on the parent patch. In other words: if you have: [inlet] [inlet] There's no way to tell by looking what the ordering is. So, obviously, don't do that, but also keep in mind that it's a good idea in general to keep all [inlet] objects in a horizontal row so one can quickly grasp their left-to-right order merely by looking at the patch: [inlet] [inlet] is much clearer than: [inlet] [inlet] [inlet] (Same for [outlet].) -Jonathan --- On Mon, 2/14/11, Morgan Packard mor...@morganpackard.com wrote: From: Morgan Packard mor...@morganpackard.com Subject: [PD] in an abstraction or subpatch, what determines the order of inlets/outlets? To: pd list pd-list@iem.at Date: Monday, February 14, 2011, 10:32 PM In other words, when I edit my subpatch, how can I tell which inlets/outlets in the subpatch correspond to which in box in the main patch representing the subpatch? I'm sure this is a common question, but a quick glance through the docs and on google didn't turn anything up. thanks, -Morgan -- Web: http://www.morganpackard.com Music/Art: Latest album: Moment Again Elsewhere iOS app Thicket available on iTunes store. -Inline Attachment Follows- ___ 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 -- shiny Rich ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] search paths
http://crca.ucsd.edu/~msp/Pd_documentation/x3.htm#s5 Regardless of path, Pd should look first in the directory containing the patch before searching down the path. Pd does not automatically look in the current directory however; to enable that, include ``. in the path. The ``extra directory, if enabled, is searched last. This isn't true for new patches, which automatically get the current directory added to the path (at least on an Ubuntu Maverick machine running Pd version 0.42-6). Also, if you do add a . to the search path, then an object like [./blah] can refer either to blah in the patch directory (which, luckily, gets searched first) or the current directory. I've never used this feature but it seems really odd to have ./ referring to two different things at once. -Jonathan Looking for earth-friendly autos? Browse Top Cars by Green Rating at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] noob question: trying to repurpose the G08.reverb.pd example
Why not always put your abstractions in the same directory as the patch? (Or in a subdirectory if you want to organize them that way.) It makes things more modular: e.g., you can just compress the containing directory and shoot it off rather than sending a separate attachment for abstractions and have them copy your manually-entered search patch settings (which most likely will not be the same across platforms). Additionally, the patch directory is searched first (at least according to the manual), so you're less likely to run into name clashes that way. (And then you can guarantee no nameclashes by prefixing your abstractions with a ./ like [./my-abs].) -Jonathan --- On Tue, 2/15/11, Richie Cyngler glitch...@gmail.com wrote: From: Richie Cyngler glitch...@gmail.com Subject: Re: [PD] noob question: trying to repurpose the G08.reverb.pd example To: Morgan Packard mor...@morganpackard.com Cc: pd list pd-list@iem.at Date: Tuesday, February 15, 2011, 3:45 AM I don't entirely follow what is happening with your files. But in order to access abstractions they need to have a file path, which you can setup via the preferences menuPath. I don't know if you are aware of this or not. I put all mine in a folder called abstractions which I have set up a path to. On Tue, Feb 15, 2011 at 1:33 PM, Morgan Packard mor...@morganpackard.com wrote: I'm trying to add that reverb in to my own patch. I simply copied and pasted the pd reverb subpatch in to my own. The reverb-echo abstraction isn't being found by my own patch (it shows up with a red outline, and an error in the console: reverb-echo ... couldn't create. The example patch works fine, loads that abstraction no problem. But it doesn't work in my own patch. I tried loading a different abstraction in to my own patch, and it loads just fine. Any ideas what's going on here? How can I get better debugging information than couldn't create? thanks! -Morgan -- Web: http://www.morganpackard.com Music/Art:Latest album: Moment Again Elsewhere iOS app Thicket available on iTunes store. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- shiny Rich -Inline Attachment Follows- ___ 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
