On Sun, Oct 10, 2010 at 05:27:25PM -0400, Jeremy wrote: The basic method for pitch detection is the same as in Autotalent. Some refinements are added: interpolation of autocorrelation peaks (improves accuracy a lot, in particular at higher pitches), some logic in the determination of the current note, and whatever it takes to make things work correctly at all sample rates between 44.1 and 192 kHz. The resampling is completely different - I never managed to grok how Autotalent does it. But whatever it does has some problems, just look at the spectrum of a 1 kHz tone 'retuned' to 987.7 Hz. Resampling is done by linear interpolation, at 44.1 and 48 kHz this is done on the signal upsampled to twice the original rate. It would be relatively easy to improve this further, but I don't think it would matter much. You'll find some comments on the algorithm used in retuner.cc. The computation of the required correction could be improved a lot by making the algorithm look ahead a few seconds. Of course this would mean off-line processing, e.g. operating on an Ardour region. Another improvement would be formant estimation and correction, for an off-line algorithm that would be relatively easy. Ciao, -- FA There are three of them, and Alleline.

On Mon, Oct 11, 2010 at 02:33:31AM +0400, alex stone wrote: I'm happy to hear you like it ! Not for the Jack apps. Rev1 and At1 are two of a collection of processors that will eventually be released as plugins in a 'rack' type of host. The GUIs and some of the internals are already designed to fit into that format. When that happens, the rack will have 'total recall' (session and snapshots), and each plugin type will have presets (per user). What I could do in the meantime is to provide them as Python classes (still with the GUI), which would allow them to be scripted easily. Mmm. Using 8 reverbs for a single orchestral mix doesn't make any sense - unless you are doing something psychedelic (*) they all play in the same space. It's easy to share a reverb for any number of channels even if the dry/wet ratio is different for each. (*) Like some opera CDs from DG wich have completely different reverbs for the orchestra and the singers - makes me seasick :-) Ciao, -- FA There are three of them, and Alleline.

On Sun, Oct 10, 2010 at 07:31:08PM -0400, Jeremy wrote: Yes, this will be a new plugin API, support libraries for both plugins and hosts will be provided, but I'm not going to actively promote it as a replacement for anything existing. It's not designed to be 'simple' - plugins and hosts *must* support a minimal functionality much wider than LADSPA or LV2. For example plugins must have a dedicated GUI, there is no such thing as a host constructing a GUI from e.g. control port descriptors - these are not even visible to a host. If a plugin supports multichannel use, this must be provided explicitly - the host can not just replicate the DSP code. There are many other differences, and some of them have far reaching consequences. This may well discourage 'novice' programmers, but that is to some extent intentional. I want this format to be used only for plugins that conform to some minimal quality standards. So it's not meant to provide an easy way to create a wrapper around some DSP code you don't even have to understand. I'm creating apps such as REV1, AT1 and some others as test cases. The specs are being reviewed and modified regularly as a result. Ciao, -- FA There are three of them, and Alleline.

On Mon, Oct 11, 2010 at 03:31:58AM +0400, alex stone wrote: None of this means you need to use more than one reverb, and if the target is to have more consistency you definitely should use just one. Reverb is a linear operation. If F1, F2, F3 are linear operations (EQ, delay, gain), then F1 (reverb (x1)) + F2 (reverb (x2)) + F3 (reverb (x3)) is the same as reverb (F1 (x1) + F2 (x2) + F3 (x3)) which uses just one reverb. * Set the reverb to 100% 'wet' and connect the outputs to your main mixing bus. * Send controlled amounts of each channel/group/section (after fader) to the reverb input. You can even equalise or delay these separately. Ciao, -- FA There are three of them, and Alleline.

On 10/11/10 14:33, fons(a)kokkinizita.net wrote: Well, as outlined below I am suggesting git/svn not as means for concurrent/team development but for providing a canonical version-independent URL that can be tracked for each of the projects. A symlink 'zita-rev1-latest.tar.bz2' could provide the former, but one won't be able to tell if there's any update without actually downloading it or checking the mtime with HTTP-HEAD. That's 3 steps to much :) Besides: The issue with download is that the next version number is not predictable. One needs to use a web-browser. If it was a repository-checkout it'd be a one-time setup and just calling a single 'pull & build' script afterward. With git it's also easy to keep more than one repo: fi. a private with all the small changes and a public where you only push out releases. As for the 'sudo make install' - I'm quite reluctant to run that command. Usually a 'make' suffices for testing. ..and if I can't wait until a tool makes it into Debian I roll my own package for the meantime which provides for clean removal later on. The commonly used target (autotools) is "make uninstall" (not "make remove") The motivation is not about recovering disk-space about being able to keep the system clean. Some of my earlier test|development machines|chroots quickly became messed up with different versions in /usr/lib /usr/local/lib and after a few weeks or month there was no hope but to re-install the thing. You may know this situation. The overhead of rolling custom packages is small compared to re-installing or cleaning up by hand. aaw right. PREFIX=$HOME/usr make install # does not work but make PREFIX=$HOME/usr install # does Thanks for the hint. I agree programmers should not be concerned about packaging. I was just suggesting a few trivial changes that'll make live easier for PPL packaging (either for distros or for their own benefit). Anyway congratulations on these effects. I've only tested the reverb (I don't [yet] have use for an autotuner) and it's brilliant. I'm already looking forward to 'rack GUI'. Keep up the good work. Cheers! robin PS. Do you know or have any mirrors of kokkinizita.net? It'd be a pity if all the great stuff on there would be lost in some accident.

On 10/11/2010 07:35 AM, fons(a)kokkinizita.net wrote: It is just a common idiom and would be good to follow it. -- Fernando

Excerpts from Robin Gareus's message of 2010-10-11 15:47:43 +0200: The only thing I could wish for is a short announcement mail in case of new versions. This way I'll update the packages in a more timely fashion, otherwise some user of the package needs to tell me that there's an update available, which can take weeks. The actual time for me to update a package is usually 2 minutes. I like short changelogs too. Well, no big deal, just my little packagers wishlist.