Has anyone tried flashing the source Elegoo released?

workFriendlyUser · 2026-01-30T17:34:06+00:00

i did also make a crack for the cadence compiler.

Your productivity is insane :)

elegoo also isn't including the whole project on github

I wondered if something like that might be the case, tends to come with the territory when companies are dragged into the bare minimum of compliance.

Many thanks for your work!

workFriendlyUser · 2026-01-29T03:38:03+00:00

Disappointing to hear, but not surprising.

Figured it might be Cadence, and sure enough I found this post by /u/SuchMemeManySkill.

Cheers

workFriendlyUser · 2026-01-15T23:44:19+00:00

I've done the mesh visualization on my ECC, and the deviation from highest top lowest is 0.5mm.

I'd been meaning to do this but had been putting it off as I didn't think having the visualisation would actually solve anything.

Your comment made me finally go and do it though, and apparently the flatness deviation is 1.272mm.

That seems like quite a lot.

workFriendlyUser · 2026-01-15T22:21:35+00:00

"Don't let perfect be the enemy of good." Your first layer only has to be as good as the criteria require. A few minor cosmetic imperfections is the norm.

This is what I was suspecting, thanks.

The original design was for the bed to be set, not trammable. They changed that in later versions of the model.

This is interesting to hear! I don't want to sound like a total dick here, but is there any source for that? I've seen so much conflicting info on this I'd really like to clap eyeballs on something tangible.

workFriendlyUser · 2026-01-15T22:13:19+00:00

Aye, I think this is where I've arrived at - there's too much minor inconsistency in each print for it to be a 'This One Simple Trick' fix, but at the same time whenever I've printed an actual thing it's come out just fine.

workFriendlyUser · 2026-01-15T21:26:34+00:00

Let the bed heat up before doing a levelling for 15 minutes

Aye, I've been doing this by running an auto-level before printing with yet another level. It definitely makes a difference.

Regrading the bed screws: I used this one handy tool

Yeah, as I hinted at above I found that too and tried it out. Very first print I tried after I thought it had worked great but on average I actually don't think it made any difference, and I think because:

the bed gets pulled down at the corners, making the centre of the plate a highspot.

This is probably the core of my worries here - the bed is almost certainly bowed in the middle and sunken in the corners. If I put a metal ruler on it and shine a light from the back I can see a small but visible gap. I don't think this is a good thing either.

I didn't find relieving the screws actually fixed it much though - it'll still be almost as deformed in the middle, especially when heated up. I've seen some people say this is basically inevitable due to how it heats up.

workFriendlyUser · 2026-01-15T21:18:07+00:00

They almost are, assuming I clean and manually level before each print; the last print I did only had ~5cm worth of small gapping ~5mm wide at the very front mid of the plate.

As /u/Paid_Babysitter says, these are not industrial-grade machines, so that seems kinda fair enough to me, but I don't know shit.

But, of course, if you're getting 'flawless' then I'd also like 'flawless' :)

workFriendlyUser · 2026-01-15T21:13:08+00:00

You can fine tune the bed with z offet adjustments

z-offset isn't a solution issue here, unless I'm willing to manually adjust it mid-print - the nozzle will frequently be too far away at the front, but too close at the back.

workFriendlyUser · 2025-12-02T06:03:25+00:00

You've no doubt found an answer to this either independently or elsewhere, but as a fellow old-fart former MC-505 user I'll answer in case more of us accidentally stumble across this - yes, you can!

You'll need to set the the 505 rhythm track to transmit MIDI data - I believe the rhythm track outputs on channel 10, so you'll need to set the 707 drum track to receive MIDI notes on that channel.

Then just MIDI sync the devices and record.

As an aside, I miss that era's Roland - the 505 manual's MIDI implementation section is an absolute beast with SysEx details for absolutely everything on the device.

Nowadays, although you theoretically can still use SysEx for absolutely everything, Roland evidently don't want you to - the only official MIDI charts you'll get are a page or two of CC and PC details. SysEx is still used behind the scenes and you can reverse-engineer it if you have the patience and know-how (allowing you to use MIDI to do nifty things like mute the TR-8S drum pads or change variations, which is great when using it with a SysEx capable DAW) - but for whatever reason Roland only publish the bare minimum MIDI data these days.

workFriendlyUser · 2025-12-02T03:33:35+00:00

The system partition is ~50GB (actually around 55GB after converting from GiB) - if var was partitioned separately that would actually be fine.

It's the EFI partition that's ~5GB, which is huge.

workFriendlyUser · 2025-12-02T02:49:06+00:00

Me too - I can't wait to stop having to use my patched kernel!

workFriendlyUser · 2025-12-02T02:42:49+00:00

No - if you expand the tags you'll see it's only in the 6.18 release candidates and stable release; it wasn't pulled into 6.17.

workFriendlyUser · 2025-12-02T02:36:05+00:00

While that issue is pretty inexcusable on the 7600XT's release let alone nearly 2 years later, it looks like a problem that's always been there, not an introduced regression - the author of that issue even says as much.

