| *** NickSB2 has quit IRC | 03:30 | |
| *** edogawa has joined #lv2 | 07:23 | |
| *** unclechu has joined #lv2 | 08:38 | |
| *** unclechu has quit IRC | 08:38 | |
| *** unclechu has joined #lv2 | 08:38 | |
| *** NickSB2 has joined #lv2 | 11:12 | |
| *** ricardocrudo has joined #lv2 | 11:28 | |
| *** falktx has joined #lv2 | 11:56 | |
| *** falktx has quit IRC | 13:05 | |
| *** falktx has joined #lv2 | 13:19 | |
| *** ricardocrudo has quit IRC | 14:36 | |
| *** falktx has quit IRC | 14:41 | |
| *** ricardocrudo has joined #lv2 | 14:58 | |
| *** edogawa_ has joined #lv2 | 15:36 | |
| *** edogawa has quit IRC | 15:38 | |
| *** falktx has joined #lv2 | 15:48 | |
| *** unclechu has quit IRC | 16:09 | |
| *** HarryHaaren has joined #lv2 | 16:19 | |
| HarryHaaren | drobilla, ping for a 5 min discussion about the AuxBus extension I'm working on for Fabla? | 16:20 |
|---|---|---|
| *** unclechu has joined #lv2 | 16:24 | |
| falktx | HarryHaaren: can I get a preview when it's working in fabla? (on the extension) | 16:24 |
| falktx | *of the | 16:25 |
| HarryHaaren | falktx, nowhere near that yet. If its done before the LAC i'll be lucky. | 16:25 |
| HarryHaaren | also, I feel its important that the community actually *want* this | 16:25 |
| HarryHaaren | as we know, extensions that aren't generally accepted aren't any good | 16:25 |
| HarryHaaren | I think from a musicians POV this is very important for workflow. | 16:25 |
| falktx | I know male wanted something like this | 16:25 |
| HarryHaaren | did he? I wasn't aware.. hm. Did he mention on IRC or when? | 16:26 |
| falktx | well, on the "daz" thing ;) he insisted to have a way to handle aux ports | 16:26 |
| HarryHaaren | ah ok, yeah | 16:27 |
| falktx | HarryHaaren: will this be used to handle sidechain ports? | 16:27 |
| HarryHaaren | not directly, but yes, it does improve the workflow of side-chaining | 16:27 |
| falktx | well, when there's a draft online I'd love to see it | 16:28 |
| HarryHaaren | falktx, tea-time here, I'll be back in 20 or so. I'll prepare some graphics for the use-cases that I'm targetting, and then hopefully we can have a discussion with you Drob Rgar Las and perhaps some others | 16:28 |
| * HarryHaaren out for tea :) | 16:28 | |
| *** zth has joined #lv2 | 16:36 | |
| *** zth has quit IRC | 16:42 | |
| *** zth has joined #lv2 | 16:43 | |
| *** edogawa_ is now known as edogawa | 16:50 | |
| *** zth has quit IRC | 16:51 | |
| *** unclechu has quit IRC | 16:53 | |
| *** zth has joined #lv2 | 17:11 | |
| drobilla | HarryHaaren: I thought we determined an extension wasn't really necessary. What's it do? | 17:57 |
| drobilla | (Today on: why disussing such things on the mailing list is better) | 17:58 |
| drobilla | Gotta to to work, bbl | 17:58 |
| HarryHaaren | drobilla, expect a mailing list post | 17:58 |
| HarryHaaren | cheers | 17:58 |
| bgola | drobilla: i finally got pset:preset working :) whats the best way to send you a patch? | 18:00 |
| *** mlpug has joined #lv2 | 19:11 | |
| *** mlpug has quit IRC | 20:18 | |
| *** zth has quit IRC | 20:53 | |
| *** ricardocrudo has quit IRC | 22:13 | |
| *** HarryHaaren has quit IRC | 22:14 | |
| *** HarryHaaren has joined #lv2 | 22:15 | |
| *** edogawa has quit IRC | 23:00 | |
| drobilla | bgola: nice. email | 23:02 |
| HarryHaaren | drobilla, i've chatted to las rgareus falktx and wrl a bit about this AuxBus, that I pinged you about earlier. http://openavproductions.com/tmp/fabla2auxbus.png | 23:07 |
| HarryHaaren | if you have some time now I can chat for a bit? | 23:07 |
| HarryHaaren | otherwise I can post to lv2-dev if you prefer | 23:07 |
| drobilla | HarryHaaren: Shoot. mainly I'm wonder what extension is needed | 23:14 |
| HarryHaaren | drobilla, have a look at the link there | 23:15 |
| drobilla | I did. I see some ports. So? | 23:15 |
| HarryHaaren | basically, the plugin mixes *voice* into these AuxBus buffers. | 23:15 |
| HarryHaaren | these buffers are then handled by the DAW as the input for an audio bus | 23:15 |
| HarryHaaren | the workflow of the user is greatly improved by having these "AuxBus" sends from *inside* the plugin. | 23:16 |
| drobilla | You expect loading a plugin to automatically create a ton of busses? | 23:16 |
| drobilla | Because I highly doubt any DAW is actually going to do so | 23:16 |
| drobilla | If the users wants to, fine, they can | 23:16 |
| HarryHaaren | the main use-case is: A) kick drum -> needs compression B) snares -> reverb | 23:16 |
| drobilla | From my perspective it seems your head is a little too in your plugin ATM and ideas are crossing abstractions barriers they don't really need to | 23:17 |
| HarryHaaren | drobilla, "a ton" no, a few? optionally. Ardour could expose the buffers in its routing-matrix as if it had multiple "normal audio outputs" | 23:17 |
| drobilla | There are some DAW features that could make this easier that would be nice, no argument there | 23:17 |
| drobilla | But plugin API wise there's nothing really special going on here | 23:17 |
| HarryHaaren | well.. not yet. let me keep talking for a bit | 23:18 |
| HarryHaaren | the point is that since the user can create "submixes" *inside* the plugin, there's a lot of flexibility + power there | 23:18 |
| drobilla | Yes, Ardour can and should do so. As sends | 23:18 |
| drobilla | (Where that send goes is the user's business) | 23:18 |
| HarryHaaren | each *MIDI note-on* event can have a different amount of send to each AuxBus. | 23:19 |
| HarryHaaren | that is currently not possible | 23:19 |
| drobilla | Not really possible at all without actual polyphonic output, unless you have a fixed number of voices where n_voices == n_aux sends | 23:19 |
| drobilla | In which case they aren't really aux sends at all | 23:19 |
| HarryHaaren | no not true | 23:19 |
| drobilla | Well, fine, kinda possible in a plugin give certain static restrictions about what to do with voices | 23:20 |
| HarryHaaren | since the *plugin* mixes the voices into the aux buffers, and MIDI CC as automation for the AuxBus level, we actually can change the amount of AuxBus send *on the same audio-file* for two similar notes (consequtive in time) | 23:21 |
| drobilla | Uninteresting from host POV anyway. | 23:21 |
| HarryHaaren | perhaps not totally interesting: but the point is, what good is a submix (from a preset) if you don't know what FX to apply on it!? | 23:21 |
| drobilla | Who's "you" | 23:22 |
| HarryHaaren | the user | 23:22 |
| HarryHaaren | aka, Fabla2, user loads a big complex drum kit, but doesn't know if AuxBus 1 is reverb or compression | 23:22 |
| HarryHaaren | useless preset | 23:22 |
| drobilla | Well, sure. I can put verb on aux one if I want.. verb on aux one. | 23:22 |
| HarryHaaren | short of experimentation of different FX per AuxBus, how will you know which AuxBus needs what FX? | 23:23 |
| HarryHaaren | this is where some meta-data is needed, that the plugin can communicate to the DAW / user what FX should be on that AuxBus. | 23:23 |
| drobilla | Batshit. | 23:23 |
| HarryHaaren | why? | 23:23 |
| drobilla | Because it is. You want a bidirectional mechanism for a plugin and preset to both figure out and dictate what effects are on an "aux" | 23:23 |
| drobilla | Which isn't even a well defined thing for approximately 9999999999999999999999999999999999999999999999999999999999999999999999999999 reasons | 23:24 |
| *** fundamental has joined #lv2 | 23:24 | |
| drobilla | A plugin that wants to play DAW and launch plugins should probably just literally do so | 23:24 |
| HarryHaaren | take a step back and concider what workflow this would offer to users | 23:25 |
| drobilla | Take a different step back and consider how utterly pissed off people are going to be if somehow setting a preset in a plugin fucks up their Ardour session :) | 23:25 |
| HarryHaaren | it won't :D | 23:25 |
| HarryHaaren | Ardour can "just" expose the AuxBus ports to its routing graph | 23:26 |
| drobilla | Yes. That's all well and good. | 23:26 |
| HarryHaaren | its hosts that are hard-coded stereo, or QTractor, which only supports stereo plugins: these *could* offer a better way of routing with busses or whatever | 23:26 |
| rgareus | from an ealier #lad comment: the "Ardour way" Midi -> plugin -> 10 channels --(10)-> Send A take chan 3+4 send to Bus B1 --(10)-> Send B take chan 5+6 send to Bus B2 --(10)-> BlackBox that removes channels 3-10 --(2)-> out | 23:27 |
| drobilla | At least half the reason I want some kind of even vaguely concrete proposal about what extension is needed is I can't tell where the hell this is going | 23:27 |
| drobilla | Gigantic pot of ideas, 90% of them Fabla internals | 23:27 |
| drobilla | Exactly what's missing in LV2? What do you want to do that you can't? | 23:27 |
| HarryHaaren | the "problem" this is solving is that currently samplers like currently released Fabla are pointless: having kick + snare *in the same audio stream* is useless. | 23:27 |
| drobilla | Seems to me like just some ports. Maybe some new designations needed at most. | 23:27 |
| HarryHaaren | Fabla needs a way to output submixes | 23:28 |
| drobilla | So make some non-main ports and output submixes | 23:29 |
| HarryHaaren | drobilla, you're gonna kill me for the implementation, but at least you'll get the idea: http://openavproductions.com/tmp/auxbus/lv2_auxbus.h | 23:29 |
| HarryHaaren | basically, the plugin communicates some float* 's to the DAW | 23:30 |
| HarryHaaren | simple | 23:30 |
| HarryHaaren | that's what I want. | 23:30 |
| HarryHaaren | I'd prefer if they *weren't* normal audio ports, because then hosts like QTractor that can't deal with audio_ports > 2 won't load it | 23:30 |
| drobilla | .............. you want audio ports that aren't audio ports | 23:31 |
| HarryHaaren | rgareus, ^ maybe you wanna have a glance at the actual WIP header that i hacked together | 23:31 |
| drobilla | Yeah, no. | 23:31 |
| drobilla | Obviously. | 23:31 |
| drobilla | That's what connectionOptional is for | 23:31 |
| HarryHaaren | you know I'm not good at API design, and you know I'm not as familiar with LV2 RDF etc as I'd like to be | 23:32 |
| HarryHaaren | i'm open to how this is implemented: the header above is my take on it, and i'm not married to it | 23:32 |
| drobilla | HarryHaaren: Too many ideas mashed into one | 23:32 |
| drobilla | HarryHaaren: Do you actually need dynamicism? | 23:32 |
| drobilla | Dynamic ports are one thing. "aux busses" are another. | 23:32 |
| HarryHaaren | kind-of yes, if you load a preset, it will have a different use of the AuxBusses | 23:33 |
| HarryHaaren | the *count* won't change though | 23:33 |
| drobilla | So, no. | 23:33 |
| rgareus | HarryHaaren: I imagined some hardcoded semantics in the TTL | 23:33 |
| HarryHaaren | its also possible (i think.. but my weakness in familiarity with TTL is know) | 23:33 |
| rgareus | Dynamically setting these can have some uses. | 23:34 |
| drobilla | Let me put it this way: you can make life dramatically more difficult for yourself and tackle the age old dynamic I/O problem in LV2 despite not actually needing it | 23:34 |
| rgareus | but in that case there should be generic dynamic meta-data. | 23:34 |
| drobilla | Or, just use audio output ports to get the ................ audio output ports, that you want | 23:34 |
| HarryHaaren | no i'm all for letting dyn-manifest die | 23:34 |
| drobilla | Like........ the amount of overthinking and hyper complexity here to get some audio output ports is fucking ludicrous | 23:34 |
| HarryHaaren | don't focus on the implementation: try to see the workflow I'm trying to offer users | 23:35 |
| drobilla | Implementation from a host POV is literally all I care about on this one. | 23:35 |
| HarryHaaren | if an audio-port is just that: hard-coded in TTL, then how should the plugin say what FX it expects on that audio stream? | 23:36 |
| drobilla | Users can have precisely the same workflow with normal ports | 23:36 |
| HarryHaaren | there's also more complex issues, like should the AuxBus stream be mixed back in with the original or not | 23:36 |
| drobilla | and, more importantly, someone (i.e. me) can implement it WAAAAAAAAAAAAAAAAAAAAAAYYYYYYYYYY more easily if it's just........ normal | 23:36 |
| drobilla | Because dynamic ports ain't happening tomorrow. or the next day. | 23:36 |
| HarryHaaren | don't need to be dynamic ports. There is a static number of them. | 23:36 |
| drobilla | Whereas ignoring connectionOptional is trivial and basically required anyway | 23:36 |
| drobilla | and checking what ports are the "main" ones and treating others (aux) specially is straightforward. Just need to actually check. | 23:37 |
| drobilla | HarryHaaren: Then no new API is necessary. | 23:37 |
| HarryHaaren | so what is a solution to "suggesting" the FX applied to a specific set of Aux ports? | 23:37 |
| drobilla | The realistic one? No DAW is actually going to do anything with it. | 23:38 |
| drobilla | That aside, how specific? "reverb", or "this plugin, then this plugin, then this plugin?" | 23:38 |
| grejppi | HarryHaaren: is the idea that the plugin tells the host what effects to load for the aux buses? | 23:38 |
| HarryHaaren | grejppi, one result of : yes | 23:38 |
| drobilla | Tagging a group with, say, "reverb" is reasonable enough. | 23:38 |
| drobilla | Probably just re-use plugin categories for that | 23:39 |
| HarryHaaren | yes, i've got that in v2 of the header | 23:39 |
| HarryHaaren | sure. Adding a plugin URI and a preset URI was the next step | 23:39 |
| drobilla | The hypothetical DAW author who is actually going to do something about this can let users tag busses with the same things and they can be matched up | 23:39 |
| HarryHaaren | aka, "suggested plugin" and "suggested preset" | 23:39 |
| drobilla | Then you need a way for the plugin to even know this information in the first place | 23:39 |
| drobilla | Frankly I suggest you drop the idea and do the rest, which is infinitely more realistic and useful | 23:40 |
| HarryHaaren | look i know I seem to be asking for a crazy workflow, but IMO this is the future of DAW: one that provides the user with an experience : not features | 23:40 |
| * drobilla dodges the waving hands | 23:40 | |
| HarryHaaren | yes, my suggestion is that when a preset is saved, the AuxBus FX state is saved too, giving the preset this info | 23:41 |
| drobilla | So if I have that aux routed to 3 different buses and a Jack client, what then? | 23:41 |
| * HarryHaaren notes there's no waving hands from me : just trying to clearly describe why I think this stuff is important | 23:41 | |
| HarryHaaren | it doesn't scale to the whole JACK graph etc etc, perhaps set a limit to one-plugin. | 23:42 |
| drobilla | Well, I'm pretty sure you want to actually get it done and provide a release, so I'm basically giving feedback on the realism of these things | 23:42 |
| drobilla | This is WAY the fuck out there | 23:42 |
| drobilla | Doing aux right and having ardour/whatever makes sends appropriately, is not. Totally doable, can and should be handled correctly | 23:42 |
| HarryHaaren | "this" can all be done relatively easily with an LV2 extension (hence not using audio ports from the beginning) and providing accurate meta-data. Hosts can ignore it if they wish. Acutally, if they don't provide the feature, they won't even know about it. | 23:43 |
| HarryHaaren | I agree a fallback to providing audio-output ports like busses would be good | 23:43 |
| HarryHaaren | and that its also possible using Audio ports described in the TTL | 23:44 |
| drobilla | An API for "aux busses" specially is a terrible idea. Sorry. | 23:44 |
| HarryHaaren | and I had concidered that | 23:44 |
| drobilla | Particularly a completely unextensible one. It's a harder problem. | 23:44 |
| HarryHaaren | I'm not saying its easy, and I'm aware that header was blissfully ignorant to anything extensible etc | 23:45 |
| drobilla | Dynamic I/O is an interesting problem that would be nice to tackle, but as far as "making Fabla do the thing I want", a really unbelievably amazingly inefficient way of getting to the goal that almost nothing will implement for a very long time if ever | 23:45 |
| HarryHaaren | my point is that I feel this needs to be dealt with: there is not way to provide a better user-experience without actually have the info to act upon right? | 23:45 |
| * HarryHaaren reads | 23:45 | |
| drobilla | If you want to throw in with that effort, I'm totall game, but that's the situation | 23:45 |
| drobilla | My point is that getting your workflow (as far as aux outs are concerned) is trivially easy with stuff we have | 23:46 |
| HarryHaaren | yes i'm aware of that. How to build the "way out there" stuff on top of that implementation is what I'm not sure of | 23:46 |
| rgareus | realistically. 1) use existing port-group semantics -> halfway done. 2) a simple way to add "human readable" meta-data to ports | 23:47 |
| HarryHaaren | this meta-data needs to be dynamic per preset though: i guess that's where the big problem comes from | 23:47 |
| rgareus | (2) can be used with JACK and in Ardour we could display them on hover over the (currently too small) port/wire | 23:47 |
| rgareus | fixed number of outputs | 23:48 |
| HarryHaaren | yes, but the "metadata" re each AuxBus needs to change | 23:48 |
| rgareus | adding a simple way to add sends of a sub-group should be added to the DAW. | 23:48 |
| drobilla | Honestly, I don't think what you're connected to is any of the damned plugin's business | 23:48 |
| HarryHaaren | preset 1 has reverb on Aux1, preset2 has a delay. | 23:48 |
| drobilla | Least of all a preset for said plugin | 23:48 |
| rgareus | HarryHaaren: presets are broken | 23:48 |
| drobilla | I'd be shocked if anyone actually implements such a thing. It's a fractal of hard problems with no clear solution | 23:49 |
| HarryHaaren | well... how else can I load a huge drumkit every time I use Fabla? Lv2:State saves a preset right? | 23:49 |
| HarryHaaren | drob: yes I've understood that too: I see limiting the actual functionality is a solution to that | 23:50 |
| rgareus | HarryHaaren: the problem only exists if you switch from preset 1 (aux1,2 -> reverb) to preset 2 (aud 5,6 -> reverb) in the same session | 23:50 |
| HarryHaaren | aka, an AuxBus can "recommend" only one plugin, and one specific preset for that plugin. | 23:50 |
| HarryHaaren | rgareus, yes exactly | 23:50 |
| drobilla | An options-like announce interfae would let you change stuff about ports dynamically... | 23:50 |
| rgareus | HarryHaaren: same session => don't do this | 23:50 |
| HarryHaaren | rgareus, unfortunatly this is pretty common for testing out drumkits / presets in a session? | 23:51 |
| rgareus | HarryHaaren: then the presets are broken | 23:51 |
| rgareus | HarryHaaren: or you need to re-wire | 23:51 |
| drobilla | Somewhat funnily, it'd actually be way easier to have the host literally just load a plugin for the plugin and pass its handle | 23:52 |
| HarryHaaren | drobilla, I don't have experience with the options interface much, but if it allows changing meta-data about a port, then perhaps this is a solution. | 23:52 |
| rgareus | HarryHaaren: making the connection to real-live drumkits on stage.. Band changes -> Drumkit gets replaced BUT the mic + channel mapping is identical for the whole show | 23:52 |
| drobilla | HarryHaaren: In one directly only at present (host tells plugin stuff) | 23:52 |
| rgareus | HarryHaaren: some mics might be unused in certain sets. but you don't re-wire | 23:52 |
| drobilla | What did las have to say about this? | 23:53 |
| HarryHaaren | rgareus, yeah.. ok, good analogy, but that argues "have tons of AuxBusses" in case a user wants specifically "this" | 23:53 |
| drobilla | I'd expect the very idea of plugins dicking with a session's structure to have gotten an.... entertaining response :) | 23:53 |
| HarryHaaren | we didn't get that far, i only talked of the AuxBus idea with him, and exposing to Ardour routing | 23:54 |
| HarryHaaren | that said, that's all I'd expect Ardour to implement / support | 23:54 |
| HarryHaaren | keep in mind I'm trying to push boundaries for live-performance: things like auto-creation of busses for FX etc are not that insane | 23:54 |
| drobilla | I suspect dynamic ports in LV2 should just announce the presence of new ports that otherwise work just like other ports. i.e. a thing with an index you connect_port | 23:54 |
| drobilla | So even with hypothetical dynamicism you should just use ports anyway | 23:55 |
| drobilla | Having multiple kinds of ports strikes me as about as well as we can do as far as making LV2 a big inconsistent mess, to be slandered and replaced ASAP... | 23:56 |
| falktx | lv2 already has a mechanism to announce things => options | 23:56 |
| falktx | use "options" to announce a new/removal of a port | 23:56 |
| HarryHaaren | i don't know enough to comment on this: it kinda defines the "direction" LV2 goes for expansion in future though: i imagine nasty topics like per-voice controls etc can be done through dynamic ports, so I'm staying well away :D | 23:56 |
| drobilla | falktx: No "announce" currently, but yes. Clear ties there | 23:57 |
| drobilla | Doing nested descriptions will be less fun, but hey. Ports tend to be flat anyway | 23:57 |
| drobilla | Per voice controls is just event business. Nothing particularly alarming. | 23:57 |
| HarryHaaren | ok, coming back to planet available-right-now, what solution do we have to provide AuxBus type functionality? | 23:57 |
| drobilla | HarryHaaren: http://lv2plug.in/ns/ext/port-groups#mainOutput and mainInput | 23:58 |
| drobilla | HarryHaaren: Auxes lv2:connectionOptional | 23:58 |
| HarryHaaren | output only, connectionOptional sure | 23:58 |
| drobilla | HarryHaaren: done and done. | 23:59 |
| drobilla | We could maybe use a designation or property or something for "I'm aux-like" | 23:59 |
| HarryHaaren | now we need to communicate *somehow* to the user what FX should be on what AuxBus | 23:59 |
| HarryHaaren | yeah, i'd like that | 23:59 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!
