| *** ColaEuphoria has quit IRC | 00:43 | |
| rgareus | drobilla: any reason to build it into jalv directly? | 00:53 |
|---|---|---|
| rgareus | drobilla: I think avlinux has a one based on `lv2ls` and `dialog` | 00:53 |
| HarryHaaren | heh, i was dealing with GTK tree model in C for my work-exp for Ubuntu's sound-selection dialog. Ouch. | 01:00 |
| HarryHaaren | +1 for a quick selector in Jalv | 01:00 |
| drobilla | rgareus: Depends how you look at it, I suppose. Then it would be an app you can just run | 01:32 |
| drobilla | Which is a thought at the moment seeded by the fact that it's basically impossible to make a Mac app out of it, but it's clearly something users are pining for | 01:33 |
| *** HarryHaaren has quit IRC | 01:35 | |
| rgareus | drobilla: on OSX for the standalone x42-plgins[.lv2] I use a simple Apple-script select launcher - much like *dialog on Linux. | 01:40 |
| *** NickSB2 has joined #lv2 | 03:07 | |
| *** damo22 has joined #lv2 | 06:28 | |
| damo22 | is it possible to have a dynamic number of output audio ports? | 06:28 |
| damo22 | or inputs | 06:28 |
| rgareus | drobilla: no. ports are fixed | 07:56 |
| rgareus | damo22: ^^ | 07:56 |
| damo22 | ok | 07:56 |
| rgareus | damo22: there was a hack sometime ago (dyn manifest or something).. not sure what's up with that these days | 07:56 |
| rgareus | damo22: the common practice is to simply add variants (mono, stereo, etc) - same plugin code, different URI & ttl | 07:57 |
| damo22 | rgareus: i was thinking of writing a drum machine plugin that syncs with the transport somehow and sends/receives tempo | 07:58 |
| rgareus | damo22: receiving tempo is relatively straight forward | 07:59 |
| rgareus | damo22: but I don't know a host that can receive tempo | 07:59 |
| damo22 | ok | 07:59 |
| damo22 | not so important i guess | 07:59 |
| rgareus | to clarify ^^ plugin receiving tempo from host = OK | 08:00 |
| rgareus | as mentioned on #ardour just now http://lv2plug.in/book/#_metronome | 08:00 |
| damo22 | yes | 08:00 |
| damo22 | gotcha | 08:00 |
| rgareus | sending a lv2#time message from plugin to host is certainly valid. and a host could parse and use it.. | 08:03 |
| damo22 | i think openav Fabla is already doing what i had in mind | 08:03 |
| rgareus | but ardour for example would not know what to do with it - or even worse what if different plugins send different info. | 08:04 |
| rgareus | a standalone host could e.g act as jack timebase master, delegating things to a plugin. or .. well whatever. :) | 08:05 |
| rgareus | yeah Harry's got big plans for Fabla2 | 08:06 |
| damo22 | :) | 08:06 |
| *** edogawa has joined #lv2 | 08:19 | |
| *** zth has joined #lv2 | 08:42 | |
| *** falktx has joined #lv2 | 08:42 | |
| *** zth_studiocomp has joined #lv2 | 08:43 | |
| *** edogawa_ has joined #lv2 | 10:48 | |
| *** edogawa has quit IRC | 10:51 | |
| *** mlpug has joined #lv2 | 11:06 | |
| *** falktx has quit IRC | 11:28 | |
| *** wumpus has quit IRC | 12:09 | |
| *** wumpus has joined #lv2 | 12:14 | |
| *** HarryHaaren has joined #lv2 | 12:15 | |
| *** mlpug has quit IRC | 13:17 | |
| *** mlpug has joined #lv2 | 13:32 | |
| *** grejppi_ has joined #lv2 | 15:01 | |
| *** grejppi has quit IRC | 15:03 | |
| *** mlpug has quit IRC | 15:31 | |
| *** grejppi_ is now known as grejppi | 15:43 | |
| *** mlpug has joined #lv2 | 15:46 | |
| *** mlpug has quit IRC | 16:08 | |
| drobilla | Sending the transport is trivial, but there's no properties or negotiation mechanism for the host to do anything with it. It seems unlikely anything but a modular would be able to do anything useful with it anyway | 16:09 |
| drobilla | Might not even need anything new spec-wise, e.g. hosts could have a "Use as time master" option in a context menu or whatever if the plugin emits time stuff if they want to | 16:09 |
| *** mlpug has joined #lv2 | 16:37 | |
| *** mlpug has quit IRC | 17:03 | |
| *** mlpug has joined #lv2 | 17:08 | |
| drobilla | I guess I could include a zenity based selector on Linux, too, just have to check it's actually around... | 17:41 |
| drobilla | I have been thinking about a portable "system file dialog and menus" C library lately | 17:41 |
| drobilla | Makes me think that it would be nice if zenity or one of the other dialog tools provided the same stuff via a C API as well | 17:42 |
| HarryHaaren | drob: you're aware of Rgar's X11 file selection thingy right? | 17:44 |
| drobilla | HarryHaaren: nope. | 17:45 |
| HarryHaaren | also I'm using TinyDir (a single header x-platform directory / file reader) | 17:45 |
| drobilla | Though I actively would rather use the system one rather than some weird thing anyway | 17:45 |
| HarryHaaren | drobilla, https://github.com/x42/sofd | 17:45 |
| drobilla | On that, I have been taking stock (i.e. with gnome-shell) Gnome 3 for a spin lately | 17:45 |
| drobilla | It's getting better, but man, what the fuck kind of crack they are smoking with menus I don't know | 17:45 |
| HarryHaaren | its currently x11 only i think, but falktx was talking about making it x-plat in #Lad one day | 17:45 |
| drobilla | Apps don't really have menus anymore, except a single special application menu that basically nothing supports | 17:46 |
| HarryHaaren | hehe "interoperability" at its best | 17:46 |
| drobilla | I hate this trend, death of discoverable keyboard nav | 17:46 |
| drobilla | But the single weird menu thing is just so... weird. If you're going to rip off OSX, just do it. | 17:46 |
| drobilla | Not force everyone in the world to switch to your fucked up model that is unlike everything else ever | 17:46 |
| HarryHaaren | AVTK is including file-browser / dialog stuff. Currently Linux only, but since its tinydir / PUGL / Cairo based, it should work everywhere after testing | 17:47 |
| drobilla | (Then probably realize that model sucks anyway and change it in a year) | 17:47 |
| HarryHaaren | a terminal. that's all that there is to trust :) | 17:47 |
| drobilla | HarryHaaren: I guess I can check it out, but the file dialog (and possible context/system menu stuff) struck me as a relatively simple thing to stick a portable wrapper around | 17:47 |
| HarryHaaren | cool. I know you're a fan of writing minimal x-plat libraries, and I like using them, so feel free ;) | 17:48 |
| *** falktx has joined #lv2 | 17:48 | |
| drobilla | HarryHaaren: I figured that's the one thing that's immensely complicated to get right and would irritate the user for being weird anyway, so is a good thing to wrap in an otherwuse pure pugl app | 17:48 |
| drobilla | You can cheat with context menus to get pseudo-combo-boxes | 17:49 |
| drobilla | Tree/list views and some other fancy advanced widget things you just need to deal with, but can generally avoid anyway | 17:49 |
| HarryHaaren | agreed | 17:50 |
| drobilla | (sofd looks pretty good though) | 17:50 |
| drobilla | I half wish "we" would all band together and cram all these various efforts into one thing | 17:51 |
| drobilla | But then we've invented a toolkit | 17:51 |
| drobilla | YATK | 17:51 |
| drobilla | (well, C/C++ chasm is trouble) | 17:51 |
| * drobilla has too many existing and hypothetical small projects in which copy pasting an entire bloody toolkit would suck immensely | 17:52 | |
| drobilla | A pure pugl jalv would sure be nice, though. | 17:52 |
| HarryHaaren | +1 for that.. is there much of a GTK dep? I mean, jalv (not .gtk etc) doesn't depend on GTK does it? | 17:53 |
| drobilla | The core doesn't at all, there are several UIs | 17:53 |
| HarryHaaren | its about writing a new frontend, that can deal with XEmbed.. | 17:53 |
| HarryHaaren | yeah sure | 17:53 |
| drobilla | The only usable UI is totally Gtk | 17:54 |
| HarryHaaren | yep. | 17:54 |
| drobilla | Re: zenity, to make a proper plugin selector I need the names. Maybe I need to make an lv2query | 17:54 |
| HarryHaaren | With ShowInterface and IdleInterface we could potentially let plugin UI's "just" handle thier own window, removing the need for XEmbed "hosting" support? | 17:54 |
| HarryHaaren | some grep / sed / awk magic would work too, although a bit hacky | 17:55 |
| drobilla | lv2query doap:name => <http://foo/> "Foo" <newline> <http://...> ... | 17:55 |
| drobilla | HarryHaaren: ? | 17:55 |
| drobilla | HarryHaaren: Sure, if you don't want to embed, well, you can not embed | 17:55 |
| drobilla | Trouble being most do want to embed :) | 17:55 |
| HarryHaaren | in Jalv? | 17:55 |
| HarryHaaren | i persontally don't care if the plugin embeds in Jalv or runs in its own window | 17:56 |
| drobilla | Oh, you mean embedding UIs in a Pugl app | 17:56 |
| HarryHaaren | yeah | 17:56 |
| drobilla | Yeah, Suil needs a thing there | 17:56 |
| HarryHaaren | anyway, i think we're on a tangent to a tangent now :) | 17:56 |
| * HarryHaaren back to compiling some code | 17:57 | |
| drobilla | Though....... native window in a pugl view..... er... | 17:57 |
| * drobilla has no idea how to do that | 17:57 | |
| *** NickSB has quit IRC | 19:05 | |
| *** NickSB has joined #lv2 | 19:06 | |
| *** HarryHaaren has quit IRC | 20:20 | |
| *** ricardocrudo has joined #lv2 | 20:22 | |
| *** HarryHaaren has joined #lv2 | 20:34 | |
| drobilla | Re: presets, maybe instead of adding API for that specifically, an ability for UIs to ask the host to pop up a menu for <something> is better? | 21:12 |
| drobilla | Then, at least for presets, it can build in save and other fancier things the plugin itself can't really do (without yet more API specifically for that, and on and on it goes...) | 21:12 |
| drobilla | are there other uses for such a thing? reset values to defaults? | 21:13 |
| drobilla | Perhaps just a show_menu_for(subject) | 21:14 |
| drobilla | Where subject may be the plugin, or a port (or something I haven't thought of just now) | 21:14 |
| drobilla | With some mandates about what must be in there, e.g. presets for the plugin | 21:14 |
| *** mlpug has quit IRC | 21:16 | |
| HarryHaaren | drobilla, if that's @me, I think the whole point of presets in the plugin UI is for UX. | 21:20 |
| HarryHaaren | users *expect* presets in the UI of the plugin itself. It just makes sense. | 21:20 |
| HarryHaaren | it also allows the plugin to be smart about catagorizing / browsing the presets | 21:20 |
| drobilla | For all intents and purposes the menu *would* be in the UI. | 21:20 |
| drobilla | Plugin being "smart" about that is almost impossible unless you assume baked-in presets only which is 90% pointless | 21:21 |
| drobilla | (we need preset categorization in general) | 21:21 |
| HarryHaaren | no, the host needs to communicate the available presets to the plugin UI | 21:21 |
| drobilla | why? | 21:21 |
| HarryHaaren | yes better preset categorization is good anyway, +1 for that | 21:21 |
| HarryHaaren | so the plugin UI can show them. Its where a user looks for presets : in the UI of the plugin itself. | 21:22 |
| * drobilla points at the thing he *just* said. | 21:22 | |
| drobilla | The button would be in the UI. That's the whole point. | 21:22 |
| HarryHaaren | this is my goal: http://2.bp.blogspot.com/-oOHqFUIs-O0/U6RtWiAFjHI/AAAAAAAAACc/0VdEfGqIobw/s1600/nexus2_skin10.jpg | 21:23 |
| drobilla | Well, yes, you wouldn't be able to do things like that. | 21:23 |
| HarryHaaren | to allow users to browse presets *inside* the plugin UI | 21:23 |
| drobilla | Forgive me if I don't care all that much. | 21:23 |
| drobilla | Boo hoo you can't piss away a vast amount of UI real-estate on something basically useless once it's set :P | 21:24 |
| HarryHaaren | you're suggesting a "preset" button in the UI, which signals the host to present a preset selector? | 21:24 |
| HarryHaaren | also, that's not true. UX needs work in audio-software, and I have a lot of ideas. | 21:24 |
| drobilla | Yes. Among other things. | 21:24 |
| drobilla | Like automation options. | 21:24 |
| HarryHaaren | changing presets *should* become a much easier task, and partial-loading of presets also become easy | 21:24 |
| HarryHaaren | automation is something I've been meaning to discuss with las rgarus and you, because indeed it needs to become more transparent to the user | 21:25 |
| drobilla | Well, yes, but it should be better in the hosts anyway. | 21:26 |
| HarryHaaren | "learn moved knob automation" is something that needs to be addressed | 21:26 |
| drobilla | Multiple redundant ones, like you'd get in Ardour, looks like shit | 21:26 |
| HarryHaaren | presenting automation targets in a list is horrid for UX | 21:26 |
| HarryHaaren | sure, we're saying the same thing :) | 21:26 |
| drobilla | Architecturally I like this because it's simple and can do a shitload of things | 21:26 |
| drobilla | Whereas a fuckton of preset API is neither | 21:27 |
| HarryHaaren | ^^ "this" <- i don't know quite exactly what you're reffering to | 21:27 |
| drobilla | "this" = API for UI to request host to pop-up a menu for <whatever> <here> | 21:27 |
| drobilla | I'd say whatever, nevermind, not a particularly high priority, but due to the lack of any LV2 issues tracking I have no idea WTF needs doing or what their priorities are in the first place | 21:28 |
| drobilla | Other than what I can vaguely remember somebody mentioning at some arbitrary point in the past, which isn't much. | 21:29 |
| HarryHaaren | sure. If you can think of a way to transfer "whatever" as an Atom into the plugin (if requested) then that would suffice for the preset-list-in-UI | 21:29 |
| HarryHaaren | "plugin UI" i mean | 21:29 |
| drobilla | That's different. | 21:30 |
| HarryHaaren | true - but not totally a different ball game: host scrapes data from LILV, presents it, or host scrapes data from LILV, writes it to atom port | 21:30 |
| drobilla | The menu thing is simple because there is no such shuttling of a ton of data to the UI. Just show menu. | 21:31 |
| drobilla | Host does the rest. Which it can already do. | 21:31 |
| drobilla | Yes, I am aware this doesn't get your selector thing | 21:32 |
| drobilla | My position as guy who actually has to do this shit lends towards pragmatism ;) | 21:32 |
| HarryHaaren | sure, i understand that completly :) | 21:32 |
| drobilla | Though we need categories before it's particularly useful anyway | 21:32 |
| HarryHaaren | yep, i'll shup now and let you do your thing | 21:33 |
| drobilla | How to do that I'm not sure, they're not pre-defined like plugin categories | 21:33 |
| drobilla | But label as ID is a no-go (i18n), so it can't be *that* dumb/simple | 21:33 |
| drobilla | Anyway. I really need that issue tracking thing, but nobody used trac... | 21:34 |
| drobilla | I guess I could hold my nose for now and just use the github one | 21:35 |
| drobilla | If anyone would actually use that | 21:35 |
| drobilla | (Which everyone will say they will, of course, but I'm old enough to take that with a boulder of salt) | 21:35 |
| drobilla | I guess I'll just keep hammering on the documentation for now and clean up what we have | 21:45 |
| drobilla | Maybe see if I can gracefully merge extensions without breaking anything, because it's a real mess right now | 21:45 |
| *** ricardocrudo has quit IRC | 22:08 | |
| *** edogawa_ has quit IRC | 22:34 | |
| *** zth has quit IRC | 22:49 | |
| *** HarryHaaren has quit IRC | 23:06 | |
| *** hybrid has joined #lv2 | 23:09 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!
