* drobilla wonders how an X11-free framebuffer pugl would work | 00:11 | |
badosu | surprised you expose your personal and dev email publicly, dont you receive lots of spam? | 00:17 |
---|---|---|
drobilla | Pretty much every developer does. How else could anyone contact you? | 00:18 |
drobilla | Not really. Not much that gets through the filter, anyway. | 00:18 |
badosu | well, usually via mailing lists | 00:19 |
badosu | for example, if I did not know about you via IRC I'd try sending the patch to lv2 mailing list | 00:20 |
badosu | and then hope the mantainer reads it :-) | 00:20 |
badosu | for example, abduco and dvtm are not suckless projects, but Marc uses the mailing list as the medium for collaboration | 00:21 |
drobilla | "usually"... go to your favourite directory full of source code and do grep Copyright | grep '@' | 00:21 |
badosu | ok, just did this on lv2 project | 00:23 |
drobilla | Trying to hide an email address is pretty much a lost cause anyway, unless you use an account per service setup | 00:23 |
badosu | the output was not really helpful | 00:23 |
badosu | I am not trying to hide an email address | 00:23 |
drobilla | Well, you seem surprised that I don't | 00:24 |
badosu | yeah, but I am not advocating for this | 00:24 |
drobilla | My point is, I literally do not know of a single developer who does | 00:24 |
drobilla | Might as well be surprised that the sky is blue :) | 00:24 |
badosu | ok drobilla I was just commenting | 00:24 |
*** gianMOD_ has joined #lv2 | 00:33 | |
*** gianMOD has quit IRC | 00:36 | |
*** gianMOD_ has quit IRC | 00:37 | |
badosu | drobilla: I am having a weird problem with lilv_port_get_name | 01:20 |
*** badosu has quit IRC | 01:22 | |
*** badosu has joined #lv2 | 01:23 | |
*** Anchakor_ has quit IRC | 03:16 | |
drobilla | badosu: did you try turning it off then back on again? | 04:40 |
badosu | I don't know what the issue | 05:04 |
badosu | sometimes it return the name of the port, sometimes it complains that: lilv_port_get_name(): warning: Plugin <http://bado.so/bad-amp> port has no (mand | 05:04 |
badosu | atory) doap:name | 05:05 |
badosu | sorry for the paste | 05:05 |
badosu | sometimes this function will return null | 05:06 |
badosu | and print the following message to stdout | 05:06 |
badosu | lilv_port_get_name(): warning: Plugin <http://bado.so/bad-amp> port has no (mandatory) doap:name | 05:06 |
badosu | which makes no sense, because I declared doap:name | 05:06 |
badosu | what I am doing is fairly trivial, see: https://gist.github.com/badosu/e58c99e421c474bd2c9f#file-gistfile1-cpp-L136-L138 | 05:07 |
badosu | this is what I am doing | 05:07 |
badosu | it's fairly trivial, just iterateing through the ports and printing their name | 05:08 |
*** badosu has left #lv2 | 05:09 | |
*** badosu has joined #lv2 | 05:09 | |
drobilla | You suuuuuuuuuuuuuuuure that port has a name? | 05:12 |
drobilla | check lv2info and/or paste ttl | 05:12 |
badosu | https://github.com/badosu/BadAmp/blob/master/amp.ttl | 05:13 |
badosu | also, lv2info shows the name for the port accurately | 05:14 |
drobilla | Hm, that message is wrong. It's lv2:name, not doap:name | 05:18 |
drobilla | (How this ended up such a mess is beyond me, we use 3 different name/label predicates...) | 05:18 |
badosu | oh, but why this indeterministic behaviour? | 05:18 |
drobilla | badosu: er... you are casing a pointer to Jalv's internal port struct to LilvPort | 05:19 |
drobilla | and needlessley copying it to boot | 05:19 |
badosu | well, I was reading the gtk code but I guess I am deumb | 05:19 |
drobilla | Generally best to check before casting something to the thing you need to make it compile, that it actually is that thing ;) | 05:20 |
badosu | so, on gtk code you store it as Port | 05:20 |
badosu | but when you retrieve it you cast to LilvPort | 05:21 |
badosu | :-( | 05:21 |
drobilla | Sure don't | 05:21 |
badosu | Ok, so forget about it | 05:21 |
drobilla | const Port* port = lilv->ports[i]; | 05:21 |
drobilla | lilv_whatever(port->lilv_port, ...) | 05:21 |
drobilla | Port is a struct in jalv_internal.h | 05:21 |
drobilla | not a lilv thing | 05:21 |
badosu | ok, so could you bother explaining this to me? | 05:22 |
badosu | You do this: g_array_append_vals(control_ports, &jalv->ports[i], 1); | 05:22 |
badosu | but then you do this later: const LilvPort* port = g_array_index(control_ports, LilvPort*, i); | 05:23 |
drobilla | That's admittedly a bit nasty | 05:23 |
drobilla | But you can cast a Port to a LilvPort* because that's the first field | 05:23 |
badosu | hmmm.... | 05:23 |
drobilla | You can't cast a Port* to a LilvPort*, which is what you're doing | 05:23 |
badosu | Ok, pointer math confusion on my side | 05:23 |
badosu | thanks for the patience to help me | 05:24 |
drobilla | Basically just don't do any ugly casts | 05:24 |
badosu | Sorry about that :-) | 05:24 |
badosu | LOL how did this work in the first place? | 05:24 |
badosu | ok, now I got it | 05:25 |
* drobilla didn't write that array code, for the record :) | 05:25 | |
badosu | I am not talking about that code, but mine | 05:26 |
badosu | How can this work sometimes and sometimes not | 05:26 |
drobilla | That every working is strange indeed | 05:26 |
badosu | funny | 05:26 |
badosu | great, it works flawlessly now | 05:27 |
badosu | thanks for the help | 05:27 |
drobilla | y/w | 05:27 |
badosu | I guess the first code was working gue to the use of g_functions | 05:28 |
badosu | becaus it's not possible, I can't even understand | 05:29 |
drobilla | The gtk code? | 05:29 |
badosu | yep | 05:30 |
drobilla | That works because e.g. if you have struct Foo { int bar; }, you can cast Foo* to int* | 05:31 |
drobilla | first thing in the struct, so the address of the Foo and the int are the same | 05:31 |
badosu | yeah, but I thought I was doing the same thing | 05:32 |
badosu | anyway, I already can list all the controls inside a plugin | 05:32 |
badosu | that's nice | 05:32 |
drobilla | badosu: Updated the gtk code to avoid that confusing cast-via-garray stuff | 05:45 |
badosu | nice! gonna pull it | 05:45 |
badosu | so is every control in lv2 a float? | 05:46 |
drobilla | Well, every ControlPort is, anyway | 05:48 |
drobilla | Properties tell you if it should be treated as integer, or an enumeration, etc | 05:49 |
badosu | yep, is just that jalv.gtk has that weird slider floating between 0.000-2.000 for example on an enum with 3 values | 05:50 |
badosu | wow, svn update pulls and merge changes silently | 05:51 |
badosu | differently from git, which complain if your index is dirty before git pull | 05:51 |
drobilla | It shows a combo box for enumerations | 05:51 |
drobilla | It will show a slider with ticks for a port with scale points that is not an enumeration | 05:52 |
drobilla | lv2:portProperty lv2:enumeration ; | 05:52 |
badosu | in this case calf vintage delay should change it's ttl | 05:52 |
drobilla | MDA Combo has an enumeration and a toggle | 05:53 |
badosu | because it just uses lv2core#integer | 05:53 |
drobilla | Yeah, some hosts treat anything with scale points as an enum, but this is wrong | 05:53 |
badosu | ok, so now that I am implementing a host I'll see all sorts of garbage on ttls | 05:53 |
drobilla | Weeeeeeelll it's not so bad | 05:54 |
drobilla | I need to make validation easier and more well-known to combat this | 05:54 |
drobilla | Though that wouldn't catch things like this, it's valid to have that property or not | 05:54 |
badosu | still, I don't understand why an integer could have a floating value | 05:55 |
badosu | as it's implemented on jalv.gtk | 05:55 |
badosu | It would make sense for it to be a knob with 3 fixed values | 05:55 |
badosu | in that case where there are 3 scale points | 05:55 |
* drobilla installs git in Windows VM | 05:56 | |
drobilla | ugh, soooo slow | 05:56 |
badosu | git on windows is reportedly slower | 05:56 |
drobilla | No sure what you mean by that. "integer could have a floating value"? | 05:56 |
badosu | jalv.gtk uses a slider that can set a non-integer value | 05:57 |
badosu | the scale points are only used as the markers on top of the slider | 05:57 |
badosu | drobilla: any reason for using svn? You like svn more than git? | 05:58 |
drobilla | badosu: I think that repo predates git's existence. If not, close. | 05:59 |
badosu | just out of curiosity | 05:59 |
drobilla | badosu: Migrating will be incredibly painful due to all the sub-projects, so I haven't done it yet | 05:59 |
badosu | I am having a hard time using svn :P | 06:00 |
drobilla | I will when the libs move to lv2 | 06:00 |
badosu | if you want help let me know | 06:00 |
badosu | I was almost mirroring it to git and uploading to git.bado.so | 06:01 |
badosu | so that I could send patches using http | 06:01 |
drobilla | I think you can do that locally with git-svn | 06:01 |
drobilla | The trouble with that migration is, I don't know how the dep situation works WRT packaging | 06:02 |
drobilla | Bunch of libraries, one tarball, bunch of different pkg-config files as currently, but... pkg-config deps not mapping to packages, kinda weird | 06:02 |
drobilla | Weird concerns me. | 06:03 |
drobilla | Gah, cairo really should not depend on glib crap | 06:45 |
drobilla | ugh, pkg-config on windows + spaces in paths => boom | 06:56 |
*** edogawa has joined #lv2 | 07:01 | |
* drobilla gives up | 07:02 | |
*** Anchakor_ has joined #lv2 | 07:36 | |
badosu | drobilla: why are you developing on windows? | 07:37 |
*** ddom has joined #lv2 | 08:38 | |
*** gianMOD has joined #lv2 | 09:20 | |
bgola | drobilla: what i mean is: if I send patch:Patch using the REST API it doesnt change the property i am trying to change. but when I send a patch:Set it works. dumping all the data my patch:Patch message looks ok. | 09:23 |
*** ricardocrudo has joined #lv2 | 09:37 | |
*** falktx has joined #lv2 | 10:03 | |
*** edogawa has quit IRC | 10:18 | |
*** gianMOD has quit IRC | 10:30 | |
*** ricardocrudo has quit IRC | 11:07 | |
*** gianMOD has joined #lv2 | 11:31 | |
bgola | drobilla: also, is it the desired behaviour that the engine broadcasts the message all clients including the client that sent it? there is no Response msg anymore? | 11:36 |
bgola | to all clients* | 11:36 |
*** gianMOD has quit IRC | 11:37 | |
*** sigma6 has quit IRC | 11:51 | |
*** gianMOD has joined #lv2 | 12:11 | |
*** gianMOD has quit IRC | 12:25 | |
*** ricardocrudo has joined #lv2 | 12:29 | |
*** falktx has quit IRC | 12:32 | |
*** rncbc_jolla has joined #lv2 | 12:43 | |
*** rncbc_jolla has quit IRC | 12:54 | |
*** gianMOD has joined #lv2 | 13:25 | |
*** gianMOD has quit IRC | 13:30 | |
*** gianMOD has joined #lv2 | 14:26 | |
*** gianMOD has quit IRC | 14:31 | |
*** gianMOD has joined #lv2 | 14:41 | |
*** edogawa has joined #lv2 | 14:48 | |
*** falktx has joined #lv2 | 14:51 | |
*** falktx has quit IRC | 14:59 | |
*** sigma6 has joined #lv2 | 15:10 | |
*** gianMOD has quit IRC | 15:19 | |
*** gianMOD_ has joined #lv2 | 15:24 | |
*** falktx has joined #lv2 | 15:26 | |
*** gianMOD_ has quit IRC | 15:49 | |
*** gianMOD has joined #lv2 | 15:50 | |
*** falktx has quit IRC | 15:53 | |
*** gianMOD has quit IRC | 15:55 | |
*** gianMOD has joined #lv2 | 16:36 | |
*** gianMOD has quit IRC | 16:38 | |
*** falktx has joined #lv2 | 16:42 | |
*** falktx has quit IRC | 16:45 | |
*** falktx has joined #lv2 | 16:52 | |
*** ddom has quit IRC | 17:25 | |
*** gianMOD has joined #lv2 | 17:53 | |
*** gianMOD has quit IRC | 18:04 | |
*** sigma6 has quit IRC | 18:16 | |
*** falktx has quit IRC | 18:39 | |
*** gianMOD has joined #lv2 | 18:49 | |
*** gianMOD has quit IRC | 18:52 | |
*** ricardocrudo has quit IRC | 18:59 | |
*** aombk2 has joined #lv2 | 19:10 | |
*** aombk has quit IRC | 19:13 | |
*** gianMOD has joined #lv2 | 19:17 | |
*** falktx has joined #lv2 | 19:29 | |
*** gianMOD has quit IRC | 20:16 | |
*** gianMOD has joined #lv2 | 20:29 | |
*** gianMOD has quit IRC | 20:48 | |
*** gianMOD has joined #lv2 | 21:05 | |
*** ricardocrudo has joined #lv2 | 21:08 | |
badosu | drobilla: http://bado.so/2015-03-03-183928_1312x274_scrot.png | 21:47 |
*** gianMOD has quit IRC | 21:49 | |
drobilla | badosu: nice. is knob a default qt widget? | 21:56 |
drobilla | badosu: what's with the different sizes? | 21:56 |
drobilla | badosu: I would put the value label next to or below the name label, this placement dissociates them too much | 21:56 |
badosu | drobilla: this is the most basic setup, so still needs adjusting the alignment/padding/layout | 21:59 |
badosu | drobilla: the knob is a QDial: http://qt-project.org/doc/qt-4.8/qdial.html | 21:59 |
badosu | drobilla: it's reptty clunky as it handles integer values, so I don't know if I'll still use it | 21:59 |
badosu | drobilla: for now I am more concerned about being able to control all the possible controls appropriately | 22:00 |
badosu | drobilla: then i'll make it prettier | 22:00 |
* drobilla looks | 22:03 | |
drobilla | Huh. Surely all sliders in Qt aren't integer constrained, that's insane | 22:03 |
badosu | drobilla: what do you mean? | 22:04 |
drobilla | I mean...... that? | 22:07 |
badosu | "Surely all sliders in Qt aren't integer constrained" | 22:09 |
badosu | what integer constrained means, that is my question | 22:09 |
drobilla | I honestly can not come up with a way of restating that sentence | 22:09 |
drobilla | contrained to only work on integers? | 22:09 |
badosu | because you can simply pass setRange(min, max) | 22:09 |
drobilla | like.... they use integers? | 22:09 |
badosu | well, it's quite the opposite | 22:10 |
badosu | they are always integer constrained | 22:10 |
drobilla | if by "opposite" you mean "exactly" | 22:10 |
badosu | ok | 22:10 |
drobilla | Bizarre, what a useless design | 22:10 |
badosu | so, I think I am in an alternate reality where up mean down and left means right | 22:11 |
badosu | but it's fine, as long as I am able to make that host work | 22:11 |
badosu | it's really sad that we can't communicate though :-( | 22:12 |
drobilla | I don't get it. Is this a language thing or something? | 22:12 |
drobilla | If someone says "surely <seemingly insane scenario>" it means they can't believe that is actually the case. | 22:12 |
badosu | oh, ok. I interpreted that literally | 22:13 |
drobilla | I guess you can make it 0..INT_MAX and map it to float yourself | 22:13 |
badosu | english is not my native language, and I pretty much don't use it outside technical discussions | 22:13 |
drobilla | fair enough | 22:13 |
badosu | so some ironical expressions I don't understand | 22:14 |
badosu | drobilla: yeah, it's pretty annoying to create the step handling by yourself | 22:14 |
Anchakor | I think the Qt dev didn't consider that somebody would want to use a dial for precise input, there are other widgets for that (where you can enter exact number) | 22:14 |
badosu | Anchakor: on the Qt lib? | 22:15 |
Anchakor | re QDial being integer based | 22:15 |
drobilla | I'd assume it's floating point internally, you can even set 'pixels between steps' in float | 22:15 |
falktx | badosu: rncbc has custom knob classes for qt in his plugins | 22:15 |
falktx | it handles floats and proper up/down drag | 22:15 |
badosu | falktx: I'd imagine that, but I really wanted to make as close to vanilla qt as possible | 22:16 |
falktx | it's a single header+file afaik | 22:16 |
falktx | you can join it into a single header | 22:16 |
badosu | falktx: this makes it more interesting, thanks for the heads up | 22:16 |
*** ricardocrudo has quit IRC | 22:18 | |
*** falktx has quit IRC | 22:50 | |
rgareus | badosu: I don't think you'll find a major toolkit that is suitable for audio-plugins | 23:12 |
rgareus | neither QT, nor gtk nor OSX Cocoa,... are really suitable. | 23:13 |
rgareus | the big kitchen-sink for audio is JUCE | 23:13 |
drobilla | jalv.pugl FTW | 23:14 |
rgareus | yeah - though thats not a TK, is it? | 23:14 |
drobilla | Well, no | 23:14 |
rgareus | drobilla: cont'd the discussion re x11 embeddeding. I get XGetGeometry() 1,1 for the parent | 23:17 |
drobilla | generic UI builder thingie makes me wonder how much intersection with Ingen there it here | 23:17 |
drobilla | it'd work for that, but probably some kind of actual builder or "presentation model" dealey is needed for that to be a decent 'plugin dev kit' | 23:17 |
drobilla | rgareus: weird | 23:17 |
rgareus | I dimly remember that there is a /bug/ ie first request always returns 1,1 | 23:17 |
rgareus | falktx worked around this callit it 3 or 4 times until it returns something > 1,1 | 23:18 |
drobilla | hah, lovely | 23:18 |
rgareus | yeah he can be pragmatic. | 23:18 |
rgareus | gtk window not realized.. uhm blame suil design... | 23:18 |
badosu | rgareus: I know, I've heard this discourse from drobilla already | 23:19 |
badosu | rgareus: my motivation to develop jalv.qt is because it will be important for LMMS later on | 23:19 |
badosu | rgareus: at least the stuff I'll have to learn | 23:20 |
rgareus | drobilla: taking a leaf out or his book, how aboutI sui/ X11 just sending a ConfigureNotify ? | 23:20 |
drobilla | That "suil design" stuff seems to be a whole lot of "I have no idea what I'm talking about", frankly | 23:20 |
rgareus | badosu: well, that's the host end, right? | 23:20 |
rgareus | badosu: so if you want to provide 'generic guis' for plugins that have none, yes you're on the right track. | 23:21 |
badosu | rgareus: yep, this is the idea | 23:21 |
drobilla | His thing just makes a top level Gtk window, I don't get how this is even related, or why so much gymnastics are needed | 23:21 |
drobilla | rgareus: Sending an appropriate event at some level (gtk or X11, whichever works) seems reasonable | 23:21 |
rgareus | drobilla: It /works/ in ardour if I edit, edit with generic UI, edit a configure notify is sent in that case. | 23:22 |
rgareus | though in both cases ardour tears down and reinitiates the plugin GUI. but only in the latter a Configure is sent. odd | 23:23 |
rgareus | maybe gtk size-request/allocate related due to actually changing things inside the window | 23:23 |
drobilla | rgareus: I'm guessing x_window_is_valid returns false preventing the existing attempt at this from working | 23:23 |
badosu | rgareus: I need this generic interface for 2 reasons | 23:24 |
badosu | 1. I can't trust lv2 ui developers that they'll always make usable GUIs | 23:24 |
badosu | 2. LMMS has some nice usability funcionalities that require access to the control widgets | 23:25 |
badosu | re: that QDial discussion, I've decided that for now I'll handle step calculations myself with 0.1% precision | 23:30 |
badosu | if drobilla finds this unsuitable for jalv.qt it will be easy to switch later | 23:33 |
drobilla | why 0.1% | 23:40 |
drobilla | Just use the full range of int (or maybe +'ve int), just as easy | 23:41 |
badosu | drobilla: I don't want to bother with this for now. Also, after a threshoul the precision does not make any difference | 23:47 |
drobilla | badosu: "bother with this"... it's exactly the same thing regardless of what the max is | 23:48 |
drobilla | float normal = int_val / (float)max; | 23:48 |
drobilla | float val = normal * (max - min) + min; | 23:49 |
badosu | drobilla: QDial usability is mostly incompatible with audio users expectation, that's why I am not bothering for now | 23:50 |
drobilla | well... okay | 23:50 |
badosu | drobilla: for example, on QDial you have to move the mouse *around* the widget instead of up/down | 23:50 |
badosu | drobilla: I'll only tweak QDial if there's no alternative that won't increase the size of jalv_qt4 very much | 23:51 |
drobilla | Must be poorly written code for this even to be a thing | 23:51 |
badosu | drobilla: it's not porrly writen code, it's UI for non audio users | 23:52 |
drobilla | jalv.qt should probably just use sliders, too, if QDial sucks | 23:52 |
drobilla | I mean your code that somehow involves 0.1% | 23:52 |
badosu | drobilla: probabyl, but until I release it for review, this only concerns to me | 23:53 |
badosu | this integer restricion is present on the QSlider class which QDIal inherits | 23:54 |
badosu | so any slider on vanilla qt will have this behaviour | 23:54 |
drobilla | integers have a whole lot more than 1000 possible values | 23:54 |
badosu | drobilla: I know :-) | 23:54 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!