hi, was there ever anything like this? have 2 years old patch where i used [gain~] for gaining of the signal, has 3 inlets : 1 sound 2 (data) gain 3 (data) ??? ales
Ales Zemene wrote:
hi, was there ever anything like this? have 2 years old patch where i used
nope!
[gain~] for gaining of the signal, has 3 inlets : 1 sound 2 (data) gain
3 (data) ???
fade time
think about your very first pd-patch. remember ? like
[inlet~] [inlet] [inlet] | | | | [pack 0 50] | | | [line~] | | | +-----+ | | [*~] | [outlet~]
(the gain in this example is "linear"!)
if somebody has built this as an external, i will bump my head onto the desk the whole day (i guess, tim has done something like this, with SSE)
ales
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
if somebody has built this as an external, i will bump my head onto the desk the whole day (i guess, tim has done something like this, with SSE)
You will probably stop bumping if you ever have to work with a performance system using dozens of these combinations on a slow machine (and still want to do something else than just gaining) By the way... one of my useless externals libraries in development is an audio routing system with built-in fades and other useless goodies. But never mind, noone has to use it.
cheers to Tim! Thomas
Thomas Grill wrote:
You will probably stop bumping if you ever have to work with a performance system using dozens of these combinations on a slow machine (and still want to do something else than just gaining) By the way... one of my useless externals libraries in development is an audio routing system with built-in fades and other useless goodies. But never mind, noone has to use it.
oh i have forgotten to mention that zexy's [matrix~] and [multiline~] were written for exactly this purpose... (although not SIMD-optimized)
so i can start bumping again...
mfg.uzt.aa IOhannes
oh i have forgotten to mention that zexy's [matrix~] and [multiline~] were written for exactly this purpose... (although not SIMD-optimized)
and if i remember correctly they are not even loop unrolled / vectorized ... haven't checked the code, though ...
t
Tim Blechmann wrote:
oh i have forgotten to mention that zexy's [matrix~] and [multiline~] were written for exactly this purpose... (although not SIMD-optimized)
and if i remember correctly they are not even loop unrolled / vectorized ... haven't checked the code, though ...
neither is sickle version of matrix~, nor any other sickle clone. When I was experimenting back then with gcc-2.95, the consistent pattern was that -funroll-loops performed slightly better than unrolling by hand.
Wonder about similar measurements with -ftree-vectorize once it matures...
Krzysztof
neither is sickle version of matrix~, nor any other sickle clone. When I was experimenting back then with gcc-2.95, the consistent pattern was that -funroll-loops performed slightly better than unrolling by hand.
well, that's interesting ... there are three different factors for speeding up things:
- using SIMD instructions (single instruction multiple data)
- using aligned memory operations movaps / movups
- loop unrolling ... loop unrolling is necessary for simd instructions, since the parallel instructions can be used (although i've never seen a compiler producing the specific code)
cheers ... tim
if somebody has built this as an external, i will bump my head onto the desk the whole day (i guess, tim has done something like this, with SSE)
i did something like that with sse instructions, since it performs much better than the combination of pd objects. it includes different optimizations for
- ramp (vector * vector)
- constant factor (vector * scalar)
- factor 1 (vector * 1 = vector)
- factor 0 (vector * 0 = 0)
instead of bumping your head onto your desk, i'd prefer you think of a way, how to change pd that way that it optimized this patch structure to exactly the above behaviour ;-)
cheers ... tim
-
Ales Zemene -
IOhannes m zmoelnig -
Krzysztof Czaja -
Thomas Grill -
Tim Blechmann