monohusche

I am starting to realize that adding features to max patches comes at a cost, and I am going to tackle the (frightening) poly issue.

At the moment, within my looper app, there are are 8 channel instances which deal with buffer management, playback and user interaction independently. All are driven by a central common phasor.

I assume that playhead calculation using multiple rates and final playback causes a lot of cycles, so I was planning to put that into a common poly-based playback object.

At the moment, there are two related questions:

1. Will using poly make any difference to cpu usage assuming that all channels are playing ? My understanding of poly was that it allows to allocate unused resources, the question is whether there is any benefit if all components are used.

But maybe, I haven't understood the whole multithreading aspect fully yet, I just would like to avoid ripping out the whole signal stuff replacing wave~ with groove to save cpu.

2. If the inputs to my poly playback objects originate from the channel bpatchers, is there any other way to make them communicate than with using send/receive's.

Last but not least, it would be sweet if there were some expert hints which objects are to be avoided to save cycles (such as snapshots etc.)

poly-design-question

monohusche wrote on Thu, 19 March 2009 13:21

I assume that playhead calculation using multiple rates and final playback causes a lot of cycles

Don't assume too much when it comes to cpu usage. Design is more important than cpu usage optimization.

, so I was planning to put that into a common poly-based playback object.

Great, poly~ is one of the most powerful features in Max.

1. Will using poly make any difference to cpu usage assuming that all channels are playing ?

No, no difference if you work with a single core processor.

Yes, improvements with multicore: the DSP inside voices may be distributed over several cores.

Rule of thumb with poly~: always, always use inlets and outlets to enter signal in, or take signal out of a poly~.

Spending more time on design, less on saving cycles. And you're right, beware snapshot~!

monohusche wrote on Thu, 19 March 2009 13:21
I assume that playhead calculation using multiple rates and final playback causes a lot of cycles

Don't assume too much when it comes to cpu usage. Design is more important than cpu usage optimization.monohusche wrote on Thu, 19 March 2009 13:21
, so I was planning to put that into a common poly-based playback object.

Great, poly~ is one of the most powerful features in Max.monohusche wrote on Thu, 19 March 2009 13:21
1. Will using poly make any difference to cpu usage assuming that all channels are playing ? 

No, no difference if you work with a single core processor.
Yes, improvements with multicore: the DSP inside voices may be distributed over several cores.monohusche wrote on Thu, 19 March 2009 13:21
2. If the inputs to my poly playback objects originate from the channel bpatchers, is there any other way to make them communicate than with using send/receive's.

Rule of thumb with poly~: always, always use inlets and outlets to enter signal in, or take signal out of a poly~.monohusche wrote on Thu, 19 March 2009 13:21
Last but not least, it would be sweet if there were some expert hints which objects are to be avoided to save cycles (such as snapshots etc.)

Spending more time on design, less on saving cycles. And you're right, beware snapshot~!
Jean-François.


poly design question