jayrope

two months ago i bought elastic~, finally got to proper testing today.

here's a test case using an altered copy from elastic~'s help file as a "real-time" harmonizer (in short: not suitable here!)

- i tested on ibook g4 1.2 MHz/ 10.4.11/ max 4.63

- my basic setting was setting speed and pitch of elastic~ to 1 (i.e. original). That way i could mix the processed signal with a phase-inverted copy of the original signal to target latency by ear and eventually find out about the artefacts in sound elastic~ generates when processing audio.

- initial CPU load, when elastic switched on 17%++.

- Latency: no less then approx. 92 ms, when comparing elastic's output signal with the original signal, while working with an i/o size of 512 and a vector size of 64 and using a delay~ with adjustable milliseconds on the original signal (*~ -1). 

- More notes: Latency is generally unstable/unpredictable. Entering edit mode in your patch alone changes the latency, too. Using the same buffer size again also does not consistently produce the same latency with elastic. A very small buffer size under 50 ms might produce artefacts in one case but not in another. There's many possible causes for this, nevertheless i didn't experience such unpredictability with buffer and groove, or with delay lines of any sort.

- Buffer size as well: The lowest i could use was 36 (ms) without elastic starting to produce nasty artefacts. 

this while have set the delay of elastics playhead to 0.01 ms. This setting was again not reliable. Somewhere above 55 ms artefacts seem to dissappear for good, nevertheless this already produces a latency of more than 110 ms, unstable values here as well, although the buffer size was the same.

- when changing the buffer size on the fly max likes to crash oftenly.

- Signal quality: having set elastic~ to original pitch and speed still processes the signal extremely. 

Following what ableton's developers already did in version 3 or so i would recommend for the elastic developers to establish an option to deliberately turn off processing when original speed and pitch are set, as this would improve audio quality massively on that setting. In ableton the "warp engine" can be turned off for that purpose.

- Comparing with outboard gear: Elastic~ vs. PCM 80 pitch card didn't go too well for elastic. The PCM 80 allows for setting a root pitch f. i., which has an influence on the window size of the pitch algorhythm. that way the pitch quality can be adjusted to the nature of the audio signal coming in. Very bassy signal need a larger window size, whereas other signals don't. The latency of the PCM 80 never exceeds 40 ms, while sounding much more natural than elastic and allowing for much bigger pitch range (+/- 3 octaves). 40 ms. by teh way already hurt much, when having to play live with such a thing...

as i paid for this external i would NOT recommend buying elastic~ for the purpose of real-time harmonizing momentarily.

the price of 20GBP nevertheless doesn't really hurt anyone trying it out, it can be useful and quite good sounding for contexts, which don't relay on real time processing.

although some of the encountered troubles (artefacts and latency) cannot be clearly marked as development errors there is obviously some things to improve here:

- elastic~ should idealistically produce the same results, when using the same settings, especially when using very small buffer sizes.

- the developers mark the used algorhythm as the one of "Cubase, Ableton Live, and Kontakt", nevertheless it oftenly sounds worse, which shows, that the algorythm alone is probably not the reason why pitch changing would sound good and at low latency. i experimented a bit with low cut filters on the incoming signal, though this didn't change much. 

When comparing the signal with kontakt's sound it seems, as if kontakt's internal 32bit resolution was not used in elastic.

- the extraoctave feature extending elastics range from 0.5-2x to 0.25-4 speed and -1/1 to -2/2 pitch octaves does not change audio quality audibly, therefore it can be turned on by default anyways. the sound quality in the original smaller processing range does not seem to be affected by this. extraoctave is not an extra sounding feature.

- the livebuffer feature appears to have to be turned on always, otherwise max crashes instantly, at least on a slow machine like the one i used.

- elastic's website on elasticmax.co.uk appears to be short on info. several postings of mine in the forum have not been finally answered. example patches apart from the elastic.help are missing. The URL of an apparent Youtube video about real time harmonizing is nowhere to be found.

- elastic~ "extreme", a version with larger pitch and speed range has long been mentioned possible on elasticmax's website, there's no news regarding this since a while.

hope this helped anyone, i attached my test patch below.

open to corrections/suggestions/additions.

two months ago i bought elastic~, finally got to proper testing  today.

- Latency: no less then approx. 92 ms, when comparing elastic's output signal with the original signal, while working with an i/o size of 512 and a vector size of 64 and using a delay~ with adjustable milliseconds on the original signal (*~ -1). 
- More notes: Latency is generally unstable/unpredictable. Entering edit mode in your patch alone changes the latency, too. Using the same buffer size again also does not consistently produce the same latency with elastic. A very small buffer size under 50 ms might produce artefacts in one case but not in another. There's many possible causes for this, nevertheless i didn't experience such unpredictability with buffer and groove, or with delay lines of any sort.

- Buffer size as well: The lowest i could use was 36 (ms) without elastic starting to produce nasty artefacts. 
this while have set the delay of elastics playhead to 0.01 ms. This setting was again not reliable. Somewhere above 55 ms artefacts seem to dissappear for good, nevertheless this already produces a latency of more than 110 ms, unstable values here as well, although the buffer size was the same.
- when changing the buffer size on the fly max likes to crash oftenly.

- Signal quality: having set elastic~ to original pitch and speed still processes the signal extremely. 
Following what ableton's developers already did in version 3 or so i would recommend for the elastic developers to establish an option to deliberately turn off processing when original speed and pitch are set, as this would improve audio quality massively on that setting. In ableton the "warp engine" can be turned off for that purpose.

as i paid for this external i would NOT recommend buying elastic~ for the purpose of real-time harmonizing momentarily.
the price of 20GBP nevertheless doesn't really hurt anyone trying it out, it can be useful and quite good sounding for contexts, which don't relay on real time processing.
although some of the encountered troubles (artefacts and latency) cannot be clearly marked as development errors there is obviously some things to improve here:

- the developers mark the used algorhythm as the one of "Cubase, Ableton Live, and Kontakt", nevertheless it oftenly sounds worse, which shows, that the algorythm alone is probably not the reason why pitch changing would sound good and at low latency. i experimented a bit with low cut filters on the incoming signal, though this didn't change much. 
When comparing the signal with kontakt's sound it seems, as if kontakt's internal 32bit resolution was not used in elastic.

hope this helped anyone, i attached my test patch below.
open to corrections/suggestions/additions.

elastic-as-real-time-harmonizer-test-case-not-good

the missing URL of the elastic~ demo video on youtube at least:

http://www.youtube.com/watch?v=SM1z1bsuFeg

the missing URL of the elastic~ demo video on youtube at least: 

elastic~ as real time harmonizer / test case: not good.