Olivier Heinry wrote:

You should use mrpeach's objects for bundles and OSC in a general mamner. They are in pd-extended as well as in subversion.

i just watched yet another pd newbie struggle and have lots of pain trying to do a very simple thing with pd.

on osx 0.40-3-extended, mrpeach is not in the default library loading setup

• you need to manually edit the library loading preferences to actually be

able to use the mrpeach objects. which is asking far too much of a newbie.

with anger, d

Hans-Christoph Steiner wrote:

Yes, the library stuff is a mess. I spent a good deal of time working on import/declare stuff for the 0.40.3-extended release, and for the next release, I plan on spending more time on it. To me, having a library format that is easy to use and install is the top priority right now.

What particularly was the problem? Did you try using import or declare?

i don't know - i haven't kept up with the development of the import/declare/library mechanism, i just use a copy of pd-vanilla with a custom .pdrc file pointing to an external directory of stuff.

to make it go we just added mrpeach to the startup lib preferences...

d

Hans-Christoph Steiner wrote:

On Sep 9, 2008, at 7:54 PM, Damian Stewart wrote:

...

Hans-Christoph Steiner wrote:

...

Yes, the library stuff is a mess. I spent a good deal of time
working on import/declare stuff for the 0.40.3-extended release,
and for the next release, I plan on spending more time on it. To
me, having a library format that is easy to use and install is the
top priority right now. What particularly was the problem? Did you try using import or
declare?

i don't know - i haven't kept up with the development of the import/ declare/library mechanism, i just use a copy of pd-vanilla with a
custom .pdrc file pointing to an external directory of stuff.

to make it go we just added mrpeach to the startup lib preferences...

The idea is to embed the library settings into the patch. In
Pd-0.40.3-extended, if you added this to the patch, it would work for
any Pd-0.40.3-extended install:

[import mrpeach]

Or could use Miller's declare, but I don't remember what the state of
the declare bugs were in 0.41.4. It would be something like:

[declare -lib mrpeach]

or maybe

[declare -stdpath extra/mrpeach]

.hc

Just to be clear, does this mean if I use [import] in a patch, it becomes incompatible with vanilla Pd? Or can [import] be um, imported into vanilla Pd?

Phil Stone www.pkstonemusic.com

Phil Stone skrev:

Phil Stone wrote:

...

Hans-Christoph Steiner wrote:

...

The idea is to embed the library settings into the patch. In
Pd-0.40.3-extended, if you added this to the patch, it would work for
any Pd-0.40.3-extended install:

[import mrpeach]

Or could use Miller's declare, but I don't remember what the state of
the declare bugs were in 0.41.4. It would be something like:

[declare -lib mrpeach]

or maybe

[declare -stdpath extra/mrpeach]

.hc

Just drop a patch, I'll be glad to test it.

...

...

Just to be clear, does this mean if I use [import] in a patch, it becomes incompatible with vanilla Pd? Or can [import] be um, imported into vanilla Pd?

I apologize for following-up my own post, but this is a fairly important point, and I think it needs clarification. I'm about to release an abstraction, and I used [import] to eliminate a few dozen [mrpeach/...] style invocations of Martin Peach's OSC objects. Up until now, my abstraction would work with vanilla Pd if a couple of externals/libs were included (mrpeach being one of them). Have I now completely blocked out any vanilla Pd users by using [import]?

Of course, I could use [declare], but I've seen some questions about [declare] bugs on this list.

Is my only choice to go back to the redundant (and rather ugly) [mrpeach/routeOSC] style, in order to be compatible with vanilla Pd?

Is it rude to ask why we are essentially forking a very useful object?
Is there any possibility of this being resolved into one, compatible object?

Phil Stone www.pkstonemusic.com

---

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

On Sep 12, 2008, at 2:45 PM, Frank Barknecht wrote:

Hallo, Phil Stone hat gesagt: // Phil Stone wrote:

...

I apologize for following-up my own post, but this is a fairly
important point, and I think it needs clarification. I'm about to release an abstraction, and I used [import] to eliminate a few dozen
[mrpeach/...] style invocations of Martin Peach's OSC objects. Up until now, my abstraction would work with vanilla Pd if a couple of externals/libs were included (mrpeach being one of them). Have I now completely blocked out any vanilla Pd users by using [import]?

AFAIK [import] is an external, for vanilla users it would just be an additional dependency to install.

Another problem, maybe bigger problem, is that using [import] like in pd-extended requires a certain directory layout. For example to make [import mrpeach] work in that it makes [routeOSC] availabe, pd-vanilla users not only need [import], they also have to put routeOSC.pd_linux|dll|... into a directory "mrpeach" in their path
(e.g. into "extra") to let [import mrpeach] actually load [routeOSC].

But the problem is not as big as I make it. E.g. vanilla users
could use an empty abstraction import.pd and keep Martin's objects in the Pd- path directly. They are available as [routeOSC],... directly then.
Having the empty import.pd will make Pd shut up when [import mrpeach] is used and you could use [routeOSC] without prefix just fine. You could not use [mrpeach/routeOSC] then, but you don't want to anyway. ;)

Or even easier, just copy the "mrpeach" folder in extra from a Pd- extended build into your Pd-vanilla install's extra folder. Done.
Then you can use namespace prefixes too, like [mrpeach/routeOSC].

.hc

Ciao

Frank Barknecht

---

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

Access to computers should be unlimited and total. - the hacker ethic

On Sep 12, 2008, at 4:40 PM, Phil Stone wrote:

Hans-Christoph Steiner wrote:

...

On Sep 12, 2008, at 2:45 PM, Frank Barknecht wrote:

...

Hallo, Phil Stone hat gesagt: // Phil Stone wrote:

...

I apologize for following-up my own post, but this is a fairly important point, and I think it needs clarification. I'm about to release an abstraction, and I used [import] to eliminate a few dozen [mrpeach/...] style invocations of Martin Peach's OSC objects. Up until now, my abstraction would work with vanilla Pd if a couple of externals/ libs were included (mrpeach being one of them). Have I now completely blocked out any vanilla Pd users by using [import]?

AFAIK [import] is an external, for vanilla users it would just be an additional dependency to install.

Another problem, maybe bigger problem, is that using [import]
like in pd-extended requires a certain directory layout. For example to make [import mrpeach] work in that it makes [routeOSC] availabe, pd- vanilla users not only need [import], they also have to put routeOSC.pd_linux|dll|... into a directory "mrpeach" in their path (e.g. into "extra") to let [import mrpeach] actually load [routeOSC].

But the problem is not as big as I make it. E.g. vanilla users could use an empty abstraction import.pd and keep Martin's objects in the Pd- path directly. They are available as [routeOSC],... directly then. Having the empty import.pd will make Pd shut up when [import mrpeach] is
used and you could use [routeOSC] without prefix just fine. You could not use [mrpeach/routeOSC] then, but you don't want to anyway. ;)

Or even easier, just copy the "mrpeach" folder in extra from a Pd- extended build into your Pd-vanilla install's extra folder. Done. Then you can use namespace prefixes too, like [mrpeach/routeOSC].

.hc

Yes, but the [import mrpeach] objects would throw errors, unless the pure-Pd end-user created empty [import] objects, as Frank pointed out. There doesn't seem to be a solution that is "one-size-fits-all."

I know that the namespace problem in general is still under construction, and I'm happy to have [import], but it would be nice if there weren't such an incompatibility with vanilla Pd. Is there any chance that [declare] could be the solution for both builds -- what obstacles are there to that?

If Miller accepts the patches to [declare], then it would work in
vanilla.

.hc

Phil

---

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

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, Phil Stone hat gesagt: // Phil Stone wrote:

...

I apologize for following-up my own post, but this is a fairly important point, and I think it needs clarification. I'm about to release an abstraction, and I used [import] to eliminate a few dozen [mrpeach/...] style invocations of Martin Peach's OSC objects. Up until now, my abstraction would work with vanilla Pd if a couple of externals/libs were included (mrpeach being one of them). Have I now completely blocked out any vanilla Pd users by using [import]?

AFAIK [import] is an external, for vanilla users it would just be an additional dependency to install.

Another problem, maybe bigger problem, is that using [import] like in pd-extended requires a certain directory layout. For example to make [import mrpeach] work in that it makes [routeOSC] availabe, pd-vanilla users not only need [import], they also have to put routeOSC.pd_linux|dll|... into a directory "mrpeach" in their path (e.g. into "extra") to let [import mrpeach] actually load [routeOSC].

But the problem is not as big as I make it. E.g. vanilla users could use an empty abstraction import.pd and keep Martin's objects in the Pd-path directly. They are available as [routeOSC],... directly then. Having the empty import.pd will make Pd shut up when [import mrpeach] is used and you could use [routeOSC] without prefix just fine. You could not use [mrpeach/routeOSC] then, but you don't want to anyway. ;)

Well, it's a little more complicated than one would wish, but at least it's possible, then. Thanks, Frank.

Phil

IOhannes m zmoelnig wrote:

well, yes and now. as said above, there is always the fallback thing. having [import mrpeach] without a "mrpeach" directory will (at the worst) give you a warning (or error?). nevertheless Pd will still find

just to re-stress this: an error does not always make your patch unusable! i have done plenty of patches that happily lived witherrors (while ugly, they were expected)

to remove the ugliness, it would be nice to have a (built in!) way to "try" instantiating an object. like [try { import mrpeach } catch {}]

