ComfortableInClouds

Hi - I was wondering why it is that a program like Ableton can have dozens, if not hundreds, of objects being affected by transposition at the same time and not get bogged down in terms of CPU uage, while a relatively small number of simple transposers (ie, based off of gizmo~'s help file) in MaxMSP can really weigh the computer down? What calls for this great disparity in CPU consumption? Is it the same way with all MSP objects in Max - that they'll always be using more CPU than other programs working on a higher level of abstraction?

This isn't so much a complaint as a matter of curiosity.

why-the-diff-in-cpu-hit-btwn-max-and-other-programs

"simple transposers (ie, based off of gizmo~'s help file)"

In fact, FFT processings like gizmo~ are not simple at all, they are really expensive in term of CPU.

"simple transposers (ie, based off of gizmo~'s help file)"
In fact, FFT processings like gizmo~ are not simple at all, they are really expensive in term of CPU.


then what kind of transposition is ableton using that is so much less computationally expensive than spectral transposition?

On 26 oct. 08, at 22:16, Bertrand Fraysse wrote:

> "simple transposers (ie, based off of gizmo~'s help file)"

> In fact, FFT processings like gizmo~ are not simple at all, they are 

In example/effects/transposer-folder there's a patch called transposer 

which make a transposition using delay lines. It costs less CPU, but 

the sound result my not be as good as with gizmo~ depending on the 

kind of sound that you want to transpose.

> "simple transposers (ie, based off of gizmo~'s help file)"
> In fact, FFT processings like gizmo~ are not simple at all, they are  
> really expensive in term of CPU.

In example/effects/transposer-folder there's a patch called transposer  
which make a transposition using delay lines. It costs less CPU, but  
the sound result my not be as good as with gizmo~ depending on the  
kind of sound that you want to transpose.

Granular, in various flavours. More importantly, it's not really 

real-time, so the comparison is a bit off. The transposition in Live is 

not like an effect that you can run stuff through.

> then what kind of transposition is ableton using that is so much less computationally expensive than spectral transposition?

Granular, in various flavours. More importantly, it's not really 
real-time, so the comparison is a bit off. The transposition in Live is 
not like an effect that you can run stuff through.

Kyle Kaplan skrev:
> then what kind of transposition is ableton using that is so much less computationally expensive than spectral transposition?
> --
> -k.
>
>


I'll check out the transposing delay lines! Sounds quite awesome.

Wterberg - what do you mean by Ableton's transposer not being real-time? You can link it up to a midi controller and transpose in real time. How is that not real-time?

What I meant was that it's applied to a *buffered* file, that the 

systems has prior knowledge of, so to speak. You can't apply the 

pitchshift as you're recording, for instance - hence the not real-time. 

It can be altered in real-time in a sense, but ONLY when the audio is 

In that sense you can compare it to some of the (many) granular patches 

for maxMSP buffer~, which can access any part of the file if need be. 

For gizmo to do that it would need a flux capacitor and a Deleurean ;)

> I'll check out the transposing delay lines! Sounds quite awesome.

> Wterberg - what do you mean by Ableton's transposer not being real-time? You can link it up to a midi controller and transpose in real time. How is that not real-time?

What I meant was that it's applied to a *buffered* file, that the 
systems has prior knowledge of, so to speak. You can't apply the 
pitchshift as you're recording, for instance - hence the not real-time. 
It can be altered in real-time in a sense, but ONLY when the audio is 
already in place.

In that sense you can compare it to some of the (many) granular patches 
for maxMSP buffer~, which can access any part of the file if need be. 
For gizmo to do that it would need a flux capacitor and a Deleurean ;)

Kyle Kaplan skrev:
> I'll check out the transposing delay lines! Sounds quite awesome.
>
> Wterberg - what do you mean by Ableton's transposer not being real-time? You can link it up to a midi controller and transpose in real time. How is that not real-time?
> --
> -k.
>


Quote: Wetterberg wrote on Sun, 26 October 2008 17:59

----------------------------------------------------

> For gizmo to do that it would need a flux capacitor and a Deleurean ;)

i see what you mean about the buffers/granular transposition. that makes sense. ill go take a look at some of the max examples granular patches.

Quote: Wetterberg wrote on Sun, 26 October 2008 17:59
----------------------------------------------------

> For gizmo to do that it would need a flux capacitor and a Deleurean ;)
>
> Andreas
>

i see what you mean about the buffers/granular transposition. that makes sense. ill go take a look at some of the max examples granular patches.


If the the FFT's in max was vectorized, you would be able to do the same spectral transposition at a fraction of the CPU.

Most OSX audio software use vectorized FFT, and thus will use maybe between 4X and 16X less CPU for the same FFT task.

Maybe cycling people are too busy and not ready to optimize the objects. So maybe someone in the users will code such vectorized FFT object from the SDK and apple framework ?

If the the FFT's in max was vectorized, you would be able to do the same spectral transposition at a fraction of the CPU.
Most OSX audio software use vectorized FFT, and thus will use maybe between 4X and 16X less CPU for the same FFT task.

What do you mean by vectorized, Salvator? Perhaps make a new thread asking C74 why the FFT objects aren't vectorized; perhaps this is something they haven't thought of?

This is common feature of modern processor that allow to process data by vector (kind of packet), rather than one item by one.

Google is your friend ! try "velocity engine" or SSE.

C74 is aware that vectorization is possible, since some objects were already vectorized for the powerPC mac... (like *~ ) But not for the intel mac to my knowledge. Maybe a matter of time...

Have you heard about altivec or SSE ?
This is common feature of modern processor that allow to process data by vector (kind of packet), rather than one item by one.

Why The Diff. In CPU Hit Btwn Max and Other Programs?