kages
in their own right.
Katja
>
>
> From: katja <katjavet...@gmail.com>
> Sent: 21 January 2017 10:50
>
> To: Liam Goodacre
> Cc: PD list
> Subject: Re: [PD] repackaging externals on Deken
>
> Liam,
>
> Choosing a unique name for an ext
On Mon, Jan 23, 2017 at 1:04 PM, IOhannes m zmoelnig wrote:
> On 2017-01-21 11:50, katja wrote:
>> Not only a future release of a dependency has the potential to
>> break your patch. An old release with a bug or missing feature can do that
>> too! It seems there's no way to
On 2017-01-23 05:00, Liam Goodacre wrote:
> What would be involved in forking an external
I don't think there is any good fool-proof, one-click solution.
but i do think that forking the source code for the sake of distributing
is the worst solution.
i would probably:
- specify the requirements
On 2017-01-21 15:11, cyrille henry wrote:
>
> for patch that are located in the project_folder, you can load
> [unique_directory_name/counter].
> this way your can be sure that you will not load any "counter" that came
> with any other lib.
however, as a side-effectm aby [counter] object loaded
On 2017-01-21 11:50, katja wrote:
> Choosing a unique name for an external is indeed the best warranty to avoid
> conflicts.
the problem is of course to create those "unique" names.
"context_initbang" could easily nameclash.
UUID could be used, but has other drawbacks
this.
From: katja <katjavet...@gmail.com>
Sent: 21 January 2017 10:50
To: Liam Goodacre
Cc: PD list
Subject: Re: [PD] repackaging externals on Deken
Liam,
Choosing a unique name for an external is indeed the best warranty to avoid
conflicts. Not only a future release of a dependen
---
*From:* katja <katjavet...@gmail.com <mailto:katjavet...@gmail.com>>
*Sent:* 20 January 2017 15:29
*To:* Liam Goodacre
four versions: one for Windows, Linux Mac, and one without
> externals.
>
> Liam
>
> --------------
> *From:* katja <katjavet...@gmail.com>
> *Sent:* 20 January 2017 15:29
> *To:* Liam Goodacre
> *Cc:* PD list
> *Subject:* Re: [PD] repackaging externals o
On 21/01/17 02:30, IOhannes m zmölnig wrote:
in the meantime i was thinking about extended deken to display a README
Sounds cool. Or it could open "README.pd".
Cheers,
Chris.
--
http://mccormick.cx/
___
Pd-list@lists.iem.at mailing list
On 01/20/2017 03:50 AM, Chris McCormick wrote:
> The best solution to this is currently vapourware.
>
> It would work like Python's requirements.txt
right.
in the meantime i was thinking about extended deken to display a README
(if present) after unzipping the package.
this would at least allow
On 01/20/2017 05:22 PM, Liam Goodacre wrote:
> A quick and dirty solution to this might be to rename all the external files
> that are
> uploaded in the Context deken package (ie. "demux.pd_linux" -->
> "demux2.pd_linux").
> This would solve the problem as far as I can see, although it seems
9
To: Liam Goodacre
Cc: PD list
Subject: Re: [PD] repackaging externals on Deken
In the early days of Raspberry Pi I has a need to redistribute a few
externals with PicoJockey, an ARMv6 targeted version of SliceJockey,
because Pd-extended did not explicitly support the platform.
PicoJockey incl
In the early days of Raspberry Pi I has a need to redistribute a few
externals with PicoJockey, an ARMv6 targeted version of SliceJockey,
because Pd-extended did not explicitly support the platform.
PicoJockey includes a source tree with subsets of some external
libraries plus a custom build
Hi all,
I am looking for the same feature with our project Malinette
(http://malinette.info).
I could be very nice to make your own bundle of externals with a file
with the name of externals and a python script or php which will looking
for them with Deken (download, extract).
If someone
Hi all,
On 20/01/17 03:19, Fred Jan Kraan wrote:
I'm starting to think about how to distribute the Context sequencer when
it is ready (hopefully the day is not very far away). Context is an
abstraction, but it relies heavily on externals*. Ideally, I want it up
on Deken, but I'm not sure what
Hi Liam,
Hi all,
I'm starting to think about how to distribute the Context sequencer when
it is ready (hopefully the day is not very far away). Context is an
abstraction, but it relies heavily on externals*. Ideally, I want it up
on Deken, but I'm not sure what to do about the external
Hi all
I'm starting to think about how to distribute the Context sequencer when it is
ready (hopefully the day is not very far away). Context is an abstraction, but
it relies heavily on externals*. Ideally, I want it up on Deken, but I'm not
sure what to do about the external packages. Is it
17 matches
Mail list logo