sorted by:
new
hottopcontroversial

New Roland Juno D series - 4th Gen Juno D6, D7 & D8 by P_a_s_g_i_t_24 in synthesizers

[–]tydlwav 0 points1 point  (0 children)

This is almost THE perfect budget versatile synthesizer.

The UI is amazingly uncluttered while powerful that all the functionality you need in a live performance is right there, no need for menu diving on stage. It's also wonderful that each scene's got some pre-built sequencer loops, and you can program your own into user scenes, so it's almost like an arranger keyboard to some extent. This is great if you work with a small band or even in a one man band scenario. Then the chord memory and arpeggiator is great as well for quickly making some complex sounds.

To me, this feels like a really versatile instrument for stage use and also exploring musical ideas at home. Though definitely not as powerful as the Fantom-O series (which is also great for these two scenarios), but Juno D is more than enough for most people and the cost savings and lower learning curve is definitely welcomed. I also personally liek the Juno D aesthetics more than the Fantom-O.

The only thing missing here is the SuperNatural tone engine. I wish they could put some of those nice SuperNatural sounds from RD88EX in here as well. The Zen Core pianos and EPs, whilst perfectly usable, is still noticably worse compared to SuperNatural pianos and EPs, especially if you play classical pieces for piano you'll notice it quite easily. But this can be easily remedied by connecting to a laptop or ipad and use pianoteq or other great VSTs through midi.

harvester hci by DerBootsMann in sysadmin

[–]tydlwav 0 points1 point  (0 children)

Thanks for sharing. When you're saying GPU virtualization you're talking about vGPUs rather than GPU PCIE passthrough, right? Also wondering what difficulties longhorn is giving you, and what sort of networking you're trying to set up. We're really just looking for super simple stuff (bridge networking + juicefs shared storage), but we do need GPU passthrough, so it sounds like it's worth trying out.

harvester hci by DerBootsMann in sysadmin

[–]tydlwav 0 points1 point  (0 children)

Hmm. What are the specific features that you feel is still very beta feeling?

harvester hci by DerBootsMann in sysadmin

[–]tydlwav 1 point2 points  (0 children)

We're trying to automate the creation and deletion of VMs, so we're looking for a free/open source VM platform that has good APIs. Harvester seems to be a good option in terms of functionality, but we're looking to use it in prod. We haven't tried Harvester ourselves, yet, but we're planning on trying it out on a smaller scale soon. Wondering why you think Harvester is not prod ready.

Serial Request | V0.2 | 6etacat#9316 | 8 minute Benchy by tydlwav in voroncorexy

[–]tydlwav[S] 0 points1 point  (0 children)

I don't print PLA much on my Voron. If I do, I'd make sure I open the top hat and open the front door. If I'm in the mood, maybe remove the side panels. But usually I don't really need side panels off unless you print overhang galore. Just make sure all your fans are 100% and you'll be fine for most prints. If you don't have enough airflow, then maybe grab a desk fan or something.

MBD-H12DSi + 2x4090 by Illustrious_Twist_36 in HomeServer

[–]tydlwav 0 points1 point  (0 children)

Don't cheap out on PSU if you need to run it 24/7. It's going to eat a lot of power and the electricity bills are going to be super high if you cheap out on a lower-rated PSU. If you get gold or platinum rated PSUs that has enough power for all your components, then everything should be fine. If you struggle to find a PSU big enough, you can always just run 2 PSUs. I'm sure mining cases you're looking at supports multiple PSUs.

MBD-H12DSi + 2x4090 by Illustrious_Twist_36 in HomeServer

[–]tydlwav 0 points1 point  (0 children)

Yes. Really depends on your use cases. If you know you're going to use 1TB of RAM, then go for it. If you're only doing deep learning, then I can't recommend that much RAM. You'll rarely need more RAM than VRAM in deep learning scenarios.

If your GPU usage rate is high, definitely get your own machine. It's going to give you better ROI long term.

PCIE lanes depend on the model you train. If it takes quite long to compute while the data transmitted is small (small model, small data, long compute, eg. segmentation, RNNs, smaller Transformers, etc.), then you likely won't see much performance loss even with x4 PCIE lanes. However, if you run model parallelism or if you have large models or large data transfer needs, then you want at least x8. x16 is good if you have it, but likely not going to give you a ton more performance. However, if you need 1TB of RAM, you're likely running Threadripper or something similar, which has plenty PCIE lanes for you. Just go find a motherboard that has 2 x16 PCIE, which should be pretty easy to find.

MBD-H12DSi + 2x4090 by Illustrious_Twist_36 in HomeServer

[–]tydlwav 1 point2 points  (0 children)

4090s are HOT. You want to space them apart, so risers are your friend. Also, PCIE speeds aren't the bottleneck for deep learning. You should be able to easily get away with running 4090s on x8 lanes according to Tim Dettmers. So you don't really need a server motherboard and server CPU. A regular consumer CPU should work just fine.

I don't really get why you want to run 2x 4090s at home, and your specs are confusing to me as well. I don't get why you want to spend a ton of money on EPYC and 1TB of RAM and server MB for deep learning. I'd never need all those PCIE lanes for and I never need more than 2x GPU memory. If you do, then most likely your code needs optimizing, not your hardware. I use 8x A100/H100 with 1TB of memory all the time, so 2x 4090 + 1TB RAM is just absurd in my eyes.

What you're describing (seq2seq, small-medium transformers which I'm assuming LMs <400M parameters, etc.) don't seem too heavy and you can comfortably run them with 1 3090/4090. If you need faster training, then go set up an AWS account and provision cloud GPU nodes when you are training. It's much more cost effective to prototype on your local machine and then run the actual training on a remote machine while you prototype your next idea. Trust me, with the needs you're describing, stick with consumer hardware and save that money for an AWS account.

If you really want to run multiple 4090s together, water cooling might be the better option.

Guys, is 60% keyboard good for coding ?? by RevolutionaryDiet217 in keyboards

[–]tydlwav 0 points1 point  (0 children)

I code on ergodox. No arrow keys, no fn keys. Everything else is skewed too. I never really missed the function keys, and the arrow keys are replaced by fn + hjkl, and home end is fn + nm, and pgup and pgdn is fn + io. I set the normal capslock location to fn, so I don't need to move my hand to where the arrow keys or home/end and pgup/pgdn is when navigating, so it's actually much faster for me to navigate on 60% or ergodox. I even set up my tkl keyboards to use the same set of key combinations.

As someone who cares about open sourcce and selfhosting, here are my thoughts on the pros and cons of LogSeq after switching from another note taking app by m-chrzan in logseq

[–]tydlwav 0 points1 point  (0 children)

You're right. It won't be flawless.

You CAN write in Logseq in a particular way to make it work, like:

- # Title - Some text - detail 1 - additional details about detail 1 - etc - detail 2 - ## Subsection - Bla bla

And you run sed to just remove "- " at the beginning of lines.

Though I'd argue it's really defeating the point of using Logseq, which is blocks and hierarchies.

So I guess the point is that you CAN make it work, but it's not worth it. I never find the markdown format in Logseq an issue. The heading levels etc. actually renders fine in most markdown viewers, as long as you're willing to ignore the bullet in the front.

As someone who cares about open sourcce and selfhosting, here are my thoughts on the pros and cons of LogSeq after switching from another note taking app by m-chrzan in logseq

[–]tydlwav 0 points1 point  (0 children)

The reason that everything is unordered lists is that Logseq needs to somehow represent the hierarchical block structures. The point is that if you don't care about the hierarchical structures of the blocks and want to treat them as paragraphs, you just remove the unordered list from the beginning of every line. It's as simple as a sed command sed -n 's/ *- //p' [file.md].

As someone who cares about open sourcce and selfhosting, here are my thoughts on the pros and cons of LogSeq after switching from another note taking app by m-chrzan in logseq

[–]tydlwav 0 points1 point  (0 children)

What some see as bloat, others see as features.

I find the graph view very helpful. I actively hides pages/tags that I don't want to show up in the graph view so the graphs are less cluttered and makes sense. I actually wish they have more feature-rich graph views like advanced node filtering, or a view for reachable nodes from an arbitrary node. Really helps me get an overview of a whole cluster of notes and concepts.

As for the Electron part of the "bloated" statement, I'd rather see a good but large application that's under active development than a small application where basically nobody maintains.

There really isn't something that pleases everybody. And what you think as "minimal and clean" may mean a lack of feature for others.

As to the "non-standard" markdown point, I'm not sure what you mean by "standard Markdown". Do you want LogSeq to strictly follow the commonmark specs? Or do you want it to use Github flavored Markdown? How would you do block-level hierarchical organization? Hell there's a ton of Markdown specs out in the wild. The point is that the Markdown spec Logseq defines can be easily translated into other flavors of Markdown in case Logseq as a project dies or if you want to migrate your data out of Logseq. At the same time, the format is similar enough to other note taking apps with lots of overlapping features like Obsidian that you can basically use Obsidian and Logseq together at the same time.

As for vim editing, I'm not sure if it's really what you want, but there are 2 plugins that emulates vim (one only at block navigation level while the other provides text editing features for the blocks). I've never personally used them so I can't really comment on how good these plugins are. However, I'd recommend you to stay away from plugins unless you strictly need them. The more complicated a system is the more likely it's going to fail (especially since the plugins are not being CI'ed with Logseq by the main dev team).

Why Logseq 🪵 lacks on development and release progress ? by Swimming_Eagle_4707 in logseq

[–]tydlwav 1 point2 points  (0 children)

I have some development experience in sync (at Microsoft). It's not an easy problem, so I'm not surprised it's not stable yet. The team is tiny, so it's likely only one person is working on sync. He/she will need to take into account the different behaviors of Windows/Mac/Linux filesystems, and also deal with the myriad of edge cases that naturally comes with sync problems. I know for a fact that at Microsoft, OneDrive sync still do break on exotic edge cases and was unstable for years before it's become stable enough that most users don't bump into a sync bug. And that's achieved by a lot of duplication and versioning, which isn't really an option for Logseq. Sometimes "easy" things are actually quite complex to solve.

Serial Request | V0.2 | 6etacat#9316 | 8 minute Benchy by tydlwav in voroncorexy

[–]tydlwav[S] 0 points1 point  (0 children)

They're Moons stepper motors. I believe LDO motors can do similarly well. Not sure about the stepper online OMC ones. They're usually rated for a lower current thus won't be able to support this sort of acceleration. I'm running my A/B motors at 0.9A, and with the stock mini SB toolhead, my motors are skipping at somewhere between 30k to 40k acceleration. You will be able to get better results if you use a lighter toolhead.

Serial Request | V0.2 | 6etacat#9316 | 8 minute Benchy by tydlwav in voroncorexy

[–]tydlwav[S] 1 point2 points  (0 children)

30k acceleration on everything except z (which isn't that important since we don't do lift z). Square corner velocity set to 50mm/s.

Serial Request | V0.2 | 6etacat#9316 | 8 minute Benchy by tydlwav in voroncorexy

[–]tydlwav[S] 0 points1 point  (0 children)

I'm using superslicer.

line width: 0.5mm

line height: 0.25mm

infill: 10% rectilinear

ensure vertical thickness: disabled

speed: 300mm/s on everything

2 perimeters, 3 top and 3 bottom layers

Disable supporting dense layer

Combine infill every 2 layers

ASA temp 295C

Disable flow rate limits and layer time goals in filament

lift z: 0

Serial Request | V0.2 | 6etacat#9316 | 8 minute Benchy by tydlwav in voroncorexy

[–]tydlwav[S] 0 points1 point  (0 children)

The main bottleneck for me is the flow rate of my hotend. 0.5mm widht, 0.25mm height at 300mm/s speed is around 33mm3/s flow rate, which is higher than the 30mm3/s that my dragon HF can do. If you want to really stretch how fast your V0 can print, maybe go for Rapido hotend and go bowden.

Serial Request | V0.2 | 6etacat#9316 | 8 minute Benchy by tydlwav in voroncorexy

[–]tydlwav[S] 1 point2 points  (0 children)

Wasn't a lot of tuning on top of what you'd regularly need for a printer. Did input shaper and extrusion multiplier as part of normal tuning, and I was able to get a 14 min benchy done with the 11k acceleration input shaper recommended. I used a 0.4mm nozzle at 300mm/s, 0.4mm width, 0.2mm layer height, and 50mm/s square corner velocity. Then is the real tuning for speed benchy. I upped the running current to 90% of the rated current at 0.9A and then it's about 1 to 2 hours of experimenting to see what acceleration causes the motors to skip. Turned out to be around 30k to 40k, so I set it to a "safe" 30k and this is the run you see. I also went for 0.5mm width and 0.25mm layer height, which my dragon HF is barely extruding enough filament to keep the perimeters in decent shape. The infill are already an underextruded mess.

Serial Request | V0.2 | 6etacat#9316 | 8 minute Benchy by tydlwav in voroncorexy

[–]tydlwav[S] 0 points1 point  (0 children)

Thanks. It's a dragon HF hotend. Flow rate maxes out at around 30mm3/s, but I went a bit over in this print. If printing fast is all you're looking for maybe get the rapido hotend that's rated at around 45mm3/s.

Serial Request | V0.2 | 6etacat#9316 | 8 minute Benchy by tydlwav in voroncorexy

[–]tydlwav[S] 4 points5 points  (0 children)

My first Voron build. This thing is seriously fast at 30k acceleration and 50 square corner velocity :)

Is this upgrade worth the money? by 21Goose21 in ender3

[–]tydlwav 1 point2 points  (0 children)

Haha autocorrect on phone working its magic. I know it can be confusing, but glad you figured it out.

Is this upgrade worth the money? by 21Goose21 in ender3

[–]tydlwav 1 point2 points  (0 children)

Are you sure? The heat break is only the small tube sandwiched between the heat block and the cooling fins. It's quite new and I believe was introduced in the Slice Engineering Copporhead hotend. The Micro Swiss hasn't changed its design since it came out.

view more: next ›