[PD] hexloader WAS: Pd-extended 0.42.5 release candidate 3 released!
reduzierer at yahoo.de
Fri Jun 18 22:59:33 CEST 2010
On Fri, 2010-06-18 at 13:01 -0400, Hans-Christoph Steiner wrote:
> On Jun 18, 2010, at 8:49 AM, Roman Haefeli wrote:
> > On Thu, 2010-06-17 at 16:56 -0400, Mathieu Bouchard wrote:
> >> On Wed, 16 Jun 2010, Hans-Christoph Steiner wrote:
> >>> On Jun 15, 2010, at 10:09 PM, Mathieu Bouchard wrote:
> >>>> On Tue, 15 Jun 2010, Hans-Christoph Steiner wrote:
> >>>>> You need to do [import hexloader] first, then those objects will
> >>>>> create.
> >>>> Why isn't hexloader enabled by default ?
> >>> It was causing a lot of problems. Check the archives for details.
> >> Actually, I can't get hexloader to work. It seems to have no effect.
> >> I can't instantiate [mtx_+] without first instantiating [mtx_add],
> >> which
> >> is the same class.
> >> There are pd-extended users who recompile zexy and iemmatrix as big
> >> libraries because the system of one-class-per-file of pd-extended
> >> doesn't
> >> work with those names and the filesystems. It's causing a lot of
> >> problems.
> > Yeah, there have been some troubles. In the case of iemmatrix: most of
> > the aliases were missing completely, so even with hexloader loaded,
> > Pd-extended wouldn't find the correct files. I created a patch that
> > adds
> > all missing aliases for iemmatrix and IOhannes committed it two days
> > ago
> > . I guess you would need to try a current autobuild to be able to
> > create [mtx_+] directly. The rc3 version was released before the patch
> > was applied.
> > Regarding zexy, I am not aware of any troubles in Pd-extended. Please
> > post bugs, if you find any. I guess we're not far away from the
> > libdirs
> > behaving similar to the original multi-object library format. I
> > personally care most about zexy and iemmatrix, I haven't checked if
> > other libraries also require aliases.
> >  https://sourceforge.net/tracker/?func=detail&aid=3017152&group_id=55736&atid=478072
> > @ Hans
> > You said you removed hexloader from automatically being loaded,
> > because
> > there have been some troubles in the past. The reason could be found
> > in
> > the list archives. I haven't thoroughly checked everything about
> > hexloader, but it seemed to me that most problems have been solved. If
> > not, can you elaborate a bit the issue?
> > Personally, I think it would help _a lot_ to make Pd patches portable
> > between flavours, if hexloader would be loaded automaticall on start-
> > up
> > of Pd-extended. Please let me know, if you think it is not worth
> > raising
> > this discussion again.
> > Roman
> I don't remember the reasons, I'd have to dig in the archives to
> remember :) hexloader has been IOhannes' project. I think in order
> for it to work, it should be simplified more. I think it should use a
> setup function called setup(), for example. Then it wouldn't need to
> do any 0x hex rewriting for the setup function.
I don't see how _not_ loading hexloader automatically on start-up can
help here. A supposedly too complex hexloader mechanism is still better
that none at all, even more since it is already implemented, no?
I personally would welcome if it _would_ be loaded automatically for
reasons I mentioned above.
I am probably the wrong person to comment on the technical aspects, but
it seems to me that your proposal of having only a setup() function
instead of the current classname_setup() function would render it
impossible to have a c file provide more than one class. Or am I
misunderstanding something here?
More information about the Pd-list