@ljs @Ljsphotography lol, remembered that there is one thing i'm a tiny bit bitter to intel related sgx :-) while i was doing sgx in 2017 i got job offer from ableton, and i said to them that hold on for a while i need to finish this sgx first. and that while lasted almost 4 years...

@Ljsphotography
thanks it is still just a theme but yeah for this linux bitwig and uhe plugins are definitely sufficient :-)

the reason i believe that dawproject file format has odds to succeed because it make commerrcially sense.It is not uncommon that a song is made with one daw, mixdown with another and mastering yet another. Right now only way to transfer project is to render all stems to audio, which often works but is not very versatile. Even if you render all stems it would be nicer that the same *project* would translate between DAW\s.

also i would not be surprised if there would be some day cloud services to render tracks, i mean it is just another payload/ there is enough business opportunities and money to be made like in tooling, services. it is a selling point for any audio engineer. also, right now only reaper has DAW-wide scripting. with dawproject you can do many e.g. mixing and mastering tasks by editing the project file directly with a script. through this route AI could really make it in the audio industry. consider e.g. cloud service where you could send a dawproject file and it would gain-stage it and send an update project back you.

also that would open a door a whole category of hardware projects. e.g. mpc's of today are almost like daw\s. it would be way more translatable if these advanced sampler workstations would produce and consume the same project format.

@ljs The problem with audio is really neither Linux fault, nor something you can fix by fixing Linux. It is the ecosystem in overall...

I have Bitwig Studio also in my Linux desktop and I draft tracks sometimes with it. It works fine and I have U-he plugins (my favourite plugin company by far). It is nice in a way that options are not countless, and it renders previews fast with i9-13990k. Bitwig's EQ is pretty usable and I have Presswerk, which is pretty decent and versatile bus compressor. Regardless that there are ways to use Windows native plugins I don't mix because smooth user experience is pretty crucial to maintain when making music, to the level that you rather discard all the possible plugins.

In software synths, U-he is by far the best in detail and performance so it is not that huge loss *for drafting*. I would not fully finish a track in Linux but I can get a productivity boost from a limited environment with a equivalent user experience as in macOS (because I use only stuff that "officially" is meant to work in Linux).

To add something more in favour of Linux, Pipewire is an amazing project and Wim Taymans is truly one of a kind programmer :-) Even in macOS you need 3rd party solutions to stream audio/video between the network of apps. In Pipewire this all is built into the stack by architecture.

If I e.g. want to sample Youtube to Bitwig I just route PulseAudio (== pipewire-pulse) to Bitwig with qpwgraph. I'm not expert on Pipewire but I believe that once applications support pipewire directly instead of PA, the granularity will increase fully to per application level but this is already very useful for sampling different sources. Pipewire needs to mature but it is definitely right things done right, as far as I'm considered.

I think also that clap (royalty free plugin format) and dawproject file format are signs of new winds in the audio industry that will also move Linux audio forward (slowly) :-) Clap has been already by quite many DAW's and more recent dawproject format is already in Bitwig and Studio One. It allows to export project from one daw and load it to another daw in the language that they can both interpret.

Like here is a draft of track that i drafted in Linux last week. It is definitely not finished but I can get by far with limited set of tools :-) At this point I would switch to macOS.

@ljs Yeah, I get this. In the end of the day it is best to use what delivers best and least effort, obvious fact easily forgotten :-) I honestly do not want to spend after work any time fixing any issues in any possible operating system... Pipewire is awesome (and in some areas surpasses CoreAudio) though but fixing the audio stack unfortunately does not fix the multi-layered and scattered proprietary hell that audio world is.

Also with stock PC hardware, regardless of OS, I've been constantly fighting with all sort of side-noises RCA connectors are no good for really anything tbh, e.g. try to connect to a proper monitoring system for a mesmerising experience. Even when using USB sound cards these issues arise constantly. Mac hardware has super good protection against this type of unwanted interference. Even using the RCA plug I've never heard a single glitch...

@ljs Yeah, it is also my leisure time computer. Switching between Linux and macOS is my daily work trip in my home office :-) For making music it is really nicely packaged system. I use Bitwig and FL on it and they run perfectly.

I wonder if they've already fixed the security issue with signed kernel extension loader, which could be bypassed in the past because it was not fully implemented in kernel space (i.e. unlike how we handle things in Linux).

As I’ve said in the past, I have a M2 Mac Mini at home. It is useful for ARM64 kernel testing and (non-cross) compilation of kernel in home environment but it is also interesting to compare same tests with my Linux machines and macOS.

How the operating system and CPU cores play together makes me honestly feel that Apple is lost what they should do with macOS. If it is used for anything but real-time multimedia, e.g. raw CPU workloads, it does not really deliver. Apple is shipping general purpose computer of which software internals are optimised as it was a tablet.

i have beefiest M2 with full 32 GB of memory and trying to do a largish build with all CPU cores completely freezes the system or like make the interaction laggy to the unusable level. It is quite ridiculous tbhl. Operating system kernel is expected to do time sharing properly and evenly as possible in 2023.

This is not open source vs closed source issue. It is just bad engineering plain and simple. I mean Windows and NT kernel do deliver well in scalability (and Azure provides strong evidence of this).

For the remaining part up until end of 09/2024 at the university I’m working on enabling stuff in https://sochub.fi/, which is IMHO remarkable being academia driven project.

