[PD-dev] pd-core lib + SIMD
Hans-Christoph Steiner
hans at eds.org
Fri Jan 20 07:01:57 CET 2006
On Jan 19, 2006, at 4:59 PM, Mathieu Bouchard wrote:
> On Thu, 19 Jan 2006, Thomas Grill wrote:
>> Am 18.01.2006 um 20:56 schrieb Hans-Christoph Steiner:
>>> Thomas posted an idea a while back about making all of the core Pd
>>> objects
>>> into a library and having Pd itself just be the very core. I am
>>> thinking of
>>> doing this for the next Pd-extended, and this got me thinking. It
>>> would be
>>> great to have a SIMD version of the Pd-core lib as well. This would
>>> be
>>> easier to deploy and maintain since it could be in /externals/
>>> rather than
>>> part of Pd.
>> what i forgot to mention about the separation of core and internals is
>> that it requires a bit more code restructuring than just linking the
>> object files into two separate binaries. I remember some DSP functions
>> to be associated with internals - this code must be moved over to the
>> core part. But this should be done anyhow.
>
> I expect some object classes to not be really separable from the core,
> and
> I don't necessarily mean DSP: think of [inlet], [outlet], [pd]...
>
> However, I expect 80% or 90% of the internal classes to be
> externalizable.
> Let's do it for those classes first. Reuse the work of PDa if it makes
> sense.
>
> BTW, about PDa, it would make sense to make the Pd source
> C++-compatible,
> because if we can include C++ code in Pd, it's possible to introduce a
> fixed-point type that could be typedef'd as t_float, so that for almost
> all classes there would be no need to explicitly add integer code. (I
> haven't looked at PDa so I don't know whether it already does that...)
>
> I had made some C++-related fixes but I think that they were part of
> the
> same batch of removal of unused variables and those changes have been
> reverted.
>
> Maybe this ought to be a topic in the pd-dev meeting.
Obviously some objects would always remain in the Pd "kernel", like C
has void, while, if, else, static, sizeof, typedef, etc.
Perhaps a better route would be to make the pd-core lib. But then make
new libs with those objects and use SIMD in them. For example a "math"
lib would make a lot of sense, I don't know if there should be "math~"
as well, or whether everything should just be in "math", but that's the
general idea. "timing" is another idea. "core" could be objects like
[trigger], [select], [route], [symbol], [float], [print], etc. "gui"
could be another lib.
.hc
________________________________________________________________________
____
"Looking at things from a more basic level, you can come up with a more
direct solution... It may sound small in theory, but it in practice, it
can change entire economies."
- Amy Smith
More information about the Pd-dev
mailing list