~jaxter184

https://contact.jaxter184.net

Trackers

~jaxter184/tlature

Last active 2 months ago

~jaxter184/jaxtcc

Last active 1 year, 3 months ago

#56 Faust support 2 months ago

feature added by ~jaxter184 on ~jaxter184/tlature

#56 Faust support 2 months ago

Ticket created by ~jaxter184 on ~jaxter184/tlature

Use libfaustllvm to create, manage, and use Faust processors.

#54 Building on windows? 2 months ago

Comment by ~jaxter184 on ~jaxter184/tlature

Tidied up the error message a bit, but since it runs, I'll close this for now. If there's a specific Windows incompatibility, I think it makes sense to make a new ticket for it. Thanks for testing!

REPORTED RESOLVED FIXED

#55 Panic when entering node 3 months ago

bug added by ~jaxter184 on ~jaxter184/tlature

#55 Panic when entering node 3 months ago

Ticket created by ~jaxter184 on ~jaxter184/tlature

View panics when entering a newly created node if it was inserted in the position of an already existing node with a different processor

thread 'main' panicked at tlature-tui/src/app/view/group/mod.rs:62:34:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0: rust_begin_unwind
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/std/src/panicking.rs:597:5
   1: core::panicking::panic_fmt
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/panicking.rs:72:14
   2: core::panicking::panic
             at /rustc/79e9716c980570bfd1f666e3b16ac583f0168962/library/core/src/panicking.rs:127:5
   3: tlature::app::view::group::GroupView::update
   4: tlature::app::view::<impl tlature::app::App>::update
   5: tlature::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace

To fix, I should somehow parse node movement values in the UI, or give blocks and processors UUIDs to verify actions.

#54 Building on windows? 3 months ago

Comment by ~jaxter184 on ~jaxter184/tlature

I'm going to try out rainout

Just kidding, it basically only supports JACK anyway, so I'm just going to sit on jack-rs until something better comes along.

I also tried compiling/running it on Windows, and it seems to barely work, though I wasn't able to get any audio out of it because I forgot to also fix tlature-plugins to also compile on Windows, and I was running out of patience. I think I'm just like cursed or something because Windows always has like 2 or 3 mind-numbingly frustrating issues with it whenever I try to use it, on top of the hundreds of minor frustrations inherent in using Windows. Which is all to say that hopefully this works on your machine, because I don't think I'm going to try this again anytime soon.

That being said, please try it out and let me know if you have any issues with it, and maybe I can help fix them (as long as you're willing to handle the testing part).

#53 org: realtime safety 3 months ago

maintenance added by ~jaxter184 on ~jaxter184/tlature

#54 Building on windows? 3 months ago

Comment by ~jaxter184 on ~jaxter184/tlature

To summarize, I ran into a few hiccups, but it should compile now, and maybe even run if you have JACK installed. I'll probably try it out tomorrow, but for now, the current progress is on the windows branch.

Maybe https://docs.rs/os_pipe/latest/os_pipe/ can help there?

Looking at os_pipe, it seems like it's intended more for the same use case as std::process where it just supplies some extra handles that subprocesses can print to, and not actually changing the behavior of things like println for the current process. capture-stdio seems to do the part where println is redirected, but the function that it is built on (std::io::set_output_capture) doesn't return the original stdout that is needed to print the TUI.

For now, I've asked in the ratatui matrix chat to see if anyone's already gone through this problem before, but until I figure out a solution, I've simply skipped the stdio redirect process, so all stdout and stderr data (both from the plugins and from the TUI drawing) will print to the terminal. For most well-behaved plugins, this won't be an issue as long as they don't print errors. Unfortunately, it seems like an error is currently generated in the ave-maria example project in the reverb plugin (something to do with DPF and events, but I haven't pinpointed it yet). Hypothetically, as long as you're only using ↹lature standard plugins, you should be good to go.

Wouldn't the use of cpal abstract away the underlying audio layer?

Also, regarding cpal, I forgot that it doesn't allow for duplex I/O; that is, it separates the input and output streams so they are read from and written to in different callbacks. Instead, I'm going to try out rainout, which is currently unmaintained, but claims to try to solve the problem of abstracting cross-platform real-time audio.

#54 Building on windows? 3 months ago

Comment by ~jaxter184 on ~jaxter184/tlature

Maybe https://docs.rs/os_pipe/latest/os_pipe/ can help there?

Oh awesome, based on the first paragraph, that does seem like the right place to look. Thanks!

#54 Building on windows? 3 months ago

~jaxter184 assigned ~jaxter184 to #54 on ~jaxter184/tlature