On Wed, 2012-08-22 at 10:27 +0200, Thorsten Wilms wrote: > On 08/22/2012 01:50 AM, David Robillard wrote: > > 1) Fork these plugins and add a tuning frequency port, in Hz, which > > makes the current reality of them using absolute octave signals go away. > > The avwlv2 project will have to adjust the ported AMS modules likewise. > > Though your plugins do not currently do this, you now seem to think this > > is the correct solution? > > > > 2) Define an absolute unit in octaves with a standard, absolute, center > > frequency. This is current reality, except the "define" part, and the > > 'standard' is a weird frequency. > > I would prefer 1), because 1/octave might be useful for modulation, but > just complicates matters if the task at hand is setting an oscillator to > a specific frequency.
1 does seem to be the most sensible, and avoids all these academic 'problems' since you can honestly consider all voltage relative, though it means adding a port. Originally I was thinking about a control to set the base frequency, but it sounds like you are thinking about adding a Hz frequency CV port. This is a better idea, since you get both options, and the debate goes away entirely. The overhead is about 2 multiplications per sample, so not really an issue. Assuming all the modules agree on the frequency you can just use the Oct CV in an 'absolute' way, or you can use only Hz, or use Hz + Oct for modulation. That's nice. One thing I hadn't originally thought of is tunability. For Hz, obviously you can just do this in the note modular. For Oct, maybe there would be negative consequences of shifting the value so A is actually, say, 0.01? Even numbers and twelfths would no longer lie on a note... Particularly for those who play along with real instruments, making sure we have sensible tunability is important. > One could even argue that oscillators should not have 1/octave ports at > all, but that there should be a plugin that takes a 1/octave modulation > input, a Hz base input and delivers a resulting Hz output. The DRY > principal applied to plugins. Fons can perhaps explain it in detail, but I believe there are good reasons why these plugins need to use logarithmic frequency inputs. The attempts at faithful implementations of the Moog filters in particular. It is definitely questionable for oscillators, but once you have that unit anywhere, you have an argument for wanting it there as well. I am not a fan of this problem that AMS has dropped in my lap, but I also don't want to have a "Hz vs Voct" debate that would never resolve anyway. I only aim to make both usable in Ingen or similar programs in a way that both powerful and not confusing. > I doubt consistency with the original plugins will matter in practice at > all. The added workload for you sucks, of course and only you can weight > that aspect of it, David. You are probably right that strict compatibility is not really going to be an issue for anybody in practice. However, I would prefer to not fork Fons' plugins at all. I get the impression he is not interested in maintaining ports (or doesn't have the time), but I would rather retain the ability to easily merge changes from upstream regardless. It may be a nice idea to slam these and the AMS module ports together and make one nice consistent set of modular plugins, but that is a more ambitious project that I can't take on right now. As far as my plan goes, between these and the blop ports, there are enough modules to build a decent synth, so I would like to focus on ensuring the Ingen file format is hyper-stable and getting an Ingen release out there. -dr
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
