From orm.finnendahl at selma.hfmdk-frankfurt.de Thu Apr 1 08:58:43 2021 From: orm.finnendahl at selma.hfmdk-frankfurt.de (Orm Finnendahl) Date: Thu, 1 Apr 2021 17:58:43 +0200 Subject: [CM] Receiving OSC in (cm:rts) In-Reply-To: References: Message-ID: 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. From bthaleproductions at gmail.com Thu Apr 1 10:46:14 2021 From: bthaleproductions at gmail.com (Brandon Hale) Date: Thu, 1 Apr 2021 13:46:14 -0400 Subject: [CM] Receiving OSC in (cm:rts) In-Reply-To: References: Message-ID: <934b282b-1dc3-00e6-f2df-a73120ae000a@gmail.com> 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. From elronnd at elronnd.net Sun Apr 4 17:51:58 2021 From: elronnd at elronnd.net (Elijah Stone) Date: Sun, 4 Apr 2021 17:51:58 -0700 (PDT) Subject: [CM] Delimited strings in s7 Message-ID: For a couple of projects I've used s7 for, I've wanted to embed regular expressions directly in strings, and it's somewhat annoying to have to escape backslashes. Is there any chance we can get a 'raw' string type, which doesn't support escaping? I've attached a patch implementing support for this with the syntax #q/foo/, where '/' can be an arbitrary delimiter, and if it has a matching pair ((){}[]<>), it respects nesting. Not super confident in it as I'm not that familiar with the implementation code, but it seems to work... -E -------------- next part -------------- diff --git a/s7/s7.c b/s7/s7.c index aaa216b..7d7da5d 100644 --- a/s7/s7.c +++ b/s7/s7.c @@ -532,7 +532,7 @@ typedef block_t vdims_t; #define vdims_original(p) p->ex.ex_ptr -typedef enum {TOKEN_EOF, TOKEN_LEFT_PAREN, TOKEN_RIGHT_PAREN, TOKEN_DOT, TOKEN_ATOM, TOKEN_QUOTE, TOKEN_DOUBLE_QUOTE, TOKEN_BACK_QUOTE, +typedef enum {TOKEN_EOF, TOKEN_LEFT_PAREN, TOKEN_RIGHT_PAREN, TOKEN_DOT, TOKEN_ATOM, TOKEN_QUOTE, TOKEN_DOUBLE_QUOTE, TOKEN_DELIMITED_QUOTE, TOKEN_BACK_QUOTE, TOKEN_COMMA, TOKEN_AT_MARK, TOKEN_SHARP_CONST, TOKEN_VECTOR, TOKEN_BYTE_VECTOR, TOKEN_INT_VECTOR, TOKEN_FLOAT_VECTOR} token_t; typedef enum {NO_ARTICLE, INDEFINITE_ARTICLE} article_t; @@ -70475,6 +70475,10 @@ static token_t read_sharp(s7_scheme *sc, s7_pointer pt) backchar('u', pt); break; + case 'q': + return(TOKEN_DELIMITED_QUOTE); + + case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': case '9': { /* here we can get an overflow: #1231231231231232131D() */ @@ -70781,6 +70785,76 @@ static s7_pointer unknown_string_constant(s7_scheme *sc, int32_t c) return(sc->T); } +static s7_pointer read_delimited_string_constant(s7_scheme *sc, s7_pointer pt) +{ + const char *openers = "([{<"; + const char *closers = ")]}>"; + s7_int depth = 1; + int32_t open_delimiter = port_read_character(pt)(sc, pt); + char close_delimiter; + + if (open_delimiter == EOF) + { + sc->strbuf[0] = '\0'; + return(sc->F); + } + + { + char *opener_address = strchr(openers, open_delimiter); + if (opener_address) close_delimiter = closers[opener_address - openers]; + else close_delimiter = open_delimiter; + } + + if (is_string_port(pt)) + { + char *start = (char *)(port_data(pt) + port_position(pt)); + char *end = (char*)(port_data(pt) + port_data_size(pt)); + char needle[3] = {open_delimiter, close_delimiter, '\0'}; + char *s = start; + + while (depth) + { + s = strpbrk(s, needle); + if (!s) return(sc->F); + if (*s == close_delimiter) depth--; + else if (*s == open_delimiter) depth++; + s++; + } + + + port_position(pt) += s - start; + return(make_string_with_length(sc, start, s - start - 1)); + } + + + while (true) + { + s7_int i = 0; + int32_t c = port_read_character(pt)(sc, pt); + + switch (c) + { + case EOF: + sc->strbuf[(i > 8) ? 8 : i] = '\0'; + return(sc->F); + case '\n': + port_line_number(pt)++; + sc->strbuf[i++] = c; + break; + default: + if (c == close_delimiter) depth--; + else if (c == open_delimiter) depth++; + + if (!depth) return(make_string_with_length(sc, sc->strbuf, i)); + + sc->strbuf[i++] = (unsigned char)c; + } + + if (i >= sc->strbuf_size) + resize_strbuf(sc, i); + } +} + static s7_pointer read_string_constant(s7_scheme *sc, s7_pointer pt) { /* sc->F => error @@ -70929,6 +71003,14 @@ static void read_double_quote(s7_scheme *sc) if (sc->safety > IMMUTABLE_VECTOR_SAFETY) set_immutable(sc->value); } +static void read_delimited_quote(s7_scheme *sc) +{ + sc->value = read_delimited_string_constant(sc, current_input_port(sc)); + if (sc->value == sc->F) + string_read_error(sc, "end of input encountered while in a delimited string"); + if (sc->safety > IMMUTABLE_VECTOR_SAFETY) set_immutable(sc->value); +} + static inline bool read_sharp_const(s7_scheme *sc) { sc->value = port_read_sharp(current_input_port(sc))(sc, current_input_port(sc)); @@ -71058,6 +71140,10 @@ static s7_pointer read_expression(s7_scheme *sc) case TOKEN_DOUBLE_QUOTE: read_double_quote(sc); return(sc->value); + + case TOKEN_DELIMITED_QUOTE: + read_delimited_quote(sc); + return(sc->value); case TOKEN_SHARP_CONST: return(port_read_sharp(current_input_port(sc))(sc, current_input_port(sc))); @@ -94048,6 +94134,7 @@ static s7_pointer eval(s7_scheme *sc, opcode_t first_op) case TOKEN_ATOM: sc->value = port_read_name(current_input_port(sc))(sc, current_input_port(sc)); goto READ_LIST; case TOKEN_SHARP_CONST: if (read_sharp_const(sc)) goto READ_TOK; goto READ_LIST; case TOKEN_DOUBLE_QUOTE: read_double_quote(sc); goto READ_LIST; + case TOKEN_DELIMITED_QUOTE: read_delimited_quote(sc); goto READ_LIST; case TOKEN_DOT: read_dot_and_expression(sc); break; default: read_tok_default(sc); break; } From elronnd at elronnd.net Sun Apr 4 23:26:12 2021 From: elronnd at elronnd.net (Elijah Stone) Date: Sun, 4 Apr 2021 23:26:12 -0700 (PDT) Subject: [CM] Delimited strings in s7 In-Reply-To: References: Message-ID: <5f39b568-fe56-ea50-825e-72b329f557c@elronnd.net> Ah--it seems *#readers* can do this easily already. I missed that. Sorry for the noise! -E From elronnd at elronnd.net Mon Apr 5 00:26:46 2021 From: elronnd at elronnd.net (Elijah Stone) Date: Mon, 5 Apr 2021 00:26:46 -0700 (PDT) Subject: [CM] Delimited strings in s7 In-Reply-To: <5f39b568-fe56-ea50-825e-72b329f557c@elronnd.net> References: <5f39b568-fe56-ea50-825e-72b329f557c@elronnd.net> Message-ID: On Sun, 4 Apr 2021, Elijah Stone wrote: > Ah--it seems *#readers* can do this easily already. I do notice it's difficult to define new token types, though, because of the 'read until next delimiter' behaviour. In order to get correct behaviour in all cases, I need make a wrapper port and use 'read' and 'values'. Which is a bit inconvenient. Proposed behaviour: if a niladic function is put in *#readers*, no additional characters will be read past the #. Thoughts? (I'll post a patch tomorrow; late today.) From bil at ccrma.Stanford.EDU Mon Apr 5 02:26:59 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Mon, 05 Apr 2021 02:26:59 -0700 Subject: [CM] Delimited strings in s7 In-Reply-To: References: <5f39b568-fe56-ea50-825e-72b329f557c@elronnd.net> Message-ID: <5b3d535e1b00ef0ac3f0c3e8a8dfac9c@ccrma.stanford.edu> In case.scm I use #<...>, then object->string on the # object (and substring to get rid of the brackets). There are examples of regex strings in that file. But I'm not sure what you want here. There are a lot of examples in lint.scm (line 23201). From bthaleproductions at gmail.com Mon Apr 5 07:31:24 2021 From: bthaleproductions at gmail.com (Brandon Hale) Date: Mon, 5 Apr 2021 10:31:24 -0400 Subject: [CM] Receiving OSC in (cm:rts) In-Reply-To: <934b282b-1dc3-00e6-f2df-a73120ae000a@gmail.com> References: <934b282b-1dc3-00e6-f2df-a73120ae000a@gmail.com> Message-ID: 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. From iainduncanlists at gmail.com Mon Apr 5 07:59:35 2021 From: iainduncanlists at gmail.com (Iain Duncan) Date: Mon, 5 Apr 2021 07:59:35 -0700 Subject: [CM] Receiving OSC in (cm:rts) In-Reply-To: References: <934b282b-1dc3-00e6-f2df-a73120ae000a@gmail.com> Message-ID: 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 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 > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From squarewave at elisanet.fi Mon Apr 5 08:10:34 2021 From: squarewave at elisanet.fi (Matti Koskinen) Date: Mon, 5 Apr 2021 18:10:34 +0300 Subject: [CM] Snd-21 Message-ID: <7C29C01F-1672-4FB3-B5F3-9E94C7AFB1A5@elisanet.fi> Hi all, Just completed a short test of snd on Apple Mac Mini M1 running native arm64 and MOTIF It was quite easy to build after getting homebrew flags and packages right. On M1 I read that /usr/local ia for Intel and /opt/homebrew is better used for Apple Silicon. Xquartz has version already for M1 native code. Compiling was, how to say, blazing fast. S7.c took little longer, but the other files just like cat s7.c on old Mac. Audio works, but scrolling with mouse not, , as it has something to do with X-settings. I remember this from Ubuntu Linux, too. Old good times revive! -m From tito.01beta at gmail.com Mon Apr 5 09:11:40 2021 From: tito.01beta at gmail.com (Tito Latini) Date: Mon, 5 Apr 2021 18:11:40 +0200 Subject: [CM] Receiving OSC in (cm:rts) In-Reply-To: References: <934b282b-1dc3-00e6-f2df-a73120ae000a@gmail.com> Message-ID: <20210405161140.GA1652@vis.roboris> On Mon, Apr 05, 2021 at 10:31:24AM -0400, Brandon Hale 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? Yes with MAKE-OSC-RESPONDER. The expansion is (macroexpand-1 '(make-osc-responder *oscin* "/osc/test" "iii" (lambda (a b c) (msg warn "~D ~D ~D" a b c)))) ;; (MAKE-RESPONDER *OSCIN* ;; (LAMBDA (#:S582) ;; (WHEN (INCUDINE.OSC:CHECK-PATTERN #:S582 "/osc/test" "iii") ;; (INCUDINE.OSC:WITH-VALUES (A B C) ;; (#:S582 "iii") ;; (MSG WARN "~D ~D ~D" A B C))) ;; (VALUES))) therefore it is also possible a single responder. There is a tutorial about OSC in /path/to/incudine/doc/tutorials/osc_messages.cudo (lisp file) /path/to/incudine/doc/html/tutorial_osc.html (html file) http://incudine.sourceforge.net/tutorial_osc.html (web) I could add another example if something is not clear. From orm.finnendahl at selma.hfmdk-frankfurt.de Mon Apr 5 09:49:29 2021 From: orm.finnendahl at selma.hfmdk-frankfurt.de (Orm Finnendahl) Date: Mon, 5 Apr 2021 18:49:29 +0200 Subject: [CM] Receiving OSC in (cm:rts) In-Reply-To: References: <934b282b-1dc3-00e6-f2df-a73120ae000a@gmail.com> Message-ID: Am Montag, den 05. April 2021 um 07:59:35 Uhr (-0700) schrieb Iain Duncan: > FWIW, I'm definitely interested in hearing more about CM-incudine on here! > :-) https://www.youtube.com/watch?v=VCO1uSf5jE4 Event scheduling and interactive control (visual and acoustic) was realized with cm-incudine (using multiple threads from a single CL instance to interface with QT, OpenCL, OpenGL and scsynth). -- Orm From bthaleproductions at gmail.com Mon Apr 5 15:51:08 2021 From: bthaleproductions at gmail.com (Brandon Hale) Date: Mon, 5 Apr 2021 18:51:08 -0400 Subject: [CM] Receiving OSC in (cm:rts) In-Reply-To: <20210405161140.GA1652@vis.roboris> References: <934b282b-1dc3-00e6-f2df-a73120ae000a@gmail.com> <20210405161140.GA1652@vis.roboris> Message-ID: Thank you Tito. Orm ended up helping me out with this, so no worries. On 4/5/21 12:11 PM, Tito Latini wrote: > On Mon, Apr 05, 2021 at 10:31:24AM -0400, Brandon Hale 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? > Yes with MAKE-OSC-RESPONDER. The expansion is > > (macroexpand-1 '(make-osc-responder *oscin* "/osc/test" "iii" > (lambda (a b c) > (msg warn "~D ~D ~D" a b c)))) > ;; (MAKE-RESPONDER *OSCIN* > ;; (LAMBDA (#:S582) > ;; (WHEN (INCUDINE.OSC:CHECK-PATTERN #:S582 "/osc/test" "iii") > ;; (INCUDINE.OSC:WITH-VALUES (A B C) > ;; (#:S582 "iii") > ;; (MSG WARN "~D ~D ~D" A B C))) > ;; (VALUES))) > > therefore it is also possible a single responder. > > There is a tutorial about OSC in > > /path/to/incudine/doc/tutorials/osc_messages.cudo (lisp file) > /path/to/incudine/doc/html/tutorial_osc.html (html file) > http://incudine.sourceforge.net/tutorial_osc.html (web) > > I could add another example if something is not clear. From elronnd at elronnd.net Mon Apr 5 23:43:53 2021 From: elronnd at elronnd.net (Elijah Stone) Date: Mon, 5 Apr 2021 23:43:53 -0700 (PDT) Subject: [CM] Delimited strings in s7 In-Reply-To: <5b3d535e1b00ef0ac3f0c3e8a8dfac9c@ccrma.stanford.edu> References: <5f39b568-fe56-ea50-825e-72b329f557c@elronnd.net> <5b3d535e1b00ef0ac3f0c3e8a8dfac9c@ccrma.stanford.edu> Message-ID: On Mon, 5 Apr 2021, bil at ccrma.Stanford.EDU wrote: > But I'm not sure what you want here. There are a lot of examples in > lint.scm (line 23201). My point is, in a _general_ sense the current design of #readers makes it difficult to add new types of tokens, because of the 'read until next delimiter' behaviour. Let's say, for example--not very practical, but you get the point--that I want an alternate syntax for character literals with #&x. Unlike #\, #& should only ever accept a single character; so #&a is the same as #\a, but #&Newline is the same as #\N ewline (latter is two tokens). Under the current scheme, the reader function will get passed "&Newline" as its parameter, and need to manually return (values #\N 'ewline). To make matters worse, a token can be split across the partially-read string and the input port; for instance, consider #&x#&(. This should be the same as #\x #\(, but the reader will pass the '&' sharp reader "&x#&", and "(" will be left on the input port; and the '&' sharp reader somehow has to reconstruct the result. My proposal is to rectify this in a backwards-compatible way by checking the arity of #-readers; if a #-reader takes 1 parameter, the behaviour is the same as it is currently, but if it takes 0 parameters, then the reader will not read any characters past the first '#'. -E From tito.01beta at gmail.com Tue Apr 6 02:14:35 2021 From: tito.01beta at gmail.com (Tito Latini) Date: Tue, 6 Apr 2021 11:14:35 +0200 Subject: [CM] Receiving OSC in (cm:rts) In-Reply-To: References: <934b282b-1dc3-00e6-f2df-a73120ae000a@gmail.com> Message-ID: <20210406091434.GA2705@vis.roboris> On Mon, Apr 05, 2021 at 06:49:29PM +0200, Orm Finnendahl wrote: > Am Montag, den 05. April 2021 um 07:59:35 Uhr (-0700) schrieb Iain Duncan: > > FWIW, I'm definitely interested in hearing more about CM-incudine on here! > > :-) > > https://www.youtube.com/watch?v=VCO1uSf5jE4 > > Event scheduling and interactive control (visual and acoustic) was > realized with cm-incudine (using multiple threads from a single CL > instance to interface with QT, OpenCL, OpenGL and scsynth). Congrats to you and the other artists. I particularly like the sonorities and the effects after 10:20. Masks and restrictions are also part of the whole suggestion but the hidden scheduler in this case is managed by another anvil. From bil at ccrma.Stanford.EDU Tue Apr 6 07:32:58 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Tue, 06 Apr 2021 07:32:58 -0700 Subject: [CM] Delimited strings in s7 In-Reply-To: References: <5f39b568-fe56-ea50-825e-72b329f557c@elronnd.net> <5b3d535e1b00ef0ac3f0c3e8a8dfac9c@ccrma.stanford.edu> Message-ID: <1245a2d00e7943440dc163d29c271569@ccrma.stanford.edu> The reader tokenizes before it tries to make sense of a # sequence, so #&( will be a missing-close-paren error long before you get to the *#readers* handlers. For most other cases you might be able to use port-position which is settable: (set! *#readers* (cons (cons #\& (lambda (str) (if (= (string-length str) 1) ; #& followed by a reader delimiter (read) (begin (set! (port-position (current-input-port)) (- (port-position (current-input-port)) (string-length str) -1)) (string (string-ref str 1)))))) ())) (with-input-from-string "#&N" (lambda () (display (read)) (newline) (display (read)) (newline))) N # (with-input-from-string "#&Newton" (lambda () (display (read)) (newline) (display (read)) (newline) (display (read)) (newline))) N ewton # (with-input-from-string "#&N#&123" (lambda () (display (read)) (newline) (display (read)) (newline) (display (read)) (newline) (display (read)) (newline))) N 1 23 # (with-input-from-string "#&(123)" (lambda () (display (read)) (newline) (display (read)) (newline))) (123) # I don't want the arity of the *#reader* function to be a flag meaning "read one character" -- this would only have one use, would require hand-waving in the documentation, and would make error checking less reliable. From bil at ccrma.Stanford.EDU Tue Apr 6 08:45:24 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Tue, 06 Apr 2021 08:45:24 -0700 Subject: [CM] Delimited strings in s7 In-Reply-To: References: <5f39b568-fe56-ea50-825e-72b329f557c@elronnd.net> <5b3d535e1b00ef0ac3f0c3e8a8dfac9c@ccrma.stanford.edu> Message-ID: It occurs to me that you could replace the read with read-string or read-char when the argument string-length is 1 -- reading ahead -- then in the read-string case, after getting whatever you want, put the port-position to start reading the rest. Kind of messy perhaps, and I haven't tried this. From chris.actondev at gmail.com Wed Apr 7 14:40:09 2021 From: chris.actondev at gmail.com (Christos Vagias) Date: Wed, 7 Apr 2021 23:40:09 +0200 Subject: [CM] c_objects and garbage collection: s7_make_c_object_without_gc ? Message-ID: Hi Bil, I have some c_objects that I'm creating with s7_make_c_object. I can read, write etc, and having set the s7_c_type_set_free the allocated memory will be freed when the object is no longer used by s7. So far so good. I've stumbled upon the scenario where I would like to use the getters & setters on some c data that is handled by someone else (ie I'm not the one creating it, or it's allocated on the stack and should not be freed) and thus should not be freed by s7's garbage collector. What do you think about s7_make_c_object_without_gc ? >From what I see in the code I'd be the same without calling add_c_object(sc, x); The currently available alternative is to create a complete new c_object type, skip the "s7_c_type_set_free" and duplicate all the rest (getters, setters etc) From bil at ccrma.Stanford.EDU Wed Apr 7 15:31:42 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Wed, 07 Apr 2021 15:31:42 -0700 Subject: [CM] =?utf-8?q?c=5Fobjects_and_garbage_collection=3A_s7=5Fmake=5F?= =?utf-8?b?Y19vYmplY3Rfd2l0aG91dF9nYyA/?= In-Reply-To: References: Message-ID: <3332964448657ef2b891b7f129719f82@ccrma.stanford.edu> I'll check it out -- it sounds unproblematic. I assume the s7_cell that holds the c_object can be in the heap, and freed for reuse when s7 thinks it can't be accessed anymore. From bil at ccrma.Stanford.EDU Wed Apr 7 16:03:07 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Wed, 07 Apr 2021 16:03:07 -0700 Subject: [CM] =?utf-8?q?c=5Fobjects_and_garbage_collection=3A_s7=5Fmake=5F?= =?utf-8?b?Y19vYmplY3Rfd2l0aG91dF9nYyA/?= In-Reply-To: References: Message-ID: <505046ddc102042ca9b824e5b5530b99@ccrma.stanford.edu> I updated the tarballs and git/svn sites. Let me know of any problems (I haven't tested the new function yet). From chris.actondev at gmail.com Thu Apr 8 18:10:00 2021 From: chris.actondev at gmail.com (Christos Vagias) Date: Fri, 9 Apr 2021 03:10:00 +0200 Subject: [CM] c_objects and garbage collection: s7_make_c_object_without_gc ? In-Reply-To: <505046ddc102042ca9b824e5b5530b99@ccrma.stanford.edu> References: <505046ddc102042ca9b824e5b5530b99@ccrma.stanford.edu> Message-ID: Thanks! Seems to work as expected doing a brief test On Thu, Apr 8, 2021, 1:03 AM wrote: > I updated the tarballs and git/svn sites. Let me > know of any problems (I haven't tested the new function > yet). > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Fri Apr 9 16:38:15 2021 From: iainduncanlists at gmail.com (Iain Duncan) Date: Fri, 9 Apr 2021 16:38:15 -0700 Subject: [CM] Worthwhile to explore realtime-friendly GC strategies for s7? Message-ID: Hello Bill and colleagues, this is mostly a question of curiosity, though potentially also a question of "wonder what would make a good phd topic in a couple of years". I'm getting pretty good results running complete s7 sequencing environments in Max so long as my latency setting is high enough to be able to handle some fairly large bursts. I run the gc automatically every 100 to 300 ms and that seems to work pretty well at taming the bursts, but they are still there, introducing constraints at what I can do with lower latency (but surprisingly capable to be honest!). I'm just curious to hear thoughts. Would trying to put a more real-time friendly GC strategy into s7 be possible, feasible, worthwhile, etc? I know next to nothing yet about the various ways GCs work, but I'm getting lots of support (from my supervisors at least) for working on Scheme for Max and Scheme for PD as worthwhile long term projects, and I'm definitely interested in looking under the hood more. I'm not really interested in the no-GC approach used by things like Extempore and Carp, as the whole advantage for me is the high level dynamic coding, but if making the GC more real time friendly is not a fool's task, it could be something I might be able to work towards in the long run Thoughts welcome! iain -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.actondev at gmail.com Sat Apr 10 02:54:59 2021 From: chris.actondev at gmail.com (Christos Vagias) Date: Sat, 10 Apr 2021 11:54:59 +0200 Subject: [CM] Worthwhile to explore realtime-friendly GC strategies for s7? In-Reply-To: References: Message-ID: Hi Iain, https://gamelisp.rs/ might be of interest to you and/or Bil, quoting from their website: "GameLisp has a unique garbage collector designed specifically for game development. It runs once per frame, every frame, without causing any latency spikes" What kind of/how much computation are you doing in your scenario with scheme? That's interesting to know Some other kind of relevant things: Meanwhile, I'm also planning to integrate puredata. At the moment I have created some basic bindings for RtAudio and did my first "audio hello world": generating & outputting a sine wave from s7 (the cpu gets high though ~10%). Before diving any deeper I want to check some c-define/c-load equivalent to off-load heavy computations into C code, but without losing the REPL-driven development. >From what I've seen Bil's strategy is generating c files (from sheme code) and then compiling with gcc & linking while s7 is running. A strategy I want to check is using tinycc, which is an embeddable C99 compiler, which (I think) works in linux, windows, and mac! Maybe that's also worth it checking out! Also, would you care to share any video walkthrough of how you're using scheme4max (apart from basic tutorials)? :) On Sat, 10 Apr 2021 at 01:38, Iain Duncan wrote: > > Hello Bill and colleagues, this is mostly a question of curiosity, though potentially also a question of "wonder what would make a good phd topic in a couple of years". I'm getting pretty good results running complete s7 sequencing environments in Max so long as my latency setting is high enough to be able to handle some fairly large bursts. I run the gc automatically every 100 to 300 ms and that seems to work pretty well at taming the bursts, but they are still there, introducing constraints at what I can do with lower latency (but surprisingly capable to be honest!). > > I'm just curious to hear thoughts. Would trying to put a more real-time friendly GC strategy into s7 be possible, feasible, worthwhile, etc? I know next to nothing yet about the various ways GCs work, but I'm getting lots of support (from my supervisors at least) for working on Scheme for Max and Scheme for PD as worthwhile long term projects, and I'm definitely interested in looking under the hood more. I'm not really interested in the no-GC approach used by things like Extempore and Carp, as the whole advantage for me is the high level dynamic coding, but if making the GC more real time friendly is not a fool's task, it could be something I might be able to work towards in the long run > > Thoughts welcome! > iain > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist From k.s.matheussen at gmail.com Sat Apr 10 03:30:40 2021 From: k.s.matheussen at gmail.com (Kjetil Matheussen) Date: Sat, 10 Apr 2021 12:30:40 +0200 Subject: [CM] Worthwhile to explore realtime-friendly GC strategies for s7? In-Reply-To: References: Message-ID: On Sat, Apr 10, 2021 at 1:41 AM Iain Duncan wrote: > > Hello Bill and colleagues, this is mostly a question of curiosity, though potentially also a question of "wonder what would make a good phd topic in a couple of years". I'm getting pretty good results running complete s7 sequencing environments in Max so long as my latency setting is high enough to be able to handle some fairly large bursts. I run the gc automatically every 100 to 300 ms and that seems to work pretty well at taming the bursts, but they are still there, introducing constraints at what I can do with lower latency (but surprisingly capable to be honest!). > > I'm just curious to hear thoughts. Would trying to put a more real-time friendly GC strategy into s7 be possible, feasible, worthwhile, etc? I know next to nothing yet about the various ways GCs work, but I'm getting lots of support (from my supervisors at least) for working on Scheme for Max and Scheme for PD as worthwhile long term projects, and I'm definitely interested in looking under the hood more. I'm not really interested in the no-GC approach used by things like Extempore and Carp, as the whole advantage for me is the high level dynamic coding, but if making the GC more real time friendly is not a fool's task, it could be something I might be able to work towards in the long run > This gc might be interesting: http://users.notam02.no/~kjetism/rollendurchmesserzeitsammler/ Snd was even the main testbed for it. Note that it was made before it was necessary for memory access to be atomic for correct behavior, so it probably needs some modifications to run on modern computers. It might not be that much work though, and the information in the master thesis should still be valid: http://users.notam02.no/~kjetism/rollendurchmesserzeitsammler/Matheussen_Master.pdf From bil at ccrma.Stanford.EDU Sat Apr 10 06:57:56 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Sat, 10 Apr 2021 06:57:56 -0700 Subject: [CM] =?utf-8?q?Worthwhile_to_explore_realtime-friendly_GC_strateg?= =?utf-8?q?ies_for_s7=3F?= In-Reply-To: References: Message-ID: <5a3428a2306c2bdccf137898b6b27924@ccrma.stanford.edu> In s7, cache misses happen almost entirely in the gc and eval functions. In my informal tests, some of the standard benchmarks run ca 20% faster on an AMD 3950 (3.5GHz) with 64 MB L3 cache than on an Intel i7-6700 (4.2 GHz) with 8MB L3 cache. I'd like to try an AMD 5950 which I think has a 256 MB cache, but chip prices right now are astronomical. The benchmark compiler.scm, for example, runs in 23 secs on the small cache and 16.5 secs on the large, even though the large cache cpu is apparently slower. You might also try a smaller heap, or use float or int vectors, etc. From bil at ccrma.Stanford.EDU Sat Apr 10 07:00:16 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Sat, 10 Apr 2021 07:00:16 -0700 Subject: [CM] =?utf-8?q?Worthwhile_to_explore_realtime-friendly_GC_strateg?= =?utf-8?q?ies_for_s7=3F?= In-Reply-To: References: Message-ID: If you want examples of sound synthesis code in s7, sndlib's clm.c and clm2xen.c might be useful. sndclm.html is the documentation. From iainduncanlists at gmail.com Sat Apr 10 12:28:38 2021 From: iainduncanlists at gmail.com (Iain Duncan) Date: Sat, 10 Apr 2021 12:28:38 -0700 Subject: [CM] Worthwhile to explore realtime-friendly GC strategies for s7? In-Reply-To: References: Message-ID: Thanks everyone, that all gives me some stuff to look into and think about! Christos, some videos will be forthcoming soon! Currently doing a lot of benchmarking and load testing, and want to make sure I have a pretty good idea of performance possibilities and limits before telling the world about them. But the short answer is that I'm able to get really quite good performance with very tight timing running a full 16 track sequencer from Max with all sequencing code in the high priority max thread and sound synthesis handled in Ableton live. And there are a lot of different tradeoffs possible depending on whether one can live with a few ms of timing slop or not. I can get single sample accuracy if needed by running Max at an io vector of 246 or 512 samples, or is slop is acceptable instead, get dead low latency by running Max audio free and just piping to Live. At an rate, the load tests of the last two days have demonstrated that a commercial production rig with all sequencing done in Scheme is eminently doable, even on my 2015 macbook pro. :-) iain On Sat, Apr 10, 2021 at 7:00 AM wrote: > If you want examples of sound synthesis code in s7, > sndlib's clm.c and clm2xen.c might be useful. > sndclm.html is the documentation. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aykut_caglayan at yahoo.com Wed Apr 14 08:26:24 2021 From: aykut_caglayan at yahoo.com (aykut_caglayan) Date: Wed, 14 Apr 2021 17:26:24 +0200 Subject: [CM] Plotting w/ Common Music 3.9.0 References: <93F5AD73-77AD-4FF5-A54A-63D8ED0DD00E.ref@yahoo.com> Message-ID: <93F5AD73-77AD-4FF5-A54A-63D8ED0DD00E@yahoo.com> Hi Rick, I cannot seem to open a saved plot (as .xml) again; rather, it?s being opened in the text editor. Is there a solution to this issue? I wish I could use cm's great plotting capability again. Even though I do the computation mostly on python environment, I?m missing the ability to design graphically and copy the points to the text editor. Do you plan to translate plotting into musx? I?m on 10.14.6 Mojave Greetings to IL, Aykut From taube at illinois.edu Wed Apr 14 13:41:21 2021 From: taube at illinois.edu (Taube, Heinrich K) Date: Wed, 14 Apr 2021 20:41:21 +0000 Subject: [CM] Plotting w/ Common Music 3.9.0 In-Reply-To: <93F5AD73-77AD-4FF5-A54A-63D8ED0DD00E@yahoo.com> References: <93F5AD73-77AD-4FF5-A54A-63D8ED0DD00E.ref@yahoo.com> <93F5AD73-77AD-4FF5-A54A-63D8ED0DD00E@yahoo.com> Message-ID: Do you plan to translate plotting into musx? Hi Aykut! you can use matplotlib in python to do all sorts of really sophisticated plotting. There is also a ?piano roll? visualizer in python (sorry the name of the package escapes me now) BTW I?d say the latest version of musx is bascially at the level of cm2 now. ive been adding more examples and demos from my course to the musx_demo folder, including change ringing and sending ?real time? data out rtmidi ports and osc ports (supercollider). http://cmp.music.illinois.edu/courses/taube/mus499mrc/downloads/musx-1.3.0.zip ?Rick On Apr 14, 2021, at 10:26 AM, aykut_caglayan > wrote: Hi Rick, I cannot seem to open a saved plot (as .xml) again; rather, it?s being opened in the text editor. Is there a solution to this issue? I wish I could use cm's great plotting capability again. Even though I do the computation mostly on python environment, I?m missing the ability to design graphically and copy the points to the text editor. Do you plan to translate plotting into musx? I?m on 10.14.6 Mojave Greetings to IL, Aykut -------------- next part -------------- An HTML attachment was scrubbed... URL: From bil at ccrma.Stanford.EDU Thu Apr 15 03:37:07 2021 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 15 Apr 2021 03:37:07 -0700 Subject: [CM] Snd 21.3 Message-ID: <5ad81b8c55e8c0c12f921366e9f0feba@ccrma.stanford.edu> Snd 21.3: s7: tools/tgsl.scm removed deprecated nan.0 and inf.0 (use +nan.0 etc) added vector-rank, vector-dimension added s7_make_c_object_without_gc if you're using s7_optimize, it now returns an s7_pfunc, not an s7_function. checked: notcurses 2.2.3, sbcl 2.1.3 Thanks!: Manuel, Christos Vagias From iainduncanlists at gmail.com Thu Apr 15 07:50:38 2021 From: iainduncanlists at gmail.com (Iain Duncan) Date: Thu, 15 Apr 2021 07:50:38 -0700 Subject: [CM] Snd 21.3 In-Reply-To: <5ad81b8c55e8c0c12f921366e9f0feba@ccrma.stanford.edu> References: <5ad81b8c55e8c0c12f921366e9f0feba@ccrma.stanford.edu> Message-ID: nice! Many thanks as usual! :-))) On Thu, Apr 15, 2021 at 3:37 AM wrote: > Snd 21.3: > > s7: tools/tgsl.scm > removed deprecated nan.0 and inf.0 (use +nan.0 etc) > added vector-rank, vector-dimension > added s7_make_c_object_without_gc > if you're using s7_optimize, it now returns an s7_pfunc, not an > s7_function. > > checked: notcurses 2.2.3, sbcl 2.1.3 > > Thanks!: Manuel, Christos Vagias > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Sun Apr 18 16:11:56 2021 From: iainduncanlists at gmail.com (Iain Duncan) Date: Sun, 18 Apr 2021 16:11:56 -0700 Subject: [CM] s4m sequencing book(let) up Message-ID: Hi folks, I've just finished the first part of my ebook(let) on writing step sequencers with Scheme for Max. I'm interested in collecting feedback before I make accompanying videos for it, so if if anyone is interested in being and early reader, that would be lovely. Feedback can be sent here, to me privately, or submitted as github issues. repo with link to booklet https://github.com/iainctduncan/s4m-stk Thanks! iain -------------- next part -------------- An HTML attachment was scrubbed... URL: From aykut_caglayan at yahoo.com Sat Apr 24 02:47:59 2021 From: aykut_caglayan at yahoo.com (aykut_caglayan) Date: Sat, 24 Apr 2021 11:47:59 +0200 Subject: [CM] Plotting w/ Common Music 3.9.0 In-Reply-To: References: <93F5AD73-77AD-4FF5-A54A-63D8ED0DD00E.ref@yahoo.com> <93F5AD73-77AD-4FF5-A54A-63D8ED0DD00E@yahoo.com> Message-ID: <4E7F2547-2BC8-488E-9665-A7CFDB1BD009@yahoo.com> > you can use matplotlib in python to do all sorts of really sophisticated plotting. Hi Rick! I have tried to make a cheap imitation of Grace s plotting tool with matplotlib. User can add data points with mouse click and copy it to clipboard etc. whole process seems very cpu hungry though https://github.com/ayk-caglayan/graphic_composition_tool Viele Gr??e, Ayk -------------- next part -------------- An HTML attachment was scrubbed... URL: From bthaleproductions at gmail.com Sat Apr 24 15:38:56 2021 From: bthaleproductions at gmail.com (Brandon Hale) Date: Sat, 24 Apr 2021 18:38:56 -0400 Subject: [CM] Installer Script for cm-incudine on Arch Linux-based Distros Message-ID: <43c8177f-3079-5045-cd79-c07087389eb2@gmail.com> Hello all, Have you ever wanted to use cm-incudine, but felt like it was too hard or too much work to install on your Arch Linux-based distro? Now you can install it with https://github.com/brandflake11/install-cm-incudine . Hopefully this helps you install cm-incudine if you've ever been interested, but couldn't figure out all of the smaller bits. Feedback is welcome! Thank you very much for your time, Brandon Hale From orm.finnendahl at selma.hfmdk-frankfurt.de Mon Apr 26 02:11:06 2021 From: orm.finnendahl at selma.hfmdk-frankfurt.de (Orm Finnendahl) Date: Mon, 26 Apr 2021 11:11:06 +0200 Subject: [CM] Installer Script for cm-incudine on Arch Linux-based Distros In-Reply-To: <43c8177f-3079-5045-cd79-c07087389eb2@gmail.com> References: <43c8177f-3079-5045-cd79-c07087389eb2@gmail.com> Message-ID: cool. Thanks, Brandon! -- Orm Am Samstag, den 24. April 2021 um 18:38:56 Uhr (-0400) schrieb Brandon Hale: > Hello all, > > Have you ever wanted to use cm-incudine, but felt like it was too hard or > too much work to install on your Arch Linux-based distro? Now you can > install it with https://github.com/brandflake11/install-cm-incudine > . Hopefully this helps > you install cm-incudine if you've ever been interested, but couldn't figure > out all of the smaller bits. Feedback is welcome! > > > Thank you very much for your time, > > Brandon Hale > From taube at illinois.edu Mon Apr 26 15:47:00 2021 From: taube at illinois.edu (Taube, Heinrich K) Date: Mon, 26 Apr 2021 22:47:00 +0000 Subject: [CM] Plotting w/ Common Music 3.9.0 In-Reply-To: <4E7F2547-2BC8-488E-9665-A7CFDB1BD009@yahoo.com> References: <93F5AD73-77AD-4FF5-A54A-63D8ED0DD00E.ref@yahoo.com> <93F5AD73-77AD-4FF5-A54A-63D8ED0DD00E@yahoo.com> <4E7F2547-2BC8-488E-9665-A7CFDB1BD009@yahoo.com> Message-ID: <54090293-5E39-49C3-AE50-3859C537F833@illinois.edu> Hi Aykut! -- your plotting tool works, pretty cool! FYI I?ve released a new version 1.4.0, you can get it via curl: curl http://cmp.music.illinois.edu/courses/taube/mus205/downloads/musx-1.4.0.zip -O 1.4.0 can import Spear frame data into Spectrum objects, has demos for how to send events to supercollider synthdefs and play midi sequences using threads (Im using Python threads so your mileage will vary?) When the semester ends I will make a new github home for musx, refactor the code now that students have beaten on it, and give source code access to those that want to develop sources. ?Rick On Apr 24, 2021, at 4:47 AM, aykut_caglayan > wrote: you can use matplotlib in python to do all sorts of really sophisticated plotting. Hi Rick! I have tried to make a cheap imitation of Grace s plotting tool with matplotlib. User can add data points with mouse click and copy it to clipboard etc. whole process seems very cpu hungry though https://github.com/ayk-caglayan/graphic_composition_tool Viele Gr??e, Ayk -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Mon Apr 26 21:26:00 2021 From: iainduncanlists at gmail.com (Iain Duncan) Date: Mon, 26 Apr 2021 21:26:00 -0700 Subject: [CM] Performance of Scheme for Max + modular synth algorithmic etude Message-ID: Hi folks, just thought I'd share the fruits of one of my term projects - my first working algorithmic etude for Scheme for Max + modular synthesizer. (The recording of which may or may not have prompted the order of a bunch more modules... haha) Performance https://www.youtube.com/watch?v=rcLWTjN4qBI Walk-through of how it was made: https://www.youtube.com/watch?v=pg7B8h4yHkU Beginning of the book on writing sequencers in s4m, which has not yet gotten to the point used in the composition mind you.. https://iainctduncan.github.io/s4m-stk Hope you enjoy, as usual thanks to everyone who's work has made this possible! iain -------------- next part -------------- An HTML attachment was scrubbed... URL: From bthaleproductions at gmail.com Tue Apr 27 05:39:25 2021 From: bthaleproductions at gmail.com (Brandon Hale) Date: Tue, 27 Apr 2021 08:39:25 -0400 Subject: [CM] Performance of Scheme for Max + modular synth algorithmic etude In-Reply-To: References: Message-ID: <7841a6a6-45e7-b577-a2e0-72e131f9222e@gmail.com> Hey Iain, Thank you for sharing your work and how it was made. I would be interested in watching a livestream where you work on this in realtime, if that's something you would like to do. Did you have a score on how you altered the synthesizer, or was that improvised? Thank you again for sharing, Brandon Hale On 4/27/21 12:26 AM, Iain Duncan wrote: > Hi folks, just thought I'd share the fruits of one of my term projects > - my first working algorithmic etude for Scheme for Max?+ modular > synthesizer. (The recording of which may or may not have prompted the > order of a bunch more modules... haha) > > Performance > https://www.youtube.com/watch?v=rcLWTjN4qBI > > > Walk-through of how it was made: > https://www.youtube.com/watch?v=pg7B8h4yHkU > > > Beginning of the book on writing sequencers in s4m, which?has not yet > gotten to the point used in the composition mind you.. > https://iainctduncan.github.io/s4m-stk > > > Hope you enjoy, as usual thanks to everyone who's work has made this > possible! > iain > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist -------------- next part -------------- An HTML attachment was scrubbed... URL: From iainduncanlists at gmail.com Tue Apr 27 08:17:10 2021 From: iainduncanlists at gmail.com (Iain Duncan) Date: Tue, 27 Apr 2021 08:17:10 -0700 Subject: [CM] Performance of Scheme for Max + modular synth algorithmic etude In-Reply-To: <7841a6a6-45e7-b577-a2e0-72e131f9222e@gmail.com> References: <7841a6a6-45e7-b577-a2e0-72e131f9222e@gmail.com> Message-ID: Thanks Brandon and Michael! Brandon, I cooked up a second "orchestrator sequencer" for the score, and I talk about it later in the making of video. I will also be documenting all the code in this as part of the Scheme for Max sequencer toolkit. The orchestrator sequencer is a straightforward linear sequencer of function calls. It could be prettied up a lot with macros, but it does the job right now. Here's an example of what it looks like: from previous: (define l1a (loop-player 'loop-len 8 'outlet 0 'transpose -12)) (l1a 'set-seq 0 p1) etc the orchestratro (define s1 (event-score (hash-table :bbt (list 8 4 480)) :1:1:0 (list '(l1a 'start) ) :9:1:0 (list '(l1a 'start) '(l1b 'start) ) :25:1:0 (list ' '(l1c 'set 'transpose -5) '(l1c 'set 'on-step '(set! time-factor (+ 0.5 (* 0.5 (random 3))))) '(l1a 'start) '(l1c 'start) ) .... etc etc On Tue, Apr 27, 2021 at 5:39 AM Brandon Hale wrote: > Hey Iain, > > Thank you for sharing your work and how it was made. I would be interested > in watching a livestream where you work on this in realtime, if that's > something you would like to do. > > Did you have a score on how you altered the synthesizer, or was that > improvised? > > Thank you again for sharing, > > Brandon Hale > On 4/27/21 12:26 AM, Iain Duncan wrote: > > Hi folks, just thought I'd share the fruits of one of my term projects - > my first working algorithmic etude for Scheme for Max + modular > synthesizer. (The recording of which may or may not have prompted the order > of a bunch more modules... haha) > > Performance > https://www.youtube.com/watch?v=rcLWTjN4qBI > > Walk-through of how it was made: > https://www.youtube.com/watch?v=pg7B8h4yHkU > > Beginning of the book on writing sequencers in s4m, which has not yet > gotten to the point used in the composition mind you.. > https://iainctduncan.github.io/s4m-stk > > Hope you enjoy, as usual thanks to everyone who's work has made this > possible! > iain > > _______________________________________________ > Cmdist mailing listCmdist at ccrma.stanford.eduhttps://cm-mail.stanford.edu/mailman/listinfo/cmdist > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > -------------- next part -------------- An HTML attachment was scrubbed... URL: