| drobilla | rgareus: Minor thing ingen's menu keeps reminding me of: we really need some category for things like MIDI filters | 01:43 |
|---|---|---|
| drobilla | Need a verbey word for 'eventey stuff', but no idea what that could be | 01:45 |
| rgareus | drobilla: I re-classified them as "lv2:UtilityPlugin" recently | 02:05 |
| * rgareus needs to make a new relase soon. | 02:11 | |
| drobilla | rgareus: Yeah, Utility is much better than Filter, but now Utility is even more a massive list of etc. | 02:19 |
| drobilla | I was thinking that classifying based on a mechanism might be questionable, a lot of them have higher level meanings, too (musical scale stuff, timing stuff, dynamics, etc) | 02:23 |
| rgareus | EventProcessor is to geeky, I suppose | 02:24 |
| drobilla | But you can have several classes, so no reason not to stick yourself in the existing hierarchy too if it makes sense | 02:24 |
| drobilla | rgareus: "MIDI" is less nerdy (at least to anyone who would be using it in the first place), but... well, then it's MIDI :) | 02:25 |
| rgareus | EventProcessor would be the super-class of Midi2Midi. | 02:26 |
| drobilla | "Events" isn't a verb, but some of the current ones aren't either (Dynamics, Delay sort of) | 02:26 |
| rgareus | verb? which category has a verb? | 02:27 |
| *** NickSB2 has joined #lv2 | 02:27 | |
| drobilla | Generator, Modulator, Simulator | 02:27 |
| rgareus | since when is "Generator" a verb :) | 02:28 |
| drobilla | Nevermind, it's already inconsistent so it doesn't matter | 02:28 |
| rgareus | they're all nouns. | 02:28 |
| drobilla | Oh, right. I'm being sloppy with language | 02:28 |
| rgareus | except for some ambiguities. comb works :) | 02:29 |
| drobilla | A description of the thing that does the action (plugin) vs the data itself | 02:29 |
| * rgareus wants to use PitchPlugins to pitch LV2. | 02:30 | |
| drobilla | Classifying things is tedious :) | 02:30 |
| drobilla | I don't know if I'd make intype=>outtype the second level | 02:31 |
| rgareus | I don't mind classifying the plugin itself. Coming up with good set of categories is the hard part. | 02:31 |
| drobilla | e.g. something like PitchPlugin and TimingPlugin and a Converters for any inter-protocol business might make more sense | 02:31 |
| drobilla | Maybe just a MIDI for things that are very about MIDI... | 02:32 |
| drobilla | But for now AFAIK yours is the only fully event-based set, so easiest is to just add lv2:EventPlugin and stick them directly in that | 02:32 |
| drobilla | Move 'em later if things get unwieldy there | 02:32 |
| rgareus | drobilla: distinguishing them from instruments is the tricky part. | 02:32 |
| drobilla | rgareus: Well, they have no audio outputs, so... | 02:33 |
| rgareus | while we're at this. where would "audio to midi" plugins fit it? | 02:33 |
| rgareus | lv2:ConverterPlugin is close. | 02:33 |
| drobilla | Yeah, that's the best fit of the current classes I think | 02:35 |
| drobilla | Though maybe lv2:AnalyserPlugin would be more accurate for most | 02:36 |
| drobilla | (How many hosts present a hierarchical menu?) | 02:37 |
| rgareus | 2? | 02:37 |
| drobilla | Though I should add a by-project menu to Ingen | 02:42 |
| drobilla | (Related note, it's kind of annoying to have the "Calf" or "MDA" or whatever prefix baked-in so the host can never show you just the name, but that won't change...) | 02:44 |
| drobilla | or, author=>project, maybe | 02:45 |
| drobilla | rgareus: Seeems we also need a MeterPlugin | 02:45 |
| rgareus | :) | 02:47 |
| drobilla | Though until there's other AnalyzerPlugins I guess it doesn't matter, just moves the hulk of meterplugins somewhere else and leaves that empty | 02:48 |
| rgareus | calf has an AnalyzerPlugin, too | 02:48 |
| drobilla | Channel variants are unfortunate, but AU we ain't :/ | 02:49 |
| rgareus | and yes, it's an odd choice to bake in "branding" in the name for FLOSS plugins. | 02:49 |
| drobilla | rgareus: Yeah, I was mainly thinking about what to do when actual analyzer plugins show up (as per other discussion) | 02:49 |
| drobilla | rgareus: Well, this *could* be forced away by host pressure | 02:49 |
| drobilla | e.g. if you support project name stuff, and the data is there, auto-prefix it most everywhere | 02:50 |
| drobilla | So they get Calf Calf Filter until they fix it :) | 02:50 |
| rgareus | IMHO it makes little sense. most "collections" are diverse enough. | 02:51 |
| rgareus | anyway. I gotta sleep. | 02:52 |
| drobilla | g'night | 02:52 |
| rgareus | CU in the morning. | 02:52 |
| *** NickSB2 has quit IRC | 04:28 | |
| *** falktx` has joined #lv2 | 04:30 | |
| *** falktx has quit IRC | 04:34 | |
| *** ColaEuphoria has joined #lv2 | 06:21 | |
| *** edogawa has joined #lv2 | 07:31 | |
| *** drobilla has quit IRC | 07:49 | |
| *** NickSB___ has quit IRC | 07:50 | |
| *** NickSB has joined #lv2 | 07:51 | |
| *** falktx has joined #lv2 | 09:29 | |
| *** NickSB has quit IRC | 09:36 | |
| *** ddom has joined #lv2 | 09:39 | |
| *** ventosus has joined #lv2 | 09:43 | |
| *** ricardocrudo has joined #lv2 | 09:57 | |
| *** NickSB has joined #lv2 | 09:57 | |
| *** aombk2 has joined #lv2 | 10:21 | |
| *** falktx has quit IRC | 10:23 | |
| *** aombk has quit IRC | 10:23 | |
| *** ricardocrudo has quit IRC | 10:29 | |
| *** ricardocrudo has joined #lv2 | 10:44 | |
| *** falktx|work has joined #lv2 | 10:49 | |
| *** NickSB2 has joined #lv2 | 11:06 | |
| *** NickSB2 has quit IRC | 13:49 | |
| *** drobilla has joined #lv2 | 14:41 | |
| *** son0p has quit IRC | 14:49 | |
| *** son0p has joined #lv2 | 14:53 | |
| *** drobilla` has joined #lv2 | 17:18 | |
| *** drobilla` is now known as drobilla_lab | 17:19 | |
| *** rncbc has joined #lv2 | 17:26 | |
| *** ddom has quit IRC | 17:43 | |
| *** ssj71 has joined #lv2 | 18:27 | |
| *** ssj71 has quit IRC | 18:32 | |
| *** ssj71 has joined #lv2 | 18:33 | |
| *** SadKo has joined #lv2 | 18:47 | |
| SadKo | Hello all, is x42 here? | 18:50 |
| ssj71 | rgareus: ^^ | 18:53 |
| *** SadKo has quit IRC | 18:54 | |
| rgareus | I am now | 18:55 |
| rgareus | while we wait for him to come back: is there a host that supports multiple Atom ports (same direction)? | 18:55 |
| rgareus | SadKo wrote a plugin like that http://tracker.ardour.org/view.php?id=6679#c17675 | 18:56 |
| ssj71 | rgareus: considering thats the first such plugin I doubt it | 18:58 |
| rgareus | ardour's engine can potentially do this, but some of the MIDI plumbing prevents it from working correctly.C[C[C[C[C[C[C[C[C[C[C[C | 18:58 |
| ssj71 | why wouldn't one port just process all the atoms that come through? | 18:58 |
| drobilla_lab | We need to establish a property for 'this is my control port' for this reason | 18:59 |
| drobilla_lab | Though plugins except those that *need* multiple streams inherently (MIDI mixers and routers and so on) should not do this | 18:59 |
| ssj71 | can we add some verbage like "only one port shall be designated as lv2:control" | 19:01 |
| ssj71 | or would that not suffice? | 19:01 |
| drobilla_lab | It seems to monitor some "UI sync" event port, *and* a float port for phase | 19:02 |
| drobilla_lab | I have not looked deeper than that but I highly doubt this is sane :) | 19:02 |
| rgareus | multiple midi i/o is a valid use-case | 19:03 |
| drobilla_lab | ssj71: one port in each direction, perhaps, but something like that, yes | 19:03 |
| rgareus | ardour allows for multiple event ports and does already handle it properly IFF one adds a custom 2nd midi port to the track. | 19:03 |
| rgareus | but then no synth can be added to the track (there are none with 2 ins) | 19:04 |
| drobilla_lab | A port that only exists for UI communication (assuming that should even exist at all) should probably be connectionOptional | 19:06 |
| rgareus | if you read back on the tracker - it all started because Ardour < 4.4-git does not re-send output port values when the UI is re-opened. | 19:08 |
| rgareus | I should not have mentioned Atom ports, but I'm glad I did. new user groks the concept in no time and finds new edge-cases :) | 19:10 |
| rgareus | not a a single complaint about RDF or URIs either - that must be a first :) | 19:12 |
| drobilla_lab | Too long. I skimmed it :) | 19:12 |
| drobilla_lab | The correct way to do this if you are using atoms is to have the UI send a request (typically patch:Get) when it's opened | 19:12 |
| drobilla_lab | (Though if they added those ports just to work around Ardour, ugh) | 19:13 |
| rgareus | currently release versions of ardour do not re-send the value when the GUI is closed/re-opened. but the whole exercise is somewhat moot because 4.4-git does this now. | 19:16 |
| rgareus | without Atom it is not trivial to work around this. (I used some not-on-gui port handshake for force a change in the past) | 19:17 |
| drobilla_lab | That seems rather odd. The only values around are the correct ones | 19:19 |
| drobilla_lab | I guess it just doesn't update the UI on init whatsoever? | 19:20 |
| * drobilla_lab should probably pay more attention to the Ardour tracker, but, well, life... | 19:20 | |
| rgareus | drobilla_lab: the backend stays around. ardour did not send GUI port_events when the GUI is re-displayed | 19:20 |
| drobilla_lab | rgareus: But it did initially? | 19:20 |
| rgareus | ardour only sent port_events() to the GUI if the value changes. (not every cycle) | 19:20 |
| rgareus | drobilla_lab: yes. show the GUI the first time: all fine. close GUI, re-open -> no events *were* sent. | 19:21 |
| rgareus | well, for the first-time: events were only sent if the current value did not match the default. (that screwed up calf) | 19:22 |
| drobilla_lab | I don't see how those two cases are even different | 19:22 |
| drobilla_lab | But whatever | 19:22 |
| *** ricardocrudo has quit IRC | 19:24 | |
| *** NickSB2 has joined #lv2 | 19:55 | |
| *** falktx|work has quit IRC | 20:24 | |
| *** drobilla_lab has quit IRC | 20:59 | |
| falktx` | rgareus: since some time ago carla does support multiple atom ports | 21:12 |
| falktx` | rgareus: the one with the designation 'control' (or falling back to the 1st one) is used as the main one | 21:13 |
| falktx` | that one gets the messages from the UI I think | 21:13 |
| rgareus | falktx`: I have not seen the full code, nor know what SadKo's plugin does, but it looks like he uses 2 Atom ports for DSP to GUI notifications. | 21:15 |
| falktx` | does he set the 'port_index' in the write_function= | 21:15 |
| falktx` | ? | 21:15 |
| rgareus | I don't know. | 21:16 |
| falktx` | carla can handle it if it does | 21:16 |
| rgareus | I can see that 2 Atom ports make sense for 2 separate MIDI i/o. but it does not for plugin <> GUI comm. | 21:16 |
| falktx` | https://github.com/falkTX/Carla/blob/master/source/backend/plugin/CarlaPluginLV2.cpp#L2943 | 21:17 |
| falktx` | I agree with that | 21:17 |
| falktx` | (you) | 21:17 |
| rgareus | in ardour's case it [only] works if the track in question has 2 event-ports (e.g 2 midi-ins). otherwise the ports are merged into the same buffer | 21:17 |
| *** ventosus has left #lv2 | 21:53 | |
| *** ricardocrudo has joined #lv2 | 22:09 | |
| *** ricardocrudo has quit IRC | 23:14 | |
| *** ricardocrudo has joined #lv2 | 23:26 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!