Re: [linux-audio-dev] XAP: Some thoughts on control ramping

[David Olofson]

On Tuesday 21 January 2003 05.09, David Olofson wrote:
> So, it seems like we'll need that 0 test anyway. It should
> obviously apply the target value instantly, so that later events
> will work even if they land at the same timestamp. It doesn't have
> to set the delta at all, as sending a 0 duration means you *have*
> to send another event with the same timestamp anyway.

Another idea:
Since we need that (duration == 0) test anyway, why not have it 
explicitly stop ramping as well, so we can connect non-ramped outputs 
to ramped inputs and vice versa?

This doesn't interfere with normal operation, and it seems rude and 
pointless to enforce ramping on all FP ins and outs, just to 
guarantee punishment if you break the rules while ramping. :-)


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! .
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---

[linux-audio-dev] Re: [Jackit-devel] hangs with 2.4.20, jack and clients... one tinypatch latter

[Fernando Pablo Lopez-Lezcano]

> > >The hang is not happening in any of these processes, as far as I can
> > >tell. It is not always in exactly the same place, although it happens
> > >always around the same area. I can see time suddenly jumping up, there
> > >are xruns printed (huge underruns, not the usual stuff - I assume this
> > >is before rt_monitor degrades the priorities and things return to
> > >normal). This usually is right after ardour's process function returns.
> > >So I have to see which process is actually interrupting all of this and
> > >hanging the whole thing. 
> > >
> > >Very confused at this point. 
> > 
> > can you check the signalled/awake/complete timestamps in the client
> > struct/debug output? these tell you whether/when:
> > 
> > (1) jackd woke the client with write()
> > (2) the client woke up from poll
> > (3) the client wrote to the next fifo
> > 
> > these are 3 critical steps that tell you whether or not the hang
> > happens between the two processes, or within one of them. each
> > situation is drastically different from the other and we need to know
> > which it is.
> 
> If I understand things correctly the problem seems to be happening in
> the alsa_driver_process function (or in alsa itself). Here a list of
> what happens just before the hang with some comments, please correct me
> if I'm wrong:

[very long printout of trace deleted]

Just by chance I stumbled on this message: 

  http://www.redhat.com/mailing-lists/ext3-users/msg08990.html

(I was looking at latency issues on a 3ware controller - no matter what
I do I get 12-18 mSec hits - google for vm.bdflush and look at the
second link)

"This patch fixes an inefficiency and potential system lockup in the 2.4
kernel's ext3 filesystem.  The problem has been present since
2.4.20-pre5."

Aha!! pre5 is when I started having problems! 
Latter Andrew tells us:

"Unless task A and task B happen to both have realtime scheduling policy
- if they do then kjournald will never run.  The state is never cleared
and your box locks up."

The problem always happens with realtime scheduling :-)

So, I patched the kernel and I've been running jack+ardour SCHED_FIFO
for more than an hour (previously it would die at most in a couple of
minutes). Even stressing the disk with a nice tar. I would hate to have
to post in 1/2 hour saying that it locked again, so this time I will
_not_ say the problem is solved :-)

Try it out. 
-- Fernando

Re: [linux-audio-dev] XAP: Some thoughts on control ramping

[David Olofson]

On Tuesday 21 January 2003 00.41, David Olofson wrote:
[...]
> > > So, alternative 1; RAMP events only:
[...]
> > No branch is needed,
>
> Excellent! :-)

I just realized something that might be worth pointing out.

If you send multiple RAMP events for the same control at the same 
timestamp, only the last one will have any effect. This is because 
RAMP events change only the delta, and it takes sample frame loops to 
actually change the value.

The problem is that if you send multiple RAMP events that are so 
close together they end up getting the same timestamp, results won't 
be what you want.

For example, setting the initial level of an envelope and then 
setting up the delay or attack phase won't work, unless you wait for 
one frame before sending the RAMP event for the delay or attack 
phase. Similarly, an attack duration of 0 would result in the decay 
starting at the current value, instead of the attack peak level.

Note that waiting for one frame after saying "ramp to y over 0 
frames" is actually illegal by the definition! You're one frame past 
the aim point when the next event arrives, so results are undefined.

