vamp-devel — List for developers of Vamp plugins and hosts, and general technical discussion

Re: [Vamp-devel] Windows 11 Vamp Plugin Development

[Chris C. <ca...@al...>]

Hi there -

It's certainly still supported in the sense that it should still work! Nothing much has changed recently because, well, nothing much has changed.

I don't actually have Windows 11 currently - my only Windows computer was deemed ineligible for update by MS despite being a recent laptop of their own Surface brand (I'm still annoyed about that) - but I'm not aware of anything that should have broken it. 

The problem is that you can build a plugin dll, but it doesn't appear when checked with vamp-plugin-tester or vamp-simple-host?

This generally has one of two causes:

 * The plugin is not properly linked against a dependent library (such as the Vamp SDK), so the DLL can't be loaded at all, or

 * The plugin is loadable as a DLL but doesn't export the single C function call that is needed for the binary interface (see references in the docs to /EXPORT:vampGetPluginDescriptor)

The first can be checked in various ways, most comprehensively with a tool such as Dependency Walker (https://www.dependencywalker.com/).


Chris

On Wed, 25 Oct 2023, at 11:19, frogsniffa wrote:
> Hi,
>
> Is Vamp Plugin development for Windows 11 still supported? I'd love to 
> know this before I continue struggling with any builds. But the forums 
> and GitHub issues seem kind of dead.
>
> It seems the last commit for the SDK is a couple years old and same 
> with some of the testing executables. The documentation is great until 
> I get to the testing executables portion.
> Then, the executables run, but then they cannot detect any plugins even 
> after setting VAMP_PATH/VAMP_PATH32 or they just return without any 
> messages.
>
> In addition, the debug libs aren't included in the zips. Perhaps the 
> testing executables only work with the debug libs. My guess is that 
> I'll need to build the project myself in Visual Studio to get those.
>
> I'd appreciate any input! I'd also appreciate any 
> discords/zulips/matrixes on music information retrieval.

[Vamp-devel] Windows 11 Vamp Plugin Development

[frogsniffa <fro...@gm...>]

Hi,

Is Vamp Plugin development for Windows 11 still supported? I'd love to know
this before I continue struggling with any builds. But the forums and
GitHub issues seem kind of dead.

It seems the last commit for the SDK is a couple years old and same with
some of the testing executables. The documentation is great until I get to
the testing executables portion.
Then, the executables run, but then they cannot detect any plugins even
after setting VAMP_PATH/VAMP_PATH32 or they just return without any
messages.

In addition, the debug libs aren't included in the zips. Perhaps the
testing executables only work with the debug libs. My guess is that I'll
need to build the project myself in Visual Studio to get those.

I'd appreciate any input! I'd also appreciate any discords/zulips/matrixes
on music information retrieval.

[Vamp-devel] Realtime processing(newbie to Vamp Framework)

[Yetkin A. <yet...@gm...>]

Hello,

Normally I was developing plugins using Juce framework. I need to track tempo and noticed qm-tempotracker plugin is quite good at calculating tempo. 
I thought it’s a good idea to use Vamp Host Sdk to use any Vamp plugins in Vamp Plugin path. 
Using Host Sdk and Vamp Simple Host example, I could get plugin outputs, for a sound file loaded at the start of application and a single runPlugin function call.
I wonder if Vamp plugins has any limitations about real time analyzing. Is there any example about that which you can suggest?

I hope that it is suitable to ask this kind of question here. If not so, I apologize for that.

 Regards,
Yetkin

[Vamp-devel] Vamp development: Additional input .txt

[Manuel G. <gam...@gm...>]

Hi everybody,
I want to develop a Vamp plug-in for Sonic Visualiser by computing some
audio features on an "averaged spectrum" obtained by a temporal average of
the spectrum (bin by bin) between two onsets. For that I need to enter
manually the onset times (I want to avoid an automatic detection). So my
question is : is it possible to have an additional input (.txt for example)
apart from the signal ? I can't find any documentation about that.
Thank you for your help,
Manuel Gaulhiac

Re: [Vamp-devel] Downloads on vamp-plugins.org

[Chris C. <ca...@al...>]

Hi David, all --

Yes, I'm afraid the download site is currently down, apparently because of late running of emergency electrical works. I hope it will be up again shortly. 

As an ongoing process I would like to make downloads available from some other recognised file serving site, preferably one with a clear simple admin API (automatable would also be nice but is not vital). If you have any thoughts or preferences about this kind of service, I'd be glad to hear them.


Chris

On Mon, 12 Feb 2018, at 10:09, David Runge wrote:
> Hi!
> 
> I'm currently packaging a subset of things, that are hosted on
> vamp-plugins.org for Arch Linux (i.e. vamp-plugin-sdk,
> vamp-aubio-plugins, sonic-visualiser).
> 
> However, I have some things I'd like the maintainers and admins of said
> website to consider:
> 
> * please switch to https
> * please provide signed release tarballs
> * please provide parseable download links
> 
> While the first two requests prevent Man-in-the-middle (MITM) attacks,
> and can ensure, that whoever writes the software actually really
> released it and that the release tarball is unmodified, the latter is a
> mere best practice request for packaging:
> The links of each piece of software change not only by release but are
> arbitrarily chaotic (every new download provided updates the general
> folder structure for all downloads[1] [2]). This leads to at least two
> variables to be set on each package update and a constant cross-check on
> the website!
> 
> Additionally, the https download links are currently timing out!
> 
> 
> Best,
> David
> 
> [1] 
> https://code.soundsoftware.ac.uk/attachments/download/2206/vamp-plugin-sdk-2.7.1.tar.gz
> [2] 
> https://code.soundsoftware.ac.uk/attachments/download/2207/vamp-plugin-sdk-2.7.1.zip
> 
> -- 
> https://sleepmap.de
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Vamp-devel mailing list
> Vam...@li...
> https://lists.sourceforge.net/lists/listinfo/vamp-devel
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

[Vamp-devel] Downloads on vamp-plugins.org

[David R. <da...@sl...>]

Hi!

I'm currently packaging a subset of things, that are hosted on
vamp-plugins.org for Arch Linux (i.e. vamp-plugin-sdk,
vamp-aubio-plugins, sonic-visualiser).

However, I have some things I'd like the maintainers and admins of said
website to consider:

* please switch to https
* please provide signed release tarballs
* please provide parseable download links

While the first two requests prevent Man-in-the-middle (MITM) attacks,
and can ensure, that whoever writes the software actually really
released it and that the release tarball is unmodified, the latter is a
mere best practice request for packaging:
The links of each piece of software change not only by release but are
arbitrarily chaotic (every new download provided updates the general
folder structure for all downloads[1] [2]). This leads to at least two
variables to be set on each package update and a constant cross-check on
the website!

Additionally, the https download links are currently timing out!


Best,
David

[1] https://code.soundsoftware.ac.uk/attachments/download/2206/vamp-plugin-sdk-2.7.1.tar.gz
[2] https://code.soundsoftware.ac.uk/attachments/download/2207/vamp-plugin-sdk-2.7.1.zip

-- 
https://sleepmap.de

[Vamp-devel] Patch for cross-compiling

[Darrell W. <dar...@gm...>]

Hey, I have some changes from Audacity project for cross-compilation. I
think they will be easy to accept.

ranlib, ar, and pkg-config need to be queried for the host-specific
versions. After these patches you also need to generate a new configure.

Note these diffs are from 2.5 but I believe there is enough context to make
the changes.

Thanks,
Darrell


------------------------- lib-src/libvamp/Makefile.in
-------------------------
index 4fc9378..a547be6 100644
@@ -47,8 +47,8 @@ CXXFLAGS = -I. -I$(srcdir) @CXXFLAGS@ @SNDFILE_CFLAGS@

 # ar, ranlib
 #
-AR = ar
-RANLIB = ranlib
+AR = @AR@
+RANLIB = @RANLIB@

 # Libraries required for the plugins.
 #


------------------------- lib-src/libvamp/configure.ac
-------------------------
index 223f6f2..8adfc18 100644
@@ -3,10 +3,13 @@ AC_INIT(vamp-plugin-sdk, 2.5, ca...@al...
)

 AC_CONFIG_SRCDIR(vamp/vamp.h)
 AC_PROG_CXX
+AC_PROG_RANLIB
+AC_CHECK_TOOL([AR], [ar], [:])
+AC_CHECK_TOOL([PKG_CONFIG], [pkg-config], [:])
 AC_HEADER_STDC
 AC_C_BIGENDIAN

-if pkg-config --modversion vamp-sdk >/dev/null 2>&1; then
+if ${PKG_CONFIG} --modversion vamp-sdk >/dev/null 2>&1; then
   echo "WARNING: A version of the Vamp plugin SDK is already installed."
   echo "         Expect worries and sorrows if you install a new version"
   echo "         without removing the old one first.  (Continuing)"

[Vamp-devel] buggy libvamp-hostsdk.la preventing Audacity build

[Thomas O. <tho...@or...>]

Hi,

somehow the libtool files installed by vamp-plugin-sdk are broken, leading to

	libtool: link: `/usr/lib/libvamp-hostsdk.la' is not a valid libtool archive

when trying to link using libtool. This happens when trying to build
Audacity. This has been observed before and the usual solution is to
simply delete the .la file:

	https://bugs.launchpad.net/ubuntu/+source/vamp-plugin-sdk/+bug/1253656

Now I wonder if nobody approached the Vamp developer(s) about this and
here I am. I don't really have a clue what's broken with the .la file
here, but perhaps one insight would be to compare to a system that does
_not_ have the issue. Surely someone on this list built Audacity
recently with the Vamp plugins … ?

That's my .la file:

# cat /usr/lib/libvamp-hostsdk.la
dlname='libvamp-hostsdk.so.3'
library_names='libvamp-hostsdk.so.3.6.0 libvamp-hostsdk.so.3 libvamp-hostsdk.so'
old_library='libvamp-hostsdk.a'
dependency_libs=''
current=3
age=6
revision=0
installed=yes
libdir='/usr/lib'


Anyone got something different? Alternatively, a clue?


Alrighty then,

Thomas

Re: [Vamp-devel] Why plugin meta info is not provided by static methods?

[Chris C. <ca...@al...>]

[reawakening an old thread]

On Wed, Feb 26, 2014, at 12:43 PM, Chris Cannam wrote:
> On Tue, Feb 25, 2014, at 10:02 PM, Jakob Leben wrote:
> > I am wondering what are the reasons that plugin meta information like id,
> > name, description, parameters, etc. is requested via plugin instance
> > methods?
> [...]
> 
>  * Some of the data you might think of as static are actually dynamic --
>  for example, parameter value ranges may depend on the sample rate
>  provided when constructing the plugin.

I only realised this week (when trying to exploit this feature in a
plugin implementation) that I was totally mistaken about this. The API
is so seductive in its wrongness here that it had even misled me.

In the underlying binary interface (i.e. the interface defined in
vamp/vamp.h) parameter descriptors are completely static. They can't
depend on the sample rate. If you try to make a parameter depend on the
sample rate, for example to make a frequency range with an upper bound
at fs/2, you'll find it doesn't work -- on the host side, the parameters
will always come from a specialised instance of the plugin constructed
with sample rate equal to 48kHz.

Output descriptors are not static -- they can, and frequently do, depend
on the sample rate. Parameter descriptors can't.

Definitely a subject worth revisiting for a v3 revision of the API.


Chris

Re: [Vamp-devel] Why plugin meta info is not provided by static methods?

[Chris C. <ca...@al...>]

On Tue, Feb 25, 2014, at 10:02 PM, Jakob Leben wrote:
> I am wondering what are the reasons that plugin meta information like id,
> name, description, parameters, etc. is requested via plugin instance
> methods?
> 
> For this reason, Sonic Visualizer apparently instantiates each plugin at
> least once (without initialization), only to obtain meta info. I think it
> would really make sense to make those methods static instead.

An interesting question! I wouldn't say the answer was completely
cut-and-dried, but there are a few reasons:

 * First, note that the C++ headers don't describe the plugin API, they
 just provide a wrapper for it. The API is in C and is defined in
 vamp/vamp.h. So the question would be in two parts: would it be a good
 idea to include static data in the C API, and how should that be
 wrapped into the C++ API

 * Some of the data you might think of as static are actually dynamic --
 for example, parameter value ranges may depend on the sample rate
 provided when constructing the plugin. It would be possible to separate
 out data that must be static, but the division wouldn't be as obvious
 as you might hope, and this would result in two different mechanisms
 for providing "data about parameters" for example, which would
 complicate the object interface

 * As you mentioned in your followup, some plugins are dynamically
 generated (libxtract for example)

 * Static construction and initialisation order (especially in dynamic
 libraries) are common sources of programmer confusion and bugs

 * Finally -- what would the advantage be? Construction should be cheap,
 that's why initialise() is separate. The vast majority of the time
 taken to load and construct a plugin is spent in loading the dynamic
 library, and you can't query metadata without that unless the metadata
 is entirely external.


Chris

Re: [Vamp-devel] Why plugin meta info is not provided by static methods?

[Jakob L. <jak...@gm...>]

On Tue, Feb 25, 2014 at 2:02 PM, Jakob Leben <jak...@gm...> wrote:

> I am wondering what are the reasons that plugin meta information like id,
> name, description, parameters, etc. is requested via plugin instance
> methods?
>

Oh, I see one possible reason: generic wrapper plugins where meta info
differs among instances.
But then I would argue that it should rather be the user's responsibility
to provide meta info in a separate class - the plugin descriptor.

[Vamp-devel] Why plugin meta info is not provided by static methods?

[Jakob L. <jak...@gm...>]

Hello,

I am wondering what are the reasons that plugin meta information like id,
name, description, parameters, etc. is requested via plugin instance
methods?

For this reason, Sonic Visualizer apparently instantiates each plugin at
least once (without initialization), only to obtain meta info. I think it
would really make sense to make those methods static instead.

What do you think?

Best regards,
Jakob Leben

Re: [Vamp-devel] vamp-hostsdk, fftw3, and the GPL

[RJ R. <rr...@mi...>]

Hi Dan,

Yup, that's the plan. We're looking at using the Queen Mary beattracker
(among other QM tools) via VAMP.

Thanks,
RJ Ryan

On Mon, Nov 21, 2011 at 3:38 AM, Dan Stowell <dan...@ee...>wrote:

> Oh nice! You're using vamp for the beat tracker?
> https://blueprints.launchpad.net/mixxx/+spec/beat-tracking
>
> Mixxx is nice, and the simple bpm detector is handy. Will be interesting
> to see where this goes
>
> Dan
>
>
> On 19/11/11 21:10, RJ Ryan wrote:
> > Ahh -- thanks for the clarification and sorry I did not see that comment.
> >
> > No, we (Mixxx, GPL DJ software) haven't shipped binaries with VAMP
> > support yet -- though we will in our next major release. :)
> >
> > Though, since we are already GPL this would not be a problem for us.
> > ction
> > I was mostly confused about how the hostsdk could be BSD with FFTW
> > included, but I guess the answer is that you don't distribute binaries
> > with FFTW support enabled.
> >
> > Thanks,
> > RJ Ryan
> >
> > On Sat, Nov 19, 2011 at 4:00 PM, Chris Cannam
> > <ca...@al... <mailto:ca...@al...>>
> wrote:
> >
> >     On 19 November 2011 20:51, RJ Ryan <rr...@mi...
> >     <mailto:rr...@mi...>> wrote:
> >      > I have a question about the optional FFTW3 support in the Vamp
> >     hostsdk. If
> >      > you compile the hostsdk with HAVE_FFTW3 and link in fftw3,
> >     wouldn't that
> >      > necessitate licensing the host-sdk under the GPL?
> >
> >     If you compile the hostsdk with HAVE_FFTW3, link in fftw3, and
> >     redistribute the results, then yes, you would have to comply with the
> >     licence of FFTW3 by licensing your distribution under the GPL.
> >
> >     That doesn't affect the terms under which the Vamp SDK are licensed
> to
> >     you, it's simply a practical consequence of having to comply with the
> >     licences of all of the libraries you use.
> >
> >     Avoiding this sort of complication is why HAVE_FFTW3 isn't defined by
> >     default and why there is no configure flag for it in the Vamp SDK.
> >
> >     See also the comment in PluginInputDomainAdapter.cpp:
> >
> >       * If you want to compile using FFTW instead of the built-in FFT
> >       * implementation for the PluginInputDomainAdapter, define
> HAVE_FFTW3
> >       * in the Makefile.
> >       *
> >       * Be aware that FFTW is licensed under the GPL -- unlike this SDK,
> >       * which is provided under a more liberal BSD license in order to
> >       * permit use in closed source applications.  The use of FFTW would
> >       * mean that your code would need to be licensed under the GPL as
> >       * well.  Do not define this symbol unless you understand and accept
> >       * the implications of this.
> >
> >     May I ask why you're asking?  (Have I made a binary distribution of
> >     the SDK that uses FFTW3 by accident, for example?)
> >
> >
> >     Chris
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity, and more. Splunk takes this
> > data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-novd2d
> >
> >
> >
> > _______________________________________________
> > Vamp-devel mailing list
> > Vam...@li...
> > https://lists.sourceforge.net/lists/listinfo/vamp-devel
>
> --
> Dan Stowell
> Postdoctoral Research Assistant
> Centre for Digital Music
> Queen Mary, University of London
> Mile End Road, London E1 4NS
> http://www.elec.qmul.ac.uk/digitalmusic/people/dans.htm
> http://www.mcld.co.uk/
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Vamp-devel mailing list
> Vam...@li...
> https://lists.sourceforge.net/lists/listinfo/vamp-devel
>

Re: [Vamp-devel] vamp-hostsdk, fftw3, and the GPL

[Dan S. <dan...@ee...>]

Oh nice! You're using vamp for the beat tracker?
https://blueprints.launchpad.net/mixxx/+spec/beat-tracking

Mixxx is nice, and the simple bpm detector is handy. Will be interesting 
to see where this goes

Dan


On 19/11/11 21:10, RJ Ryan wrote:
> Ahh -- thanks for the clarification and sorry I did not see that comment.
>
> No, we (Mixxx, GPL DJ software) haven't shipped binaries with VAMP
> support yet -- though we will in our next major release. :)
>
> Though, since we are already GPL this would not be a problem for us.
> ction
> I was mostly confused about how the hostsdk could be BSD with FFTW
> included, but I guess the answer is that you don't distribute binaries
> with FFTW support enabled.
>
> Thanks,
> RJ Ryan
>
> On Sat, Nov 19, 2011 at 4:00 PM, Chris Cannam
> <ca...@al... <mailto:ca...@al...>> wrote:
>
>     On 19 November 2011 20:51, RJ Ryan <rr...@mi...
>     <mailto:rr...@mi...>> wrote:
>      > I have a question about the optional FFTW3 support in the Vamp
>     hostsdk. If
>      > you compile the hostsdk with HAVE_FFTW3 and link in fftw3,
>     wouldn't that
>      > necessitate licensing the host-sdk under the GPL?
>
>     If you compile the hostsdk with HAVE_FFTW3, link in fftw3, and
>     redistribute the results, then yes, you would have to comply with the
>     licence of FFTW3 by licensing your distribution under the GPL.
>
>     That doesn't affect the terms under which the Vamp SDK are licensed to
>     you, it's simply a practical consequence of having to comply with the
>     licences of all of the libraries you use.
>
>     Avoiding this sort of complication is why HAVE_FFTW3 isn't defined by
>     default and why there is no configure flag for it in the Vamp SDK.
>
>     See also the comment in PluginInputDomainAdapter.cpp:
>
>       * If you want to compile using FFTW instead of the built-in FFT
>       * implementation for the PluginInputDomainAdapter, define HAVE_FFTW3
>       * in the Makefile.
>       *
>       * Be aware that FFTW is licensed under the GPL -- unlike this SDK,
>       * which is provided under a more liberal BSD license in order to
>       * permit use in closed source applications.  The use of FFTW would
>       * mean that your code would need to be licensed under the GPL as
>       * well.  Do not define this symbol unless you understand and accept
>       * the implications of this.
>
>     May I ask why you're asking?  (Have I made a binary distribution of
>     the SDK that uses FFTW3 by accident, for example?)
>
>
>     Chris
>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
>
>
>
> _______________________________________________
> Vamp-devel mailing list
> Vam...@li...
> https://lists.sourceforge.net/lists/listinfo/vamp-devel

-- 
Dan Stowell
Postdoctoral Research Assistant
Centre for Digital Music
Queen Mary, University of London
Mile End Road, London E1 4NS
http://www.elec.qmul.ac.uk/digitalmusic/people/dans.htm
http://www.mcld.co.uk/

Re: [Vamp-devel] vamp-hostsdk, fftw3, and the GPL

[RJ R. <rr...@mi...>]

Ahh -- thanks for the clarification and sorry I did not see that comment.

No, we (Mixxx, GPL DJ software) haven't shipped binaries with VAMP support
yet -- though we will in our next major release. :)

Though, since we are already GPL this would not be a problem for us.

I was mostly confused about how the hostsdk could be BSD with FFTW
included, but I guess the answer is that you don't distribute binaries with
FFTW support enabled.

Thanks,
RJ Ryan

On Sat, Nov 19, 2011 at 4:00 PM, Chris Cannam
<ca...@al...>wrote:

> On 19 November 2011 20:51, RJ Ryan <rr...@mi...> wrote:
> > I have a question about the optional FFTW3 support in the Vamp hostsdk.
> If
> > you compile the hostsdk with HAVE_FFTW3 and link in fftw3, wouldn't that
> > necessitate licensing the host-sdk under the GPL?
>
> If you compile the hostsdk with HAVE_FFTW3, link in fftw3, and
> redistribute the results, then yes, you would have to comply with the
> licence of FFTW3 by licensing your distribution under the GPL.
>
> That doesn't affect the terms under which the Vamp SDK are licensed to
> you, it's simply a practical consequence of having to comply with the
> licences of all of the libraries you use.
>
> Avoiding this sort of complication is why HAVE_FFTW3 isn't defined by
> default and why there is no configure flag for it in the Vamp SDK.
>
> See also the comment in PluginInputDomainAdapter.cpp:
>
>  * If you want to compile using FFTW instead of the built-in FFT
>  * implementation for the PluginInputDomainAdapter, define HAVE_FFTW3
>  * in the Makefile.
>  *
>  * Be aware that FFTW is licensed under the GPL -- unlike this SDK,
>  * which is provided under a more liberal BSD license in order to
>  * permit use in closed source applications.  The use of FFTW would
>  * mean that your code would need to be licensed under the GPL as
>  * well.  Do not define this symbol unless you understand and accept
>  * the implications of this.
>
> May I ask why you're asking?  (Have I made a binary distribution of
> the SDK that uses FFTW3 by accident, for example?)
>
>
> Chris
>

Re: [Vamp-devel] vamp-hostsdk, fftw3, and the GPL

[Chris C. <ca...@al...>]

On 19 November 2011 20:51, RJ Ryan <rr...@mi...> wrote:
> I have a question about the optional FFTW3 support in the Vamp hostsdk. If
> you compile the hostsdk with HAVE_FFTW3 and link in fftw3, wouldn't that
> necessitate licensing the host-sdk under the GPL?

If you compile the hostsdk with HAVE_FFTW3, link in fftw3, and
redistribute the results, then yes, you would have to comply with the
licence of FFTW3 by licensing your distribution under the GPL.

That doesn't affect the terms under which the Vamp SDK are licensed to
you, it's simply a practical consequence of having to comply with the
licences of all of the libraries you use.

Avoiding this sort of complication is why HAVE_FFTW3 isn't defined by
default and why there is no configure flag for it in the Vamp SDK.

See also the comment in PluginInputDomainAdapter.cpp:

 * If you want to compile using FFTW instead of the built-in FFT
 * implementation for the PluginInputDomainAdapter, define HAVE_FFTW3
 * in the Makefile.
 *
 * Be aware that FFTW is licensed under the GPL -- unlike this SDK,
 * which is provided under a more liberal BSD license in order to
 * permit use in closed source applications.  The use of FFTW would
 * mean that your code would need to be licensed under the GPL as
 * well.  Do not define this symbol unless you understand and accept
 * the implications of this.

May I ask why you're asking?  (Have I made a binary distribution of
the SDK that uses FFTW3 by accident, for example?)


Chris

[Vamp-devel] vamp-hostsdk, fftw3, and the GPL

[RJ R. <rr...@mi...>]

Hi all,

I have a question about the optional FFTW3 support in the Vamp hostsdk. If
you compile the hostsdk with HAVE_FFTW3 and link in fftw3, wouldn't that
necessitate licensing the host-sdk under the GPL?

Best regards,
RJ Ryan

Re: [Vamp-devel] Mac makefile issue

[Dan S. <dan...@el...>]

On 30/06/2010 15:44, Chris Cannam wrote:
> On Wed, Jun 30, 2010 at 11:11 AM, Dan Stowell
> <dan...@el...>  wrote:
>> I know what the error means but I haven't spotted why I'm failing to
>> tell ld to build a DLL. The makefile is derived from the Vamp SDK one
>> but what is the glaring error?
>
> That's a nice little puzzle.  It took me a moment to see why none of
> the $(PLUGIN_LDFLAGS) appeared to be used.
>
> The reason is that your $(PLUGIN_OBJECTS) target lacks the -c option
> to g++, so it is trying to do a complete compile and link to an
> executable (which will be named with a .o extension, but which will be
> a complete executable rather than a single object file) instead of
> just compiling the single source file.
>
> btw, that rule won't work if $(PLUGIN_OBJECTS) contains more than one
> object file either.  You probably don't really want to write it that
> way -- either define an implicit rule or just have a dependency on an
> object and let GNU make figure out the compile rule for you (it will
> use your CXXFLAGS and CXX variables)..

Great, thanks, that fixes it.

Dan

Re: [Vamp-devel] Mac makefile issue

[Chris C. <ca...@al...>]

On Wed, Jun 30, 2010 at 11:11 AM, Dan Stowell
<dan...@el...> wrote:
> I know what the error means but I haven't spotted why I'm failing to
> tell ld to build a DLL. The makefile is derived from the Vamp SDK one
> but what is the glaring error?

That's a nice little puzzle.  It took me a moment to see why none of
the $(PLUGIN_LDFLAGS) appeared to be used.

The reason is that your $(PLUGIN_OBJECTS) target lacks the -c option
to g++, so it is trying to do a complete compile and link to an
executable (which will be named with a .o extension, but which will be
a complete executable rather than a single object file) instead of
just compiling the single source file.

btw, that rule won't work if $(PLUGIN_OBJECTS) contains more than one
object file either.  You probably don't really want to write it that
way -- either define an implicit rule or just have a dependency on an
object and let GNU make figure out the compile rule for you (it will
use your CXXFLAGS and CXX variables)..


Chris

[Vamp-devel] Mac makefile issue

[Dan S. <dan...@el...>]

Hi -

I've written a new little vamp plugin but am having a spot of trouble 
with the build. My makefile is here <http://pastebin.com/XBPWQ6Zr> and 
the rather clichéd output is:

g++  -O2 -Wall -I. -fPIC -o segger1.o 
-I/Users/danstowell/dev/vamp-plugin-sdk-2.1 ./segger1.cpp
/usr/bin/ld: Undefined symbols:
_main
collect2: ld returned 1 exit status
make: *** [segger1.o] Error 1


I know what the error means but I haven't spotted why I'm failing to 
tell ld to build a DLL. The makefile is derived from the Vamp SDK one 
but what is the glaring error?

Thanks
Dan

-- 
Dan Stowell
Centre for Digital Music
School of Electronic Engineering and Computer Science
Queen Mary, University of London
Mile End Road, London E1 4NS
http://www.elec.qmul.ac.uk/department/staff/research/dans.htm
http://www.mcld.co.uk/

Re: [Vamp-devel] Portability patches languishing in SourceForge tracker

[Chris C. <ca...@al...>]

On Mon, Jun 7, 2010 at 4:10 PM, Michel Alexandre Salim
<mic...@gm...> wrote:
> From what you describes, it looks like the culprit is in the configure
> script -- libdir defaults to ${exec_prefix}/lib (line 734) and that
> expands to /lib unless exec_prefix is overridden.
>
> The correct fix would be in configure.ac, and then configure will be
> regenerated from it, but I'm not the autotools expert so I'm not
> exactly sure how to specify the default there.

Right, I see.  I'm not in any way an autoconf expert either -- my
knowledge of it is basically completely "cargo-culted".  I can fiddle
about with it, but if you or any other reader could come up with a
working patch that would be very handy.


Chris

Re: [Vamp-devel] Portability patches languishing in SourceForge tracker

[Michel A. S. <mic...@gm...>]

Hi Chris,

On Mon, Jun 7, 2010 at 4:10 PM, Chris Cannam
<ca...@al...> wrote:
> On Thu, Jun 3, 2010 at 5:59 PM, Michel Alexandre Salim
> <mic...@gm...> wrote:
>> There are some patches sitting in the project's SF patch tracker --
>> two addressing hard-coded libdir (this fails on multilib RPM-based
>> distributions, e.g. Fedora and openSUSE, where on 64-bit architectures
>> libdir = $(PREFIX)/lib64 not $(PREFIX)/lib, and one addressing header
>> fixes needed by newer GCC compilers.
>>
>> Could this be looked into? I'd then be able to drop the two patches
>> that Fedora is carrying to work around the issues.
>
> Michel,
>
> Thanks for the note -- I'm sorry, I do have trouble sometimes keeping
> track of all the different trackers!
>
> The gcc 4.4 patch for FixedTempoEstimator I was very slow to pick up,
> but it is actually in SVN since revision 1101.  The problem is that I
> haven't actually done a release since then.  There are a couple of
> other small changes that could merit a point release.
>
> The libdir patch puzzles me -- on this system all it seems to do is
> cause the install to ignore my prefix setting and try to install the
> libraries beneath /lib instead, which seems dangerously wrong to me.
> What am I missing here?  I'm happy to apply a fix, I just don't quite
> understand what fix!
>
@libdir@ is one of the values that's replaced by the value passed to
configure using the --libdir flag. I apologize for the incompleteness
of the patch -- you'd want to specify a sane default. On RPM-based
Linux systems, we normally use a pre-defined macro, %configure, that
passes the standard --prefix, --libdir, etc.

>From what you describes, it looks like the culprit is in the configure
script -- libdir defaults to ${exec_prefix}/lib (line 734) and that
expands to /lib unless exec_prefix is overridden.

The correct fix would be in configure.ac, and then configure will be
regenerated from it, but I'm not the autotools expert so I'm not
exactly sure how to specify the default there.

Thanks,

-- 
Michel
>
> Chris
>

Re: [Vamp-devel] Portability patches languishing in SourceForge tracker

[Chris C. <ca...@al...>]

On Thu, Jun 3, 2010 at 5:59 PM, Michel Alexandre Salim
<mic...@gm...> wrote:
> There are some patches sitting in the project's SF patch tracker --
> two addressing hard-coded libdir (this fails on multilib RPM-based
> distributions, e.g. Fedora and openSUSE, where on 64-bit architectures
> libdir = $(PREFIX)/lib64 not $(PREFIX)/lib, and one addressing header
> fixes needed by newer GCC compilers.
>
> Could this be looked into? I'd then be able to drop the two patches
> that Fedora is carrying to work around the issues.

Michel,

Thanks for the note -- I'm sorry, I do have trouble sometimes keeping
track of all the different trackers!

The gcc 4.4 patch for FixedTempoEstimator I was very slow to pick up,
but it is actually in SVN since revision 1101.  The problem is that I
haven't actually done a release since then.  There are a couple of
other small changes that could merit a point release.

The libdir patch puzzles me -- on this system all it seems to do is
cause the install to ignore my prefix setting and try to install the
libraries beneath /lib instead, which seems dangerously wrong to me.
What am I missing here?  I'm happy to apply a fix, I just don't quite
understand what fix!


Chris

[Vamp-devel] Portability patches languishing in SourceForge tracker

[Michel A. S. <mic...@gm...>]

Hi Chris,

There are some patches sitting in the project's SF patch tracker --
two addressing hard-coded libdir (this fails on multilib RPM-based
distributions, e.g. Fedora and openSUSE, where on 64-bit architectures
libdir = $(PREFIX)/lib64 not $(PREFIX)/lib, and one addressing header
fixes needed by newer GCC compilers.

Could this be looked into? I'd then be able to drop the two patches
that Fedora is carrying to work around the issues.

Thanks,

-- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  sa...@fe...  | GPG key ID: 78884778
Jabber: hi...@ja...       | IRC: hi...@ir...

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

[Vamp-devel] Vamp plugin SDK v2.1 now available

[Chris C. <ca...@al...>]

Version 2.1 of the Vamp plugin SDK is now available.

 http://www.vamp-plugins.org/

Vamp is a plugin API for audio analysis and feature extraction plugins written
in C or C++.  Its SDK features an easy-to-use set of C++ classes for plugin
and host developers, a reference host implementation, example plugins, and
documentation.  It is supported across Linux, OS/X, Windows, and Solaris.

A documentation guide to writing plugins using the Vamp SDK can be found at
http://www.vamp-plugins.org/guide.pdf.

Version 2.1 is a maintenance release which contains a number of bug fixes
and a new set of skeleton source code files for use by plugin developers.
All of the fixes are relevant to host code only: there is no need to recompile
or re-link any plugins that have been linked with 2.0 against the new release.


Chris