[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