So, it seems like we'll need that 0 test anyway. It should obviously 
apply the target value instantly, so that later events will work even 
if they land at the same timestamp. It doesn't have to set the delta 
at all, as sending a 0 duration means you *have* to send another 
event with the same timestamp anyway.

Resulting Audiality code (how unusual! ;-):

if(ev->arg2)
{
v->ic[ev->index].dv = ev->arg1 << RAMP_BITS;
v->ic[ev->index].dv -= v->ic[ev->index].v;
v->ic[ev->index].dv /= ev->arg2 + 1;
}
else
v->ic[ev->index].v = ev->arg1 << RAMP_BITS;


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! .
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---

[linux-audio-dev] ecamegapedal 0.4.0 released

[Kai Vehmanen]

1. A short summary of changes

Sliders for parameter control and text inputs for 
lower and upper bounds have been added as well as
support for LADSPA-1.1 and ecasound effect parameter 
hints. There has been some user interface improvements 
and a native JACK support has been added. Updated to 
use the new ecasound-2.2 libraries.

---
2. What is ecamegapedal?

Ecamegapedal is a real-time effect processor software with
a graphical user interface for controlling the effect 
parameters. It is meant to be used as a virtual guitar-fx 
or studio effect box. In addition to real-time operation, 
ecamegapedal also supports reading from and writing to audio 
files. All audio object and effect plugin types provided by the 
ecasound libraries are supported. This includes ALSA, JACK, 
OSS, aRts, over 20 file formats, over 30 effect types, LADSPA 
plugins and multi-operator effect presets. Ecamegapedal's 
implementation is based on ecasound and Qt libraries.

Ecamegapedal is licensed under the GPL.

---
3. Changes since the last stable release

* Added native JACK support. If compiled with JACK support
  enabled, ecamegapedal will upon startup fetch the 
  current engine parameters from the JACK server, and 
  initialize the ecamegapedal configuration to work 
  with JACK. In practice this means that you don't 
  have to manually set the buffersize and sample rate
  parameters to use ecamegapedal with JACK.

* Support for LADSPA-1.1 and ecasound effect parameter 
  hints.

* Text inputs for overriding default upper and lower
  bounds for parameter values.

* Sliders for controlling parameter values.

* Pixmaps for transport control buttons.

* Takes advantage of the newly released ecasound 2.2.0 
  libraries (does not work with older ecasound releases).

* Should work with all released Qt2 and Qt3 versions.
  Tested with qt-2.3.2, qt-3.0.5 and qt-3.1.1.

---
4. Contributors

Patches
Kai Vehmanen
Arto Hamara

Bug Hunting
Jaakko Prattala
Justin Rosander
Junichi Uekawa

Feature proposals
Dan Lyons

---
5. Links and files
   
Web sites:
http://www.eca.cx
http://www.eca.cx/ecamegapedal
http://jackit.sourceforge.net

Source and binary packages:
http://ecasound.seul.org/download
http://ecasound.seul.org/download/ecamegapedal-0.4.0.tar.gz

--
 http://www.eca.cx
 Audio software for Linux!

[linux-audio-dev] determining pitch of audio

[Lance Blisters]

  is there free software which will, when fed 
  audio, tell me a precise number for the primary 
  frequency component?  i need to sort/tune some 
  samples, I want a software solution which is as 
  good as a human ear.  preferrably in the form of 
  a ladspa "guitar tuner" plugin, so i can employ 
  in my favorite host.

  -geoff

Re: [linux-audio-dev] XAP: Some thoughts on control ramping

[David Olofson]

On Monday 20 January 2003 18.59, Steve Harris wrote:
> On Mon, Jan 20, 2003 at 06:08:48 +0100, David Olofson wrote:
> > > but the cases I can think of it wont hurt:
> > >
> > > notched switches: will always jump to the target value anyway,
> > > so wont have to do any interpolation.
> >
> > RAMP is always interpreted as SET? Not the best way to fake
> > ramping, but then, if you say you do not ramp, you shouldn't be
> > expected to even fake it. Makes sense.
>
> Well, youd have to extrapolate the ramp to the pint where the next
> notch is reached and reshedule a 0 duration event for there if the
> timing was critical.

