| HarryHaaren | drobilla, puglPoseExpose( view, x, y, w, h) will get called for every pixel of movement during a drag | 00:10 |
|---|---|---|
| HarryHaaren | its *much* slower in reacting than the way its currently running. | 00:10 |
| HarryHaaren | note that Cairo is still drawing all of the surface, so there's improvemnt to be had there | 00:11 |
| HarryHaaren | question I'm asking is, is this designed to work for every pixel of movement, or should there be some filter on speed in puglEventExpose() calls | 00:11 |
| HarryHaaren | also, PuglDisplayFunc() only has a view, no rectangle, so I can't make Cairo redraw only a critical area | 00:13 |
| drobilla | HarryHaaren: Why is post expose being called? | 00:14 |
| drobilla | HarryHaaren: An expose will happen, for sure, because it's literally an expose, but the (e.g.) X11 backend posts that | 00:15 |
| drobilla | i.e. that should have been the case before as well | 00:15 |
| drobilla | and yes, the display function needs to be able to request a specific region for this to have any point at all | 00:15 |
| HarryHaaren | puglPostExpose() is the function to redraw just a region, the one I added? | 00:16 |
| drobilla | Yes, but that's for the UI to call if it explicitly wants to invalidate a region | 00:17 |
| drobilla | How is it being called when the mouse moves? | 00:17 |
| HarryHaaren | take a slider for example | 00:17 |
| HarryHaaren | the widget needs to expose the region it lives in on mouse-drag event | 00:17 |
| HarryHaaren | i have a widget hier-archy here, and it calls puglPostExpose() with the redraw rectangle in pixels | 00:18 |
| drobilla | That would have been happening before, too, though | 00:18 |
| drobilla | Basically everything is the same except you're adding a more constrained region, so I don't see how it could get worse | 00:18 |
| HarryHaaren | yep. Sorry I don't see what you're asking. | 00:18 |
| drobilla | Well, let me put it this way. Previously: *bunch of stuff happens, to redraw entire window* Now: *bunch of stuff happens, to redraw just a portion* | 00:19 |
| drobilla | The *bunch of stuff happens* is the same | 00:19 |
| drobilla | So how could it get slower? | 00:19 |
| HarryHaaren | because before the view->redisplay flag was being checked, and I have a usleep() in the processEvents() loop. Now we don't check a flag, but *immidiatly* draw | 00:19 |
| drobilla | ah. | 00:20 |
| HarryHaaren | the immidiate draw causes it to *never* skip a pixel or two of movement, while before it would skip some pixels movement | 00:20 |
| drobilla | So somebody needs to actually keep a list of rectangles around | 00:20 |
| HarryHaaren | actually a single rectangle: just the "biggest common rectangle" or whatever | 00:21 |
| drobilla | (or maybe be lazy and just merge them into one possibly ridiculously imprecise one) | 00:21 |
| HarryHaaren | yes | 00:21 |
| HarryHaaren | :) | 00:21 |
| HarryHaaren | cairo has a clip() function, which can be used to only have cairo redraw a given rect | 00:22 |
| drobilla | Although system-originated exposes will not benefit from this currently | 00:22 |
| HarryHaaren | its user-originated ones that occur most frequently (and are most important) though right? | 00:22 |
| drobilla | ........... this is getting tookit-ey and I don't like it | 00:22 |
| HarryHaaren | aka, mouse drag on slider -> slider moves | 00:22 |
| HarryHaaren | drobilla, I'm building a toolkit *on* PUGL, not *in* PUGL | 00:23 |
| drobilla | Well, swing the mouse across the window, and you get the same | 00:23 |
| HarryHaaren | its AVTK v2 essentially, and yes its toolkit-y | 00:23 |
| drobilla | Unless the window system is clever about this with hardware cursors, I suppose | 00:23 |
| drobilla | Which is quite likely the case but I'm dumb | 00:23 |
| HarryHaaren | i think that's the case yeah.. | 00:23 |
| HarryHaaren | not you being dumb, the mouse thing :D Sorry. | 00:23 |
| drobilla | So swing a window across your window would be it | 00:23 |
| drobilla | Hm. So, basically, instead of a flag, we keep a rectangle | 00:24 |
| HarryHaaren | i think the solution is to use the flag just like the "normal" expose event | 00:24 |
| HarryHaaren | yeah, or a flag + rectangle | 00:24 |
| drobilla | puglPostRedisplay will just set it to the whole window | 00:24 |
| HarryHaaren | yes | 00:24 |
| drobilla | the precise one is, well, more precise | 00:24 |
| drobilla | and maybe the expose events from the system should do likewise but we can ignore that | 00:24 |
| HarryHaaren | yep sounds good. | 00:25 |
| drobilla | pretty much, but non-empty rectangle can probably serve as a flag too | 00:25 |
| HarryHaaren | so moving the PuglEventExpose instance might be good to have in the impl struct? | 00:25 |
| HarryHaaren | rather than a const one in the actual redraw-code? | 00:25 |
| drobilla | Seems sketchy to re-use an event for not-an-event, but maybe not | 00:26 |
| HarryHaaren | use the same one, set the rectangle to 0,0,width,height for "normal", and set to custom precies rect otherwise? | 00:26 |
| HarryHaaren | this is literally the event that will be sent | 00:26 |
| drobilla | actually, I notice that puglProcessEvents already does this. it handles the flag by firing off an event | 00:26 |
| HarryHaaren | only it won't be on the stack, but in the impl struct | 00:26 |
| HarryHaaren | yes. | 00:26 |
| drobilla | Seems reasonable | 00:26 |
| HarryHaaren | that's the issue, my crude version of postExpose() doesn't. | 00:27 |
| HarryHaaren | cool, I'll do that then... and see if things speed up over "normal" mode. | 00:27 |
| HarryHaaren | right, bedtime too, that's for tomorrow. Laters, enjoy the evening! | 00:27 |
| drobilla | 'night | 00:28 |
| *** HarryHaaren has quit IRC | 00:29 | |
| *** NickSB has quit IRC | 01:08 | |
| *** NickSB has joined #lv2 | 01:15 | |
| *** ricardocrudo has joined #lv2 | 01:20 | |
| *** ricardocrudo has quit IRC | 01:56 | |
| *** velho has joined #lv2 | 02:19 | |
| *** velho has quit IRC | 02:32 | |
| *** velho has joined #lv2 | 02:33 | |
| *** velho has quit IRC | 03:48 | |
| *** velho has joined #lv2 | 03:54 | |
| *** velho has quit IRC | 04:09 | |
| *** gabrbedd has quit IRC | 04:14 | |
| *** velho has joined #lv2 | 04:45 | |
| *** velho_ has joined #lv2 | 04:48 | |
| *** velho has quit IRC | 04:51 | |
| *** velho_ has quit IRC | 05:01 | |
| *** velho has joined #lv2 | 05:04 | |
| *** velho has quit IRC | 05:25 | |
| *** grejppi has quit IRC | 05:28 | |
| *** edogawa has joined #lv2 | 07:30 | |
| *** edogawa_ has joined #lv2 | 08:04 | |
| *** edogawa has quit IRC | 08:07 | |
| *** edogawa_ is now known as edogawa | 08:17 | |
| *** edogawa has quit IRC | 09:36 | |
| *** edogawa has joined #lv2 | 09:39 | |
| *** edogawa has quit IRC | 10:27 | |
| *** edogawa has joined #lv2 | 10:54 | |
| *** NickSB2 has joined #lv2 | 11:24 | |
| *** grejppi has joined #lv2 | 11:43 | |
| *** ricardocrudo has joined #lv2 | 11:53 | |
| bgola | drobilla: is it possible to save / export a graph in ingen using the rest api? | 12:32 |
| *** rncbc_jolla has joined #lv2 | 12:40 | |
| *** gianMOD has joined #lv2 | 13:10 | |
| *** p0nce has joined #lv2 | 13:49 | |
| p0nce | hi, trick question | 13:50 |
| p0nce | is there a market for commercial LV2 plugins? | 13:50 |
| p0nce | I'd like to know if implementing LV2 worth it | 13:50 |
| p0nce | in a format-abstracting library | 13:50 |
| *** NickSB2 has quit IRC | 13:51 | |
| Joeboy | p0nce: At a guess, probably not. Linuxdsp just stopped selling lv2 plugins largely on the basis of lack of demand. Other than that I don't think there's much data to go on. | 13:56 |
| Joeboy | p0nce: Of cource it would be great if you did it anyway. | 13:57 |
| Joeboy | p0nce: The mod duo might possibly open the market up a bit when released. | 13:57 |
| gianMOD | hi Joeboy | 14:04 |
| gianMOD | yep. we hope so :-) | 14:04 |
| gianMOD | I've been talking to developers about it | 14:04 |
| gianMOD | even LinuxDSP is interested | 14:04 |
| gianMOD | but it is clear that their interest is just because the MOD is not a Desktop environment | 14:05 |
| gianMOD | in the Desktop Environments VST seems to hold supremacy | 14:05 |
| Joeboy | Yeah, the mod is in a very good position in the realm of ultra-flexible hardware fx boxes | 14:06 |
| gianMOD | sure | 14:06 |
| Joeboy | which seem like an idea whose time probably should have come a while ago already | 14:06 |
| gianMOD | i'm lucky it didn't :-) | 14:07 |
| gianMOD | we intend to shoot in both fields | 14:07 |
| Joeboy | gianMOD: I had a crazy plan to do a baremetal lv2 host a while ago, which you have saved me from. | 14:07 |
| p0nce | interesting project, since the Owl is ARM, will the mod duo be x86? | 14:08 |
| gianMOD | as we'll release the MOD softwares for desktop as well | 14:08 |
| Joeboy | p0nce: It's arm iirc | 14:08 |
| gianMOD | as it will be all open source and free, maybe people adopt it due to the easiness of the GUI | 14:08 |
| gianMOD | the current MOD, the Quadra , is Intel | 14:09 |
| gianMOD | the MOD Duo is ARM, but we didn't ship it yet | 14:09 |
| gianMOD | we're still to decide wether we will continue to offer the intel platform | 14:09 |
| gianMOD | I'm in China right now | 14:09 |
| p0nce | I have an owl and never used it :| ARM + only big jacks delayed it | 14:10 |
| gianMOD | and one of my acquisitions is an ARM OctaCore 2.0 GHz board | 14:10 |
| p0nce | XLR would be great | 14:10 |
| gianMOD | if this beast is as powerfull as it seems I believe the MOD Intel days are over | 14:10 |
| gianMOD | XLR is way too big | 14:10 |
| Joeboy | gianMOD: I think the duo will live or die according to how stable it is (or how buggy it isn't). The kind of people you need to get excited about it won't put up with random crashes / glitches. I've heard positive things in this regard though. | 14:10 |
| gianMOD | we have XLR on the Qaudra | 14:11 |
| gianMOD | the Quadra is pretty stable | 14:11 |
| p0nce | didn't know about the quadra, but looks more interesting :) | 14:11 |
| p0nce | than owl or mod duo | 14:11 |
| p0nce | that's just me | 14:11 |
| gianMOD | is depends much more on the plugins than anything else | 14:11 |
| gianMOD | the Quadra is a great machine | 14:12 |
| gianMOD | the reason to buy this ARM OctaCore is exactly to targer a New Quadra | 14:12 |
| gianMOD | *target | 14:12 |
| gianMOD | i believe that eight cores running at 2.0GHz might do the job | 14:12 |
| gianMOD | but I can only believe when I see | 14:13 |
| gianMOD | the intel platform is too cumbersome for emnedding | 14:13 |
| gianMOD | embedding | 14:13 |
| gianMOD | BIOS sucks | 14:13 |
| gianMOD | Cooler sucks | 14:14 |
| gianMOD | No USB Device sucks | 14:14 |
| gianMOD | no GPIOs Sucks | 14:14 |
| gianMOD | no I2S sucks | 14:14 |
| p0nce | I'm only talking from a plugin developer pov | 14:14 |
| p0nce | x86 is well known for us | 14:14 |
| gianMOD | yep. the CPU horsepower does not suck at all :-) | 14:15 |
| gianMOD | well. so far all our job to port to ARM has been on reconfiguring makefiles | 14:15 |
| gianMOD | but I reckon that at some point we'll have to really go into the code of some plugins in order to extract the most form the CPU | 14:16 |
| gianMOD | specially in order to use the NEON and the Floating point units | 14:16 |
| p0nce | really what I'd like is a VST host in a box, cheaper than a muse receptor | 14:19 |
| *** rncbc_jolla has quit IRC | 14:19 | |
| p0nce | but I guess it's way different internally | 14:19 |
| gianMOD | p0nce: it surely is | 14:20 |
| Joeboy | I think there's some version of VST that's designed for hardware applications | 14:20 |
| Joeboy | embedded applications I mean | 14:20 |
| Joeboy | I don't know if anybody uses it | 14:20 |
| gianMOD | have yo ever tried V-MAchine ? | 14:20 |
| Joeboy | Not me | 14:20 |
| gianMOD | or the V-Ped | 14:21 |
| p0nce | interesting, thx | 14:21 |
| gianMOD | they are both VST hardware hosts | 14:23 |
| Joeboy | Competition for the MODs? | 14:24 |
| gianMOD | kind of | 14:24 |
| gianMOD | but they already existed | 14:24 |
| gianMOD | before us | 14:24 |
| gianMOD | i've never used none of them | 14:24 |
| gianMOD | but reviews aren't that good | 14:24 |
| p0nce | ok thanks for informations | 14:32 |
| p0nce | it seems VST has made inroads on linux too | 14:32 |
| p0nce | despite being VST | 14:32 |
| gianMOD | p0nce: what do you mean? | 14:35 |
| *** HarryHaaren has joined #lv2 | 14:36 | |
| p0nce | there are more commercial VST for linux from what I see | 14:36 |
| p0nce | than LV2 | 14:36 |
| gianMOD | but what about VST support? | 14:37 |
| p0nce | dunno | 14:37 |
| gianMOD | AFAIK there still no official support | 14:38 |
| gianMOD | guess this poses a kind of a drawback | 14:38 |
| HarryHaaren | p0nce, is there anything in particular that you're missing in LV2 land? | 14:49 |
| p0nce | I was wondering about the size of the plugin market there | 14:50 |
| p0nce | nothing is missing, I can read the header and se it's well done | 14:50 |
| HarryHaaren | p0nce, well its a "growing market", and there's a lot of serious improvements in plugins in the last 1/2 year alone | 14:55 |
| HarryHaaren | p0nce, are you a developer? Or what is your interest | 14:56 |
| p0nce | I've done some VST/AU plugins (hobby) considering to do it fulltime | 14:56 |
| HarryHaaren | p0nce, cool. What type of plugins have you written? | 14:57 |
| p0nce | small effects | 14:57 |
| p0nce | a small synth | 14:57 |
| HarryHaaren | sounds cool, any links / demos? | 14:57 |
| p0nce | gamesfrommars.fr/plugins/ | 14:58 |
| p0nce | I used WDL to have AU/VST wrapper, now writing own wrapper | 14:58 |
| p0nce | looks reasonable to be intested in all formats | 14:58 |
| HarryHaaren | p0nce, so LV2 is amazing as it can be extended transparently: no API / ABI breakage, hosts can choose to support specific extensions or not | 14:59 |
| HarryHaaren | an example is perhaps the "worker-thread", a host allows the plugin to do work in a non-RT thread | 14:59 |
| p0nce | as I see it, LV2 only deals with the audio thread? | 15:00 |
| HarryHaaren | very useful for loading samples etc, and it saves the plugin from having to do x-thread comms | 15:00 |
| p0nce | is there a list of extensions somewhere? | 15:00 |
| p0nce | I don't see it in the sdk | 15:01 |
| HarryHaaren | these are the "official" ones, but any plugin-author can release thier own extensions: lv2plug.in/ns/ | 15:02 |
| p0nce | how would I manage the GUI? | 15:03 |
| p0nce | do I have a parent window to attach to? or LV2 let me do anything | 15:03 |
| HarryHaaren | p0nce, there's a few different ways of doing this: how do you currently do the UI->DSP communication for the knobs on eg Koch? | 15:04 |
| HarryHaaren | does the UI have an "instance pointer" of the DSP, and communicate directly? | 15:04 |
| *** gabrbedd has joined #lv2 | 15:05 | |
| p0nce | in VST, the host makes all things UI-related from its UI thread, UI -> DSP is usually handled through locked/lockfree queues | 15:05 |
| p0nce | UI has a pointer to the DSP object | 15:06 |
| *** gabrbedd has quit IRC | 15:06 | |
| p0nce | I don't remember it if signals param change to just DSP or also the host | 15:06 |
| p0nce | also. in VST/AU you get a window handle to draw into, and I believe AAX/VST3 is around the same | 15:07 |
| p0nce | s/to draw into/to derive from | 15:07 |
| *** gabrbedd has joined #lv2 | 15:08 | |
| p0nce | HarryHaaren: what makes you think it's a growing market? | 15:08 |
| p0nce | sorry to be annoying | 15:08 |
| HarryHaaren | p0nce, right so in LV2 the UI and DSP *should be* *totally* seperated, and *all* communications done using control ports, or else Atom messages | 15:08 |
| HarryHaaren | p0nce, please ask questions :) I'm proud to be a member of the LV2 community, and I'm also currently trying to make some money writing plugins etc | 15:09 |
| p0nce | HarryHaaren: that's why advanced audio companies do from what I've seen, they have cleanly separated UI and dsp it with ports | 15:09 |
| p0nce | -it | 15:10 |
| p0nce | HarryHaaren: links? | 15:10 |
| HarryHaaren | I've been releasing LV2 plugins for the year and a half, and its easier to get people to financially support now than when I started. | 15:10 |
| p0nce | fantastic | 15:10 |
| HarryHaaren | that said, I'm not yet making a full-time living from this | 15:10 |
| HarryHaaren | so its not a "lots-of-money available" situation | 15:10 |
| HarryHaaren | I'm http://openavproductions.com/ | 15:10 |
| p0nce | nice | 15:12 |
| HarryHaaren | p0nce, what I was going to say was that LV2 has these "Atom" objects to communicate, and that they make a very clean and nice seperation between UI and DSP | 15:15 |
| HarryHaaren | that basically means that the current code you have might need to be "seperated" into UI and DSP more than it currnetly is | 15:16 |
| HarryHaaren | the advantage is that the UI can run on another computer, networked, tablet, or the host can generate one | 15:16 |
| p0nce | indeed, JUCE and IPlug/WDL are known for tight coupling of UI and DSP | 15:17 |
| p0nce | in the move to AAX, some companies rewrote the JUCE plugin client | 15:17 |
| p0nce | I'm not sure of all the reasons of course | 15:18 |
| HarryHaaren | p0nce, the LV2 distribution has some example plugins, they're good learning resources | 15:25 |
| HarryHaaren | p0nce, but if you want to "write-once" and "deploy everywhere", then DISTRHO is your man: distrho.sourceforge.net | 15:26 |
| p0nce | thanks | 15:26 |
| HarryHaaren | p0nce, check this out too, its LV2 software in a hardware pedal-box: portalmod.com/home | 15:27 |
| HarryHaaren | drobilla, I've reduced the number of widgets in my double-buffering test UI (a lot), and without partial redraws it responds really fast. Wonder what I'll be like once partial-exposes works! | 15:32 |
| *** Haskellfant has quit IRC | 15:46 | |
| *** Haskellfant has joined #lv2 | 15:46 | |
| *** ricardocrudo has quit IRC | 17:00 | |
| *** falktx has joined #lv2 | 17:06 | |
| *** zth has joined #lv2 | 17:08 | |
| *** ricardocrudo has joined #lv2 | 17:08 | |
| *** ricardocrudo has joined #lv2 | 17:08 | |
| drobilla | bgola: No. Saving happens client-side | 17:20 |
| drobilla | bgola: I need to move it to the server to support saving plugin state... | 17:20 |
| bgola | drobilla: hm, nice :) im doing some tests with mod-ui controlling ingen... and maybe use ingen instead of mod-host.. do you think it makes sense? | 17:27 |
| drobilla | HarryHaaren: I guess you can simply clip with cairo and "drawing" all the stuff outside the rect is "free enough"... | 17:27 |
| bgola | i don't see a reason to keep supporting / developing our own host if ingen can be controlled via socket (as mod-host) | 17:27 |
| drobilla | bgola: Need to do some things to make it be able to do some 'ingeney' things to replace the current UI, but a web UI for Ingen would be awesome | 17:28 |
| drobilla | I wish there was a clearly good JS serialisation... the possibility of URI values, and datatypes, means objects for the values which is pretty ugly :/ | 17:28 |
| drobilla | bgola: Keep me posted. I can make changes to the server as necessary, though time's running a taaaaaad thin lately... | 17:30 |
| *** gianMOD has quit IRC | 17:31 | |
| falktx | bgola: the same can be done via carla engine with some tweaks | 17:31 |
| falktx | I have full osc support in place not sockets. but shouldn't be too hard to get it working | 17:32 |
| falktx | bgola: is there a list of required API calls somewhere? | 17:42 |
| *** p0nce has left #lv2 | 17:59 | |
| *** gianMOD has joined #lv2 | 18:07 | |
| *** falktx has quit IRC | 18:09 | |
| *** rncbc has joined #lv2 | 18:17 | |
| *** falktx has joined #lv2 | 18:29 | |
| *** mlpug has joined #lv2 | 18:40 | |
| *** rncbc has quit IRC | 18:46 | |
| drobilla | Took nearly 10 years for anybody to notice loading files with spaces doesn't work | 19:42 |
| drobilla | How delightfully Unix of us :) | 19:42 |
| falktx | drobilla: it was working before in lilv | 19:43 |
| drobilla | falktx: Partially | 19:43 |
| falktx | I remember having pianoteq working fine at some time | 19:44 |
| drobilla | (also invalidly, for the ttl part) | 19:44 |
| drobilla | Oh well | 19:44 |
| Anchakor | spaces like space instead of tabs? | 19:46 |
| drobilla | Anchakor: in URIs | 19:47 |
| Anchakor | ah | 19:48 |
| Anchakor | does loading files with '%20' work? :) | 19:49 |
| falktx | not in URIs, in paths | 19:50 |
| falktx | as in: lv2:binary <this file.so>; | 19:51 |
| falktx | or: rdfs:seeAlso <that file.ttl> | 19:51 |
| Anchakor | yeah | 19:52 |
| *** zth has quit IRC | 19:55 | |
| *** Anchakor_ has quit IRC | 19:56 | |
| *** Anchakor_ has joined #lv2 | 20:00 | |
| drobilla | falktx: that *is* a URI | 20:05 |
| drobilla | Anchakor: it does now | 20:05 |
| drobilla | falktx: i.e. that's invalid | 20:06 |
| falktx | well, then I have to say using URIs for that was a mistake | 20:06 |
| drobilla | ... yeah, okay | 20:06 |
| falktx | drobilla: so I assume absolute paths must be handled as "<file:///...>" ? | 20:06 |
| drobilla | falktx: depends what the base URI is, but that aside, yes | 20:07 |
| drobilla | </foo/bar> would be /foo/bar in the bundle | 20:07 |
| drobilla | I can make the parser lax to handle spaces, but see now way around the latter | 20:07 |
| *** NickSB2 has joined #lv2 | 20:11 | |
| drobilla | I will try to make it print an error, but still parse | 20:25 |
| drobilla | if it's a printable character, anyway | 20:25 |
| drobilla | I can't imagine passing through escapes and stuff is at all a good idea... | 20:25 |
| drobilla | heh, which works, but one of the turtle conformance tests fails, it explicitly is a bad test for this | 20:28 |
| drobilla | So I guess I need to add to the API so you can toggle strict :/ | 20:29 |
| *** mlpug has quit IRC | 20:37 | |
| drobilla | Bleh, well, kinda messy.. reader lax by default, serdi strict by default, but this preserves old behaviour (but with proper error messages on invalid input) without bumping lilv's serd dependency or sprinkling set_strict(false) throughout the code | 20:52 |
| drobilla | Unfortunately -e (tolerate errors) as in raptor is already taken | 20:53 |
| *** ricardocrudo has quit IRC | 22:04 | |
| *** wumpus has joined #lv2 | 22:11 | |
| *** wumpus has joined #lv2 | 22:13 | |
| *** gianMOD has quit IRC | 23:15 | |
| *** edogawa has quit IRC | 23:19 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!