patco hat gesagt: // patco wrote:


>> I keep on saying that using a message box is more usefull
>> for fixed memory settings,
>> like in the GOP menu patch submitted before,
>> than being in need of a textfile.
>>
>> Any memory used for things that doesn't need
>> to be saved under a preset, have absolutely no reason
>> to be in an external file, it's irrelevant.

>True, but they also have no need to be in a message box, if they are
>temporary anyway.

 Well, at least when we save the patch, the values inside the message are stored with the patch and that's exactly what it was intended to do, and without the need of an external textfile.

> You can just as well use a [textfile] without ever
>touching the "file" functionality of it: Just use it as a container
>for messages like you would use a message box. It's much easier to
>work with the textfile, because you can rewind it, get messages one by
>one etc. Attached is how this is done.

okay, that exactly like we can do with a message box
 but it's more simple with a textfile, true,
 but textfile needs an external file for keeping values.

> You could also try to remove
>duplicates by using the "setable-route" idiom to filter out keys
>that already exist, but that is a bit more tricky.

that's very tricky indeed,
 I think that a second textfile
 is needed for doing this stuff just as a temporary container


>Actually I'm currently using Georg's PDContainers a
>lot for storing and retrieving in-memory patterns and similar things.
>I have a feeling, that sometimes I'm just rebuilding [qlist] though,
>but h_multimap and h_list are just too tasty to ignore them for these
>purposes.

Hmm, pdcontainer looks interesting, I haven't tried it yet,
 but will give a try...

> A kind of "map" container is really something that is
>missing in core Pd IMO.

yeah!

> If it's relevant, but I don't see how it is.

 I wanted to say: "If it's relevant, I don't see how it is"
but I think you've understood what I said...

>> Anyone knows a trick for replacing zexy/drip, and ggee/concat with internal objects?

>[list] equals [concat]

[concat] is concatenating two strings and [list] just puts them together

for exemple [air( and [line( into concat would give "airline"
and into list it would give "air line"
unless it's possible to remove simply the space between the two strings
I don't see how [list] would replace [concat]??

> and [list]-abs is a collection of
>list-operations done with native objects in pd-0.39 and up. Zexy's
>drip is called list-drip.pd there. (The setable route from above is
>part of [list]-abs as well where it is called sroute.pd. In the
>attached patch I made it into a subpatch for simplicity.)

oh yes I never look enough into usefull list-abs!
thank again for these abs...
patco