Yeah - but then you really have a continous control with some 
internal processing. I think a control is either continous or not, 
from the API POV. If it's continous, it should implement or "fake" 
ramping in the way expected. If it's not continous, it shouldn't have 
to worry about ramping.

Anyway, inserting an event a bit later in your own queue doesn't 
sound all that hard, but there's a "hidden" problem: If the event 
lands beyond the end of the block, event ordering will be screwed up. 
Senders just add events at the end of queues, assuming that there are 
no events for the current block when they start sending.

One solution would be to always insert/sort, but I don't see many 
situations where this overhead and complexity *really* adds anything. 
Also, such a design would be in conflict with the idea that controls 
are driven by structured data; an efficient alternative to audio rate 
controls, rather than a "sequencer database interface".


> > So, alternative 1; RAMP events only:
> >
> >   case XAP_A_RAMP:
> > if(ev->duration)
> > dvalue = (ev->value - value) / ev->duration;
>
> I think you'll find that that should be
>   dvalue = (ev->value - value) / (ev->duration + 1.0f);
>
> Otherwise you end up with unwanted shelves or delays in the ramp
> shape.

Yes, you're right. My confusion is because Audiality (for some 
reason) applies dv *after* using v for each sample.


> No branch is needed,

Excellent! :-)


> cos the next delta of the control value will
> set it to the correct value, but it may well just be easier to set
> it and not have to cancel the delta next sample.

That sounds like the case where you're looking for a STOP event - and 
I don't think there's a real need for that.

If you say "aim at (y, t)", you mean exactly that - and what the 
receiver does when passing t is really *undefined*. It might try to 
continue ramping, but you should *never* allow it to, because the 
plugin might blow up if the ramping isn't as linear as you think it 
is!

Just always tell the receiver what to do at or before the current aim 
point, and you're safe. Ramped controls are driven by a chain of RAMP 
events.

It may feel a bit scary that you can't reliably stop ramping, but 
it's not very different from audio streaming. You don't have a 
definitive stable/dead/stopped state until you kill the stream - and 
that means disconnecting the input, or taking the receiver out of the 
net. Untill you do that, you have to do *something* to keep the 
receiver happy.


> > Using only RAMP events definitely looks like a great idea to me.
> > I'm going to try it in Audiality right away! :-)
>
> Yup, I like it too.
>
> > BTW, using INFINITY for duration (MAXINT for fixed point,
> > provided MAXINT is not a valid control value) has the same effect
> > as a STOP event... Should this be allowed? We've already
> > concluded that the
>
> No, getting Infs into float code can cause problems down the line.

Yeah, you're probably right - and again, the usefullness of the STOP 
feature is an illusion. Old habit or something; I tend to like the 
idea of stable states.


> > And yes, duration would be of the same type as the control value,
> > I think. There's no point in making it an integer for float
> > controls, since plugins will only use it for a aim point -> dv
> > transformation anyway.
>
> Yes, though there is the problem of what happens when the host
> specifies a non integer duration,

That would be illegal... Which is a good reason to prevent it, to 
eliminate the possibility, as well as any doubts about what 
'duration' really is.


> events cant arrive at non integer
> timestamps, so you will end up with overshoot or undershoot.

Yes...


> It may
> be safer to make them ints. int -> float cast is not expensive.

Right, and the cast has to be done *somewhere* anyway, I think. 
(Except when playing back prerecorded events, but that's not really 
something to optimize for.)

At least, the Audiality EG calculates 'duration' as the # of frames 
to the next node or other event, so it's all integer math in that end 
of the connection anyway. Well, the node timing is derived from fixed 
point values, but that's *before* we start talking about event 
timestamps. Any other way could potentially have 'duration' disagree 
with event timing due to rounding error

Re: [linux-audio-dev] XAP: Some thoughts on control ramping

[Steve Harris]

On Mon, Jan 20, 2003 at 06:08:48 +0100, David Olofson wrote:
> > but the cases I can think of it wont hurt:
> >
> > notched switches: will always jump to the target value anyway, so
> > wont have to do any interpolation.
> 
> RAMP is always interpreted as SET? Not the best way to fake ramping, 
> but then, if you say you do not ramp, you shouldn't be expected to 
> even fake it. Makes sense.

Well, youd have to extrapolate the ramp to the pint where the next notch
is reached and reshedule a 0 duration event for there if the timing was
critical.
 
> So, alternative 1; RAMP events only:
> 
> case XAP_A_RAMP:
>   if(ev->duration)
>   dvalue = (ev->value - value) / ev->duration;

I think you'll find that that should be
dvalue = (ev->value - value) / (ev->duration + 1.0f);

Otherwise you end up with unwanted shelves or delays in the ramp shape.

No branch is needed, cos the next delta of the control value will set it to
the correct value, but it may well just be easier to set it and not have
to cancel the delta next sample.

> Using only RAMP events definitely looks like a great idea to me. I'm 
> going to try it in Audiality right away! :-)

Yup, I like it too.
 
> BTW, using INFINITY for duration (MAXINT for fixed point, provided 
> MAXINT is not a valid control value) has the same effect as a STOP 
> event... Should this be allowed? We've already concluded that the 

No, getting Infs into float code can cause problems down the line.

> And yes, duration would be of the same type as the control value, I 
> think. There's no point in making it an integer for float controls, 
> since plugins will only use it for a aim point -> dv transformation 
> anyway.

Yes, though there is the problem of what happens when the host specifies a
non integer duration, events cant arrive at non integer timestamps, so you
will end up with overshoot or undershoot. It may be safer to make them
ints. int -> float cast is not expensive.

- Steve

Re: [linux-audio-dev] XAP: Some thoughts on control ramping

[David Olofson]

On Monday 20 January 2003 16.15, Steve Harris wrote:
> On Mon, Jan 20, 2003 at 04:13:17 +0100, David Olofson wrote:
> > 5) A more serious issue is that if control events are not
> >allowed while ramping, except at the time of the aim
> >point, there is no way to avoid sending one RAMP event
> >for each block while ramping. You can't aim further
> >ahead than the first frame of the next block, or you
> >might have to break in and adjust the aim before you
> >hit the aim point.
>
> I dont see why there is a restriction on aiming further ahead than
> the current block, this seems like a mistake. It forces the plugins
> to be closed to linear than is desirable.

I totally agree on this. The reason why I'm bringing it up is that it 
was originally suggested that a RAMP event refers to a specific range 
in time; basically a "macro event" that describes two actions; one 
now and one at the end of the ramp. (Physically, the latter action 
would be "stop ramping", although that has been ruled out as tricky 
to implement while not useful.)


> > Questions:
> >
> > A) Is it necessary to require that aim points are
> >within the current block, to avoid "re-aiming"?
>
> I dont see why, the obvoius inner loop for ramp aiming should deal
> with this perfectly well, it will just replace the delta_control
> number.

Exactly.


> > B) Is STOP useful enough to be in XAP?
>
> I'd argue for it not be be there. Its hard to see when it would be
> useful ,ad its one more thing to handle.

Agreed.

At the time, it happens to be a shortcut in Audiality, but as soon as 
I implement modulation of the envelope generators, that shortcut will 
be essentially useless, since the hold and sustain sections will no 
longer be guaranteed flat. (The EG will basically be multiplying the 
envelope with one or more streams of control events.)


> SET /could/ be done with a ramp with target time of 0, not
> optimally efficeint,