(with the catch-clause defining an alternative object to be instantiated)

mgasdr IOhannes

Hans-Christoph Steiner wrote:

Interesting idea, ideally it would be done without adding new syntax.
Perhaps if you were able to test if an object can be instantiated, then you could use that info to dynamically patch things depending on the setup.

i have learned the hard way that dynamic patching is evil (at least in a context where i think that a "try" thing would have meaning)

apart from that it should be fairly simple to implement a query object that asks for the existance of a certain class.

fgmasdr IOhannes

On Sep 15, 2008, at 1:23 PM, IOhannes m zmoelnig wrote:

IOhannes m zmoelnig wrote:

...

apart from that it should be fairly simple to implement a query
object that asks for the existance of a certain class.

see iem/iemguts/src/classtest.c

fgmasdr IOhannes

I could see this being really useful for netpd, there could be a
system that checks to make sure that the local system has all of the
classes in a new patch, so that if someone uploads a random patch
with some custom classes, it wouldn't cause everyone else's netpd
sessions to choke up on error messages in the Pd window.

.hc

I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.

On Fri, 2008-09-12 at 10:34 -0700, Phil Stone wrote:

Phil Stone wrote:

...

Hans-Christoph Steiner wrote:

...

The idea is to embed the library settings into the patch. In
Pd-0.40.3-extended, if you added this to the patch, it would work for
any Pd-0.40.3-extended install:

[import mrpeach]

Or could use Miller's declare, but I don't remember what the state of
the declare bugs were in 0.41.4. It would be something like:

[declare -lib mrpeach]

or maybe

[declare -stdpath extra/mrpeach]

.hc

Just to be clear, does this mean if I use [import] in a patch, it becomes incompatible with vanilla Pd? Or can [import] be um, imported into vanilla Pd?

I apologize for following-up my own post, but this is a fairly important point, and I think it needs clarification. I'm about to release an abstraction, and I used [import] to eliminate a few dozen [mrpeach/...] style invocations of Martin Peach's OSC objects. Up until now, my abstraction would work with vanilla Pd if a couple of externals/libs were included (mrpeach being one of them). Have I now completely blocked out any vanilla Pd users by using [import]?

Of course, I could use [declare], but I've seen some questions about [declare] bugs on this list.

Is my only choice to go back to the redundant (and rather ugly) [mrpeach/routeOSC] style, in order to be compatible with vanilla Pd?

Is it rude to ask why we are essentially forking a very useful object?
Is there any possibility of this being resolved into one, compatible object?

currently, as far as _i_ can see it, there is no portable solution, while 'portable' implies, that the user doesn't have to change any configuration, nor to create a dummy [import] nor run into bugs of pd. [declare] WOULD be the solution, but it seems, that it is broken.

obviously another problem is, that the dev-section of the pd community doesn't seem to agree on how to deal with this issue. while the original author martin peach suggests to install everything of mrpeach directly into the extra folder, in pd-extended everything is installed in subfolders. as a user of pd-vanilla willing to install mrpeach, no matter which way you follow, your patches are _not_ portable because of this. they are not working out-of-the-box on some installations or/and they trigger errors. for a patch creator there is currently no other way than providing a readme to tell how the externals are needed along with the patch. while not everyone seems to agree with the layout used by pd-extended, this layout is at least consistent across all pd-extended installation (or is at least going to be consistent), while for pd-vanilla there doesn't seem to be any agreement on how to install externals (in what format and where). i don't even think, that it is necessary, that every library needs to be installed the same way, but it would already help a lot, if a patch creator could assume the same library to be installed the same way on every pd(-vanilla) installation.

probably this seems noobish and naïve, since there have been many attempts to launch a discussion about those issues with only little output, but on the long run i would like to suggest to go back a bit and start the discussion from scratch, while keeping the results and outcomes and remaining issues on a centralized place (wikipage?) instead of letting it die on the list (again). probably the first thing that needs to be done would be defining a roadmap, that most of the people would agree on. also do i think, that it would be a good thing to keep track of the current issues that are around with the pd-vanilla ('not'-)way and the pd-extended way. not till then it will make sense out sketch out specifications on a meaningful namespace system, the way how [declare] could work well for many possible cases et.al. surely, a lot of brainwork has already been invested into figuring out those issues, but it is not document anywhere (or at least not at some central place and i don't consider the list to be a good place to gather info from). before any (new) implementation, the specification need to be developped. this not only would help to work on the same end, it would also enable any pd-user not knowing how to code c (me for example) to participate in the process and probably to do some of the not-so-fancy-but-necessary work, such as writing docs and maintaining the page, while the skillful people could concentrate on writing the code.

of course, this implies, that a minimum number of people agrees on the fact, that there are some things worth to improved. don't let us rush, but go on steadily.

roman

Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de