| drobilla | LAbot: Thanks for that entirely useless piece of noise | 00:00 |
|---|---|---|
| LAbot | drobilla: Error: "Thanks" is not a valid command. | 00:00 |
| drobilla | Ungrateful thing, isn't it? | 00:01 |
| rgareus | lol | 00:01 |
| * rgareus -> compiling | 00:02 | |
| rgareus | LAbot: echo "thank you" | 00:02 |
| LAbot | thank you | 00:02 |
| drobilla | That's better! | 00:02 |
| rgareus | mmh that shoud have been | 00:02 |
| rgareus | LAbot: echo y/w | 00:02 |
| LAbot | y/w | 00:02 |
| Anchakor | LAbot: echo $* | 00:03 |
| LAbot | $* | 00:03 |
| rgareus | drobilla: it just keeps reminding you that you should choose better titles for your site | 00:03 |
| drobilla | Changeset 5326 seems like a pretty suitable title for changeset 5326 to me :) | 00:04 |
| drobilla | I guess while I'm cleaning up the comms I really should disable responses the UI is not interested in | 00:07 |
| rgareus | drobilla: mmh. not fixed. | 00:10 |
| rgareus | gitk | 00:11 |
| rgareus | heh. well, I am at 5326 now. | 00:12 |
| drobilla | I see knobs not at zero... | 00:12 |
| rgareus | drobilla: the X, Y ones? | 00:12 |
| rgareus | drobilla: and gain? | 00:13 |
| drobilla | Those are at 0 | 00:13 |
| rgareus | drobilla: thet means - still b0rked | 00:13 |
| drobilla | Okay, still no response. | 00:14 |
| drobilla | I said any knob :P | 00:14 |
| rgareus | drobilla: I could work-aroud by actually using the same defaults in the GUI.. | 00:14 |
| rgareus | drobilla:but that won't solve the problem. modify state, close GUI, re-open GUI | 00:14 |
| rgareus | drobilla: when it's broken it looks like this [by default] https://f.cloud.github.com/assets/1472461/2010688/0c239b34-8771-11e3-8a8a-57d75c7e2baa.png | 00:15 |
| rgareus | and when it works.. it comes up like this http://robin.linuxaudio.org/tmp/sisco_gtk_jalv.png | 00:19 |
| drobilla | I wonder why it's so fugly in ingen | 00:20 |
| rgareus | drobilla: gtk style. | 00:20 |
| drobilla | Yes, but... why? | 00:20 |
| drobilla | Whatever you're doing should override that | 00:20 |
| rgareus | drobilla: I use ardour's theme | 00:20 |
| rgareus | drobilla: GTK2_RC_FILES=/PATH/TO/ardour/build/gtk2_ardour/ardour3_ui_dark.rc jalv.gtk ... | 00:21 |
| drobilla | rgareus: Can't you include that in your UI somehow? | 00:22 |
| rgareus | drobilla: I could hardcode the colours | 00:22 |
| drobilla | Widgets that depend ona particular style, but not actually setting that style, is not so good... | 00:22 |
| drobilla | rgareus: You should be able to literally set that style from the rc | 00:22 |
| rgareus | drobilla: the widgets don't depend on any color. they just ask GTK for it | 00:22 |
| drobilla | I believe calf does this | 00:23 |
| drobilla | I know Gtk has API for it | 00:23 |
| drobilla | rgareus: In my jalv some are dark, some are (system) light | 00:23 |
| rgareus | drobilla: robtk's gtk version uses GtkStyle and asks for style->fg[] style->bg[] with various states | 00:24 |
| rgareus | drobilla: e.g. GTK_STATE_NORMAL, GTK_STATE_ACTIVE | 00:24 |
| drobilla | It's working for some, anyway | 00:25 |
| drobilla | I guss I can make a screenshot, but if you have a light theme, it's pretty mangled | 00:25 |
| rgareus | drobilla: I may have mixed up some of those.. or rather ardour may have because it looks nice w/ ardour's theme :) | 00:25 |
| drobilla | buttons are clearly dark | 00:25 |
| drobilla | yes, ardour theme | 00:25 |
| drobilla | XY knobs and buttons are straight out of ardour | 00:26 |
| drobilla | X1 and X2 knobs follow mine | 00:26 |
| rgareus | drobilla: well, I could really just hardcode the colors. | 00:28 |
| drobilla | or just include your gtk theme and set the style | 00:28 |
| rgareus | drobilla: that's what the openGL variant does anyway (because it knows nothing og gtk to query it) | 00:28 |
| drobilla | I'm pretty sure there's a "load this .rc for this widget's style" function in Gtk | 00:28 |
| rgareus | drobilla: right, but then I need a path to another file.. and I hate that | 00:29 |
| drobilla | Sure, in effect the same thing anyway | 00:29 |
| drobilla | A static one in your own bundle, trivial and not problematic | 00:29 |
| rgareus | drobilla: C:\Program Files\LV2\gtksucks\ | 00:29 |
| drobilla | But since you have not-gtk versions too, whatever | 00:29 |
| drobilla | rgareus: You'd have to include it, of course | 00:29 |
| drobilla | rgareus: Aha. So, ingen is essentially "monitoring" the notification port | 00:30 |
| drobilla | rgareus: Including choosing when an appropriately long enough time has passed for an update to be needed | 00:30 |
| drobilla | rgareus: Which is all well and good for peaks, but not when you want reliable transfer of all events in a buffer | 00:30 |
| rgareus | drobilla: an other approach is: "a plugin must not rely on a host to deliver messages". In which case I could implement a rather simple workaround: | 00:33 |
| rgareus | if the GUI receives some other message, but has not received state -> re-request the state | 00:33 |
| rgareus | (repeat until it receives the state) | 00:34 |
| drobilla | yeah, but that's making plugins deal with unreliable protocol stuff | 00:34 |
| drobilla | which is not fun | 00:34 |
| drobilla | best to just not go there for as long as we can, preferably forever | 00:34 |
| rgareus | drobilla: indeed. | 00:34 |
| drobilla | even in ingen I just abandoned it. TCP or bust. | 00:34 |
| rgareus | drobilla: besides, other LV2 hosts manage just fine. | 00:34 |
| drobilla | other LV2 hosts can't run their UIs on the other side of the planet, but yes, it should work anway | 00:35 |
| drobilla | reliable message stream doesn't belong at the application layer anyway | 00:35 |
| rgareus | --- except for mixbus, it does not have te port-resize extension and just segfaults if a plugin tries to write more than ~1K.. (old A2 based LV2, old lilv,..) | 00:36 |
| rgareus | drobilla: I think falktx's carla can run a custom LV2 GUI in the browser using webGL. | 00:37 |
| rgareus | drobilla: I never tried it myself, but he posted screenshots | 00:37 |
| rgareus | anyway... | 00:38 |
| drobilla | probably questionable for me to ever try to backport that stuff to A2 in the first place | 00:38 |
| rgareus | drobilla: don't. | 00:38 |
| drobilla | how the heck is that possible? | 00:39 |
| rgareus | drobilla: let's move forward.. to Ardour4 :) | 00:39 |
| drobilla | rgareus: I mean, long ago, which is why it's in mixbus | 00:39 |
| drobilla | Well, at the time, Ardour 2 was the only released ardour, so I wanted eg-sample to work in it | 00:39 |
| rgareus | drobilla: 'how the heck is that possible?' -- was that regarding falktx's webGL stuff? | 00:40 |
| drobilla | Lately my role in LV2 is more "guy who forcefully drags you bastards into the future" anyway | 00:40 |
| drobilla | rgareus: yeah | 00:40 |
| rgareus | drobilla: you won't like the answer to that question. | 00:40 |
| drobilla | I mean, taking an existing anything and making it show up as GL in the browser | 00:41 |
| drobilla | Regardless of the piece of shit extension that hooks it into LV2 world | 00:41 |
| rgareus | drobilla: I don't know the exact details, but I think he hacked pugl somehow. | 00:42 |
| drobilla | bizarre. | 00:43 |
| rgareus | drobilla: and it's currently just a proof-of-concept with one of his plugins | 00:43 |
| drobilla | Though if you mean writing a UI specifically for that, sure. | 00:43 |
| drobilla | You can write a UI specifically in just about anything | 00:43 |
| rgareus | drobilla: he writes a 'meta-ui' that is then compiled into X other GUIs. | 00:43 |
| drobilla | oh. that's less interesting, then. | 00:44 |
| rgareus | and X+Y other plugin formats | 00:44 |
| drobilla | I don't really actively pay attention to Carla stuff. Never ran it. | 00:44 |
| * drobilla is more interested in plugins than hosts | 00:45 | |
| rgareus | create LADSPA|Juced|VST|LV2|... ** GTK|QT|Cocoa|GL|.. all from one soure | 00:45 |
| rgareus | source, even | 00:45 |
| drobilla | I would sure like a solution to the gigantic fragmentation problem at the LV2 UI interface level, though | 00:45 |
| drobilla | That part I am slightly familiar with, but it's quite the monstrosity, and hyper VSTey | 00:46 |
| * rgareus fires up gdb again. | 00:46 | |
| drobilla | Hrm, well, I have the foreach firing, but there seems to be nothing in the notify buffer... | 00:48 |
| drobilla | rgareus: I seem to be finding many portNotifications for this port for this plugin... | 00:52 |
| drobilla | probably not a problem, but bunch of traffic. odd. | 00:52 |
| drobilla | and indeed there is | 00:53 |
| drobilla | one for each plugin, which I'm not checking | 00:53 |
| drobilla | that sure gets verbose | 00:54 |
| drobilla | kind of pointless since the symbol has to be identical anyway | 00:54 |
| drobilla | but anyway, you are right and ingen is wrong as far as the spec goes | 00:55 |
| drobilla | This could be simplified, though | 00:59 |
| drobilla | Maybe to keep in mind when I make the upcoming "We need to have a talk about UIs" ML thread | 00:59 |
| drobilla | rgareus: So with r5328, I made it so monitoring always scans the port in this case | 01:05 |
| drobilla | rgareus: PortImpl.cpp:410 | 01:05 |
| drobilla | rgareus: But it just seems to be empty | 01:05 |
| drobilla | I don't know if it's being cleared before this point or if the plugin isn't writing or what | 01:05 |
| rgareus | drobilla: it's odd. I'm breaking at NodeModule::port_activity() | 01:09 |
| drobilla | Should be called right away, LV2Block::process() runs the instance | 01:09 |
| drobilla | rgareus: That's in the stratosphere. The engine isn't sending anything whatsoever. | 01:10 |
| drobilla | Like, in the audio thread. | 01:10 |
| drobilla | (which will then go to a ringbuffer which is drained eventually, sent through the engine queue, which will arrive at sigc thing, which, etc. etc.) | 01:10 |
| drobilla | if you stick a print in the above mentioned LV2_ATOM_SEQUENCE_FOREACH it will never print | 01:11 |
| drobilla | If that fired, it should work | 01:11 |
| drobilla | Nothing to do with UI | 01:11 |
| rgareus | drobilla: when is PortImpl::monitor() called? | 01:12 |
| drobilla | LV2Block::process() => BlockImpl::post_process() => OutputPort::post_process() => PortImpl::monitor() | 01:13 |
| drobilla | I can't find a clear anywhere in there, so next step for me anyway would be to stock a print in sisco and ensure it really is writing | 01:14 |
| drobilla | maybe the buffer isn't inited right or something, I dunnos | 01:14 |
| drobilla | rgareus: I think I've fixed all big scale stuff wrong with ingen now, just this little problem of the buffer seemingly being empty in the audio thread | 01:15 |
| * rgareus added a few printf()s to ./ingen/src/server/PortImpl.cpp -- top of PortImpl::monitor() and in case PortType::ATOM:... | 01:15 | |
| * rgareus -> compiling | 01:15 | |
| drobilla | Right. Which indeed was totally broken before | 01:17 |
| rgareus | drobilla: PortImpl::monitor is not even called | 01:17 |
| rgareus | drobilla: mmh. wait. I only check after if (!context.must_notify(this)) | 01:18 |
| drobilla | rgareus: is for me. once you create the UI that is | 01:18 |
| drobilla | If blinkenlights is off and there is no UI, then must_notify will return false, as it should. | 01:18 |
| rgareus | drobilla: not here.. I open the GUI. and the GUI sends the mesage to the plugin.. | 01:19 |
| rgareus | and I've made sisco.c:229 printf("sisco.lv2: Send settings to UI\n"); | 01:19 |
| rgareus | which is printed.. | 01:19 |
| drobilla | before that it shoudl subscribe | 01:19 |
| drobilla | hm. something is different now. | 01:20 |
| rgareus | drobilla: and now the first thing in PortImpl::monitor() { printf("PortImpl::monitor\n"); | 01:21 |
| drobilla | shit, I botched the logic when 'cleaning' it up. one sec. | 01:21 |
| rgareus | never is cprinted | 01:21 |
| rgareus | drobilla: cleanup is another issue. | 01:21 |
| rgareus | drobilla: the gtk top-level widget is destoyed first, then plugin cleanup is called | 01:21 |
| drobilla | rgareus: If you put a print at the ver very top of PortImpl::monitor() it's never printed? | 01:22 |
| rgareus | drobilla: destoying the top-level gtk_destoys() all children -> when the plugin comes around in cleanup() -> IA__gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed | 01:22 |
| * drobilla totally ignores all that | 01:22 | |
| rgareus | drobilla: correct. I put it to the top of PortImpl::monitor() and it's never triggered | 01:22 |
| drobilla | but it's called directly by OutputPort::post_process | 01:23 |
| rgareus | drobilla: http://pastebin.com/P8MT6Ee0 to be clear | 01:23 |
| drobilla | That's Impossible™ | 01:24 |
| drobilla | Hell, doing that will print a bunch of times for /control_in and /control_out before anything is even added | 01:24 |
| rgareus | drobilla: and the output when running: http://pastebin.com/1NDvZXVq | 01:25 |
| drobilla | rgareus: well, start at LV2Block::process and work your way down I suppose | 01:25 |
| drobilla | Apparently your issue is much deeper than mine | 01:25 |
| rgareus | drobilla: will do | 01:25 |
| rgareus | drobilla: uhm. stupid /me | 01:27 |
| rgareus | drobilla: modifying the file, then calling ./waf from the top-level did not re-build it! | 01:28 |
| drobilla | I figured you weren't actually running the code you thought you were :) | 01:28 |
| drobilla | though....... that's odd | 01:28 |
| drobilla | waf misses system changes, but not local | 01:28 |
| rgareus | drobilla: if I call ./waf from the ingen dir, it works. | 01:28 |
| rgareus | drobilla: but I just do a ./waf clean now | 01:28 |
| drobilla | having both configured at the same time can cause confusion. suggest one or the other | 01:29 |
| drobilla | e.g. build in one, install in the other, which is old, etc. | 01:29 |
| drobilla | I'm getting crazy bizarre missing prints now too | 01:32 |
| drobilla | yet the code is definitely being recompiled. | 01:32 |
| drobilla | .. that or I put "YES" instead of "NO" and vice versa | 01:32 |
| * drobilla is also stupid | 01:32 | |
| drobilla | Right, it's as I said before for me, getting to the FOREACH | 01:33 |
| drobilla | even simpler, size is always 0 | 01:34 |
| drobilla | if (_monitored) { | 01:34 |
| drobilla | std::cerr << "SEQUENCE MONITOR SIZE: " << seq->atom.size - sizeof(LV2_Atom_Sequence_Body) << std::endl; | 01:34 |
| rgareus | drobilla: OK. I'm getting regular printf()s now. | 01:48 |
| rgareus | drobilla: PortImpl::monitor() is only called if the UI is visible | 01:51 |
| drobilla | rgareus: Correct, and intentional. | 01:52 |
| drobilla | (it will also be called if "Animate Canvas" is enabled) | 01:52 |
| rgareus | drobilla: but nothing in the FOREACH... | 01:53 |
| drobilla | (actually I don't think that is quite correct, it will be called but must_notify will return false so it will exit immediately) | 01:53 |
| drobilla | rgareus: yep | 01:53 |
| rgareus | drobilla: BlockImpl::post_process is called every cycle when the Plugin is added. | 01:55 |
| rgareus | drobilla: so my guess is, that monitoring is enabled too late | 01:55 |
| drobilla | fixed that several commits ago | 01:56 |
| drobilla | unless something really weird is going on | 01:56 |
| rgareus | drobilla: I'm still at 5326 | 01:56 |
| drobilla | comment out all the short circuits and it still doesn't work. | 01:57 |
| * rgareus updated 5328 | 01:57 | |
| drobilla | yeah, if I force monitoring to be on all the time, still doesn't work | 01:59 |
| drobilla | size always zero | 02:00 |
| drobilla | is that capacity warning of yours enabled by default? | 02:00 |
| drobilla | because if the size is zero to begin with, that'll do it... | 02:01 |
| drobilla | break on write in sisco, set a watch point on seq->atom.size, continue? | 02:02 |
| rgareus | drobilla: but it should print the warning | 02:03 |
| drobilla | regardless, the size is 0 at this point | 02:08 |
| drobilla | and if sisco is indeed writing to the same seq, then it wasn't, then. | 02:08 |
| rgareus | drobilla: since updating to 5328. I don't see the 'sisco.lv2: Send settings to UI' message any more | 02:09 |
| rgareus | drobilla: so the plugin never receives the message from the UI | 02:10 |
| rgareus | drobilla: diff to sisco.lv2: http://pastebin.com/GEtvPt5X | 02:11 |
| rgareus | drobilla: it does print "Atom size 8" | 02:11 |
| rgareus | with jalv I do see 'sisco.lv2: Send settings to UI' \n 'Atom size 280' | 02:12 |
| rgareus | with ingen neither, only ever 'Atom size 8' now | 02:12 |
| drobilla | You saw this before in ingen? | 02:13 |
| rgareus | drobilla: yes | 02:14 |
| rgareus | drobilla: that was ^^^ http://pastebin.com/1NDvZXVq | 02:15 |
| drobilla | sidenote: we seriously should have had an lv2:value | 02:15 |
| drobilla | I guess I could use pset:value in ingen | 02:15 |
| drobilla | preset extension itself should have just been in lv2 core | 02:15 |
| drobilla | defaults should be a preset | 02:15 |
| rgareus | drobilla: the actual goal here is. keep the backend running open/close the GUI | 02:16 |
| rgareus | drobilla: and just closing the UI temporarily does not warrant a preset | 02:16 |
| drobilla | oh, right, switching to ingen:activity did that | 02:16 |
| drobilla | ? | 02:16 |
| drobilla | I don't know how you could have even drawn the conclusion that I was suggesting a preset was somehow the solution to this :) | 02:17 |
| rgareus | pset:value | 02:17 |
| drobilla | I mean lv2:default is stupid, and having pset:value and the rest of it off in some other extension is also stupid | 02:17 |
| drobilla | lv2:default, pset:value, ingen:value | 02:17 |
| drobilla | should x and y be vertical? | 02:18 |
| drobilla | (and amp) | 02:18 |
| drobilla | they were all the way left before IIRC | 02:18 |
| drobilla | Pretty sure yes | 02:19 |
| drobilla | Which means I did actually fix the problem a few commits ago | 02:19 |
| drobilla | I just also broke it by switching to ingen:activity, which doesn't actually push to the port buffer | 02:19 |
| drobilla | rgareus: http://dev.drobilla.net/changeset/5329 | 02:20 |
| LAbot | Title: Changeset 5329 – drobillad (at dev.drobilla.net) | 02:20 |
| drobilla | This took like 4 hours. Fuck me, programming is the worst sometimes. | 02:21 |
| drobilla | Oh well, at least monitoring actually makes sense now, and the replies to set_property | 02:21 |
| rgareus | drobilla: still not.. | 02:23 |
| rgareus | fixed | 02:23 |
| rgareus | drobilla: I only get 'Atom size 8' from sisco. the plugin does not receive the initial request from the UI | 02:23 |
| rgareus | drobilla: on a related note. Thanks for making plugin discovery much much faster (or caching it?) | 02:24 |
| drobilla | I do. | 02:24 |
| drobilla | rgareus: That was entirely the workaround for meters.ttl ;) | 02:24 |
| rgareus | drobilla: aah wait. | 02:24 |
| drobilla | It was a fix in lilv to never parse the same file twice | 02:25 |
| drobilla | It just never mattered before, because nobody put a bajillion plugins in the same file before | 02:25 |
| rgareus | lost in the scrollback buffer: now fith 5329: http://pastebin.com/gnAAEHE5 | 02:25 |
| rgareus | let me add back the monitoring printf() | 02:26 |
| rgareus | so sisco gets the message & responds. at the end of sisco's run there's something in the Atom buffer | 02:26 |
| drobilla | Oddly I get th same X,Y,amp as jalv, but X1 and X2 are different | 02:26 |
| drobilla | rgareus: To be clear, it *totally* works for me, as in the X,Y,amp controls in the UI are not zero | 02:27 |
| drobilla | all 3 are straight vertical as in jalv | 02:27 |
| rgareus | drobilla: and I also see it in foreach in ingen | 02:28 |
| drobilla | rgareus: and yet it's still not working? | 02:28 |
| drobilla | er, reverted sisco and now it doesn't again. WTF. | 02:29 |
| rgareus | drobilla: wait a min. I've disabled port_events() in the gui for debugging.. | 02:29 |
| rgareus | drobilla: works now! | 02:29 |
| rgareus | drobilla: let me try, if it does so reliably. | 02:30 |
| drobilla | did for me, now not. sgh. | 02:30 |
| rgareus | drobilla: maybe just because of the printf() * timing | 02:30 |
| drobilla | Shouldn't be, it's all synchronous | 02:30 |
| drobilla | Unless we have now finally arrived at the weird Gtk syncey things you figured it was initially | 02:31 |
| rgareus | drobilla: right. | 02:31 |
| rgareus | drobilla: but 5329 is OK here, now. | 02:32 |
| rgareus | drobilla: tested 5 times 5 times OK | 02:32 |
| drobilla | Not for me :( | 02:32 |
| drobilla | never sent, again | 02:33 |
| rgareus | drobilla: odd | 02:33 |
| drobilla | hm.. something seems to be sent *every* cycle | 02:34 |
| drobilla | judging by a print in that FOREACH | 02:34 |
| rgareus | the 8bytes? en amety sequence? | 02:35 |
| rgareus | empty sequence. just the header | 02:35 |
| drobilla | *in* that foreach shouldn't do so | 02:35 |
| drobilla | I reverted sisco and not it consistently does *not* work for me | 02:36 |
| drobilla | now* | 02:37 |
| drobilla | valgrind time | 02:37 |
| * drobilla thought he was finally done | 02:37 | |
| drobilla | aaaaaand zombie | 02:39 |
| drobilla | I hate jack so much sometimes | 02:39 |
| drobilla | -d dummy -Z --timeout 99999 means NO FUCKING ZOMBIES | 02:40 |
| rgareus | not with jack1 :) | 02:42 |
| drobilla | SiSco.lv2 error: LV2 comm-buffersize is insufficient 33008/33024 bytes. | 02:43 |
| drobilla | rgareus: Worst fork situation ever. | 02:43 |
| rgareus | drobilla: the mono version? | 02:44 |
| rgareus | drobilla: it has rsz:minimumSize 33024; rdfs:comment "Plugin t | 02:44 |
| rgareus | oops. | 02:44 |
| drobilla | yes | 02:44 |
| rgareus | drobilla: so if you host only gives it 33008.... | 02:44 |
| drobilla | rgareus: One of us is probably not compensating for sizeof(LV2_Atom_Sequence) | 02:45 |
| rgareus | 33024 is 8192 [max jack bufsize] * sizeof(float) + LV2-Atom overhead | 02:45 |
| drobilla | If you mean literally LV2_Atom overhead that's not enough | 02:46 |
| drobilla | (this is at 8192) | 02:46 |
| rgareus | drobilla: no, not literally | 02:46 |
| rgareus | drobilla: but elaborating on the whole thing literally would fill a page :) | 02:47 |
| rgareus | drobilla: 33024 is the total everything at the end | 02:48 |
| drobilla | The capacity reported is self->notify->atom.size | 02:48 |
| rgareus | drobilla: yes | 02:49 |
| drobilla | Fine, I will assume ingen isn't giving enough | 02:50 |
| drobilla | But I am going to be super pissed off if the number is wrong :P | 02:50 |
| rgareus | drobilla: well, the .ttl says 33024. and in run() self->notify->atom.size is 33008 | 02:51 |
| rgareus | drobilla: so that's 16 bytes difference. | 02:51 |
| drobilla | rgareus: Those two numbers are not the same. atom.size will be sizeof(LV2_Atom) smaller than rsz:minimumSize | 02:52 |
| rgareus | drobilla: not only 8 for the sequence header | 02:52 |
| drobilla | that's 8 bytes, though. I don't know why 16 | 02:52 |
| drobilla | You should be getting 33016 | 02:53 |
| drobilla | this time it worked but all red because of the buffer thing | 02:53 |
| rgareus | drobilla: mmh. that's not what the doc says. http://lv2plug.in/ns/ext/resize-port/#minimumSize | 02:54 |
| LAbot | Title: LV2 Resize Port Extension (at lv2plug.in) | 02:54 |
| rgareus | "Indicates that a port requires a buffer at least this large, in bytes" | 02:54 |
| rgareus | thanks, LAbot | 02:54 |
| drobilla | the monitoring is still broken | 02:54 |
| drobilla | rgareus: LV2_Atom is part of the buffer. | 02:54 |
| drobilla | rgareus: That property is not atom specific. | 02:54 |
| drobilla | It says the port buffer must be x bytes large. | 02:54 |
| rgareus | drobilla: right. | 02:55 |
| drobilla | So if you ask for 33024 your atom.size should be 33016 | 02:55 |
| rgareus | drobilla: OK. I'll add 8 | 02:55 |
| drobilla | Right. | 02:55 |
| drobilla | Which leaves 8 mystery bytes :) | 02:55 |
| * drobilla is still trying to figure out why monitoring doesn't work | 02:56 | |
| rgareus | dark-matter | 02:56 |
| rgareus | because you're using Atoms | 02:56 |
| drobilla | heh | 02:57 |
| * drobilla wonders if ccache isn't being reliable or something | 03:00 | |
| drobilla | Hm, wait, if the size is off, then it won't be sent | 03:01 |
| drobilla | duhr | 03:01 |
| drobilla | _atom->size = _capacity - sizeof(LV2_Atom_Sequence); | 03:03 |
| drobilla | there's the 8 bytes | 03:03 |
| drobilla | SiSco.lv2 error: LV2 comm-buffersize is insufficient 33016/33024 bytes. | 03:03 |
| drobilla | Fun ingen facts: pretty sure this makes every sequence allocated from then on that large | 03:04 |
| drobilla | I need to redo buffers | 03:04 |
| drobilla | Well, at least 100% of the problem wasn't shitty broke-ass Ingen :) | 03:05 |
| rgareus | drobilla: odd thing. with jalv I get self->notify->atom.size = 33024 when I request rsz:minimumSize 33024 | 03:06 |
| rgareus | drobilla: same with ardour | 03:06 |
| drobilla | rgareus: More never hurts | 03:06 |
| rgareus | drobilla: yes. | 03:07 |
| drobilla | Though, I wonder if you *really* get that much... | 03:07 |
| drobilla | or if the size is just set wrong, which would be bad | 03:07 |
| rgareus | drobilla: the plugin gets that much. it works, I can see the waveform :) | 03:11 |
| drobilla | rgareus: actually I don't think it does. LV2_Evbuf is broken. | 03:12 |
| rgareus | http://robin.linuxaudio.org/tmp/ingen_sisco.png | 03:12 |
| rgareus | drobilla: where? in Ardour? | 03:13 |
| rgareus | drobilla: or jalv? | 03:13 |
| drobilla | same used in both | 03:13 |
| drobilla | hmm.. no, it allocates a bit more at the start | 03:13 |
| drobilla | n/m | 03:13 |
| drobilla | Ingen as of last rev will give you exactly what's requested | 03:14 |
| rgareus | drobilla: so I don't need to add 8? | 03:14 |
| drobilla | You do need to add 8 | 03:18 |
| drobilla | Then it should work at 8192 | 03:19 |
| drobilla | Actually it seems weird that that matters, but anyway, you're off by sizeof(LV2_ATOM) | 03:19 |
| drobilla | LV2_Atom, even | 03:19 |
| rgareus | actually I think I can relax the check. 33024 is over-conservative. I've added too much padding | 03:21 |
| rgareus | even with 8192 floats + GUI state. the total measured max is only 33024 | 03:21 |
| drobilla | shame a nice round number like 32768 won't suffice :) | 03:21 |
| rgareus | aah wait. the state for the 4channel version is larger. | 03:21 |
| drobilla | We could totally design a more graceful mechanism for this | 03:22 |
| drobilla | But it hardly seems worth the effort | 03:22 |
| drobilla | Though it would be neat if the forge itself could somehow signal the host so it would know to increase it next time | 03:23 |
| rgareus | worst case the plugin transfers 8K audio-samples + the Atom-vector overhead of it + the GUI-settings which are 3 vectors in one cycle. | 03:23 |
| rgareus | 8K audio-samples * number of channels. GUI-state is also * number of channels | 03:23 |
| drobilla | I guess the forge could set the buffer to a special underrun atom | 03:24 |
| rgareus | the padding is slightly different in each case. | 03:24 |
| drobilla | Though I guess the plugin would still need to check that it failed to try again next cycle | 03:24 |
| rgareus | drobilla: right. | 03:24 |
| drobilla | Probably easier for the host to just support dynamic resize, really | 03:24 |
| rgareus | i think I did that somewhere.. | 03:25 |
| rgareus | the ebur128 gui probably. | 03:25 |
| rgareus | drobilla: so did you find the problem in ingen? | 03:28 |
| drobilla | rgareus: http://dev.drobilla.net/changeset/5331 | 03:29 |
| LAbot | Title: Changeset 5331 – drobillad (at dev.drobilla.net) | 03:29 |
| rgareus | drobilla: and sisco now works for you w/ jack -p <= 4096 | 03:30 |
| rgareus | drobilla: and will work with 8192 once I've add 8 to each rsz:minimumSize | 03:31 |
| drobilla | rgareus: right | 03:31 |
| rgareus | ..or changed the check for the min size | 03:31 |
| drobilla | I suppose, but those should of course correspond | 03:31 |
| rgareus | drobilla: I've started re-doing the worst-case max. size-calculation | 03:32 |
| rgareus | drobilla: yeah I wasn't aware of he +8 issue. basically because jalv and A3 gave me rsz:minimumSize as self->notify->atom.size | 03:32 |
| drobilla | I'm half inclined to check the logic there, but why bother going out of my way to make it smaller and potentially break something | 03:33 |
| drobilla | Seems the memory is actually there, so whatever | 03:33 |
| rgareus | ardour uses LV2_Evbuf* evbuf = (LV2_Evbuf*)malloc(sizeof(LV2_Evbuf) + sizeof(LV2_Atom_Sequence) + capacity); | 03:35 |
| rgareus | with capacity == rsz:minimumSize | 03:35 |
| rgareus | drobilla: and it was you who wrote that :) | 03:36 |
| rgareus | 2012-02-25 | 03:36 |
| rgareus | well, setting capacity to rsz:minimumSize was /me | 03:36 |
| drobilla | Like I said, it's the same in both. | 03:37 |
| drobilla | Right, which is where the extra comes from. | 03:37 |
| rgareus | drobilla: to make ardour 100% strict, it should just not add sizeof(LV2_Atom_Sequence) | 03:38 |
| rgareus | drobilla: though throwing in 8 extra bytes does not hurt | 03:38 |
| drobilla | Well, depending on how you look at it, I suppose. | 03:38 |
| drobilla | indeed. | 03:38 |
| rgareus | drobilla: subtracting 8 and then adding 8 seems worse. | 03:38 |
| drobilla | I guess making it strictly correct could prevent someone from making this same mistake in the future | 03:39 |
| rgareus | drobilla: my first test is always in jalv. | 03:39 |
| drobilla | lv2_evbuf.c is just being lazy, it probably needs to be different for each type | 03:41 |
| rgareus | drobilla: right. ./jalv/src/lv2_evbuf.c is very similar to ./libs/ardour/lv2_evbuf.c | 03:45 |
| drobilla | I was not aware they had diverged whatsoever | 03:45 |
| drobilla | I probably should have put that in LV2 itself as a utility header | 03:45 |
| drobilla | Would have prevented that Renoise dipshit from getting confused about what to do, at the very least | 03:46 |
| rgareus | drobilla: there's a minor change for a compiler warning. (the default: case) | 03:49 |
| rgareus | drobilla: http://pastebin.com/VWx5fcmk | 03:49 |
| rgareus | drobilla: the change to ev = (LV2_Event*)((char*)ebuf->data + iter.offset); should probably be ported to Ardour | 03:50 |
| rgareus | though actually case LV2_EVBUF_EVENT: should just be removed :) | 03:50 |
| drobilla | rgareus: Hopefully sooner rather than later, though see lv2-dev for evidence that at least one person gets pissy about the idea | 03:51 |
| drobilla | rgareus: Though at that point, lv2_evbuf can just disappear entirely | 03:51 |
| drobilla | Calf is the biggest thing to resolve before that happens. | 03:51 |
| rgareus | drobilla: the guitarix tuner -> midi output is no loss | 03:51 |
| drobilla | AFAIK all (not-dead) hosts support atoms. | 03:51 |
| drobilla | Indeed. Though I suppose maybe lack of equivalents to event-helpers.h was the cause of that. | 03:52 |
| drobilla | Kind of hard when people just piss and moan, and don't actually tell you. | 03:52 |
| drobilla | Easier to just not give a fuck than speculate, so I'll just do that. :) | 03:52 |
| * drobilla nestles comfily on his benevolent dictator throne | 03:52 | |
| drobilla | Though, I thought of something tricky there.... | 03:53 |
| drobilla | Technically, changing port types means changing URIs | 03:53 |
| rgareus | drobilla: thanks for tracking down these ingen issues, Mr Dictator. | 03:53 |
| drobilla | Which something like calf sure doesn't want to do | 03:53 |
| drobilla | rgareus: y/w | 03:53 |
| drobilla | Though it's almost 11pm and I completely hate myself for doing so, it made me fix some totally wrong things about Ingen comm, so it's all good | 03:54 |
| rgareus | drobilla: let me close 954 | 03:54 |
| drobilla | In the context where this matters and me failing at life doesn't, anyway :) | 03:54 |
| rgareus | 11pm on a Friday night. | 03:56 |
| rgareus | here's 5am on a Saturday morning. | 03:56 |
| drobilla | fair enough :) | 03:57 |
| * rgareus -> bed() | 03:58 | |
| rgareus | drobilla: I'll update the buffersize +8 after a bit of sleep | 03:58 |
| drobilla | This weekend I have to finish and submit this paper, write a progress report for my research project, merge 3 branches and fix a bunch of shitty code for work stuff, implement a bunch of non-trivial functionality..... | 03:58 |
| drobilla | Plan comps, consider course situation, kill self, etc. | 03:58 |
| drobilla | rgareus: 'night | 03:58 |
| *** edogawa has joined #ingen | 07:02 | |
| *** thorwil has joined #ingen | 09:15 | |
| *** drobilla has quit IRC | 09:30 | |
| *** drobilla has joined #ingen | 09:34 | |
| *** thorwil has quit IRC | 11:15 | |
| *** thorwil has joined #ingen | 13:21 | |
| *** dongl is now known as donut | 14:42 | |
| *** donut is now known as dong | 15:23 | |
| *** edogawa_ has joined #ingen | 15:30 | |
| *** edogawa has quit IRC | 15:33 | |
| *** edogawa_ is now known as edogawa | 15:41 | |
| drobilla | Hmmmm.. I wonder if the list is broken because we're using the 'convenience' address ingen@drobilla.net and not ingen@lists.drobilla.net | 20:24 |
| drobilla | Well, half broken for me anyway except on Android which can magically see it | 20:24 |
| *** drobilla has quit IRC | 20:40 | |
| *** drobilla has joined #ingen | 20:53 | |
| *** thorwil has quit IRC | 21:19 | |
| *** edogawa has quit IRC | 23:29 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!
