[CM] Receiving OSC in (cm:rts)

[Brandon Hale]

Thanks so much Orm! I didn't know if the cmdist list would also support 
your cm-incudine, but it would be better to have an open discussion for 
others seeking help on this.

I will play with this and report back if I have any questions. Thank you 
for the detailed explanation and the awesome example!

On 4/1/21 11:58 AM, Orm Finnendahl wrote:
> Hey Brandon,
>
> Am Donnerstag, den 01. April 2021 um 09:29:16 Uhr (-0400) schrieb
> Brandon Hale:
>> Hey Orm,
>>
>> I hope it's okay to send questions your way. I've been really interested in
>> trying to receive OSC messages into common music. I've looked at your
>> documentation in cm-incudine/README.org about opening the port for OSC and
>> your README says to look into the common music docs for handling input
>> events. Is that the (INPUT) function that I would look into from common
>> music? I am really interested in triggering (EVENTS) from OSC messages.
>   it's ok to contact me, although the cmdist list should be an
> appropriate forum for such questions, even if it's CL and CM2 related.
>
> I therefore also forward my response to the cmdist list. Maybe there
> are people out there using CM2 on CL.
>
>
> In the current CM2 version on my github repository, OSC i/o is handled
> by incudine. Main reasons are:
>
> 1. incudine is optimized for OSC messages and
>
> 2. Although OSC had been implemented in Common Music 2, back then it
>     seems to have been mainly used for communication with super
>     collider, probably wasn't used very much and therefore isn't well
>     documented. I looked into the implementation before but remember
>     that I wasn't sure the implementation was very practical as you had
>     to define classes and methods for every message type. For your
>     purpose I guess it's more straightforward using incudine directly
>     for receiving OSC. You can call the events macro within the
>     responders.
>
> Below is an example. Let me know if that works for you. In case you
> want to avoid the incudine: prefix, you can (use-package :incudine) or
> maybe it is even sufficient with (use-package :incudine.osc).
>
> For more info on OSC handling you can refer to the incudine doc
> (http://incudine.sourceforge.net/incudine.html), and it should also be
> mentioned on one page of incudine's tutorials.
>
> Best,
> Orm
> ---------------------------------------------------------
>
> ;;; open a connection "socket":
>
> (setf *osc-in* (incudine.osc:open :direction :input :host "127.0.0.1" :port 3091))
>
> ;;; start listening on the socket:
>
> (incudine:recv-start *osc-in*)
>
> ;;; define a responder (an association between the osc route/arg types
> ;;; and a function to call on the args). In this case an anonymus
> ;;; lambda function is used, but you could also specify a named
> ;;; function, using the #' prefix on the function name.
>
> (defparameter *osc-responder*
>    (incudine:make-osc-responder *osc-in* "/osc/test" "fff"
>                                 (lambda (a b c)
>                                   (format t "~f ~f ~f~%" a b c))))
>
> ;;; add the responder to the list of responder functions to be invoked,
> ;;; when the socket receives input:
>
> (incudine:add-responder *osc-responder*)
>
> ;;; after this you should be able to send 3 floats to /osc/test over
> ;;; osc and the floats should be printed in the REPL.
>
> ;;; The previous 2 steps of course could be done in one step with:
>
> ;;; (incudine:add-responder
> ;;;   (incudine:make-osc-responder
> ;;;    ...
> ;;; ))
>
> ;;; the following two functions are for inspection
>
> ;;; check if osc-receiver is running:
>
> (incudine:recv-status *osc-in*)
>
> ;;; Check which functions are active in the receiver:
>
> (incudine:recv-functions *osc-in*)
>
> ;;; close connection by undoing the previous three steps in reverse
> ;;; order:
>
> (incudine:remove-responder *osc-responder*)
> (incudine:recv-stop *osc-in*)
> (incudine.osc:close *osc-in*)
>
> ;;; Although it sounds unnecessarily complicated the advantage of this
> ;;; modularized approach is that you can dynamically add/remove
> ;;; responders or stop/restart listening without having to remove and
> ;;; add the responders again.