*** gianMOD has joined #lv2 | 00:16 | |
*** gianMOD has quit IRC | 00:21 | |
*** ricardocrudo has joined #lv2 | 00:29 | |
drobilla | HarryHaaren: Your http://openavproductions.com/rtmem/ misses the canonical solution to this problem: ringbuffer it elsewhere | 01:10 |
---|---|---|
HarryHaaren | drobilla, for recording you mean? | 01:11 |
drobilla | HarryHaaren: yeah | 01:11 |
HarryHaaren | drobilla, once the recording is done, it needs to jump straight to the beginning again: unless you want to stream somewhere-else, and then double it back. Its an option, and i'll admit i didn't concider it yet. | 01:12 |
HarryHaaren | doubling the data back is a bit hack-y.. but I guess it works. Only the initial 1 second or so would be plenty.. hmm. | 01:12 |
HarryHaaren | not bad, thanks for the suggestion. | 01:12 |
drobilla | HarryHaaren: Sure, it's not totally without cons | 01:12 |
HarryHaaren | all of them have drawbacks. Horses for courses | 01:13 |
drobilla | HarryHaaren: But the other thread can ultimately make sure a single buffer with the result exists when done (assuming it fits in memory), perhaps using these techniques, so grabbing that pointer and using it right away should be doable | 01:13 |
drobilla | HarryHaaren: The win is it's truly RT safe and unlimited in size provided the ring is big enough and the other thread can keep up | 01:14 |
HarryHaaren | well the "right away" part there is difficult. at time of stop-record, the RT thread needs access to the start-data. In the same process() as the stop-record event took place. The other thread might have to move the data in order to squeeze this last bit of data to the end, so the whole lot could be moved -> bad pointer in RT section | 01:16 |
HarryHaaren | but if a short buffer of a few nframes lenghts or so was used to store the starting audio, the larger buffer could be swapped in later | 01:16 |
HarryHaaren | that's pretty neat. | 01:17 |
drobilla | as long as there is always as much free space at the end as can come in in a cycle, it's fine? | 01:17 |
drobilla | Actually, not quite. Let's just say "enough" free space :) | 01:17 |
drobilla | Something like ring size + block size | 01:18 |
HarryHaaren | yeah that | 01:18 |
HarryHaaren | becomes a bit fuzzy there though | 01:18 |
HarryHaaren | depending on nframes + thread scheduling really | 01:18 |
* HarryHaaren shudders | 01:19 | |
drobilla | Just nframes and ring size, I think | 01:19 |
drobilla | If you can't keep up you're fucked anyway | 01:19 |
HarryHaaren | keeping 1 second local in the RT section is a good solution though don't you think? | 01:19 |
drobilla | Yeah, though playback is a bit more difficult then | 01:19 |
HarryHaaren | drobilla, "short-term" can't keep up can be fixed by a larger ringbuffer, if there's 1 sec available | 01:19 |
HarryHaaren | why that? | 01:19 |
HarryHaaren | use "local buffer", when the event with large buffer arrives, swap it in. The playback code doesn't know the difference | 01:20 |
drobilla | Yep. Such is RT. There are limits, but they're just a number you can bump until there's enough space | 01:20 |
HarryHaaren | :) | 01:20 |
*** falktx has quit IRC | 01:36 | |
HarryHaaren | drobilla, PUGL native handle into LV2_Widget, embedded UI, any example code? You have the OpenGL in Ardour example on the blog post, no source-link though.. | 01:48 |
* HarryHaaren temps with a screeny... http://openavproductions.com/tmp/1_avtk_starting.png | 01:51 | |
*** ricardocrudo has quit IRC | 01:57 | |
drobilla | HarryHaaren: There's a "glamp" in my lad repo, if a bit rotten | 01:59 |
drobilla | HarryHaaren: But basically it's like any other UI | 01:59 |
HarryHaaren | i'll checkout glamp | 01:59 |
*** gianMOD has joined #lv2 | 02:18 | |
*** gianMOD has quit IRC | 02:23 | |
HarryHaaren | wheee http://openavproductions.com/tmp/2_lv2_embed.png | 02:28 |
HarryHaaren | might not be that much yet, but its working perfect. Lots of kudos for PUGL! | 02:28 |
drobilla | HarryHaaren: Nice. Partial redraw yet? | 02:30 |
HarryHaaren | nope. | 02:30 |
drobilla | HarryHaaren: I assume you're making a toolkit "AVTK"? | 02:31 |
* drobilla pays super close attention lately as you can see | 02:31 | |
HarryHaaren | yep I am, its API is pretty much based on NTK, with a few tweaks for even-easier-hacking | 02:31 |
HarryHaaren | (read, public member variables) | 02:31 |
drobilla | Bit foot shootey, that | 02:32 |
HarryHaaren | ah yeah. Its mostly under-the-hood for now, and i'll probably refactor when necessary | 02:33 |
HarryHaaren | drobilla, there's a few cases that should redraw but currently dont: alt-tab changing window order, or certain window movements don't cause a redraw | 02:33 |
drobilla | I also happen to be a fan of no-gaudy-bullshit flat rectangles, so I'll be sure to check it out at some point | 02:33 |
HarryHaaren | is this a known thing? Should I be doing redraws in client code, or do you think there's something we can do with X events? | 02:33 |
drobilla | HarryHaaren: Should be getting an expose in those cases | 02:34 |
drobilla | ... I think | 02:34 |
HarryHaaren | ok, i'll double check tomorrow or so and see if I can figure it out. | 02:34 |
HarryHaaren | otherwise, prepare for a confused me ;) | 02:34 |
drobilla | Anything beats marking these Prolog assignments... | 02:35 |
drobilla | Helping anyone with a properly functioning brain on anything anybody anywhere gives any hint of a crap about at all, big step up | 02:35 |
HarryHaaren | hahah i was asked if I knew Cobol in the Uni recently... quickly shrugged "nope" and walked away... static analysis of Cobol was the guys job :? | 02:36 |
drobilla | lol, COBOL | 02:38 |
drobilla | Basic for suits | 02:38 |
drobilla | (Rather silly question to ask anyone who isn't 50+ anyway) | 02:39 |
HarryHaaren | yeah the dude wasn't mad into it either.. anyways. I'm concidering applying to start a PHD in september.. how's your gut treating the PHD decision? | 02:39 |
drobilla | ................. you may not want to know, at the moment :) | 02:40 |
HarryHaaren | yeah kinda guessed... still though, if it aint all rainbows and unicorns maybe i should know that too | 02:41 |
drobilla | Well, it's December (end of term), I have to waste a ton of time marking this awful stuff (for money), I'm probably not going to reach my research goals with looming deadline since nothing is working out and I can't figure out why / don't have the time to, and of course that sucks away LAD time almost entirely. Plus other things in my life generally going to hell, though specific to my situation. | 02:48 |
drobilla | At other times, I would be more into the endeavour | 02:48 |
drobilla | But at the moment, life is a nightmare | 02:48 |
drobilla | So yes, it very definitely is not all rainbows and unicorns all the time :) | 02:48 |
HarryHaaren | fair enough, sorry to hear personal things ain't going well, hope things improve there. I definatly know what you're saying about the time thing though, i've to fight off "real-life" to some degree to keep enough time to be productive | 02:50 |
HarryHaaren | in a way the PHD is (hopefully) an extension of that fight for time, since I'm planning to do it on the topic of "OpenAV" in general... if I can make that work for the Uni is a different story | 02:51 |
HarryHaaren | we'll see. | 02:51 |
drobilla | Meh. The plus side of December is it ends in a holiday, I'll live | 02:51 |
HarryHaaren | for now, Avtk -> LV2 embedding is working fine, so that's nice. Tomorrow, more widgets, and perhaps Fabla 2.0 DSP code. | 02:51 |
drobilla | If you can combine the two, even if at some distance, that would be pretty great | 02:51 |
HarryHaaren | good stuff, that's always good. | 02:51 |
drobilla | It's ever so much worse when you spend essentially 4 years of well over full time doing nothing of any tangible relevance | 02:52 |
HarryHaaren | yeah the lecturer who supervised my Bachelor final project is interested in taking me on again, so he knows what i'm looking for.. and he's a software / media type guy himself too, even if he's not directly involved. Should work out I hope :) | 02:52 |
* HarryHaaren goes to bed, chat another time! | 02:53 | |
*** HarryHaaren has quit IRC | 02:54 | |
*** gianMOD has joined #lv2 | 03:16 | |
*** gianMOD has quit IRC | 03:20 | |
*** NickSB2 has quit IRC | 03:43 | |
*** gianMOD has joined #lv2 | 04:16 | |
*** gianMOD has quit IRC | 04:21 | |
*** gianMOD has joined #lv2 | 04:27 | |
*** gianMOD has quit IRC | 04:56 | |
*** gianMOD has joined #lv2 | 05:02 | |
*** gianMOD has quit IRC | 05:08 | |
*** gianMOD has joined #lv2 | 06:31 | |
*** gianMOD has quit IRC | 06:37 | |
*** zth has joined #lv2 | 06:58 | |
*** edogawa has joined #lv2 | 07:58 | |
*** edogawa_ has joined #lv2 | 08:05 | |
*** edogawa has quit IRC | 08:08 | |
*** edogawa_ is now known as edogawa | 08:28 | |
*** falktx has joined #lv2 | 09:19 | |
*** Anchakor_ has quit IRC | 10:59 | |
*** NickSB2 has joined #lv2 | 11:21 | |
*** edogawa has quit IRC | 11:31 | |
*** gianMOD has joined #lv2 | 12:13 | |
*** ricardocrudo has joined #lv2 | 12:19 | |
*** ricardocrudo has quit IRC | 12:19 | |
*** ricardocrudo has joined #lv2 | 12:20 | |
*** falktx has quit IRC | 13:35 | |
*** HarryHaaren has joined #lv2 | 14:45 | |
*** gabrbedd has quit IRC | 15:23 | |
*** gabrbedd has joined #lv2 | 15:24 | |
*** NickSB2 has quit IRC | 15:31 | |
*** Anchakor_ has joined #lv2 | 15:41 | |
*** HarryHaaren has quit IRC | 16:05 | |
*** rncbc has joined #lv2 | 16:30 | |
*** Haskellfant has quit IRC | 16:34 | |
*** Haskellfant has joined #lv2 | 16:48 | |
*** HarryHaaren has joined #lv2 | 16:48 | |
*** falktx has joined #lv2 | 17:29 | |
*** gianMOD_ has joined #lv2 | 18:00 | |
*** gianMOD has quit IRC | 18:03 | |
*** rncbc is now known as rncbc|AFK | 18:06 | |
*** rncbc|AFK has quit IRC | 18:08 | |
*** bgola has quit IRC | 18:21 | |
*** HarryHaaren has quit IRC | 18:27 | |
*** falktx has quit IRC | 18:41 | |
*** rncbc has joined #lv2 | 18:52 | |
*** Anchakor_ has quit IRC | 19:17 | |
*** Anchakor_ has joined #lv2 | 19:17 | |
*** rncbc has quit IRC | 19:21 | |
*** bgola has joined #lv2 | 19:22 | |
*** gianMOD_ has quit IRC | 19:37 | |
*** zth has quit IRC | 19:46 | |
*** mlpug has joined #lv2 | 19:47 | |
*** falktx has joined #lv2 | 19:49 | |
*** gianMOD has joined #lv2 | 20:38 | |
*** gianMOD has quit IRC | 20:43 | |
*** NickSB2 has joined #lv2 | 20:48 | |
*** mlpug has quit IRC | 20:53 | |
*** rncbc_jolla has joined #lv2 | 21:01 | |
*** rncbc_jolla has quit IRC | 21:15 | |
*** falktx has quit IRC | 21:32 | |
*** NickSB2 has quit IRC | 22:37 | |
*** gianMOD has joined #lv2 | 22:40 | |
*** edogawa has joined #lv2 | 22:43 | |
*** gianMOD has quit IRC | 22:45 | |
*** ColaEuphoria has joined #lv2 | 22:47 | |
ColaEuphoria | Scenario: You program a simple amplifier plugin that uses a floating point coefficient that multiplies into the input array. Everything works, but you hear a clicking noise when you move the port value in Ardour because it only sends information once every time the run() function gets called. | 22:49 |
ColaEuphoria | How would I do this with sample accuracy? | 22:49 |
drobilla | ColaEuphoria: There's two questions there. How can you have a control with sample accuracy, and how can you do it without zipper noise | 22:58 |
drobilla | Sample accuracy doesn't mean you won't get the noise | 22:58 |
ColaEuphoria | Well true | 22:59 |
drobilla | You do something like low-pass it, which adds a very small amount of latency to the control to slew it to avoid big jumps | 22:59 |
drobilla | Or linear interpolation, or (etc) | 22:59 |
ColaEuphoria | My first thought was to do some kind of interpolation between buffer refreshing, but is there a way to do it with sample accuracy? | 23:00 |
drobilla | Well, yes, but not one that's really supported by hosts yet | 23:00 |
drobilla | In general, event-based controls | 23:00 |
drobilla | There's also CV for things where that makes sense | 23:00 |
drobilla | There's been lots of talk about this and related things lately, probably/hopefully will be a serious standardization effort post-next-lv2-release | 23:01 |
drobilla | The other thing about interpolating/low-passing control ports is, without a fixed block size restriction, you can't really do it well | 23:04 |
ColaEuphoria | Just a thought that might not go anywhere: I've been wondering if there was a way for the host to collect input-changing data as an array and pass that into the plugin somehow on the next run() call | 23:04 |
drobilla | Well, sometimes. DSP nerdery is not my specialty, there's just some issues there | 23:05 |
ColaEuphoria | then the plugin has access to all the information in the for() loop that processes the audio block | 23:05 |
drobilla | ColaEuphoria: That's basically what "event-based control" means | 23:05 |
ColaEuphoria | oh | 23:05 |
drobilla | e.g. you can do with with MIDI CC currently, though the resolution of the value of course sucks | 23:05 |
ColaEuphoria | At least I finally found out what the zipper-noise was all about. How does VST circumvent zipper-noise if you know by any chance? | 23:07 |
drobilla | Up to the plugin to do so internally, same deal | 23:25 |
ColaEuphoria | Thanks. This whole time I just thought I was missing something in the documentation somewhere. | 23:28 |
drobilla | Nope. It's basically an inherent thing with audio processing | 23:28 |
drobilla | The only way you could really "avoid" it is to have the host do it, and pass CV buffers, but this is very expensive and has other problems | 23:29 |
drobilla | I'm sure you can find plenty of example code that does it, but I don't have any particularly good links handy | 23:29 |
*** edogawa has quit IRC | 23:36 | |
*** gianMOD has joined #lv2 | 23:42 | |
*** gianMOD has quit IRC | 23:47 | |
*** falktx has joined #lv2 | 23:50 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!