remotelove

Weird title, sorry. Let me try and explain.

Goal: Convert simple higher level script into a low level logic gate mess. Basically, I want to build my own custom computers in Factorio with circuit networks. I can easily create any type of logic gate that I want, similar to how computers Minecraft have been built, but with more options.

It would be super nice to code in something similar to Python but have it "compile" into clusters of logic gates. Of course, functionality would be extremely limited, but that is OK and I don't need to boil the ocean.... yet...

(TBH, this sounds really close to what I know about programming FPGAs.)

I have two MacBooks that I acquired through two different startups. Both companies no longer exist and I was basically given the laptops. (They have just been sitting in my closet for a few years collecting dust, and it seems like a waste.)

Unfortunately, now that I want to use the laptops as part of a local k8s cluster (or even dedicated music production hardware), I am locked out of wiping the things because they want to connect to MDM servers that no longer exist or have admin passwords that have long since been forgotten.

Since these laptops are essentially "bricked" I have no problems opening them up and attempting hardware hacks to get around this stuff.

Both laptops are in various states of reset or wipe due to previous attempts to reset. (Funny thing, actually. I was personally responsible for locking down one of these laptops at the time they were in corporate use...)

Trash or treasure? I dunno. I am apple-dumb.

I have been attempting to extract the firmware from an HVAC controller board using my Pickit3 and MPLAB X.

It seems that many HVAC controllers are PIC based and most are kind enough to include debug/flash pins. Grabbing the firmware images should be trivial once the correct pins are traced out. MPLAB X will see my Pickit3 and the target MCU, but it fails to pull an image that isn't all zeros. (The "bin" file is a text file with each line noting the start address, followed by 16 byte values.)

I do get an occasional "Target device ID invalid message" but that is usually due to my janky wiring to the board. Once I get that issue cleared, MPLAB will always warn that the debug bit (byte?) is set on the MCU. (That doesn't make sense as the MCU should be running standalone on the board during normal operation.)

Is there some kind of read protection that may be enabled on the PIC? Do I just need to unsolder the PIC and put it in its own dedicated circuit for pulling the firmware?

The one trick that Big Music doesn't want you to know!

I was absolutely struggling when I went to do a final mix after writing everything in stereo. For me, it was a whack-a-mole game: Fixing one problem created ten more, bass was unmanageable, highs tended to blare or everything was a midrange soup and I constantly struggled with frequency cancellation.

Above all other problems, music was not portable. It would sound great with headphones, but became a blown out mess on external speakers.

Mono. Just write everything in mono. If the track sounds good in mono, even just the slightest bit of stereo separation makes it sound awesome!

As a perk, it forced me to learn more about compression and limiting and when it is applicable. If something is inaudible in mono, it's going to sound like absolute garbage in stereo. (It also forced me into EQ'ing nearly every component of a song at first. I am not nearly as aggressive with that now, but again, it opened up new doors that I didn't realize existed.)

Why, oh why, is this technique not pushed more to hobbyists and beginners? Is there a shortcoming that I am not aware of?

Obviously, this isn't a cure-all and I kinda framed this post as a magic trick. Its one hell of a teaching tool, if nothing else.

Yolo.

(Wait, what? This is from 2022??? I have known about CAL for a while, but this glass stuff is new to me.)

3DPN video: https://youtu.be/pkBP_eO-Pug?si=l4__tZwrNDB4qNlU

CAL: computed axial lithography

Researchers at UC Berkeley have developed a new way to 3D-print glass microstructures that is faster and produces objects with higher optical quality, design flexibility and strength, according to a new study published in the April 15 issue of Science.

I am fed up with resin slicers.

Chitubox is about as stable as a drunk on a tightrope, Lychee is bad for engineering models and over-priced if you just want some basic support functions and PrusaSlicer is under-developed. All of these solutions work for different things based on the goals of the user. (For some, Lychee is an excellent value so my distaste is likely not universal.)

What really pissed me off is that support painting shouldn't be a paid feature. You hold the mouse button down and drop a support at specific distance from the last. It doesn't take massive cloud computational clusters or huge storage requirements but yet, money. Fuck. That.

I want a completely FOSS tool that is stable and includes functionality for auto-positioning models and has a full set of knobs and levers for support generation, support painting included.

So, I spent the morning getting a dev environment setup for PrusaSlicer to use as a base for resin-only tools. Over the next month or so, I'll take some time to strip out all the FDM support and get the slicer into a bare-bones state with only the existing resin features. Of course, it'll be on GitHub.

Back to the main subject. I was hoping that y'all had references in regards to anything resin printing: Support placement methods, model rotation optimization, resin strength data, FEP peel force data or anything that could be coded and implemented into a slicer. Hell, even discovering different methods for hollowing an STL would be nice.

Data and strategies for various tools would be nice to have at this point to at least start forming a roadmap for development. (One of the first goals is to integrate UVTools as a snap-in, somehow.)

FDM tools are plentiful because of wide spread adoption. Resin printers still seem niche so printer manufacturers naturally gravitate to writing their own tools for their own hardware in their race to the bottom.

With all of that said, I am actually curious if others would even want to see a project like this kicked off.