her

[tomara-x]

too early?

[tomara-x]

okay the only sticky spots left are: 1) commands and repetition there and how that whole side scales. this is blocking #33 and there's also talk of nom in #76. so that's gonna be taken care of there. 2) ease of communication between audio nodes and data. this is the main focus here. and she's the only way to test

[tomara-x]

• seq curves? or doing the fading in the input nets? (gimme lar, xar, ld, xd, with optional args)
  • hmm i like having direct control over the fading like this without needing to update the seq node
• var change detection is not cool with loading, either mark nums, or update vars a different way
  • we can ignore that for now (or forever) so what if that atomic is being assigned every frame? who cares
• i'd like to try the other way of doing this, non-seq version
  • yeah, building her entirely using nets is so much more versatile, but avoids the issue

[tomara-x]

//         s exp      mantissa
let x = 0b_0_11111111_00000000000000000000001;
let y = f32::from_bits(x);
println!("{}", y);

[tomara-x]

curves are so pretty! attack-release with curvature parameters 78764489effd9b3

[tomara-x]

the idea of sequencing instruments instead of sending data to one instrument is just more flexible (sorry amaranth) csound ftw here

[tomara-x]

open nth kinda does it

[tomara-x]

still not satisfied for some reason

it has some funny feel with fast rates that needs investigation, order of the outputs of monitor, and a reset net op would be useful here (we can use sequence here!)

[tomara-x]

seq is all you need