abstractions...i meant abstractions

Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:

...

out of interest, is there any difference in cpu usage between a message box bang, and [t b] ???

|bang( evaluates the string "bang" to a bang ... in general, you don't want to do that ...

|b| is the object of choice ...

Though the difference is quite minor. The object to absolutely avoid is the GUI-bang.

Attached is a little benchmark for all four types. The GUI-bang gives horrible results and you have to be careful not to halt Pd with that benchmark patch.

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

Ultimately, it sounds like these would be very good candidates for a
"file" library, i.e. a library of all file related functions. But as
I have said earlier, I think we should approach the design of these
new standard libraries in a top-down way. We already have a massive
amount of code built from the bottom-up to draw from. Now its time
to design libraries to be consistent and clean, and then port the
existing code to these new libraries.

This includes pulling out the objects from Pd core. So things like
[openpanel] and [savepanel] should probably be in the "file"
library. My goal for Pd-0.39.2-extended is to build all of the Pd- core objects as a single-file externals in a libdir for backwards
compatibility, then start porting them to new standardized libraries.

Part of this will also be moving all of the externals/build/src
objects into their own libdir, so that by default, there will only be
the very minimal core objects in the root namespace. Everything else
will have a lib prefix. Then preferences files like the current Pd- extended ones (org.puredata.pd.plist and pd-settings.reg) can set up
a backwards-compatible environment.

Ben, want to take on the "file" library?

.hc

On Feb 27, 2006, at 11:01 AM, B. Bogart wrote:

hi Andres,

I don't have time to try them out now, but they look very nice. I'm especially interested in objects.pd what does it do exactly?

Anyhow to the devs, pixelTANGO has a slew of useful abstractions that are there only to make the patching of the high-level GOPs easier, things like [dirpanel] to choose a directory, and [dirlist] to read
all files that match a wildcard pattern in a directory and output as a
list.

They don't have any help-files yet, so the pixelTANGO GOP abstractions are the best documentation on how to use them.

So the question is, since these abstractions work outside of the
context of pixelTANGO, how should they be included in CVS? Right now they are all in the pixelTANGO folder...

As we're talking about redundancy in externals what do you all think should be done to reduce the problem of too many redundant
abstractions? (specifically excluding such conceptual sets of abstractions, like Frank's abstraction reimplimentations of externals)

Just thinking aloud again...

.b.

Andres Ferrari wrote:

...

here, some useful and pedagogical abstractions. acceptance suggestions. enjoy.

http://www.puredata.org/Members/anfex

soon, some more.

---

Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

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