| badosu | Really nice: https://www.kernel.org/doc/Documentation/circular-buffers.txt | 01:57 |
|---|---|---|
| *** Socapex has joined #lv2 | 06:15 | |
| *** gianMOD has joined #lv2 | 06:55 | |
| *** gianMOD has quit IRC | 07:05 | |
| *** edogawa has joined #lv2 | 07:16 | |
| badosu | drobilla: Is it possible to make jalv.qt a qt widget inside a Qt4 project? | 08:22 |
| *** sigma6 has joined #lv2 | 08:25 | |
| Socapex | Wait a minute, you guys expect *users* to compile their plugins!? | 09:14 |
| LAbot | Socapex: Sent 1 day, 4 hours, and 57 minutes ago: <rgareus> http://www.rossbencina.com/code/lockfree | 09:14 |
| *** gianMOD has joined #lv2 | 09:23 | |
| *** ricardocrudo has joined #lv2 | 09:25 | |
| *** falktx has joined #lv2 | 09:45 | |
| falktx | drobilla: can we expect some lv2/serd/etc releases soon? | 09:46 |
| * falktx is packaging stuff needed for latest ingen | 09:46 | |
| falktx | drobilla: also, there has been a lot of changes in suil since last release. has the ABI (not API) changed? | 09:50 |
| * falktx wonders where to see old tickets now | 09:59 | |
| falktx | http://lv2plug.in/ticket/14 url doesn't work | 09:59 |
| *** gianMOD has quit IRC | 10:01 | |
| falktx | latest lv2 git fails to build | 10:02 |
| falktx | it doesn't seem to read PKG_CONFIG_PATH of it's not checking for pkgconfig in fifths | 10:03 |
| falktx | *or it's not | 10:03 |
| falktx | ../plugins/eg-fifths.lv2/fifths.c:25:21: fatal error: sndfile.h: No such file or directory | 10:04 |
| falktx | but I do have sndfile installed on a custom path | 10:04 |
| falktx | $ pkg-config sndfile --cflags | 10:04 |
| falktx | -I/opt/kxstudio/include | 10:04 |
| *** gianMOD has joined #lv2 | 10:22 | |
| *** bgola has joined #lv2 | 11:03 | |
| bgola | drobilla: hey :) when I set a plugin position (canvasX, Y) using ingen's gui it broadcasts a patch:Patch, but if I send a patch:Patch it does not work. I have to send a patch:Set for canvasX and for canvasY. it is not a problem, but i would like to keep things consistent on my side. is there a reason to no support patch:Patch using the API? or maybe i am missing something | 11:25 |
| bgola | (i mean, if I send a patch:Patch using the socket api) | 11:25 |
| bgola | (socket / REST) | 11:25 |
| *** falktx has quit IRC | 11:27 | |
| *** ddom has joined #lv2 | 11:27 | |
| *** edogawa_ has joined #lv2 | 11:30 | |
| *** edogawa has quit IRC | 11:33 | |
| *** Socapex has quit IRC | 11:49 | |
| *** gianMOD has quit IRC | 11:54 | |
| *** ricardocrudo has quit IRC | 11:56 | |
| *** falktx has joined #lv2 | 12:01 | |
| *** ricardocrudo has joined #lv2 | 12:16 | |
| falktx | I've built all the latest lv2 stuff. jalv-qt cannot properly show x11 uis | 12:23 |
| falktx | they appear in a separate window | 12:23 |
| *** gianMOD has joined #lv2 | 12:29 | |
| falktx | fabla works on the same window, but it doesn't have the proper size | 12:33 |
| falktx | hmm ingen fails to build with -fvisibility=hidden | 12:49 |
| *** rncbc_jolla has joined #lv2 | 12:52 | |
| *** rgareus has quit IRC | 12:57 | |
| *** rgareus has joined #lv2 | 13:02 | |
| *** rncbc_jolla has quit IRC | 13:59 | |
| *** Socapex has joined #lv2 | 14:01 | |
| falktx | this is weird, ingen is calling urid-unmap with id 62465 | 14:21 |
| falktx | no way that many uris have been mapped | 14:22 |
| *** gianMOD has quit IRC | 14:52 | |
| *** gianMOD has joined #lv2 | 15:01 | |
| drobilla | falktx: http://lv2plug.in/git/cgit.cgi/lv2.git/commit/ | 15:37 |
| drobilla | falktx: The ABI compatibility is in the version number as always. | 15:37 |
| drobilla | bgola: "does not work" how? Ingen itself uses patch:Path for plenty of things. | 15:40 |
| Socapex | drobilla: You guys expect users to compile their plugins? | 15:53 |
| drobilla | Socapex: ? | 15:55 |
| Socapex | drobilla: There is no packaging spec for LV2? All plugins need the user to compile them! | 15:56 |
| drobilla | Socapex: What would a "packaging spec" say, exactly? | 15:56 |
| drobilla | LV2 plugins live in bundles. That is the packaging spec. | 15:56 |
| Socapex | drobilla: Put your plugin here: [insert location] in a .lv2 folder or whatever | 15:56 |
| drobilla | http://lv2plug.in/pages/developing.html | 15:57 |
| Socapex | So you actually are telling me you think its fine that users have to compile their plugins? | 15:57 |
| Socapex | wow | 15:57 |
| Socapex | find me a plugin that I dont have to compile | 15:57 |
| drobilla | Welcome to Linux. Things are generally packaged by distributions. | 15:57 |
| Socapex | you know why apt-get and yum exist>? | 15:58 |
| Socapex | you guys are ridiculous, you are responding with a straight face right now | 15:58 |
| drobilla | um...... yes. To install distribution packages. | 15:58 |
| Socapex | like you seriously believe its ok | 15:58 |
| drobilla | I don't know what the fuck you're all outraged about | 15:58 |
| drobilla | If you want to make a binary package for your plugin, then do it | 15:58 |
| Socapex | why doesnt the spec require that? | 15:59 |
| drobilla | How could an API spec possibly require that? | 15:59 |
| drobilla | Thou shalt not distribute plugin source code? | 15:59 |
| Socapex | im engraged because i've spent the last 2 weeks working on this awesome open-source plugin solution, which ends up not even considering the end-users at all | 15:59 |
| Socapex | thou shalt put plugin in a folder/whatever with this structure | 16:00 |
| drobilla | Maybe you should read the link I posted before going on an ignorant tirade | 16:00 |
| drobilla | "Distribution and Packaging" header might be relevant | 16:00 |
| drobilla | Cryptic, I know. | 16:00 |
| Socapex | im sure what the link says is that plugin creators can compile if they want to, and user copies in /usr/lib/something, yes? | 16:00 |
| drobilla | Obviously there are standard locations to install plugins... | 16:01 |
| Socapex | drobilla: So basically, nobody follows that? Link me a plugin that does this plz | 16:02 |
| drobilla | Making distribution independent package for Linux is a notoriously difficult and messy situation | 16:02 |
| falktx | I can link you to a lot of them | 16:02 |
| drobilla | Well, yes. Like roughly every other open source Unix project ever, upstream typically distributes source code. | 16:02 |
| falktx | https://github.com/zamaudio/zam-plugins | 16:03 |
| falktx | see https://github.com/zamaudio/zam-plugins/blob/master/Makefile#L27 | 16:03 |
| drobilla | Though some do | 16:03 |
| drobilla | The people targeting other platforms obviously do | 16:03 |
| falktx | "make install" or equivalents put plugins in /usr/lib/lv2/ | 16:03 |
| falktx | Socapex: this (let users compile) usually refers to linux users only | 16:04 |
| Socapex | falktx: Exactly, you expect sound engineers/musicians and users to go in a terminal and type make install | 16:04 |
| falktx | Socapex: I don't and that's why I make kxstudio | 16:04 |
| falktx | lots of good packages in there | 16:04 |
| Socapex | falktx: Which is? | 16:04 |
| falktx | you can see the plugins I package here https://launchpad.net/~kxstudio-debian/+archive/ubuntu/plugins/ | 16:04 |
| Socapex | ok. How many plugins exist pre-packaged and ready to go for windows? And lets not get the flame war going on how bad windows sucks, thats not the point. | 16:05 |
| drobilla | A handful at best. What's your point? | 16:05 |
| falktx | people developing for linux usually don't care about windows | 16:06 |
| falktx | it's much harder to support | 16:06 |
| drobilla | If you want Windows packages for plugins that don't exist, take it up with the plugin developers. | 16:06 |
| Socapex | drobilla: Im not trying to make a point. I am asking a question I shouldve asked weeks ago | 16:07 |
| Socapex | So LV2 is basically cross-platform but knowbody really develops for win/mac | 16:07 |
| * falktx is a nobody | 16:08 | |
| drobilla | The overwhelming majority of developers work on Linux. | 16:08 |
| * Socapex is a nobody | 16:08 | |
| falktx | Socapex: devs are on linux for a reason. most of them don't want anything to do with windows | 16:09 |
| falktx | so most of them won't release windows plugins | 16:09 |
| Socapex | falktx: Then why protray LV2 as crossplatform? | 16:09 |
| falktx | because if is | 16:09 |
| drobilla | Because it is cross platform? | 16:09 |
| falktx | LV2 can't mandate what plugin devs do | 16:09 |
| Socapex | used by hundreds of plugins and other projects. <-- 1 link, only 1 link with a package. Heck, an installer for linux | 16:10 |
| falktx | then help by making more | 16:10 |
| falktx | we're not being payed to work on this | 16:11 |
| drobilla | There are hundreds of plugins in most major distributions. | 16:11 |
| Socapex | and I'm not either. There is no point in making LV2 because if I am to do that, I basically have to add the host capabilities to our project, which gives absolutely nothing because all plugins are linux only, and even worst, users have to compile them themselves | 16:12 |
| falktx | you're missing the point | 16:12 |
| Socapex | what is the point? | 16:12 |
| falktx | some plugins are not even released for linux | 16:12 |
| falktx | the authors only release source | 16:12 |
| falktx | do with them as you wish, with a free license | 16:13 |
| Socapex | thats *exactly* my point :( | 16:13 |
| falktx | linux distros are just nice to us and compile them for us | 16:13 |
| Socapex | I guess you guys cant force devs to package their plugs, I'll give you that | 16:13 |
| drobilla | Socapex: Well, then, you demonstrate nicely why Windows support is limited | 16:13 |
| falktx | Socapex: the code is there, you can build them yourself and package them with your app | 16:13 |
| drobilla | Socapex: You want plugin devs to write plugins for hosts that don't exist, but you don't implement a host unless they do | 16:14 |
| Socapex | and that you actually specify exactly what I wouldve done is as much as you can do | 16:14 |
| falktx | audacity does this, it includes swh and other ladspa plugins | 16:14 |
| Socapex | drobilla: I know, its a chicken-egg problem | 16:14 |
| Socapex | drobilla: So basically so far, only linux distros have been shipping plugins and nobody cares about other platforms. | 16:16 |
| Socapex | even less packaging in a user digestable way | 16:16 |
| falktx | if you care, build them for windows and provide users a link | 16:16 |
| falktx | it only takes 1 person | 16:16 |
| falktx | I though about doing this, but I'm already pretty busy | 16:16 |
| Socapex | falktx: I'm also very busy, and seriously, thats kind of insane | 16:17 |
| Socapex | I understand the lack of mac support, as running in a VM is against TOS, but you can get free legal VMs of windows. sigh | 16:18 |
| drobilla | Mac will probably take off before Windows, if anything. It's less horrible and weird to port to, and most audio people use it anyway | 16:19 |
| drobilla | Though most plugins use UIs that are fundamentally unpackageable for either of those platforms. | 16:21 |
| drobilla | Getting the plugins themselves to work is usually pretty trivial | 16:21 |
| falktx | the question is how will maintain those ports? where to report bugs to? | 16:22 |
| falktx | *who | 16:22 |
| drobilla | Somebody Else :) | 16:29 |
| falktx | aka Not Me :) | 16:32 |
| *** Socapex has quit IRC | 16:39 | |
| *** gianMOD has quit IRC | 17:09 | |
| *** gianMOD has joined #lv2 | 17:12 | |
| drobilla | falktx: Fixed ingen compilation with hidden visibility | 17:16 |
| falktx | nice | 17:16 |
| drobilla | Kind of a mess with random things in engine/gui needing to be exported for LV2 to work, but whatever | 17:16 |
| falktx | lol | 17:16 |
| falktx | hack it until it builds | 17:17 |
| drobilla | Pretty much. The modules don't have strict interfaces, and this sort of thing is nightmarish in C++ in general | 17:17 |
| *** ddom has quit IRC | 17:21 | |
| *** edogawa_ is now known as edogawa | 17:43 | |
| badosu | I don't understand why Socapex was so outraged | 18:32 |
| *** gianMOD has quit IRC | 18:38 | |
| *** mlpug has joined #lv2 | 18:43 | |
| *** falktx has quit IRC | 18:46 | |
| *** ricardocrudo has quit IRC | 19:04 | |
| * drobilla shrugs | 20:03 | |
| badosu | I mean, what's the alternative? To distribute is just as easy as sharing a compressed folder that the user needs to put into a location | 20:05 |
| badosu | drobilla: so, I had this idea of changing jalv.qt main window to be a widget and using this to be lmms | 20:07 |
| badosu | 's host | 20:08 |
| drobilla | Indeed. Bundles make packaging delightfully simple, aside from library dependency / static issues that are inherent to any binary. | 20:08 |
| badosu | what do you think? is this a bad idea? | 20:08 |
| drobilla | badosu: What's the point? | 20:08 |
| badosu | Well, the point is to reuse jalv.qt code | 20:08 |
| drobilla | badosu: All 150 lines of it :P | 20:09 |
| badosu | For example, to create a qt widget that could be imported as a lib on any DSP-capable software that uses qt | 20:09 |
| drobilla | badosu: That's precisely what suil is for. Jalv is a program, there is little in there of use UI-wise | 20:09 |
| badosu | drobilla: well, the idea is to make jalv.qt be able to handle ui-less plugins | 20:09 |
| badosu | drobilla: ok | 20:09 |
| drobilla | Well, yes, jalv.qt sucks compared to jalv.gtk | 20:10 |
| drobilla | It isn't really feasible to turn jalv into a library, though. | 20:10 |
| badosu | drobilla: Ok. So let me formulate what I think better | 20:10 |
| drobilla | a generic GUI wrapper library or even plugin UI would be nice | 20:10 |
| drobilla | which is basically what you're getting at | 20:10 |
| badosu | I feel it would be a waste of resources to have a specific builder for UI-less interfaces specific to lmms | 20:11 |
| badosu | for example, it would be great to have a library where you just pass the node with the info on the plugin and receive a widget back | 20:11 |
| badosu | I'll see how jalv.gtk does it and port it to QT | 20:14 |
| badosu | then I'll try to extract the builder interface to a library that could be used on LMMS | 20:14 |
| badosu | What do you think? | 20:14 |
| drobilla | I think such a library is a good idea. | 20:15 |
| badosu | This is important for lmms as we have to have this specific interface anyway | 20:15 |
| drobilla | Though I had planned on avoid Gtk/Qt and the problems thereof entirely in it, it can support multiple toolkits easily enough. | 20:15 |
| badosu | Yeah, I understand what you mean, but for lmms this is mandatory | 20:15 |
| badosu | as we use this interface to handle automations | 20:15 |
| badosu | and offer the user a way to not depend on the specific UI as it may hide controls/not be usable | 20:16 |
| drobilla | Assuming the library API itself is C, and doesn't suck, I will gladly migrate Jalv to using it. | 20:16 |
| badosu | Well, it will mandatorily have to be C++ as it will use QT | 20:16 |
| badosu | also, it will probably suck, so I'll ask some advice after a finish it | 20:17 |
| drobilla | No, the widget would be Qt. Much like the UI extension itself. | 20:17 |
| badosu | Well, can you use QT without C++?? | 20:17 |
| drobilla | If it's C++ only, Qt only, and very tied with the way LMMS does things, you might as well just write it in LMMS | 20:17 |
| badosu | Ok, so you envision something different of what I am proposing | 20:18 |
| drobilla | No, but the suil API, and the LV2 UI API are C... same thing. | 20:18 |
| badosu | You envision a front-end for building the interface that could switch backends | 20:18 |
| drobilla | Not really. You want something to build a UI for a plugin. | 20:18 |
| drobilla | The obviously sensible way of doing so is a simple interface that, well, returns a UI for a plugin. | 20:19 |
| badosu | what you mean by "returns a UI for a plugin"? | 20:19 |
| drobilla | Which is nearly identical to the way we already do UIs, except being generated, it'll take in some Lilv information and generate it instead of loading it from a binary. | 20:19 |
| drobilla | This could even be integrated into suil itself. | 20:19 |
| drobilla | I mean returns a UI for a plugin? :) | 20:20 |
| badosu | hahaha | 20:20 |
| badosu | ok | 20:20 |
| drobilla | You don't want some completely different interface, then you need to support two things | 20:20 |
| drobilla | Once I get it, I should be able to use it like any other LV2 UI instance | 20:20 |
| badosu | so, what I thought first was something more QT-specific, for example a drop-in Widget class that would receive a lilv node and build the interface | 20:21 |
| badosu | This would be useful for example to reuse code between QTractor, LMMS and Jalv.qt | 20:21 |
| badosu | But what you propose is more generic, and probably a good idea as it could be used regardless of the toolkit | 20:22 |
| drobilla | Then each of those hosts needs to implement LV2 UI, and Qt specific UI thingie | 20:22 |
| drobilla | It's more work even if you only care about Qtville | 20:22 |
| badosu | well, so you say this is abroken design | 20:23 |
| badosu | I thought it was really simple | 20:24 |
| drobilla | Well, it's basically the right idea, but you propose adding a bunch of new API difficulty that is counter-productive | 20:24 |
| drobilla | Since any LV2 UI already has a straightforward way of interacting with the host | 20:24 |
| badosu | yes, but it does not provide a builder for plugins without UI | 20:25 |
| badosu | which was the initial idea | 20:25 |
| badosu | could you describe your proposal of a lib that could help in this regard? | 20:25 |
| drobilla | No, but the question is: what is the desired output of such a builder? | 20:25 |
| drobilla | The answer is, an LV2 UI | 20:26 |
| badosu | Oh, ok so I guess I am not being too clear | 20:26 |
| badosu | The API would be minimal, it would just be a constructor receiving a lilv node | 20:26 |
| drobilla | Specifically LV2UI_Descriptor and/or an instance thereof | 20:26 |
| badosu | And return q Widget to be embedded where the host wants | 20:27 |
| drobilla | Which literally every GUI supporting LV2 host, including QTractor and Jalv.qt, already support | 20:27 |
| badosu | Anyway, this is too confusing for now. I'll port jalv.qt to support UI-less then we can have this conversation | 20:27 |
| drobilla | No, you're being clear, but missing the point :) | 20:28 |
| badosu | Ok :-) | 20:28 |
| drobilla | The widget itself would be an opaque QWidget, just as current Qt GUIs are | 20:28 |
| badosu | No | 20:28 |
| drobilla | Well...... yes. | 20:28 |
| badosu | The widget would be a grid of controls | 20:28 |
| badosu | that's the purpose | 20:28 |
| badosu | it would be the simplest thing possible | 20:28 |
| drobilla | Otherwise there is no point to trying to do this generically, because it's largely useless | 20:28 |
| drobilla | The content doesn't matter. | 20:29 |
| badosu | Well, why do you think it's useless? | 20:29 |
| drobilla | Because it doesn't produce an LV2 UI | 20:29 |
| drobilla | Let me put it this way | 20:29 |
| badosu | Oh.... ok, I think I got your point now | 20:29 |
| drobilla | Such a thing could produce a UI that works with any host that supports LV2 UIs at all | 20:29 |
| drobilla | or, it could be a weird thing with it's own API that requires totally separate support | 20:29 |
| badosu | Yeah, actually that's a great idea | 20:29 |
| drobilla | Surely the former is obviously better | 20:30 |
| drobilla | and we can cram a Gtk one in the same framework, maybe a Pugl based on that works statically on all platforms, etc. Sky's the limit, because it just builds an LV2 UI that is exactly like any other | 20:30 |
| badosu | Yeah, but can this be built dynamically? I mean without code generation? | 20:31 |
| drobilla | I am not sure if integrating this into suil is appropriate, but it could be done, at which point every host gets automagic fancy UIs for any plugin | 20:31 |
| drobilla | mmmmmmmmmm I think so | 20:31 |
| drobilla | You can happily write a UI generator thing without caring about this initially | 20:32 |
| badosu | Ok, this is too ambitious for my current skills. | 20:32 |
| badosu | But looks wonderful | 20:32 |
| drobilla | Just make it talk via the same callbacks | 20:32 |
| drobilla | Which is trivial | 20:32 |
| badosu | Ok, so let me describe you the use case for LMMS | 20:32 |
| drobilla | This could be stuck in a more ambitious general wrapper thingie at some later point | 20:32 |
| badosu | We need this independent interface for every plugin | 20:33 |
| drobilla | (and is what you'll end up doing anyway, since LMMS or any other host will already have those callbacks anyway) | 20:33 |
| badosu | Because of automations and stuff | 20:33 |
| badosu | But we need to access the inner widgets | 20:33 |
| drobilla | Why? | 20:33 |
| badosu | For example to bind events to those controls | 20:33 |
| drobilla | Do you? | 20:34 |
| *** curlymorphic has quit IRC | 20:34 | |
| drobilla | => automation won't work with custom UIs | 20:34 |
| badosu | Well, we have a shortcut on LMMS where you hold ctrl and drag a control to create an automation track | 20:34 |
| badosu | this would be problematic on such a general API | 20:34 |
| badosu | do you understand my point? I like your idea, but it does not address the problem that I want to solve | 20:35 |
| badosu | But I guess you're right, my initial assumption that this would be usable outside LMMS is probably wrong | 20:35 |
| drobilla | Probably possible, if tricky | 20:38 |
| drobilla | But yes, that's mainly the point. At best copy-paste-modify reusable to some degree | 20:39 |
| badosu | what would be the first backend for your lib? | 20:40 |
| drobilla | In my general grandoise plan of things I'll get around to "eventually", that comes after finding some minimal toolkit I like to stick on top of Pugl, so, that. | 20:42 |
| drobilla | (Because Gtk*UI and Qt*UI are useless for binary dists on other platforms anyway) | 20:43 |
| badosu | are you helping building avtk? | 20:43 |
| drobilla | If I were to write it today, Gtk, because I actually have that code. | 20:43 |
| drobilla | Not really. I may steal it. | 20:43 |
| badosu | drobilla: yeah, that's why I feel jalv is very important, it's a nice reference | 20:43 |
| drobilla | I'm puzzled why you proposed to steal jalv.qt since it doesn't implement a generic UI whatsoever :) | 20:44 |
| badosu | Well, because I did not propose this | 20:44 |
| badosu | I want to actually develop jalv.qt | 20:44 |
| drobilla | It was mainly written as a shitty test host, but if you want to make it a half decent one, feel free | 20:44 |
| badosu | jalv.qt would is the best place for me to play with this | 20:45 |
| badosu | s/would// | 20:45 |
| badosu | drobilla: that's the idea | 20:45 |
| badosu | drobilla: the code should be identical for LMMS and jalv.qt, with the difference that is much easier to hack jalv.qt than LMMS | 20:46 |
| drobilla | Go nuts. There's little point unless you're religiously opposed to using a Gtk app at all, but as a place to work on building the widgets it'll suffice. | 20:46 |
| badosu | I am not *opposed* to use gtk | 20:46 |
| badosu | It's just that LMMS uses Qt and not Gtk | 20:47 |
| drobilla | I know. I meant point for end users of Jalv, which is why nobody has bothered | 20:47 |
| badosu | Oh yeah, bu I don't see jalv only as a usable host | 20:47 |
| badosu | I see it as a reference for developers | 20:48 |
| badosu | plugin and host developers | 20:48 |
| drobilla | Though I would prefer the UIs remain single files of a reasonable size | 20:48 |
| badosu | Also, this is not wasted effort, the code that I'll write will be identical to the one LMMS will need | 20:48 |
| drobilla | Yes, I get it. It is a decent plan | 20:49 |
| badosu | that's why I came up with the portable widget idea | 20:49 |
| badosu | but I'll not bother with this until I face the challenges of building it | 20:50 |
| *** mlpug has quit IRC | 20:52 | |
| *** falktx has joined #lv2 | 20:53 | |
| drobilla | badosu: Good ol' flat list of controls is straightforward, if limited | 21:06 |
| drobilla | badosu: I'd probably do that first and deal with creating appropriate widgets for various controls (ala jalv.gtk), then deal with smarter packing if you feel so inclined | 21:07 |
| badosu | hahaha, yeah, thanks for the feedback | 21:07 |
| *** falktx has quit IRC | 21:12 | |
| *** curlymorphic has joined #lv2 | 21:15 | |
| badosu | drobilla: why the lilv lib is referenced as lilv-0? | 21:40 |
| badosu | ok, it looks like arch extra repository is still stuck on version 0.20 | 21:42 |
| badosu | i'll have to build from source | 21:42 |
| drobilla | badosu: 0 is the major version. This is done to allow parallel installation of major versions | 21:44 |
| drobilla | e.g. if an incompatible lilv 1 comes out, current things needn't break | 21:45 |
| drobilla | It should really be 1, but 0 turned into the widely used releases, so.. oh well | 21:45 |
| badosu | lol, wy does jalv depend on a version that was not even released? | 21:47 |
| badosu | drobilla: that makes sense, better than just appending the number to the name | 21:48 |
| drobilla | I assume you mean jalv in svn, which, well, isn't released, so... | 21:49 |
| drobilla | badosu: it *is* just appending the number to the name | 21:49 |
| badosu | yeah, but with a - in the middle | 21:49 |
| drobilla | Well, yeah | 21:50 |
| badosu | oh shit, I can't just uninstall my lilv package >.< | 21:50 |
| badosu | ok, gotta eat, cya later | 21:50 |
| *** gianMOD has joined #lv2 | 21:51 | |
| *** gianMOD has quit IRC | 21:53 | |
| *** gianMOD has joined #lv2 | 21:54 | |
| *** gianMOD has quit IRC | 21:58 | |
| *** falktx has joined #lv2 | 22:03 | |
| grejppi | badosu: the ui generator you're proposing would still depend on lmms widgets such as the knobs, no? | 22:08 |
| badosu | grejppi: yes and no. if we expose the internal grid LMMS could tweak the controls the way it wants | 22:09 |
| grejppi | badosu: how would "the internal grid" be implemented then? | 22:10 |
| badosu | grejppi: By creating a QLayout that inserts controls read in the provided Lilv node | 22:11 |
| badosu | I don't rally understand you question | 22:11 |
| badosu | oh no, lilv source depends on sord source :-( | 22:12 |
| *** gianMOD has joined #lv2 | 22:16 | |
| drobilla | I blame pianoteq :) | 22:17 |
| rgareus | badosu: and sord depends on serd.. | 22:18 |
| badosu | oh my god, :-( | 22:18 |
| rgareus | well it's a nice clean abstraction | 22:18 |
| badosu | We should develop using released versions so that I don't have to build the entire dependency tree | 22:18 |
| rgareus | serd depends on libc | 22:19 |
| badosu | this is fine, the problem is not to have denpendencies | 22:19 |
| rgareus | yes, pulling this all into a single LV2-stack is somewhere on the todo list | 22:19 |
| badosu | no, I mean | 22:20 |
| rgareus | ie a one-stop lib. (that internally just consists of sord+serd+lilv and maybe suil) | 22:20 |
| badosu | Arch already provides packages for lilv, serd and sord | 22:20 |
| badosu | They work fine | 22:20 |
| badosu | I don't have a problem with this | 22:20 |
| badosu | The problem is that the development version of these libs depend on the development version of the other libs | 22:20 |
| rgareus | badosu: I install them to $HOME/lib | 22:21 |
| rgareus | badosu: then set LD_LIBRARY_PATH and PKG_CONFIG_PATH | 22:21 |
| rgareus | done | 22:21 |
| badosu | I am not saying this can't be done | 22:21 |
| badosu | It's just unnecessary overhead to collaborate on a simple project | 22:21 |
| rgareus | alternatively you can roll your own package | 22:21 |
| badosu | yeah, this would be one solution | 22:22 |
| badosu | Aur has the arch-svn package, but it's outdated | 22:23 |
| rgareus | development version of of libX depending on developmebt version of libY .. news at 11. | 22:23 |
| badosu | I am sorry if this is obious to you, but I am not used to this | 22:23 |
| rgareus | it's quite normal | 22:24 |
| rgareus | one example glib + gtk | 22:24 |
| rgareus | but even the kernel does this for new new feature | 22:24 |
| badosu | I am sorry, I am probably wrong, but I find this very bad | 22:25 |
| rgareus | ABI is forward compatible but never backwards | 22:25 |
| badosu | For example, to collaborate on jalv, I ahve to build lilv from source | 22:25 |
| rgareus | new function available.. the lib needs to support the function and the system underneath | 22:25 |
| badosu | to build lilv from source I have to build sord | 22:25 |
| rgareus | badosu: normal bussines. not only for LV2 | 22:26 |
| badosu | rgareus: I know, you already said this is obvious to you | 22:26 |
| badosu | but it's hard to me to understand why this is accepted | 22:26 |
| rgareus | badosu: there is no other way, is there? | 22:26 |
| badosu | To use only released versions? | 22:27 |
| rgareus | badosu: imagine you write a new driver.. and expose its funtionality though libasound | 22:27 |
| rgareus | badosu: you need to have both the kernel and lib-part above. | 22:27 |
| rgareus | badosu: for a 'normal user' this is not a problem.. but if you're a developer, things are different | 22:28 |
| rgareus | badosu: but yes, the current lilv <> suil situation is not 'normal' | 22:28 |
| rgareus | oops lils <> serd/sord | 22:28 |
| rgareus | badosu: "normally | 22:28 |
| rgareus | " serd/sord are API and ABI compatible | 22:29 |
| badosu | rgareus: I don't mhaving to build a lib or another once in a while | 22:29 |
| rgareus | there has been a recent major change.. | 22:29 |
| badosu | but the whole dependendy tree is quite annoying | 22:29 |
| rgareus | in the past working on lilv-dev was possible to use existing released versions of sord/serd. | 22:29 |
| badosu | for example, imagine that for building libreoffice you had to build gtk, cairo and X | 22:30 |
| rgareus | badosu: gtk & cairo yes. there was a time when libreoffice required dev versions of those | 22:30 |
| badosu | when you just wanted to push a one liner | 22:30 |
| rgareus | badosu: due to a threading issue in pango | 22:30 |
| badosu | :-( | 22:30 |
| badosu | Ok, I'll stop crying and getting back to work | 22:31 |
| rgareus | if there is a bug in an underlying lib AND your new version requires this bug to be gone.. -> recompile the whole stack. | 22:32 |
| rgareus | well, drobilla can we have new serd/sord releases anytime soon? | 22:32 |
| drobilla | badosu: I can just not fix bugs. Would you prefer that? ;) | 22:53 |
| drobilla | The track record for ABI compatibility with these libraries is pretty damned good, frankly. | 22:54 |
| drobilla | rgareus: I suppose | 22:54 |
| badosu | drobilla: well, alternatively you can release bugfixes from ground up | 22:54 |
| drobilla | rgareus: Previously your requests for that were interspersed with an equal number of changes :) | 22:54 |
| drobilla | This seems to have tapered off, now | 22:54 |
| rgareus | drobilla: yes, you did a great job. I think it's the first time that compat is broken. | 22:54 |
| rgareus | it's just that the time between current release vs last-release is quite long. | 22:55 |
| drobilla | badosu: This benefits almost nobody, makes everything slower, and makes it impossible for me or anyone else to ensure that a problem is *actually* fixed top down | 22:55 |
| drobilla | Anyway, as rgareus said, this is highly irregular | 22:55 |
| badosu | drobilla: ok, I am not here to argue what you should do with your own library | 22:56 |
| badosu | I was just being a nuisance | 22:56 |
| drobilla | Well, building a bunch of stuff is annoying | 22:56 |
| rgareus | badosu: you're just unlucky to come at a wrong time.. | 22:56 |
| drobilla | Which is the main reason why it's all slated to go in LV2 itself | 22:56 |
| drobilla | But that's a whole new set of problems to deal with | 22:57 |
| badosu | I like the current model, serd and sord separated from suil | 22:58 |
| badosu | I guess there are uses for them outside lv2 | 22:58 |
| drobilla | This is a case of convenience trumping modularity, straight up, which is pretty unfortunate, but at least for the libraries that are solely LV2 related, they have little utility outside of it anyway | 22:58 |
| badosu | I mean, separated from lilv | 22:58 |
| drobilla | Yes. Those two need to merge into one thing as well, but will always be separate | 22:59 |
| drobilla | Soon as I figure out how to do so without sacrificing serd's main claim to fame, speed | 23:00 |
| badosu | weird, waf is not giving priority to /usr/local/lib even with LD_PRELOAD setup | 23:00 |
| drobilla | LD_PRELOAD is purely a runtime thing. | 23:01 |
| badosu | shouldnt ./waf configure --libdir=/usr/local/lib take care of this? | 23:02 |
| drobilla | Take care of what, exactly? | 23:03 |
| drobilla | That should install libraries to /usr/local/lib | 23:03 |
| drobilla | It will not magically affect the linker's behaviour | 23:05 |
| drobilla | LD_LIBRARY_PATH is the env var you want for that | 23:05 |
| badosu | hmmm... ok | 23:05 |
| drobilla | Though I believe /usr/local/lib takes precedence over /usr/lib by default anyway | 23:05 |
| badosu | yeah, it should right? | 23:05 |
| badosu | yeah, I already set LD_LIBRARY_PATH, that's what I meant previously | 23:06 |
| drobilla | But what configure scripts find is a pkg-config problem | 23:06 |
| badosu | ok, found a PKG_CONFIG_PATH variable | 23:08 |
| drobilla | There is a thing that lets you build a stub debian package easily to avoid dependenc6y issues and let you remove the system package in favour of a /usr/local installed one, but I forget what it's called. | 23:13 |
| badosu | ok, in case this is useful for anybody, this worketd out for me | 23:14 |
| badosu | PKG_CONFIG_LIBDIR=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig ./waf configure | 23:15 |
| badosu | this would be nice to puto on the build instructions for lv2-related projects | 23:16 |
| badosu | drobilla: how collaboration works for people without write access? I just send an email or a link with the patch? | 23:18 |
| *** edogawa has quit IRC | 23:20 | |
| drobilla | That isn't really LV2 related, or even waf related. | 23:29 |
| drobilla | Why some distros ship a pkg-config where this isn't the default is beyond me, but they shouldn't. | 23:29 |
| drobilla | badosu: yes, either way. | 23:29 |
| drobilla | badosu: or ticket | 23:30 |
| badosu | ok, please send me your email address via private message if that's fine for you | 23:33 |
| badosu | I prefer email | 23:33 |
| drobilla | The one scattered absolutely everywhere in the projects you've been hacking on? | 23:35 |
| drobilla | Um, yes, better keep that private! :P | 23:35 |
| badosu | :-) | 23:38 |
| *** falktx has quit IRC | 23:40 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!