*** ricardocrudo has joined #lv2 | 06:17 | |
*** Anchakor_ has quit IRC | 06:18 | |
*** jcelerier has joined #lv2 | 07:49 | |
jcelerier | hello :) | 07:49 |
---|---|---|
jcelerier | so, after the first few days it's starting (I think :D) to make sense in my head about LV2. | 07:49 |
jcelerier | (this may or may not be stockholm syndrome :p) | 07:50 |
jcelerier | and I was wondering about the handling of plug-in data in my software, considering that of course I do not wish to support only LV2 but also VST, AU, etc... | 07:50 |
jcelerier | so I'm a bit torn | 07:51 |
jcelerier | should I give it all in to LV2, and use LV2's model as general data model for plug-ins in my applications, and then write LV2 encapsulation wrappers for VST, etc... (unless they already exist) | 07:52 |
jcelerier | or re-do my own similar (but certainly simpler) data model that fits exactly to what I need on my software, and then bind the necessary parts of lv2, vst, etc... | 07:52 |
*** trebmuh has joined #lv2 | 08:37 | |
*** falktx|work has joined #lv2 | 08:51 | |
*** sigma6 has joined #lv2 | 09:06 | |
*** jcelerier has quit IRC | 09:51 | |
*** trebmuh has quit IRC | 11:37 | |
*** jcelerier has joined #lv2 | 11:39 | |
*** trebmuh has joined #lv2 | 11:50 | |
rgareus | jcelerier: most DAWs that I know have an internal abstracttion for plugins. The main parts are pretty much identical in all: [float] control ports and a run() function. instantiate, activate, deactivate, unload | 12:14 |
rgareus | jcelerier: if your DAW uses an object oriented programming language a [virtal] base class makes sense. | 12:14 |
rgareus | you'll want the opposite of encapsulation. that'll limit features of all standards to what LV2 can do. or rather into the LV2 way of doing things. | 12:16 |
rgareus | AU for example has variable i/o port count (LV2 does not) and uses a callback method for input (plugin asks hosts for samples if needed) | 12:17 |
rgareus | VSTi needs midi-event before run(). -- LV2 passes them as Atom-sequence etc etc. Time/Bar-Beat reporting is different in each case. all that stuff is better modelled as abstraction + implementation (not encapsulating) | 12:18 |
rgareus | ...not to mention state save/load. | 12:21 |
*** oofus_lt has joined #lv2 | 12:32 | |
jcelerier | *weeps in sadness* | 12:35 |
*** sigma6 has quit IRC | 12:35 | |
rgareus | it's not impossible to wrap all things in LV2. but it's not too sensible | 12:36 |
rgareus | jcelerier: Carla.lv2 can load VSTs for example | 12:36 |
jcelerier | okay | 12:36 |
jcelerier | I wonder if someone has a clean enough GPL implementation in his sequencer | 12:36 |
rgareus | jcelerier: ardour is GPLv2 (and uses vestige -- VST2.x) | 12:37 |
jcelerier | I went looking into QTractor's source but it looks like a big #ifdef mess | 12:37 |
*** sigma6 has joined #lv2 | 12:38 | |
rgareus | JUCE is also GPL (that's what carla uses) | 12:38 |
jcelerier | vestige is the VST header reimplementation right ? | 12:38 |
rgareus | yes, just the header (interface) | 12:38 |
rgareus | no implementation | 12:38 |
jcelerier | yep | 12:38 |
jcelerier | And for juce.. I dunno, I already use Qt and it pains me to have two complete software toolkits in my software | 12:39 |
jcelerier | but if it's the path of least resistance... | 12:39 |
rgareus | what does QT buy you in a sequencer? | 12:40 |
jcelerier | uh... well it made it damn easy to develop | 12:40 |
jcelerier | www.i-score.org | 12:40 |
rgareus | last I looked there were no audio specific widgets in there, not to mention anything related to score rendering. | 12:41 |
jcelerier | what kind of audio specific widgets ? | 12:42 |
jcelerier | waveforms, piano roll ? | 12:42 |
rgareus | yes and faders, knobs | 12:42 |
rgareus | the default sliders are just useless. | 12:43 |
jcelerier | ah well, honestly it's not too hard to reimplement them but for the users of the software it does not matter that much | 12:44 |
jcelerier | it started as a sequencer for max/msp | 12:44 |
rgareus | mmh though looking at the screenshot, i-score takes a different aproach to this, anyway | 12:44 |
*** arguy_work has quit IRC | 12:44 | |
jcelerier | one of the big gains of Qt is that it makes the object model available almost seamlessly from Javascript | 12:45 |
jcelerier | so for instance you can write "automations" inline directly in JS | 12:45 |
jcelerier | more like transfer functions maybe... | 12:45 |
rgareus | I was getting into issues with ABI. say a QT5 Host, QT4 plugin GUI (same memory space) it's arguably fault of the plugin devs | 12:46 |
jcelerier | ah yeah, a solution may be to have a namespaced build of qt | 12:47 |
jcelerier | e.g. you can enclose everything in my_namespace for instance | 12:47 |
jcelerier | this way no symbol collision | 12:47 |
rgareus | jcelerier: the problem is QT itself | 12:47 |
jcelerier | but you have to have a special build of qt for each platform... | 12:47 |
rgareus | not your app | 12:47 |
jcelerier | yes, and you can configure the qt symbols to be in their own namespace | 12:48 |
jcelerier | eg myapp::QString | 12:48 |
jcelerier | etc... | 12:48 |
rgareus | QT5/QT4 cannot exist in the same memory space (process) | 12:48 |
rgareus | same with gtk2/3 | 12:48 |
*** sigma6 has quit IRC | 12:48 | |
rgareus | there are some static globals. | 12:48 |
jcelerier | :( | 12:49 |
rgareus | and last I looked QT5 still used gtk2's theming engine | 12:49 |
rgareus | so gtk3 plugin GUIs are out, too | 12:49 |
rgareus | it's a mess. | 12:49 |
rgareus | falktx compiled complete QT as static lib. and I think some patches, too to work around this. but carla also uses bridges (process separation) | 12:50 |
rgareus | on OSX it's worse because it has a flat namespace. | 12:51 |
*** NickSB2_ has quit IRC | 12:51 | |
jcelerier | I guess bridge is the best long-term solution | 12:51 |
jcelerier | especially for stability | 12:51 |
rgareus | jcelerier: it does not scale | 12:52 |
rgareus | jcelerier: it's fine for a handful of plugins.. or running at large buffersizes | 12:52 |
rgareus | but 100+ plugins: you'll send more time switching processes than doing audio-processing | 12:53 |
*** arguy|work has joined #lv2 | 12:55 | |
rgareus | jcelerier: http://lists.ardour.org/pipermail/ardour-users-ardour.org/2015-August/027373.html has a rundown on the numbers | 12:55 |
jcelerier | rgareus: okay | 13:01 |
jcelerier | weird, I used bitwig and I had no problem with hundres of instances of plugins | 13:01 |
rgareus | jcelerier: at what buffersize? | 13:02 |
rgareus | BW is by default 1024 * 2 so 48msec | 13:03 |
*** NickSB2_ has joined #lv2 | 13:05 | |
*** jcelerier has quit IRC | 13:06 | |
falktx|work | bitwig has different brigde modes | 13:06 |
rgareus | there's a single binary | 13:07 |
falktx|work | yes | 13:07 |
rgareus | which probably wakes up VSTs inside in sequence | 13:07 |
falktx|work | but it has mode for 1 bridge per plugin, or 1 bridge for all plugins | 13:07 |
falktx|work | 1 bridge for 32bit and 1 bridge for 64bit | 13:07 |
rgareus | but I don't see how that can be used for parallel processing | 13:07 |
falktx|work | you don't need a separate binary, you can run yourself with different arguments | 13:08 |
falktx|work | tracktion does this | 13:08 |
rgareus | right. same thing really | 13:09 |
rgareus | process separation | 13:11 |
rgareus | Bitwig's approach would allow to ship a complete GPL LV2 loader (separate binary) that just speaks their protocol | 13:11 |
drobilla | One could wrap VST in LV2 relatively easily. Some ports (like MDA) half-assedly take this approach anyway | 13:33 |
drobilla | AUs dynamic I/O, among other things, not so much | 13:34 |
falktx|work | would would either require dynmanifest or run a script to generate plugins | 13:34 |
drobilla | But literally using LV2s data model in the host probably doesn't make sense | 13:34 |
drobilla | Having to do a bunch of work to use different plugin specs is just the cost of doing business with multiple plugin specs | 13:36 |
drobilla | My fantasy next version of the stack would unify all the node types (SerdNode, LilvNode, SordNode) | 14:30 |
drobilla | Storing everything in one big ol' RDF model is a beautifully elegant way to do things, but the librarys make it a tedious mess in practice currently | 14:30 |
*** oofus_lt has quit IRC | 15:24 | |
*** arguy|work has quit IRC | 15:29 | |
*** sigma6 has joined #lv2 | 15:38 | |
*** ssj71 has joined #lv2 | 15:38 | |
*** deva has joined #lv2 | 15:52 | |
*** sigma6 has quit IRC | 16:05 | |
*** ssj71 has quit IRC | 16:37 | |
*** ssj71 has joined #lv2 | 16:40 | |
*** rncbc has joined #lv2 | 16:52 | |
*** ricardocrudo has quit IRC | 16:57 | |
*** falktx|work has quit IRC | 17:31 | |
*** Anchakor has joined #lv2 | 17:35 | |
*** ricardocrudo has joined #lv2 | 19:11 | |
*** ColaEuphoria has quit IRC | 19:46 | |
*** ColaEuphoria has joined #lv2 | 19:58 | |
*** deva has quit IRC | 20:13 | |
*** jcelerier has joined #lv2 | 20:32 | |
jcelerier | rgareus: sorry, I had to leave quickly earlier, I was at a conference | 20:33 |
jcelerier | I hope to continue this conversation another day ! | 20:33 |
*** jcelerier has quit IRC | 20:33 | |
drobilla | C++ thoughts: the lvtk way of cramming absolutely everything in a mixin has always rubbed me in the wrong way | 21:50 |
drobilla | I did end up using them in my tinkerings for interfaces, since it's the only way to get a magical extension_data method | 21:50 |
drobilla | But having things like uri_map() on the plugin is just strange, and means you need a wrapper around the template for mandatoryness and all the rest | 21:51 |
drobilla | Considered doing features just as classes you can use on your own, as members. _uri_map.map() and so on | 21:51 |
ColaEuphoria | @drobilla What would be the easiest way to do a "pull request" for pugl? | 21:51 |
ColaEuphoria | oops i did the "twitter" thing | 21:52 |
ColaEuphoria | sorry we use Slack at work so I'm just used to it | 21:52 |
drobilla | But come to think of it, a slightly different mixin idea seems nice: have a "host" member which is extended with mixins | 21:52 |
drobilla | _host.uri_map() or _host.whatever_provided_by_host() seems a lot clearer to me, and much more like what a nice native C++ interface would look like | 21:52 |
drobilla | ColaEuphoria: There's a github mirror if you must, but just email me, really | 21:53 |
drobilla | One thing that annoys me about git is it's *so* close to having this workflow, but you can't set the email address to email patches to upstream and have it pulled, so not quite | 21:53 |
*** trebmuh has quit IRC | 21:53 | |
drobilla | ColaEuphoria: i.e. git format-patch and git send-email | 21:54 |
drobilla | ColaEuphoria: But whatever gets it to me, I don't really care | 21:54 |
ColaEuphoria | I just feel silly using github JUST to make pull requests | 21:54 |
ColaEuphoria | gh really rubs me wrong | 21:54 |
drobilla | You and me both | 21:54 |
ColaEuphoria | however to be honest | 21:55 |
ColaEuphoria | my "patch" is literally nothing more than just #include<stdint.h> in pugl/event.h | 21:55 |
drobilla | Let's take this lovely thing whose main selling point is being decentralized then centralize it as much as possible. On a proprietary commercial platform no less. Woo | 21:55 |
ColaEuphoria | and then everyone thinks github and git are synonymous ;) | 21:55 |
drobilla | ColaEuphoria: Okay, I'll just do that | 21:56 |
drobilla | Though it looks like common.h is missing the same for intptr_t, so putting it there will do | 21:56 |
ColaEuphoria | i'll probably put in a "real" pull request later if i modify the wscript to allow for static linking | 21:57 |
ColaEuphoria | and i'll mail you the patch | 21:58 |
drobilla | ColaEuphoria: http://git.drobilla.net/cgit.cgi/pugl.git/commit/?id=80510efead3512766d798d29fbfb66ea5646a249 | 22:00 |
drobilla | Note to self: fancy up my cgit like lv2plug.in/git | 22:00 |
drobilla | --static doesn't work? | 22:01 |
rgareus | WFM | 22:01 |
ColaEuphoria | oh | 22:08 |
ColaEuphoria | it works | 22:08 |
ColaEuphoria | nevermind heh | 22:08 |
drobilla | While we're on the topic of git, it'd be nice if cgit could do signed tarballs | 22:15 |
drobilla | Just tagging a release and having everything magically available would be pretty great | 22:15 |
* drobilla is on a kick to absolutely minimize the amount of effort he needs to put into releasing/maintaining things | 22:16 | |
rgareus | drobilla: I wrote a php script for that | 22:19 |
rgareus | drobilla: ping a URL and php calls "make tagupdate" https://github.com/x42/x42-plugins/blob/master/Makefile | 22:20 |
rgareus | ie check if any of the submodules has a new tag, and if so, submodule update, roll a tgz and return it (debian uscan compatible) | 22:21 |
rgareus | so debian uscan comes around every other day.. hits http://gareus.org/misc/x42-plugins.php and automatically notifies the packager and even downloads the tgz for him if there's a new tag | 22:22 |
* rgareus hasn't written announcement messages since | 22:23 | |
rgareus | https://github.com/x42/x42-plugins/blob/master/Makefile.git has the "make dist" | 22:23 |
drobilla | rgareus: Fancy, but not really any less work than doing so locally, and having GPG be able to sign on the server and all... | 22:24 |
rgareus | i'm sure you can come up with a similar system. git tag .. ; git push. done | 22:25 |
drobilla | rgareus: I migrated my site to Pelican and wrote a thing to automatically generate blog posts straight from the NEWS file | 22:25 |
drobilla | (not uploaded yet) | 22:25 |
drobilla | I'd like to just interact with the world purely through git and email, but it's nice to have feeds of releases and news on the site anyway | 22:25 |
rgareus | drobilla: there's always IRC | 22:26 |
rgareus | well, you can blog and announce and email.. how much you like | 22:27 |
rgareus | but having the release-process itself automated is very handy | 22:27 |
rgareus | IMHO | 22:27 |
drobilla | Not familiar with uscan until now. I guess since I publish a dir with foo-x.y.z.tar.bz2 and foo-x.y.z.tar.bz2.sig it just should work | 22:27 |
rgareus | drobilla: aka debian/watch | 22:27 |
drobilla | The email part I haven't automated yet | 22:27 |
drobilla | Not sure how much I care, but given what I already have it'd be pretty trivial I suppose | 22:28 |
* drobilla is a superfan of SSGs now | 22:28 | |
drobilla | lv2plug.in also runs on Pelican, so if the libs ever actually migrate there, same deal | 22:29 |
rgareus | drobilla: liblilv has a watch file. there should be regular pings to http://download.drobilla.net/lilv-(.+)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) | 22:31 |
ColaEuphoria | holy regex | 22:31 |
rgareus | there are 2 more lines before that in debian/watch http://download.drobilla.net/ is a index list | 22:32 |
drobilla | Some day I am going to regret putting all those in the same place... but not today :) | 22:33 |
drobilla | Ah, 2011/2012. I could really use another phase where I'm free to dump a ton of time into biggish things that need doing | 22:34 |
drobilla | or: When NIHism works out super well | 22:36 |
drobilla | I suppose having done all that I should actually do the whole release thing | 22:54 |
*** unclechu has joined #lv2 | 22:57 | |
*** ricardocrudo has quit IRC | 23:03 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!