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