On Sep 15, 2009, at 8:24 AM, ydego...@gmail.com wrote:
Hans-Christoph Steiner wrote:
On Sep 14, 2009, at 8:09 AM, ydego...@gmail.com wrote:
ola,
precisely, there are _too_ many discussions on this topic,
and i don't know the actual state of it...
subsidiary question :
do i neeed pd-exten
Hans-Christoph Steiner wrote:
On Sep 14, 2009, at 8:09 AM, ydego...@gmail.com wrote:
ola,
precisely, there are _too_ many discussions on this topic,
and i don't know the actual state of it...
subsidiary question :
do i neeed pd-extended ( from which version on ? )
to use namespaces and insp
On Sep 14, 2009, at 8:09 AM, ydego...@gmail.com wrote:
ola,
precisely, there are _too_ many discussions on this topic,
and i don't know the actual state of it...
subsidiary question :
do i neeed pd-extended ( from which version on ? )
to use namespaces and inspect the mapping library ?
Pro
ola,
precisely, there are _too_ many discussions on this topic,
and i don't know the actual state of it...
subsidiary question :
do i neeed pd-extended ( from which version on ? )
to use namespaces and inspect the mapping library ?
will pd-extended crush my dev version living in /usr/local/pd
On Sat, 12 Sep 2009, Ivica Ico Bukvic wrote:
Second that. I would love to hear more about the hexloader. Is this a part
of the regular distribution or only pd-extended? Also, why is zexy not built
as a lib rather than being a collection of files? Does it have lower memory
footprint this way?
i
There is lots of discussion in the archives on these topics. Here's a
summary:
- building as one-class-per-file gives us some namespace functionality
to deal with nameclashes
- pd-extended aims to use a single format for all libraries
- the nightly build of Pd-vanilla + externals uses v
very good subject .
in fact, i would add : and what are the differences between
a pd vanilla + externals and pd-extended ?
it's not listed ni trced anywhere?
and which libs became objects,
or objects became libs?
Ivica Ico Bukvic wrote:
Yup, we are aware. Originally that stuff was handled by
> > Yup, we are aware. Originally that stuff was handled by the hexloader
> for
> > special characters, which had serious bugs.
>
> I probably missed something important. What happened to the
> hexloader?
Second that. I would love to hear more about the hexloader. Is this a part
of the regular d
On Sat, 12 Sep 2009, Hans-Christoph Steiner wrote:
Yup, we are aware. Originally that stuff was handled by the hexloader for
special characters, which had serious bugs.
I probably missed something important. What happened to the hexloader?
_ _ __ ___ _ _ __
Yup, we are aware. Originally that stuff was handled by the hexloader
for special characters, which had serious bugs. I think there are
some workarounds on the list, there was a fair amount of discussion
and bug reports. I never use those so I don't know much about it.
.hc
On Sep 11,
It appears when compiling zexy from pd-extended svn source (0.41.4) the
resulting zexy.pd_linux fixes problems that are apparent when zexy is
compiled into separate objects (as is the case in /usr/lib/pd/extra/zexy/
folder that is a part of the pd-extended linux package).
Ico
__
In addition, it appears there are other objects that are messed up:
0x2e (scalar multiplication)
Reports: load_object: Symbol "0x2e_setup" not found
(fails to load)
0x260x260x7e (&&~)
This one loads but still reports: load_object: Symbol
"0x260x260x7e_setup" not found
The
Hans (and others),
Not sure if you were aware of this but it appears that in 0.41.4 zexy's
>~
<~
||~
are all messed up. Namely, their names have been replaced by hex values of
the ascii characters:
0x3c0x7efor <~
0x3e0x7efor >~
0x7c0x7c0x7efor ||~
Any ideas on h
13 matches
Mail list logo
