2018-04-13 17:03 GMT-03:00 José Rafael Subía Valdez <jsubiaval...@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
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.
Pdfirstname.lastname@example.org mailing list
UNSUBSCRIBE and account-management ->