Re: [LAU] My first impulse response

On Thu, Apr 26, 2007 at 04:53:31PM +0200, Arnold Krille wrote:

> Am Donnerstag, 26. April 2007 schrieb Fons Adriaensen:
>
> > On Wed, Apr 25, 2007 at 10:39:33PM +0200, Arnold Krille wrote:
> > > Question of the day: Is it possible to create IRs with aliki not via
> > > sweep but via delta pulse?
> > > I do have some locations which I would love to sample but I can't
> > > transport my speakers there.
> > You don't need Aliki to do this. If you can produce somehow a loud pulse
> > (a gunshot is the classical way) all you need to do is to record it.
> > Problem of course is the enormous peak/average amplitude ratio, so the IR
> > will have a poor S/N ratio. The frequency response won't be correct either.
> > You could use the result for reverb effect etc. but it will not be the
> > exact impulse response.
>
> Ah, so "all" aliki does is compute the pulse-signal from the sweep and its
> response and save that? Beginning to understand the convolution...

It's not 'all' but the deconvolution of the recorded sweep is the essential
function ATM. Apart from that it takes care of automated multichannel and
sequential measurements, ensuring that all are exactly time-aligned etc.

Aliki contains a lot of infrastructure that you don't see ATM because
the functions it will support are not yet present in the release version.

Some things already working in the development version or as separate
proof-of-concept code:

- Inversion of IR for speaker / room EQ.
- Two-dimensional windowing (time * freq) of IR (required for above).
- Computation of arbitrary filters as IR.
- Measurement of reverb time, clarity, and related parameters, on
  full range signal and in octave bands.
- Creation of synthetic reverb IR.

> Idea for the next aliki-release: Extend the export to also export jace config
> files. :-)

Nearly impossible, there are too many combinations and options, it would
almost amount to writing a jace config file in an aliki window. But see
also below...

> Fons: Thanks for that great software of yours! I am thinking about lashifying
> jace. Anyone interested in this?

Don't, for three reasons:

- The code in jace is not designed to be reconfigured without restarting -
  the configuration is not dynamic. Trying to make it would be very hard.
  So the only thing Lash could ever save is the name of the config file
  that jace started with. Lash can then as well start jace with that config
  without any support from jace itself.

- Jace is to be replaced soon by Aella (on which I'm working now). This
  will have a GUI, preset manangement etc. It will also offer zero-delay
  convolution for period sizes down to 64 frames, with much less CPU load
  than would be possible wiht jace. The difference is that Aella can use
  multiple partition sizes, very short ones for the first few ms and
  progressively longer ones later. It also offers a special reverb mode
  in which you have a short N_in * N_out convolution matrix for the early
  reflections, and a long 1 * N_out for the reverb tail, and also allows
  to modify the shape of the reverb while running. Aella preset files
  can refer to *.ald files created by Aliki.

- I will resist Lashification of any of my apps until the basic network
  protocol is fixed and documented, or until at least the Lash developers
  provide libraries that completely separate the protocol (encoding and
  decoding Lash messages) and the transport (sending and receiving them
  via the network). I do not want to depend on any libraries that will
  not integrate well with the application framework I'm using, and as
  long as these two functions are combined that will be the case.

-- 
FA
Follie! Follie! Delirio vano è questo !
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user