input values not at top of the repl

[jlmitch5]

the readme says:

input values are printed on the top line

but I'm not seeing those

[trentgill]

realizing that First actually breaks this functionality. in order for it to work, the stream & change events need to be defined as:

stream     = function(value) _c.tell('stream',chan,value) end
change     = function(state) _c.tell('change',chan,state and 1 or 0) end

[simonvanderveldt]

@trentgill is there a reason a script can (choose to) break this behavior/not adhere to the standard?
Can we make sure that this always works?

[csboling]

Alternatively, a druid command could maybe reset the default handlers + input modes.

[tehn]

if you clear First ^^c won't this functionality be restored? that seems like a decent behavior.

i don't think input monitoring should be "always on" as it's extra usb traffic (and crow processor load) but maybe that's negligible.

if we were going to go full-time with input reporting, might make sense to also do output reporting?

[simonvanderveldt]

if you clear First ^^c won't this functionality be restored? that seems like a decent behavior.

I just used clearscript/^^c and I didn't see anything in the two capture fields until I set input[n].mode('stream').

[tehn]

ok. i think the input/output capture is a sort of secondary feature that we need to consider. like a "scope" view, when enabled, druid sends some config.

but note that it may/will mess up the currently running script given it's overriding the config of inputs. so for this to be robust crow would need more plumbing--- like a secondary/not-script-related input/output update-via-usb

[trentgill]

This feature was secondary from the start. I mostly wanted to observe the input streams without trashing the console output (especially when sending at a high-rate).

We could add a library function to crow that sets up a metro & sends the stream message

One solution would be to add a library function that creates a metro which transmits the input values always. :

scope_metro = {} -- need a global to store whether we're sending
function scope(active)
  if active and scope_metro == {} then
    scope_metro = metro.init{ time = 0.1 }
    scope_metro.event = function()
      _c.tell('stream',1,input[1].volts) end
      _c.tell('stream',2,input[2].volts) end
    end
    scope_metro:start()
  elseif not active and scope_metro ~= {}
    scope_metro:stop()
    metro.free(scope_metro.id)
    scope_metro = {}
  end
end

I guess my point is, implementation is easy, it's much more of a design issue.

Is it even useful to have the raw floats / bools printed? I've been thinking a visual fader might make it more communicative. Alternatively we could scrap the input vals being printed, and instead have some kind of scope / histogram thing.

[simonvanderveldt]

Would it make sense to make easy input monitoring a primary feature?

It seem like a very useful feature to have. I mean quiet a lot of scripts will take an input and being able to monitor that input helps a lot.
I can image one would sometimes like to see the derived value that is use in the script instead of the raw input. The boolean value as shown for change is an example for this, but it could for example also be a 5-state switch based on voltage. In that case you probably want to see 1-5 instead of 0-10V. This of course would mean it needs to be configurable but this would allow easy monitoring of the logically useful inputs going into a script.

Anyway, I've been working through the docs/tutorials this weekend and I've found it very useful to be able to easily view either the current value (in volts) or the boolean state when using change.
For this I definitely prefer the values as-is instead of some visual thing. A scope might be useful to monitor changes over time but that seems like a nice to have to me.

[jlmitch5]

FWIW, I am ambiguous about the actual behavior. The issue is more the documentation in the readme is not valid for a new user...especially considering first is loaded by default. I thought it was something working incorrectly (which is why I initially filed the issue)