Hallo all, Just wanted to post an idea... It would be great if Pd highligted modified abstractions in red in their parent patch (that is, the one pixel bounding box and text. When I've modified one of a bunch of abstractions in a parent and close it without saving, I have to open each one to see if it was the one I modified.
Another thing I've been thinking about is an integrated method to view diffed patches (most especially when resolving an SVN conflict)... something like OS X's FileMerge for Pd.
Ok, there are my PitS ideas, in case anyone wants to write them before I get around to it :).
On Thu, 2007-05-10 at 20:42 -0700, Luke Iannini (pd) wrote:
Just wanted to post an idea... It would be great if Pd highligted modified abstractions in red in their parent patch (that is, the one pixel bounding box and text. When I've modified one of a bunch of abstractions in a parent and close it without saving, I have to open each one to see if it was the one I modified.
you could easily come around this by letting the window of the instance of your abstraction open, that you have modified. when testing is finished and you decide to save changes, you know which one to save. however, i like the idea as well. a visual feedback in the parent patch would be nice.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Yes; this suggestion is for when I close the window inadvertently : )
On 5/11/07, Roman Haefeli reduzierer@yahoo.de wrote:
On Thu, 2007-05-10 at 20:42 -0700, Luke Iannini (pd) wrote:
Just wanted to post an idea... It would be great if Pd highligted modified abstractions in red in their parent patch (that is, the one pixel bounding box and text. When I've modified one of a bunch of abstractions in a parent and close it without saving, I have to open each one to see if it was the one I modified.
you could easily come around this by letting the window of the instance of your abstraction open, that you have modified. when testing is finished and you decide to save changes, you know which one to save. however, i like the idea as well. a visual feedback in the parent patch would be nice.
roman
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think there is a lot of potential for using color in Pd patches to
represent state. It's just a matter of trying things. It would
take some diving into the guts of Pd.
.hc
On May 10, 2007, at 11:42 PM, Luke Iannini (pd) wrote:
Hallo all, Just wanted to post an idea... It would be great if Pd highligted modified abstractions in red in their parent patch (that is, the one pixel bounding box and text. When I've modified one of a bunch of abstractions in a parent and close it without saving, I have to open each one to see if it was the one I modified.
Another thing I've been thinking about is an integrated method to view diffed patches (most especially when resolving an SVN conflict)... something like OS X's FileMerge for Pd.
Ok, there are my PitS ideas, in case anyone wants to write them before I get around to it :).
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
..and also the ever-requested 'turn an abstraction into a subpatch' button.
was there ever a good reason not to make that? should be simple, no?
hard off wrote:
..and also the ever-requested 'turn an abstraction into a subpatch' button.
was there ever a good reason not to make that? should be simple, no?
well, there are plenty of reasons for not doing that. first of all: an abstraction has features that a subpatch lacks; that is why they are there. what do you gain from turning abstractions into subpatches?? compare it to what you lose...
i would vote for a 'turn subpatch into an abstraction' button though.
and of course the long awaited feature to embed abstractions in abstractions.
mfg.asdr IOhannes
On Tue, 2007-05-15 at 17:43 +0200, IOhannes m zmoelnig wrote:
i would vote for a 'turn subpatch into an abstraction' button though.
and of course the long awaited feature to embed abstractions in abstractions.
what does this mean? something like libs embed external objects?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo!
i would vote for a 'turn subpatch into an abstraction' button though.
and of course the long awaited feature to embed abstractions in abstractions.
what does this mean? something like libs embed external objects?
think about maybe like functions in a python script or c program or whatever. You can reuse the function in the whole file, but the function is also defined in the same file.
So in PD this would mean that you can define an e-abs ("embedded abstraction" ;) somewhere, which is only valid for the scope of the current patch, but you can use this e-abs in the whole patch (or abstraction) without coding it multiple times ...
LG Georg
Georg Holzmann wrote:
Hallo!
think about maybe like functions in a python script or c program or whatever. You can reuse the function in the whole file, but the function is also defined in the same file.
I don't know about Python, but C programs are limited to named functions, you can't have anonymous functions that you define where you need them - you end up having to define a zillion names for things you only use once.
What would be really cool if this gets implemented in the right way, is that you could have embedded abstractions instantiated in a subpatch of a main patch by internal messages - should make some dynamic patching tasks a lot easier (and quicker - I have a patch that has 256 instances of an abstraction, takes an age to load the abstraction from hard disk each time...).
What would be even cooler is if you could create embedded abstractions with internal messages - imagine creating abstractions as and when you need them (with $0-names if you like, global names if you like too) that you can use for bits and pieces - so Frank's list-abs things could change their behaviour at runtime.
Say you had [list-foldr + 0], that sums all elements of a list, you could send a message like "op *, seed 1" to have it clear its current behaviour and create a new embedded abstraction to find the product of the elements of a list. Or even have the parent patch have an embedded abstraction $0-blah that does:
[inlet] [inlet] | | | [* 10] | | [+ ] | [outlet]
Then:
"list 0 1 2 3 4 5 6 7 8 9" | [list-foldr $0-blah 0] | 9876543210 -- in base 10 ;)
Give me lambda abstraction and I'm a happy programmer!
Now what about currying?
Claude
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
What would be even cooler is if you could create embedded abstractions with internal messages - imagine creating abstractions as and when you need them (with $0-names if you like, global names if you like too)
Which makes me wonder: Should these theoretical embedded abstractions have their own $0? I'd vote for yes.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
What would be even cooler is if you could create embedded abstractions with internal messages - imagine creating abstractions as and when you need them (with $0-names if you like, global names if you like too)
Which makes me wonder: Should these theoretical embedded abstractions have their own $0? I'd vote for yes.
Of course! They can get their parents' $0s if the parent wants to pass them down through creation arguments, like any other abstraction :)
Ciao
Claude
-
Claude Heiland-Allen -
Frank Barknecht -
Georg Holzmann -
Hans-Christoph Steiner -
hard off -
IOhannes m zmoelnig -
Luke Iannini (pd) -
Roman Haefeli