vamp-devel Mailing List for Vamp audio analysis plugin API
Brought to you by:
cannam
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(8) |
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(3) |
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
|
| 2014 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: Chris C. <ca...@al...> - 2023-10-26 09:10:59
|
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. |
|
From: frogsniffa <fro...@gm...> - 2023-10-25 06:19:53
|
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. |
|
From: Yetkin A. <yet...@gm...> - 2023-05-21 11:33:53
|
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 |
|
From: Manuel G. <gam...@gm...> - 2021-05-16 12:02:29
|
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 |
|
From: Chris C. <ca...@al...> - 2018-02-12 11:58:19
|
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) |
|
From: David R. <da...@sl...> - 2018-02-12 10:09:59
|
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 |
|
From: Darrell W. <dar...@gm...> - 2017-03-23 21:02:58
|
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)"
|
|
From: Thomas O. <tho...@or...> - 2016-01-01 16:49:18
|
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 |
|
From: Chris C. <ca...@al...> - 2014-07-13 14:32:32
|
[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 |
|
From: Chris C. <ca...@al...> - 2014-02-26 11:43:11
|
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 |
|
From: Jakob L. <jak...@gm...> - 2014-02-25 22:09:48
|
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. |
|
From: Jakob L. <jak...@gm...> - 2014-02-25 22:02:37
|
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 |
|
From: RJ R. <rr...@mi...> - 2011-11-21 15:17:42
|
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 > |
|
From: Dan S. <dan...@ee...> - 2011-11-21 08:38:50
|
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/ |
|
From: RJ R. <rr...@mi...> - 2011-11-19 21:11:25
|
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 > |
|
From: Chris C. <ca...@al...> - 2011-11-19 21:00:40
|
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 |
|
From: RJ R. <rr...@mi...> - 2011-11-19 20:51:49
|
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 |
|
From: Dan S. <dan...@el...> - 2010-06-30 16:19:08
|
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 |
|
From: Chris C. <ca...@al...> - 2010-06-30 15:13:14
|
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 |
|
From: Dan S. <dan...@el...> - 2010-06-30 10:28:13
|
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/ |
|
From: Chris C. <ca...@al...> - 2010-06-07 15:14:54
|
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
|
|
From: Michel A. S. <mic...@gm...> - 2010-06-07 15:10:42
|
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
>
|
|
From: Chris C. <ca...@al...> - 2010-06-07 14:10:16
|
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 |
|
From: Michel A. S. <mic...@gm...> - 2010-06-03 16:59:36
|
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 |
|
From: Chris C. <ca...@al...> - 2009-09-25 16:16:55
|
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 |