alda

WE'VE MOVED! Join us at: http://slack.alda.io
dave 2016-01-21T00:45:46.000140Z

@yjmbo: you might consider talking about CRAM, it's a pretty unique feature

2016-01-21T02:59:59.000143Z

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 ...

2016-01-21T03:05:10.000144Z

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 ...

dave 2016-01-21T03:22:03.000145Z

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

dave 2016-01-21T03:23:43.000147Z

it's not ideal though, as you can't see the printing happening from the client, it happens on the server

dave 2016-01-21T03:24:18.000148Z

it works in the alda REPL, at least

dave 2016-01-21T03:24:31.000149Z

or if you run an alda server in the foreground by running alda server

dave 2016-01-21T03:25:03.000150Z

the scheduled function story could be improved, i think

2016-01-21T03:34:40.000151Z

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 :simple_smile:

dave 2016-01-21T03:35:34.000152Z

at the moment it's an http server

2016-01-21T03:36:00.000153Z

difficult to make that timing-sensitive ...

dave 2016-01-21T03:36:28.000154Z

how so?

2016-01-21T03:37:02.000155Z

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

2016-01-21T03:37:40.000156Z

not a big deal, I'm not really into karaoke myself, lol

dave 2016-01-21T03:37:43.000157Z

haha

dave 2016-01-21T03:37:50.000158Z

actually, this is interesting to think about

dave 2016-01-21T03:38:06.000159Z

in the back of my mind i've been wondering if an http server is the best thing to do

dave 2016-01-21T03:38:24.000160Z

i might explore zmq

2016-01-21T03:38:56.000161Z

http is rarely 'best', but it is generic & well-known. ZeroMQ is awesome :simple_smile: Other MQs are fine too :simple_smile:

dave 2016-01-21T03:39:38.000162Z

rabbitmq is pretty good -- we use that at work

2016-01-21T03:40:26.000163Z

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

2016-01-21T03:41:10.000164Z

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 :simple_smile:

dave 2016-01-21T03:43:38.000165Z

i think getting reliable and fast responses is what i'm mostly concerned with

dave 2016-01-21T03:44:15.000166Z

i've noticed some weird behavior with the http server if i leave it running for a long time and/or close and re-open my macbook

dave 2016-01-21T03:44:41.000167Z

another thing i'm curious to explore is the new socket server repl in clojure 1.8