| ghaydn | this is it: http://pastebin.com/AqUDGpJN | 00:05 |
|---|---|---|
| *** ghaydn has quit IRC | 01:01 | |
| *** ghaydn has joined #ingen | 01:31 | |
| *** ghaydn has quit IRC | 01:46 | |
| *** Anchakor_ has quit IRC | 02:29 | |
| *** edogawa has joined #ingen | 08:07 | |
| *** thorwil has joined #ingen | 08:09 | |
| *** Anchakor_ has joined #ingen | 08:35 | |
| *** Anchakor_ has quit IRC | 09:48 | |
| *** Anchakor_ has joined #ingen | 09:50 | |
| *** thorwil has quit IRC | 14:05 | |
| *** dongle is now known as dongl | 14:23 | |
| *** edogawa has quit IRC | 15:31 | |
| *** edogawa has joined #ingen | 15:31 | |
| *** Anchakor_ has quit IRC | 16:57 | |
| *** Anchakor_ has joined #ingen | 16:57 | |
| rgareus | drobilla: can ingen be easily changed to take the same approach to ringbuffering Atom communication in the same way as jalv (and ardour3) does? | 19:12 |
| drobilla | rgareus: Explain? That's how the whole thing does work. | 19:12 |
| rgareus | drobilla: ie not use sigc direct delivery - see http://dev.drobilla.net/ticket/954#comment:3 | 19:12 |
| LAbot | Title: #954 (issues with LV2 Atom Transfer from/to GUI) – drobillad (at dev.drobilla.net) | 19:12 |
| drobilla | rgareus: Not really. | 19:13 |
| drobilla | rgareus: Why? I highly doubt that has anything to do with your problem | 19:13 |
| rgareus | drobilla: could there be 'ui active' flag. that prevents the backend from reading (and responding) to messages from the UI until the UI is completely initialized? | 19:15 |
| rgareus | drobilla: UI writes to ringbuffer, but the backend won't read from that ringbuffer until all the signals are connected. | 19:16 |
| rgareus | drobilla: does that make sense? or do you think that's just a bad workaround? | 19:16 |
| drobilla | rgareus: Mmmmmmmm, well, sort of, but that screams deadlock to me | 19:16 |
| drobilla | UI does something weird and the whole thing seizes up | 19:16 |
| drobilla | rgareus: What does "completely initialized" even mean? | 19:17 |
| drobilla | The question is, if the instance init is sending them, why is it not then ready to receive stuff right away? | 19:17 |
| rgareus | drobilla: the instance is ready to receive. ingen is not | 19:19 |
| drobilla | rgareus: what part of ingen? | 19:20 |
| rgareus | drobilla: ingen only hooks up signals later. Also while it's creating the instance _plugin_ui is unset, | 19:20 |
| drobilla | If it's not clear, I don't actually know what the problem is here yet. | 19:21 |
| rgareus | drobilla: NodeModule::port_activity() { if (!_plugin_ui) { return;} ... | 19:21 |
| drobilla | rgareus: but the GUI/main thread is what must call emit_signals | 19:21 |
| rgareus | drobilla: the UI sends a message while ingen is at _plugin_ui = plugin->ui(app().world(), _block); | 19:22 |
| drobilla | rgareus: as long as everything is set up before it all returns back down to main, that should not be possible | 19:22 |
| rgareus | drobilla: at this point _plugin_ui is just about to be asigned. | 19:22 |
| drobilla | The ingen GUI is not multi-threaded | 19:22 |
| rgareus | drobilla: so? | 19:23 |
| drobilla | rgareus: So there can't be a race like that | 19:23 |
| rgareus | drobilla: message is created in gui-thread. delieved to audio-thread while the GUI is still initializing... | 19:23 |
| rgareus | drobilla: audio-thread processes the event, generated a reply.. | 19:23 |
| drobilla | rgareus: sure, and it will go throguh the engine and generate a reply, which will get sent back to the UI | 19:23 |
| rgareus | drobilla: gui-thread continues.. but the reply is lost. (bceause the GUI was not fully initialized0 | 19:24 |
| drobilla | rgareus: and get queued for handling *in the same thread the UI is being instantiated in* later. | 19:24 |
| rgareus | drobilla: it does not get queued. | 19:24 |
| drobilla | rgareus: Literally everything gets queued, that's what ThreadedSigClientInterface does. | 19:25 |
| rgareus | drobilla: it should be queued. | 19:25 |
| rgareus | drobilla: are you using sigc::signal()? | 19:26 |
| * rgareus reads ingen/client/ThreadedSigClientInterface.hpp | 19:26 | |
| rgareus | drobilla: if it should be queued and only executed later. there's a bug in there. | 19:27 |
| drobilla | rgareus: The point is that 100% of any and all communication to or from the UI is one big queue | 19:27 |
| rgareus | drobilla: because I clearly see that's delivered directly. | 19:28 |
| drobilla | There is no connections and signals everywhere and pointers deep into the engine business like Ardour | 19:28 |
| drobilla | rgareus: Explain. | 19:28 |
| drobilla | you clearly see that it's delivered directly how? "directly" meaning what? | 19:28 |
| rgareus | drobilla: just start it up like blablack did, and notice that the event does never arrive in the GUI. | 19:29 |
| rgareus | drobilla: 'directly' -> use gdb and follow the execution graph. | 19:30 |
| drobilla | But that reply originates from the next element in the queue | 19:31 |
| rgareus | drobilla: I don't even see a call to `NodeModule::port_value_changed` or `NodeModule::port_activity` for the response. | 19:32 |
| rgareus | .. in the GUI thread | 19:32 |
| rgareus | drobilla: how does jalv handle this? because it works in jalv. is this apples vs. oranges? or is there a similarity? | 19:33 |
| drobilla | rgareus: apples vs spaceships | 19:33 |
| drobilla | but the use of 'setting the value' for this is wrong anyway | 19:34 |
| drobilla | I was planning on doing it later today anyway. The feedback thing might need some non-trivial work in the engine | 19:34 |
| rgareus | drobilla: I was wondering a while ago if it's valid for a GUI to send a message during initialization | 19:35 |
| drobilla | I don't see how it could be a race, though. | 19:35 |
| drobilla | rgareus: Well, kinda has to be, since we have no activate()-like-thing, so let's just go with yes | 19:35 |
| rgareus | drobilla: it's not a race per se. I can reproduce 100%. | 19:36 |
| drobilla | Well, it's not stuff happening in the GUI thread while the GUI thread is making the UI, anyway | 19:36 |
| rgareus | drobilla: the initialization thread always breaks in Ingen::Client::lv2_ui_write | 19:36 |
| drobilla | Unless something really hyper severely weird and wrong is going on | 19:36 |
| *** thorwil has joined #ingen | 19:36 | |
| rgareus | drobilla: which probably triggers a context-switch for some reason. | 19:37 |
| rgareus | drobilla: in line 84 | 19:37 |
| rgareus | drobilla: ui->world()->interface()->set_property(port->uri(),....) | 19:38 |
| rgareus | drobilla: mmh it calls EMIT which goes back to sigc, which is not thread-safe | 19:39 |
| drobilla | rgareus: wrong directly | 19:42 |
| drobilla | rgareus: er, wrong direction | 19:42 |
| rgareus | ? | 19:42 |
| drobilla | I forget what class that would be in this case. If you're in gdb, step and tell me | 19:43 |
| drobilla | rgareus: the emit stuff is engine=>GUI | 19:43 |
| rgareus | drobilla: I can get back into gdb | 19:43 |
| drobilla | oh, right, EventWriter | 19:44 |
| drobilla | rgareus: It's a queue push | 19:44 |
| drobilla | If you really don't believe me, you can just run the GUI and the engine in separate processes. They'll talk over a socket | 19:45 |
| rgareus | drobilla: how can you explain what's happening, then? | 19:46 |
| drobilla | rgareus: I have no idea. | 19:46 |
| rgareus | drobilla: it's blablack who sees the issue, I do, and gdb does as well.. | 19:47 |
| drobilla | The signals are connected by NodeModule on construction anyway, they don't depend on the UI existing, so if value_changed and friends aren't being called *at all*, it's something deeper | 19:47 |
| rgareus | drobilla: it could be a simple bug. | 19:47 |
| rgareus | drobilla: or it could be a design-flaw. I don't know yet know the code+concept well enough to judge. | 19:47 |
| drobilla | Nah. *All* things being a big queue is why the design is good. | 19:48 |
| drobilla | and is why I can do fancy things like seprate GUI via TCP or LV2 ports :) | 19:48 |
| drobilla | anyway, clearly I can't be on IRC and get any work done anyway, so I might as well just fix it | 19:48 |
| drobilla | What is the easiest way to see the issue? comment out the run-time sending stuff in a meter? | 19:49 |
| rgareus | drobilla: if you have sisco.lv2 around. start gdb --args ingen -eg; add "simple scope (Stereo) GTK", then add breakpoints, http://pastebin.com/9ms1VvXK, continue. | 19:50 |
| rgareus | use right-click > Show GUI (double click locks the mouse-pointer in move-mode, so that you can't easily use gdb in another terminal) | 19:51 |
| rgareus | drobilla: I've commented out src/sisco.c:327 | 19:52 |
| rgareus | drobilla: //tx_rawaudio(..); but that's not strictly neccesary, just convenient. | 19:53 |
| rgareus | drobilla: sisco's Makefile has '-g' as CFLAG by default, and I've waf configured ingen with --debug | 19:54 |
| drobilla | Man, those deprecation warnings sure are annoying. Maybe I'm pushing it. | 19:56 |
| drobilla | Temporary nuisance vs chorus of ATOMS ARE CONFUSING WHATS GOING ON. Tricky line to walk, that. | 19:57 |
| drobilla | See also: event/atom | 19:57 |
| drobilla | I need to add a 'favourites' like Ardour one of these days | 20:02 |
| drobilla | My Ardour favourites is entirely full of things useful for debugging, which say a lot about how much I get to actually use this crap :) | 20:02 |
| * dongl peers at node.js+RTC Error500 alert-system | 20:10 | |
| drobilla | That set ends up coming back as a delta anyway, which is crap. I guess I'll just fix the comms, then see what's up | 20:15 |
| drobilla | (delta is a messy event...) | 20:19 |
| drobilla | I need some kind of better design for reacting to 'special' property changes | 20:21 |
| rgareus | ? | 20:22 |
| drobilla | rgareus: Ingen's design is based on events, all operations happen through them, like, Connect | 20:25 |
| drobilla | rgareus: Delta is the one that changes properties (delta as in diff).. but some properties are special, like changing polyphony | 20:25 |
| drobilla | So it's just a massive if for all that. | 20:26 |
| drobilla | Design wart, but not quite big enough to be alarming yet | 20:26 |
| drobilla | Considering how dramatically this thing has evolved over the years, it's alright, I guess | 20:26 |
| rgareus | drobilla: "delta as in diff" clarified it what you meant with "delta is a messy event". | 20:27 |
| rgareus | drobilla: can you reproduce the problem? | 20:28 |
| rgareus | drobilla: compare ingen's behaviour with jalv.gtk 'http://gareus.org/oss/lv2/sisco#Stereo_gtk' -- with ingen the GUi comes up with all knobs set to zero because the settings are not transferred to the GUI. | 20:30 |
| LAbot | Title: LV2 Plugin Documentation (at gareus.org) | 20:30 |
| drobilla | I don't know why I avoided "diff" terminology both in ingen and in the patch vocabulary, which probably should have been called that | 20:30 |
| drobilla | "patch" in audio land doesn't make you think diff | 20:31 |
| drobilla | and maybe "delta" only does for mathy types? | 20:31 |
| drobilla | rgareus: Yeah, but I'm opting to start with fixing related things that need fixing anyway | 20:31 |
| rgareus | drobilla: fair enough. | 20:32 |
| drobilla | Which might actually be the source of the problem, but I don't know. | 20:33 |
| drobilla | Basically step 1 is always make sure the comms make sense. | 20:33 |
| drobilla | They don't. | 20:33 |
| rgareus | drobilla: If I can provide debug information, i'd be happy todo that. | 20:33 |
| drobilla | rgareus: Definitely a ton of NodeModule::value_changed being called on embed | 20:48 |
| drobilla | I can't tell why "a ton of". Maybe I'll try as an LV2. Ingen's debug dumping sucks compared to jalv -d | 20:48 |
| rgareus | drobilla: I think some of them are due to loops | 20:49 |
| rgareus | drobilla: gui event goes back to gui.. | 20:50 |
| rgareus | drobilla: ..creates another event from the gui | 20:50 |
| rgareus | drobilla: For sisco.lv2, I've put a stopgap in place in the latest git revision a few days ago | 20:50 |
| drobilla | I wouldn't stopgap around Ingen, really, it's just pretty flaky in this regard still | 20:51 |
| drobilla | This mechanism was originally for 'set port value' stuff, which avoids feedback by value equivalence | 20:51 |
| drobilla | But this should be 'activity' anyway, so maybe fixing that will magically make it go away | 20:51 |
| drobilla | rgareus: How many messages does sisco init send? | 20:52 |
| rgareus | drobilla: there's also value-equivalence in the GUI. but that depends on the GTK-thread being active | 20:52 |
| rgareus | drobilla: which eventually stops the loop. | 20:52 |
| rgareus | drobilla: but the value of the dial itself is not updated until the GUI thread comes around | 20:52 |
| rgareus | drobilla: init only one | 20:52 |
| drobilla | I guess you mean vs a drawing thead you are using internally | 20:52 |
| drobilla | (LV2 UI dictates one thread for all methods) | 20:53 |
| drobilla | I also personally think it's batshit insane to involve threads in UIs in the first place, but I don't really know anything about GL | 20:54 |
| drobilla | On that, maybe the red book would be a good reading project | 20:54 |
| drobilla | If, y'know, I had time for recreational reading projects | 20:54 |
| rgareus | drobilla: which red-book? these days there's too many of them :) | 20:55 |
| drobilla | The GL one. | 20:56 |
| drobilla | Apparently there's a new edition that's all about shaders, which I guess things are, these days. | 20:56 |
| drobilla | Maybe if my living nightmare of having to take a course turns out to be true, I'll get lucky and some GL using course will happen next fall. | 20:57 |
| drobilla | (FML) | 20:57 |
| rgareus | drobilla: http://glprogramming.com/red/ ? | 20:57 |
| LAbot | Title: OpenGL Programming Guide : Table of Contents (at glprogramming.com) | 20:57 |
| drobilla | Yeah | 20:57 |
| rgareus | or the hard-copy http://www.amazon.com/OpenGL-Programming-Guide-Official-Learning/dp/0321552628 | 20:58 |
| drobilla | I don't know much about it, other than being under the impression that there was a The GL Book, and that's the one | 20:58 |
| drobilla | (I have never actually read The C Book) | 20:58 |
| drobilla | Avoiding "feedback" in Ingen isn't so trivial, sometimes a Put can actually create something with a more expressive description | 21:00 |
| drobilla | Maybe I can just special case it for set_property and it'll be Good Enough™ | 21:00 |
| rgareus | drobilla: anyway.. initially there should be UI => Plugin a <http://gareus.org/oss/lv2/sisco#ui_on> . | 21:00 |
| LAbot | Title: LV2 Plugin Documentation (at gareus.org) | 21:00 |
| drobilla | rgareus: So just one? | 21:00 |
| rgareus | which triggers a response Plugin => UI a <http://gareus.org/oss/lv2/sisco#ui_state> | 21:00 |
| LAbot | Title: LV2 Plugin Documentation (at gareus.org) | 21:00 |
| rgareus | drobilla: yes | 21:00 |
| drobilla | rgareus: okay, thanks | 21:00 |
| drobilla | LAbot: shut up | 21:01 |
| LAbot | drobilla: Error: "shut" is not a valid command. | 21:01 |
| drobilla | Suppose I could just take its voice away | 21:01 |
| rgareus | drobilla: and then there are are few 'UI => Plugin' messages | 21:01 |
| drobilla | rgareus: so not just one | 21:01 |
| drobilla | UI => Plugin => UI, then many UI => Plugin? | 21:01 |
| rgareus | drobilla: correct | 21:02 |
| drobilla | even if the response isn't received? | 21:02 |
| rgareus | drobilla: the latter are generated because the UI updates its state (and then redundanly notifies the backend of those) | 21:02 |
| drobilla | So, the same shit Ingen does :) | 21:03 |
| rgareus | drobilla: if the first reply Plugin => UI does not make it though. the UI won't create further messages | 21:03 |
| drobilla | rgareus: ok | 21:03 |
| rgareus | drobilla: the GUI does not care about the origin of the value-change (it coud be user+mouse or MIDI-binding or whatever). it always tells the backend about the new state. | 21:05 |
| rgareus | drobilla: I could filter out state-restore. | 21:05 |
| rgareus | drobilla: but I didn't. | 21:05 |
| drobilla | Guess I have to make the broadcaster have a concept of 'ignore this client' when sending updates | 21:08 |
| drobilla | Eventually I will get this insanity calmed down to be able to actually trace the damned problem :) | 21:08 |
| * drobilla totally should have went outside more today | 21:09 | |
| rgareus | drobilla: I could probably whip up a small test-client. | 21:09 |
| rgareus | drobilla: or just edit gui/sisco.c:2810 and add a return(); as first thing in port_event() | 21:10 |
| drobilla | rgareus: If it still proves tricky, that might be useful, but this needs sorting out anyway | 21:10 |
| rgareus | drobilla: this will make the GUI shut up after the first event. | 21:10 |
| drobilla | e.g. running ingen in jalv -d and doing something like this should be a few messages, all of which totally make sense | 21:10 |
| drobilla | There is a deeper philosophical issue here I'll just ignore :) | 21:12 |
| drobilla | e.g. ingen UI does *not* assume connections are actually made when requesting | 21:12 |
| drobilla | it sends the request, then the UI (view) is updated by the response | 21:13 |
| drobilla | For special properties this may actually be how it needs to work, too. | 21:13 |
| drobilla | But a bit stupid "ignore this client" will do, for now. | 21:13 |
| drobilla | ... I really hope releasing Ingen doesn't interfere with my hobby of making it perfect :) | 21:14 |
| *** thorwil has quit IRC | 21:16 | |
| rgareus | drobilla: FWIW, http://pastebin.com/stYHPGsF | 21:16 |
| drobilla | rgareus: Thanks | 21:17 |
| drobilla | rgareus: Hrm, I should probably figure out how to special case vectors to avoid all those type tags | 21:17 |
| drobilla | Shame that the Turtle pretty types don't correspond to our actual needed types. Had to put some hand-waving in my paper around this. | 21:17 |
| Anchakor | did you write the paper about atoms or gave up? | 21:18 |
| drobilla | Anchakor: Not finished yet, deadline extension and all, but I wrote it. Almost done. | 21:19 |
| Anchakor | to when was the deadline extended? | 21:20 |
| drobilla | 3rd | 21:20 |
| drobilla | I can send the WIP if anyone's interested | 21:20 |
| Anchakor | I could give my 2c on it | 21:20 |
| drobilla | Currently fizzles out around 'applications', no conclusion | 21:21 |
| drobilla | MAKE PLUGIN UI { | 21:25 |
| drobilla | WRITE 0 | 21:25 |
| drobilla | } END MAKE PLUGIN UI | 21:25 |
| drobilla | warning: Non-port item added to module. | 21:25 |
| drobilla | WRITE 0 | 21:25 |
| drobilla | WRITE 0 | 21:25 |
| drobilla | Hm, so there's the one write by the UI, and two more from... somewhere | 21:25 |
| drobilla | but this is lv2_ui_write | 21:25 |
| drobilla | guess it's breakpoint time | 21:26 |
| drobilla | fuck off, SIGPIPE | 21:27 |
| drobilla | the jack dummy driver really isn't what I wish it was | 21:28 |
| drobilla | rgareus: Actually, it sends some on size allocate, too | 21:35 |
| drobilla | http://pastebin.com/KwDtKWvx | 21:35 |
| drobilla | Which ends up happening the next Gtk main tick before the next ingen event is processed, I think | 21:36 |
| drobilla | I am not really sure what the spec could or should say about things like this. | 21:38 |
| rgareus | drobilla: odd that I don't see this in jalv. | 21:40 |
| rgareus | drobilla: and an interesting feat of gtk. | 21:41 |
| drobilla | rgareus: You really should follow the universal bloody conventions when naming your types and properties :P | 21:41 |
| rgareus | drobilla: you mean variable names or URIs? | 21:42 |
| rgareus | (or both?) | 21:42 |
| drobilla | rgareus: Probably not really problematic anyway. Most likely happens in jalv too, you'd just have to specifically be looking for it | 21:42 |
| drobilla | rgareus: eg:MyType eg:myProperty | 21:42 |
| * drobilla is not a huge fan of camel case either, except for types | 21:43 | |
| rgareus | drobilla: URIs, yeah. sadly all this code predates you educating me about the convention. | 21:43 |
| drobilla | Yeah, just idly bitching, nevermind me :) | 21:43 |
| drobilla | I need to do some work on the book... | 21:44 |
| rgareus | drobilla: I considered changing it. there's no 1.0 release yet, so I can just change it and saved state will be lost. | 21:44 |
| rgareus | drobilla: I may still do this when I'm bored. | 21:45 |
| drobilla | Yeah, nothing like some mindless renaming to feel productive without having to actually think :) | 21:45 |
| rgareus | drobilla: excactly. | 21:46 |
| rgareus | drobilla: though 'good urls don't change'. I can appease my conscience that they were not good URLs to begin with and explain to users that there was no 1.0 yet.... but what a waste of time. | 21:48 |
| drobilla | I care less since there's an "official" scope example | 21:48 |
| drobilla | Things pitched as examples being weird is problematic. | 21:49 |
| drobilla | Anyway, it would seem the notify response isn't getting sent, period | 21:51 |
| drobilla | like, from the engine, it's not making it to the UI at all | 21:52 |
| rgareus | drobilla: yes | 21:52 |
| drobilla | So all that stuff about it getting there but racey timing not ready to receive and so on was way off | 21:54 |
| rgareus | drobilla: The response is put into the Atom buffer during lilv_instance_run() | 21:54 |
| rgareus | drobilla: but I didn't see NodeModule::port_activity() | 21:55 |
| drobilla | Right, and I'm currently looking for the code that scans that to decide if anything needs sendig to clients... | 21:55 |
| rgareus | drobilla: nor NodeModule::port_value_changed() | 21:55 |
| drobilla | which really should be in here somewhere... | 21:55 |
| drobilla | rgareus: yeah, but that's universes above the level where it seems to get lost | 21:56 |
| drobilla | like, it's literally just not sent period | 21:56 |
| rgareus | drobilla: IIUC the port subscriptions happens in src/gui/NodeModule.cpp only after the GUI is instantiated | 21:58 |
| rgareus | drobilla: though it should really be done when the plugin is instantiated -- not the GUI. | 21:59 |
| drobilla | that'd do it. | 21:59 |
| drobilla | rgareus: Not really. flood. | 21:59 |
| drobilla | rgareus: == "please send all MIDI everything ever to the UI" | 21:59 |
| drobilla | otherwise, at best it wants an occasional bonk so a port can light up | 22:00 |
| drobilla | and even that is off by default | 22:00 |
| rgareus | drobilla: but even then it'll not work, because at the time the event comes. _plugin_ui == 0. the event would not make it though | 22:03 |
| drobilla | rgareus: again, the UI is not multi-threaded | 22:03 |
| drobilla | so no event can "come" in the middle of a function | 22:04 |
| rgareus | drobilla: that's what the backtrace at ticket/954 shows anyway. | 22:04 |
| drobilla | I do not see how that backtrace shows this | 22:05 |
| drobilla | "can send a message to the backend, which is not ring-buffered but directly delivered to the back-end" = false | 22:05 |
| drobilla | The backtrace doesn't say anything about the reply | 22:06 |
| drobilla | Which is not surprising, because there isn't one ;) | 22:06 |
| rgareus | drobilla: mmh indeed. | 22:06 |
| drobilla | I don't blame you, you're conditioned by the pain of Ardour | 22:07 |
| drobilla | In ingen, that whooooooooooooole world of stuff just does not exist at all. All things are just one big linear queue, ringbuffered on both sides | 22:07 |
| drobilla | Assuming the monitoring stuff (set ingen:broadcast = true) works, it's just that this is being set *after* the requests, so no responses | 22:08 |
| drobilla | i.e. you nailed it somewhere up there re: subscription | 22:09 |
| drobilla | rgareus: are you using the dynamic port subscribe stuff? | 22:10 |
| drobilla | something is subscribing, but I can't find what | 22:11 |
| drobilla | and looking at jalv -d it does actually seem to happen first | 22:11 |
| rgareus | drobilla: "dynamic port subscribe" I don't even know what that is in LV2 context. | 22:11 |
| drobilla | rgareus: There are functions for this the UI can call | 22:12 |
| drobilla | Rather than list static port notifications. Added somewhat recently | 22:12 |
| drobilla | Hm. THe problem may be self-contained in PluginUI::create, which literally subscribes after instantiate | 22:13 |
| rgareus | drobilla: from the plugin's POV (backend and UI) all ports are all static as described in the .ttl | 22:14 |
| drobilla | the failed to instantiate case is going to be super annoying :/ | 22:14 |
| drobilla | Yeah, I just don't actually look for notifications. It's pretty annoying. :) | 22:14 |
| rgareus | drobilla: the .ttl includes a notify part, though | 22:14 |
| drobilla | Which means it was probably pushing the ttl thing too far, if *I* was too lazy to implement it | 22:15 |
| drobilla | ... But I'm pretty lazy :) | 22:15 |
| drobilla | rgareus: If I see knobs not at zero does that mean fixed? | 23:15 |
| drobilla | (e.g. hold = 0.5) | 23:15 |
| drobilla | white backgrounds in this UI look horrific in Ingen | 23:16 |
| rgareus | drobilla: yes. and yes. | 23:16 |
| rgareus | drobilla: it uses gtk styles | 23:16 |
| drobilla | rgareus: the real problem was subscribing after instantiate, all local to the same function | 23:17 |
| rgareus | drobilla: so how did/do you solve this? | 23:19 |
| drobilla | 1) grep ingen code for suil_instance_new | 23:20 |
| drobilla | 2) find this in a function, which, immediately *AFTER* that, subscribes to port notifications | 23:20 |
| drobilla | 3) ah | 23:20 |
| drobilla | that said, I fixed a bunch of cracked out comms in the process anyway | 23:21 |
| drobilla | pretty hefty 280 byte message whenever anything changes, but I guess that's the easy/solid way if it's small enough | 23:32 |
| rgareus | drobilla: another issue of /me being lazy | 23:32 |
| drobilla | I sometimes think about turning the Ingen way of things into a framework | 23:33 |
| rgareus | drobilla: just dump the whole state (rather than the change only) | 23:33 |
| drobilla | Which would be quite nice | 23:33 |
| drobilla | But I have no incentive to do so since I have no other apps | 23:33 |
| drobilla | Well... I guess Machina could be | 23:33 |
| drobilla | Well, let me clean up and commit | 23:34 |
| rgareus | but calling 280 bytes 'hefty' is a bit of an overstatement :) | 23:35 |
| rgareus | in particular compared to Kbytes of raw audio-data transmitted plugin => UI | 23:36 |
| drobilla | Fair enough. | 23:37 |
| drobilla | I made atom pretty bloatey anyway since I didn't want to eventually go "shit, 16 bits wasn't enough" | 23:38 |
| drobilla | Totally probably would have been enough though | 23:38 |
| *** edogawa has quit IRC | 23:46 | |
| drobilla | I hope this feedback fix doesn't have consequences... | 23:59 |
| drobilla | Quite possible the GUI itself relies on that in several places | 23:59 |
| drobilla | rgareus: http://dev.drobilla.net/changeset/5326 | 23:59 |
| LAbot | Title: Changeset 5326 – drobillad (at dev.drobilla.net) | 23:59 |
| drobilla | rgareus: Please confirm fix when you get the chance | 23:59 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!