#21

ah dang, of course you’re right. thus far there has been no reason for an operator to be aware of its outputs’ positions in the global array.

honestly, i was just tossing off the idea of reporting outputs via serial as a potential. maybe it’s not particularly useful.

if you can already get input node values, then that’s kind of enough. i assume they are explicitly polled by the host? maybe it would be useful for the host to specify that it wants to always be informed when a given input changes value?

thing is, i like the point you made earlier, that the host should be able to dictate what gets sent without the user having to make patch changes.

and what i’d ultimately like to do is add serial glue for patch editing commands, and for querying preset and connection state. so we can finally get that remote editor…

#22

I feel like with the slightly revised op_param we at least have a workable toolkit now. params & ins are explicitly polled by the host, not callback. (Actually this is a lie - technically speaking the host polls requesting a callback as there’s no transaction built into the messaging protocol).

It’s now straightforward to add the patching commands to comms protocol I can probably quickly hack the plumbing in tonight. I think all the extra commands required for patch editing are:

  • dump_outputs (request from host)

  • outputs_dump (response from aleph - comma delimited strings like ins or params)

  • dump_connections (request from host)

  • connections_dump (response from aleph [outIdx_hi,outIdx_lo,inIdx_hi,inIdx_lo] per connection)

  • patch_x_to_y (command from host) [outIdx_hi,outIdx_lo,inIdx_hi,inIdx_lo]

  • disconnect_x (command from_host) [outIdx_hi,outIdx_lo]

  • dump_ops (request from host)

  • ops_dump (response from aleph [opIdx_hi,opIdx_lo,opType_hi,opType_lo])

  • new_op(request from host) [opType_hi,opType_lo]

  • delete_op(request from host) [opIdx_hi,opIdx_lo]

#23

aleph-side comms protocol for remote editing is complete (not tested yet - that also requires the lisp-side & it’s time for bed now).

regarding the points about polling vs callbacks and the inherent crappiness of needing a serial operator, there’s another elephant in the room here - that is the lack of callbacks from the DSP. Would also point out it’s now possible to achieve the same effect as “callback on input change” using the new op_serial.

The thing that really bugs me is yanking that SD card in & out the whole time. I’d like to see a fully functional linux simulator with OSC control of the params & the ability to load blackfin program over the wire without rebooting bees.

Also not forgetting the feature to make the ‘patch matrix’ in grains show textual values rather than patch indices. Really we should move these tangential discussions back to github issues that will help prioritise…

#24

hey rick! i’m looking for this link and can’t find it. did it get erased?

#25

http://eli.thegreenplace.net/2009/08/12/framing-in-serial-communications/

1 Like
#26

oops sorry the link shouldn’t have got erased from source code…

Added back into this open pull request so the info is in right place: