Le 13/07/2010 02:34, Mathieu Bouchard a écrit :

On Tue, 13 Jul 2010, cyrille henry wrote:

...

yep. cyrille

is yours supposed to be working in pd-extended ?

nop.

even when adding "iemmatrix" directly to the library list,

it was working when iemmatrix was a lib. now that iemmatrix is split in diferents file, i haven't corrected this patch.

cyrille

mtx_./ ... couldn't create mtx_.* ... couldn't create mtx_.* -1 ... couldn't create mtx_.* 0 ... couldn't create mtx_+ ... couldn't create mtx_./ 1 ... couldn't create mtx_.^ 0.5 ... couldn't create

does it work with a more recent version ? how recent does it have to be ?

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

On 2010-07-14 18:49, Mathieu Bouchard wrote:

On Tue, 13 Jul 2010, cyrille henry wrote:

...

it was working when iemmatrix was a lib. now that iemmatrix is split in diferents file, i haven't corrected this patch.

I think that it's important to pick the vocabulary so that it doesn't sound like the patch is doing something wrong ("the patch has to be corrected") but instead, that the library is wrong ("the patch has to circumvent a hopefully temporary problem in the library")....

but what is the problem with the library? shouldn't it read "the patch has to circumvent a hopefully temporary problem in the loader"?

ghst IOhannes

On Jul 15, 2010, at 11:53 AM, Mathieu Bouchard wrote:

On Wed, 14 Jul 2010, IOhannes m zmoelnig wrote:

...

On 2010-07-14 18:49, Mathieu Bouchard wrote:

...

I think that it's important to pick the vocabulary so that it
doesn't sound like the patch is doing something wrong ("the patch has to be corrected") but instead, that the library is wrong ("the patch has
to circumvent a hopefully temporary problem in the library")....

but what is the problem with the library? shouldn't it read "the patch has to circumvent a hopefully temporary problem in the loader"?

Well, it may be "the patch has to circumvent a hopefully temporary
problem in the build system" or something like that.

Is there a mtx_0x2b.pd_linux in your version of pd-extended ?
There's none in mine. It's a few months old, but recent mails
indicate that even very recent versions of pd-extended don't have a
mtx_0x2b.pd_linux. Why would you blame that on the hexloader ?

mtx_0x2b.pd_linux is now included. Check the 'aliases' that Roman
added.

.hc

               ¡El pueblo unido jamás será vencido!

Sorry for my random rant, but it seems purely illogical to me, that for instance maxlib is loaded on default, which seems to have no maintainer anymore, is buggy in some respects and creates name clashes, while iemmatrix, a clean library, which has an active maintainer with a well-established reputation, and which even uses a prefix and thus is unlikely to cause any name clashes is _not_ loaded on default.

I picked some random examples, which I chose simply because I stumbled across them. And I am aware, that this is an old discussion. It happened to jump into my eyes just now, that's why I am bringing it up.

Is there a way the community can participate in those processes? Currently, those things seem to be based on 'gut-decisions' made by the benevolent dictator. Hans, if that is clearly not the case, please accept my apologies, but that's how things look to me.

Likely there are historical reasons for the current list of automatically loaded libraries. However, this list looks very random to me and I am not clear, what purpose or rule it is following. Personally, I'd prefer to not auto-load anything at all, which would also encourage a nice patching style with explicitly loading the required libraries. I'd be interested to hear what others think about the matter.

Hans, although my rants seem directed to you, let me say, that I very much appreciate the work you put in into Pd-extended. I hope you agree, that there might be better ways of composing a list of loaded libraries than you just picking some.

Cheers Roman

On Tue, 2010-07-13 at 10:44 +0200, Roman Haefeli wrote:

On Mon, 2010-07-12 at 20:34 -0400, Mathieu Bouchard wrote:

...

On Tue, 13 Jul 2010, cyrille henry wrote:

...

yep. cyrille

is yours supposed to be working in pd-extended ? even when adding "iemmatrix" directly to the library list,

mtx_./ ... couldn't create mtx_.* ... couldn't create mtx_.* -1 ... couldn't create mtx_.* 0 ... couldn't create mtx_+ ... couldn't create mtx_./ 1 ... couldn't create mtx_.^ 0.5 ... couldn't create

does it work with a more recent version ? how recent does it have to be ?

I added all missing aliases, so that using those names works directly also in Pd-extended's libdir format, without having to use any quirks as loading [mtx_add] before [mtx_+].

