[LV2] LV2 & Patchstorage:
Hermann Meyer
brummer- at web.de
Fri Mar 10 07:59:25 PST 2023
Hi Pranciškus
I see you've uploaded most of my plugs already. As a note, there is now
a donation link for my work which you may implement.
https://paypal.me/brummer1010
regards
hermann
Am 10.03.23 um 14:53 schrieb Pranciškus Jansas:
> Hi David,
>
> Thank you for your extensive input!
>
> So, as the interest in this topic is low, we are moving forward with
> our initial plan - to cover our project requirements first.
> If there is more interest or additional projects in need of a plugin
> cloud solution, we will be more than happy to dedicate more resources
> to it, but we can't tackle the whole scope all at once alone.
>
> To note, all already uploaded plugins have links to their source code,
> and donate flow is active if we manage to find a related donate URL
> (e.g., https://patchstorage.com/instrument-tuner/). We are populating
> all the info ourselves, but PRs are welcome -
> https://github.com/patchstorage/patchstorage-lv2-uploader/blob/main/plugins.json.
> The build and publish guide is here -
> https://github.com/patchstorage/patchstorage-docs/wiki/Platform:-LV2-Plugins.
>
>
> We already see the Patchstorage LV2 section rising on Google and we
> will announce the Patchstorage LV2 section and the
> corresponding MODEP update officially next week. Let's see where
> it goes from there.
>
> If anyone has any questions, concerns, or suggestions, just reach out
> to me. And if someone wants to change how their plugin is presented on
> Patchstorage, let me know too.
>
> Thank you! Have a great weekend!
>
> Pranciškus Jansas
> Team Player at Blokas
> blokas.io <https://blokas.io>
> community.blokas.io <https://community.blokas.io>
>
> Blokas
>
> This message and any attachments are confidential and may be
> privileged or otherwise protected from disclosure.
> If you are not the intended recipient, you are kindly asked to
> telephone or email the sender and delete this message and any
> attachments from your system.
> If you are not the intended recipient, you are strongly requested not
> to copy this message or attachments or disclose the contents to any
> other person.
> Any liability for viruses is excluded to the fullest extent permitted
> by law.
>
>
> On Mon, Feb 20, 2023 at 6:36 PM David Robillard <d at drobilla.net> wrote:
>
> On Thu, 2023-01-26 at 22:21 +0200, Pranciškus Jansas wrote:
> > Hello LV2 Community!
> > Pranciškus from Blokas/Patchstorage here. Hermann Meyer suggested
> > reaching out here.
> > Let me begin by expressing our team's gratitude for all of your work
> > that helped us bring projects like Pisound and Patchbox OS to life
> > that heavily relies on the LV2 ecosystem.
> > I am reaching out because we are in the midst of finalizing
> > https://patchstorage.com support for LV2 plugins, and I would
> like to
> > have a discussion with you all.
> > Although the initial idea for this integration came from the need to
> > decouple plugin builds from Patchbox OS releases in the context of
> > the MOD stack, with help from other MOD-based projects, we reached a
> > state that could benefit the entire LV2 ecosystem.
> > What we have with Patchstorage now is a proof-of-concept system that
> > allows:
> > * LV2 plugin developers to build their plugins for different
> > platforms locally.
> > * Publish/update multi-platform plugins to Patchstorage via CLI
> > utility.
> > * For new/existing projects like MOD-UI, integrate Patchstorage
> as a
> > plugin cloud solution via Patchstorage API.
> > * For end-users to explore, download, rate, comment on plugins, and
> > subscribe to new plugin notifications. Also, having a
> centralized LV2
> > library would highly increase the visibility of the entire LV2
> > standard (SEO, spill-over effect from other platforms hosted on
> > Patchstorage, 23k MAU last month).
> > * For plugin developers to communicate directly with their
> users and
> > get donations from them (via any 3rd-party service). Later on, we
> > could implement Bandcamp-style “pay what you like” model.
> > You can find more info here -
> >
> https://github.com/patchstorage/patchstorage-docs/wiki/Platform:-LV2-Plugins
> > .
> > We are at the stage where we can start populating the LV2 section on
> > the site, but before doing so, we would like to discuss with you
> what
> > would be the best way to move forward:
> > * Would such kind of single LV2 library/index be beneficial from
> > your point of view? What aspects/features would be most appreciated
> > by plugin developers?
>
> I'm not really a plugin developer in any real sense aside from a few
> very conservative ports, but since nobody else has weighed in yet,
> here's my two cents:
>
> The ability to easily download working LV2 plugin binaries certainly
> seems useful for users. I don't know about developers; it depends,
> really. A lot of FLOSS developers just don't deal with binary
> distribution whatsoever, and LV2 is no different there. Most are used
> to packagers being other people, most commonly, OS distributions.
>
> The site seems more suited to sharing presets at first glance,
> which is
> a different thing from plugins themselves, and has a much lower
> barrier
> of entry. LV2 presets are, for the most part, just portable data that
> doesn't have any of these binary issues, and any user can save and
> share one pretty easily.
>
> > * In your opinion, would the plugin developers be willing to build
> > and upload plugins themselves? If not, could there be concerns if we
> > upload plugins ourselves, of course giving the credit for
> authors and
> > linking to their project pages?
>
> You're legally free to do whatever the licenses say you are, but sure,
> without halfway decent credit and links to upstream projects and such
> you'll generate a ton of bad will.
>
> The trouble with uploading builds is that doing builds appropriate for
> binary distribution, especially on Linux, is hard. If you provide
> tooling of some sort that makes this easy and hard to screw up (e.g. a
> standard toolchain, verifying that things aren't linked to some shared
> library that might not be present, etc), that would be useful to
> developers.
>
> Otherwise, it's effectively just another place that one could upload
> something, after doing a bunch of work (that they're probably not
> doing
> already)? That means an incentive is probably needed to make anyone
> particularly care. If there's a wider userbase, and some kind of
> financial incentive like a donation system or whatever, I imagine that
> would provide some incentive for many, but everyone's different. Some
> people are into providing portable binaries in general, some are happy
> with releasing source code that makes its way into traditional
> distributions, some don't care at all. Some care about a wider
> userbase and/or better direct communication with the userbase,
> some not
> at all. Some wish they could make some money off of their plugin
> work,
> some not at all. Some care about Windows and MacOS, some not at all
> (or are actively hostile to the idea), etc.
>
> Your uploader tool, patchstorage-lv2-uploader, has "Tested on Windows
> only" in its README, which is... not a good look. Meanwhile, the
> builder tool requires a "Linux or Mac OS" based computer. That also
> seems to be a huge meta-project of vendored things, without any clear
> instructions on how one might build their own plugin, if this is even
> possible. I think if you want people to upload binaries, it has to be
> as simple as possible and very clear how to do so.
>
> > * Regarding builds and targets - we have quite clear requirements
> > for the MOD stack projects, and currently, the builder supports
> > x86_64, raspberrypi3_armv8, raspberrypi4_aarch64 platforms. Having
> > said that, Patchstorage could support a different packaging option
> > for other targets as well. From your experience, is it practically
> > feasible to provide packaged plugins built for different
> > targets/platforms (in single digits) that would cover at least
> 70% of
> > end-user needs? I am not that familiar with all the Linux packaging
> > and dependencies nuances and don’t know what architecture and Linux
> > distro combinations are the most popular.
>
> The only way to distribute binary plugins that are likely to work
> across various Linux systems is to vendor and/or statically link
> nearly
> - but not quite - everything. Even then, libc incompatibilities and
> such can get you. Lignux is a notoriously awful platform for
> distributing binaries, but the constrained scope of plugins means you
> can pull it off. It takes some work and know-how, though, and the
> default build you get out of whatever build system on whatever
> distribution won't do it.
>
> Architecture-wise, x64, arm32, and aarch64 certainly covers well over
> 70% of needs in practice. LV2 is also used on Windows and MacOS,
> although much less than on Linux (or POSIX in general).
>
> > To sum up, I would like to understand how much effort we should
> > dedicate to Patchstorage and LV2 questions - should we stick to
> > covering just MOD-based-projects needs, and that’s it, or with your
> > help, we could achieve something that would be a great boost for the
> > entire LV2 ecosystem?
>
> The above-mentioned preset idea seems like a much easier thing to
> establish to me, although I don't know if the current site structure
> meshes with that so well since there's a vast number of "projects"
> (plugins) that they could fall under.
>
> Otherwise, the problem of making it easy to provide solid binary
> builds
> for "all" platforms (and test them somewhat, to at least be sure
> they're likely to load at all) is still just, well... there. A website
> to upload the results to doesn't seem to do much for most developers
> who don't already have such infrastructure set up.
>
> It would be nice, though, for whatever that's worth.
>
> --
> dr
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.lv2plug.in
> http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20230310/2cc75e2a/attachment-0001.htm>
More information about the Devel
mailing list