Though it does get a little funny, when you want to write org mode code blocks, that contain actually org mode code. If I recall correctly a "+" at the beginning of the line is then used for escaping?
I've not had time to explore fully, but I just cracked open emacs on this windwoes machine, and tried it, and it auto-added a comma to the beginning of a nested #+BEGIN_SRC...
I have been 'enjoying' this with Debian on a PC with a 1080Ti nvidia card, which is no longer supported by the nvidia v590 + drivers. I've had to pin to v580, but the whole "oops, I updated, rebooted and 'look ma, no high-resolution anymore'" got tired really quickly. You have my sympathies.
EndeavourOS is apparently Arch-based so I've got no useful suggestions for fixing there, sorry.
Gaming is all well and good, but I'd be interested to hear of experiences with moving and using Audio apps (Ableton Live, Cubase and other Steinberg apps, plus many VSTs) from Windows to Linux.
I see Wine, YABridge and LinVST mentioned in searches, but while I've got plenty of Linux experience, I'm time-poor and would prefer to make computers make noises rather than spend my time making things work. I have Reaper which is cross-platform but again, getting the VSTs working would be great (at a bare minimum).
A Mac is not an option here. Any pointers gratefully received!
> but I'd be interested to hear of experiences with moving and using Audio apps (Ableton Live
I've been using Linux for work and hobbies for more than a decade at this point, mostly Arch Linux, some CachyOS, but always had a partition of Windows available too. Why? Almost solely because Ableton does not run properly with Wine, Proton or any other tooling, and has never been able to do so, for as long as I've used Ableton (since version 8 or 9 I think).
If you spend most of your day with Ableton, then Linux is not ready for you, and then I'm not even considering plugins or what not, just the default and standard stuff is not running properly no matter what you'll try.
right - same here WRT windows partition. Not always using Live, but it gets used when it's necessary. I'm slightly disappointed that they haven't done the decent thing and released a Linux version, but .. ah well, what can ya do hey?
I'd be willing to shell out for a new license if they need that for making a Linux version... I guess next step is to fund some FOSS developer to actually add support for it to Wine, by force if must be :P Wonder if there is some way for developers to raise money for adding support for specific software to Wine? Might not be such a a bad idea.
I can't speak for DAWs but in 2019 when I tried switching to native Linux my Scarlett 2i2 3rd gen USB audio interface did not play nicely with Debian at the time. I'd get an endless amount of crackles and pops during recordings / playback and I spent days going over tons of audio configs / tools (Jack, Alsa, PulseAudio, etc.). They weren't xruns, at least Jack wasn't reporting them as that. Buffer sizes were normal too.
The good news is the same interface today works fine with PipeWire, without needing to tweak anything. I am using Arch this time around.
Yeah, these days the Scarletts are fine (as is the aging Firewire connected Edirol FA-101 I've got attached). Non-DAW things such as Supercollider work fine, but I focus less on that sort of environment (which isn't a dis - SC is great!).
I love how windows-linux discussion is populated by DAW/VST incompatibility. I'm still new to the industry, and therefore also open minded about daw/plugins.
I actually had good experience with setting up yabridge, it could have worked for me I think. But the elephant in the room is that many big commercial plugins use JUCE as a framework, and the recent release of JUCE (JUCE8) just broke compatibility with wine and seem to be sabotaging wine-based usage completely, and are not considering going back at the moment.
There are patches based on binary diffs to JUCE7, but it is just so much pain to simply run the commonest plugins in the field :/
So I'm now kind of stuck between using windows with commercial plugins or use linux with mainly smaller scale alternatives (although there are good ones: lsp, decent sampler, cardinal, surge)
Thanks! I wasn't aware of the JUCE newer version issue.. I'll have to (sometime) dig into that a bit deeper. Me I don't mind the idea of the smaller-scale alternatives, but having to occasionally work withothers that aren't linux based could be.. problematic.
I use Reaper for Linux and love it. Getting Windows VSTs to work is okay with lin-vst and wine. Bascially install wine with your package manager, maybe run winecfg, then get lin-vst and make a copy of its single so-file, named the same as each vst binary in the same directory, then add that dir as a vst location in Reaper. As far as I remember.
> I'm time-poor and would prefer to make computers make noises
Then Linux is not for you at this point. I don't mean to discourage you - for me, Reaper works, Scarlett works, ffmpeg works etc. But there are quirks. Reaper has horrible scaling on 4k screen, which I believe can be resolved by forcing UI scaling, but this requires change every time I switch from laptop to external monitor, so I just live with tiny buttons. Scarlett works, but requires JACK, and I never got it working properly with Pulse/Pipewire (outputs get duplicated sometimes), also control software doesn't exist, aside from one opensource reimplementation, which works but looks horrible.
More seriously, my understanding is that the octopus retina does not have color receptors, just aggregate light, I.e. brightness.
But the octopus practically has a sub-brain behind each respective eye, and the eye brains can extract color from the slight lensing differences across frequencies.
They are amazing magical creatures.
Taking that approach, and some sort of ocular lathe, and we can fix this.
Emacs user here, and the whole "electric-mode" stuff (for matching parens or other balanced pairs of things) I find really quite useful. And closing a pair is usually something like shift+enter, which is quite simple (but also - at least in Emacs - generally completely configurable). I think the benefits outweigh the pitfalls, personally.
Can't speak to other editors though.. I don't want to sound like I'm trolling, but they generally feel quite clunky, compared to Emacs (ducks, runs ;p )
There's nothing wrong with emacs. Both vim and emacs are just targeting different segments of humanity, that's all. Vim is clean, concise, slim, where as emacs is more bulky, cluttered, stifling.
It's just matching, and reflecting the way different humans think, and reason, that's all.
During Covid, my son (who is deaf and attends a deaf school) has issued masks with transparent windows at the front, especially for assisting with lip-reading for deaf users. This is in Switzerland though - I don't know if this innovation reached across the Atlantic ;)
They honestly do sound quite interesting, and if I could fork myself off a few times to look at fun & interesting things, this GreenArray stuff would be in the list ;)
I 'learned' Forth decades ago (on a Sinclair ZX81, so essentially a quite horrible experience), and tripped over it again recently.. ending up ploughing through the books "Thinking Forth" and (currently) "Starting Forth" both of which are extremely interesting and so very very different to what we use these days. It very much fits into that saying "A language that doesn't change how your think about programming, isn't worth knowing". I realise now just how shallow an understanding of Forth I had as a teen, back in the day ;)
But I think the win here - these days - for Forth is in things like "running on small embedded devices".. I'm looking with interest at some of the activity around say Arduinos and am thinking that Forth is a rather nice fit for that sort of system. Have bought a kit, and am looking forwards to some non-work quality time to play further :)
(The Books I meantion can be found online very easily, but you'll forgive them for being written back in a time when systems were _simpler_ to grok ;) )
> I think the win here - these days - for Forth is in things like "running on small embedded devices"
In principle that's not a bad idea, it's just that you're at least 40 years late to the party. FORTH was and propably is used in embedded systems for most of it's existence. Often simply with a minimal text console over UART, that being your "way in". Once you've got that going you can start builing up your system from the inside.
Maybe some stuff are hard to perceive as a teen though. I used turbopascal, had a book, but I could't foresee the value of some types or ideas. Forth can be even more alien in a way.
blah
#+END_SRC
org-mode to the rescue ;p
reply