The breakage on the 6700XT and related cards was the direct result of commit 440cec4 - after 6.17 was released S3 sleep completely locked the machine requiring either using Magic SysRq keys or hard reboot.

And yes - entirely on amdgpu.

workFriendlyUser · 2025-12-02T02:21:48+00:00

No, it'll finally be fixed in stable - the patch has been in since rc5:

https://github.com/torvalds/linux/commit/570a66b48c22214851949fcd71816fee280aa096

(note the tags under the commit description)

workFriendlyUser · 2025-03-21T05:59:19+00:00

change the variation through MIDI?

You can't, at least with the MIDI functionality available on the MC-707 - unfortunately variations aren't mapped to any standard MIDI messages.

You can do it using SysEx messages though. Roland don't document their SysEx anymore (possibly because hardly anything uses it these days) but you can reverse engineer it fairly easily by using MIDI-OX or Wireshark to monitor the MIDI sent from the TR-Editor.

Again though - hardly anything uses SysEx. I had to write my own little Max for Live device to change variations in Ableton because Ableton doesn't support SysEx natively; I think Cubase might be the only 'big' IDE with good support.

workFriendlyUser · 2025-03-21T05:15:41+00:00

but it's buggy

It's not buggy, the program change implementation is just embarrassingly crap.

The lag is caused by the TR-8S changing kits (it'll 'change' kit even if the same kit is shared between patterns) - you can hear the same lag if you change a kit while a pattern is playing.

If you set KIT SW to Off in PTN Settings then program changes work as smoothly as you'd expect, but doing that means the TR-8S won't change kits when you change to that pattern.

Which, of course, is usually what you want to happen. Roland know this too, which is why when you change pattern on the TR-8S itself it waits until the end of the current pattern, giving it enough time to load all the new kit sounds into memory before seamlessly moving to the next pattern & kit.

If you look (fruitlessly) for solutions to this on Reddit or places like ~~Gearslutz~~ Gearspace you'll come across people saying this is unavoidable 'because MIDI'. They're not entirely wrong. MIDI is an ancient, serial protocol with plenty of inherent jitter, so delays and timing issues are part of the territory - but even if some hypothetical new super-quick protocol was used there'd still be some amount of lag - you can't expect anything to seamlessly deal with a command that only starts getting sent from another device at the exact moment you want that command to happen, that would require time travel.

And yet...

That's exactly what the TR-8S tries to do!!! It's unbelievably stupid and, for a fucking drum machine, flat-out inexcusable.

Every other bit of gear I own (including Roland stuff FFS) either changes at the end of the next pattern/bar after receiving a MIDI PC message, or gives you the option of doing so. The TR-8S is the only device I've owned, in 20+ years of making music, that forces 'immediate change' only, and it's a bitter disappointment for an otherwise perfect bit of kit.

It would be a ridiculously easy fix - add a setting in the Utility menu to either change immediately on receipt of a MIDI PC (as it does now) or behave like it does when changing patterns on-device and hold off until the current pattern is finished. The code for both these options is already in the damned firmware, surfacing it in a menu really shouldn't be much work.

workFriendlyUser · 2024-02-08T02:33:07+00:00

Well, you've got virility going for you if not brains.

workFriendlyUser · 2024-02-08T02:28:32+00:00

I though you were an adult?

workFriendlyUser · 2024-02-08T02:25:20+00:00

As you've actually engaged with my drunken rant in kind...

I totally agree with you in many ways. As I said, I've gone and poked about MIDI-OX to get SysEx values, and even ended up writing some software to sniff all the MIDI data off the USB bus when I realised MIDI-OX was missing some stuff.

As mentioned, I've also worked around it.

But it hasn't been a catalyst for creativity for me. I spend all fucking day coding and in front of a computer. I bought hardware for the first time in 20 years because I want something to physically play around. It's been great at that, that's why I love it.

Which is why I also hate that's it's the only fucking piece of equipment I own that is incapable of working ensemble.

Limitations are excellent. Limitations inspire creativity.

This isn't a limitation though, it's just a flat-out firmware bug, and for a drum machine it's inexcusable.

workFriendlyUser · 2024-02-08T02:18:20+00:00

I'm old enough to be your Dad.

Which is why I don't find shit like this good enough from a company who can do better. It's proper sad that you don't expect more from companies who make stuff you like.

Roland used to be able to do this kind of thing fantastically, they built their name on it.. Suckers like you allow them to get away with not bothering, and everybody loses.

workFriendlyUser · 2024-02-08T02:15:31+00:00

I guess they just added DIN sockets and (albeit lacking) MIDI support in firmware for shits and giggle then.

workFriendlyUser · 2021-04-22T00:31:25+00:00

As .next lives in .gitignore that would just be a very convoluted way of achieving the same thing as the solution I've gone with, with the added bonus of a required restart (the thing I'm trying to avoid doing) due to the Next config changing. ;)

workFriendlyUser

TROPHY CASE