This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-21
Channels
- # aatree (88)
- # admin-announcements (14)
- # alda (26)
- # announcements (4)
- # avi (6)
- # aws (7)
- # beginners (80)
- # boot (268)
- # braid-chat (58)
- # cider (4)
- # clara (54)
- # cljs-dev (16)
- # cljsrn (27)
- # clojars (13)
- # clojure (123)
- # clojure-chicago (2)
- # clojure-czech (8)
- # clojure-france (5)
- # clojure-hamburg (2)
- # clojure-miami (6)
- # clojure-nl (5)
- # clojure-russia (285)
- # clojure-spain (2)
- # clojurebridge (3)
- # clojurescript (137)
- # code-reviews (14)
- # community-development (6)
- # core-async (8)
- # core-matrix (10)
- # cursive (2)
- # datascript (1)
- # datomic (24)
- # dirac (2)
- # emacs (5)
- # hoplon (4)
- # incanter (6)
- # jobs (7)
- # ldnclj (42)
- # ldnproclodo (2)
- # leiningen (1)
- # mount (60)
- # off-topic (15)
- # om (134)
- # onyx (65)
- # perun (4)
- # portland-or (2)
- # proton (15)
- # random (1)
- # re-frame (24)
- # reagent (7)
- # testing (4)
- # yada (9)
Thanks Dave ... CRAM seems like something that would be pretty difficult to achieve with standard notation. I've been looking at compressorhead recently, their robot players can certainly play the guitar/drums in ways that humans can't, and perhaps notation like this would be interesting to them too ...
anyone asked for karaoke lyric support? I can see a 'voice' that plays text strings with the same durations as the notes, and plays these by printing them out in advance of the actual note ...
you can do something karaoke-like by using scheduled function events: https://github.com/alda-lang/alda/blob/master/doc/inline-clojure-code.md#scheduling-custom-events
it's not ideal though, as you can't see the printing happening from the client, it happens on the server
There isn't really a cross-platform way to talk to the server; perhaps it should open a ZeroMQ pub socket and chuck data into there ... leave it up to the clients to figure out how to consume that
in the http model, the client has to keep on polling the server to look for an update; in an MQ, the server can spit out messages at the time intervals it chooses
http is rarely 'best', but it is generic & well-known. ZeroMQ is awesome Other MQs are fine too
the timing problem is how predictable the packet output will be from the server's perspective, you have to know how long it'll take to get a packet on to the wire in order to be able to sync properly I guess
So ZMQ is very lightweight from that perspective ... but I guess they'll all be predictable enough if the end-goal is to fit in to a human's reaction time