Re: [LAU] My first impulse response

On Thu, Apr 26, 2007 at 04:53:31PM +0200, Arnold Krille wrote: 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. 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... 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 !