optimization

[tomara-x]

just leaving this here for the future, I can make them much more effecient using function tables (with vectorial opcodes), but I know future csound will probably have pass-by-reference arrays.. something to think about

[tomara-x]

those vectorial ops... 😋

[tomara-x]

ugh! do i do this or just spend the day chilling with additive? the pros are cool:

• gens and vectorial ops to manipulate inputs (maybe i'll ditch the gain in)
• much more efficienter (no array copying) so i'll get more of an urge to mess with longer sequences
• jagged arrays and running multiple instances? eh?

cons:

• it's a new way to work with them, so i'll have to rethink some shit
• more typing? with all those table ops? (but less typing with the gens? depends)
• don't forget, there's no range checking for the vectorials (whole lotta crashes) which brings me to the per-step range limiting.. it's actually pretty easy, but i think it'll look messy

[tomara-x]

instrs instead of ops? hmm, that's cool!

• no step mode (current step is a variable that's readable and writable)
• no reset (same)
• not interp (just edit the table op)
• no limit modes (just edit the index limiting function on the vtable)
• gain can be used or omited (just a vaddv) <- lmao talkin like i know what i'm talkin bout
• i'm thinking about ditching the Q even! hear me out, you can patch and assign the active step based on conditions, same way the gain isn't exactly needed when you can assign/patch the indexes.. i think

[tomara-x]

oh! those things don't seem to be exactly what i thought they were? or i'm messing something up

edit: lmmfao! if kStep == 2 then and thinking it was just one k-cycle

[tomara-x]

bohahahaha! i mean, if you're going for instrument, why not use arrays? 😝

[tomara-x]

that decides it!

[tomara-x]

lol jam 35/36