Now's a great time for people to get into the free Kontakt library scene, even if you don't own a Komplete Kontrol keyboard. Since loading a Kontakt library without OCR is accessible on both Mac and Windows, you can avail yourself of some killer freebies such as this new drum kit from Fracture Sounds.
Reaper users especially take note.
There's a plethora of free-to-use instruments that run in Kontakt player, so you can enjoy pianos, strings, drums, bells, a fantastic Rhodes plugin, all sorts of goodies.
The free landscape has honestly never been as good as it is now.
Thomas Depierre
in reply to daniel:// stenberg:// • • •Thomas Depierre
in reply to Thomas Depierre • • •daniel:// stenberg://
in reply to Thomas Depierre • • •mort
in reply to daniel:// stenberg:// • • •This is my biggest worry too: they essentially copied the NPM package management model and practices. Good for short term productivity, but I worry that it causes significant long-term maintainability problems.
And everything is version 0.x, in part due to technical limitations of Cargo: moving out of 0.x is a breaking change, so if you have users on 0.x (which Cargo encourages by adding semver compatibility rules which make 0.x.a compatible with 0.x.b), moving out of 0.x breaks them.
Thomas Depierre
in reply to daniel:// stenberg:// • • •i mean yes, but at least the compiler is a tool.
While C and others are uh. Well some are finally realising they have users
Stefan Eissing
in reply to daniel:// stenberg:// • • •Andre Weissflog
in reply to daniel:// stenberg:// • • •synlogic
in reply to daniel:// stenberg:// • • •Frederik Braun �
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Frederik Braun � • • •Frederik Braun �
in reply to daniel:// stenberg:// • • •Well, it seems that your point is "Firefox consists of bad code", whereas I believe that the conclusion from the post should be "The library is bad code, which is why we are not using it in production. We'd be happy to look at their rust implementation, when it's possible"
(footnote: "bad code" being an abbreviation of "100k multi-threaded C++")
daniel:// stenberg://
in reply to Frederik Braun � • • •@freddy you're reading too much into my words. I'm just amazed by how large the existing JPEG XL decoder is.
And I don't think I am alone.
Frederik Braun �
in reply to daniel:// stenberg:// • • •Oh, OK. Sorry for misreading then. I'll back off. 🙂
(And yes, the existing library is... 🤯)
guenther
in reply to daniel:// stenberg:// • • •@freddy
and "uses" in this case means "has it available behind a feature flag in their nightly builds, and does not ship it to normal users because of this very issue"
DamonHD
in reply to daniel:// stenberg:// • • •We had 100kloc C++ in a smart radiator valve that saved a bunch of extra energy.
I think it is just a reflection that extracting efficiency requires complexity.
Daniel
in reply to daniel:// stenberg:// • • •David W. Jones
in reply to daniel:// stenberg:// • • •How many of those lines are for handling security issues such as boobytrapped JPEGs?
How many lines do the other HTML rendering engine use for the same function?
The graphical web has many sins to make amends for!
Andreas Rosvall
in reply to daniel:// stenberg:// • • •See flak.tedunangst.com/post/on-bu… by @tedu for the current state of the art method of decoding jpegxl safely, which is both hilarious and sad.
tאmáš
in reply to daniel:// stenberg:// • • •Wait, so JPEG XL isn't completely dead? That's probably not what you meant to communicate but I'm so happy to hear that
fwiw I think that LOC of the reference implementation doesn't really say anything about anything - even if Firefox "adopted" it, which feels like a sensible choice given the state of things
supersingular
in reply to daniel:// stenberg:// • • •tht 🇧🇬
in reply to daniel:// stenberg:// • • •Julien Avérous – 🇫🇷🇪🇺🇺🇦
in reply to daniel:// stenberg:// • • •xs4me2
in reply to daniel:// stenberg:// • • •Handler Skyler
in reply to daniel:// stenberg:// • • •Stefan Scholl
in reply to daniel:// stenberg:// • • •browser vendors should coordinate which subset of JPEG XL they want to support, and only this part of the standard needs to get implemented.
I remember JPEG and that you could never use progressive JPEGs. Some programs even offered an “export for web” feature so that you wouldn't use any unsupported JPEG features.
Even Rouault
in reply to daniel:// stenberg:// • • •- JPEG: libjpeg 6b encoder+decoder: 24,200 lines of C
- JPEG: libjpeg-turbo encoder+decoder: 127,000 of C and ASM (multi architectures)
- JPEG2000: openjpeg encoder+decoder: 50,000 lines of .C
- JPEG2000: Kakadu commercial encoder+decoder: 214,000 lines of C++ (only coresys component)
- libjxl: 150,000 lines for the core library, encoder+decoder (deps excluded)
(All above includes blank lines + inline doc)
So this is pretty much standard for a modern codec
daniel:// stenberg:// reshared this.
Waltteri
in reply to daniel:// stenberg:// • • •Expired Token
in reply to daniel:// stenberg:// • • •