Interesting factoid: modern guitar effects typically have their input jacks on the right-hand side, and output jacks on the left. In this article's guitar rig diagram, the jacks are reversed, but this is accurate: back then, for whatever reason the jacks were reversed on each of these pedals. Modern reissues of the round-enclosure Fuzz Face pedals preserve this pattern despite the reversal of industry trends.
the ergonomic advantage of left-to-right is that most players use right-handed guitars, so the guitar's cord comes out the right side of your body, and it's most ergonomic for it to be directed straight away from you to the right side of your pedal board, not criss-crossing in front of you towards the left side of your board.
>criss-crossing in front of you towards the left side of your board.
No need to criss-cross the cable in front of you, you can connect the cable to the guitar on the right side and the cable will go behind you and emerge on the left side, into the pedal board/fx processor.
With your cable in your right hand, it is easier to plug into the right side of a pedal. If you were to try to do the equivalent with your left, the guitar neck would be a little bit in the way as well.
Typical modern practice would be to have a pedal board with all interconnects and power set up and fixed. Hendrix didn’t do that, but EVH did. And now the internet is full of people posting their pedalboards (P&W people especially).
But you still have to plug in from the right with the guitar cord, and from the left for the card to the amp. So I dunno, my theory may be bogus. But this pattern got established very early on, by the late 60s st the latest.
Sure! I'm referring to setting up a1111's stable diffusion webui, and setting up Open WebUI.
Wrt/ a1, it worked at one point (a year ago) after 2-3 hours of tinkering, then regressed to not working at all, not even from fresh installs on new, different Linuxes. I tried the main branch and the AMD specific fork as well.
Wrt/ Open WebUI, it works, but the thing uses my CPU.
Conda manages binaries and their native dependencies together, including shared libraries[0]. This offers significant advantages over uv and pip when distributing packages with C extensions, such as dependency resolution that accounts for shared library requirements, and better package isolation.
The PyPI ecosystem can not, for the foreseeable future, replicate the scope of the conda ecosystem. From microarch builds to library deduplication, conda is a more general purpose solution. That doesn't mean that one "wins out" (and, for reference I predominantly use Python's PyPI), but they're not the same tools.
Does PDM manage C/Fortran library dependencies? IIRC conda was the only solution for managing both native and python dependencies but I haven't really looked elsewhere.
With wheels and the manylinux specifications there's less of a usecase for that, but still could be useful
Numba is a great option for speeding up (vectorizing) loops and NumPy code, apart from CuPy and JAX. Xarray is also worth trying for tensors beyond 2 dimensions.
true, a nice jit compiler solves a lot of the problems mentioned in the article. These days i often use jax.jit for the gpu support and numpy like syntax with the added benefit of fast loop constructs.
reply