[PD] enhance pd-extended with pd-l2ork featues ?

Hans-Christoph Steiner hans at at.or.at
Tue Jan 22 16:37:21 CET 2013


On 01/22/2013 10:30 AM, Ivica Ico Bukvic wrote:
>> Ah yes, right, you have to build everything for pd-l2ork because of binary
>> incompatibility.  That's unfortunate, since it means you have to do all
> the
>> same maintenance/packaging work instead of building upon what's there.
> 
> Well, it's not that much of work at all. The automated pd-l2ork build script
> already takes care of all that. True, there are still some externals that I
> did not include in the auto-build process but that should be a lot easier
> now that the core appears to be stable. Besides, my opinion is that shedding
> binary compatibility under these circumstances is really a non-issue when
> compared to benefits it yields, particularly considering that almost every
> new version of all three pd variants ships with newly recompiled externals
> and as such the process is entirely transparent to the user. Of course, if
> pd-extended adopted the pd-l2ork widgetbehavior, things could become a lot
> easier for all involved ;-)

>> Packages like pd-readanysf, pd-iemambi, and coming soon pd-fftease and
>> pd-lyonpotpourri, are all built to be shared across different pd versions.
> You
>> can still use the packages puredata-utils (pdsend and pdreceive) and
> cyclist
>> with pd-l2ork.
> 
> Pd-l2ork indeed has its own folder (including pd-l2ork-externals in home
> folder and settings file). The conflict is in the /usr/bin/ folder with
> binaries that share the same name but not necessarily code-base (I think
> pdsend/pdreceive and something else, IIRC--cannot remember off top my head).

config-switcher.sh.  Does anyone actually use it?  I stopped years ago, and I
wrote that script.  I plan on removing it from Pd-extended as well.  I should
have already...


>> Unless pd-l2ork is looking in /usr/lib/puredata, then it will not use any
> of
>> the objects included in the puredata* packages.  The pd-* packages install
>> into /usr/lib/pd, and Pd-extended installs into /usr/lib/pd-extended.  If
>> pd-l2ork does not install into /usr/lib/pd or /usr/lib/pd-extended, then
> it
>> can coexist fine.  Just make sure that /usr/lib/pd and
> /usr/lib/pd-extended
>> are not in pd-l2ork's search path and it won't load those libraries.
> 
> Indeed, that is not the problem. The problem lies (potentially) in
> user-settings file that may mess things up even though pd-l2ork uses
> different file name.

If pd-l2ork uses a different name for the settings file, like Pd-extended
does, then there will be no conflict there.  pure-data uses ~/.pdsettings,
Pd-extended uses ~/.pdextended, so pd-l2ork could use ~/.pd-l2ork and there
will be no conflict.

.hc



> 
> Best wishes,
> 
> Ico
> 
>>
>> .hc
>>
>> On 01/22/2013 08:57 AM, Ivica Bukvic wrote:
>>> Because:
>>>
>>> 1. the two are not binary compatible, so any stray packages may crash
> one
>>> or the other if they are in the shared directory
>>>
>>> 2. pd-l2ork comes as a monolithic distribution
>>>
>>> 3. Pd-utils is enough to break the one or the other due to different
> ways
>>> how gui functions between the two.
>>>
>>> If you can think of a better way please do let me know.
>>>
>>> That said, the two can nicely coexist if you install one of them using
> the
>>> binary installer script because that one exists in the usr/usr/local
>>> directory as opposed to/usr. Pd-l2ork already provides binary installers
>>> and automated tarball builders.
>>>
>>> P.S. I tried building pd-extended but had no luck using the same "make
>>> install path=/usr/local" (as per readme in packages/linux). I will try
> to
>>> resync latest svn. Perhaps something has changed.
>>> On Jan 21, 2013 11:58 PM, "Hans-Christoph Steiner" <hans at at.or.at>
>> wrote:
>>>
>>>> On 01/21/2013 11:22 PM, Ivica Ico Bukvic wrote:
>>>>>> Interesting, I'll have a go at it.
>>>>>>
>>>>>> I think I said I'd pay you if you were able to fix this.  Or maybe
> that
>>>>> was
>>>>>> matju.  Either
>>>>>> way if it's fixed I'll pay you for it.
>>>>>>
>>>>>> To be honest, I have no earthly idea why I care so much about this
>>>>>> feature.  Perhaps
>>>>>> it's from going through the hamster-wheel of externals all written
> just
>>>> to
>>>>> get
>>>>>> the args
>>>>>> list when this is all that is needed to solve all but the exotic
> cases.
>>>>>>
>>>>>> -Jonathan
>>>>>
>>>>> You can also try the binary builds I just posted (20130121 version)
> that
>>>> has
>>>>> all of the aforesaid fixes (assuming you use Ubuntu).
>>>>>
>>>>> Cheers!
>>>>>
>>>>
>>>> Hey ico,
>>>>
>>>> I'm curious why you made the pd-l2ork package conflict with all of the
>>>> puredata packages.  As far as I can tell, it only conflicts with
>>>> puredata-utils.  It would be very handy if pd-l2ork could live in
> parallel
>>>> with pd and pd-extended.
>>>>
>>>> And in terms of lowering your maintenance load, you could remove lots
> of
>>>> libraries from pd-l2ork and instead set them in Depend: and have them
>>>> provided
>>>> by the official packages that are already in Debian and Ubuntu.  You
> can
>>>> see a
>>>> listing of what's included in Debian here: look for all the packages
> that
>>>> start with pd-
>>>>
>>>>
>>>> http://qa.debian.org/developer.php?login=pkg-multimedia-
>> maintainers at lists.alioth.debian.org
>>>>
>>>> .hc
>>>>
>>>
> 



More information about the Pd-list mailing list