#SoCHub produces yearly a new bigger RISC-V chip with IP blocks from the partner companies for the purpose different topics where you need a #SoC. If I got it right, they are also beefiest SoC’s designed by #academia anywhere in the world.

#Tampere #University drives the project and integrates the IP blocks to the chip design with their own in-house developed 500 kSLOC tool, partners provide the IP blocks around RISC-V core and eventually they can be used for applied research.

For 10/2024 I’m probably looking for a stable corporate job after windy 2022 in a startup, and this period at the university but plans are then pretty much wide and open.

Is there a a config flag to trigger scripts/clang-tools/gen_compile_commands.py for every build?

For instance, #cmake has CMAKE_EXPORT_COMPILE_COMMANDS for this.

Manually calling it for every build is a glitch if the build is scripted, and tedious if the build is done manually.

#linux #kernel

not going to cover this, i just used it as a reference to create a nu-discoish’s bass sound. also quite happy with the guitar made with @uheplugins #zebra2. i’m going to use these sounds to make a track for a compilation coming from a new israel based freeform #psytrance (or #suomisaundi as it is called) record label. ps. neither autotune nor any pitch correction in the vocal, recorded from laptop mic :-) #audio #musicproduction

for insightful reviews at #amazon checkout mine :-)

#AI can be useful but there is lot of useless AI where well-established algorithm does a better job. Sometimes even completely random from well-chosen distributions can deliver more interesting results than as deep learning is essentially a search engine, which substitutes links with data aggregation. AI is definitely not an #algorithm.

Especially this is true for #audio industry where AI innovation happens in the #plugin layer, which bottlenecks all the interesting applications. The only way it can ever work for audio is in the #DAW layer because deep learning algorithms are at their best for global optimization problems where as algorithms sort out localized problems.

I believe that the next thing for DAW's is scripting languages similarly as #Reaper already has but extended with ways to use 3rd party modules to integrate with e.g. AI frameworks. Before AI revolution it was archaic feature but if AI is moving forward in audio, this development is sort of inevitable...

#musicproduction

@ljs @jani @vbabka I’m trying to convince David (Howells) that we should seed Rust support to keyutils because it is exactly the context where Rust would work out pretty well. It would also provide governance from forks. I’m already putting together patches for this, even tho have not checked yet what David responded in IRC to this idea.

Other benefit is to be able to deprecate old rusty bash based test suite. With that change we could start using something like rstest to build up more comprehensive test suite. Also Rust test suite is easier to deploy to a BuildRoot image to run kernel tests.

These bash/autotools test suites are terrible for any SoC type of stuff tbh. They should be IMHO deprecated in almost any possible project… They also add up to the security risks because less test suite is run, more likely bugs will leak in. The only nicely aged test suite I know is kselftest which packages easily to anywhere :-) It’s not perfect but we should be happy that we have it…

@ljs @jani @vbabka That said I don't think this oreboot is useless. It could be used as basis to glue Rust into mainline coreboot (if that makes sense in a way or another). I just don't believe that it will live on like this... I mean it is a working of proof of concept that coreboot can utilize Rust if they ever want to, and if that ever happens, it would probably make sense to re-use some of this codebase.

@ljs @jani I'd look for places where de-facto stuff is crap or unuseful for modern use. This is why I work on side with my zmodem crate and serial terminal to accompany it (MS-DOS had better terminal apps than anything for Linux). And while ago @vbabka told me about this SUSE employee who does a software TPM in Rust. That makes also a lot of sense because IBM and Microsoft implementations are not up to today's standards (trying to state this politely as I can :-)).

There's really a lot of this type of stuff that would really deserve a rewrite so I just don't get why to focus on stuff that works and is of quality (like coreboot IMHO is). Especially in boot loader you would anyway do tons of unsafe stuff, and the actual malware facing thing is only after that, e.g. SBI implementation in the case of RISC-V (for OpenSBI it really would make sense to enable Rust on side based on experience of tailoring it recently).

I do like Rust but I do not like this "Let's reinvent the wheel... in Rust!"-culture ;-)

@jani @liw even tho i work in low-level i do mostly think what users care of. as a user i don't care if there was boreboot written in BASIC, if it improved my life somehow :-) less compatible fork of coreboot does not really improve my life quality...

I’m not excited about oreboot. Fork is not engineering. Neither is replacing mature field-stressed implementation with immature Rust implementation.

Enabling Rust on side with C in upstream #coreboot would be engineering. This way upstream stays mature but Rust can be used to further improve the implementation.

EDIT: I gave this more thought and here’s what I spammed :-) To put story short I don’t believe this works as a “standalone product” but is still potentially useful: https://social.kernel.org/notice/AdIOdilzP66IevvbCy

#rustlang

I use Bitwig myself too but still envy ReaScript, which would really bring alot to table (and pool clips, which are equivalent to FL/Tracker style patterns).

@polarity Yeah, I mean point was not to say that it is bad. It is of course great if it works for you :-) I just merely see it as a different UI for already existing modulation system, in terms of expressive power, so I would not necessarily take EQ/Sampler as analogy here (actually all you need is sampler and all-pass filters if you really want to go that archaic :-)).

@polarity Might a be bit controversial opinion but I've never really got into situation where I would *need* to use grid. It is because the modulation system already for the most part allows to connect stuff freely.

All "must use grid" use cases that I'm aware of are related just to a device that is only available in the grid, which is sort of artificial.

I'd be happier with Bitwig if it had instead of Grid something like ReaScript, which unquestionably adds to Reaper, or at least I would have tons more use for something like that.