Vaughan and Ed have been in touch with me about this, and Vaughan has suggested we might add Ed's ideas to bug 55. I should have given some explanation, but was trying to save time/words.

The reason I dismissed this rather summarily was that this bug as worded contradicts bug 55, so the two bugs can't really coexist together. LV2 was a significant part of GSoC 2008 even though the work was left unfinished:
http://wiki.audacityteam.org/wiki/LV2_Support

So I presume some effort will eventually be put into making it compile.  

Also although Ed has told me that every time he compiles SVN HEAD on Windows he has to remove all four slv2 solutions before Audacity will compile, building slv2 seems to be disabled by default on Windows, so it shouldn't be a practical issue. The issue is release noted (for Windows). If we removed slv2 then fix bug 55, it just seems to make work to add it back. 

Looking at Linux, r8487 removed the following from configure back in 2009, which I hadn't realised: 
 --with-redland          use Redland for reading RDF data
 --with-slv2             use SLV2 for loading LV2 plugins
 --with-liblrdf          use liblrdf for categorisation of LADSPA plugins

However libslv2 is in /mac/Audacity.xcodeproj/project.pbxproj so I assume it actually builds there?  

So in summary, removing slv2 from SVN doesn't seem appropriate to me, action on Windows doesn't seem vital and I'm not clear whether any action is needed on Mac or not. Comments more than welcome.

then how about removing it from sln only--leave it in SVN

(In reply to comment #2)
> then how about removing it from sln only--leave it in SVN

Ed, when you build Audacity, do you happen to do a "Build -> Batch build", click "Select All", then then click "Build"?

Leland

(In reply to comment #1)
> However libslv2 is in /mac/Audacity.xcodeproj/project.pbxproj so I assume it
> actually builds there?  
> 
> So in summary, removing slv2 from SVN doesn't seem appropriate to me, action on
> Windows doesn't seem vital and I'm not clear whether any action is needed on
> Mac or not. Comments more than welcome.

The library is part of the Xcode project, but it is not built.

If it matters, I would agree with removing the use of the 3 libraries in question from the project/solution files and from SVN.  Last time I tried getting it to work on Windows (during the GSoC), I stopped a ways into it since it was getting out of hand.

I'd leave the Audacity specific SLV2 code in "src" as a "reminder".  I'd also suggest that, if SLV2 support is desired, then it be readdressed as an external effect module in the post-2.0 releases.

But, that's just my opinion...

(In reply to comment #4)
> If it matters, I would agree with removing the use of the 3 libraries in
> question from the project/solution files and from SVN.  Last time I tried
> getting it to work on Windows (during the GSoC), I stopped a ways into it since
> it was getting out of hand.
> 
It's over 70MB of unused source code...

(In reply to comment #1)
> Looking at Linux, r8487 removed the following from configure back in 2009,
> which I hadn't realised: 
>  --with-redland          use Redland for reading RDF data
>  --with-slv2             use SLV2 for loading LV2 plugins
>  --with-liblrdf          use liblrdf for categorisation of LADSPA plugins
> 
> However libslv2 is in /mac/Audacity.xcodeproj/project.pbxproj so I assume it
> actually builds there?  
> 
I've just removed them from the Xcode project as well since they depended on the configure stuff, so they would not longer build anyway.

(In reply to comment #3)
Leland asked "...do you happen to do a "Build -> Batch build",
click "Select All", then then click "Build"?"

Yes, but...

Once a day (but only if there has been a commit) I grab a new SVN HEAD and "test build" all four configurations. I do find "does not compile" problems this way and generally go straight to the author of the offending commit if I can pinpoint the problem.

When I am working on something specific I grab a new SVN HEAD then I load the solution (change from the default (non-Unicode) Debug config to Unicode Debug) and build just that solution.

I see today it has been removed from the Mac stuff (XCode is Mac right?). Its been gone from Linux for years. Why do the Windows folks need to was bandwidth & compile time on this.

Please consider re-evaluating the "Invalid" designation! Zip the slv2 source code up and hide it on the server with some note in the readme for historical purposes.

(In reply to comment #7)

I had just marked bug 55 as "(Windows and OS X) The slv2 library needed for LV2 support is included in the project files but will not compile" but now it's been removed from the Mac project, it reads "The slv2 library needed for LV2 support will not compile on any platforms but is currently included in the Windows project files and in the source code."

@Ed, out of interest, I would still assume when you batch build that you could select the projects to build, then until you do a fresh checkout, that build selection persists?
 
I think the issue was the description in Bug 55 which suggested it was a Windows only problem. DanH had reported that he had got slv2 to build on Linux and no-one had contradicted that or updated the bug to reflect that the three libs had actually been removed from configure. 

Clearly now Mac has the libs removed from the project they should be removed from Windows too for consistency.     

Again the reason for the "Invalid" was the somewhat presumptuous "un-needed" title in the bug. I've reopened this as "remove slv2, redland and liblrdf from source code?" but we should decide what we aim to do with LV2 post 2.0. I'd be disappointed with just ditching something that was thought worthy of GSoC and actually believed it was a P3 (bug 55) that we didn't have LV2 support working.         

If other developers agree with Leland's idea of removing the three libs from lib-src, leaving the Audacity-specific alv2 code in "src" and readdressing it as an external effect module post-2.0, that's OK with me. Where does that leave the previous need of translating much of the slv2 lib to C++ - would that still have to be done?

(In reply to comment #8)
> If other developers agree with Leland's idea of removing the three libs from
> lib-src, leaving the Audacity-specific alv2 code in "src" and readdressing it
> as an external effect module post-2.0, that's OK with me. Where does that leave
> the previous need of translating much of the slv2 lib to C++ - would that still
> have to be done?

The reason I'd mentioned an "external module" kind of thing is that it could then be built within an MSYS environment so that gcc could be used.

Another possibility may be to simply use MSYS to build the libraries and then dynamically load those from within the existing SLV2 code.  That might be an easy solution as well...though I haven't looked into it.

(In reply to comment #8)
Gale said "@Ed, out of interest, I would still assume when you batch build that you could select the projects to build, then until you do a fresh checkout, that build selection persists?"

Yes, and when I am working on something I do this. Unfortunately, SVN Update is unreliable for me so I always do SVN Checkout which forces a retooling of Batch Build. I like to use Batch Build as it does everything unattended.

OK so I think the developer discussion about this ought to go somewhere else so this "issue" just reflects what action was finally agreed on or implemented? I've cleared the URL field. 

And when we remove the libs from the Windows project, close bug 55? I don't think anything would be release notable once that's done.

I've removed the libs related to SLV2 and the taglib project from the Windows solution.  The projects are still available in win/Projects, so adding them back to the solution would be easy.

Wow, this thread has gotten long. 

> 
> Gale Andrews <gale@audacityteam.org> changed:
> 
> The reason I dismissed this rather summarily was that this bug as worded
> contradicts bug 55, so the two bugs can't really coexist together. LV2 was a
> significant part of GSoC 2008 even though the work was left unfinished:
> http://wiki.audacityteam.org/wiki/LV2_Support

Thanks for the reminder. That is something that probably will be useful in future, so I now think we should keep it in. (And undo any removal that has occurred.)


Ed, I was going to ask the same question Leland's did, about whether you "select all". IMO, you simply should not do that. If it's not clear in compile.txt, we should make it so. 

The right way to batch build is just select Audacity projects, and let the dependencies build only the libraries we actually use. I think there are several libraries we include in lib-src and the SLN file, but don't build -- mostly projects that are alternative builds (with #USE_*) or incomplete projects we might return to. I guess the others compile, but there's no reason for you to build them, which you are doing with "select all" -- so your batch build times are probably significantly longer than they need to be. 

Anyway, we should document this anywhere lib-src is documented, and in compile.txt rather than throwing away previous work that might be implemented in future.

As to the size of slv2, 70MB is tiny these days.

Just my opinion.

(In reply to comment #13)
> 
> Thanks for the reminder. That is something that probably will be useful in
> future, so I now think we should keep it in. (And undo any removal that has
> occurred.)
> 
Just to clarify...none of the real work was removed.  It all still remains in the Audacity source.  The only thing that was removed was he ability to build the supporting libraries.

As far as the LV2 plugin support, I do not believe trying to build the SLV2 library as part of the Audacity Windows solution would ever have worked without quite a bit of patching.

The EFFECT_CATEGORIES feature could have been made to work, but that's been possible since it was put in and it has never been utilized.

(In reply to comment #14)
> none of the real work was removed.  It all still remains in
> the Audacity source.  The only thing that was removed was he ability
> to build the supporting libraries.
>
> As far as the LV2 plugin support, I do not believe trying to build the SLV2
> library as part of the Audacity Windows solution would ever have worked without
> quite a bit of patching.

I think at least it's consistent now cross-platform, and could be left like that for now. It seems like bringing LV2 support in could have a number of solutions, but we don't need to burn our bridges by removing the libs from lib-src.        

I've changed the bug title (again) to "LV2 support unfinished". 

> The EFFECT_CATEGORIES feature could have been made to work, but that's been
> possible since it was put in and it has never been utilized.
It was actually in one or more Betas, and functional, but we pulled it because it was unpopular (largely because we let heavily used effects be hidden too far inside the structure). I think the correct approach as the code comment states would be to give the user a way to turn it on/off then bring it back. And sometime maybe give user the ability to move the effects around in the groupings as they want.

(In reply to comment #15)

 
> Gale Andrews <gale@audacityteam.org> changed:
>[...]
> I think at least it's consistent now cross-platform, and could be left like
> that for now. 

Fine by me. Thanks for the clarification, Leland.

As the below might assist with completing LV2 support, promoted to P4. 

SLV2 has been superseded by LILV (http://drobilla.net/software/lilv/). LILV is said to compile easily on Windows, Mac and Linux and has minimal dependencies e.g. Redland not required. 

In the Forum topic in the URL, Harrison Consoles plan to release cross-platform LV2 plug-ins for Ardour and Mixbus and are interested in helping to bring them into Audacity. There is also an unreplied-to devel topic http://audacity.238276.n2.nabble.com/Good-news-for-LV2-support-td7556402.html .

(In reply to comment #17)
Reworked LV2 support (using LILV for Windows was committed in http://code.google.com/p/audacity/source/detail?r=12781 .  

This removes the old supporting libraries (liblrdf, libraptor, redland, and slv2) and enables all platforms to use LV2 plug-ins in non-GUI mode.  There is
still some work to do, like subgroup handling and better scalepoint
handling. 

Marking it as "DEVEL - FIX MADE" to track that the current major improvement is working correctly.   

If someone has a view on whether the remaining issues should be separate P4's or P5's or keep this as a summary bug for remaining LV2 issues, please comment. 

I think there is more we can do to support LV2 GUI (on Linux) without losing the textual interface. See:
http://audacity.238276.n2.nabble.com/Width-of-LV2-plug-ins-td7560252.html#a7560276 .    

However the consensus seems to be that it will be hard to support LV2 GUI properly other than on Linux.

Textual interface works which is probably all this bug was supposed to address.