2018-04-13 17:03 GMT-03:00 José Rafael Subía Valdez <jsubiavaldez@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