[PD-dev] pd-core lib + SIMD

Hans-Christoph Steiner hans at eds.org
Fri Jan 20 17:32:26 CET 2006


On Jan 20, 2006, at 4:26 AM, geiger wrote:

>
> On Thu, 19 Jan 2006, Mathieu Bouchard wrote:
>> 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.
>
> There is probably not that much that you can actually reuse. For a  
> start,
> I think externalizing the ~ objects makes most sense. These are also  
> the
> objects that will benefit from SIMD, the message based objects won't  
> run
> any faster because their performance is bottlenecked by scheduling and
> other factors that can't take advantage of SIMD.
>
> Instead of  the typedef, what I did was to redefine t_sample.
> Unfortunately the usage of t_sample as the base DSP type is not fully
> consistent in Pd, which means you have to change several occurences of
> t_float or float directly to t_sample in the dsp _perform routines.
>
> It would be nice to have them consistent, because we could
> redefine t_sample to "double" and compile a high-end version of
> Pd. I admit that I doubt that it would really improve sound quality,
> but its a good point for selling.

Please submit patches to the tracker to do this!  It sounds like it  
makes a lot of sense, and Miller has been accepting most patches  
submitted these days.

> Like, you know, Pd sounds better because it runs with 64 bit numbers.

Actually, 64-bit floats would be nice for things like timestamps.  The  
current floats aren't big enough.

.hc

>
> Guenter
>
>>
>> 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.
>>
>>  _ _ __ ___ _____ ________ _____________ _____________________ ...
>> | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
>> | Freelance Digital Arts Engineer, Montréal QC Canada
>>
>> _______________________________________________
>> PD-dev mailing list
>> PD-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>>
>>

________________________________________________________________________ 
____

                     There is no way to peace, peace is the way.
						        				-A.J. Muste





More information about the Pd-dev mailing list