Fork me on GitHub
#alda
<
2016-01-21
>
dave00:01:46

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

yjmbo02:01:59

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

yjmbo03:01:10

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

dave03:01:43

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

dave03:01:18

it works in the alda REPL, at least

dave03:01:31

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

dave03:01:03

the scheduled function story could be improved, i think

yjmbo03:01:40

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

dave03:01:34

at the moment it's an http server

yjmbo03:01:00

difficult to make that timing-sensitive ...

yjmbo03:01:02

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

yjmbo03:01:40

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

dave03:01:50

actually, this is interesting to think about

dave03:01:06

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

dave03:01:24

i might explore zmq

yjmbo03:01:56

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

dave03:01:38

rabbitmq is pretty good -- we use that at work

yjmbo03:01:26

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

yjmbo03:01:10

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

dave03:01:38

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

dave03:01:15

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

dave03:01:41

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