Unfortunately, Hans is not comfortable with auto-enabling hexloader, so in order to be able to use those aliases, you need an [import hexloader iemmatrix] in order to take advantage of those aliases.

Even I, who already discussed with Hans about the issue with en/disabling hexloader on default, first forgot to enable it manually, which made me think, that the aliases are not working. I still think, that _not_ enabling hexloader causes more confusion than simply loading it on default. I thought I delivered enough proof that it is not causing any harm.

So, using an rc4 autobuild and putting an [import hexloader iemmatrix] (iemmatrix is not loaded per default) should work.

Roma

---

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

On Tue, 2010-07-13 at 12:26 +0200, Frank Barknecht wrote:

Hi,

On Tue, Jul 13, 2010 at 11:48:18AM +0200, Roman Haefeli wrote:

...

Personally, I'd prefer to not auto-load anything at all, which would also encourage a nice patching style with explicitly loading the required libraries. I'd be interested to hear what others think about the matter.

I would love a proper way for Pd vanilla/core to load libraries into abstractions. I know of [import] but most of my abstraction libraries target vanilla installs, too, so I cannot use it. And [declare] currently is designed for top-level _main.pd-style patches only, so there's no way to really preload list-abs in RTC-lib-abstractions for example.

In what way is [declare] inferior to the commandline arguments -lib and -path?

Last time I checked, [declare] indeed was working inside abstractions.

Roman

On Tue, 2010-07-13 at 13:18 +0200, Frank Barknecht wrote:

Hi,

On Tue, Jul 13, 2010 at 12:43:08PM +0200, Roman Haefeli wrote:

...

Last time I checked, [declare] indeed was working inside abstractions.

Depends on what you call "working" ...

Quoting the help file:

WARNING: you might want to avoid putting "declare"
statements inside abstractions, as their effects will
extend to the calling patch. As of version 0.41, "declare
path" is ignored inside abstractions, although, probably
unwisely, "-stdpath" takes effect (on the calling patch as
well as the abstraction.)

Attached is an example showing where declare in abstractions fails: Open abstraction-help.pd, then click "abs/abstraction" to see an object not created, although it's in the [declare]ed path. Open abs/abstraction.pd directly then: now the object creates.

This is a nice example, which exposes clearly the culprits with [declare]'s current implemtentation. Thanks for sharing.

[declare] is definitely not ready for 'intra-project' usage. However, it still can be used as a replacement for the command line flags '-lib' and '-path' for system-wide installed libraries and that was the use case I initially was talking about. Instead of Pd-extended loading system-wide installed libraries per default, those also could be loaded with [declare -stdlib], respectively [declare -stdpath]. And those work also inside abstractions.

As you pointed out, [declare] still has issues. However, in the long run it'd be the preferred way to load dependencies dynamically from the patch instead of generally and automatically on start-up. Do we agree here?

Also see the source for abstraction-help.pd to spot the "#X declare"-pollution.

It was me who reported this bug back then. And it is still not fixed. http://sourceforge.net/tracker/?func=detail&aid=2251387&group_id=557...

On Jul 13, 2010, at 11:07 AM, Mathieu Bouchard wrote:

On Tue, 13 Jul 2010, Frank Barknecht wrote:

...

I would love a proper way for Pd vanilla/core to load libraries
into abstractions. I know of [import] but most of my abstraction
libraries target vanilla installs, too, so I cannot use it. And
[declare] currently is designed for top-level _main.pd-style
patches only, so there's no way to really preload list-abs in RTC- lib-abstractions for example.

For the record, I'd gladly give the copyright for the [import] code to
Miller if he wants to include it. As for libraries, I think one thing
that would be very helpful would be if the namespace prefixes worked
everywhere we want them too. The hard one is when you include libdirs
in your project, like this:

myproject/ myproject/list-abs/ myproject/rtc-lib/

Then you want the abstractions in myproject/rtc-lib to be able to find
list-abs/list-len in the folder myproject/list-abs. That currently
doesn't work.

.hc

                         kill your television

On Wed, 2010-07-14 at 08:31 +0200, Frank Barknecht wrote:

Hi,

On Tue, Jul 13, 2010 at 11:07:08AM -0400, Mathieu Bouchard wrote:

...

On Tue, 13 Jul 2010, Frank Barknecht wrote:

...

I would love a proper way for Pd vanilla/core to load libraries into abstractions. I know of [import] but most of my abstraction libraries target vanilla installs, too, so I cannot use it. And [declare] currently is designed for top-level _main.pd-style patches only, so there's no way to really preload list-abs in RTC-lib-abstractions for example.

It's not even working for top-level patches, because what you load for one top-level patch is also loaded for all subsequent patches until you restart pd.

If I interpret Miller's intentions for [declare] correctly, that's what it's designed to do. (I base my interpretation partly on his use of [declare] in the Pure Data Repertory Project PDRP.)

In my interpretation, [declare] is intended to be used in a single MAIN.pd and is the place to load all dependencies for all abstractions used inside that project ("dependencies" includes things like paths to resources like samples etc.). So if an abstraction you use complains about missing a [list-drip], add a [declare -(std)path list-abs] in MAIN.pd.

Your interpretation does not quite reflect, how [declare] currently behaves:

• [declare]ing a path in top level patchA.pd does not affect top level

patchB.pd. In that respect, [declare] _is_ canvas local.

• [declare]ing a path in abstraction [abs] which is instantiated in

patchA.pd does not affect patchA.pd. Also in this respect it is canvas local.

• A [declare] with a flag, that is supposed to be relative to the patch

('-lib' and '-path') expands always only relative to the path of the most top level patch (see your example). This actually renders those flags unusable within abstractions.

• [declare -stdlib] and [declare -stdpath] still can be used within

abstractions, since those flags are relative to the Pd path and thus independent from the most top level patch.

• [declare -lib] and [declare -stdlib] cannot load a class library or

single classes canvas local. But this is probably more related to the classloader of Pd than specific to [declare] (and is the same with [import]).

• [declare] still has bugs. When saving a patch after having

instantiated an abstraction containing a [declare], the patch is polluted with a hidden [declare]. This does not mean, that [declare] is not canvas local.

When used in this way as we do in all the RjDj scene archives[*] [declare] works very well. But [declare] does not help with canvas-local loading at all, probably because it's designed with different intentions. To declare is not to import.

This is also not true. The combo libdir and [import] behaves very similar to [declare -stdpath] in that it is canvas local in the same respects as described above and also in that it expands pathes relative to Pd. A difference is, that it requires a mylib-meta.pd patch. If you want, [declare] is an extended [import] with bugs under certain circumstances.

(It took me a while to realise all that ...)

After all, I don't see why one should restrict themselves in [declare] usages as you propose it, OTOH it's certainly safe.

Roman

morning all,

My technique (read: "hack") for auto-loading libraries in vanilla has been just to instantiate an object [foo] in order to load the library foo.pd_linux. This causes error messages for some libraries (notably xsample, which I use a lot), but works well with the vanilla loader. I guess we can't dictate that every library xyz.pd_linux register a class 'xyz', but that's the simplest way I've found of loading libs. Of course, you can't declare inter-library dependencies this way (that I know of), but it's a start...

marmosets, Bryan

On 2010-07-13 12:26:42, Frank Barknecht fbar@footils.org appears to have written:

Hi,

On Tue, Jul 13, 2010 at 11:48:18AM +0200, Roman Haefeli wrote:

...

Personally, I'd prefer to not auto-load anything at all, which would also encourage a nice patching style with explicitly loading the required libraries. I'd be interested to hear what others think about the matter.

I would love a proper way for Pd vanilla/core to load libraries into abstractions. I know of [import] but most of my abstraction libraries target vanilla installs, too, so I cannot use it. And [declare] currently is designed for top-level _main.pd-style patches only, so there's no way to really preload list-abs in RTC-lib-abstractions for example.

If this issue is solved, the problem of autoloading becomes almost moot. Well, there still are some issues like the sad omission of "sssad" in Pd-extended which is not shipped at all but such things are comparatively trivial to fix.

Ciao

thanks cyrille, to make your patch work I had to change [mtx_+] to [mtx_add] in interpol, and [mtx_-] to [mtx_sub] in interpol_mod.

(@mathieu, it works here on osx with the latest pd-extended with the above mentioned modification)

I see that the number of stored presets have to be defined upon creation of the object - do you think this is something that can be altered by input too?

cheers, martin

On Mon, Jul 12, 2010 at 11:56 PM, cyrille henry ch@chnry.net wrote:

yep. cyrille

Le 13/07/2010 00:23, Martin . a écrit :

...

hello list,

has anyone already come up with a 2d preset interpolation similar to Ali Momeni's concept (http://www.alimomeni.com/interpolation-spaces) or as made in max (http://tirl.org/software/colorblobs/) for pd?

cheers, martin

---

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