[PD] sending OSC bundles. + help files?

[Roman Haefeli]

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