Re: [LAD] [ann] CAPS 0.4.5
[Jeff McClintock] >What happens when you modify version-1 of your plugin and remove a port >(making Version2), then later re-add a new (unrelated) port with different >semantics? (Version 3)... Then load a project created with version 1. > > Does the host in THIS situation set the new port to it's default value, I >doubt it. More likely it 'restores' it to some invalid setting. > >Do you want a fragile, crash-prone, plugin ecosystem?, or a robust one? The plugins in CAPS clamp all control inputs to the valid range. Whatever the host sends, including inf and nan, there is no "invalid" setting. Moreover, the plugins will not crash even if run without connecting their control ports at all. The above experiment, by the way, is exactly what I did, and it did not cause any abnormal behaviour: no crash, no segfault, no bus error, no assertion failure in any part of the executed code; no inf or nan, not even a single sample value of or in excess of 1f absolute in the audio output. I think your fear of a fragile and crash-prone plugin ecosystem is unfounded and exaggerated. >I Agree with Paul on this one. I can very well see how a host author would want plugin port signatures to be stable, and I was never happy about invalidating this assumption. However, the evolved plugin doesn't even break ardour or its session files, so the pragmatic thing is to just get on with it and not waste as much breath on a triviality like this as we do now. Cheers, Tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
> An informal experiment shows that jack-rack 1.4.7 and ardour 2.8.11 > both do exactly the right thing when a plugin referenced by a saved > session gains a port: they set the new port to its default value and > happily carry on working. > > (Both also cope with the removal of a port. These are the only > publicly available hosts I have tested.) What happens when you modify version-1 of your plugin and remove a port (making Version2), then later re-add a new (unrelated) port with different semantics? (Version 3)... Then load a project created with version 1. Does the host in THIS situation set the new port to it's default value, I doubt it. More likely it 'restores' it to some invalid setting. Do you want a fragile, crash-prone, plugin ecosystem?, or a robust one? I Agree with Paul on this one. Best Regards, Jeff ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
[Robin Gareus] >On Apr 10, 2011, at 3:52 PM, Tim Goetze wrote: >> >> Surely you will understand that I'm not inclined to maintain two >> versions of a plugin whose code differs in only one line. >> > >That sounds like a good case of an #ifdef, no? Just generate two >plugins from the same code: old one: unchanged; updated version: new >UniqueID. Thanks Robin, while this is of course entirely viable and not unreasonable, unfortunately I see two problems: besides the code, there are also differences in the data describing the plugin that would need to be put inside conditionals, and that is not as handily concentrated into one line as is the case with the code. And to be quite honest, smart adhoc solutions like these create exactly the kind of source code that I don't want to have to maintain. :D Cheers, Tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On Apr 10, 2011, at 3:52 PM, Tim Goetze wrote: > [Paul Davis] >> On Sun, Apr 10, 2011 at 3:43 AM, Tim Goetze wrote: >>> Following your suggestion and changing the plugin's UniqueID would >>> break perfectly good saved session files in these and other properly >>> designed host applications - instead of *preventing* breakage, it'd >>> actually *cause* it. >> >> Strongly disagree. The CAPS package would just continue to include the >> old version of the plugin. > > Surely you will understand that I'm not inclined to maintain two > versions of a plugin whose code differs in only one line. > That sounds like a good case of an #ifdef, no? Just generate two plugins from the same code: old one: unchanged; updated version: new UniqueID. just an idea.. robin ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
[Paul Davis] >On Sun, Apr 10, 2011 at 3:43 AM, Tim Goetze wrote: >> Following your suggestion and changing the plugin's UniqueID would >> break perfectly good saved session files in these and other properly >> designed host applications - instead of *preventing* breakage, it'd >> actually *cause* it. > >Strongly disagree. The CAPS package would just continue to include the >old version of the plugin. Surely you will understand that I'm not inclined to maintain two versions of a plugin whose code differs in only one line. However, as a compromise, I am thinking about moving obsolete plugins into a separate 'abandoned' package that would not enjoy further maintenance. It's far from an ideal solution but then again nothing seems to be. >You can't fix this in Ardour in general. As noted, just appending a >port won't break anything (I think), but the general issue that the >port signature has changed and this invalidates old state for the >plugin is something that definitely goes against everything that we >had in mind when LADSPA was designed. In that case, it is rather unfortunate that the specification bears not a trace of your thoughts on this matter. Perhaps you want to make an effort to fix it? Cheers, Tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
On Sun, Apr 10, 2011 at 3:43 AM, Tim Goetze wrote: > Adding a port doesn't break the *plugin*, it /might/ break *hosts* > that were designed around assumptions that aren't supported by the > interface specification. Strongly disagree. There are ways to add a port that won't do this, but there are plenty of ways to do it that will. > Following your suggestion and changing the plugin's UniqueID would > break perfectly good saved session files in these and other properly > designed host applications - instead of *preventing* breakage, it'd > actually *cause* it. Strongly disagree. The CAPS package would just continue to include the old version of the plugin. > If your particular LADSPA host design is incapable of handling a port > signature change gracefully, you could fix it - an endeavour I'll be > happy to help with, witness the discussed version symbol export - or > you can simply choose not to upgrade your copy of CAPS. You can't fix this in Ardour in general. As noted, just appending a port won't break anything (I think), but the general issue that the port signature has changed and this invalidates old state for the plugin is something that definitely goes against everything that we had in mind when LADSPA was designed. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] [LAA] [ANN] guitarix update release gx_head-0.14.0
gx_head is a simple guitar mono tube amplifier simulation based on the work we have done in the guitarix project. gx_head provide different tube models and tonestack models, so you can simply adjust the amp-model to your needs. gx_head comes with a bunch of in-build effects, like distortion, crybaby, autowah, phaser, flanger, echo, delay, . . . The effects could ordered in two Racks, on for the mono effects, witch could be load for pre or post processing, and one for the stereo effects, witch could only used in post processing. Effects are loadable over the menu, a pop-up menu in the racks, or a plugin bar. Settings could saved/load as presets. gx_head comes with some factory settings provided by guitarix/gx_head friends "funkmuscle", "zettberlin" and "StudioDave" thanks therefore. All UI controllers could connected over jack midi via MIDI learn with your external MIDI controllers. gx_head is comes, thanks to Pablo Fernández with Spanish , Ivan Tarozzi with Italian, jy with French translation. Thanks to the new project member Pete Shorthose we could fix a old Bug in libgxw/gxwmm related to 64 bit systems, also Pete have add animation support for knobs in libgxw/gxwmm. new features in short: * add tube 6DJ8 * add clean tube modes * reworked drive controller (bypass <-> wet) * add clipper * add mono level controller * add French translation by jy * add TACTILE skin by Pete Shorthose * add knob animation support by Pete Shorthose * add new knob images by Pete Shorthose * add new switch images by Pete Shorthose * fix 64bit related bug in libgxw by Pete Shorthose * add factory settings by Dave Phillips * add 3band EQ + sharper * add tremolo by transmogrifox (Rakarrack) have fun _ gx_head is licensed under the GPL. screen-shots and sound examples: http://sourceforge.net/apps/wordpress/guitarix/ direct download: http://sourceforge.net/projects/guitarix/files/gx_head/gx_head-0.14.0.tar.bz2/download download site: http://sourceforge.net/projects/guitarix/ please report bugs and suggestions in our forum: http://sourceforge.net/apps/phpbb/guitarix/ For extra Impulse Responses, gx_head uses the zita-convolver library, and, for resampling we use zita-resampler, both written by Fons Adriaensen. http://kokkinizita.linuxaudio.org/linuxaudio/index.html We use the marvellous faust compiler to build the amp and effects and will say thanks to : Julius Smith http://ccrma.stanford.edu/realsimple/faust/ : Albert Graef http://q-lang.sourceforge.net/examples.html#Faust : Yann Orlary http://faust.grame.fr/ For faust users : All used Faust dsp files are included in /gx_head/src/faust, the resulting .cc files are in /gx_head/src/faust-generated The tools we use to convert (post-processing and plot) the resulting faust cpp files to the needed include format, stay in the /gx_head/tools directory. regards guitarix development team ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] CAPS 0.4.5
[David Robillard] > On 07/04/11 01:00 PM, Tim Goetze wrote: >> The new port for the AutoWah plugin will indeed be appended to the >> list of input ports; however, it will still precede the audio output, >> adhering to the CAPS port order convention which puts inputs before >> outputs. >> > This will horribly break all sorts of things. Do not do this! Admittedly, > slightly less so than rearranging control port indices would (which would > definitely break virtually everything), but still. I'm afraid you generously overestimate the popularity of CAPS and the AutoWah plugin in particular expecting this change to break "all sorts of things". And you seem to underestimate the ability of your fellow host application designers, as we shall see in a bit. > You should just change the ID of the plugin and this whole mess goes away. I > can't think of any reason to keep the ID and break the plugin rather than just > change the ID... Adding a port doesn't break the *plugin*, it /might/ break *hosts* that were designed around assumptions that aren't supported by the interface specification. An informal experiment shows that jack-rack 1.4.7 and ardour 2.8.11 both do exactly the right thing when a plugin referenced by a saved session gains a port: they set the new port to its default value and happily carry on working. (Both also cope with the removal of a port. These are the only publicly available hosts I have tested.) Following your suggestion and changing the plugin's UniqueID would break perfectly good saved session files in these and other properly designed host applications - instead of *preventing* breakage, it'd actually *cause* it. If your particular LADSPA host design is incapable of handling a port signature change gracefully, you could fix it - an endeavour I'll be happy to help with, witness the discussed version symbol export - or you can simply choose not to upgrade your copy of CAPS. [Paul Coccoli] > And name it AutoFilter...like the Maxon AF-9 Auto Filter... Yeah, with the added filter mode switch this name makes sense. Looking at the AF-9 it seems there's demand for a hi-pass mode as well, so we might as well add that too. Cheers, Tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
