Re: [PD] C++ for reusable dsp lib - or better use C?
On Tue, Feb 21, 2012 at 10:59:59AM -0500, Mathieu Bouchard wrote: ABI compatibility is still an issue with C++. In addition to name mangling, calling convention and other issues accross compilers, C++ presents problems with ABI incompatibility even when using the same compiler. If your library is designed with user-extensible classes, choosing C++ places severe constraints upon core development -- no new virtual methods or member variables in non-leaf classes, etc: http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B The comment thread here may be germane (it describes some of the reasons we avoided C++ for Apache Lucy): https://issues.apache.org/jira/browse/LUCY-5 Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [expr] license issue (update)
On Sat, Dec 03, 2011 at 02:35:26PM -0500, Mathieu Bouchard wrote: I don't think anyone claims copyright on correcting a small typo, for example. There are all kinds of crazy people in the world who claim things they don't have the right to, but to pursue the matter ad absurdum, any lawsuit over a small typo is going to be thrown out for failing a de minimis test. Nevertheless, I understand wanting to err on the side of safety. Politics and courtesy probably play a larger role here than actual legal concerns. And I certainly agree with Jonathan that IANAL. :) Marvin said something about implicitly giving up copyright, in the previous big thread about licenses (in sep+oct). I must have said something about granting implicit license under the license of the project when you provide a patch, which is definitely not the same thing as implicitly giving up copyright. Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gdb and Pd WAS: testtone comments
On Wed, Nov 16, 2011 at 07:28:34AM -0800, Jonathan Wilkes wrote: So can I just use Valgrind with my current nightly build, or do I still need to recompile with the options Hans mentioned? You don't need to recompile. If at some point we create a Valgrind suppressions file for Pd, it will help to compile with -fno-inline-functions. But that's not required -- it just cuts down on the noisy false positives. Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gdb and Pd WAS: testtone comments
On Wed, Nov 16, 2011 at 09:46:18AM -0500, Hans-Christoph Steiner wrote: To this end, I recently did some work on the Pd-extended build system to make sure that everything gets built with -g -fno-omit-frame-pointer. With those two, I have found that you can get good info while still having the (other) optimizations in. Debugging with the optimizations is also important since that's how most people actually use pd. Certainly, compiling with those flags aids debugging with gdb and optimizations enabled. Nevertheless, I have to say that while I've used Valgrind to debug countless memory glitches, I have only tracked the problem down to an optimization-related compiler bug once. Memory corruption bugs and leaks seem to originate much more often with the programmer than the compiler. :) To fully exploit Valgrind and its ability to identify ordinary C programmer error, it's convenient (though not required) to build with optimization off and -fno-inline-functions so as to make building suppressions files easier. That's not going to hide bugs like double-frees, buffer overruns, etc, and most of the time, that's what at the root of the problem. I would also like to second Matju -- it is much more useful to know the moment the invalid write occured than it is to know what happened at the moment the corrupted memory caused the crash. Heap memory corruption in particular is a spooky-action-at-a-distance phenomenon[1] -- there is usually no obvious cause-and-effect relationship between the bad write and its eventual consequences, because overwriting the heap's bookkeeping records causes stuff to go haywire in really weird ways at unpredictable moments. It is much easier to debug starting from the cause that Valgrind identifies rather than starting from the effect that gdb identifies. Marvin Humphrey [1] http://en.wikipedia.org/wiki/Action_at_a_distance_%28computer_science%29 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] expr money
On Sat, Nov 12, 2011 at 03:24:27PM -0500, Mathieu Bouchard wrote: btw, I haven't seen any of the three funders (Andy, Jonathan, Marvin) say whether their money is just for [expr], or does it include [expr~] and/or [fexpr~] as well. The task description should be made clearer. What I would like to see is uniform BSD licensing for PD Vanilla. That said, if Shahrokh believed that the task only included [expr], I'm fine with that. I doubt he's going to be funded at anywhere near what his time is worth, either way. Also, there's no webpage about it. Perhaps you could get together to write a page listing the goals and the amounts of money. It could be on puredata.info. There could also be a new section for that kind of thing, and/or it could be put next to the Google Summer of Code pages and other funding-related things. Personally, I'm not into the idea of generalizing this -- public funding is a legal and bureaucratic hassle, and I'm considering this a specific charity donation a la sponsoring a friend in Race for The Cure, not seed money for a bug-bounty model of development. I'm also unlikely to contribute again. For me, this is a one-time put-your-money-where-your-mouth-is special situation that I only really considered because the original author made a unique proposal. Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] expr alternative
On Wed, Oct 26, 2011 at 08:51:23AM +0800, Simon Wise wrote: On 26/10/11 01:29, Hans-Christoph Steiner wrote: The Apple App Store is incompatible with the GPL and LGPL, from what I understand. Getting Apple to make their App Store compatible with the GPL and LGPL is another much better solution since it will work for all GPL and LGPL software. this is of course the best solution ... 8 snip license advocacy and geopolitical theory 8 I would like to register my disagreement. In my opinion, the solution which best serves the broad community of users -- including those users for whom expr's licensing is problematic -- is for Pd Vanilla to have uniform BSD licensing. It seems to me that an implementation of expr which is license-compatible with the rest of Vanilla is a perfectly reasonable and understandable feature request. The practical rationale is obvious: if GPL (or potentially LGPL) is not an option for you, then expr is missing from your toolkit, and it would be nice to have it. I understand that there are several valuable contributors within the Pd community who believe that it is important to deny that feature request for moral reasons. There are also opposing moral reasons to grant it, but as before, I intend to keep my developer list posts on licensing limited to dry mechanics if possible; if you absolutely cannot live without a sprinkle of BSD license advocacy to complement the on-list deluge of copyleft license advocacy, please ask off-list. Best, Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] expr alternative
On Mon, Oct 24, 2011 at 08:36:39AM +0100, Andy Farnell wrote: On Mon, 24 Oct 2011 11:16:18 +0900 i go bananas hard@gmail.com wrote: in that case, it might be as simple as a nice email to Shadrokh Yadegari to get his expr for pd license changed to LGPL too?? What makes you think its okay to ask someone to reconsider a carefully made moral decision simply for your convenience? I don't know the specifics of the expr case, and it may well be that the GPL is something that Shadrokh Yadegari feels strongly about. Still, as a data point, when the codebase that is now Apache Lucy was granted to the ASF and we had to get 20 copyright holders to sign off on on a license change from GPL/Artistic to Apache 2.0, not a single one of them objected. Not everyone cares. From a practical standpoint, if there have been any patches to expr since it was added to Pd, it would be necessary to secure the consent of those authors as well, any one of whom may refuse, or might not be available. Relicensing is hard. But especially if writing a from-scratch alternative to expr is being contemplated, I think it's commendable and wise for mr. bananas to at least explore the possibility of achieving his objective via polite requests before taking any other actions. I don't think he should feel bad about that at all. Indeed, that is the community-friendly approach, attempting to keep development united. I choose to have faith that if expr's author receives a polite request regarding relicensing, the response will also be polite, even if it is a rebuff. If my faith is misplaced and the response is instead an indignant flame, in my opinion, that does not reflect poorly on mr. bananas. There are those of us who are on the BSD side of the fence who also have strong moral reasons for our choices. You tend not to hear from us as often because we feel you should have the freedom to GPL works which bundle ours, just as you should have the right to release bundled software under proprietary licenses. Despite these strong beliefs, if I were to receive a sincere request to relicense software I had written under a copyleft license, I would not be offended and I would contemplate it in good faith. Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] editing pd silence - dither
On Sun, Oct 23, 2011 at 02:20:38PM -0400, Mathieu Bouchard wrote: Personally, I don't understand what's the point of dither in audio. Maybe it's just an evil plot to make CD quality sound like 8-track cartridges. Without dither, truncation error becomes truncation distortion. It is correlated with the signal, yet not harmonic. While under certain circumstances this can be exploited as a special effect, it is not desirable when your goal is fidelity. The use of dither in digital audio is directly analogous to the use of dither to defeat posterization and achieve the illusion of smooth color transitions in visual images with limited color levels. http://en.wikipedia.org/wiki/File:Colour_banding_example01.png In that image, the 24-bit gradient would be analogous to the full width audio signal prior to bit depth reduction, the 8 bit gradient, dithered would be analogous to dithered audio, and the 8 bit gradient displaying obvious color banding would be analogous to truncated audio. Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] editing pd silence - dither
On Sun, Oct 23, 2011 at 04:04:58PM -0400, Mathieu Bouchard wrote: I understand all of that already, but my impression is that it's more like making a 24-bit gradient use dithering so that it looks more like a 48-bit gradient. Would it make a perceptual improvement if you did so ? No, of course not -- such a difference, though measurable, would fall below a human's perceptual threshold. But truncate over and over again, and eventually, the error accumulates and rises above threshold. It's hard to hear the first pass of a perceptual codec. But run audio through a codec multiple times, and you get a cliff edge effect: nothing... nothing... nothing... oh wow now I hear it. Truncation distortion, being enharmonic, is pretty nasty. It's not like analog tape overload. A little truncation distortion goes a long way, and unless you are going for glitch, best practice to keep it at bay by managing gain structure wisely and dithering when appropriate. E.g. if you have a fully 16-bit-digital volume control on an amp, and the amp has a big volume range and you only use the quiet range, the effective number of bits can down a lot. It's also not uncommon to capture a killer take under less than ideal recording conditions -- including input gain structure. It's worthwhile for developers of audio software to think about such things, so that downstream users benefit from the additional headroom. Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Fri, Oct 14, 2011 at 02:33:13PM -0400, Mathieu Bouchard wrote: Le 2011-10-11 à 11:37:00, Hans-Christoph Steiner a écrit : I work to make sure that everything in Pd-extended is GPLv3 compatible. [...] Everything in Pd-extended is GPLv3, I think that it's better to remain picky in the manner of saying things like that, and not confuse GPLv3 and GPLv3-compatible. You could be saying something like « All licenses of all parts of Pd-extended are GPLv3-compatible and it will remain like that ». +1 Everything in Pd-extended is GPLv3 is simply incorrect. License proliferation within Pd is regrettable and sucks time and energy better spent on other things, but asserting that everything is under a unified licensing regime when that's just not true makes things *more* complicated, not less. It is not in the interest of the project to create a situation where the licensing of patches is contentious because a contributor was told something that conflicted with the reality of how the files are licensed in the repository. This causes less confusion than claiming things about a whole when people don't know what the whole is supposed to mean. Indeed. It was a similarly expansive passage[1] earlier in this thread that prompted me to request clarification regarding the status of contributions to individual parts of Pd-extended (which was quickly forthcoming[2], thank you). Had language such as All licenses of all parts of Pd-extended are GPLv3-compatible been used instead, this thread might have been shorter. :P Marvin Humphrey [1] http://lists.puredata.info/pipermail/pd-list/2011-09/091410.html My personal thoughts on the license of what is in pd-extended.git are more vague. Yes, the intention is for much/most of that code to contributed back to Pd, but my only distribution of the whole thing is part of the Pd-extended package, which is GPLv3. So if you want to be sure, consider it GPLv3. [2] http://lists.puredata.info/pipermail/pd-list/2011-09/091422.html As the maintainer and main author of the pd-extended.git, I will you give you my assurance that the code under pd-extended.git is under a BSD license. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Wed, Sep 28, 2011 at 06:17:08PM +0800, Simon Wise wrote: typing into a spreadsheet cell is somewhat analogous, and probably a fairly common activity ... Nice connection! generally enter saves and exits the cell, while to put a newline into a cell without leaving it is ctrlenter ... not sure what the OSX equivalent is, maybe cmdenter. I just checked out the Google Docs spreadsheet behavior. I assume that it mimics the interfaces of other popular spreadsheet programs, though I don't know that for sure. * enter and shiftenter both save and exit the cell. * controlenter and cmdenter both insert a newline. * esc cancels the change and exists the cell. I haven't seen anyone object to Matthieu's suggested behaviors for enter and esc, which are consistent with both behavior and general OS gui conventions, so I think we may have achieved consensus there. What's left is the basically irrelevant issue of how to insert a newline that's going to be turned into a space later anyway. My inclination is to supply a patch which simply does not support the insertion of newlines. If that results in user confusion and support inquiries, a binding for modifierreturn can be added later. Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Thu, Sep 29, 2011 at 10:37:45AM -0700, Jonathan Wilkes wrote: Something I was thinking about for the future is a way to model keyboard input after the efficiency of 'vi' input. When in Edit mode without yet editing the text of an object, one could use h, j, k, and l to move the bounding box selection around in the patch. Then bind / to duplicate ctrl-f, and you have a quick way to get around the entire patch without leaving home position. (Maybe also bind i to enter text-editing mode, and a to enter text editing mode at the end of the object's text.) Then when in text editing mode or Run mode, turn off these bindings. The tricky part is figuring out the most efficient way to make/edit connections. There is already auto-connect behavior for leftmost xlets-- there needs to be a way to make a new connection, remove a connection, move a connection, and possibly make many-to-many connections like [select 0 1 2 3 4] with each outlet going to a new message box. DesireData has a way to edit connections with the keyboard but I found it takes too many keystrokes. Perhaps some of those features could be accommodated by having configurable key bindings for the actions in question. You don't have to provide default bindings for all options, either -- just provide hooks, and let the user create key bindings for the actions they care about. Ever used Logic Audio? I was quite fond of its key binding preferences system when I used it a decade ago. What's left is the basically irrelevant issue of how to insert a newline that's going to be turned into a space later anyway. My inclination is to supply a patch which simply does not support the insertion of newlines. If that results in user confusion and support inquiries, a binding for modifierreturn can be added later. That will result in user confusion, because when a message box with semicolons gets instantiated it doesn't automatically get newlines added until you save the patch and reopen it, while object boxes add the newlines after instantiation. Currently the discrepancy can be hidden by always adding the newlines yourself with enter. Ah, I see. Source text: 'eep; op; ork; ah-ah;' Object after instantiation: eep; op; ork; ah-ah; Message after instantiation: eep; op; ork; ah-ah; Message after close and reopen: eep; op; ork; ah-ah; So people who know this and don't want to close-and-reopen require some way to enter newlines while editing text. That seems like a bug worth fixing, but I don't feel strongly about shiftenter one way or another, and if it solves a problem people care about, fine by me. Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Tue, Sep 27, 2011 at 12:14:00PM -0400, Hans-Christoph Steiner wrote: Pd-extended as a whole is under the GPLv3, that's the easiest way to think about it. Some sections of it are under the BSD License, some under the Tcl License (which Pd was originally), some under GPLv2, etc. My personal thoughts on the license of what is in pd-extended.git are more vague. Yes, the intention is for much/most of that code to contributed back to Pd, but my only distribution of the whole thing is part of the Pd-extended package, which is GPLv3. So if you want to be sure, consider it GPLv3. OK, then: Since Pd-extended as a whole is under the GPLv3, if I ever supply a patch against Pd-extended.git, I must assume that the GPLv3 applies to it if I want to be sure. It sounds as though if I want to avoid producing GPLv3 code, I need to steer a wide berth around Pd-extended. Also, it sounds as though if you want to be sure, no code which was ever derived from Pd-extended can ever be merged upstream into Vanilla without violating the GPL. If I can't be sure that other Pd contributors won't claim that the GPL applies to contributions I'm making that are intended for the Vanilla's BSD core, that makes it a lot less attractive to contribute to this project. Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Wed, Sep 28, 2011 at 11:00:21AM -0400, Hans-Christoph Steiner wrote: As the maintainer and main author of the pd-extended.git, I will you give you my assurance that the code under pd-extended.git is under a BSD license. That repo is a fork of the pure-data.git repo of Miller, it is largely intended as way to develop and feed patches to the upstream pure-data.git, and as Matju pointed out, the only license statement in pd-extended.git is Miller's BSD one from pure-data git. Thanks, Hans. Given your constraints, I can't think of a way to improve upon this setup. It seems wise that you keep the satellite libraries in a seperate repository from the core -- that makes it more difficult for code to wander where it shouldn't or for tight bonds to form. Of course it would be ideal if there was only one core repository, not the least because it seems like a lot of work for you to maintain the fork in the manner that you do -- but it is apparent why that is not feasible. License proliferation is a costly problem, both in the open source world at large and within the microcosm of this one project. Cheers, Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Thu, Sep 29, 2011 at 12:44:39AM -0400, Hans-Christoph Steiner wrote: In my opinion, using GPLv3 has been the easiest of the options. It means that we can use code that is licensed with a BSD, MIT, Tcl, Apache, GPLv2, LGPL, GPLv3, etc.. So its the most compatible to the code that's out there, meaning thinking about licenses less writing more code that everyone is free to use :) All I'm gonna say is that I see things from a different angle. :) Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Tue, Sep 27, 2011 at 11:50:07AM -0400, Mathieu Bouchard wrote:
Le 2011-09-25 à 09:29:00, Marvin Humphrey a écrit :
The patch below fixes the problem. I don't know if it's the right solution,
though.
Pd doesn't _have_ to pass keynums around like that. If the Tk code were
sending Up/Down/Left/Right names as given by Tk's bind's %K (uppercase),
then you wouldn't have to replicate in g_editor.c things that Tk already
does as part of its portability layer.
Ha, interesting.
The patch below, which also achieves correct behavior of cursor keys under Snow
Leopard, is an alternative to the patch supplied earlier. This one has the
advantage of removing the #ifdef __APPLE__ code from src/g_editor.c, as the
normalization is now achieved via Tk. However, I don't yet understand all the
ramifications, just as I did not with the last patch.
Marvin Humphrey
From 08d585e6f4d9158f94edc8896de80a3635bb717f Mon Sep 17 00:00:00 2001
From: Marvin Humphrey mar...@rectangular.com
Date: Tue, 27 Sep 2011 19:57:13 -0700
Subject: [PATCH] Normalize cursor key behavior at the Tcl level.
Take advantage of Tk's portability layer for normalizing cursor key values
instead of reproducing it ourselves at the C level.
---
src/g_editor.c | 10 --
tcl/pd_bindings.tcl |4
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/src/g_editor.c b/src/g_editor.c
index f494732..983f463 100644
--- a/src/g_editor.c
+++ b/src/g_editor.c
@@ -1699,16 +1699,6 @@ void canvas_key(t_canvas *x, t_symbol *s, int ac, t_atom
*av)
keyupsym = gensym(#keyup);
keynamesym = gensym(#keyname);
}
-#ifdef __APPLE__
-if (keynum == 30)
-keynum = 0, gotkeysym = gensym(Up);
-else if (keynum == 31)
-keynum = 0, gotkeysym = gensym(Down);
-else if (keynum == 28)
-keynum = 0, gotkeysym = gensym(Left);
-else if (keynum == 29)
-keynum = 0, gotkeysym = gensym(Right);
-#endif
if (keynumsym-s_thing down)
pd_float(keynumsym-s_thing, (t_float)keynum);
if (keyupsym-s_thing !down)
diff --git a/tcl/pd_bindings.tcl b/tcl/pd_bindings.tcl
index 82ac350..cff0bbc 100644
--- a/tcl/pd_bindings.tcl
+++ b/tcl/pd_bindings.tcl
@@ -249,6 +249,10 @@ proc ::pd_bindings::sendkey {window state key iso shift} {
Tab { set iso ; set key 9 }
Return{ set iso ; set key 10 }
Escape{ set iso ; set key 27 }
+Left { set iso ; set key 28 }
+Right { set iso ; set key 29 }
+Up{ set iso ; set key 30 }
+Down { set iso ; set key 31 }
Space { set iso ; set key 32 }
Delete{ set iso ; set key 127 }
KP_Delete { set iso ; set key 127 }
--
1.7.3.2
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Tue, Sep 27, 2011 at 01:59:20PM -0400, Mathieu Bouchard wrote: None of these combinations provide that behavior on Pd Vanilla built from latest git on OS X 10.6: control-Enter command-Enter option-Enter shift-Enter I could live with control-Enter instead of ESC (especially since I've rewired my caps lock key to control at the OS level using the Keyboard system prefs) -- though ESC works so well for switching modes in Vim. :) The only thing that has made sense to me is : Enter for accepting changes made in a box's text and exit that mode ; Well, that's the simplest and possibly the best design. It mates up the most easy and obvious keypress with the most common case. However, it's also the most invasive modification. If anyone is accustomed to being able to produce a newline with Enter while editing text into Message or Comment boxes, they will have to change their habits. Are there people who would object to such an change? Escape for cancelling those changes and exit that mode too ; Good idea -- that's consistent with Mac GUI design for closing dialog boxes without making changes. I like it! Is that also consistent with the traditional behavior of Escape under Windows and X? Shift-Enter to insert a literal newline in a box's text (currently meaningless because they get replaced by Space by the loader/saver) ; Newlines seem to be normalized to Spaces for Pd Objects, but that doesn't seem to be the case for either Messages or Comments. Using Shift-Enter for newlines doesn't seem like a very intuitive design to me. I suspect that a significant fraction of the people who want newlines will never discover the magic key combo. However, that may be a price worth paying to optimize the common case. Those shortcuts don't necessarily apply to the main Edit Mode... I don't recall whether we bound Enter to « switch to text edition ». Your English is 100x better than my French, but I assume that when you wrote edition, you meant editing? Escape has no effect in that context, because there's no modal dialogue-like thing to get out of. So, if I understand correctly, you are suggesting that these key bindings would only take effect while actively editing the text of an Object, Message, or Comment. If that's the case, +1 -- I agree. Cheers, Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Tue, Sep 27, 2011 at 11:34:43AM -0400, Mathieu Bouchard wrote: The three clauses of the BSD license used by Pd Vanilla are compatible with both the GPL v2 v3 Integrating GPL code with BSD code makes GPL the overall dominant license, as in it has all the clauses of BSD and makes the most restrictions. The BSD license still applies to any portions still under BSD license. The pdextended license (GPL) doesn't say to which parts of the programme it applies, and all the copyright/license notices I can find (in a bêta of 42) are all BSD. Changes additions to BSD code don't have to be under the BSD license, thus if it's not stated, it's somewhat harder to make any assumptions... According to Intellectual Property and Open Source by Van Lindberg[1] (which I highly recommend), a patch which is offered up on a mailing list or through a patch tracker comes with an implicit grant of license to use it in the project, which means that it must be licensed under the same terms as the project itself. I can't imagine that some sort of submarine licensing attempt would hold up in court: Yes, I acknowledge that my patch was against a file with a BSD license header, but even though I didn't say so, I contributed it under the terms of the GPL and I refuse to grant a BSD license. Gimme a break! I think it's rational to assume that mistakes notwithstanding[2], all content of any BSD-licensed file in the Pd source is under the BSD license, and all content of any file with a GPL notice is under the GPL. If any contributor ever intended some other outcome but did not communicate their desires explicitly, that cannot possibly be worth worrying about. To make trouble, the disgruntled contributor would have to be A) prepared to sue over the distinction between two free software licenses and B) prepared to lose. That kind of license fuzz is tolerated because pd developers have no expectation that lawyers ever have to put their nose in the project... and even if they did, they would not have the background to know how to fix it, or know which advice they can trust. While copyright violations do not result in injunctions unless a litigant appears, I do not believe it is in the interest of any project to neglect the law. I think that this is true of many (if not most) open/free projects. I'm not comfortable with that generalization. Open source projects with commercial involvement tend to be fastidious about intellectual property, and there is a lot of activity in that area these days. Indeed, part of the appeal of Apache projects is that the ASF is known to emphasize IP cleanliness, and companies feel more comfortable sponsoring development on projects that aren't likely to be sunk by completely avoidable legal problems. Ever increasing numbers of developers are paid to work on open source, which is a glorious and beautiful thing. But personally, even before most of my open source dev work was sponsored, I was careful about IP, partly because it's the right thing to do and partly because I was determined not to squander untold hours of labor and creativity. I don't think that outlook is uncommon. It makes sense for us as developers to protect our investments by doing our best to understand and adhere to relevant laws -- whether our livelihoods depend on it, or whether we work on a project for fun or other personal reasons. Marvin Humphrey [1] http://www.amazon.com/Intellectual-Property-Open-Source-Protecting/dp/0596517963 [2] Mistakes do happen. Sometimes they are fixable: https://issues.apache.org/jira/browse/LUCENE-675?focusedCommentId=12901057page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12901057 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Wed, Sep 28, 2011 at 12:43:06AM -0400, Hans-Christoph Steiner wrote: The question with this patch then, is does it work fine on GNU/Linux and Windows? I don't know. I'm experienced with cross-platform development and I have a Windows 7 dev environment available via a Bootcamp partition, so in theory I could check. It seems likely to work, but it has not been verified. It's a PITA to power down OS X and fire up Windows, so I don't do it very often. No X Windows box immediately available, either. I don't see any unit tests. Are there any? I really think the whole key handling code in both Tcl and C needs rewriting rather than patching. I'm not prepared to offer an opinion on that, as I'm not yet sufficiently familiar with the code base. If we were to make such an attempt, I'd suggest preserving the existing interface while changing the implementation. And of course it would seem wise to secure the blessing of Mr. Puckette in advance as to the general approach. Perhaps matju's answer is the way forward, making it based on the %K bind var rather the %k. That seemed logical to me and I attempted to figure it out, but came up short. Grepping the source for %k didn't turn up anything. Grepping for %K turned up the pd_bindings.tcl file, and I hacked from there. I added a couple more keys to your origin one: Nice! Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Mon, Sep 26, 2011 at 11:20:13AM -0400, Hans-Christoph Steiner wrote: Welcome to Pd! This is a nice entry, showing up with a patch to fix a bug :-D. Thanks, nice to meet you. I may as well put these C skills to use, eh? The whole canvas_key thing is pretty messy, so I think your patch is probably as good as its going to get. I'll apply it. Patches are definitely very welcome :-D. Thanks for being so responsive. In the future, please submit them to the patch tracker, the 'git format-patch' format is preferred: http://puredata.info/dev/patchtracker Well, I wasn't yet convinced that the patch was in its final form -- the inlined diff was intended for discussion. :) FWIW, I'd seen reference to the patch tracker while browsing through http://puredata.info/dev. There's a decent amount of documentation there for potential contributors to orient themselves, though like most wikis the world over, some of the material is out of date. If I figure out further improvements, I will submit final patches to the patch tracker according to the project's preferred procedures. Ideally, I would like to eliminate the #ifdef __APPLE__ altogether. That's probably not possible. My second choice would be to keep only the higher keyval numbers, since that's what my current system needs. But maybe I've been going down the wrong path this whole time... Curiously, the official Pd 0.43 OS X binary does not have any problems on Snow Leopard with regards to cursor keys. I only get these problems when building from source. I tried compiling from the 0.43 source tarball. (I tried first to find a git tag corresponding to 0.43; git tag -l didn't find anything, but I'm not a git power user and maybe I'm missing something.) Building with the new build system required the fix launching on Mac OS X patch (3360aba7). (Building with the old build system failed spectacularly and I wasn't sure how to proceed.) Compiling the 0.43 sources produced a binary that doesn't handle cursor keys correctly. So, something about my Snow Leopard build environment is causing the problem... Hmm, I had ActiveTCL 8.6 installed... but disabling that didn't help. (Aside: It's a pain to hide everything that Tcl installs.) Any ideas? How does my system differ from the system which was used to build the official 0.43 OS X binary? Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Mon, Sep 26, 2011 at 11:26:27AM -0400, Hans-Christoph Steiner wrote: Check out the GUI plugins, they could be a fun way for you to learn Tcl. Yes, this is actually one of my motivations. :) I went through some of the Pd tutorials a couple years ago, and have meant to get back into it for a while. Then recently, I gained a professional reason to learn Tcl, and it's provided me with an excuse to dive into the Pd source code. :) You can customize a lot of the way the GUI works using them. Key bindings are easy. You could check out the completion-plugin to see how it does the Enter key binding, and then just use that to bind to Esc. http://puredata.info/docs/guiplugins/ http://download.puredata.info/completion-plugin Unfortunately, this plugin is GPL'd. I cannot create a derivative work from it to supply to Vanilla. Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Mon, Sep 26, 2011 at 08:40:22AM -0700, Jonathan Wilkes wrote: so if you want your patches to be included into Pd proper, then they must (legally) be BSD3. The main restriction here is that you cannot take or revise someone else's code that is licensed under the GPL and decide to _change_ the license to something else. The GPL does not allow that. Unless you are the copyright holder, you can't *change* the license of BSD3 code, either. You can bundle BSD licensed code in a collective work which is released under the GPL. However, you cannot remove the license nor the copyright notice from a BSD-licensed file. You don't own the IP, you just have permission to use it under the terms of the BSD license, which includes this provision: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. This makes life challenging in a multi-licensing environment, since code cannot move easily between files under different licenses. Here is how the Apache Software Foundation recommends that its projects handle differently licensed code: http://www.apache.org/legal/src-headers.html#3party 4. Minor modifications/additions to third-party source files should typically be licensed under the same terms as the rest of the rest of the third-party source for convenience. 5. Major modifications/additions to third-party should be dealt with on a case-by-case basis by the PMC. At the ASF, though, we only deal with modifications to third-party files with permissive licenses (MIT, BSD, Apache, etc). Things get trickier when one of the licenses is the GPL, because the GPL stakes its claim at the boundary of derivative work, and it takes effort to ensure that BSD code within a project is in no way derived from any of the GPL code in the next directory over. Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Mon, Sep 26, 2011 at 08:29:45PM -0400, Hans-Christoph Steiner wrote: Wow, that's interesting. I don't often hear that, people using Tcl in their work. I write open source code for a living -- Eventful sponsors my work on the Apache Lucy search engine library, and that's where about 75% of my hours go. A volunteer showed up a little while ago who wants to add Tcl bindings for Lucy. I'm teaching myself Tcl so that I can work with this volunteer more effectively. Sure you can, its a .tcl script, meaning you are giving the user the source whenever you are giving the user the program. So its even kind of BSD-ish because you can't give the user a GUI plugin without giving them the source, so you don't need to do anything else to distribute the source. Pd patches are the same idea. I am sincerely grateful for the pointer to this plugin and for your generosity with your time and support, but I assume that a miscommunication has occurred and I am not understanding your suggestion properly. I cannot take code from this plugin, make changes to adapt it for Vanilla, remove the GPL tag and replace it with an implicit BSD license by submitting it to the patch tracker. That would not adhere to the original author's license, and it would be a violation of copyright. If I wish to supply the proposed functionality for Vanilla my options are either to create a new patch from scratch which cannot be considered a derivative work of that plugin, or to track down all the original authors of that plugin, persuade them to issue their code under an additional BSD3 license, and then once that process is complete, create a derivative work and submit it. Best, Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Sun, Sep 25, 2011 at 05:16:23PM +1000, Richie Cyngler wrote: If you drag select an object or group of objects you can use the nudge functionality with cursor keys, you can also hold shift for block moves. So that functionality is already there. Thanks, Richie. It seems that there is a bug affecting Pd on Mac OS X (at least 10.6), and the cursor keys do not function properly. http://sourceforge.net/tracker/index.php?func=detailaid=3187517group_id=55736atid=478070 The bug was reported for 0.43.0-extended-20110119, but is affecting my up-to-date clone of git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data. When I drag-select an object and then press any of the cursor keys, nothing happens, regardless of whether shift is depressed. Furthermore, when editing text inside either an object or a message, pressing any of the cursor keys produces strange effects: * When appending to existing text, the cursor position does not move, but an invisible character is inserted to the right of the cursor. * When either the box is empty, or all existing text is selected (so the next character will replace it) pressing any cursor key inserts a box character. According to the bug report linked above, it seems that the arrow keys work fine on the other platforms. Perhaps it's time to take this to the dev list, as I'm now digging in the source code and it looks like src/g_editor.c and the canvas_key function are the place to start. In regards to a key, like enter, to complete an object I think that's a great idea. I was just thinking the same thing actually. OK, if this is new functionality, I think it should be something other than ENTER. The problem with ENTER is that it is sometimes necessary to insert a newline when editing, especially with comments, and the same key should be used to release focus from any text entry situation. My preference would be for ESC. Cheers, Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Sun, Sep 25, 2011 at 07:11:32AM -0700, Marvin Humphrey wrote: On Sun, Sep 25, 2011 at 05:16:23PM +1000, Richie Cyngler wrote: If you drag select an object or group of objects you can use the nudge functionality with cursor keys, you can also hold shift for block moves. So that functionality is already there. Thanks, Richie. It seems that there is a bug affecting Pd on Mac OS X (at least 10.6), and the cursor keys do not function properly. http://sourceforge.net/tracker/index.php?func=detailaid=3187517group_id=55736atid=478070 The patch below fixes the problem. I don't know if it's the right solution, though. Assuming that cursor keys worked at one time on OS X in Pd... it seems that the keycode sent when a cursor key is pressed may have changed in Snow Leopard. I haven't been able to track down any official documentation, though, nor any other bug reports that describe the root of the problem. Marvin Humphrey diff --git a/src/g_editor.c b/src/g_editor.c index f494732..76586fa 100644 --- a/src/g_editor.c +++ b/src/g_editor.c @@ -1700,13 +1700,13 @@ void canvas_key(t_canvas *x, t_symbol *s, int ac, t_atom *av) keynamesym = gensym(#keyname); } #ifdef __APPLE__ -if (keynum == 30) +if (keynum == 30 || keynum == 63232) keynum = 0, gotkeysym = gensym(Up); -else if (keynum == 31) +else if (keynum == 31 || keynum == 63233) keynum = 0, gotkeysym = gensym(Down); -else if (keynum == 28) +else if (keynum == 28 || keynum == 63234) keynum = 0, gotkeysym = gensym(Left); -else if (keynum == 29) +else if (keynum == 29 || keynum == 63235) keynum = 0, gotkeysym = gensym(Right); #endif if (keynumsym-s_thing down) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Sun, Sep 25, 2011 at 10:51:56AM -0700, Jonathan Wilkes wrote: I'm using Pd-l2ork, and control-Enter toggles between creating the object and editing the text in the box. I thought Pd-extended had this same key binding, but Pd as installed from the debian package in Wheezy does not. None of these combinations provide that behavior on Pd Vanilla built from latest git on OS X 10.6: control-Enter command-Enter option-Enter shift-Enter I could live with control-Enter instead of ESC (especially since I've rewired my caps lock key to control at the OS level using the Keyboard system prefs) -- though ESC works so well for switching modes in Vim. :) Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Mon, Sep 26, 2011 at 08:34:26AM +1000, Richie Cyngler wrote: Oh wow, command+enter works for me! Thanks Jonathan my workflow just got a whole lot smoother! Marvin I'm on OSX 10.6.8 running Pd-extended. Drag select and cursors keys are also working for me. Maybe give Pd-extended a try? Thanks, but if I become a serious user, I hope to make substantial contributions to Pd at some point, and for various reasons my preference is to contribute to a BSD-licensed project over one that is licensed under the GPL. (Not trying to start a discussion, just explaining why I will continue to use Vanilla for now. If someone absolutely must ask why, I expect to reply offlist in the interests of being a good guest.) :) I was under the impression that Pd-extended consisted of augmentations to Vanilla. Is it actually a fork? Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Keyboard shortcuts for nudge, done editing
On Sun, Sep 25, 2011 at 05:33:22PM -0700, Jonathan Wilkes wrote: If you are planning on making substantial contributions to Pd Vanilla, I wouldn't say I'm planning on it -- more that I'd like to keep that option open. you should consider making a few test contributions to gauge the amount of time and energy it will take you to get patches accepted; something like a patch for getting this control-enter key binding would be a good start. Indeed, I've already started that process, by negotiating the shape of the patch to come and building consensus. :) There's been some question as to what key combo should be used. It seems that [modifier]-Enter is already in use and people are happy with it, so I'll go that direction despite my mild personal preference for ESC. A patch which has consensus support from the community probably has a better chance at being applied, even under BDFL governance. :) But consensus can be costly to achieve depending on the project's culture... Also, realize that any substantial changes you make may sit in the patch tracker for some time -- it's not easy getting them accepted, nor communicating with Miller if they don't. Well, controlling entities for open source projects have to be responsive to their communities. If they are not, they get forked, or people move on to other things. But it's also generally true that large, boil-the-ocean patches are costly to review, especially for stable projects with large user bases, and so contributors are well-advised to bear that in mind and prepare small, easily-digested morsels when possible. Additionally, if they are big, desirable improvements to the Pd community they may find their way into Pd-extended anyway. So long as contributions to Vanilla are integrated into Pd-extended in a way that adheres to the provisions of Vanilla's BSD license, then there's no problem. :) Cheers, Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Keyboard shortcuts for nudge, done editing
Greetings, A couple questions from a PD noob: First, is there any keyboard shortcut to signal I'm done editing text? When entering text into an object, a message, etc, it seems that the only way to signal that you are finished is a mouse click outside of the item being edited. I'd like to press a key -- ESC, TAB, ENTER, whatever -- and have the focus leave the text box. Second, is there any keyboard shortcut to nudge an element? It would be great to select an object (or a group of objects), then press LEFT_ARROW to move it one pixel, or CONTROL/COMMANDLEFT_ARROW to move it 10 pixels (or N pixels). If such things are not possible, I'm curious what other mechanisms people have come up with to streamline the editing process, because it feels like I'm having to touch the mouse waaay too often and it's slowing me down. It seems I'm not the only person to have made such observations: http://artengine.ca/~catalogue-pd/18-Lee-Bouchard.pdf One obvious shortcoming is that users are required to constantly switch between keyboard and mouse to operate the program. This becomes especially problematic in the context where patches are developed rapidly. I'm using PD Vanilla, built from the latest sources. I'm an experienced open source developer, fluent in C and learning Tcl, so suggestings that involve hacking the source are welcome. Cheers, Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd~ object under windows - 'can't create'
On Mon, Jun 07, 2010 at 08:46:37AM -0700, Miller Puckette wrote: I'm open to suggestions as to how to et it to work on windows though! (maybe there's an open source pipe implementation somewhere, or maybe I should hack up a shared memory version?) It might be posible to share information using memory mapped files, via mmap() on Unixen and MapViewOfFile() on Windows. Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdpedia and spam
On Sat, Oct 17, 2009 at 12:54:16PM +0100, Philip Potter wrote: Given that it doesn't seem to be used much, I am considering stepping down and leaving it to the spam fiends. I had a choice once for a wiki I ran. A) Leave it to the spam fiends. B) Install captchas. I chose B. The rationale: a wiki with no captchas is better than a wiki with captchas, but a wiki with captchas is better than no wiki at all. Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pdpedia and spam
On Sat, Oct 17, 2009 at 03:59:03PM -0400, Mathieu Bouchard wrote: why wouldn't it be better to just have no wiki at all, Maybe it would be better to kill it off, I dunno. If you're gonna do that, though, either remove it completely or preserve it as a read-only resource. Don't leave the rotting carcass lying around for spammer maggots to feast on. even in a situation where there wouldn't be any spam and the captcha wouldn't be annoying? I don't think spammers ought to be driving the decision when there are countermeasures available. If the wiki is underused or outdated or whatever, do something to address that, such as retiring it. But if it's being used and the problem is the spam-to-edit ratio, captchas, whatever their drawbacks, can treat the spammer pestilence and let the wiki live on to die a natural death at the end of its natural lifespan. Marvin Humphrey ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
