is there any reason why bryan's externals/libraries are not on the sf-cvs (apart from "nobody checked them in")?
mfg.ads.r IOhannes
moin (i|j)ohannes, moin all,
On 2006-02-01 12:19:22, IOhannes m zmoelnig zmoelnig@iem.at appears to have written:
is there any reason why bryan's externals/libraries are not on the sf-cvs (apart from "nobody checked them in")?
well, [ratts] can't go onto sf.net because of licensing trickiness with some of the code from rsynth (i'm still waiting on rsynth-3.0 for a rewrite of the relevant code, but that's been pre-pre-alpha for a few years now, afaik), [sprinkler] is on sf cvs (right off externals/), together with its poorly named predecessor, [forward], which resides in a dead directory (yay for the -P switch)... as to the rest, I've just been too lazy to upload them. If there's interest (I count your inquiry as "some interest", in the existential quantification sense of "some"), I can upload them -- do I have it right that the currently accepted cvs structure is something like
externals/${developer}/${package}/ ?
... so I could grab myself externals/moocow/whatever ?
marmosets, Bryan
Bryan Jurish wrote:
moin (i|j)ohannes, moin all,
moin
been too lazy to upload them. If there's interest (I count your inquiry as "some interest", in the existential quantification sense of "some"),
yes, that would be great.
I can upload them -- do I have it right that the currently accepted cvs structure is something like
externals/${developer}/${package}/ ?
it (imo: unfortunately) seems to be like that
... so I could grab myself externals/moocow/whatever ?
yep that'll be fine.
mfg.asdr. IOhannes
externals/${developer}/${package}/ ?
it (imo: unfortunately) seems to be like that
there are some subdirs like signal/ and control/ now..which could have new subdirs like filters, logic, math, filetypes...maybe the toplevel dirs could be tagged with ALLCAPS categories files for rearrangement when switching to SVN..
cc
Hallo, cdr hat gesagt: // cdr wrote:
externals/${developer}/${package}/ ?
it (imo: unfortunately) seems to be like that
there are some subdirs like signal/ and control/ now.. which could have new subdirs like filters, logic, math, filetypes...maybe the toplevel dirs could be tagged with ALLCAPS categories files for rearrangement when switching to SVN..
That's great! For quite some time now I would like to give away some of my externals to the community by moving them out of externals/footils, namely knob and buzz~. However before I do this, it would be good to agree on some concrete structure for this. Then every developer could decide when to move stuff out of the personalized directory into project-directories.
Ciao
Hey all,
I think one factor that would make the organization of the externals easier is NOT to structure the CVS in that way. What I mean is that there are a plenty of externals that would simultaneously belong to two catagories, like pix_pix2sig~ (not an individual external) which is both audio and video... If we don't have to worry about externals belonging to a particular catagory exclusively then that would make the organization more accurate, and solve some stalemakes.
Symlinks possible from an external in one CVS directory?
The whole help-patch meta-data searching idea would make finding externals very easy, there could even be a commandline version that searches the CVS for a file with the keywords "gem, texture signal" and get a list of matching externals. Mathieu would even like to see a tree of externals that is generated from the keywords.
Anyhow the organization of externals (for the user) need not be the representation us (the developers) have.
One directory for each external In that directory: one external-help.pd for each external (main reference patch) w/ meta-data. plus all the other stuff.
heck searching of the CVS could be done on the server too... (not just locally on a checked out copy)
Just a template for how to organize stuff in CVS could be handy (at least for externals if not libs etc..) but we'll never agree so why bother? ;)
How about contribuing to:
http://puredata.org/Members/bbogart/CatagoriesForExternals/view?searchterm=e...
As a start?
.b..
On Wed, February 1, 2006 11:48 am, Frank Barknecht said:
Hallo, cdr hat gesagt: // cdr wrote:
externals/${developer}/${package}/ ?
it (imo: unfortunately) seems to be like that
there are some subdirs like signal/ and control/ now.. which could have new subdirs like filters, logic, math, filetypes...maybe the toplevel dirs could be tagged with ALLCAPS categories files for rearrangement when switching to SVN..
That's great! For quite some time now I would like to give away some of my externals to the community by moving them out of externals/footils, namely knob and buzz~. However before I do this, it would be good to agree on some concrete structure for this. Then every developer could decide when to move stuff out of the personalized directory into project-directories.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Wed Feb 01, 2006 at 12:28:47PM -0500, B. Bogart wrote:
Hey all,
I think one factor that would make the organization of the externals easier is NOT to structure the CVS in that way.
and just stick with complete disorganization? :D
What I mean is that there are a plenty of externals that would simultaneously belong to two catagories, like pix_pix2sig~ (not an individual external) which is both audio and video...
its not an exact science(1), but it would be helful to be able to cd externals/streaming and see mp3_play~ shoutcast~ pdp_live~ etc. there could even be a category that pix2sig, pdp2grid, netsend, sc4pd might fit into..
metadata
this can help too. perhaps the basic category metadata hint could base itself on it's parent path within externals/
symlinks
great point. not sure ive seen symlinks in CVS or SVN dirs. but how do you propose we caterogize say, the externals in Zexy without making it a total hell for the maintainer?
If we don't have to worry about externals belonging to a particular catagory exclusively then that would make the organization more accurate, and solve some stalemakes.
yeah, it would be great if our filesystems were databases, and supported 'tagging'. maybe we should all switch to BeOS?
one dir per external, w/ doc and metadata
like that, esp for integrated browsing (navigating 5.reference/ was always a safari)
(1) current "portage" categories:
a portage # ls -d */ app-accessibility/ dev-cpp/ games-board/ media-fonts/ net-wireless/ sys-fs/ app-admin/ dev-db/ games-emulation/ media-gfx/ net-www/ sys-kernel/ app-antivirus/ dev-dotnet/ games-engines/ media-libs/ net-zope/ sys-libs/ app-arch/ dev-embedded/ games-fps/ media-plugins/ packages/ sys-power/ app-backup/ dev-games/ games-kids/ media-radio/ perl-core/ sys-process/ app-benchmarks/ dev-haskell/ games-misc/ media-sound/ profiles/ virtual/ app-cdr/ dev-java/ games-mud/ media-tv/ rox-base/ www-apache/ app-crypt/ dev-lang/ games-puzzle/ media-video/ rox-extra/ www-apps/ app-dicts/ dev-libs/ games-roguelike/ metadata/ sci-astronomy/ www-client/ app-doc/ dev-lisp/ games-rpg/ net-analyzer/ sci-biology/ www-misc/ app-editors/ dev-ml/ games-server/ net-dialup/ sci-calculators/ www-servers/ app-emacs/ dev-perl/ games-simulation/ net-dns/ sci-chemistry/ x11-apps/ app-emulation/ dev-php/ games-sports/ net-firewall/ sci-electronics/ x11-base/ app-forensics/ dev-php4/ games-strategy/ net-fs/ sci-geosciences/ x11-drivers/ app-i18n/ dev-php5/ games-util/ net-ftp/ sci-libs/ x11-libs/ app-laptop/ dev-python/ gnome-base/ net-im/ sci-mathematics/ x11-misc/ app-misc/ dev-ruby/ gnome-extra/ net-irc/ sci-misc/ x11-plugins/ app-mobilephone/ dev-scheme/ gnustep-apps/ net-libs/ sci-visualization/ x11-proto/ app-office/ dev-tcltk/ gnustep-base/ net-mail/ scripts/ x11-terms/ app-pda/ dev-tex/ gnustep-libs/ net-misc/ sec-policy/ x11-themes/ app-portage/ dev-tinyos/ kde-base/ net-nds/ sys-apps/ x11-wm/ app-shells/ dev-util/ kde-misc/ net-news/ sys-auth/ xfce-base/ app-text/ distfiles/ licenses/ net-nntp/ sys-block/ xfce-extra/ app-vim/ eclass/ mail-client/ net-p2p/ sys-boot/ app-xemacs/ games-action/ mail-filter/ net-print/ sys-cluster/ dev-ada/ games-arcade/ mail-mta/ net-proxy/ sys-devel/
On Feb 1, 2006, at 4:17 PM, cdr wrote:
yeah, it would be great if our filesystems were databases, and supported 'tagging'. maybe we should all switch to BeOS?
...or osx 10.4+, but we all know what ya think of that ;-) Are there any gnu/linux projects working on this?
james
I've been thinking about this a lot recently, especially with all of the Pd-extended stuff I have been doing. Here's what I am currently thinking would be the best approach:
- new code like moocow gets added in the old-style developer directory.
- new libraries get defined, like math, net, buffer, mapping, io, etc.
- lead maintainers get chosen for each library (it could be more than one person)
- the maintainers then design the library, including which objects should be included, make a naming scheme, arguments, messages, etc. For example, for a math lib, I think that all conversion objects should have a "2" in the name (cart2pol, f2m, etc. instead of carttopol, ftom, etc. for messages, use [reset( everywhere instead of also sometimes [clear(,
- then all additions, etc. go thru these maintainers. What level of control is up to the maintainer. For me, its very important that a library have a very coherent set of standards. Other maintainers might have different ideas (though I would encourage them to try to make things as consistent as possible).
- old developer libraries will be kept for backwards compatibility
- meta data would be used for a class browser, a help browser, etc. There could be many keywords or categories, and an object could be included in many of these categories.
And to address some of Ben's ideas, I think that not having things organized into libraries makes it impossible to have a full namespace like Java. Here is the wiki page I started to outline these ideas:
http://puredata.org/dev/PdLibraries
Ben's page is somewhat related, but I think that page is more related to PDDP, then we could use it to start mapping out the meta data categories that we want to use for the class/help browser.
.hc
On Feb 1, 2006, at 12:28 PM, B. Bogart wrote:
Hey all,
I think one factor that would make the organization of the externals easier is NOT to structure the CVS in that way. What I mean is that there are a plenty of externals that would simultaneously belong to two catagories, like pix_pix2sig~ (not an individual external) which is both audio and video... If we don't have to worry about externals belonging to a particular catagory exclusively then that would make the organization more accurate, and solve some stalemakes.
Symlinks possible from an external in one CVS directory?
The whole help-patch meta-data searching idea would make finding externals very easy, there could even be a commandline version that searches the CVS for a file with the keywords "gem, texture signal" and get a list of matching externals. Mathieu would even like to see a tree of externals that is generated from the keywords.
Anyhow the organization of externals (for the user) need not be the representation us (the developers) have.
One directory for each external In that directory: one external-help.pd for each external (main reference patch) w/ meta-data. plus all the other stuff.
heck searching of the CVS could be done on the server too... (not just locally on a checked out copy)
Just a template for how to organize stuff in CVS could be handy (at least for externals if not libs etc..) but we'll never agree so why bother? ;)
How about contribuing to:
http://puredata.org/Members/bbogart/CatagoriesForExternals/view? searchterm=externals
As a start?
.b..
On Wed, February 1, 2006 11:48 am, Frank Barknecht said:
Hallo, cdr hat gesagt: // cdr wrote:
externals/${developer}/${package}/ ?
it (imo: unfortunately) seems to be like that
there are some subdirs like signal/ and control/ now.. which could have new subdirs like filters, logic, math, filetypes...maybe the toplevel dirs could be tagged with ALLCAPS categories files for rearrangement when switching to SVN..
That's great! For quite some time now I would like to give away some of my externals to the community by moving them out of externals/footils, namely knob and buzz~. However before I do this, it would be good to agree on some concrete structure for this. Then every developer could decide when to move stuff out of the personalized directory into project-directories.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
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
hi.
Hans-Christoph Steiner wrote:
I've been thinking about this a lot recently, especially with all of the Pd-extended stuff I have been doing. Here's what I am currently thinking would be the best approach:
- new code like moocow gets added in the old-style developer directory.
i don't think that this is the _best_ approach (especially as the prominent first item of your list), but i agree that it might be the most practical.
new libraries get defined, like math, net, buffer, mapping, io, etc.
lead maintainers get chosen for each library (it could be more than
one person)
sounds ok, though - just for the archives - these libraries should be structured themselves into sub-libraries (via subdirs), which could be maintained by other people than the parent lib.
as for designing the categories i think it would be best to stick to existing layouts; probably the one from java (and not the one from perl)
- the maintainers then design the library, including which objects
should be included, make a naming scheme, arguments, messages, etc. For example, for a math lib, I think that all conversion objects should have a "2" in the name (cart2pol, f2m, etc. instead of carttopol, ftom,
(while this is just to illustrate the idea, i wonder why you think this (i mean "2" vs "to") is such a good idea....but nevermind
- then all additions, etc. go thru these maintainers. What level of
control is up to the maintainer. For me, its very important that a library have a very coherent set of standards. Other maintainers might have different ideas (though I would encourage them to try to make things as consistent as possible).
i think the main task of the maintainer should be maintainance and not development. as a first step it will be mere collecting/revisioning of existing objects, then adapting them to a "layout" and finally to write the missing parts. (which might be fairly obvious)
- old developer libraries will be kept for backwards compatibility
i don't think that the stdlib-project's goal should be to totally eliminate people's libraries - it should not even cover everything that is now in the externals/-folder i see it as a way to have access to objects for "everyday" usage - not for highly sepcialized things.
are a plenty of externals that would simultaneously belong to two catagories, like pix_pix2sig~ (not an individual external) which is both
btw, i don't think that Gem should be part of the stdlib project. and even if it would, than i would like to have every "real" Gem object in "graphics:Gem"
while having things like [pix_video] and [pdp_qt] in the same package (as in: sub-package of the stdlib) "graphics:pixel:input" makes some functional sense, it will only confuse people into trying to connect [pix_video] to [pdp_xv].
of course, this does not mean that both things don't belong into the same "category" (from a help-browser point of view), so they should be tagged with metadata appropriately.
Symlinks possible from an external in one CVS directory?
on w32?
you could have symlinks in the cvsroot (this is: server side of cvs), but in the sandbox (client side of the cvs) they will appear separate. (but if you checkin the changes of one symlink, the other one will magically get the changes on next update)
anyhow, i (think i) agree with hans that there is some need for a stdlib for pd and that this is _not_ the same as the (also necessary) pddp (even though it superficially seems to be so, as they share some keywords)
mfg.asd.r IOhannes
Hallo!
- lead maintainers get chosen for each library (it could be more than
one person)
sounds ok, though - just for the archives - these libraries should be structured themselves into sub-libraries (via subdirs), which could be maintained by other people than the parent lib.
of course ...
while having things like [pix_video] and [pdp_qt] in the same package (as in: sub-package of the stdlib) "graphics:pixel:input" makes some functional sense, it will only confuse people into trying to connect [pix_video] to [pdp_xv].
yes, I also think that Gem and pdp should have different parent-folders (and also Gridflow) ...
Symlinks possible from an external in one CVS directory?
on w32?
this does not solve the problem of symlinks, but why not just make a different folder for "pd-stdlib", e.g. CVS/pdlib (well, pdlib is not a good name, ... but I have no other one now ... ;)
And something else, which is very important i think: the build system. There should be a common build system, so that developers don't have to write makefiles, configure-scripts etc. when they write an object for this pd-stdlib ... this means: - the buildsystem should be able to compile externals with more then one c file and also with h files ... - should be able to handle dependencies to external C/C++-libraries (e.g. libsndfile ...) - also flext externals should be integrated in that system
Then it would be also easy to make packages of such a pd-stdlib ...
anyhow, i (think i) agree with hans that there is some need for a stdlib
yes, I also think that this would really make much sense !
LG Georg
On Feb 2, 2006, at 7:58 AM, Georg Holzmann wrote:
Hallo!
- lead maintainers get chosen for each library (it could be more
than one person)
sounds ok, though - just for the archives - these libraries should be structured themselves into sub-libraries (via subdirs), which could be maintained by other people than the parent lib.
of course ...
while having things like [pix_video] and [pdp_qt] in the same package (as in: sub-package of the stdlib) "graphics:pixel:input" makes some functional sense, it will only confuse people into trying to connect [pix_video] to [pdp_xv].
yes, I also think that Gem and pdp should have different parent-folders (and also Gridflow) ...
Symlinks possible from an external in one CVS directory?
on w32?
this does not solve the problem of symlinks, but why not just make a different folder for "pd-stdlib", e.g. CVS/pdlib (well, pdlib is not a good name, ... but I have no other one now ... ;)
And something else, which is very important i think: the build system. There should be a common build system, so that developers don't have to write makefiles, configure-scripts etc. when they write an object for this pd-stdlib ... this means:
- the buildsystem should be able to compile externals with more then
one c file and also with h files ...
- should be able to handle dependencies to external C/C++-libraries
(e.g. libsndfile ...)
- also flext externals should be integrated in that system
Then it would be also easy to make packages of such a pd-stdlib ...
Most definitely, I agree with all of these, but the work needs to be done to make this work. The current one needs work in this regard. I think using autoconf is probably inevitable and not a bad thing. Unfortunately, these questions are not easy...
The current externals/Makefile can build multi-file externals (see "hid" target), and use .h files(see "hid" target), and it can handle external dependencies (see "pdogg" target). Its not very clean, and can be a little whacky, but its relatively simple and it works. But don't let that stop anyone from improving it!
As for flext, that's a tricky one, that is only going to get more complicated as people write objects using Thomas' loader functionality. We might have to restrict subsections to one language... hmm...
.hc
anyhow, i (think i) agree with hans that there is some need for a stdlib
yes, I also think that this would really make much sense !
LG Georg
________________________________________________________________________ ____
"Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism." - retired U.S. Army general, William Odom
On Feb 2, 2006, at 6:55 AM, IOhannes m zmoelnig wrote:
hi.
Hans-Christoph Steiner wrote:
I've been thinking about this a lot recently, especially with all of the Pd-extended stuff I have been doing. Here's what I am currently thinking would be the best approach:
- new code like moocow gets added in the old-style developer
directory.
i don't think that this is the _best_ approach (especially as the prominent first item of your list), but i agree that it might be the most practical.
- new libraries get defined, like math, net, buffer, mapping, io, etc.
- lead maintainers get chosen for each library (it could be more than
one person)
sounds ok, though - just for the archives - these libraries should be structured themselves into sub-libraries (via subdirs), which could be maintained by other people than the parent lib.
This idea should probably be tested first to see what kind of problems might arise from names like [math/fft/rifft~]. But a Java-style multi-level namespace would probably also make sense for Pd too.
Namespaces were recently implemented in SmallTalk, so this would probably be a good example to look into. Its similar to Pd in that we are adding a namespace to an established language. There are a number of papers on the topic.
as for designing the categories i think it would be best to stick to existing layouts; probably the one from java (and not the one from perl)
Java is a well defined example of a namespace, but I am not a fan of its C-ishness sometimes. But yes, definitely not perl.
- the maintainers then design the library, including which objects
should be included, make a naming scheme, arguments, messages, etc. For example, for a math lib, I think that all conversion objects should have a "2" in the name (cart2pol, f2m, etc. instead of carttopol, ftom,
(while this is just to illustrate the idea, i wonder why you think this (i mean "2" vs "to") is such a good idea....but nevermind
a) one standard is needed b) I think having a "2" is much clearer to read
ftom (f-tom a strange atom?) vs. f2m (f-to-i, freq2midi would be better) atoi (a-toy) vs. a2i (a-to-i, ascii2int would be better) mtof (m-tof) vs. m2f (m-to-f, midi2freq would be better)
- then all additions, etc. go thru these maintainers. What level of
control is up to the maintainer. For me, its very important that a library have a very coherent set of standards. Other maintainers might have different ideas (though I would encourage them to try to make things as consistent as possible).
i think the main task of the maintainer should be maintainance and not development. as a first step it will be mere collecting/revisioning of existing objects, then adapting them to a "layout" and finally to write the missing parts. (which might be fairly obvious)
Ok, call it a library designer then, if you don't like the word maintainer for that. But I do not think we should take objects as they are just because they work. The interface needs to be standardized, so object names will change, inlets, outlets, arguments, etc. Certain functionality will change too. We of course should use the vast body of existing code, but we should not sacrifice anything to backwards compatibility. These are brand new libraries. They should be thought of as a whole, not merely a bag of assembled tricks. The only libraries will be there for backwards compatibility.
- old developer libraries will be kept for backwards compatibility
i don't think that the stdlib-project's goal should be to totally eliminate people's libraries - it should not even cover everything that is now in the externals/-folder i see it as a way to have access to objects for "everyday" usage - not for highly sepcialized things.
The namespace allows people to do whatever they want in that regard. What I am saying is that we should think of Pd as a platform like Java. And this platform comes with a vast set of standard libs. People are always free to add their own namespaces, classes, etc. But the standard distro should be clearly organized. There is no java.misc, for example, (tho java.util is kind of misc-like).
are a plenty of externals that would simultaneously belong to two catagories, like pix_pix2sig~ (not an individual external) which is both
btw, i don't think that Gem should be part of the stdlib project. and even if it would, than i would like to have every "real" Gem object in "graphics:Gem"
while having things like [pix_video] and [pdp_qt] in the same package (as in: sub-package of the stdlib) "graphics:pixel:input" makes some functional sense, it will only confuse people into trying to connect [pix_video] to [pdp_xv].
The video stuff will probably stay as it is for a long time. Plus Miller is working on making video work with ~ classes. Let's start with the easy problems, like math and io, and not worry about video and other thorny issues for now.
of course, this does not mean that both things don't belong into the same "category" (from a help-browser point of view), so they should be tagged with metadata appropriately.
yes.
Symlinks possible from an external in one CVS directory?
on w32?
you could have symlinks in the cvsroot (this is: server side of cvs), but in the sandbox (client side of the cvs) they will appear separate. (but if you checkin the changes of one symlink, the other one will magically get the changes on next update)
Symlinks are possible with Cygwin, but not MinGW or straight Win32. So unless someone wants to do some serious work getting Pd running on Cygwin, then we should probably not use symlinks for cross-platform stuff.
anyhow, i (think i) agree with hans that there is some need for a stdlib for pd and that this is _not_ the same as the (also necessary) pddp (even though it superficially seems to be so, as they share some keywords)
yes.
.hc
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
On Thu, 2 Feb 2006, Hans-Christoph Steiner wrote:
as for designing the categories i think it would be best to stick to existing layouts; probably the one from java (and not the one from perl)
Java is a well defined example of a namespace, but I am not a fan of its C-ishness sometimes. But yes, definitely not perl.
Strange. My experience has been that all external stuff in Java gets named by the domain name of the author ("vendor"), like org/eds/hans/mystuff/MyStuff.class rather than the Perl layout SomeGeneralCategory/MyStuff/MyStuff.pm.
Which part of Java's namespacing are you thinking about and which part of Perl's namespacing are you thinking about?
ftom (f-tom a strange atom?) vs. f2m (f-to-i, freq2midi would be better)
how is a midi note not a frequency? It should have been hertz to midi. That's clear. The "2" can get in the way. E.g. you convert square meters to square furlongs; in your convention that would be [m22furlong2]. "twenty-two" ?
wouldn't you want [midi_to_hz] to be clearer?
But the standard distro should be clearly organized. There is no java.misc, for example, (tho java.util is kind of misc-like).
java.util is exactly misc-like. Isn't every library a "utility" of some kind anyway??
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Thu, 2 Feb 2006, Mathieu Bouchard wrote:
how is a midi note not a frequency? It should have been hertz to midi. That's clear. The "2" can get in the way. E.g. you convert square meters to square furlongs; in your convention that would be [m22furlong2]. "twenty-two" ?
Another reason that frequency is ambiguous: radians/second are another popular unit of frequency, especially in physics and signal processing. 3.14159 rad/s = 0.5 Hz.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
a) one standard is needed b) I think having a "2" is much clearer to read
If one is a l33t h8x0r or listenes to lots of music by TheArtistFormerlyKnownAsPrinceThenAsSymbolAndNowPrinceAgain. What about [mtwof]?
I'm only half joking: As much as I like to type less as in [t b b] changing mtof or dbtorms to 2-ish names doesn't right, if we already have them as [mtof] for almost a decade now in Pd alone, not even mentioning Max. If there should be one standard, is should be "xtoy". (Note that I doubt there has to be such a standard.)
Ciao
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
a) one standard is needed b) I think having a "2" is much clearer to read
If one is a l33t h8x0r or listenes to lots of music by TheArtistFormerlyKnownAsPrinceThenAsSymbolAndNowPrinceAgain. What about [mtwof]?
I'm only half joking: As much as I like to type less as in [t b b] changing mtof or dbtorms to 2-ish names doesn't right, if we already have them as [mtof] for almost a decade now in Pd alone, not even mentioning Max. If there should be one standard, is should be "xtoy". (Note that I doubt there has to be such a standard.)
Ciao
IMHO it should be _to_ as in x_to_y, xtoys are in my toybox. ;)
Martin
On Feb 2, 2006, at 3:43 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
a) one standard is needed b) I think having a "2" is much clearer to read
If one is a l33t h8x0r or listenes to lots of music by TheArtistFormerlyKnownAsPrinceThenAsSymbolAndNowPrinceAgain. What about [mtwof]?
I'm only half joking: As much as I like to type less as in [t b b] changing mtof or dbtorms to 2-ish names doesn't right, if we already have them as [mtof] for almost a decade now in Pd alone, not even mentioning Max. If there should be one standard, is should be "xtoy". (Note that I doubt there has to be such a standard.)
Like I said before, I think that we should not try to be backwards compatibile for these libraries. The old libraries will be in place for that reason. I am not saying that the names MUST change, that can stay the same if it makes sense. This is a chance to shed a lot of cruft with relatively little difficulty in the transition. We should not waste this opportunity.
There are precidents to the "2" names: - MATLAB has: cart2pol, pol2cart, hex2num, str2num, rsf2csf, hsv2rgb, etc. - Pd has: cart2pol, pol2cart, etc. - There are many commandline utils: pdf2ps, gif2png, etc. etc.
I could be convinced to use "_to_", but "to" aka [mtof] is not clear. Another idea is "->". [hertz->midi], [hsv->rgb]. Actually, I think I might like "->" even better.
While I am at it, I think that we should try to come up with meaningful names. We have plenty of memory these days, even on 10 year old computers, we don't need to use short names. And its also now pretty clearly established in computer science that clear naming saves much more time than short names. Its all about avoiding bugs.
[ftom] is actually a good example, for what Matju pointed out too. There are other units for frequency. [hertz->midi] is much clearer.
.hc
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
I could be convinced to use "_to_", but "to" aka [mtof] is not clear. Another idea is "->". [hertz->midi], [hsv->rgb]. Actually, I think I might like "->" even better.
same. but will it look right in courier? an important consideration..
im not a fan of the_whole_underscore_thing. well it has its place but would look foreign in an object box
On Thu, 2 Feb 2006, Hans-Christoph Steiner wrote:
I could be convinced to use "_to_", but "to" aka [mtof] is not clear. Another idea is "->". [hertz->midi], [hsv->rgb]. Actually, I think I might like "->" even better.
Precedent for "->" includes Scheme:
(symbol->string 'bang) gives "bang" (string->symbol "bang") gives bang
While I am at it, I think that we should try to come up with meaningful names. We have plenty of memory these days, even on 10 year old computers, we don't need to use short names.
What we don't have plenty of, is screen space, especially when Pd eats it horizontally and doesn't let people resize objectboxes to their width of choice.
And its also now pretty clearly established in computer science that clear naming saves much more time than short names. Its all about avoiding bugs.
clear names are clearer. short names are shorter. however, long names aren't necessarily clearer...
what i said about "_to_" wasn't too serious, but i don't know of a good alternative. GF has [#rgb_to_yuv] and [#rgb_to_greyscale], but also has [#import] which turns anything to a grid, and [#export], which converts a grid to a seq of floats, and [#export_list], which converts a grid to a list, and [#export_symbol], which converts a grid to a symbol, so i'm not all consistent about it.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Feb 3, 2006, at 12:31 AM, Mathieu Bouchard wrote:
On Thu, 2 Feb 2006, Hans-Christoph Steiner wrote:
I could be convinced to use "_to_", but "to" aka [mtof] is not clear. Another idea is "->". [hertz->midi], [hsv->rgb]. Actually, I think I might like "->" even better.
Precedent for "->" includes Scheme:
(symbol->string 'bang) gives "bang" (string->symbol "bang") gives bang
While I am at it, I think that we should try to come up with meaningful names. We have plenty of memory these days, even on 10 year old computers, we don't need to use short names.
What we don't have plenty of, is screen space, especially when Pd eats it horizontally and doesn't let people resize objectboxes to their width of choice.
Encapsulation is the key to writing good software in any language, call it functions, procedures, methods, objects, abstractions, subpatches, whatever. If you are writing patches that don't fit on 800x600 using long names, I think you need to encapsulate more.
Its kind of like saying we should all turn our screens 90 degrees so that we can write longer functions in C. ;)
And its also now pretty clearly established in computer science that clear naming saves much more time than short names. Its all about avoiding bugs.
clear names are clearer. short names are shorter. however, long names aren't necessarily clearer...
Yes but clear names tend to be longer.
what i said about "_to_" wasn't too serious, but i don't know of a good alternative. GF has [#rgb_to_yuv] and [#rgb_to_greyscale], but also has [#import] which turns anything to a grid, and [#export], which converts a grid to a seq of floats, and [#export_list], which converts a grid to a list, and [#export_symbol], which converts a grid to a symbol, so i'm not all consistent about it.
How about: [#rgb->yuv] [#rgb->grayscale] (this happens to be a clear name that is not short :) [#->list] [#->symbol]
Tho "export" makes sense in that context too.
.hc
________________________________________________________________________ ____
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it." - Thomas Jefferson
On Fri, 3 Feb 2006, Hans-Christoph Steiner wrote:
Encapsulation is the key to writing good software in any language, call it functions, procedures, methods, objects, abstractions, subpatches, whatever. If you are writing patches that don't fit on 800x600 using long names, I think you need to encapsulate more.
Well, it's not that much the total space of the patch than how much it's possible to have wires not pass under objects, so that the diagrams stay clear. Because we don't have segmented patchcords either, you know.
Somehow, patching requires two-dimensional use of the surface, but some things just seriously indent that space just because there's a lot to write in a single object box, e.g.:
[#inner (4 4 # 76 -44 128 0 150 -85 -108 0 29 128 -21 0 0 0 0 256), seed 128]
now how can i have two boxes like that side to side in a 800x600 page? Note that newlines are allowed in objectboxes, and are properly ignored, but they get so ignored that they don't even survive a save/load. Else, I'd gladly write it like:
[#inner (4 4 # 76 -44 128 0 150 -85 -108 0 29 128 -21 0 0 0 0 256 ), seed 128]
like it ought to be, anyway.
Its kind of like saying we should all turn our screens 90 degrees so that we can write longer functions in C. ;)
When dealing with some people's C code, it wouldn't be a bad idea... combined with smaller fonts of course. I mean especially those situations where you can't improve the encapsulation, because it would be considered a "cosmetic" change and then rejected.
And its also now pretty clearly established in computer science that clear naming saves much more time than short names. Its all about avoiding bugs.
Yes but clear names tend to be longer.
I've got a question for you.
Why did algebra switched to a very terse notation during the 16th century, and that, for most purposes, scientists and engineers haven't looked back much ?
I mean, why did geometers start to write "a²+b²=h²" instead of writing "the square of the length of the adjacent side plus the square of the length of the opposed side equals the square of the length of the long side" like they used to do ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Why did algebra switched to a very terse notation during the 16th century, and that, for most purposes, scientists and engineers haven't looked back much ?
I mean, why did geometers start to write "a²+b²=h²" instead of writing "the square of the length of the adjacent side plus the square of the length of the opposed side equals the square of the length of the long side" like they used to do ?
I must admit, reading "trigger bang anything bang" in a patch to my eyes much looks like "the square of the length of ..." and I really have problems following such patches as quickly as I can follow the more common usual [t b a b].
Ciao
On Feb 5, 2006, at 6:26 AM, Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Why did algebra switched to a very terse notation during the 16th century, and that, for most purposes, scientists and engineers haven't looked back much ?
I mean, why did geometers start to write "a²+b²=h²" instead of writing "the square of the length of the adjacent side plus the square of the length of the opposed side equals the square of the length of the long side" like they used to do ?
I must admit, reading "trigger bang anything bang" in a patch to my eyes much looks like "the square of the length of ..." and I really have problems following such patches as quickly as I can follow the more common usual [t b a b].
I think that's more a matter of what you are used to. Personally, I avoid abbreviations whenever possible, and I find it much more readible. Oftentimes, I need to stretch out big [trigger]s, so the long names help with that.
I like a "bang" to always read "bang", or a "float" to always read "float", like here:
[route float] [route bang] [bang] [bang(
None of these work as [trigger b] or [trigger f] does: [route f] [route b] [b] [b( [f 1(
So it seems to be that the [trigger] abbrevations are a bit of a kludge.
.hc
________________________________________________________________________ ____
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
None of these work as [trigger b] or [trigger f] does: [route f] [route b] [b]
Actually [b] does work. It's functionally equivalent to [t b].
Ciao
On Feb 5, 2006, at 7:01 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
None of these work as [trigger b] or [trigger f] does: [route f] [route b] [b]
Actually [b] does work. It's functionally equivalent to [t b].
Ok, let's try that again. [trigger] understands these shortcuts [t a b f l p s]. These don't work like the [trigger] shortcuts:
[a] [route b] [b( [route f] [f 5( [route l] [l( [l] [route s] [s( [s] != [symbol] [p( [p]
And I am definitely not saying that should work. Instead, I am just pointing out the kludgeyness of the [trigger] shortcuts. No other language that I know has shortcuts for object/message/function names. Each object, message, or function has one name.
.hc
________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
On Sun, 5 Feb 2006, Hans-Christoph Steiner wrote:
And I am definitely not saying that should work. Instead, I am just pointing out the kludgeyness of the [trigger] shortcuts. No other language that I know has shortcuts for object/message/function names. Each object, message, or function has one name.
That's cause [trigger] is phoney shit that should've been deprecated since Noah, because it's trying to do two jobs at once, namely the job of ordering outputs, and the job of [b] [f] [symbol] [pointer] plus a few quirks, without much of a reason. But I've said that before.
To me, the most compelling reason to abbreviate the triggers is that it's the closest thing to making them disappear, among the things that I can do without looking like I'm coming straight from the jMaxlavian refugee ghetto.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sun, Feb 05, 2006 at 08:22:38PM -0500, Mathieu Bouchard wrote:
On Sun, 5 Feb 2006, Hans-Christoph Steiner wrote:
And I am definitely not saying that should work. Instead, I am just pointing out the kludgeyness of the [trigger] shortcuts. No other language that I know has shortcuts for object/message/function names. Each object, message, or function has one name.
That's cause [trigger] is phoney shit that should've been deprecated since Noah, because it's trying to do two jobs at once, namely the job of ordering outputs, and the job of [b] [f] [symbol] [pointer] plus a few quirks, without much of a reason. But I've said that before.
To me, the most compelling reason to abbreviate the triggers is that it's the closest thing to making them disappear, among the things that I can do without looking like I'm coming straight from the jMaxlavian refugee ghetto.
Hi!
Sometimes intelligent design achieves less optimal results than evolution.
Best,
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
On Mon, 6 Feb 2006, Chris McCormick wrote:
To me, the most compelling reason to abbreviate the triggers is that it's the closest thing to making them disappear, among the things that I can do without looking like I'm coming straight from the jMaxlavian refugee ghetto.
Hi! Sometimes intelligent design achieves less optimal results than evolution.
Sounds wise but ambiguous. What do you want to say?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sun, Feb 05, 2006 at 08:40:03PM -0500, Mathieu Bouchard wrote:
On Mon, 6 Feb 2006, Chris McCormick wrote:
To me, the most compelling reason to abbreviate the triggers is that it's the closest thing to making them disappear, among the things that I can do without looking like I'm coming straight from the jMaxlavian refugee ghetto.
Hi! Sometimes intelligent design achieves less optimal results than evolution.
Sounds wise but ambiguous. What do you want to say?
I want to say that sometimes intelligently designing a system can acheive a less optimal result than a system which is subjected to a process of evolution.
Best,
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
On Mon, 6 Feb 2006, Chris McCormick wrote:
On Sun, Feb 05, 2006 at 08:40:03PM -0500, Mathieu Bouchard wrote:
On Mon, 6 Feb 2006, Chris McCormick wrote:
To me, the most compelling reason to abbreviate the triggers is that it's the closest thing to making them disappear, among the things that I can do without looking like I'm coming straight from the jMaxlavian refugee ghetto.
Hi! Sometimes intelligent design achieves less optimal results than evolution.
Sounds wise but ambiguous. What do you want to say?
I want to say that sometimes intelligently designing a system can acheive a less optimal result than a system which is subjected to a process of evolution.
Ok, now I'm lost. which part of what we were saying corresponds to what you consider to be evolution, and which part corresponds to creationism, and why do you say it.
BTW I'm not USAian enough to understand the subtleties of the new phrase "intelligent design" vs the traditional term "creationism" so please bear with me.
Now that I think of it, maybe you're saying that both options could be provided and we'd let people decide and let bad features die off. Maybe we would then find that not only people can't decide themselves, but bad features don't die off, and if perchance they do, they come back to haunt us.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sun, Feb 05, 2006 at 09:01:28PM -0500, Mathieu Bouchard wrote:
On Mon, 6 Feb 2006, Chris McCormick wrote:
On Sun, Feb 05, 2006 at 08:40:03PM -0500, Mathieu Bouchard wrote:
On Mon, 6 Feb 2006, Chris McCormick wrote:
To me, the most compelling reason to abbreviate the triggers is that it's the closest thing to making them disappear, among the things that I can do without looking like I'm coming straight from the jMaxlavian refugee ghetto.
Hi! Sometimes intelligent design achieves less optimal results than evolution.
Sounds wise but ambiguous. What do you want to say?
I want to say that sometimes intelligently designing a system can acheive a less optimal result than a system which is subjected to a process of evolution.
Ok, now I'm lost. which part of what we were saying corresponds to what you consider to be evolution, and which part corresponds to creationism, and why do you say it.
All software is intelligently designed, but some of it is more subjected to the process of evolution (in the market place) than others.
BTW I'm not USAian enough to understand the subtleties of the new phrase "intelligent design" vs the traditional term "creationism" so please bear with me.
Me neither. I am not from the United States, and not interested in that ridiculous debate.
Now that I think of it, maybe you're saying that both options could be provided and we'd let people decide and let bad features die off. Maybe we would then find that not only people can't decide themselves, but bad features don't die off, and if perchance they do, they come back to haunt us.
Maybe. I am saying that software evolution in the Free market place might be the most effective way to get better software. 'Bad' design might help in not becoming trapped at local maxima. Let's not lop off every inefficiency and quirk immediately because it's not 'good design' - many people use [trigger]s successfully to produce great art and sounds, and trigger might be the tip of an iceberg of new thinking. Perhaps Pd is so successful because it has more character than other similar dataflow environments.
Best,
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
On Feb 5, 2006, at 8:22 PM, Mathieu Bouchard wrote:
On Sun, 5 Feb 2006, Hans-Christoph Steiner wrote:
And I am definitely not saying that should work. Instead, I am just pointing out the kludgeyness of the [trigger] shortcuts. No other language that I know has shortcuts for object/message/function names. Each object, message, or function has one name.
That's cause [trigger] is phoney shit that should've been deprecated since Noah, because it's trying to do two jobs at once, namely the job of ordering outputs, and the job of [b] [f] [symbol] [pointer] plus a few quirks, without much of a reason. But I've said that before.
To me, the most compelling reason to abbreviate the triggers is that it's the closest thing to making them disappear, among the things that I can do without looking like I'm coming straight from the jMaxlavian refugee ghetto.
Implement something better!
.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
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
That's cause [trigger] is phoney shit that should've been deprecated since Noah, because it's trying to do two jobs at once, namely the job of ordering outputs, and the job of [b] [f] [symbol] [pointer] plus a few quirks, without much of a reason. But I've said that before.
Maybe then it's best to just always only use "anything" and "bang" as trigger arguments. You would retain the important role trigger plays when ordering outputs without trigger trying to do type conversions except converting to bang which would just be a handy shortcut to avoid lots of [b] objects.
Ciao
On Feb 7, 2006, at 4:04 AM, Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
That's cause [trigger] is phoney shit that should've been deprecated since Noah, because it's trying to do two jobs at once, namely the job of ordering outputs, and the job of [b] [f] [symbol] [pointer] plus a few quirks, without much of a reason. But I've said that before.
Maybe then it's best to just always only use "anything" and "bang" as trigger arguments. You would retain the important role trigger plays when ordering outputs without trigger trying to do type conversions except converting to bang which would just be a handy shortcut to avoid lots of [b] objects.
I was just fiddling with jMax last night. The jMax version of [trigger] would be quite nice to have in Pd. I like how you can stretch it when you need more outlets.
.hc
________________________________________________________________________ ____
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it." - Thomas Jefferson
On Tue, 7 Feb 2006, Hans-Christoph Steiner wrote:
I was just fiddling with jMax last night. The jMax version of [trigger] would be quite nice to have in Pd. I like how you can stretch it when you need more outlets.
jMax's [fork] is weird because you can't stretch it in all versions of jMax. I'm not sure it was even a bug: it looked to me like the feature had been removed willfully.
Otherwise I don't want the stretching of [fork] to cause extra outlets to appear, because I assume stretching an object doesn't change its behaviour, which has a use in the case of [fork], because you can use that in order to have outlets spaced the way you want.
I think that even though GF's [fork] only supports 2 outlets, it should be as many outlets as one want. e.g. [fork 4] would make one with 4 outlets, and $1 would default to 2.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Feb 10, 2006, at 4:07 PM, Mathieu Bouchard wrote:
On Tue, 7 Feb 2006, Hans-Christoph Steiner wrote:
I was just fiddling with jMax last night. The jMax version of [trigger] would be quite nice to have in Pd. I like how you can stretch it when you need more outlets.
jMax's [fork] is weird because you can't stretch it in all versions of jMax. I'm not sure it was even a bug: it looked to me like the feature had been removed willfully.
Otherwise I don't want the stretching of [fork] to cause extra outlets to appear, because I assume stretching an object doesn't change its behaviour, which has a use in the case of [fork], because you can use that in order to have outlets spaced the way you want.
I think that even though GF's [fork] only supports 2 outlets, it should be as many outlets as one want. e.g. [fork 4] would make one with 4 outlets, and $1 would default to 2.
In jMax 4.0.1, stretching just changes the size, shift-stretching adds inlets.
.hc
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
On Tue, 7 Feb 2006, Frank Barknecht wrote:
Maybe then it's best to just always only use "anything" and "bang" as trigger arguments. You would retain the important role trigger plays when ordering outputs without trigger trying to do type conversions except converting to bang which would just be a handy shortcut to avoid lots of [b] objects.
Yeah, that would be the best because b is very common in t and if an equivalent of t had no b then a damn lot of [b] objects would have to be added.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Tue, 7 Feb 2006, Frank Barknecht wrote:
Maybe then it's best to just always only use "anything" and "bang" as trigger arguments. You would retain the important role trigger plays when ordering outputs without trigger trying to do type conversions except converting to bang which would just be a handy shortcut to avoid lots of [b] objects.
Yeah, that would be the best because b is very common in t and if an equivalent of t had no b then a damn lot of [b] objects would have to be added.
Btw: A more important practical problem of [trigger] is, that adding another outlet to an already connected trigger will mess up the previous connections depending on what was connected where. Probably this cannot be solved easily, but it's a real nuisance.
Ciao
I've been messing around with ways to colourize the patch cords in pd as I find that useful as a visual aid in a cluttered patch as well as being less depression-inducing than black ;). I know it's bad form to have cluttered patches but that's the way they always start out when I do them, for me the cleanup phase starts when the patcher is working. The attached c file contains all the functions in pd (these are fromm version 0-39.2) that affect the colours of lines, together with the changes I made that give randomish colours to them, and some comments. I have added code in pseudo-diff format, i.e. lines prefixed with + are to be added, and lines prefixed with - are to be removed, for a total of five insertions across the three source files g_canvas.c, g_editor.c and g_graph.c. I'm using the line's tag to determine its colour as this is AFAIK a number unique to each line. Perhaps someone would like to try it and see what they think, if it's interesting enough I'll submit a proper patch. I would also personally prefer to use orange rather than blue for selections...and the colourizing should be switchable in the main pd window somewhere.
Martin
/* line drawing in pd. These are the functions that draw lines connecting objects in pd 0.39 test 7 */ /* lines prefixed with - are to be removed and replaced with the lines starting with + */ /* if you want to use coloured lines */ /* 2006102 Martin Peach */
/* g_canvas.c 894: */ /* canvas_drawlines is called only from canvas_map in g_canvas.c. This draws lines in newly opened canvases */ static void canvas_drawlines(t_canvas *x) { t_linetraverser t; t_outconnect *oc; { linetraverser_start(&t, x); while (oc = linetraverser_next(&t)) - sys_vgui(".x%lx.c create line %d %d %d %d -width %d -tags l%lx\n", - glist_getcanvas(x), - t.tr_lx1, t.tr_ly1, t.tr_lx2, t.tr_ly2, - (outlet_getsymbol(t.tr_outlet) == &s_signal ? 2:1), - oc); + { + sys_vgui(".x%lx.c create line %d %d %d %d -width %d -tags l%lx -fill #%06lX\n", + glist_getcanvas(x), + t.tr_lx1, t.tr_ly1, t.tr_lx2, t.tr_ly2, + (outlet_getsymbol(t.tr_outlet) == &s_signal ? 2:1), + oc, + (((long)oc<<2) & 0x0FFFFFF)); + } } }
/* g_canvas.c 909: */ /* canvas_fixlinesfor is called by iemgui_size, iemgui_delta, iemgui_pos, iemgui_displace in g_all_guis.c; */ /* by bng_dialog in g_bang.c; */ /* by glist_deselect, canvas_setgraph, canvas_connect(see above) in g_editor.c; */ /* by canvas_addinlet, canvas_rminlet, canvas_resortinlets, canvas_addoutlet, canvas_rmoutlet; */ /* canvas_resortoutlets, graph_displace in g_graph.c */ /* by hradio_dialog, hslider_dialog, my_numbox_dialog, text_displace, */ /* toggle_dialog, vradio_dialog, vslider_dialog, vu_dialog, vu_size */ /* canvas_fixlinesfor sets the coordinates of lines after the objects they connect have changed */ void canvas_fixlinesfor(t_canvas *x, t_text *text) { t_linetraverser t; t_outconnect *oc;
linetraverser_start(&t, x); while (oc = linetraverser_next(&t)) { if (t.tr_ob == text || t.tr_ob2 == text) { sys_vgui(".x%lx.c coords l%lx %d %d %d %d\n", glist_getcanvas(x), oc, t.tr_lx1, t.tr_ly1, t.tr_lx2, t.tr_ly2); + sys_vgui(".x%lx.c itemconfigure l%lx -fill #%06lX\n", + glist_getcanvas(x), oc, (((long)oc<<2) & 0x0FFFFFF)); } } }
/* g_editor.c 99: */ /* glist_selectline is called only by canvas_doclick in g_editor.c */ /* glist_selectline sets the colour of the selected line to blue */ void glist_selectline(t_glist *x, t_outconnect *oc, int index1, int outno, int index2, int inno) { if (x->gl_editor) { glist_noselect(x); x->gl_editor->e_selectedline = 1; x->gl_editor->e_selectline_index1 = index1; x->gl_editor->e_selectline_outno = outno; x->gl_editor->e_selectline_index2 = index2; x->gl_editor->e_selectline_inno = inno; x->gl_editor->e_selectline_tag = oc; sys_vgui(".x%lx.c itemconfigure l%lx -fill blue\n", x, x->gl_editor->e_selectline_tag); } }
/* glist_deselectline is called by glist_select and glist_noselect in g_editor.c */ /* glist_deselectline restores the colour of a deselcted line */ void glist_deselectline(t_glist *x) { if (x->gl_editor) { x->gl_editor->e_selectedline = 0; - sys_vgui(".x%lx.c itemconfigure l%lx -fill black\n", - x, x->gl_editor->e_selectline_tag); + sys_vgui(".x%lx.c itemconfigure l%lx -fill #%06lX\n", + x, x->gl_editor->e_selectline_tag, + (((long)x->gl_editor->e_selectline_tag<<2) & 0x0FFFFFF)); } }
/* g_editor.c 1268: */ /* canvas_doconnect is called only from canvas_mouseup and canvas_motion in g_editor.c */ /* This draws newly connected lines on mouseup (doit = 1) but not motion (doit=0) */ void canvas_doconnect(t_canvas *x, int xpos, int ypos, int which, int doit) { int x11=0, y11=0, x12=0, y12=0; t_gobj *y1; int x21=0, y21=0, x22=0, y22=0; t_gobj *y2; int xwas = x->gl_editor->e_xwas, ywas = x->gl_editor->e_ywas; if (doit) sys_vgui(".x%lx.c delete x\n", x); else sys_vgui(".x%lx.c coords x %d %d %d %d\n", x, x->gl_editor->e_xwas, x->gl_editor->e_ywas, xpos, ypos);
if ((y1 = canvas_findhitbox(x, xwas, ywas, &x11, &y11, &x12, &y12)) && (y2 = canvas_findhitbox(x, xpos, ypos, &x21, &y21, &x22, &y22))) { t_object *ob1 = pd_checkobject(&y1->g_pd); t_object *ob2 = pd_checkobject(&y2->g_pd); int noutlet1, ninlet2; if (ob1 && ob2 && ob1 != ob2 && (noutlet1 = obj_noutlets(ob1)) && (ninlet2 = obj_ninlets(ob2))) { int width1 = x12 - x11, closest1, hotspot1; int width2 = x22 - x21, closest2, hotspot2; int lx1, lx2, ly1, ly2; t_outconnect *oc;
if (noutlet1 > 1) { closest1 = ((xwas-x11) * (noutlet1-1) + width1/2)/width1; hotspot1 = x11 + (width1 - IOWIDTH) * closest1 / (noutlet1-1); } else closest1 = 0, hotspot1 = x11;
if (ninlet2 > 1) { closest2 = ((xpos-x21) * (ninlet2-1) + width2/2)/width2; hotspot2 = x21 + (width2 - IOWIDTH) * closest2 / (ninlet2-1); } else closest2 = 0, hotspot2 = x21;
if (closest1 >= noutlet1) closest1 = noutlet1 - 1; if (closest2 >= ninlet2) closest2 = ninlet2 - 1;
if (canvas_isconnected (x, ob1, closest1, ob2, closest2)) { canvas_setcursor(x, CURSOR_EDITMODE_NOTHING); return; } if (obj_issignaloutlet(ob1, closest1) && !obj_issignalinlet(ob2, closest2)) { if (doit) error("can't connect signal outlet to control inlet"); canvas_setcursor(x, CURSOR_EDITMODE_NOTHING); return; } if (doit) { oc = obj_connect(ob1, closest1, ob2, closest2); lx1 = x11 + (noutlet1 > 1 ? ((x12-x11-IOWIDTH) * closest1)/(noutlet1-1) : 0) + IOMIDDLE; ly1 = y12; lx2 = x21 + (ninlet2 > 1 ? ((x22-x21-IOWIDTH) * closest2)/(ninlet2-1) : 0) + IOMIDDLE; ly2 = y21; - sys_vgui(".x%lx.c create line %d %d %d %d -width %d -tags l%lx\n", - glist_getcanvas(x), - lx1, ly1, lx2, ly2, - (obj_issignaloutlet(ob1, closest1) ? 2 : 1), oc); + sys_vgui(".x%lx.c create line %d %d %d %d -width %d -tags l%lx -fill #%06lX\n", + glist_getcanvas(x), + lx1, ly1, lx2, ly2, + (obj_issignaloutlet(ob1, closest1) ? 2 : 1), oc, + (((long)oc<<2) & 0x0FFFFFF)); canvas_setundo(x, canvas_undo_connect, canvas_undo_set_connect(x, canvas_getindex(x, &ob1->ob_g), closest1, canvas_getindex(x, &ob2->ob_g), closest2), "connect"); } else canvas_setcursor(x, CURSOR_EDITMODE_CONNECT); return; } } canvas_setcursor(x, CURSOR_EDITMODE_NOTHING); }
/* g_editor.c 2176: */ /* canvas_connect is called by canvas_undo_disconnect in g_editor.c and is also */ /* the method for 'connect' messages sent to a canvas */ /* canvas_connect creates lines from 0,0 to 0,0 and then calls */ /* canvas_fixlinesfor to set their true endpoints */
void canvas_connect(t_canvas *x, t_floatarg fwhoout, t_floatarg foutno, t_floatarg fwhoin, t_floatarg finno) { int whoout = fwhoout, outno = foutno, whoin = fwhoin, inno = finno; t_gobj *src = 0, *sink = 0; t_object *objsrc, *objsink; t_outconnect *oc; int nin = whoin, nout = whoout; if (paste_canvas == x) whoout += paste_onset, whoin += paste_onset; for (src = x->gl_list; whoout; src = src->g_next, whoout--) if (!src->g_next) goto bad; /* bug fix thanks to Hannes */ for (sink = x->gl_list; whoin; sink = sink->g_next, whoin--) if (!sink->g_next) goto bad;
/* check they're both patchable objects */ if (!(objsrc = pd_checkobject(&src->g_pd)) || !(objsink = pd_checkobject(&sink->g_pd))) goto bad;
/* if object creation failed, make dummy inlets or outlets as needed */ if (pd_class(&src->g_pd) == text_class && objsrc->te_type == T_OBJECT) while (outno >= obj_noutlets(objsrc)) outlet_new(objsrc, &s_); if (pd_class(&sink->g_pd) == text_class && objsink->te_type == T_OBJECT) while (inno >= obj_ninlets(objsink)) inlet_new(objsink, &objsink->ob_pd, &s_, &s_);
if (!(oc = obj_connect(objsrc, outno, objsink, inno))) goto bad; if (glist_isvisible(x)) { sys_vgui(".x%lx.c create line %d %d %d %d -width %d -tags l%lx\n", glist_getcanvas(x), 0, 0, 0, 0, (obj_issignaloutlet(objsrc, outno) ? 2 : 1),oc); canvas_fixlinesfor(x, objsrc); } return;
bad: post("%s %d %d %d %d (%s->%s) connection failed", x->gl_name->s_name, nout, outno, nin, inno, (src? class_getname(pd_class(&src->g_pd)) : "???"), (sink? class_getname(pd_class(&sink->g_pd)) : "???")); }
/* g_graph.c 634: */ /* Called by canvas_setgraph, canvas_dofont in g_editor.c; graph_bounds, graph_xticks, graph_yticks, */ /* graph_xlabel, graph_ylabel, and graph_displace in g_graph.c */
void glist_redraw(t_glist *x) { if (glist_isvisible(x)) { /* LATER fix the graph_vis() code to handle both cases */ if (glist_istoplevel(x)) { t_gobj *g; t_linetraverser t; t_outconnect *oc; for (g = x->gl_list; g; g = g->g_next) { gobj_vis(g, x, 0); gobj_vis(g, x, 1); } /* redraw all the lines */ linetraverser_start(&t, x); while (oc = linetraverser_next(&t)) sys_vgui(".x%lx.c coords l%lx %d %d %d %d\n", glist_getcanvas(x), oc, t.tr_lx1, t.tr_ly1, t.tr_lx2, t.tr_ly2); + sys_vgui(".x%lx.c itemconfigure l%lx -fill #%06lX\n", + glist_getcanvas(x), oc, (((long)oc<<2) ^ 0x0FFFFFF)); canvas_drawredrect(x, 0); if (x->gl_goprect) { post("draw it"); canvas_drawredrect(x, 1); } } if (x->gl_owner && glist_isvisible(x->gl_owner)) { graph_vis(&x->gl_gobj, x->gl_owner, 0); graph_vis(&x->gl_gobj, x->gl_owner, 1); } } }
/* fin line_drawing_in_pd.c */
A real diff -uw is much more useful since you just apply it with patch, no manual editing necessary.
Also, this feature was around in 0.36-devel, but no one ever ported it forward. I think it would be a nice preference to have. The default color could be black, but you could set audio coords to be a different color if you wanted. Also, it would be good to make the lines anti-aliased too. On Mac OS X, the audio-rate lines are already anti-aliased.
.hc
On Feb 10, 2006, at 4:37 PM, Martin Peach wrote:
I've been messing around with ways to colourize the patch cords in pd as I find that useful as a visual aid in a cluttered patch as well as being less depression-inducing than black ;). I know it's bad form to have cluttered patches but that's the way they always start out when I do them, for me the cleanup phase starts when the patcher is working. The attached c file contains all the functions in pd (these are fromm version 0-39.2) that affect the colours of lines, together with the changes I made that give randomish colours to them, and some comments. I have added code in pseudo-diff format, i.e. lines prefixed with + are to be added, and lines prefixed with - are to be removed, for a total of five insertions across the three source files g_canvas.c, g_editor.c and g_graph.c. I'm using the line's tag to determine its colour as this is AFAIK a number unique to each line. Perhaps someone would like to try it and see what they think, if it's interesting enough I'll submit a proper patch. I would also personally prefer to use orange rather than blue for selections...and the colourizing should be switchable in the main pd window somewhere.
Martin /* line drawing in pd. These are the functions that draw lines connecting objects in pd 0.39 test 7 */ /* lines prefixed with - are to be removed and replaced with the lines starting with + */ /* if you want to use coloured lines */ /* 2006102 Martin Peach */
/* g_canvas.c 894: */ /* canvas_drawlines is called only from canvas_map in g_canvas.c. This draws lines in newly opened canvases */ static void canvas_drawlines(t_canvas *x) { t_linetraverser t; t_outconnect *oc; { linetraverser_start(&t, x); while (oc = linetraverser_next(&t))
sys_vgui(".x%lx.c create line %d %d %d %d -width %d -tags
l%lx\n",
glist_getcanvas(x),
t.tr_lx1, t.tr_ly1, t.tr_lx2, t.tr_ly2,
(outlet_getsymbol(t.tr_outlet) ==
&s_signal ? 2:1),
oc);
{
sys_vgui(".x%lx.c create line %d %d %d %d -width %d -tags l%lx
-fill #%06lX\n",
glist_getcanvas(x),
t.tr_lx1, t.tr_ly1, t.tr_lx2, t.tr_ly2,
(outlet_getsymbol(t.tr_outlet) ==
&s_signal ? 2:1),
oc,
(((long)oc<<2) & 0x0FFFFFF));
}}
}
/* g_canvas.c 909: */ /* canvas_fixlinesfor is called by iemgui_size, iemgui_delta, iemgui_pos, iemgui_displace in g_all_guis.c; */ /* by bng_dialog in g_bang.c; */ /* by glist_deselect, canvas_setgraph, canvas_connect(see above) in g_editor.c; */ /* by canvas_addinlet, canvas_rminlet, canvas_resortinlets, canvas_addoutlet, canvas_rmoutlet; */ /* canvas_resortoutlets, graph_displace in g_graph.c */ /* by hradio_dialog, hslider_dialog, my_numbox_dialog, text_displace, */ /* toggle_dialog, vradio_dialog, vslider_dialog, vu_dialog, vu_size */ /* canvas_fixlinesfor sets the coordinates of lines after the objects they connect have changed */ void canvas_fixlinesfor(t_canvas *x, t_text *text) { t_linetraverser t; t_outconnect *oc;
linetraverser_start(&t, x); while (oc = linetraverser_next(&t)) { if (t.tr_ob == text || t.tr_ob2 == text) { sys_vgui(".x%lx.c coords l%lx %d %d %d %d\n", glist_getcanvas(x), oc, t.tr_lx1, t.tr_ly1, t.tr_lx2, t.tr_ly2);
sys_vgui(".x%lx.c itemconfigure l%lx -fill #%06lX\n",
} }glist_getcanvas(x), oc, (((long)oc<<2) & 0x0FFFFFF));
}
/* g_editor.c 99: */ /* glist_selectline is called only by canvas_doclick in g_editor.c */ /* glist_selectline sets the colour of the selected line to blue */ void glist_selectline(t_glist *x, t_outconnect *oc, int index1, int outno, int index2, int inno) { if (x->gl_editor) { glist_noselect(x); x->gl_editor->e_selectedline = 1; x->gl_editor->e_selectline_index1 = index1; x->gl_editor->e_selectline_outno = outno; x->gl_editor->e_selectline_index2 = index2; x->gl_editor->e_selectline_inno = inno; x->gl_editor->e_selectline_tag = oc; sys_vgui(".x%lx.c itemconfigure l%lx -fill blue\n", x, x->gl_editor->e_selectline_tag); } }
/* glist_deselectline is called by glist_select and glist_noselect in g_editor.c */ /* glist_deselectline restores the colour of a deselcted line */ void glist_deselectline(t_glist *x) { if (x->gl_editor) { x->gl_editor->e_selectedline = 0;
sys_vgui(".x%lx.c itemconfigure l%lx -fill black\n",
x, x->gl_editor->e_selectline_tag);
sys_vgui(".x%lx.c itemconfigure l%lx -fill #%06lX\n",
x, x->gl_editor->e_selectline_tag,
}(((long)x->gl_editor->e_selectline_tag<<2) & 0x0FFFFFF));
}
/* g_editor.c 1268: */ /* canvas_doconnect is called only from canvas_mouseup and canvas_motion in g_editor.c */ /* This draws newly connected lines on mouseup (doit = 1) but not motion (doit=0) */ void canvas_doconnect(t_canvas *x, int xpos, int ypos, int which, int doit) { int x11=0, y11=0, x12=0, y12=0; t_gobj *y1; int x21=0, y21=0, x22=0, y22=0; t_gobj *y2; int xwas = x->gl_editor->e_xwas, ywas = x->gl_editor->e_ywas; if (doit) sys_vgui(".x%lx.c delete x\n", x); else sys_vgui(".x%lx.c coords x %d %d %d %d\n", x, x->gl_editor->e_xwas, x->gl_editor->e_ywas, xpos, ypos);
if ((y1 = canvas_findhitbox(x, xwas, ywas, &x11, &y11, &x12, &y12)) && (y2 = canvas_findhitbox(x, xpos, ypos, &x21, &y21, &x22,
&y22))) { t_object *ob1 = pd_checkobject(&y1->g_pd); t_object *ob2 = pd_checkobject(&y2->g_pd); int noutlet1, ninlet2; if (ob1 && ob2 && ob1 != ob2 && (noutlet1 = obj_noutlets(ob1)) && (ninlet2 = obj_ninlets(ob2))) { int width1 = x12 - x11, closest1, hotspot1; int width2 = x22 - x21, closest2, hotspot2; int lx1, lx2, ly1, ly2; t_outconnect *oc;
if (noutlet1 > 1) { closest1 = ((xwas-x11) * (noutlet1-1) +
width1/2)/width1; hotspot1 = x11 + (width1 - IOWIDTH) * closest1 / (noutlet1-1); } else closest1 = 0, hotspot1 = x11;
if (ninlet2 > 1) { closest2 = ((xpos-x21) * (ninlet2-1) +
width2/2)/width2; hotspot2 = x21 + (width2 - IOWIDTH) * closest2 / (ninlet2-1); } else closest2 = 0, hotspot2 = x21;
if (closest1 >= noutlet1) closest1 = noutlet1 - 1; if (closest2 >= ninlet2) closest2 = ninlet2 - 1; if (canvas_isconnected (x, ob1, closest1, ob2, closest2)) { canvas_setcursor(x, CURSOR_EDITMODE_NOTHING); return; } if (obj_issignaloutlet(ob1, closest1) && !obj_issignalinlet(ob2, closest2)) { if (doit) error("can't connect signal outlet to control
inlet"); canvas_setcursor(x, CURSOR_EDITMODE_NOTHING); return; } if (doit) { oc = obj_connect(ob1, closest1, ob2, closest2); lx1 = x11 + (noutlet1 > 1 ? ((x12-x11-IOWIDTH) * closest1)/(noutlet1-1) : 0) + IOMIDDLE; ly1 = y12; lx2 = x21 + (ninlet2 > 1 ? ((x22-x21-IOWIDTH) * closest2)/(ninlet2-1) : 0) + IOMIDDLE; ly2 = y21;
sys_vgui(".x%lx.c create line %d %d %d %d -width %d
-tags l%lx\n",
glist_getcanvas(x),
lx1, ly1, lx2, ly2,
(obj_issignaloutlet(ob1, closest1) ? 2 :
1), oc);
sys_vgui(".x%lx.c create line %d %d %d %d -width %d
-tags l%lx -fill #%06lX\n",
glist_getcanvas(x),
lx1, ly1, lx2, ly2,
(obj_issignaloutlet(ob1, closest1) ? 2 :
1), oc,
} } canvas_setcursor(x, CURSOR_EDITMODE_NOTHING);(((long)oc<<2) & 0x0FFFFFF)); canvas_setundo(x, canvas_undo_connect, canvas_undo_set_connect(x, canvas_getindex(x, &ob1->ob_g), closest1, canvas_getindex(x, &ob2->ob_g), closest2), "connect"); } else canvas_setcursor(x, CURSOR_EDITMODE_CONNECT); return;
}
/* g_editor.c 2176: */ /* canvas_connect is called by canvas_undo_disconnect in g_editor.c and is also */ /* the method for 'connect' messages sent to a canvas */ /* canvas_connect creates lines from 0,0 to 0,0 and then calls */ /* canvas_fixlinesfor to set their true endpoints */
void canvas_connect(t_canvas *x, t_floatarg fwhoout, t_floatarg foutno, t_floatarg fwhoin, t_floatarg finno) { int whoout = fwhoout, outno = foutno, whoin = fwhoin, inno = finno; t_gobj *src = 0, *sink = 0; t_object *objsrc, *objsink; t_outconnect *oc; int nin = whoin, nout = whoout; if (paste_canvas == x) whoout += paste_onset, whoin += paste_onset; for (src = x->gl_list; whoout; src = src->g_next, whoout--) if (!src->g_next) goto bad; /* bug fix thanks to Hannes */ for (sink = x->gl_list; whoin; sink = sink->g_next, whoin--) if (!sink->g_next) goto bad;
/* check they're both patchable objects */ if (!(objsrc = pd_checkobject(&src->g_pd)) || !(objsink = pd_checkobject(&sink->g_pd))) goto bad; /* if object creation failed, make dummy inlets or outlets as needed */ if (pd_class(&src->g_pd) == text_class && objsrc->te_type ==
T_OBJECT) while (outno >= obj_noutlets(objsrc)) outlet_new(objsrc, &s_); if (pd_class(&sink->g_pd) == text_class && objsink->te_type == T_OBJECT) while (inno >= obj_ninlets(objsink)) inlet_new(objsink, &objsink->ob_pd, &s_, &s_);
if (!(oc = obj_connect(objsrc, outno, objsink, inno))) goto bad; if (glist_isvisible(x)) { sys_vgui(".x%lx.c create line %d %d %d %d -width %d -tags
l%lx\n", glist_getcanvas(x), 0, 0, 0, 0, (obj_issignaloutlet(objsrc, outno) ? 2 : 1),oc); canvas_fixlinesfor(x, objsrc); } return;
bad: post("%s %d %d %d %d (%s->%s) connection failed", x->gl_name->s_name, nout, outno, nin, inno, (src? class_getname(pd_class(&src->g_pd)) : "???"), (sink? class_getname(pd_class(&sink->g_pd)) : "???")); }
/* g_graph.c 634: */ /* Called by canvas_setgraph, canvas_dofont in g_editor.c; graph_bounds, graph_xticks, graph_yticks, */ /* graph_xlabel, graph_ylabel, and graph_displace in g_graph.c */
void glist_redraw(t_glist *x) { if (glist_isvisible(x)) { /* LATER fix the graph_vis() code to handle both cases */ if (glist_istoplevel(x)) { t_gobj *g; t_linetraverser t; t_outconnect *oc; for (g = x->gl_list; g; g = g->g_next) { gobj_vis(g, x, 0); gobj_vis(g, x, 1); } /* redraw all the lines */ linetraverser_start(&t, x); while (oc = linetraverser_next(&t)) sys_vgui(".x%lx.c coords l%lx %d %d %d %d\n", glist_getcanvas(x), oc, t.tr_lx1, t.tr_ly1, t.tr_lx2, t.tr_ly2);
sys_vgui(".x%lx.c itemconfigure l%lx -fill #%06lX\n",
} if (x->gl_owner && glist_isvisible(x->gl_owner)) { graph_vis(&x->gl_gobj, x->gl_owner, 0); graph_vis(&x->gl_gobj, x->gl_owner, 1); } }glist_getcanvas(x), oc, (((long)oc<<2) ^ 0x0FFFFFF)); canvas_drawredrect(x, 0); if (x->gl_goprect) { post("draw it"); canvas_drawredrect(x, 1); }
}
/* fin line_drawing_in_pd.c */ _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
Hans-Christoph Steiner wrote:
A real diff -uw is much more useful since you just apply it with patch, no manual editing necessary.
I'm not experienced with automated patching, I suppose there would be three diff files, one for each source file (g_canvas.c, g_editor.c and g_graph.c)? And what happens if someone else changes the source files in the interim?
Also, this feature was around in 0.36-devel, but no one ever ported it forward. I think it would be a nice preference to have. The default color could be black, but you could set audio coords to be a different color if you wanted. Also, it would be good to make the lines anti-aliased too. On Mac OS X, the audio-rate lines are already anti-aliased.
Currently it looks as though the audio rate lines are of width 2, maybe that's what makes them anti-aliased. Maybe all lines could be width 2 and the audio lines striped as in Max. --or selected lines could go to width+2 instead of changing colour, also as in Max. Ideally each line would have a colour field in its struct so the colour doesn't have to be recalculated, but that is a pd-wide adjustment. Also the method I used for determining the colour seems to give mostly dark brown and green lines, maybe a random colour would be better.
Martin
On Feb 13, 2006, at 4:40 PM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
A real diff -uw is much more useful since you just apply it with patch, no manual editing necessary.
I'm not experienced with automated patching, I suppose there would be three diff files, one for each source file (g_canvas.c, g_editor.c and g_graph.c)? And what happens if someone else changes the source files in the interim?
Its quite easy if you use sources that are checked out from CVS. Here's how you would do it: first, check out the sources from CVS; then make the changes in the source and compile it to make sure the changes work; then to make the patch, run this command:
cvs diff -uw g_canvas.c g_editor.c g_graph.c > /path/to/my_patch.patch
then /path/to/my_patch.patch is the file. If you make a patch using -u format, then the program "patch" is actually quite good at handling changes to the source file. It will only choke if the exact same lines are changed.
.hc
Also, this feature was around in 0.36-devel, but no one ever ported it forward. I think it would be a nice preference to have. The default color could be black, but you could set audio coords to be a different color if you wanted. Also, it would be good to make the lines anti-aliased too. On Mac OS X, the audio-rate lines are already anti-aliased.
Currently it looks as though the audio rate lines are of width 2, maybe that's what makes them anti-aliased. Maybe all lines could be width 2 and the audio lines striped as in Max. --or selected lines could go to width+2 instead of changing colour, also as in Max. Ideally each line would have a colour field in its struct so the colour doesn't have to be recalculated, but that is a pd-wide adjustment. Also the method I used for determining the colour seems to give mostly dark brown and green lines, maybe a random colour would be better.
Martin
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.
Martin Peach wrote:
Hans-Christoph Steiner wrote:
A real diff -uw is much more useful since you just apply it with patch, no manual editing necessary.
I'm not experienced with automated patching, I suppose there would be three diff files, one for each source file (g_canvas.c, g_editor.c and g_graph.c)? And what happens if someone else changes the source files in the interim?
that's why you do a "unified" (that's the "-u" flag) diff: it gives you (or the "patch"-program) a context where the changes appeared. example: original file: a b c
modified file: a b 0 c
a normal diff would say: in line 3 replace "c" by "0\nc"
now imagine somebody had changed the file beforehand to: a 1 b c
now line3 reads "b", and thus the patch (which replaces the line3 "c" by "0\nc") has to fail.
a unified diff would say: near line 3 insert "0" between the line containing "b" and the line containing "c". this patch can still be applied, even if "c" is now in line 4.
Currently it looks as though the audio rate lines are of width 2, maybe that's what makes them anti-aliased. Maybe all lines could be width 2 and the audio lines striped as in Max. --or selected lines could go to width+2 instead of changing colour, also as in Max.
personally i think that fat lines can be read better than striped ones.
i am not sure whether i would want all my chords have a different color. i think that would add to the confusion rather than minimize it. i would be quite content if signal and message chords can be separated, e.g. because signal chords were red and message chords stay black (or green, if you prefer that)
and of course i am not at all for "make it look like max" - but that's just my personal feeling.
mfg.asdr. IOhannes
On Feb 5, 2006, at 4:27 AM, Mathieu Bouchard wrote:
On Fri, 3 Feb 2006, Hans-Christoph Steiner wrote:
Encapsulation is the key to writing good software in any language, call it functions, procedures, methods, objects, abstractions, subpatches, whatever. If you are writing patches that don't fit on 800x600 using long names, I think you need to encapsulate more.
Well, it's not that much the total space of the patch than how much it's possible to have wires not pass under objects, so that the diagrams stay clear. Because we don't have segmented patchcords either, you know.
Somehow, patching requires two-dimensional use of the surface, but some things just seriously indent that space just because there's a lot to write in a single object box, e.g.:
[#inner (4 4 # 76 -44 128 0 150 -85 -108 0 29 128 -21 0 0 0 0 256), seed 128]
now how can i have two boxes like that side to side in a 800x600 page? Note that newlines are allowed in objectboxes, and are properly ignored, but they get so ignored that they don't even survive a save/load. Else, I'd gladly write it like:
[#inner (4 4 # 76 -44 128 0 150 -85 -108 0 29 128 -21 0 0 0 0 256 ), seed 128]
like it ought to be, anyway.
Its kind of like saying we should all turn our screens 90 degrees so that we can write longer functions in C. ;)
When dealing with some people's C code, it wouldn't be a bad idea... combined with smaller fonts of course. I mean especially those situations where you can't improve the encapsulation, because it would be considered a "cosmetic" change and then rejected.
And its also now pretty clearly established in computer science that clear naming saves much more time than short names. Its all about avoiding bugs.
Yes but clear names tend to be longer.
I've got a question for you.
Why did algebra switched to a very terse notation during the 16th century, and that, for most purposes, scientists and engineers haven't looked back much ?
I mean, why did geometers start to write "a²+b²=h²" instead of writing "the square of the length of the adjacent side plus the square of the length of the opposed side equals the square of the length of the long side" like they used to do ?
Math is not computer science. I know little about math, and I don't think its always applicable to computer science.
So I have a question for you: why have programming languages and computer interfaces switched to longer words without looking back?
.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
Hans-Christoph Steiner wrote:
I could be convinced to use "_to_", but "to" aka [mtof] is not clear. Another idea is "->". [hertz->midi], [hsv->rgb]. Actually, I think I might like "->" even better.
Yes, me too, but I thought the > might get snagged on its trip through the multitude of parsers...
Martin
Martin Peach wrote:
Hans-Christoph Steiner wrote:
I could be convinced to use "_to_", but "to" aka [mtof] is not clear. Another idea is "->". [hertz->midi], [hsv->rgb]. Actually, I think I might like "->" even better.
Yes, me too, but I thought the > might get snagged on its trip through the multitude of parsers...
For example on Windows a filename cannot contain [/:*?"<>|] so hertz->midi.dll couldn't exist.
Martin
On Feb 3, 2006, at 12:45 PM, Martin Peach wrote:
Martin Peach wrote:
Hans-Christoph Steiner wrote:
I could be convinced to use "_to_", but "to" aka [mtof] is not clear. Another idea is "->". [hertz->midi], [hsv->rgb]. Actually, I think I might like "->" even better.
Yes, me too, but I thought the > might get snagged on its trip through the multitude of parsers...
For example on Windows a filename cannot contain [/:*?"<>|] so hertz->midi.dll couldn't exist.
But thanks to IOhannes' hex loader patch (included in Pd-0.38.4-extended and Pd-0.40 in CVS), you can replace those chars with hex values in filenames. So it will work fine.
.hc ________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
On Feb 3, 2006, at 11:17 AM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
I could be convinced to use "_to_", but "to" aka [mtof] is not clear. Another idea is "->". [hertz->midi], [hsv->rgb]. Actually, I think I might like "->" even better.
Yes, me too, but I thought the > might get snagged on its trip through the multitude of parsers...
Thanks to IOhannes' hex loader patch, the setup functions will work with these names now too. Within Pd, its a symbol, so it should be no problem.
The Mac OS X and GNU/Linux filesystems handle those names fine. But of course Windows is a pain: NTFS does not allow these characters in filenames:
< > : " / \ |
But again, IO's hex loader patch works on filenames too, so well have to get used to seeing "0x3c" in filenames, i.e. hertz-0x3Cmidi.pd = [hertz->midi].
.hc
________________________________________________________________________ ____
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Thanks to IOhannes' hex loader patch, the setup functions will work with these names now too. Within Pd, its a symbol, so it should be no problem.
It would be for abstractions, AFAIK.
Ciao
On Feb 3, 2006, at 1:10 PM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Thanks to IOhannes' hex loader patch, the setup functions will work with these names now too. Within Pd, its a symbol, so it should be no problem.
It would be for abstractions, AFAIK.
No, its for filenames and setup functions for any object. Plus I think there is support for the hex names with Thomas' loaders functionality. If its not already part of the loaders, it should be, and it would not be hard to do.
.hc ________________________________________________________________________ ____
"Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies." - Amy Smith
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Thanks to IOhannes' hex loader patch, the setup functions will work with these names now too. Within Pd, its a symbol, so it should be no problem.
It would be for abstractions, AFAIK.
my original hex-loader was used whenever it comes to the instantion (what is the word? creation of a class) of an (yet unknown) object: thus it worked for both externals and abstractions.
mfg.adsr. IOhannes
btw: miller took the hex-loader patch as i originally made it, which means "setup_0x12"-like functions! (which is not what pd-extended expectes)
On Feb 3, 2006, at 4:28 PM, IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Thanks to IOhannes' hex loader patch, the setup functions will work with these names now too. Within Pd, its a symbol, so it should be no problem.
It would be for abstractions, AFAIK.
my original hex-loader was used whenever it comes to the instantion (what is the word?
instance, instantiate, instantiation...
creation of a class) of an (yet unknown) object: thus it worked for both externals and abstractions.
mfg.adsr. IOhannes
btw: miller took the hex-loader patch as i originally made it, which means "setup_0x12"-like functions! (which is not what pd-extended expectes)
ah, ok, I'll change the patch then...
.hc
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Thanks to IOhannes' hex loader patch, the setup functions will work with these names now too. Within Pd, its a symbol, so it should be no problem.
It would be for abstractions, AFAIK.
my original hex-loader was used whenever it comes to the instantion (what is the word? creation of a class) of an (yet unknown) object: thus it worked for both externals and abstractions.
I admit, I didn't yet play with the patch, so this question may stupid, but: To save a patch using a silly name, do I need to "escape" forbidden characters by hand or does the file selector take care of this?
Ciao
On Feb 3, 2006, at 6:22 PM, Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Thanks to IOhannes' hex loader patch, the setup functions will work with these names now too. Within Pd, its a symbol, so it should be no problem.
It would be for abstractions, AFAIK.
my original hex-loader was used whenever it comes to the instantion (what is the word? creation of a class) of an (yet unknown) object: thus it worked for both externals and abstractions.
I admit, I didn't yet play with the patch, so this question may stupid, but: To save a patch using a silly name, do I need to "escape" forbidden characters by hand or does the file selector take care of this?
Hmm... that's a good question. Currently, you have to do it by hand, but it should probably do it automatically perhaps...
.hc
________________________________________________________________________ ____
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
On Fri, 3 Feb 2006, Hans-Christoph Steiner wrote:
< > : " / \ | But again, IO's hex loader patch works on filenames too, so well have to get used to seeing "0x3c" in filenames, i.e. hertz-0x3Cmidi.pd = [hertz->midi].
Here's a demangling script for you:
echo hertz-0x3Cmidi.pd | ruby -ne 'puts gsub(/0x(..)/){$1.hex.chr}'
which yields:
hertz-<midi.pd
but chances are you wanted to say hertz-0x3Emidi.pd
also, in Perl:
echo hertz-0x3Cmidi.pd | perl -ne 's/(0x..)/chr(eval $1)/ge;print'
This may be helpful whenever demangling is needed in scripts or makefiles.
A Tcl version would be cool, but i'm not *that* good with Tcl regexps.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Fri, 3 Feb 2006, Hans-Christoph Steiner wrote:
< > : " / \ | But again, IO's hex loader patch works on filenames too, so well have to get used to seeing "0x3c" in filenames, i.e. hertz-0x3Cmidi.pd = [hertz->midi].
Here's a demangling script for you:
echo hertz-0x3Cmidi.pd | ruby -ne 'puts gsub(/0x(..)/){$1.hex.chr}'
which yields:
hertz-<midi.pd
but chances are you wanted to say hertz-0x3Emidi.pd
also, in Perl:
echo hertz-0x3Cmidi.pd | perl -ne 's/(0x..)/chr(eval $1)/ge;print'
This may be helpful whenever demangling is needed in scripts or makefiles.
A Tcl version would be cool, but i'm not *that* good with Tcl regexps.
This is a bit too clunky to do off the command line, but:
set name hertz-0x3Cmidi.pd puts [regsub {0x(..)} $name [format "%c" [lindex [regexp -inline {0x(..)} $name] 0 ]]]
I'm still learning tcl so I'm sure there is a better way to do this.
Martin
On Feb 1, 2006, at 11:10 AM, cdr wrote:
externals/${developer}/${package}/ ?
it (imo: unfortunately) seems to be like that
there are some subdirs like signal/ and control/ now..which could have new subdirs like filters, logic, math, filetypes...maybe the toplevel dirs could be tagged with ALLCAPS categories files for rearrangement when switching to SVN..
I think for now, moocow should be added in its own directory. The layout for libraries is not defined enough to start putting objects into it IMHO. And we can always move the code later once things are figured out.
.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