writing during yet more FreeBSD port builds must be a theme innit
I also happen to be in my local transit agency's dispatch office writing most of this. Yes, I sometimes dispatch buses, usually for night service so it's often chill enough to do other things whilst maintaining watch. Don't worry, shit does hit the fan sometimes, which means I get to be first to get remedies or corrective action moving. Yes I get monies for this, but more importantly gets me out of the house when I otherwise don't have plans for the week, particularly social or scheming for world domination.
Anyway, here is another episode of…open source despatches.
DJ-BSD
Technically my hardware setup was complete during the drawn-out writing process of the last episode, but I had no idea what I was doing. I still don't know what I'm doing, but at least I figured out how to beatmatch two easier-to-me tracks by ear, after the last episode dropped. Wait, what?!
 |
| "day zero posterity pic" |
Yes, I am indeed learning how to DJ. Despite the computer monitor's presence, it is and will not be used to display audio waveforms like CDJs and controllers/software do. I think phonograph records and turntables are the purest form of this art, even if dialing up digital tracks for the timecode record to control.
So far I've started amassing my first crate of records and playing around with them. Genres for now are all 140-bpm grime and dubstep (specifically not the brostep branch). Once I set up my mixer, the last hardware to arrive, I attempted to mix two grime tracks together (as shown in the pic, if you know you know) and it was an epic fail. Then I tried one grime one dubstep, later both dubstep, even later almost indiscriminately selecting anything that would make sense, all to no avail. First attempts in learning.
I eventually realised that I needed to isolate some percussive element on the downbeat ("the one"). In many electronically-produced genres, following a 4/4 time signature, this would be a snare. With grime, percussive elements are all over the place, vocals included. In dubstep, the snare usually falls on the three, but there are less percussive elements overall so it is easier to pick something. So a few days later, I dialed up two dubstep tracks on the turntables and focused on the kicks starting from the bass drop. DJ Rob Swift, a longtime hip-hop turntablist, calls this "building a relationship". After a couple tries, I had the two tracks synced, so rinse and repeat those exact two a few more times to make sure I really had them. Luck would have it that these two tracks were at the same bpm so no pitch adjustments needed, but if I dropped the second track just a bit off, I would have to nudge the second record forward or touch the platter ever so slightly. It's fun when you start to get it in this manner, even with needed adjustments.
If this was on a controller or CDJ, the former of which would have been much easier on the wallet, I would have gotten up to speed a bit more quickly but with some bad habits in tow. Looking at waveforms to beatmatch would be like using a debugger on a problem program without fully understanding program architecture and control outside of specific code segments. Beatmatching by ear, ie "building a relationship", is exactly that, building a relationship with your program from a total lifecycle standpoint before diving into code at all.
I still need to practise matching before or without any bass drops, because sometimes I do want the intros heard in the mix. I also still haven't fired up Mixxx, the open source DJ program, to enable playing with my timecode records and thus control my digital tracks. We'll see how it behaves with my setup on FreeBSD. To this end, I'll turn it over to an old SEPTA slogan:
 |
| i don't think the gift shop has these to sell |
DankPad omissions and update
I forgor to mention that the DankPad does have on-board wifi. In fact, ThinkPad X13 users get a random selection between three different M.2 wireless cards, none of which I believe work in FreeBSD as of this writing. My machine has the Qualcomm QCNFA765, which on Linux is driven by ath11k(4). Some machines get an Intel AX-series card, which is iwlwifi(4) territory. On FreeBSD, our home-grown iwm(4) driver supports Intel cards up to the AC-series, but anything newer uses iwlwifi(4). Our grand total of one (funded) FreeBSD committer working on wireless support started porting some Linux drivers over along with improving our LinuxKPI in our kernel, but some things are just incomplete:
ath11k_pci0: <ath11k_pci> mem 0xfd000000-0xfd1fffff at device 0.0 on pci3 ath11k_pci0: MSI vectors: 32 ath11k_pci0: wcn6855 hw2.0 linuxkpi_mhi_register_controller: XXX-BZ TODO
At some point I would like to help out in this effort. Funding would be nice too, since this is a hard but lucrative-outside-of-FreeBSD problem space. Let's not forget that I attempted to start porting not one but two Linux Realtek wireless drivers, one for the meme machine's built-in wifi and other for a TP-Link USB 3 dongle, but I stumbled over how to write a new Makefile with the existing C sources. I should build a relationship in that area before thinking about bigger things…
In the meantime my wireless needs are met by another TP-Link USB 2.0 dongle driven by rtwn_usb(4). Ethernet is through a USB 3.0 hub with a ure(4)-driven device at the end.
As for my suspend saga, the "Linux" sleep state, ie S3, BIOS option was the correct one. Our copy of ACPICA does not support S0ix so of course the `hw.acpi.suspend_state` sysctl came up empty when set to "Windows". With S3, the system suspends fine, but resuming is a different story: when I perform the actions in the X graphical environment, the AMD graphics hang the entire system on resume. I should be fine when I suspend in the console, which I have had to do on the other ThinkPad when I change monitor configurations, but again let's see what happens.
setuptools reduction act
I finally committed the setuptools-scm update discussed last time, after slightly tweaking my poudriere (port build automation) setup on the HP air fryer to add a separate environment for build verification runs. There is still some minor cleanup to do, because some Python packages have still not adopted PEP 517, and the latest setuptools-scm only officially works with setuptools versions that exclusively support the PEP 517 method…
…which brings me to why this section title.
tl;dr a long and winding history exists. For those ports still using the old method, direct setup.py execution, setuptools is a build dependency but also a run dependency. The latter part, in a blanket sense, is wrong. The only reason why setuptools would be a run dependency outside of a Python package build context is when the package uses the included pkg_resources, which itself is deprecated and replaced by other modules. Further, setuptools itself deprecated direct setup.py execution in version 58 and unsupported after, so all ports using this method will eventually specify setuptools 58 specifically. Two setuptools versions cannot exist in the same environment, at least not in the same Python distribution as they call it. The work is cut out twofold: an experimental build run to see how all ports using direct setup.py execution behave after removing the setuptools run dependency at the framework level, and finding individual ports that explicitly specify the setuptools run dependency.
