On Sun, Sep 25, 2011 at 4:41 PM, Fons Adriaensen <fons@xxxxxxxxxxxxxx> wrote: > On Sun, Sep 25, 2011 at 03:45:31PM -0400, Paul Davis wrote: > >> hint: the patch to add a new port type to JACK will involve on the >> same order of magnitude number of characters as have already been used >> in this email thread. > > Indeed. But why should anyone submit a patch for an idea that > has already been rejected, in particular if the rejection was > motivated in a way that implicitly condones crappy programming > instead of criticizing it ? What sort of excellence can you > expect if things are decided in that way ? (1) > > Don't take this personally, but I've had enough of this sort > of negative argumentation for some time. I do remember the LV2 > discussions (2), the Jack session ones, and some others. And > the result is that I go my own way, even if that leads to a > loss of synergy and benefit for all. > > > (1) Mediocrity. > (2) The real gem in that case was a remark that representing > the sample rate as a ratio would lead to inefficiency as it > required a (1, one) division. this is a reminder of the closing post from the last thread about this subject. it came from you. to me it can be summarized as "a complete control API would include both lower sample rate control signals and timestamped events", which if true leads to my point about there being a lack of consenus about the right way to tackle the issue, and as usually happens with a project like jack, a lack of consensus *AND* and a lack of any working patch means that things don't change. neither of the two ideas was rejected. the subject is basically still open. ------------------------ On Sat, Feb 20, 2010 at 07:31:04AM +0100, torbenh wrote: > i am basically more in favour of timestamped events. > but your argumentation in this thread is pretty convincing. > and timestamped events come with a galore of other problems, > which i think are harder to tackle in a jack context. I'll repeat once again ** Low rate control signals are not meant to replace generic timestamped events which are still needed. ** They provide a solution for some cases that are quite difficult to handle with events, even if you don't consider the Jack context, i.e. the variable data size. For example it would be quite hairy to use discrete events to create a C1 continuous control signal - C1 means no 'jumps' and no 'corners'. It can be done but would require a level of complexity that breaks the charms of the basic idea and would make most potential users run away screaming. Just combining (adding) two such streams with non-coincident events would be a real nightmare. With continuous control signals the burden of ensuring it has the required qualities for a particular use (e.g. any degree of continuity, or spectral limits) are on the generator of the control signal. The receiver would be safe to use it at its full bandwidth, but doesn't have to do this - it could still cut corners for efficiency if it wanted, and in most cases that would actually happen as Fs/16 is overkill anyway. The 1/16 rate is chosen because it ensures that even with a period size of 16 (the practical limit IMHO) all periods are still equal, and a factor of 16 reduction in stored data size makes it usable. Having non-power-of-2 period sizes complicates the picture. When and why was this allowed ? I'm pretty sure it will break a lot of code (including some of mine, including probably Aeolus and Jconvolver). _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
