On Fri, 2011-07-29 at 21:16 +0200, Olivier Guilyardi wrote:
On 07/29/2011 08:00 PM, David Robillard wrote:
On Fri, 2011-07-29 at 13:56 +0200, Olivier
Guilyardi wrote:
I
understand that you want LV2 to be a standard and only a standard, and thus
only show its specification on
http://lv2plug.in. You seem to consider that
serd, sord and lilv are helper libraries and only one route amongst other
possible routes to host LV2 plugins. This is consistent in /principle/, but do
you not something feel like such "modularity" can be confusing, when compared
to
existing major plugin technologies which provide everything as an SDK? Do you
not feel like a complete LV2 SDK would be more developer friendly, in /practice/?
No I don't. Do you have any concrete reason why that would be the case,
that isn't eliminated by simply clearly pointing to good implementations
on the LV2 site?
I agree that good pointers and docs on the LV2 site could be a solution. But,
one concrete reason is that for example, you don't have anything like aptitude
install lilv on other OSes. I think that we don't see the need for SDKs on Linux
because we have distributions and smart packaging systems, which gracefully
handle dependencies.
I have tested my LV2 stack on both Windows (in MingW) and OSX and it
builds and works fine. I very much support LV2 branching out to other
platforms, and even reluctantly went with a much more liberal license
than I prefer to facilitate that.
What you are talking about is simply packaging. Feel free. Someone who
actually has a clue about XCode or Visual Studio or Eclipse or whatever
other environment would have to do that part. I certainly don't. I can
probably pull off building an OSX "framework" if anyone cared. None of
this work magically gets done by sticking an "SDK" sticker on something.
(Though honestly, anyone writing audio software is going to be perfectly
capable of making use of a portable C library regardless)
As for what I will personally do, I will eagerly do any reasonable work
to help out a developer who contacts me and is interested in using this
stuff but needs certain tweaks or whatever. I am *not* interested in
wasting extremely valuable time on things for hypothetical fantasy
developers, though. Communication is important. If you can't even
contact the developer of something to ask about collaboration, frankly
you deserve to be left in the cold. If, for example, the Audacity
developers, contact me and need some changes to Lilv to make it work
well for them on Windows, they can contact me, and I'd be more than
happy to help. Real people, real problems, real work, real benefit.
It's worth doing when you *know* somebody is going to use it. There's
certainly no shortage of such things, so wasting time on things that
*might* be useful to some hypothetical person is foolish.
Free Software is community-based software. Communities collaborate. If
you want to write software using tools from some faceless monolith that
it's hopeless to even communicate with, well, this isn't really the
software for you. If you want software by and for real *people*...
Greetings! What are you trying to do? Awesome, let's do it.
-dr