OTOH, this test must be done somewhere anyway. (Audiality does it on 
the sender side, as it has SET + RAMP.) It could be argued that with 
pre-recorded event streams, it's better to use SET, as that 
eliminates the run-time conditional altogether, but I'm not sure it's 
worth it. (It's just one very simple test...) For control streams 
generated on the fly, it doesn't matter much where you do it.


> but the cases I can think of it wont hurt:
>
> notched switches: will always jump to the target value anyway, so
> wont have to do any interpolation.

RAMP is always interpreted as SET? Not the best way to fake ramping, 
but then, if you say you do not ramp, you shouldn't be expected to 
even fake it. Makes sense.


> continuous controls: SET operations will be quite unusual, and the
> overhead is not that big.

So, alternative 1; RAMP events only:

  case XAP_A_RAMP:
if(ev->duration)
dvalue = (ev->value - value) / ev->duration;
else
{
value = ev->value;
dvalue = 0.0;
}
break;

- Adds a receiver side conditional for decoding, even if
  the input is prerecorded.
- Contrary to the normal logic, duration == 0 implies
  that ramping is *stopped* by the RAMP event.
+ Senders don't have to check for 0 duration.
+ duration == 0 becomes a valid and logical case.
+ Won't blow up if a 0 duration is "accidentally" sent.
+ More streamlined API; only one event per control type.


Alternative 2; RAMP and SET:

  case XAP_A_SET:
value = ev->value;
dvalue = 0.0;
break;
  case XAP_A_RAMP:
dvalue = (ev->value - value) / ev->duration;
break;

- More events in the API.
- Senders must replace 0 duration RAMPs with SET.
- Sending 0 for RAMP duration may have plugins blowing up.
- Turns "ramping with dv == 0" into a special state.
+ No extra conditional for duration; switch() is full decode.
+ No 0 duration testing at all when playing prerecorded events.


Using only RAMP events definitely looks like a great idea to me. I'm 
going to try it in Audiality right away! :-)


BTW, using INFINITY for duration (MAXINT for fixed point, provided 
MAXINT is not a valid control value) has the same effect as a STOP 
event... Should this be allowed? We've already concluded that the 
STOP action - whether it's an event of it's own or not - isn't very 
useful, so maybe we should just leave this in the "undefined 
behavior" domain.

And yes, duration would be of the same type as the control value, I 
think. There's no point in making it an integer for float controls, 
since plugins will only use it for a aim point -> dv transformation 
anyway.


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --

Re: [linux-audio-dev] Additional LADSPA hints

[torbenh]

On Sun, Jan 19, 2003 at 06:44:36PM +, Steve Harris wrote:
> My main concern abou htis hint is that it artificially introduces a
> distinction that isn't really there. Its fine as long as no modular host
> ever prevents me form wiring an audio output to hinted continuous control
> input or vice-versa.

i dont consider evaluating that hint in gAlan... its fine with me...

[linux-audio-dev] [ANN] JACK TimeMachine 0.0.2

[Steve Harris]

I've fixed some build issues and theoretically made it slightly more
efficient. If you managed to build 0.0.1 theres no real point in you
upgrading.

Theres also now a webpage of sorts, with a screenshot ;)
http://plugin.org.uk/timemachine/

- Steve

Re: [linux-audio-dev] XAP: Some thoughts on control ramping

[Steve Harris]

On Mon, Jan 20, 2003 at 04:13:17 +0100, David Olofson wrote:
>   5) A more serious issue is that if control events are not
>  allowed while ramping, except at the time of the aim
>  point, there is no way to avoid sending one RAMP event
>  for each block while ramping. You can't aim further
>  ahead than the first frame of the next block, or you
>  might have to break in and adjust the aim before you
>  hit the aim point.

I dont see why there is a restriction on aiming further ahead than the
current block, this seems like a mistake. It forces the plugins to be
closed to linear than is desirable.
 
> Questions:
> 
>   A) Is it necessary to require that aim points are
>  within the current block, to avoid "re-aiming"?

I dont see why, the obvoius inner loop for ramp aiming should deal with
this perfectly well, it will just replace the delta_control number.
 
>   B) Is STOP useful enough to be in XAP?

I'd argue for it not be be there. Its hard to see when it would be
useful ,ad its one more thing to handle.

SET /could/ be done with a ramp with target time of 0, not optimally efficeint,
but the cases I can think of it wont hurt:

notched switches: will always jump to the target value anyway, so wont
have to do any interpolation.

continuous controls: SET operations will be quite unusual, and the
overhead is not that big.

- Steve, minimalist ;)

[linux-audio-dev] BU FIRSATTAN RARARLANIN.

[MARAMARA Erotik Market]

DIKKAT

VIDEO CD :
Iddia ediyoruz.. Hic bir yerden temin edemeyeceginiz ses ve göruntu kalitesi ile 
yuzlerce porno video CD. arSivimiz yenilenmistir. istemis oldugunuz video CD.ler 
bire bir yollanir kesinlikle isteginiz harici alakasiz baSka video CD.ler yollanmaz.

