Re: [Audacity-devel] some questions about modules and mod-script-pipe
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Vaughan J. <va...@au...> - 2011-03-04 23:34:25
|
Is this a crazy idea: just have the modules' code #include Audacity.h, rather than having to duplicate the version string, so it always gets updated and doesn't have to be done manually? That way, we know the built module and app match. I see ScripterCallback.cpp does #include "../../src/ShuttleGui.h" - V On 3/2/2011 1:41 PM, James Crook wrote: > On 01/03/2011 22:51, Vaughan Johnson wrote: >> On 2/27/2011 11:40 PM, Leland wrote: >>> On 2/27/11 9:59 PM, Vaughan Johnson wrote: >>>> A client of mine wants me to programmatically apply VST effects via script. >>>> >>>> I see that in LoadModule(), the module version string must exactly match >>>> the Audacity version string. That means modules that used to work no >>>> longer work without rebuild, regardless whether the code actually works. >>>> Any objection to me changing it to Audacity version number components >>>> and>=, so it's just a minimum version requirement? Other modules need >>>> update if I do that? >>>> >>> Having it match exactly is really the only way to guarantee they'll work >>> together. Since there's no class abstractions/interfaces isolating >>> modules from Audacity internal changes, a ">=" may or may not work. >>> And, even if the "backleveled" module appears to work, it may be doing >>> very subtle things...even slight corruptions to memory or audio. >> Thanks, Leland. But for the alphas we're appending the date, so it needs >> to be rebuilt every day. Any smaller time granularity that would be safe? > > We need to be strict here. > > If it is a hardship rebuilding the plug-ins, then let us address that as > an issue. In other words, if you want to test an alpha with a plug-in, > it should either be a plug-in we build for you with that alpha, or you > should be building alpha and plug-in from source yourself. If you want > to build totally private versions of Audacity without proper > compatibility checks, then that is entirely your own business, but they > should not leave your machine. > > Version compatibility is far and away simplest by stating that versions > must match. Once you deviate from that you need both the host program > and the plugged in program to be able to check the version of the other > and reject it - and to have knowledge of the compatibility of versions. > When plugins depend on other plugins, and they will, it gets > complicated. Trying to code this kind of thing into the version number > is a quick route to insanity. > > At a later date we can be more sophisticated and version APIs and > subsets of APIs, including even APIs that 'look the same' but actually > behave differently - as the scripting interface is clearly in the > process of doing - see the discussion of 'generate tone'. If you want > that to happen sooner, then start a wiki Proposal page, and we can talk > through the options, and perhaps come up with a simple version that can > be used very soon. It won't be as simple a solution as you are hoping for. > > > --James. > > > > > > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |