I have been attempting to dive into Rust for years now and mostly only accomplish keeping up with "This week in Rust", and cloning GitHub projects and running them. Is there a community preferably also involved with Ratatui that I could join to get some support and learn more?

I have one, i currently making a ascii image shower, so in my terminal app, you can see the ascii image inside a block with borders, the problem is, if the terminal size is too small, the ascii image wont shot 100%, how can i make the ascii images responsive?

@@sponkurtus2597 you would have to determine the viewport size with the rendering function, then adjust the size of the image appropriately before rendering it out.

any idea how to use dbg!, print useful values, etc?

@@Iris-jw3ci well you can’t directly use print macros because they would print to stdout/stderr. However, you could use a Paragraph widget to display arbitrary text upon calling a function, which you could format with the fmt macro.

Do it buddy and share the link 😊

Do it!

Ratatui is dope but you should also check out Bevy for the ECS for games. I believe they have terminal app examples as well.

I was thinking really old school, text-based adventures, with this as a HUD showing the current scene, the characters possesions and status, and a place for descriptions, decisions, and conversations.

I'm glad you found a crate that worked for you!

yes it is immediate. It expects you to build every widget on every frame. They also note that the overhead of this is usually negligible compared to the overhead of the terminal emulator.

Stateful widgets are an existing feature but are pretty limited at the moment. Generally, it uses immediate rendering.

I actually had never uploaded it, but just went and found the directory today github.com/rust-adventure/yt-ratatui-audio-viz/tree/main There's some extra files and whatnot since I was starting to move towards using wgpu iirc, but the core program seen in the video still works. use cargo run.

I'm going to assume you mean +100 because -100 would make it even lower. I didn't do that because 100 is a totally arbitrary number. Why not 75, or 125? and it results in arbitrarily cutting off the data. The problem was that the dBFS level for an f32 sample is between -758 dBFS and 770 dBFS (you can read more about that here: www.sounddevices.com/32-bit-float-files-explained/ ), I had to fit that into a u64 to graph the sparkline. Doing .abs() loses the least amount of data without needing to pick an arbitrary cutoff. I could've also lerped to get a value from 0-1 but I didn't think about it for more than a second because it wasn't important to the project as long as I could represent any data that came in.

@@chrisbiscardi I meant subtract the value after absolute from whatever the minimum was for noise floor which i thought you said in video was -100, so 100-abs(-100) would have been 0, just felt like such a minor thing to miss out on fixing :) really great video nonetheless

@@cchance yeah, the way the audio interface I have works, is a self-noise level of -127dBu (which isn't necessarily the same as dBFS), and it contains what I'll refer to as "two sensors". It switches between them to capture the full range its capable of and is an 32-bit float recorder, so it doesn't have "gain" in the same way as a 24-bit recorder. This means it doesn't clip, but also means it can amplify up or down the signal in whatever manner without affecting the actual data. So I could get a different level signal coming into the computer if I was recording something much quieter or louder. That's why I went with something more like .abs(). Its more important for me to be able to not lose data, since this is just a debugging visualizer, than to have a low-to-high graph.

Nightowl

@@chrisbiscardi thanks