Anal. Oral. Vajinal. Grup. Zenci. FethiS. Ayak fethiS. Gay. Zenci gay. Trans. 
Transexual.
Lezbiyen ve daha bircok ceSit   

ZENGIN URUN CESITLERIMIZ :

Sisme Bebekler . (Erkek & Bayan) Kesinlikle size hayir demeyecek.
Vibratörler  Istediginiz boy ve ebatlarda 
(Vajinal/Anal/catal.Pilli.Motorlu.TitreSimli)
Suni Vajinalar . Asla gerceginden ayirt edemeyeceksiniz (Gercek ten hassasiyetinde)
Reailistik Penisler. Gercek ten hassasiyetinde ve dokusunda (Vantuzlu/Deri kemer 
kilotlu)
Vakum Pompalari  Ereksiyonu kolaylastirici ve duzenli kullanimlarda peniste 
irilesme saglar.
Geciktiriciler . Erken boSalmayi dert etmeyin (Sprey ceSitleri/Kremler)
Kremler  Anal ve Vajinal iliSkilerde kullanabileceginiz kayganlaStirici 
krem ceSitleri
Uyandiricilar .. Cinsel istek uyandirici haplar ve damlalar.

Yapmaniz gereken tek Sey    TIKLAMAK ..



NOT : BU MAIL REKLAM AMAcLI OLUP HIcBIR SEKILDE TARAFIMIZDA KAYDINIZ BULUNMAMAKTADIR.
  ILGI ALANINIZIN DISINDA ISE EGER LUTFEN DIKKATE ALMAYINIZ TESEKKURLER.. 

[linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15

[Kjetil S. Matheussen]

k_jack is a jack reimplementation, and mammut is a very special sound
transformating sound editor.

Download from http://www.notam02.no/arkiv/src/




New in mammut v0.14->v0.15:
---
-Removed the synth transform. It was not supposed to be there and had no
 function.
-Fixed the wobble transform. Segfaulted with mono-files. (Bug found
 by Dave Phillips)






k_jack V0.0.0.5 ALPHA - EXPERIMENTAL
-



ABOUT

k_jack currently consists of k_jackd~, libk_jack and libaipc.

k_jackd~ is a jack server external for pure-data.

libk_jack is (supposed to be) a (somewhat) libjack compatible
library.

Jack applications that want to contact k_jackd~ instead
of jackd must (somehow) be linked with libk_jack and
libaipc instead of libjack.

k_jackd~ does not speak with libjack, and jackd does not
speak with libk_jack.

libaipc is a library for audio interprocess communication,
based on code from the vstserver. A preview version is
included with this version of k_jack. (API is not settled.)

By using libaipc for interprocess communication, and letting
PD take care of various low/mid/high-level audio-stuff,
only a few hundred lines of code is currently used for this
implementation of a simple jack system.

k_jackd~ and libk_jack are not based on the jack sourcecode
found at jackit.sf.net, except for protos in the header files.



COMPILE
1. Go into the aipc/src folder and write make to compile up
   libaipc.a
2. Go into the library folder and write make to compile up
   libk_jack.a
3. Write make to compile up k_jack~.pd_linux.
4. Relink you jack application(s) somehow.



USAGE
1. Start pd with the "-lib k_jackd~" option.
2. Start a jack application linked with libk_jack.
3. Make an object in pd called "k_jackd~ ".
   Correct number of inlets and outlets will be made
   automaticly.

That should be it. Later, when things get more stable, point 3
can do point 2 automaticly.



WHY
use k_jackd~ ?

1. Simple. Only the clientname is used, not the portnames.
2. Easy and powerful interface to control the audioflow.
3. Good performance. Shouldn't be necessary to run as root.



TESTED CLIENTS
simple_client, freqtweak, ceres.


BUGS
Crashes pretty often. Does not clean up. Huge risk of not
freeing shared memory in the current implementation: Client
must exit before server, and client must not crash. And
server must not crash.


CONTACT
Send ideas (especially about the k_jackd~ object syntax),
comments (especially about the libaipc API), questions,
code, food, etc. to [EMAIL PROTECTED]



--