crow: output querying no longer working

[dndrks]

crow.output[x].query() used to alias get_out(x) and return the current output value (with shaping) back to norns. here's an example of its historical usage.

even if get_out is wrapped in crow.send, the handler isn't registered:

>> crow.send("get_out(1)")
unused event: ^^output(1,0)

we ran into something similar with crow.input[x].query() last year (fix + lines discussion), but i wasn't able to quickly grok how to fix things in this case :/

@trentgill, please lmk if i can provide any additional info / testing! cc: @justmat

[trentgill]

noted -- sorry i always forget to test these norns-specific functions when i'm making updates :/

it is slightly non-trivial due to the way the event handlers for crow are assigned on norns, but should be easy to roll in with the doepfer psu fix.

i guess it was lost at the same time as the input.query, but because it's quite rare to query an output (usually we are just setting them), it must have slipped through.

[trentgill]

This should now be fixed in Crow 4.0.5, though admittedly I have not tested it on norns hardware. https://github.com/monome/crow/releases/tag/v4.0.5

[dndrks]

@trentgill rad rad, all is pretty much working now! just getting some new errors printing in testing while running https://github.com/monome/crow-studies/blob/main/5-contruct.lua

lua: 
/home/we/norns/lua/core/crow.lua:32: [string "norns.crow.events.I(-1.18972norns.crow.events..."]:1: ')' expected near 'norns'
stack traceback:
    [C]: in function 'assert'
    /home/we/norns/lua/core/crow.lua:32: in local 'evalcrow'
    /home/we/norns/lua/core/crow.lua:42: in function </home/we/norns/lua/core/crow.lua:27>

nothing show-stopping, but wanted to mention since it's new! feel free to close this out if this isn't concerning!

[trentgill]

you mean its mostly working but sporadically kicking out these errors? or is always printing them?

i assume its sporadic as it looks like the norns serial parser is failing either due messages being split across multiple packets, or the messages are themselves being corrupted (perhaps overflowing the usb-tx buffer on crow).

i can investigate but will suggest a workaround in 2 ways:

1. firstly there is no need to poll at 100fps when the norns screen only runs at 30(?) fps. as far as i see these values are only used to be visualized. a simple reduction in metro frequency will accomplish this.
2. rather than sending all 4 chans at once, make the for loop run only one channel per event trigger. you can multiply metro speed by 4 to accomodate this. that should avoid any buffer limitations that could be the source of the issue.

i’ll still try and see if i can reproduce onnPC so i can diagnose the underlying limitation.

[dndrks]

yes, apologies -- everything's working, just saw the error eventually print once every run so i though it'd be good to raise. the script itself absolutely needs some touching up, ty for the review + rad fix suggestions!!

i'm good to close this if you are!