device settings

[tomara-x]

need to study some cpal for this

• changing output device
• sample rate
• buffer size
• channels

can this be set in out()?

[tomara-x]

i was a goofball

[tomara-x]

so now we can store the stream (and start a new one replacing it) also we bask in the light of jack

https://github.com/tomara-x/quartz/tree/output-tests

now need to figure out a way to select devices (i'll leave settings to them, for now at least)

[tomara-x]

alright! :od (out device) command.. jack is a little crashy for some reason, but it's not me 🥰 i love crashes i didn't cause!

[tomara-x]

something is funky with tuning (sample rate issue)

[tomara-x]

• does set_sample_rate propagate to the inner nodes?

  • yes, calling it on slot will call it on the nodes in there, and calling it on net will call it for each node in the net.. so why does this happen? let me repeat that.. WHY DOES THIS HAPPEN?!

• why is jack's sr still 48k even after i change it from its settings? shouldn't default_output_config read the settings from the device? or is that some predefined default?

  • that's my jack settings refusing to change sr, has something to do with alsa [pipewire i think]

[tomara-x]

remove set_sampling_rate on the slot? this way it can be set using sr() ^ tried that. tried hardcoding an sr, tried removing the bigblockadapter, and nothing prevents it from happening. for some reason running on jack outputs higher frequency.. is this even related to sr?

aaaa! sr works on the nodes as is! that's the mother of all "why tf does this happen?" i have set_sample_rate being called on the final slot, yet somehow passing a net through an sr() changes its sr

69da7eb removed it.. so much questions 😔 matching the device's sr (sr() before out()) so in jack's case setting it to 48k makes it work correctly (no detune). this and the fact that sr() worked on output even before that commit tells me that for some reason the set_sample_rate in the run function didn't work at all

[tomara-x]

ohh! i'm a goofball of unprecedented proportions! the run function is only called once the stream is constructed. so the slot (containing the initial dc(0) nodes is set_sample_rateed. but after that we set the front end of the slot to other nodes and i don't think that those nodes will have their sr set.. gotta test

[tomara-x]

yep

use fundsp::hacker32::*;

fn main() {
    let (mut slot_f, mut slot_b) = Slot32::new(Box::new(sine_hz(1.)));
    slot_b.set_sample_rate(1.);
    for _ in 0..10 {
        println!("{:?}", slot_b.get_mono());
    }
    println!("");
    slot_f.set(Fade::Power, 0., Box::new(sine_hz(1.)));
    for _ in 0..10 {
        println!("{:?}", slot_b.get_mono());
    }
    println!("");
    slot_b.set_sample_rate(1.);
    for _ in 0..10 {
        println!("{:?}", slot_b.get_mono());
    }
}

out

``` -0.0514355 -0.0514355 -0.0514355 -0.0514355 -0.0514355 -0.0514355 -0.0514355 -0.0514355 -0.0514355 -0.0514355 -0.051435508 -0.051719557 -0.0518617 -0.052003846 -0.052145988 -0.05228813 -0.05243027 -0.05257241 -0.05271455 -0.052856684 -0.052856684 -0.052856684 -0.052856684 -0.052856684 -0.052856684 -0.052856684 -0.052856684 -0.052856684 -0.052856684 -0.052856684 ```

[tomara-x]

this is mambo number 5