FWIW, I'm definitely interested in hearing more about CM-incudine on here! :-)
iain On Mon, Apr 5, 2021 at 7:31 AM Brandon Hale <[email protected]> wrote: > I just got around to trying this out, and man, this is awesome! Being > able to trigger common music events with the incudine responder is > excellent. > > For the responders, you would have to create a new responder for each > event you would want for different osc messages, right? > > Thanks for your help! > > On 4/1/21 1:46 PM, Brandon Hale wrote: > > 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. > _______________________________________________ > Cmdist mailing list > [email protected] > https://cm-mail.stanford.edu/mailman/listinfo/cmdist >
_______________________________________________ Cmdist mailing list [email protected] https://cm-mail.stanford.edu/mailman/listinfo/cmdist
