| *** HarryHaaren has quit IRC | 00:25 | |
| drobilla | falktx: Well, listening for any of them has always been what they Should™ do | 00:51 |
|---|---|---|
| drobilla | falktx: So basically that continues to be best practice, until we just ditch the other types and simplify things | 00:52 |
| drobilla | falktx: The examples always did this. I am not sure what every plugin in the wild does. I'd just leave whatever you're doing for a while, if it works. | 00:53 |
| drobilla | falktx: Should at least wait until the next release in any case. | 00:53 |
| drobilla | falktx: Updating is fine though. Nothing has actually broken in a hard way. | 00:53 |
| drobilla | falktx: Oops. Thanks, fixed those comments. | 00:53 |
| drobilla | falktx: Hmmmmm, why didn't I get those warnings... | 00:54 |
| *** unclechu has quit IRC | 01:00 | |
| falktx | I think I have CV ports working now. what's a good plugin/setup to test it? | 01:07 |
| *** NickSB has quit IRC | 01:14 | |
| *** NickSB has joined #lv2 | 01:15 | |
| falktx | drobilla: does CV have bounds? and a default? I'm now I have the CV port buffers all zero when (in the graph) it's not connected to anything | 01:32 |
| falktx | *right now | 01:33 |
| drobilla | falktx: https://github.com/blablack/ams-lv2 | 01:33 |
| drobilla | falktx: Basically they are audio port buffers + control port data. So, yes. | 01:33 |
| drobilla | I guess the reasonable default would be -1, 0, 1 if not | 01:34 |
| falktx | is that also the same in ladspa? I'm mixing ladspas and lv2s here.. :) | 01:34 |
| falktx | drobilla: ams.lv2 is the avw.lv2 project renamed, right? | 01:35 |
| drobilla | falktx: yeah | 01:47 |
| drobilla | falktx: LADSPA has no such concept | 01:48 |
| falktx | I'm having a small issue in pugl on windows | 02:09 |
| falktx | when the host window moves (the one that has a pugl UI embed) the UI doesn't trigger a repaint | 02:10 |
| drobilla | I need to bring a drive to campus tomorrow and copy the windows VM image | 02:10 |
| falktx | I'm now seeing if I can find a fix | 02:10 |
| falktx | I get no new events when I move the window | 02:15 |
| *** Anchakor_ has quit IRC | 02:29 | |
| *** triune has quit IRC | 04:40 | |
| *** triune has joined #lv2 | 04:45 | |
| *** edogawa has joined #lv2 | 08:07 | |
| *** Anchakor_ has joined #lv2 | 08:35 | |
| *** abique has joined #lv2 | 09:39 | |
| *** Anchakor_ has quit IRC | 09:48 | |
| *** Anchakor_ has joined #lv2 | 09:50 | |
| *** unclechu has joined #lv2 | 10:13 | |
| *** triune has quit IRC | 11:46 | |
| *** triune has joined #lv2 | 11:53 | |
| *** unclechu has quit IRC | 12:26 | |
| *** NickSB has quit IRC | 12:59 | |
| *** NickSB has joined #lv2 | 13:01 | |
| *** falktx has quit IRC | 13:17 | |
| *** triune has quit IRC | 13:18 | |
| *** triune has joined #lv2 | 13:24 | |
| *** triune has quit IRC | 14:19 | |
| *** triune has joined #lv2 | 14:25 | |
| *** edogawa has quit IRC | 15:31 | |
| *** edogawa has joined #lv2 | 15:31 | |
| drobilla | I don't know why those sizeof(LV2_Atom_Object) - sizeof(LV2_Atom) were in there anyway | 15:44 |
| drobilla | sizeof(LV2_Atom_Object_Body) | 15:44 |
| drobilla | The need for two separate types for each there really sucks, just body type would be better, but I couldn't rely on C99 var-length structs | 15:44 |
| drobilla | I guess I could have just ommitted the types for the whole atom entirely. Seems like that would make code uglier, though. LV2_ATOM_BODY() everywhere | 15:45 |
| drobilla | (Re: falktx's patch above) | 15:45 |
| *** triune has quit IRC | 15:50 | |
| *** triune has joined #lv2 | 15:58 | |
| *** ssj72 has quit IRC | 16:19 | |
| *** triune has quit IRC | 16:21 | |
| *** triune has joined #lv2 | 16:28 | |
| *** ssj72 has joined #lv2 | 16:36 | |
| *** Anchakor_ has quit IRC | 16:57 | |
| *** Anchakor_ has joined #lv2 | 16:57 | |
| *** triune has quit IRC | 17:52 | |
| *** HarryHaaren has joined #lv2 | 17:57 | |
| *** triune has joined #lv2 | 18:00 | |
| *** abique has quit IRC | 18:52 | |
| *** abique has joined #lv2 | 19:16 | |
| *** mlpug has joined #lv2 | 19:40 | |
| *** abique has quit IRC | 19:42 | |
| *** HarryHaaren has quit IRC | 19:45 | |
| *** ricardocrudo has joined #lv2 | 20:01 | |
| *** HarryHaaren has joined #lv2 | 20:22 | |
| *** ricardocrudo has quit IRC | 20:47 | |
| *** mlpug has quit IRC | 21:07 | |
| drobilla | Anchakor: http://drobilla.net/files/lac2014_lv2_atoms.pdf | 21:21 |
| *** NickSB2 has quit IRC | 21:33 | |
| Anchakor | drobilla: it's really good so far, I made a few comments in sidelines: http://mud.cz/lac2014_lv2_atoms.pdf.pdf | 22:06 |
| Anchakor | let me know if you can open that pdf | 22:06 |
| Anchakor | when I tried from web, evince said it is damaged, but locally it read it | 22:06 |
| drobilla | Anchakor: it's been bitmapified, but it opens. thanks. | 22:06 |
| * Anchakor finally had an opportunity to really put xournal to use | 22:07 | |
| Anchakor | drobilla: I think most important point is that I am confused if AtomPort is associated with just one atom type or it is a channel to send any atoms through | 22:10 |
| drobilla | In theory you can atom:supports several. In practice it's basically always Sequence | 22:11 |
| drobilla | Anchakor: You seem to be ascribing more to it than it is. It's literally connected directly to LV2_Atom* which is what I was trying to convey | 22:12 |
| Anchakor | I think that part should be expanded and this explained more thoroughtly | 22:14 |
| Anchakor | like how does plugin/host he can write/read to the LV2_Atom | 22:14 |
| Anchakor | s/host/host know/ | 22:15 |
| drobilla | I will try | 22:15 |
| drobilla | But I'm not sure what I can say for simple inputs other than, well, you connect it | 22:16 |
| drobilla | Just like there isn't much to be said about pointing to a float | 22:16 |
| Anchakor | also "connect" term is for most people associated with jack connections | 22:16 |
| drobilla | it's literally in the API, and LADSPAs. If you can imagine a better replacement that isn't a big string of repetitive words... | 22:17 |
| drobilla | I guess just "points" | 22:17 |
| drobilla | explicitly mentioning float* instead of / alongside "audio buffer" may help | 22:18 |
| Anchakor | no that is fine | 22:19 |
| Anchakor | but "AudioPort is | 22:19 |
| drobilla | Well, apparently not. | 22:19 |
| Anchakor | connected to an audio buffer" | 22:19 |
| Anchakor | is worste then "AudioPort points to an audio buffer" | 22:19 |
| Anchakor | worse* | 22:19 |
| drobilla | I had "directly" in there but figured it wasn't helping. | 22:20 |
| drobilla | you can also think of it as a "contains" relationship | 22:20 |
| drobilla | ultimately LV2 ports are pointers. an AtomPort is simply an LV2_Atom* | 22:21 |
| drobilla | I need to convey how utterly mundane and straightforward this concept is better | 22:21 |
| drobilla | Preferably in two sentences or so. | 22:21 |
| Anchakor | ok, now so if AtomPort points to LV2_Atom_Int, some word about how the synchronization between reads and writes happens | 22:22 |
| Anchakor | ...would be good | 22:23 |
| drobilla | what synchronization? | 22:23 |
| drobilla | there's a run() method. | 22:23 |
| drobilla | I kind of assume plugin 101 as a basis | 22:24 |
| Anchakor | ok for some reason I always assumed one AtomPort is enough both for sending and recieving all atoms from/to a host | 22:25 |
| drobilla | ('connect' is just a really fucking stupid way to pass a parameter to run() anyway. Shouldn't have adopted that from LADSPA in the first place) | 22:25 |
| drobilla | I guess I could mention that it is either an input or output for those unfamiliar with LV2 | 22:25 |
| Anchakor | and with Sequence, you can send xor recieve any atoms right? | 22:26 |
| drobilla | Given the context I'm hesitant to even use those words. | 22:28 |
| drobilla | You can have an input sequence, and an output sequence. | 22:28 |
| drobilla | in *separate* ports | 22:28 |
| Anchakor | yeah sure | 22:28 |
| Anchakor | but in the sequence you can combine any atoms | 22:29 |
| *** falktx has joined #lv2 | 22:29 | |
| Anchakor | right? | 22:29 |
| drobilla | Yep. | 22:29 |
| Anchakor | even a sequence in a sequence? :) | 22:29 |
| drobilla | Yep. | 22:30 |
| drobilla | All kinds of fun ;) | 22:30 |
| drobilla | One could even argue a Sequence ia a good representation for a note, I suppose. | 22:31 |
| drobilla | (... but let's not go there) | 22:31 |
| Anchakor | ok great, well you see what I was confused about, so you know what probably others would too :) | 22:31 |
| * falktx wants to get ingen inside carla and carla inside ingen | 22:31 | |
| drobilla | I believe thinking of one as both an input and output was the main problem | 22:31 |
| Anchakor | yeah | 22:32 |
| drobilla | I will revise based on these comments when finished sorting out Ingen | 22:32 |
| drobilla | Since this is what I was supposed to be doing today anyway :) | 22:32 |
| drobilla | (some levels removed from what I really actually am supposed to be doing, naturally) | 22:32 |
| falktx | drobilla: will you ever add back external ui to ingen? I can make all my plugs (carla things) not dependant on instance-data, but I need external ui | 22:33 |
| drobilla | falktx: add back? I don't think it was ever there in the first place. | 22:33 |
| Anchakor | so basically AtomPort is fetched/pushed on every jack period right? | 22:33 |
| drobilla | falktx: in any case, no. Sorry. | 22:33 |
| Anchakor | (every time run() is executed) | 22:34 |
| falktx | drobilla: it was there, I remember seeing linuxdsp UIs working | 22:34 |
| falktx | drobilla: not embed, only external | 22:34 |
| drobilla | Ingen does not and will not ever support things I personally consider counter-productive. | 22:34 |
| drobilla | falktx: Nope, embed as X11UI | 22:34 |
| drobilla | falktx: Which linuxdsp implemented quite some time ago | 22:34 |
| drobilla | One of the originals, in fact | 22:34 |
| falktx | drobilla: I'm not sure how I can force a python based UI (and full blown app like carla) to work as X11UI... | 22:35 |
| falktx | but I'll try | 22:35 |
| drobilla | A nice framework to do so would be a wonderful thing. | 22:35 |
| wrl | falktx: may be prudent to develop some sort of a shim | 22:35 |
| drobilla | Sorry, but I deal with other people's shit SO much. | 22:35 |
| drobilla | Ingen is the one damned thing I get to do my way | 22:35 |
| wrl | an osc/ui bridge that works as a part of the plugin itself | 22:35 |
| drobilla | It's also basically one of the only things I even enjoy working on at all, which I doubt is a coincidence :) | 22:36 |
| drobilla | Intuitively I'd expect if you can write a UI in python whatsoever you can get the window handle for it, but I'm not familiar with such things. | 22:37 |
| wrl | drobilla: wait, without instance-access, the only way a UI can communicate back to the plugin itself is via exposed ports? | 22:37 |
| falktx | wrl: I already have it working as external, just need to pass the X11 window handle and try to do QX11Embed magic I guess | 22:37 |
| wrl | the issue there may be running python inside the address space of the host | 22:37 |
| wrl | or perhaps running several of them | 22:38 |
| drobilla | wrl: I'm not sure what "exposed" means, but yes. That is the Proper™ way to communicate. | 22:38 |
| wrl | drobilla: i suppose there's not another sort of port. okay, noted. | 22:38 |
| falktx | wrl: I create a new process for this | 22:38 |
| falktx | vfork+exec stuff | 22:38 |
| drobilla | I totally get how me both demanding good solutions and not having the time to personally do everything is frustrating, but oh well. Suil was me personally investing the time to make external go away. Other languages weren't really an issue | 22:39 |
| drobilla | I'd love to make that easily possible without imposing on hosts. | 22:40 |
| falktx | drobilla: I think it can work, as long as I use qt4 | 22:40 |
| falktx | with qt5 qx11embed is no longer available | 22:40 |
| drobilla | oh, great. | 22:41 |
| falktx | this is why rui had to implement external-ui | 22:41 |
| falktx | with the move to qt5 there's no x11 embed anymore | 22:41 |
| drobilla | Surely it must be possible to do xembed with qt5 somehow | 22:41 |
| falktx | more hackery :) | 22:41 |
| drobilla | The fuck kind of insane regression is that? | 22:41 |
| drobilla | The stubborn refusal of that fucking kludge to die has me wondering if the LV2_UI interface itself shouldn't just make a bunch of similar assumptions, rather than making it a type | 22:43 |
| drobilla | But doing that now would mean we'd have even more problems, so whatever | 22:43 |
| falktx | drobilla: with qt5 afaik the though was to make the paint backend modular. that's why wayland works there now | 22:44 |
| drobilla | That transition is going to be super fun no matter how you slice it. | 22:45 |
| falktx | qt5 as shared lib can be using NOT x11 | 22:45 |
| falktx | exposing a qx11embed class would be very tricky | 22:45 |
| drobilla | Once again we didn't make the struct extensible, so basically screwed for changing it now | 22:45 |
| drobilla | But having a command(char* name, ...) method on UIs would do | 22:46 |
| drobilla | maybe URI to avoid the obvious problems, but whatever. | 22:46 |
| drobilla | then, a UI can either expose an actual widget, or not, along with a type | 22:46 |
| drobilla | and if that type isn't something the host can actually directly embed, the show command will pop it up | 22:46 |
| drobilla | or something along those lines | 22:46 |
| drobilla | Well, as it happens, there was discussion earlier (myself and rgareus) about how exposing non-portable widget types sucks anyway, having to describe a bunch | 22:50 |
| falktx | can't we just pass some options to the UI for the missing data? | 22:51 |
| drobilla | Maybe we can define a new "widget" type for this, which also has show/hide or whatever (preferably extensibly), and everyone's happy using just that one? | 22:51 |
| falktx | right now I'm using options to tell the UIs about bufferSize and sampleRate | 22:51 |
| drobilla | falktx: yeah, but not to add methods to the UI | 22:51 |
| falktx | extension_data() ? | 22:52 |
| drobilla | Sure, that's what it's for. | 22:53 |
| falktx | drobilla: one thing we might be missing now is the X11 display | 22:53 |
| falktx | I'm not sure though, haven't tested plugins in Xinerame/TwinView yet | 22:53 |
| drobilla | I forget how I got the display. | 22:53 |
| drobilla | I get it from the parent window, which is passed | 22:54 |
| falktx | oh, a X11 Window can report its display? | 22:54 |
| drobilla | Hm, actually, that's GDK_WINDOW_XDISPLAY, in the Gtk wrapper, so Gtk specific | 22:56 |
| drobilla | I'm not sure you can get the display from an X window | 22:56 |
| Anchakor | hmm can you run a webserver in a worker thread? | 22:56 |
| drobilla | I wonder what actual X11 uis do internally | 22:57 |
| drobilla | Anchakor: you can't do continuous anything in the worker thread, it's for processing 'units' of work | 22:57 |
| drobilla | Anchakor: One of the main points is that there may be *one* worker thread in a many-plugin host | 22:58 |
| drobilla | It is *not* a "make me my own private thread" API | 22:58 |
| Anchakor | ok | 22:58 |
| Anchakor | but you can run a separate thread or process from plugin anyway | 22:58 |
| drobilla | right. to do stuff like that there is no point in relying on host support. | 22:59 |
| drobilla | the main point of the worker is that every plugin making a bunch of threads is really not so great | 23:00 |
| drobilla | well, also removed non-portable stuff from plugins which is nice | 23:00 |
| falktx | pianoteq actually creates 2 threads in activate() so it can render in parallel | 23:00 |
| drobilla | and forces plugins to do non-RT things properly since it can only work one way | 23:00 |
| Anchakor | falktx: so if you REALLY want to do external UI, you can do it in HTML :) | 23:01 |
| drobilla | Anyway, I am all for making a widget type that both makes having to list many non-portable UIs in data, and the need for external, go away. | 23:01 |
| Anchakor | +1 to that | 23:02 |
| drobilla | Especially with the X11 => ? transition | 23:02 |
| drobilla | The idea being that *any* UI can degrade by supporting the show and hide commands | 23:02 |
| drobilla | This point of contention is fucking shitty. | 23:03 |
| drobilla | I don't think me embracing external would actually make it any less shitty. | 23:03 |
| drobilla | We need to just remove this from affecting the host<=>ui interface in such fundamental ways at al | 23:03 |
| falktx | I don't think external-ui is going away | 23:04 |
| falktx | it's a good fast solution for when there's no UI types available | 23:04 |
| drobilla | Well, that specific extension would if there was a better alternative. That's the point. | 23:04 |
| falktx | for example, a macos Carbon UI | 23:04 |
| falktx | I don't think any reasonable lv2 host would want to work on an old API | 23:05 |
| drobilla | Having a universal "widget" type that has show/hide commands AND an accessor for the window/whatever pointer | 23:05 |
| falktx | anyway, the currention situation is not so bad | 23:05 |
| drobilla | It's quite bad, actually. | 23:05 |
| falktx | I'm waiting for wayland to reach debian testing and then I'll do some tests | 23:05 |
| falktx | drobilla: could be worse ;) | 23:06 |
| drobilla | It doesn't seem bad when you've already implemented everything, naturally. | 23:06 |
| drobilla | Part of my job is seeing these problems, and solving them with new things. | 23:06 |
| drobilla | People get grumpy about anything changing ever, sure, but c'est la vie. | 23:06 |
| falktx | drobilla: that reminds me, could we have an option for the initial UI width+height? | 23:06 |
| falktx | drobilla: that would avoid an extra UI resize before showing the UI | 23:07 |
| drobilla | falktx: I guess. Can't hurt. | 23:07 |
| drobilla | "can't hurt." properties are such wonderful things. | 23:07 |
| drobilla | okay, anyway, fuck, I need to get back to actually doing work | 23:07 |
| falktx | ok, sorry, me too | 23:08 |
| drobilla | but I think solving all these problems in one widget type and/or extension_data API thingie is really blatantly The Solution, now that I think of it | 23:08 |
| drobilla | Whenever possible, embedders get their widget. If not, there's show/hide commands. | 23:08 |
| drobilla | Boom. rift healed. | 23:08 |
| drobilla | ... come to think of it, why the hell was external-ui implemented as a widget type in the first place? | 23:09 |
| falktx | won't that make the UIs "external" ? | 23:09 |
| falktx | don't ask me... | 23:10 |
| drobilla | It would make them optionally external. | 23:10 |
| falktx | that sounds great | 23:10 |
| drobilla | Well, this entire discussion/solution would have happened years ago if Nedko actually bothered, but let's not go there. | 23:10 |
| falktx | as long as the UI is allowed to refuse to use embed. can I haz that? | 23:10 |
| drobilla | falktx: Either one is a pain in somebody's ass, so probably they'd be able to just not provide either | 23:11 |
| drobilla | I'd have to think about the most backwards compatible thing here, I dunno. | 23:12 |
| drobilla | 6pm, fuck me. more on that later :P | 23:13 |
| drobilla | Today on: How IRC Cost Me My PhD | 23:13 |
| falktx | just one thing (and I'll shutup later): if an UI refuses to use embed, make it so that I can still get a handle to it | 23:16 |
| drobilla | falktx: ? they are the same thing | 23:16 |
| falktx | I like to have the handle directly so that I can tell X11 the transient hint | 23:16 |
| drobilla | you can either get a widget pointer, or not | 23:16 |
| drobilla | that handle is precisely the thing I want, and the reason I hate people falling back to external-ui | 23:17 |
| falktx | drobilla: it's hard to explain. maybe an UI can get us a handle but not support embed | 23:17 |
| drobilla | it is effectively equivalent to "possibly embeddable" | 23:17 |
| drobilla | falktx: Embedding is the host's problem, the way I see it | 23:17 |
| falktx | but the plugin needs to support at least ui-resize for it to work properly | 23:17 |
| drobilla | I still doubt that part | 23:18 |
| drobilla | but 'support ui-resize' is a well-defined thing you can either do or not, so fine. | 23:18 |
| falktx | anyway, talk later, don't want to bother you much | 23:19 |
| drobilla | is 'I don't support embedding for nebulous undefined reasons' going in the API? well, no, clearly not. | 23:19 |
| drobilla | This is infinitely better as a mailing list discussion anyway, but I always think that. | 23:20 |
| * falktx hates mailing lists | 23:20 | |
| drobilla | People with way too much free time generally do | 23:21 |
| drobilla | I remember that. It was nice. :) | 23:21 |
| drobilla | I wish someone was working on a unified discussion bridge that wasn't also trying to ruin it for better profit margins | 23:22 |
| drobilla | But failing that I'll stick to the thing that's worked for decades | 23:22 |
| Anchakor | I don't really see IRC<->mailinglist bridge working :) | 23:23 |
| drobilla | Suffice to say it's unbelievably shitty for me to effectively either have to be constantly so distracted and irritated that I can't get any work done whatsoever, OR, be completely in the dark about a project I maintain / benevolently dictate | 23:23 |
| drobilla | Anchakor: That's more of a forum/mailing list idea, admittedly | 23:23 |
| drobilla | IRC is in the exact same box of toxic shit as Facebook is for me. Both occasionally useful, but net effect is crippling. | 23:24 |
| drobilla | The irony of going on about it on a meta level like this makes it self-evident really :) | 23:25 |
| Anchakor | I'd prefer some decent forum software which works more IM-like, something like reddit which you can install on your own server, but without that downvote bullshit | 23:25 |
| drobilla | On that, I noticed some project hosting a stack overflow -like thing | 23:25 |
| drobilla | It would be great if people'd use something like this for LV2 stuff | 23:26 |
| * drobilla loves him some downvotin' | 23:26 | |
| drobilla | Basically ANYTHING non-real-time would be REALLY great | 23:26 |
| falktx | a phpbb forum! | 23:27 |
| drobilla | Okay, well, ANYTHING less lame than that | 23:27 |
| drobilla | :) | 23:27 |
| falktx | a reddit subreddit! | 23:28 |
| drobilla | what the heck was that project... | 23:28 |
| falktx | /r/lv2 ? | 23:28 |
| Anchakor | phpbb is so bad | 23:28 |
| drobilla | I guess question things like http://askbot.org/en/questions/ don't really do discussion | 23:29 |
| *** Gethiox has joined #lv2 | 23:30 | |
| drobilla | I really think it would help LV2 to have more shiny and community going on. Maybe the top level trac needs to die, even. | 23:30 |
| drobilla | What we need is sufficient popularity to be able to outsource this to quasi-hacker types who aren't about to write a bunch of C anyway :) | 23:31 |
| drobilla | I don't know. I design archictures, not PR. I am so mega bad at this. | 23:32 |
| drobilla | architectures* | 23:33 |
| Anchakor | well such people aren't going to write some amazing dsp code anyway | 23:34 |
| drobilla | Right. It's questionable whether a shinier public face would actually result in anything tangibly better anyway. | 23:35 |
| drobilla | Ultimately LV2 was explicitly designed as a framework for Those Who Can to be able to do what they want | 23:36 |
| drobilla | Which is more or less how it's used | 23:36 |
| Anchakor | yeah, mission successful so far | 23:38 |
| drobilla | More or less. Complainers always gonna complain :) | 23:38 |
| drobilla | We didn't do everything right, that's for sure. | 23:38 |
| drobilla | ... but we did it | 23:38 |
| drobilla | I guess if I hung around user lists and such more I'd get more enthusiasm and less constant criticism and hate | 23:39 |
| drobilla | They don't care about the how at all | 23:39 |
| Anchakor | groundbreaking would be if ingen was running on windows, inside windows DAWs and hosted lv2 plugins, this would make windows geeks make lv2 plugs to make their modular synths | 23:39 |
| drobilla | Anchakor: I do like the idea of briding into other plugin specs | 23:40 |
| drobilla | VST makes this way harder than AU though | 23:40 |
| Anchakor | hmm I thought VST was pretty dumb | 23:40 |
| drobilla | Portability is important, large part of the reason I've been trimming my external dependency fat | 23:41 |
| falktx | vst is very limited, which is a good thing sometimes | 23:41 |
| Anchakor | it probably needs fixed number of ports right? | 23:41 |
| drobilla | IIRC it's because AU has a dynamic discovery mechanism and VST does not, so you'd have to statically wrap | 23:41 |
| drobilla | I could make ingen talk over a socket and run as a VST easily enough though | 23:41 |
| Anchakor | you could make 4x4 in/out ingen VST free and 12x12 paid for to finance your development :) | 23:42 |
| drobilla | Yeah, I probably could have lived off it somehow if I actually tried | 23:42 |
| Anchakor | though probably in windows DAWs you don't usually need more then 2 stereo inputs and 1 output and 1/1 midi in/out | 23:43 |
| drobilla | If you want actual money, OSX is more lucrative | 23:43 |
| drobilla | Plenty of people use Windows........... in their mom's basement and aren't giving you shit | 23:44 |
| falktx | windows is filled with piracy | 23:44 |
| Anchakor | that's what I imagine too :) | 23:44 |
| falktx | even big "musicians" use pirated software, it's very sad | 23:44 |
| drobilla | Mac has a much more paying-friendly culture | 23:44 |
| drobilla | I'd rather crowdsource development than try to sell software though | 23:45 |
| falktx | well, to get a mac you have to have good money first | 23:45 |
| drobilla | Ultimately I don't really agree with the latter anyway | 23:45 |
| *** edogawa has quit IRC | 23:46 | |
| drobilla | Well, sort of, but ultimately if you're going to drop $thousand-something on a computer, it can be a mac, and very often is. | 23:46 |
| drobilla | (and with anybody seriously producing music, very very very very very often is) | 23:46 |
| drobilla | Anyway, as far as Ingen goes, being released for Lignux first kind of needs to happen before any of that :) | 23:47 |
| drobilla | LAD doesn't pay me, grad school does, so grandiose full time efforts like that aren't happening. | 23:48 |
| Anchakor | yeah, good luck with that and hope you get more free time :) | 23:48 |
| drobilla | Making an LV2 "SDK" by mashing all my libs into one tarball would probably help on other platforms quite a bit though | 23:48 |
| drobilla | Well, I have all the free time I want. Spent all day today on this crap. | 23:49 |
| drobilla | It just contributes to the washing out and/or never graduating bank account. | 23:49 |
| drobilla | I don't think I want an academic job to begin with. It's hard to care. | 23:50 |
| drobilla | Buuuuuuuuuut making money on FLOSS gets back to the PR thing | 23:50 |
| drobilla | "Hi, community! I'm that asshole you may have heard of! Give me money!" | 23:51 |
| drobilla | Maybe Dr. Asshole would get more, heh | 23:51 |
| Anchakor | I'd rather get a job with flexible hours and good-enough-to-get-by pay | 23:54 |
| drobilla | Anyway, pretty sure focusing on actual deliverables is the correct approach to any and all of the above | 23:54 |
| Anchakor | yeah | 23:54 |
| Anchakor | shame the faust guys halted their efforts | 23:54 |
| drobilla | hm? | 23:55 |
| Anchakor | that looked promising | 23:55 |
| drobilla | Albert was talking about moving to atom just the other day. Is upstream faust itself dead now? | 23:56 |
| Anchakor | hmm maybe my impression is wrong | 23:56 |
| Anchakor | I thought I read someone say something about it being abandoned | 23:57 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!