| *** ricardocrudo has joined #lv2 | 01:09 | |
| *** Balten has joined #lv2 | 01:58 | |
| Balten | Heya | 01:58 |
|---|---|---|
| *** ricardocrudo has quit IRC | 02:00 | |
| drobilla | Balten: Hello. | 02:03 |
| *** Balten has quit IRC | 02:37 | |
| *** NickSB2 has joined #lv2 | 02:56 | |
| *** velho has quit IRC | 03:13 | |
| *** Anchakor_ has quit IRC | 05:19 | |
| *** LAbot` has joined #lv2 | 06:10 | |
| *** LAbot has quit IRC | 06:11 | |
| *** Anchakor_ has joined #lv2 | 07:01 | |
| *** zth has joined #lv2 | 07:05 | |
| *** zth has quit IRC | 07:11 | |
| *** NickSB has quit IRC | 08:38 | |
| *** NickSB has joined #lv2 | 08:38 | |
| *** edogawa has joined #lv2 | 09:33 | |
| *** grejppi has quit IRC | 10:30 | |
| *** falktx has joined #lv2 | 11:17 | |
| *** grejppi has joined #lv2 | 11:39 | |
| *** rncbc_jolla has joined #lv2 | 12:25 | |
| *** ricardocrudo has joined #lv2 | 12:37 | |
| *** NickSB2 has quit IRC | 13:36 | |
| *** rncbc_jolla has quit IRC | 13:37 | |
| *** rncbc_jolla has joined #lv2 | 13:44 | |
| *** edogawa has quit IRC | 13:47 | |
| *** ddom has joined #lv2 | 13:50 | |
| *** falktx has quit IRC | 14:03 | |
| *** rncbc_jolla has quit IRC | 14:17 | |
| *** gabrbedd has quit IRC | 15:15 | |
| *** gabrbedd has joined #lv2 | 15:19 | |
| *** gianMOD has joined #lv2 | 16:05 | |
| bgola | im trying the latest version of jalv / patchage / qjackctl to check the jack metadata api (pretty names) but no success at all, patchage and qjackctl compiled with metadata support, jalv (and mod-host) as well .. any ideas why? | 16:41 |
| *** zth has joined #lv2 | 16:48 | |
| *** ddom has quit IRC | 16:59 | |
| *** HarryHaaren has joined #lv2 | 17:04 | |
| bgola | hm, jack2 doesnt implement the metadata api :| ... | 17:26 |
| *** falktx has joined #lv2 | 17:51 | |
| HarryHaaren | bgola, probably worth posting to jack-dev mailing-list, Stephane Letz (the main jack2 guy) reads there. | 18:02 |
| * HarryHaaren out for dinner, later | 18:03 | |
| *** HarryHaaren has quit IRC | 18:03 | |
| drobilla | Indeed it doesn't. They added a stub API that does nothing | 18:03 |
| *** grejppi has quit IRC | 18:05 | |
| falktx | you mean the jack2 metadata ? | 18:08 |
| drobilla | falktx: yeah | 18:08 |
| falktx | I made that, it was mostly to ensure binary packages built with jack1 still worked for users with jack2 | 18:08 |
| falktx | that's very important for audio distros | 18:08 |
| bgola | falktx: maybe some kind of warning (even only when jackd is running with --verbose ;)) would be nice | 18:14 |
| falktx | bgola: the jack2 changelog stated that meta-data is non-working | 18:15 |
| bgola | only figured it when I checked jack2 source code to find why it was returnig -1 | 18:15 |
| falktx | if jack2 has meta-data working there would be great news about it | 18:15 |
| falktx | *had | 18:15 |
| *** gianMOD has quit IRC | 19:00 | |
| *** gianMOD has joined #lv2 | 19:02 | |
| *** wumpus has quit IRC | 19:28 | |
| *** grejppi has joined #lv2 | 19:43 | |
| *** zth has quit IRC | 20:06 | |
| *** zth has joined #lv2 | 20:21 | |
| *** zth has quit IRC | 20:22 | |
| *** HarryHaaren has joined #lv2 | 20:35 | |
| grejppi | hey all, remember that note event idea I had a while back? | 20:36 |
| grejppi | I've begun revising it | 20:36 |
| grejppi | https://gist.github.com/grejppi/6dca5caaddd9e408b7ec | 20:37 |
| grejppi | there's a new draft; I hope it gives good enough an idea | 20:37 |
| grejppi | basically, instead of notes with arbitrary IDs, you now deal with a defined set of voices (think of a tracker interface) | 20:42 |
| grejppi | and the different parameters you can give to the voices are (for now) restricted to float values, similarly to control ports | 20:43 |
| *** gianMOD_ has joined #lv2 | 21:01 | |
| *** gianMOD has quit IRC | 21:02 | |
| *** edogawa has joined #lv2 | 21:14 | |
| drobilla | grejppi: hmm. giving voices properties like velocity rather than notes seems weird | 21:19 |
| drobilla | and it's totally divorced from a sort of 'better MIDI' event model basically everyone expects | 21:21 |
| drobilla | Though voice control in general is certainly a good thing | 21:21 |
| drobilla | need to think about it | 21:21 |
| grejppi | drobilla: each voice can play only one note at a time, and that's where velocity and other properties apply to | 21:23 |
| drobilla | grejppi: So what does a note on event look like? | 21:26 |
| drobilla | (or equivalent) | 21:26 |
| drobilla | Also it is probably simpler and more in line with how we (are starting to) use properties with atoms in other cases to state the range and such on the property itself. Then plugins just need to list the ones they support and all the information is attached to the property. designating a pseudo-property as another property is weird | 21:27 |
| grejppi | good that you brought this up | 21:28 |
| grejppi | I see a massive hole in my logic :3 | 21:29 |
| grejppi | these properties in this draft don't have uris | 21:29 |
| * grejppi is lost in ttl | 21:30 | |
| drobilla | I am not sure it's a net win over simply adding a voice number to note/control events, though | 21:31 |
| drobilla | Fair enough. +1 for bothering at all :) | 21:32 |
| drobilla | It is interesting to consider no "note events" at all, though | 21:35 |
| drobilla | Just setting properties | 21:35 |
| drobilla | Where you set velocity, note number, and whatever, with a voice number | 21:36 |
| drobilla | Though the simple patch:Set is no good for setting many at a time... | 21:39 |
| drobilla | I am very interested in this stuff in general, but quite a few more conservative/important things to get out of the way first, and a release | 21:41 |
| *** gianMOD_ has quit IRC | 21:43 | |
| grejppi | drobilla: just updated that document with some explanations at the bottom | 21:44 |
| grejppi | also, one may think of voice indices equivalent to note ids | 21:45 |
| drobilla | grejppi: Better, thanks. | 21:51 |
| drobilla | I think ultimately it needs integration with the patch stuff, but same problem there | 21:51 |
| drobilla | patch:put requires you to have a blank that contains all the properties, so it's nested | 21:51 |
| drobilla | I avoided having a flag one with 'special properties' because that's kind of sketchy | 21:52 |
| drobilla | flat* | 21:52 |
| drobilla | but Set can only do one | 21:52 |
| drobilla | I'll have to think about if it's possible to have a more general message that's as convenient as your voice:VoiceEvent example here but not problematic | 21:52 |
| drobilla | though having a separate VoiceEvent isn't necessarily a bad thing. just need to consider non-voice stuff as well | 21:53 |
| grejppi | drobilla: something like control ports but with atom events I suppose? | 21:54 |
| Anchakor | what is the use case for this anyway? aren't voices kinda synth internal issue? | 21:56 |
| grejppi | Anchakor: yes, generally | 21:57 |
| grejppi | actually this extension would move the responsibility of allocating voices from the plugin to the host | 21:57 |
| grejppi | I mentioned trackers earlier | 21:58 |
| grejppi | jeskola buzz, aldrin, neil, etc... these in particular are what I'm thinking of | 21:59 |
| drobilla | grejppi: Yes. Which if you think about it, is basically what this is | 21:59 |
| drobilla | It *can* move that reponsibility, but we can't really *require* hosts to do so, either | 22:00 |
| drobilla | But this ties in with another thing: ideally this should be ultra simple to use on both sides, and double-ideally easy to drive from other protocols, like MIDI | 22:00 |
| drobilla | Which suggests a thin utility layer to translate, which could also optionally do voice allocation | 22:00 |
| drobilla | That parts comes after the events and such make sense though | 22:01 |
| grejppi | such a utility is in my plans | 22:01 |
| Anchakor | usually for this kind of control (track-like continuous control - velocity,panning etc) you use multiple instances | 22:01 |
| Anchakor | how would you control how re the voices allocated anyway? | 22:02 |
| drobilla | Per-voice controls would be an extremely powerful thing to be able to control in a DAW as well. Particularly stuff like bend | 22:03 |
| HarryHaaren | +1, using multiple instances is a hack fix because most plugin specs don't allow the "ideal" workflow | 22:03 |
| Anchakor | I'm all for rich note events, but this is different | 22:03 |
| drobilla | Not really. | 22:03 |
| Anchakor | this is track-like controls | 22:03 |
| drobilla | What is a "track-like control"? | 22:03 |
| grejppi | Anchakor: the plugin has voice:polyphony which tells the host how many voices it can manage. the host is free to use them however it wants | 22:04 |
| Anchakor | velocity, panning etc continuously, no matter what notes are playing | 22:04 |
| drobilla | Sure, you need to be able to have non-voice-associated controls | 22:05 |
| grejppi | if it's a piano roll based, or if notes are converted from midi, it can allocate voices sequentially | 22:05 |
| HarryHaaren | drobilla, since we're here, partial-expose for PUGL, will I add a function puglPostPartialRedisplay(PuglView* view, x, y, w, h) ? | 22:05 |
| drobilla | This is not that. This is pretty much exactly no-that, that's the entire point :) | 22:05 |
| drobilla | HarryHaaren: Isn't expose already like that? | 22:05 |
| drobilla | HarryHaaren: I guess not in the glut-like callback API | 22:05 |
| HarryHaaren | currently puglPostRedisplay(PuglView* view); | 22:05 |
| HarryHaaren | (is what the client code calls to re-blit the backbuffer) | 22:06 |
| drobilla | HarryHaaren: Hm, yes. That should have had sizes all along. Not sure if I got that from glut or if I'm just stupid | 22:06 |
| drobilla | glut | 22:06 |
| HarryHaaren | no issue, adding the "Partial" into the function name will solve? | 22:06 |
| HarryHaaren | no breaking backwards either? | 22:07 |
| Anchakor | well I think voices are an implementation detail which are done by the synths internally how they like it, an rich events are what we really are after. I don't thing host/user should think about voice-note allocation | 22:07 |
| Anchakor | think* (wtf /me, go sleep) | 22:07 |
| drobilla | That is sometimes the case. | 22:08 |
| drobilla | Usually because MIDI is a piece of shit. | 22:08 |
| drobilla | But it's basically equivalent to "I think you shouldn't be able to control things on a per-voice basis" | 22:08 |
| drobilla | Which is just crippled | 22:08 |
| drobilla | Poly aftertouch being the existing case of such a thing, which MIDI needs a special event for | 22:09 |
| drobilla | DAWs and modular environments and trackers and other such things that can make use of it aside, I have a controller to my right that can send independent bend and pressure for several independent notes | 22:10 |
| Anchakor | why not introduce note event ids and allow changing properties for them? | 22:10 |
| drobilla | Perhaps. More or less the same thing. Either is more difficult in various scenarios/perspectives | 22:11 |
| grejppi | Anchakor: that was the original idea, but then I ran into quite a few issues | 22:11 |
| drobilla | But I might want to change the delay on a /voice/ independent of the notes played on that voice, too | 22:11 |
| drobilla | grejppi: Do you have experimental plugins that use this stuff? | 22:12 |
| Anchakor | with voices as user I either have to manually allocate the notes to the voices or have a method of acquiring the voice ID for a note | 22:12 |
| drobilla | Define "user" | 22:12 |
| drobilla | Clearly the user-user wouldn't ever be doing such a thing (except perhaps in "advanced environments") | 22:13 |
| Anchakor | sequencer | 22:13 |
| grejppi | drobilla: yes, the note extension is implemented in my fork of lmms | 22:13 |
| grejppi | and I made a simple test plugin that proved me note ids was not the right way to go | 22:13 |
| drobilla | The obvious problem with non-constrained note IDs is the plugin then has to look them up | 22:14 |
| drobilla | Maybe they are the same thing anyway. Host knows polyphony, and the "stupid note ID" is just (last_note_id++ % voices). Which also happens to be a voice number | 22:15 |
| Anchakor | I don't see why it would | 22:15 |
| drobilla | Well, I get a change for note 235679532 | 22:15 |
| drobilla | What now? | 22:15 |
| drobilla | foreach (voice) if (voice.current_note_id == 235679532) { ... } | 22:16 |
| drobilla | for every single event | 22:16 |
| Anchakor | plugin just remembers IDs for still active notes and applies updates for them which recieves and ignores update for those he doesn't know | 22:16 |
| drobilla | uh.. yeah, i.e. looks them up :P | 22:16 |
| grejppi | drobilla: https://gist.github.com/grejppi/68a0c0aee6690b3a8925 | 22:17 |
| drobilla | HarryHaaren: Maybe just puglPostExpose | 22:17 |
| falktx | you can always use pointers | 22:17 |
| drobilla | (shorter and matches event name) | 22:17 |
| Anchakor | well if you define a function implemented by a plugin which gives a host a "plugin side note id" that is basically a voice :) | 22:17 |
| drobilla | falktx: ew. | 22:17 |
| HarryHaaren | drobilla, sure yeah that's fine | 22:18 |
| drobilla | falktx: It needs to be "wire" transferrable anyway, so pointers are out | 22:18 |
| drobilla | Anchakor: Perhaps, but I don't see the win. | 22:19 |
| Anchakor | with voices it's nice that it allows sequencer to plan out the voice allocation | 22:19 |
| drobilla | If a plugin wants to implement its own voice allocation, fine, it can do so. Just set "polyphony" to some crazy high value and do so | 22:19 |
| drobilla | or leave it unset, perhaps | 22:19 |
| grejppi | ^ that's a possibility | 22:20 |
| Anchakor | however that also means the sequencer *has to* plan out the voice allocation | 22:20 |
| drobilla | The problem with a "pure setting-properties based" approach to notes is essentially that | 22:21 |
| drobilla | If the host *doesn't* specify voices, you're kind of screwed, since what is a "note on" is ambiguous | 22:21 |
| Anchakor | I don't follow | 22:22 |
| drobilla | A property can sort of do it ("gate", here) but I'm not sure about that | 22:22 |
| drobilla | Anchakor: If you have fancy note events, the host can just note pass a voice number. Done. | 22:22 |
| Anchakor | I assumed there would be some note lifecycle control so plugin knows when to drop the note id | 22:23 |
| drobilla | No per-voice control that way, but it's straightforward | 22:23 |
| *** ricardocrudo has quit IRC | 22:23 | |
| drobilla | But if there are no note events at all, just setting properties on a voice, you can't really do that | 22:23 |
| drobilla | Which is unfortunate because that's a very nice approach otherwise | 22:23 |
| drobilla | Well, you can, kinda, if setting the 'note gate' or whatever to 1 means note start | 22:24 |
| Anchakor | well it seems the same as having multiple monophonic synths :) | 22:24 |
| drobilla | But I am not sure how nice this will be. Usually plugins dispatch on event type, if (note_on) { } else if (note_of) { } else if (control) | 22:24 |
| drobilla | This, I think, is the fundamental question | 22:26 |
| drobilla | Different message type for notes, or not | 22:26 |
| Anchakor | didn't you implement something like this in ingen? wrapper-polyphony for mono synths? just add this logic to the wrapper and you have this voice system | 22:26 |
| drobilla | Multiple instances is not a solution for a slew of obvious reasons | 22:27 |
| HarryHaaren | drobilla, PUGL epose: partial redraw coordinats: A) add PuglEventExpose instance to impl B) add ints to impl? | 22:27 |
| drobilla | Basically "just don't support polyphony". Silly. | 22:27 |
| drobilla | Also probably the most host-burdensome approach possible | 22:28 |
| drobilla | HarryHaaren: There is already an expose event with x,y,width,height | 22:28 |
| HarryHaaren | drobilla, yep, but we need to move the data from the puglPostExpose() function, and have it in puglProcessEvents() | 22:29 |
| drobilla | HarryHaaren: puglDispatchEvent(). The view needs a display function with coords | 22:29 |
| HarryHaaren | drobilla, yep, i gathered that | 22:30 |
| Anchakor | I mean if all hosts do implement this voice allocation stuff for the plugins and it's trivial to do so for host implementers, I'm in complete support of this voice system | 22:30 |
| drobilla | HarryHaaren: PostRedisplay is probably wrong to be setting a flag. I think it can just post an expose event, like the backend does | 22:30 |
| HarryHaaren | drobilla, ah right, so puglDispatchEvent(view, (const PuglEvent*)&expose); with the partial rectangle in place? | 22:31 |
| drobilla | As I said, that's the primary problem with not having a separate note event | 22:31 |
| drobilla | A layer in-between could do this part, though | 22:31 |
| Anchakor | I just don't want as a user allocate notes to voices manually or just have host authors give up on implementing this functionality because it's too tedious | 22:31 |
| drobilla | Well, the reality check there is, hosts probably don't want to implement this whatsoever. Particularly by crafting the events. | 22:32 |
| grejppi | how is it tedious if there are many many midi based instruments out there that do voice allocation on a daily basis? :3 | 22:32 |
| drobilla | Even if I made a fancier C++ forge, not very popular. | 22:32 |
| drobilla | The layer, in particular, would need a handle_midi_event(buf) | 22:32 |
| drobilla | Which the overwhelming majority of hosts would, at least initially, use | 22:32 |
| drobilla | Then you have a fancy plugin with atom events and potential voice control and all that business, but if a host doesn't give a shit, it can just fire MIDI at it | 22:33 |
| drobilla | But with note events the plugin can just do it if there's no voice numbers. It's unfortunate to have to do both, though... | 22:34 |
| drobilla | Seems all signs point to a nice abstraction being a key piece | 22:34 |
| *** edogawa has quit IRC | 22:37 | |
| *** falktx has quit IRC | 23:30 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!