Two of my own palette designs for #BitwigStudio:

1. #Dracula/#Monokai inspired "Monocula".
2. "Amstrad" which is what it s Amstrad CPC 464 color palette, which was exactly 27 colors, i.e. match with the Bitwig's palette size.

if you don't have #linkedin, #typst is quite awesome for creating a #resume

yay. #TDR-style delta-button for listening what gets compressed for #Bitwig's stock. uses phase inversion for subtraction. #compressor. #audio

took 2 years of bitwig to pay attention to this :-)

new learning from #bitwig: i used keytrack modulator for a long time for fx selector and only 30 minutes ago realized that there is a mode selector on right. makes life a whole lot easier :-) #audio

great, i have #dracula colors available in #bitwig now:

Any good 27 color palette's? only well known palette i know is amstrad cpc palette.

i use dracula in my text editor but bitwig has 27 color palette's. would be nice if these theme designers would define a number of different granularity palette's that are "compatible".

did not get very far but to be continued for sure :-)

making track with #renoise and #ace as only external synth

Palvelimen kuuluisi ilmoittaa, että "sähköposti lähetetään, jos se on tietokannassa", eikä raportoida lähtikö sähköpostia vai ei.

#tietoturva #tietoevry #tkl #tampere

@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.

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 :-)

I actually ended up putting both serial and monitor as sockets along the lines of:

I packed swtpm for the #QEMU build so it does not have to be installed to the system:

https://github.com/jarkkojs/tpmdd-buildroot-external

start-qemu.sh will automatically setup shenanigans so that swtpm will work as TPM emulation host for QEMU.

After build there’s three options:

1. TPM2 TIS/FIFO: output/build/images/start-qemu.sh
2. TPM2 TIS/CRB: output/build/images/start-qemu.sh --tpm-crb
3. TPM1 TIS/FIFO: output/build/images/start-qemu.sh --tpm1

Right, and neither QEMU needs to be installed to the host. I’m trying to sort of construct this in a way that it would become as CI friendly as possible so that this could be in addition used as a CI workload for keyutils.

#BuildRoot #linux #kernel #tpm

And you can easily use it for generating extra wave cycles for saw too...

meaning that the day has come that i can finally fully capture VB-1 :-) people still use VB-1 a lot. it is sort of 303 of vst's. crappiest bass emulation ever but has sort of its own color. one of the first vsts ever released.

"easter eggs" in #Xfer #Serum and #SerumFX

generated documentation starts to look a bit like actual documentation after fixing all the clippy::pedantic errors.i was not aware of this flag until some sent a PR fixing a few of these. not that experienced with the language yet..

only thing that is left is two integration tests for examples in order call this 0.1, i.e. test_sz_to_rzm and test_rz_szm but I need a. stable and idiomatic way to point out to the executables. I guess I could make this happen by injecting stuff through build.rs, right?

after that is sorted out it is good for what i needed it originally for (my serial terminal), i’ll set up github runner for CI (tests + clippy), make the crate release and call it a day. after that not going to do proactively do anything to it except review and merge pull requests.

#zmodem2 #rustlang

I switched to #helix editor because three advantages weight me more than disadvantage of having to learn away for #vim shortcuts:

1. Too much legacy.
2. Too many plugins.
3. It is a varying challenge to install the latest version #neovim, which anyway needs to be done in order not to break init.lua (and that big pile of plugins).

So for the price of few weeks inconvenience I can stop spending time on text editor configuration and/or figuring out on how to install it.

I used #vim and later on neovim fo the period 1998-2023, even before using Linux. I switched to vim in MS-DOS from text editor called #QEDIT :-)