falktx @falktx@mastodon.falktx.com

FYI I am updating KXStudio peertube instance, in order to try out the livestream livechat feature.
Will be temporarily unavailable!

Here comes another release.
This time it is a bugfix for our dear Carla, now at v2.4.2.
https://kx.studio/News/?action=view&url=carla-242-has-been-released

Should have been earlier, but there were a couple of things I wanted to verify first. With Carla being used now in Cardinal and Ildaeil projects, I found a couple new issues to solve which delayed it too.
But it is tagged now, enjoy! :)

@unfa Not sure if this will be readable, but I am uploading how it looks for me.
This is just a terminal with irssi which I have running remotely, so I am always logged in, thus have history. I only need a terminal and internet connection in order to go talk on IRC 😊

@unfa
Not being able to fix typos or send screenshots is quite intentional. you cant do that either with raw text emails, and people still use it on a daily basis, using references in whatever style they prefer, either inline or as [1] and [2] etc.

Now the lack of history is both good and bad IMO. Sometimes you do not actually want history, if conversations are meant to be a volatile thing.
When we really need history on IRC we just setup something dedicated for it. Either a bot or a bouncer.

@unfa it is all a question of finding the right tool for the job. on IRC you can create as many channels as you want, so for example there is #lad and #lv2 for development, #cardinal and #kxstudio for those specific things, etc
You can DM people if you rather only talk to them of course. If there is a lot of people talking at once, just wait a bit until topic clears, and then have your turn.

Still early days, but finally got some sound out, even if choppy and unstable.

One day my full suite of tools will run on Haiku, we are not there yet, but we are one step closer.

Go Haiku! 🚀

After Cardinal got all the attention, now come releases of the little things that got a bit side-tracked.
First, WineASIO 1.1, just to get it building and running with latest Wine.

https://kx.studio/News/?action=view&url=wineasio-v110-released

More to come soon!

@obsoleszenz @unfa tbqh for myself I dont need any of those.

@unfa tbh all the alternatives are quite crappy.
not to mention having terrible terms of service and privacy policies.

you know that mailing lists and IRC is what linux kernel developers use, right? it has been working for them for many years

some of the things that come from the new platforms/services/etc, like emoji, images, videos, etc are things not everyone wants.

@FriendofBernie in any case, this is not the place for such discussions. open a ticket and we can talk there

@FriendofBernie @unfa you know it is in the archlinux repos already, right?

if you plan to build it yourself, better to try to understand the process a bit first. trying to build without "make" is just.. well you wont be able to build much at all of anything.

I dont use arch, I cant help there, you are on your own when building software. IMO users should not be doing that really. if you are not a developer in any way, trying to build things results in a bad time as you dont know how to fix it

@guenther ok, so just rumors as usual. would be great to not spread them around as if they were fact though. it has never been officially confirmed as far as I know

@guenther do you have a source on this?

This is madness https://hacks.mozilla.org/2022/02/version-100-in-chrome-and-firefox/

@gcrkrause @unfa it is nothing new exactly. and they always had this stance anyway.

even their GPLv3 license is unclear if is even valid. they require extra work which is unenforceable by GPL rules. when asked for comment they say nothing back.. :/
I went to ask JUCE devs since Steinberg is just quiet about it. https://github.com/juce-framework/JUCE/issues/1027

@colinsmatt11 right yes, which is kinda what rust developers are doing. A lot of C++ concepts do not apply to rust, so a pure conversion is not ideal.

I did something similar myself for DPF where I went with a custom API-incompatible implementation.

On both cases the final binary is ABI-compatible with regular VST3. As far as users are concerned, all approaches result in valid VST3 plugins

@colinsmatt11 a pure reimplementation that would just convert the existing C++ code into something else would for sure be problematic, but Steinberg doesn't even want clean-from-scratch implementations.

As far as I am aware, but obviously not a lawyer and all that, implementing something from scratch that targets an existing API is quite okay. No copyrighted code ends up being used.

@colinsmatt11 APIs are not copyrightable, that is enough to handle this whole thing. They still act like they are though.