| Socapex | I have to say guys, your website is really really nice :) | 00:01 |
|---|---|---|
| falktx | hmm, there's an issue... | 00:01 |
| falktx | gtk2 widgets don't have x11 win Ids until they are realized | 00:01 |
| falktx | I guess now I need jalv.qt5 to test it | 00:05 |
| * falktx can't make waf find moc-qt5 | 00:12 | |
| Socapex | anyone uses a mac with macports? how would I add my lv2 install to macports pkg-config (in /opt/local)? | 00:17 |
| Socapex | ps. Decided to build with waf, as I wish to keep the last remaining shadows of sanity I have ^_^ | 00:17 |
| falktx | errrm.... | 00:18 |
| falktx | /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1034:4: error: #error "You must build your code with position independent code if Qt was built with -reduce-relocations. " "Compile your code with -fPIC or -fPIE." | 00:18 |
| falktx | # error "You must build your code with position independent code if Qt was built with -reduce-relocations. "\ | 00:18 |
| drobilla | falktx: No. reparenting is far more flakey | 00:19 |
| Socapex | waf: error: no such option: --lv2-dir | 00:23 |
| Socapex | sigh -.- | 00:23 |
| drobilla | Socapex: --prefix | 00:27 |
| drobilla | (Like roughly every other configure/build thing ever) | 00:27 |
| drobilla | falktx: AFAIK gtk plug/socket only works on X11 anyway | 00:27 |
| Socapex | drobilla: ty, I rtfmed a bit and got it ^_^ | 00:28 |
| Socapex | drobilla: Did I miss the sratom dependency, or is it actually missing from docs? | 00:31 |
| Socapex | Would be nice to add it to the lilv page. Not a big deal though. | 00:33 |
| falktx | drobilla: this qt5 thing is going to be complicated... | 00:34 |
| falktx | but now I have to update lilv first, which I guess requires the whole thing too... :S | 00:36 |
| *** gianMOD has joined #lv2 | 00:37 | |
| Socapex | Does anyone have a good lilv example to start me off? | 00:41 |
| *** rncbc|AFK has quit IRC | 00:42 | |
| *** gianMOD has quit IRC | 00:42 | |
| badosu | Socapex: that jalv.qt example that I passed to you should use lilb | 00:59 |
| badosu | *lilv | 00:59 |
| badosu | Socapex: I need to host lv2 plugins on qt as well, though Im on qt4 | 00:59 |
| Socapex | badosu: ah perfect! Right now I'm just going through doc. Once everything is setup, Qt Creator actually auto-completes lilv_, which will help alleviate the initial pain. | 01:00 |
| badosu | Socapex: if you ever publish this code let me know, every reference is useful | 01:04 |
| Socapex | badosu: Of course! Right now I'm just going to protoype, play around with lib, bang head on keyboard etc. But if I get a prototype working I'll push to my github. | 01:05 |
| Socapex | badosu: Adding plugin support for the actual project I'm working on is probably at least .5 year away I would believe. | 01:06 |
| falktx | drobilla: I got everything to build, but there's an issue. gtk2 widgets don't have win ids until they are about to being shown | 01:07 |
| falktx | drobilla: but I need to know that winId to do embed in qt5 | 01:07 |
| badosu | Socapex: I know how you feel, I want lv2 support on lmms | 01:08 |
| badosu | Socapex: grejppi's already done some work, but it seems hard | 01:08 |
| Socapex | badosu: oh that *has* to be a priority on lmms! | 01:09 |
| badosu | falktx: I can't believe you're going to add qt5 support on suil in such a little period of time | 01:09 |
| badosu | falktx: great productivity | 01:09 |
| Socapex | badosu: especially for the instruments, I think your audience would really appreciate it :) | 01:10 |
| badosu | Socapex: yeah, I know. But surprisingly we have many other requests with more priority | 01:10 |
| badosu | Socapex: I guess the power users already discard lmms due to lack of lv2 support in a snap | 01:11 |
| badosu | Socapex: so the users that remain do not care very much | 01:11 |
| Socapex | badosu: really? Well its been a while I haven't used lmms so I don't know what state it is now. But yeah, the VST issue eventually dragged me away from linux for audio :( | 01:11 |
| badosu | Socapex: actually VST support on lmms works surprisingly well | 01:12 |
| badosu | Socapex: it's not perfect, but lots of complicated VSTs work | 01:12 |
| Socapex | badosu: oh wow, you have that!? that is awesome! | 01:12 |
| Socapex | badosu: Its been a long long time (I was using a fedora 3 audio build buy a dude... can't remember the name) | 01:12 |
| badosu | Socapex: 32 bits VST dll should work on LMMS | 01:13 |
| badosu | Socapex: *ahem* most of the time | 01:13 |
| Socapex | badosu: lol | 01:13 |
| badosu | also, there's a DSSI wrapper for VST, maybe you could check that for other applications | 01:15 |
| drobilla | falktx: Why can't you just do it the way gtk2_in_qt4 does it? | 01:16 |
| falktx | drobilla: qt5 doesn't work like that | 01:16 |
| falktx | it also seems wrong. the host is the one that has to do reparenting, not the ui | 01:17 |
| falktx | calling gtk_widget_show_all doesn't work :( | 01:18 |
| drobilla | The host passes the parent widget into which the UI should create itself | 01:18 |
| drobilla | The "create a UI, then we can reparent it or embed it or show it or whateer" was the initial plan. It was wrong. | 01:19 |
| drobilla | Which is why the parent thing is a feature | 01:19 |
| falktx | the ui is created first, and send to the host | 01:19 |
| falktx | the host gets the UI and reparents or adds as subwidget | 01:19 |
| falktx | the qt4 code is letting the UI controlling the host reparenting | 01:20 |
| drobilla | Uh, okay. | 01:20 |
| drobilla | You are contradicting yourself for starters, and what is the "UI"? | 01:20 |
| drobilla | The LV2 UI is not reparenting anything. | 01:20 |
| falktx | the qt4 code has this: | 01:21 |
| falktx | GtkWidget* const plug = gtk_plug_new(wrap->winId()); | 01:21 |
| falktx | wrap is the (future) host widget | 01:21 |
| falktx | the gtk UI creates a bridge between the host window and ui widget | 01:22 |
| falktx | instead it should be something like | 01:22 |
| drobilla | You aren't listening. | 01:22 |
| drobilla | Yes, you think it should just create a widget with no parent then the host can reparent or whatever. | 01:22 |
| drobilla | I though this 4 years ago, too. | 01:22 |
| drobilla | It doesn't work (well, at least). | 01:23 |
| drobilla | So, as I've said twice now, the host passes a parent widget and the UI (and/or suil) uses this as parent. | 01:23 |
| drobilla | It was changed to be this way deliberately. | 01:23 |
| falktx | heh | 01:23 |
| falktx | so the QX11EmbedContainer use is wrong | 01:24 |
| falktx | it's not containing anything | 01:24 |
| drobilla | ... ? | 01:24 |
| drobilla | It contains the UI | 01:24 |
| falktx | well it is, yeah, but qt doesn't really know it | 01:25 |
| drobilla | That's what QX11EmbedContainer is for. It implement XEMBED | 01:25 |
| falktx | the embedClient() function that QX11EmbedContainer was created for is never called | 01:25 |
| drobilla | The Gtk things are created with its child ID | 01:25 |
| drobilla | Yes, that's weird. I don't know if this circumvents XEMBED or not. | 01:28 |
| drobilla | AFAIK events work... | 01:28 |
| drobilla | If not it's a pretty severely flawed design | 01:29 |
| falktx | I though we're going for something like: | 01:29 |
| drobilla | Reparenting is the devil. I'm not sure why you seem to actively want to do it. | 01:29 |
| Socapex | Does lilv send errors to perror or something of the likes to debug world creation being NULL? | 01:29 |
| falktx | 1. host gets ui widget | 01:30 |
| falktx | 2. host does embedThisWinId() | 01:30 |
| drobilla | Socapex: It prints to stderr | 01:30 |
| Socapex | drobilla: ok, ty | 01:30 |
| falktx | drobilla: anyway, qt5 does not have a special class to handle xembed, and I don't think it ever will | 01:31 |
| falktx | drobilla: it does have however a QWidget::createWindowContainer() which can embed external windows | 01:32 |
| falktx | drobilla: but since we can't know the gtk2 win id before it's shown (and flushed), it can't work on qt5 | 01:32 |
| falktx | it *needs* the win Id before creating the widget | 01:32 |
| drobilla | falktx: Is there no winId anymore? | 01:33 |
| falktx | there is | 01:33 |
| falktx | but there won't be xembed support like tha qt4 class | 01:33 |
| falktx | x11-on-qt5 can work at least | 01:34 |
| drobilla | Well, I knew we were only going to get so far until somebody had to actually implement XEMBED | 01:34 |
| drobilla | Leave it to Qt to force that hand | 01:34 |
| drobilla | Doesn't what this createWindowContainer thing does kind of inherently imply there's an embed implementation in there? | 01:36 |
| falktx | there is, sorta | 01:36 |
| falktx | but with x11 vs wayland vs mir. it would get very tricky to implement xembed | 01:36 |
| falktx | qt5 might be running on wayland, so xembed wouldn't work | 01:36 |
| falktx | createWindowContainer assumes the winId matches the qt window backend | 01:37 |
| drobilla | So do we until we have a real reason to otherwise. Non-issue | 01:38 |
| *** gianMOD has joined #lv2 | 01:38 | |
| drobilla | Well, you can maybe create an unplugged gtkplug then add it with the Qt thing | 01:39 |
| drobilla | I am not sure if an unplugged gtkplug has a window ID at all though | 01:39 |
| drobilla | or use a socket embedded in some normal Qt thing and use the Gtk XEMBED implementation on both sides | 01:41 |
| drobilla | Welcome to why these nightmares are isolated in a library :) | 01:42 |
| *** gianMOD has quit IRC | 01:43 | |
| badosu | I noticed you two talking about xembed and I got worried, suilv's x-platform compatibility is good for Windows and OSX? | 01:45 |
| badosu | This is very important for LMMS | 01:46 |
| falktx | no | 01:47 |
| drobilla | badosu: Gtk<=>Qt does not work on Windows or Quartz (without X11) | 01:47 |
| falktx | only gtk2 has something about cross platform | 01:47 |
| badosu | So it will not be so easy as I imagined | 01:48 |
| falktx | you'll have to do the cocoa-in-qt4 and win-in-qt4 modules | 01:48 |
| drobilla | Distributing binary plugins that use Qt or Gtk is essentially impossible anyway | 01:48 |
| drobilla | The native window types on each platform work. | 01:48 |
| * falktx is finding suil code a bit hard to understand | 01:48 | |
| badosu | Ok, so this will have to be linux-first and then try to implement it for windows | 01:49 |
| Socapex | drobilla: Wow, this is *really* promising! https://www.dropbox.com/s/82pgvuom1xynioc/Screenshot%202015-02-22%2020.48.42.png?dl=0 | 01:49 |
| Socapex | practically 30 minutes with doc | 01:49 |
| Socapex | xD | 01:49 |
| drobilla | badosu: All the libraries, including suil, work fine on Windows/OSX | 01:49 |
| badosu | I really thought that I wouldnt have problems with QT plugins though | 01:49 |
| drobilla | badosu: That situation itself is inherently problematic. | 01:49 |
| drobilla | badosu: How do you know the plugin uses exactly the same version of Gtk/Qt that you do? | 01:50 |
| Socapex | oh oops, meant to ping badosu. Oh well | 01:50 |
| falktx | drobilla: I'm going to give up on this :( | 01:50 |
| drobilla | and, for the eleventy billionth time, suil doesn't get in the way if the host and UI type are the same | 01:51 |
| drobilla | seriously people | 01:51 |
| drobilla | Qt in Qt (etc) it just passes the damned widget handle. Obviously. | 01:51 |
| drobilla | Please for the love of all that is holy let me stop having to say this :P | 01:51 |
| badosu | wow, nice work Socapex :-) | 01:51 |
| drobilla | falktx: *shrug* okay. | 01:52 |
| falktx | drobilla: but maybe I can get jalv.qt5 working, even if without any cross-ui type support | 01:52 |
| falktx | the issue right now is moc... | 01:52 |
| badosu | drobilla: hahaha, I got it sorry | 01:52 |
| Socapex | badosu: Well its not much, but its a really simple & nice API :D | 01:52 |
| drobilla | The issue is always moc | 01:52 |
| badosu | yeah, I lost some hours trying to figure out how to use moc with make | 01:53 |
| badosu | falktx: I know you don't use Make, but if this helps you: https://github.com/badosu/BadAmp/blob/master/Makefile#L22-30 | 01:53 |
| badosu | it's for qt-4 | 01:53 |
| drobilla | I don't really get it. They hardly seem to give much of a crap about compatibility of numerous other things. It's 2015, drop your horrible 90's preprocessor designed to work around garbage C++ implementations from decades ago already... | 01:54 |
| falktx | it's not an issue in PyQt btw | 01:56 |
| falktx | python hides all that moc madness | 01:56 |
| falktx | drobilla: jalv-qt4 and qt5 code is the same, except for Qt4UI and include jalv_qt4_meta.hpp | 01:58 |
| falktx | drobilla: so maybe the file should renamed jalv_qt.cpp and some macros added | 01:59 |
| badosu | drobilla: this widget-passing suilv implementation is really cool | 01:59 |
| badosu | drobilla: I am just worried that I'll have to individually treat each case individually | 02:00 |
| falktx | drobilla: oh there's one "TRUE" undefined var. It should be lowecase "true" anyway. | 02:00 |
| badosu | drobilla: for example, is it possible to use a X11UI widget on Windows? | 02:00 |
| falktx | drobilla: patch http://kxstudio.sourceforge.net/Paste/repo/toDCa | 02:00 |
| badosu | s/widget/plugin | 02:00 |
| drobilla | badosu: Theoretically, probably. | 02:01 |
| drobilla | badosu: Is X11 present on 99.9999999999999% of normal Windows machines? No. | 02:01 |
| badosu | drobilla: hahaha, I meant practically | 02:02 |
| badosu | drobilla: like if there was some kind of fake X11 server to make it work | 02:03 |
| drobilla | falktx: OK, thanks. Yes, copy pasting the whole thing is crazy if it's nearly identical anyway. Same thing with gtk2/3 | 02:03 |
| Socapex | So from a high-level, if I understand correctly, LV2 plugins simply have ports and other classes. I want to connect these ports with lilv world ports. Then do I fill them up using a callback? | 02:03 |
| drobilla | badosu: That'd be the 0.00000000000000001% | 02:03 |
| badosu | drobilla: so this implies that it's impossible to distribute openAv plugins to a Windows audience? | 02:03 |
| badosu | drobilla: since they use X11UI | 02:04 |
| drobilla | badosu: OpenAV uses a thin abstraction layer (pugl) and can provide native windows on X11/OSX/Windows | 02:04 |
| drobilla | Socapex: Who is "I"? host or plugin? | 02:04 |
| drobilla | Socapex: Ports are connected to buffers. Those buffers are processed in run() | 02:05 |
| badosu | drobilla: oh, wait a minute, so the problem is not really the type of UI, but if the plugin uses non supported code? | 02:05 |
| Socapex | drobilla: the host. | 02:05 |
| drobilla | Socapex: Well, they're your buffers, then. Why would you need a callback to fill your own buffers, and who would be calling it? :) | 02:05 |
| badosu | by non-supported-code I mean, drawing expecting X for example | 02:05 |
| badosu | ok, I'll give it a try this week, Ill bother with Windows and OSX later | 02:06 |
| Socapex | drobilla: hmmm, I meant filling the buffers of the file... I have limited knowledge with this (did work with AUs though). | 02:06 |
| drobilla | badosu: I don't understand your question. The type of the UI is the relevant thing. | 02:06 |
| Socapex | drobilla: buffers of the plugin, sorry | 02:06 |
| drobilla | Socapex: What file? | 02:06 |
| drobilla | Socapex: The buffers are owned by the host | 02:06 |
| drobilla | Socapex: You fill them, well... however. | 02:06 |
| badosu | drobilla: openAv uses ui:X11UI last time I checked, this means that it should pass a X window id | 02:07 |
| drobilla | e.g. memset will fill them with silence easily enough | 02:07 |
| drobilla | badosu: Yes, but on Windows, it would not. | 02:07 |
| drobilla | badosu: As I said, it uses a thin compatibility layer. They are not implemented in raw X11 | 02:07 |
| badosu | drobilla: ok, so you answered my question. Using pugl should not matter in this case | 02:07 |
| drobilla | badosu: That layer works with the native window type on whatever platform. | 02:07 |
| Socapex | drobilla: allright, so what I thought. Sorry if I don't explain very well. I fill up the port buffers (callback or whatever is available). Thats how I transfer audio to the plugin. Does the plugin provide a callback to get audio back from it? | 02:07 |
| badosu | drobilla: unless you extend a new ui type | 02:07 |
| drobilla | badosu: Well, it matters because that's the thing that makes it work on all three platforms | 02:07 |
| badosu | drobilla: I understand this, but this is also true for QT | 02:08 |
| drobilla | Socapex: You seem to have some kind of fundamental misunderstanding | 02:08 |
| badosu | drobilla: with the exception that QT requires a QT-aware host | 02:08 |
| drobilla | Socapex: The host points the plugin to buffers | 02:08 |
| drobilla | Socapex: You then run() the plugin and it does stuff, reading the input ones and writing the output ones | 02:08 |
| drobilla | Socapex: They are your buffers. You own them, passed them to the plugin, and still own them. There is no funny buffer callback business necessary. | 02:09 |
| badosu | drobilla: don't worry, I'll discover these details when I implement it | 02:09 |
| drobilla | badosu: Yes, a Qt UI could probably provide native UI types too in a similar way. | 02:09 |
| Socapex | drobilla: It looks much more simple than I thought, but if I'm doing realtime, don't I need a way to get lets 512 processed frames when they are ready? So I can feed my soundcard? | 02:10 |
| drobilla | Well, maybe. main loops and multiple toolkits and all that... | 02:10 |
| drobilla | Socapex: Yeah. run(). | 02:10 |
| Socapex | drobilla: oh, so you specify a number of frames to run! | 02:11 |
| drobilla | Socapex: ... do at least look at the header, first. :P | 02:11 |
| Socapex | drobilla: ^_^ sowwy. Quick question that just popped up in my head, I'm sure you have a solution, but what about the delay induced in multiple instances of plugins chained together. If each has to wait 512 frames before getting the data, wouldn't that cause ginormous delay? | 02:12 |
| drobilla | Socapex: no. | 02:13 |
| Socapex | drobilla: I guess I could run it for less samples. I'm just not used to this way of doing audio. Allways used callbacks. Mind blown | 02:13 |
| drobilla | frame 0 in that 512 frame block is the same frame 0 for every plugin in the chain. | 02:14 |
| drobilla | Socapex: ? this is how basically every plugin interface ever works | 02:14 |
| Socapex | not AU | 02:14 |
| Socapex | but frame 0 isn't the same if the plugins are chained | 02:14 |
| Socapex | gate -> eq -> compressor -> reverb | 02:15 |
| Socapex | frame 0 gets processed sequentially | 02:15 |
| drobilla | yes it is, unless they are latent. | 02:15 |
| drobilla | audio time != real time. | 02:16 |
| drobilla | if frame 0 is "now", then if I process it through 999999999999999 non-latent plugins, it's still frame 0, "now" | 02:16 |
| Socapex | hmmm | 02:16 |
| Socapex | basically processing is faster than realtime? Is that what you are trying to say? | 02:17 |
| drobilla | It may or may not be. | 02:17 |
| drobilla | If you can't do it fast enough you'll get a dropout, sure | 02:17 |
| Socapex | unless I use latency inducing plugins (lookahead etc) | 02:17 |
| drobilla | My point is "each has to wait 512 frames before getting the data" is wrong thinking | 02:18 |
| Socapex | btw thank you for taking the time to explain all this | 02:18 |
| drobilla | It's the same 512 frames of data | 02:18 |
| drobilla | i.e. represents the same chunk of time | 02:18 |
| drobilla | y/w | 02:18 |
| Socapex | thats really interesting. I come from a tech background, so I think in a very "practical" or "end-user" way | 02:19 |
| Socapex | *audio tech | 02:19 |
| drobilla | All that callback loopiness has confused you. It's not that complicated :) | 02:20 |
| drobilla | Think of plugins as glorified functions. | 02:20 |
| Socapex | mind == loopy | 02:20 |
| Socapex | xD | 02:20 |
| badosu | hahaha | 02:21 |
| drobilla | It's easy to see if you consider 1 frame blocks, I suppose. | 02:21 |
| drobilla | Every frame in must be a frame out | 02:21 |
| drobilla | So if I take frame 0 and do a bunch of stuff to it and somehow it's become frame 27, well... what about this huge gap? | 02:22 |
| Socapex | yes | 02:22 |
| Socapex | no gap | 02:23 |
| drobilla | ('course some plugins *are* latent, so things like that can actually happen, but simple hosts can just blissfully pretend it doesn't) | 02:23 |
| Socapex | hehe, well running with as little samples as possible will help. In my specific application, it will matter. But we will provide some basic plugins that are as non-latent as possible. If users want to add latency then they are welcome to do it of course | 02:25 |
| Socapex | I'm super excited about LV2 anyways, so far the doc is minimal but effective and clear. Also it was much easier to setup than I imagined! | 02:26 |
| drobilla | What environment are you running in? | 02:26 |
| Socapex | I'll be working on integrating plugins to obs-studio (broadcasting software), so as live as it gets | 02:27 |
| drobilla | Good to hear, particularly considering how often I hear people piss and moan about how atrocious the documentation/everything is. Thanks :) | 02:27 |
| drobilla | Well, I just mean often your latency/block size is determined outside your application anyway | 02:27 |
| drobilla | But it's a tradeoff. Lower latency = higher overhead | 02:28 |
| drobilla | Otherwise we'd all be running everything at 1 frame | 02:28 |
| Socapex | haha, well its pretty logical! create a world, get plugins, iterate through them... :) | 02:28 |
| Socapex | yeah | 02:28 |
| Socapex | We'll have to expose the parameter (as all DAWs do anyways) | 02:28 |
| Socapex | I guess your doc could use examples, but the jalv and lv2file are clear | 02:29 |
| Socapex | and your website is sexy :) | 02:29 |
| drobilla | This is complicated by lilv not being an "official" LV2 project | 02:31 |
| drobilla | They'll probably be integrated into a sort of SDK thing soon | 02:31 |
| drobilla | but yes, those two serve as the usual simple host examples | 02:32 |
| drobilla | Generally spend more time on plugin documentation, since hosts are few and far between and new host authors hardly pop up every day | 02:32 |
| *** falktx has quit IRC | 02:33 | |
| drobilla | and thanks, redid the whole site recently | 02:34 |
| drobilla | That screenshot thingie could certainly use some work but it's way better than it was before | 02:34 |
| Socapex | well hopefully I wont be bugging *too* much, but I am still a student with limited experience in general. | 02:34 |
| drobilla | The spec docs are much better and more integrated with the site design in git now too, but not uploaded until the next LV2 release | 02:34 |
| Socapex | The slideshow is really nice :D | 02:34 |
| Socapex | It looks super pro, not what I was expecting, especially when you look at LADSPA website before lol | 02:35 |
| drobilla | I'm technically still a student. No excuse! :P | 02:36 |
| Socapex | haha, damn it! | 02:39 |
| *** gianMOD has joined #lv2 | 02:39 | |
| Socapex | allright, time for bed now. I wont sleep all night if I continue working on this :) | 02:41 |
| Socapex | thx all for the help, I'll see you later with updates on my host prototype | 02:41 |
| drobilla | ttyl | 02:42 |
| *** gianMOD has quit IRC | 02:44 | |
| *** gianMOD has joined #lv2 | 03:40 | |
| *** gianMOD has quit IRC | 03:45 | |
| *** NickSB2 has quit IRC | 03:53 | |
| *** gianMOD has joined #lv2 | 04:40 | |
| *** gianMOD has quit IRC | 04:46 | |
| *** Socapex has quit IRC | 05:22 | |
| *** gianMOD has joined #lv2 | 05:41 | |
| *** gianMOD has quit IRC | 05:46 | |
| *** edogawa has joined #lv2 | 06:07 | |
| *** gianMOD has joined #lv2 | 06:42 | |
| *** gianMOD has quit IRC | 06:47 | |
| *** gianMOD has joined #lv2 | 07:43 | |
| *** gianMOD has quit IRC | 07:48 | |
| *** ricardocrudo has joined #lv2 | 09:18 | |
| *** gianMOD has joined #lv2 | 09:21 | |
| *** gianMOD has quit IRC | 09:22 | |
| *** gianMOD has joined #lv2 | 09:22 | |
| *** EntropyS1nk is now known as EntropySink | 10:17 | |
| *** curlymorphic has quit IRC | 10:24 | |
| *** NickSB2 has joined #lv2 | 10:28 | |
| *** EntropySink has quit IRC | 10:29 | |
| *** EntropyS1nk has joined #lv2 | 10:29 | |
| *** EntropyS1nk has quit IRC | 10:38 | |
| *** EntropySink has joined #lv2 | 10:38 | |
| *** gianMOD has quit IRC | 10:56 | |
| *** gianMOD has joined #lv2 | 10:56 | |
| *** HarryHaaren has joined #lv2 | 11:16 | |
| *** gianMOD has quit IRC | 11:24 | |
| *** gianMOD has joined #lv2 | 11:41 | |
| *** sigma6 has joined #lv2 | 11:50 | |
| *** edogawa_ has joined #lv2 | 12:13 | |
| *** falktx has joined #lv2 | 12:13 | |
| *** edogawa has quit IRC | 12:17 | |
| *** gianMOD has quit IRC | 12:59 | |
| *** gianMOD has joined #lv2 | 13:00 | |
| *** ricardocrudo has quit IRC | 13:04 | |
| *** gianMOD has quit IRC | 13:04 | |
| *** gianMOD has joined #lv2 | 13:46 | |
| *** gianMOD has quit IRC | 13:46 | |
| *** gianMOD has joined #lv2 | 13:48 | |
| *** NickSB2 has quit IRC | 13:51 | |
| *** ricardocrudo has joined #lv2 | 14:22 | |
| *** curlymorphic has joined #lv2 | 14:51 | |
| *** gianMOD has quit IRC | 15:13 | |
| *** gianMOD has joined #lv2 | 15:15 | |
| *** edogawa_ has quit IRC | 15:23 | |
| bgola | drobilla: the waf file in the lilv repository doesn't contain the swig module, so it can't build the python bindings. | 15:26 |
| bgola | creating a new one with --tools=autowaf.py,swig works fine | 15:27 |
| *** gianMOD has quit IRC | 15:31 | |
| *** gianMOD has joined #lv2 | 15:42 | |
| *** edogawa has joined #lv2 | 15:43 | |
| falktx | bgola: I'm pretty sure it does, I used it for building the bindings | 15:56 |
| falktx | including py3 ones with some small modifications | 15:56 |
| bgola | falktx: i just cloned the svn repo, did ./waf and checked .waf*/extras/ , no swig.py there | 15:58 |
| bgola | falktx: http://pastebin.com/FvutHM6S not sure if im doing something wrong | 15:58 |
| falktx | bgola: I see it on 0.20 release in bindings/lilv.i | 15:59 |
| falktx | bgola: it's there on your list too, as lilv/bindings/lilv.i | 16:00 |
| falktx | bbl | 16:01 |
| bgola | falktx: i mean the waflib/extras/swig.py | 16:04 |
| bgola | when i run ./waf configure --bindings it says it can't find the waflib swig module | 16:05 |
| *** falktx has quit IRC | 16:06 | |
| drobilla | bgola: oops. | 16:39 |
| *** falktx has joined #lv2 | 16:44 | |
| drobilla | bgola: fixed | 16:45 |
| *** Socapex has joined #lv2 | 16:50 | |
| Socapex | Hello, I have a quick question. Using lilv, are all features supported, or only core, or is that my job to add the necessary features? If I have to add them, is it simply a case of including the correct extension headers, or is there more to supporting features? | 16:51 |
| drobilla | Socapex: It Depends™. Generally the whole point of a feature is to allow hosts to provide extended functionality, so yes, generally you have to implement something | 16:54 |
| falktx | you need to support the features yourself | 16:54 |
| bgola | drobilla: :) | 16:55 |
| bgola | drobilla: im testing now my mod/python stuff with the latest ingen revision | 16:55 |
| *** rncbc has joined #lv2 | 16:55 | |
| bgola | drobilla: btw, any plans on changing to git ? :P | 16:56 |
| Socapex | So if a plugin requires urid:map, Ill have to implement that. Are there at least headers to see what the plugin expects? | 16:56 |
| falktx | bgola: hehe, we keep asking him that | 16:56 |
| bgola | falktx: :P | 16:56 |
| falktx | Socapex: the plugin has requiredFeatures in its ttl to let hosts know what it needs in order to work | 16:56 |
| falktx | Socapex: it will also have optionalFeatures, which has the name implies are optional :) | 16:57 |
| Socapex | falktx: Yes exactly, but I have to implement its required features | 16:57 |
| falktx | yes | 16:57 |
| falktx | start with urid-map, that's the most common one | 16:57 |
| Socapex | So what is urid:map? | 16:57 |
| falktx | see its header file | 16:57 |
| Socapex | the required_features link work? lets see... | 16:58 |
| Socapex | ok. much impress! | 16:58 |
| Socapex | Maybe I should read the spec, because its a bit hazy how this whole thing works. | 17:01 |
| falktx | you should yes | 17:02 |
| falktx | Socapex: are you able to load eg-amp? | 17:02 |
| falktx | afaik that plugin has no dependencies | 17:02 |
| Socapex | falktx: It doesnt return NULL but crashes | 17:02 |
| Socapex | falktx: When I run() it | 17:03 |
| falktx | maybe you forgot to call activate or connect_port ? | 17:03 |
| Socapex | ah, connect_port? >.> | 17:03 |
| drobilla | bgola: Yes, but there'd be a million submodules and it would be absolute hell | 17:03 |
| * Socapex hides | 17:03 | |
| drobilla | bgola: Most of the libs are going to move to lv2, so after that | 17:03 |
| drobilla | Need to decide how to do that part, too. Submodules are probably more trouble than they're worth, since the libs are not useful outside an LV2 context anyway (unless serd and sord make it in there) | 17:05 |
| bgola | drobilla: ah yeah, moving the ibs to LV2 would help already :) | 17:06 |
| bgola | but why submodules? | 17:06 |
| bgola | (i just spent a few hours organizing my environment to have everything running with the latest revision, also updated the aur package lv2-svn to lv2-git ... ) | 17:07 |
| bgola | thats why im asking about svn x git :) | 17:07 |
| Socapex | falktx: So, I have a uri-map.lv2 in my libs folder when I installed LV2. That is the header, and I simply implement that? Do I have to implement all that is inside my lib folder except core? | 17:07 |
| drobilla | bgola: Well, in the case of my lad repo they are really totally separate projects | 17:07 |
| falktx | Socapex: you implement whatever you want | 17:07 |
| falktx | Socapex: but you should go as its needed by plugins | 17:08 |
| falktx | one thing at a time | 17:08 |
| Socapex | falktx: But to be compatible with all plugins, your theoretically need to implement everythiing | 17:08 |
| drobilla | I am still not sure what various distro policies are on single upstream packages that install a bunch of libraries | 17:08 |
| falktx | in theory yes | 17:08 |
| Socapex | wait a minute, lv2core doesnt provide implementation either? | 17:09 |
| drobilla | ... implementation of what? | 17:09 |
| falktx | lv2 is the sdk, it only tells you how things work | 17:09 |
| bgola | drobilla: yeah, each project under the lad svn repo would work if it was in a separeted git repo i think | 17:10 |
| falktx | hosts implement the sdk, and plugins too | 17:10 |
| drobilla | Aside from some utility things like atom/forge.h, the LV2 headers are just API definitions. The plugin is the implementation. | 17:10 |
| bgola | (i tried using git-svn to adjust it to my workflow but it didnt work... some kind of bug that i wasn | 17:10 |
| bgola | 't feeling like looking into) | 17:10 |
| drobilla | bgola: Yes, but then I'd have to manually build all of them individually which would be a huge PITA for me | 17:10 |
| Socapex | drobilla: I dont understand | 17:11 |
| falktx | Socapex: think of lv2 as a protocol, like html | 17:11 |
| Socapex | simple question, is LV2core provided as a lib, or do I have to implement it?? | 17:11 |
| * drobilla cringes | 17:11 | |
| drobilla | HTML is a protocol now, is it? :P | 17:11 |
| falktx | Socapex: webpages are made in html, and web browsers implement the spec | 17:11 |
| falktx | sorta | 17:11 |
| drobilla | Not sorta. At all. :P | 17:11 |
| falktx | it's the shortest example I can think of | 17:12 |
| drobilla | Socapex: A plugin is a binary that implements an interface. | 17:12 |
| falktx | s/protocol/spec, done | 17:12 |
| drobilla | Socapex: lv2.h is the interface that LV2 plugins implement | 17:12 |
| Socapex | is lilv your SDK? Do you provide an SDK? | 17:12 |
| drobilla | yes, no, mu, sort of. | 17:13 |
| Socapex | lol please, dont mix me up even more | 17:13 |
| Socapex | I thought that LV2 was a lib | 17:14 |
| drobilla | It isn't. | 17:14 |
| Socapex | the amount of work required to support it has just exploded | 17:14 |
| drobilla | That depends on what you want to support. | 17:14 |
| drobilla | It is not intended that every potential plugin in the universe work in every host. | 17:14 |
| Socapex | what plugins need | 17:14 |
| Socapex | I dont want instrument features | 17:15 |
| Socapex | but lets just talk of core | 17:15 |
| drobilla | Some plugins simply do not make sense in certain hosts at all. | 17:15 |
| Socapex | I need to code LV2core | 17:15 |
| Socapex | which, I would imagine is like shoving a pine-tree somewhere :) | 17:15 |
| drobilla | Well, you need to use that interface to do things with plugins... | 17:15 |
| drobilla | That's what a plugin is. | 17:15 |
| drobilla | Sounds like you already have, anyway, except for that whole running plugins on garbage buffers thing. | 17:16 |
| drobilla | Socapex: What is the programming environment you're most familiar with? | 17:16 |
| Socapex | drobilla: Qt or plain c++ | 17:16 |
| *** gianMOD has quit IRC | 17:16 | |
| Socapex | drobilla: lilv provides lv2core? | 17:16 |
| drobilla | Socapex: lv2.h (LV2_Descriptor) is the class interface. plugins are instances of this class. | 17:16 |
| drobilla | That's it. There is no "implementing" or "providing" lv2core (except by plugins), there is nothing for a library to do. | 17:17 |
| drobilla | plugins have a run() (etc) method. that's it. | 17:18 |
| *** ricardocrudo has quit IRC | 17:19 | |
| Socapex | drobilla: but they require for example urid:map | 17:19 |
| Socapex | drobilla: I need to implement that... | 17:19 |
| drobilla | You just went on and on about how we're only talking about lv2core :P | 17:20 |
| Socapex | lol | 17:20 |
| drobilla | Features, yes, you need to implement if you want to support them. That's the whole point of them. | 17:20 |
| Socapex | ok I gotta go, class is over. I'll connect back later to continue this conversation :) | 17:20 |
| drobilla | If you don't care about instruments, you probably don't need to implement almost any. | 17:20 |
| Socapex | allright, that is a good base. I'll came back to ask more of these questions | 17:21 |
| Socapex | ty for the time and help | 17:21 |
| Socapex | o/ | 17:21 |
| *** Socapex has quit IRC | 17:21 | |
| *** HarryHaaren has quit IRC | 17:21 | |
| *** Socapex has joined #lv2 | 17:36 | |
| Socapex | drobilla: its me again :O So, lv2core is just a spec and the plugin is in charge of being compatible. Extensions have to be coded by the host. | 17:37 |
| Socapex | drobilla: urid:map is basically a hashing function | 17:37 |
| drobilla | Well, "extensions" is a catch-all term for anything that extends the LV2 spec | 17:39 |
| drobilla | "features" are specifically things passed by the host | 17:39 |
| drobilla | lilv probably could/should implement urid among others, but in any case doesn't ATM | 17:39 |
| Socapex | yes. I can deal with that. So a simple hashing function, and I pass the function pointer to the plugin? | 17:41 |
| drobilla | It has to be collision-free, so not quite a general hashing function | 17:42 |
| Socapex | oh, collision free hash | 17:42 |
| Socapex | uhm, that exists? | 17:43 |
| Socapex | :P | 17:43 |
| drobilla | Well, you can implement it with a std::map or simple array with binary search or whatever | 17:43 |
| Socapex | yes I was going to do a map, though technically its not collision free. But would resolve collisions correctly I believe | 17:45 |
| drobilla | std::map is not a hash table, there is no such thing as collision | 17:45 |
| badosu | falktx: I tried ui:Qt5UI and was not very successful | 17:48 |
| badosu | I ran through the git log of lv2 and did not find the part where a Qt5 compatible widget is passed and glued with the ns specification | 17:49 |
| falktx | Socapex: you can just have a string-list which works fine | 17:49 |
| drobilla | badosu: You seem confused. It's just a URI to identify the type. | 17:50 |
| badosu | drobilla: I am :-) | 17:50 |
| falktx | Socapex: to get an urid you look for the string that matches, and add a new one if it's not there yet | 17:50 |
| drobilla | badosu: Nothing whatsoever is different API wise | 17:50 |
| falktx | Socapex: to get a uri you just do "return stringlist[urid]" or similar | 17:50 |
| badosu | drobilla: oh, so let me see if I understand this properly. Actually LV2 is a really, really thin wrapper | 17:51 |
| *** NickSB2 has joined #lv2 | 17:51 | |
| drobilla | badosu: The UIs are just void* at the end of the day | 17:51 |
| drobilla | badosu: The type URI tells the host what that void* actually is | 17:51 |
| badosu | drobilla: It is just a glue between rdf specifications and specification of the interface | 17:51 |
| badosu | drobilla: oh... ugh | 17:51 |
| badosu | drobilla: So I actually need to fix jalv.gtk to support QT5, I got it | 17:52 |
| Socapex | falktx: ty for that. I'm not to sure what the urid is, but I believe its just a map? And I return the URI once given urid? | 17:52 |
| drobilla | ugh? You have a better way? :P | 17:52 |
| badosu | drobilla: no, I am sorry for the word. It's just that I understood now my confusion | 17:52 |
| badosu | drobilla: we had somewhat discussed this yesterday, so it should already been obvious to me | 17:53 |
| drobilla | badosu: Well, suil deals with that stuff | 17:53 |
| falktx | Socapex: uri is a string, urid is a number. | 17:53 |
| Socapex | falktx: ok, so I provide unique numbers for strings | 17:53 |
| falktx | yes | 17:53 |
| Socapex | falktx: sounds fair enough. tyvm :) | 17:53 |
| falktx | as I said, a string list should do just fine | 17:53 |
| badosu | drobilla: yeah, thanks for the answers and sorry for the annoyance | 17:53 |
| Socapex | falktx: I dont know the stringlist container | 17:54 |
| falktx | "string list" as a generic term. use whatever your current code provides | 17:54 |
| Socapex | falktx: oh... just a list of strings ^_^ | 17:54 |
| falktx | aka string list :P | 17:54 |
| Socapex | lol | 17:55 |
| badosu | drobilla: where do I submit a patch for the projects hosted at dev.drobilla? LV2-dev mailing list? | 17:55 |
| drobilla | badosu: ticket or email me | 17:55 |
| badosu | drobilla: okay, if I find and implement any improvement I'll let you know | 17:56 |
| *** falktx has quit IRC | 18:02 | |
| *** falktx has joined #lv2 | 18:02 | |
| *** Socapex has quit IRC | 18:08 | |
| *** gianMOD has joined #lv2 | 18:18 | |
| *** sigma6 has quit IRC | 18:21 | |
| *** gianMOD has quit IRC | 18:24 | |
| *** ricardocrudo has joined #lv2 | 18:30 | |
| *** gianMOD has joined #lv2 | 18:31 | |
| *** gianMOD has quit IRC | 18:34 | |
| *** ricardocrudo has quit IRC | 18:39 | |
| *** Socapex has joined #lv2 | 18:41 | |
| *** Socapex has quit IRC | 18:47 | |
| *** rncbc is now known as rncbc|AFK | 19:42 | |
| *** Socapex has joined #lv2 | 20:13 | |
| *** Socapex has joined #lv2 | 20:13 | |
| Socapex | I don't think its in there but I'll ask anyways. Is there port iterator functions in lilv? If not, I guess it would be nice to have :) | 20:29 |
| drobilla | you get them by index, so... | 20:29 |
| Socapex | drobilla: but i'm not finding the getter by index... | 20:30 |
| Socapex | Am I blind today? most probably | 20:30 |
| drobilla | Apparently. ;) | 20:30 |
| Socapex | lol. help? pretty please? ^_^ | 20:31 |
| drobilla | Seriously? | 20:32 |
| drobilla | I literally can not imagine a reasonable search term that wouldn't lead you to the appropriate functions in lilv.h | 20:32 |
| Socapex | I can't find the accessor function by index... Seriously | 20:32 |
| Socapex | currently I'm getting how many ports with lilv_plugin_get_num_port | 20:33 |
| Socapex | I can loop through that | 20:33 |
| Socapex | But I don't see how I can access a port by index | 20:33 |
| Socapex | oh shit | 20:33 |
| drobilla | Let's play a game. | 20:33 |
| Socapex | *lilv_plugin_get_port_by_index | 20:34 |
| drobilla | Invent a function name that you think might be an appropriate one for a lilv function that gets a port by index. | 20:34 |
| Socapex | it was in PLUGINS, not PORTS :P | 20:34 |
| drobilla | mmhmm.. :P | 20:34 |
| Socapex | I would name it, lilv_port_get_by_index | 20:34 |
| Socapex | :P | 20:34 |
| drobilla | You'd be naming it pretty terribly, since you can't get a port from nothing. | 20:35 |
| Socapex | Anyways, I still think a LilvPorts itarotor collection would be nice. It would fit with all the rest of the lib. This is of course the thought of a 2 day user... So take it for what it is :) | 20:36 |
| Socapex | yeah I was just trying to save face... | 20:36 |
| drobilla | It'd be more tedious to use than a for loop by index anyway | 20:36 |
| drobilla | I suppose it would be more consistent, but I'm not all that keen on adding even more collection boilerplate to pretend C is typesafe (probably shouldn't have bothered in the first place) | 20:37 |
| Socapex | well what I mean is everything else I;ve used is iterators. So I don't know why that particular case is a standrad loop | 20:37 |
| Socapex | yes, consistent was the word I was looking for. I am not native english, sorry | 20:37 |
| drobilla | Socapex: Mainly because ports have a meaningful index, and the other things don't | 20:43 |
| Socapex | drobilla: I'll settle for that. I'm not really trying to defend the idea, but I guess it's just something to note. New users may be searching for port iterators cause they are used to that. Personally I don't mind one or the other. I expect much more challenging things than for loops to be coming my way | 20:44 |
| drobilla | Socapex: You're the first. But, yes. | 20:45 |
| Socapex | drobilla: I'm the first? O_o I feel special right now! (Queue Madonna song which I shall not name) | 20:46 |
| Socapex | xD | 20:46 |
| *** drobilla has quit IRC | 20:55 | |
| *** rncbc|AFK is now known as rncbc | 21:13 | |
| *** gianMOD has joined #lv2 | 21:54 | |
| *** rncbc has quit IRC | 22:01 | |
| *** gianMOD has quit IRC | 22:43 | |
| *** drobilla has joined #lv2 | 22:53 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!
