Re: [LAU] Jconv

On Fri, Mar 27, 2009 at 07:42:05PM +0100, Jörn Nettingsmeier wrote: The simple answer to this is no. I've been analysing and exploring this for almost two years now, and the conclusion of this is that two things I originally wanted to do will not happen. One is basing the design on LV2 somehow, and the second is using jack for internal routing. Regarding LV2, this would be possible in theory, by defining a number of extensions. This would mean: - I have to define the extensions. Some of them are likely to be in conflict with existing ones, or to create ambiguities which are not resolved by the current specs. - I have to write a host supporting the basic API, all existing extensions, and my own. - The chance that other hosts will adopt the new extensions is small. - I have to complicate things no end by handling basic and essential things as extensions. Apart from that, the nature of the extensions I'd need would mean that, apart from the extension mechanism itself, *nothing* would remain of the basic LV2 API. Things like its initialisation and process methods would be replaced *completely*. For a host author it would actually be easier to add a new plugin API than to add the extensions. There have been serious discussions with the LV2 devs some time ago, these have led to nothing. The standard answer is: "this can be provided by an extension" which has the same usability level as "Jesus will take care of it", or "this would be too complicated for a novice programmer who wants to write a simple plugin", which amounts to a voluntary limit on the scope of LV2. Regarding Jack, it is not moving in the right direction. - Port locking has been removed. I'd actually need this to be expanded rather than removed. - Port 'ties' are deprecated and will be removed. There is no simple and efficient alternative. - The latency issue. About a month ago Paul Davis posted his new latency calculation scheme and invited comments. I did reply, and one of my comments was that this scheme, while correct, provided only half of the required functionality. No reply at all to this, nada, niente. Either the matter is forgotton for the time being, or something is being developed in some closed group and we will some day have some solution, which may be satisfactory or not, imposed de facto. I can't take that risk. - Jack is getting too fat. We now have the scary situation that a non-audio connection can affect audio timing by creating a loop. Regarding integrating some of the things I will implement as plugins in Ardour, this would be possible, but some of the essential functionality will be lost. Some of the design, in particular in the GUI and global management areas is radically different, and Ardour has its history, both in terms of existing code structure and acceptance of its current personality by users. Apart from that it has a much wider scope than just being a mixer, and also that has its consequences. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.