[PD] How to declare custom libraries in abstractions

Alexandre Torres Porres porres at gmail.com
Sat Apr 14 03:16:32 CEST 2018


Sure, I guess I didn't expressed well myself. By being either "one or
another", I meant that you'd only need to either add it to the path or load
it as a library.

If a library like GEM has abstractions, you need to both add it to the
paths AND as a a library.

As it is, it wouldn't make sense to compile all code in cyclone as a single
binary, for the sake of making things simpler, as you'd still need to
install in the same way, by including it in the path and as a library.

2018-04-13 22:06 GMT-03:00 Christof Ressi <christof.ressi at gmx.at>:

> >  For now, the only way for cyclone to pick a format would be to compile
> it as a single library
> > (which implies turning the current abstractions into compiled code)
>
> all the popular single binary libraries I know (GEM, iemlib and zexy) also
> include abstractions.
>
>
> Gesendet: Samstag, 14. April 2018 um 02:17 Uhr
> Von: "Alexandre Torres Porres" <porres at gmail.com>
> An: "José Rafael Subía Valdez" <jsubiavaldez at gmail.com>
> Cc: "PD list" <pd-list at lists.iem.at>
> Betreff: Re: [PD] How to declare custom libraries in abstractions
>
>
>
> 2018-04-13 17:03 GMT-03:00 José Rafael Subía Valdez <
> jsubiavaldez at gmail.com[mailto:jsubiavaldez at gmail.com]>:
> Hello list,
>
> I have a couple of questions or more like "views" on this too.
>
> 1. the problem with using [library/object] method (when libraries compiled
> as one single file) is that you must always include the complete external
> library and this, as Liam said, may cause a 2 mb project to extend to 35mb,
> to give an example.
>
> well, when externals are compiled as one single binary pack (a.k.a.
> "library"), you cannot load it as "[library/object]", so I don't understand
> this point.
>
>
> 2. I am more worried if some libraries are going to change or not to a
> single compiled file, in this case, the [library/object] I think becomes
> obsolete as the library must be loaded independently. making patches that
> were using an old version of the library to cause "couldn't create" error.
>
> hmm, I guess the common practice nowadays is to offer separate binaries,
> and I can't see much motivation for someone who distributes them separately
> to change the deal and pack them up together.
>
>
> so if let's say "cyclone" decides to compile it into one file, I am not
> sure if objects created with [library/object] in a patch will
> successfully create.
>
> Ok, Cyclone seems to be a unique case. Originally, it was a "library", you
> could load the "hammer" library (only control/MAX objects), the "sickle"
> library (only signal/MSP objects) or "cyclone" (which loaded both
> hammer/sickle plus a set of objects with non alphanumeric names - such as
> +=~). In Pd Extended, cyclone got split into separate binaries, although it
> still carried the hammer/sickle/cyclone library binaries. In this process,
> the non alphanumeric names got a bit "lost to oblivion", as you could load
> them if you loaded the "cyclone" library.
>
> Well, currently, Cyclone keeps the separate binaries but still needs a
> "sub library" to load this subset of externals, as it's the only way to
> safely load non alphanumeric object names in vanilla. In fact, as it is
> now, it has this sub-library, a majority of compiled single binary objects
> and also a few abstractions. And abstractions, on the other hand, cannot be
> loaded as a "library". Hence, as of now, cyclone cannot be either just a
> set of separate binaries or a single binary pack.
>
> I don't know if there are other hybrid cases like this in the Pd world.
> And in my opinion, it would be easier and desirable if a library wasn't
> hybrid, just either a binary pack or a set of objects. Unless we have a way
> in the future to safely load non alphanumeric objects in Pd vanilla (I
> would personally love this as it would "fix" everything). For now, the only
> way for cyclone to pick a format would be to compile it as a single library
> (which implies turning the current abstractions into compiled code). But I
> don't think there are big chances for this to happen.
>
> cheers
>  _______________________________________________ Pd-list at lists.iem.at
> mailing list UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list[https://
> lists.puredata.info/listinfo/pd-list]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180413/5962ab5f/attachment-0001.html>


More information about the Pd-list mailing list