| rgareus | Socapex: when run returns, the plugin is done with processing the buffer.. | 00:07 |
|---|---|---|
| Socapex | rgareus: run is blocking? | 00:08 |
| rgareus | Socapex: no never. it must be realtime safe | 00:08 |
| rgareus | Socapex: it processes the given data and returns. | 00:08 |
| rgareus | it's intened to run in an audio-process callback | 00:08 |
| Socapex | rgareus: Uhm, how do I know it is done? You mean it will just continue the process after? | 00:08 |
| Socapex | ah ok | 00:09 |
| Socapex | So I can hook it up to my readFile callback to fill | 00:09 |
| Socapex | then I'm kinda clueless where to go from there. Expecting many plugins to be hooked through callbacks together etc | 00:09 |
| rgareus | well it is 'blocking' in the sense that it won't return until the data is processed.. | 00:10 |
| Socapex | yes thats actually perfect then | 00:10 |
| rgareus | Socapex: you call it periodically. read some data into buffer -> call run() ; repeat | 00:10 |
| Socapex | I'll just hook up either output or next plugin | 00:10 |
| rgareus | exactly | 00:11 |
| Socapex | so readfile (512) -> run(512) -> output or plugin2in | 00:11 |
| Socapex | all in its nice little isolated thread | 00:11 |
| Socapex | ^_^ | 00:11 |
| rgareus | yep | 00:11 |
| rgareus | BTW, input buffer can be the same as output buffer - most plugins can process in-place. | 00:11 |
| Socapex | oh thats great info! ty | 00:12 |
| rgareus | if they can't they must specify in-place-broken | 00:12 |
| rgareus | http://lv2plug.in/ns/lv2core/#inPlaceBroken | 00:12 |
| Socapex | hmmm, maybe I'll just make it general and have 2 buffers. Somehow it makes more "visual" sense that way for me | 00:12 |
| Socapex | All LV2 instances derive from a main plugin class which only has 2 buffers for now | 00:13 |
| Socapex | I'll probably make output a plugin, a bit like CoreAudio does I guess | 00:13 |
| rgareus | VST and AU deprecated non-inplace. all new plugins must support in-place. and most DAWs ignore plugins that can't do it. So it's just a few edge-case things that don't support it. | 00:14 |
| rgareus | but yes.. if the host provides different buffers.. all will work anyway. | 00:15 |
| rgareus | Socapex: if I may ask. what host are you working on? | 00:15 |
| rgareus | re suil - that's for custom plugin GUIs. | 00:16 |
| rgareus | eg a plugin GUI is written in Cocoa but your host is GTK or X11 and QT... suil provides bridges | 00:17 |
| Socapex | rgareus: I'm currently just working on a prototype to get accustomed to LV2. The plan is to integrate plugin suport in open broadcaster software (so not a DAW but live stuff). Though sometimes my wishes are not aligned with theirs, I'm pretty sure the guy wont be able to resist a plugin/mixer pull request :D | 00:17 |
| Socapex | rgareus: So I'm working in Qt right now, I want suil then. Downloading it right now | 00:18 |
| rgareus | Socapex: the bad news... the QT stuff there is a bit half-baked.. most of us don't use QT :( | 00:18 |
| rgareus | falktx promised some QT updates to suil. but that has not yet happened | 00:18 |
| Socapex | Well, if I run Qt, then I only have to provide other contexes, not the Qt one since I'm shipping with it? Or am I misunderstanding? | 00:19 |
| rgareus | yes | 00:19 |
| rgareus | qt in qt is a noop | 00:19 |
| Socapex | :) | 00:20 |
| falktx | rgareus: I gave up, can't make qt5+suil in a way that I'll be happy | 00:20 |
| Socapex | So then I;m covered, but making the plugins qith Qt5 would be a no-no :/ | 00:20 |
| rgareus | there are very few lv2 plugins with a QT gui though. I know know rui's vee-one suite | 00:20 |
| rgareus | s/know know/only know/ | 00:20 |
| Socapex | I plan on making some (the basics you would need for voice). We want to ship cross-plateform with out-of-the-box plugins | 00:21 |
| rgareus | Socapex: gtk2 + gtk3 has the same issue | 00:21 |
| rgareus | Socapex: the trend is to go to a lower level, openGL + native window system. | 00:21 |
| rgareus | the big toolkits don't provide much for most plugin UIs anyway. | 00:22 |
| Socapex | rgareus: yes, I actually have a friend that made his own visual library with openGL just for VSTs. I'll probably revert to that then | 00:22 |
| Socapex | And its neat since everything runs on GPU, which is perfect for audio processing | 00:22 |
| Socapex | By that I mean, it frees up CPU. Qt is a CPU hog | 00:23 |
| rgareus | ie eventually you only need "X11 in Qt", "Cocoa (well really quartz) in QT" and "Win in Qt" | 00:23 |
| rgareus | with X11 maybe becoming wayland or sth - though the underlying context to a openGL view + events is not unsimilar | 00:24 |
| Socapex | So how do I go about trying to display the UI? | 00:24 |
| Socapex | I'm reading up lilv doc right now, but nothing pops up | 00:24 |
| rgareus | suil_instance_new | 00:25 |
| rgareus | the long story e.g. https://github.com/Ardour/ardour/blob/master/gtk2_ardour/lv2_plugin_ui.cc | 00:25 |
| Socapex | lol I'll read that :) Thank you very much | 00:25 |
| rgareus | thouhg better just read the jalv source | 00:25 |
| rgareus | except I can't find a direct link to it.. it is still somewhere hiding in SVN | 00:26 |
| Socapex | Yes I do have those. I'm going to take a look | 00:26 |
| Socapex | They hae been very helpfull | 00:26 |
| rgareus | http://svn.drobilla.net/lad/trunk/jalv/src/jalv_qt4.cpp | 00:26 |
| rgareus | nice and short jalv_open_ui there | 00:26 |
| rgareus | though the heavy lifiting is done by jalv_ui_instantiate | 00:27 |
| Socapex | allright, sounds like a good place to start at least :) | 00:30 |
| rgareus | jalv is really nice - a good reference implementation | 00:30 |
| rgareus | drobilla: is jalv going to be included in the libs+tools that will eventually migrate to lv2plug.in ? | 00:32 |
| Socapex | I hope to release my prototype as an extra reference for ppl. I'll let you know when it's working so you can point out some wrong code etc | 00:32 |
| drobilla | rgareus: Probably. That and a take on lv2file to serve as simpler example | 00:44 |
| drobilla | I fear actually doing this, but svn sure is getting annoying | 00:47 |
| Socapex | Wow suil is hardcore :O | 01:11 |
| rgareus | how so? | 01:11 |
| rgareus | do you mean using suil? or writing libsuil wrappers itself? | 01:12 |
| Socapex | using it... This is some crazy stuff. Not that I don't like a challenge and learning new stuff. But everything that has to do with pure C does make me uneasy | 01:13 |
| Socapex | and the whole turtle stuff, and protocoles and and and :) | 01:13 |
| * rgareus just feels the other way 'round. | 01:13 | |
| rgareus | give me pure C every day | 01:14 |
| Socapex | hehe, I know I'm the oddball around here | 01:14 |
| rgareus | well using it in C++ should be really straight forward. | 01:14 |
| Socapex | So, uhm, atom events are an extension? And how does this whole protocole communication work? For example, I have to setup some methods for writing to ports, or reading etc... but to what end? | 01:15 |
| drobilla | ? Basically none of these mentioned things are related to suil | 01:15 |
| Socapex | Wow I'm a bit overwhelmed by all this UI stuff. | 01:15 |
| rgareus | plugin <> GUI communication. | 01:16 |
| rgareus | plugin calls write functions -> host writes it into a ringbuffer. <- all realtime safe | 01:17 |
| drobilla | Well, sure, "related" some extremely vague sense... | 01:17 |
| drobilla | Socapex: "protocol" is just the word we used for "way to send thing to port" | 01:17 |
| rgareus | ...later GUI thread comes around -> reads from ringbuffer and tells the UI about it | 01:17 |
| drobilla | There's basically only two: the control port one (set a float), and the event/sequence one (send an event) | 01:17 |
| drobilla | Unless you are writing a network transparent host, you don't have to care about the actual content of the events at all. Just memcpy them. | 01:18 |
| drobilla | (via a ring as rgareus says) | 01:18 |
| Socapex | rgareus: So I just need to store it in a ring buffer and provide it to suil later? Sounds reasonable | 01:18 |
| rgareus | Socapex: yep. the same is also true for MIDI. in case you worry about that. that's also an "Event sequence" | 01:19 |
| Socapex | rgareus: And the atom stuff is a protocol I would imagine? I'll look into that later I guess. I'll stick to just getting control port things working for now :) | 01:21 |
| drobilla | In the general sense, yes, in the UI extension sense, no. | 01:21 |
| drobilla | Events of any type are done the same way. | 01:22 |
| drobilla | i.e. (again assuming a monolithic non-network host) if MIDI works, whatever else (including atoms) will, too. | 01:22 |
| Socapex | ok | 01:23 |
| rgareus | Socapex: yes. disregard atoms at first. | 01:23 |
| Socapex | I shall happily do so | 01:23 |
| rgareus | drobilla: BTW, I've completed latency-compensation for my little LV2 host, but only audio so far. Input ports are delayed to sync them according to the jack capture port latency. | 01:25 |
| rgareus | drobilla: I'd love to port this to jalv. but I already hear you saying that the delayline code is too large. | 01:25 |
| drobilla | rgareus: Can you blame me? :) | 01:27 |
| drobilla | rgareus: What's large? | 01:27 |
| rgareus | drobilla: no, not really | 01:27 |
| drobilla | I don't know, with a simpler example the need for Jalv to stay "simple" will be lessened somewhat | 01:27 |
| rgareus | audio only is about 80 lines + headers | 01:28 |
| drobilla | If it can be somewhat reasonably isolated into its own .c that's easy to ignore if you don't care, it's considerably better | 01:28 |
| drobilla | (I should probably do this with Jack itself) | 01:28 |
| rgareus | just for the dealayline. then maybe 50 or so to calculate things and interact with jack | 01:28 |
| rgareus | jack is just a mechanism. | 01:28 |
| rgareus | it should never delay audio | 01:28 |
| drobilla | I meant isolate the code related to Jack itself, instead of jalv.c. Nevermind. | 01:29 |
| rgareus | aah right | 01:29 |
| rgareus | yes that makes sense for jalv. | 01:29 |
| rgareus | would allow to also add a coreaudio in/out or whatever. | 01:29 |
| rgareus | drobilla: btw what does the "li" in lilv stand for? | 01:30 |
| drobilla | rgareus: Well, go for it, I guess. | 01:30 |
| drobilla | rgareus: Seems like some pretty fancy shit for what's a pretty simple host at the end of the day, but I guess it should be as good a host as possible and Jack forces hosts to deal with this | 01:31 |
| drobilla | For what I'm sure are valid reasons but I don't like it just the same :) | 01:31 |
| drobilla | rgareus: LIghtweight LV2 | 01:31 |
| rgareus | lost in lv2 | 01:33 |
| drobilla | I think suil (Simple UI Library) is the only one that's actually an acronym and not a sort of fuzzy portmenteau designed to be pronounceable | 01:34 |
| Socapex | hmm, so the data port structure seems not that bad now that I am over with my little heart-attack. Basically you guys have a ControlChange info thing + data after. | 01:34 |
| drobilla | I did find the "yalv" pronunciation many euros gravitate to most entertaining :) | 01:35 |
| drobilla | Socapex: Well, the problem in general is "I have a change in the UI thread I need applied in the audio thread". A ring with a header to say what the change applies to followed by the data is the obvious solution. | 01:38 |
| drobilla | I can't even think of another one, actually. | 01:38 |
| Socapex | It seems really reasonable and elegant to me. | 01:39 |
| drobilla | or some kind of queue, anyway. Ring is just handy because it's inherently thread-safe and you don't have to deal with deletion (at the cost of a bounded limit on how much stuff you can cram in there) | 01:40 |
| * drobilla => laptop | 01:41 | |
| Socapex | ring buffer is also nice cause if you ever did any type of audio stuff, your users are going to know about it | 01:42 |
| drobilla | Well, yep. This is why forcing the comm to go through the host is a good idea. | 01:47 |
| drobilla | Plenty of plugin authors clearly don't know their ass from their elbow when it comes to RT/multi-threaded anything, but anyone capable of writing a halfway decent host is going to grok ringbuffering stuff | 01:48 |
| *** NickSB has quit IRC | 01:50 | |
| Socapex | well see about that ;) Right now I'm thinking where I want to do all the suil instantiation. Since I will have multiple plugins running at the same time, it is tempting to make it a per object thing. | 01:50 |
| rgareus | drobilla: it's funny that people here are prefactly capable of pronouncing Jack like "check" but fail with jalv. | 01:50 |
| *** NickSB has joined #lv2 | 01:53 | |
| Socapex | drobilla: Do you mind if I copy paste some stuff from jalv? | 01:56 |
| rgareus | Socapex: it's very liberally licensed for exactly that purpose. | 01:56 |
| Socapex | rgareus: :) There are a few things in there that just seem stupid to do differenty | 01:57 |
| Socapex | ty though | 01:57 |
| rgareus | Permission to use, copy, modify, and/or distribute this software for any purpose.... see the header | 01:57 |
| Socapex | yes, but I meant, like does he doesn't like it etc. | 01:59 |
| Socapex | I dunno, just felt like I had to ask. I dont like copy pasting stuff | 01:59 |
| rgareus | well, I'll let him answer it | 01:59 |
| rgareus | Socapex: yeah it's nice to ask, indeed | 01:59 |
| *** falktx has quit IRC | 02:15 | |
| drobilla | Socapex: Feel free. As rgarus says, license is that way for precisely that reason | 02:34 |
| drobilla | Socapex: Thanks for asking | 02:34 |
| drobilla | Socapex: For trivial bits of a few lines here and there don't worry about copyright. For considerable chunks, license applies. | 02:36 |
| Socapex | drobilla: No problem. If I ever get my thing in a release state its public domain | 03:42 |
| drobilla | Public domain can be problematic or even impossible depending on country. Check out "unlicense" if you're into that sort of thing | 04:13 |
| * rgareus recommends http://www.wtfpl.net/ | 04:17 | |
| Socapex | I just thought that dwtfyw license wasnt very pro for a "tutorial" like project | 05:01 |
| *** drobilla has quit IRC | 07:14 | |
| *** Socapex has quit IRC | 08:08 | |
| *** ricardocrudo has joined #lv2 | 09:59 | |
| *** falktx has joined #lv2 | 11:27 | |
| *** drobilla has joined #lv2 | 11:56 | |
| *** ricardocrudo has quit IRC | 12:23 | |
| *** ricardocrudo has joined #lv2 | 12:50 | |
| *** gianMOD has joined #lv2 | 13:29 | |
| *** NickSB2 has quit IRC | 14:40 | |
| *** gianMOD has quit IRC | 14:45 | |
| *** gianMOD has joined #lv2 | 14:47 | |
| *** gianMOD has quit IRC | 15:24 | |
| *** edogawa_ has joined #lv2 | 15:27 | |
| *** edogawa has quit IRC | 15:31 | |
| *** gianMOD has joined #lv2 | 15:43 | |
| *** edogawa_ is now known as edogawa | 15:44 | |
| *** falktx has quit IRC | 16:57 | |
| *** rncbc has joined #lv2 | 17:27 | |
| *** falktx has joined #lv2 | 17:28 | |
| *** gianMOD has quit IRC | 17:33 | |
| *** ricardocrudo has quit IRC | 17:43 | |
| *** aombk2 has joined #lv2 | 18:00 | |
| *** aombk has quit IRC | 18:03 | |
| *** rncbc has quit IRC | 18:12 | |
| *** rncbc has joined #lv2 | 18:39 | |
| *** gianMOD has joined #lv2 | 18:41 | |
| *** gianMOD has quit IRC | 18:49 | |
| *** NickSB2 has joined #lv2 | 18:53 | |
| *** rncbc has quit IRC | 19:23 | |
| *** ssj71 has joined #lv2 | 19:50 | |
| ssj71 | does anyone have an example of the options extension in a plugin's instantiate? | 19:51 |
| ssj71 | ok, maybe I'm getting it | 19:54 |
| badosu | ssj71: I always return NULL. but there are some | 19:58 |
| ssj71 | badosu: I actually need one of the options | 19:59 |
| ssj71 | but I think I've got it. We'll see once it compiles though | 20:00 |
| ssj71 | can anyone teach me the difference between using urid:map vs just strcmp? | 20:01 |
| badosu | ssj71: drobilla would be your man, but I guess he's busy/away | 20:05 |
| drobilla | You need me to teach you the difference between strings and integers? ;) | 20:06 |
| ssj71 | apparently :) | 20:25 |
| ssj71 | ok I'll go RTFM some more | 20:26 |
| drobilla | If you're asking why we map them at all, two reasons: performance and memory management | 20:33 |
| drobilla | If events were typed by strings, then you'd be doing a strcmp of a lengthy string ever single e.g. MIDI event, which is way too slow | 20:33 |
| drobilla | and someone has to be responsible for freeing that string | 20:33 |
| *** ssj71 has quit IRC | 20:44 | |
| *** ssj71 has joined #lv2 | 20:45 | |
| *** ssj71 has quit IRC | 20:48 | |
| *** ssj71 has joined #lv2 | 20:48 | |
| *** gianMOD has joined #lv2 | 20:52 | |
| *** ssj71 has quit IRC | 21:06 | |
| *** ssj71 has joined #lv2 | 21:07 | |
| *** ssj71 has joined #lv2 | 21:08 | |
| *** ricardocrudo has joined #lv2 | 21:25 | |
| *** gianMOD has quit IRC | 21:30 | |
| *** gianMOD has joined #lv2 | 21:31 | |
| *** gianMOD has quit IRC | 21:45 | |
| *** gianMOD has joined #lv2 | 21:58 | |
| badosu | drobilla: just submitted a proposal for this year's FISL on introducing LV2, hope gets accepted | 22:04 |
| *** gianMOD has quit IRC | 22:15 | |
| *** gianMOD has joined #lv2 | 22:17 | |
| *** falktx has quit IRC | 22:19 | |
| *** ssj71 has quit IRC | 22:22 | |
| *** gianMOD has quit IRC | 22:31 | |
| *** ricardocrudo has quit IRC | 23:44 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!