Skip to content
This repository has been archived by the owner on Jan 6, 2021. It is now read-only.

Latest commit

 

History

History
180 lines (122 loc) · 7.11 KB

CHANGELOG.md

File metadata and controls

180 lines (122 loc) · 7.11 KB

CHANGELOG

0.5.0 (2019-04-13)

  • Renamed (not yet used in an Alda release) export-status command to job-status.

    I've convinced myself at this point that it's equivalent to the play-status command, so play-status is just a supported synonym at this point. In the next release of Alda, the client will send a job-status request for both play and export jobs.

0.4.4 (2019-04-11)

  • Added support for MIDI export and export-status commands.

0.4.3 (2019-01-28)

  • Refactored to remove dependency on the alda.now namespace, which is being removed from alda/sound-engine-clj. We can achieve the same functionality in alda/server-clj by using alda.sound directly.

0.4.2 (2019-01-19)

  • Add support for an instruments command, which returns a list of available instruments.

0.4.1 (2018-10-28)

  • Updates to support alda/sound-engine-clj 1.0.0, which now uses a Java MIDI Sequencer instead of JSyn to do event scheduling:

    • Removed call to alda.sound/start-synthesis-engine!, which has been removed.

    • Added a call to midi/open-midi-sequencer! when starting a worker process.

0.4.0 (2018-06-22)

0.3.3 (2017-10-07)

  • Added support for an "events" option to the "parse" command.

0.3.2 (2017-10-05)

  • Added an alda.server/*disable-supervisor* dynamic var that, when bound to a truthy value, has the same effect as the ALDA_DISABLE_SUPERVISOR environment variable.

    I needed this in order to write a convenient development task for the alda/core project. The Boot process was already running a JVM, so I couldn't really set ALDA_DISABLE_SUPERVISOR after the fact.

  • Increased the number of worker lives from 10 to 30. This effectively means that a worker will wait until it's been 30 seconds, not 10 seconds, since it received its last heartbeat from the server before giving up and killing itself. This should help with some timing issues I was seeing where the server took a little longer than 10 seconds to send a worker its first heartbeat. 30 seconds ought to be a safer timeframe.

0.3.1 (2017-06-11)

  • Added support for the stop-playback command. When a server gets that command, it sends a STOP signal to all known workers. Each worker then stops playback immediately.

0.3.0 (2017-05-27)

  • Updates for compatibility with alda/core 0.2.0, which has a brand new parser rewritten from the ground up.

    One thing about the new parser is that it doesn't generate alda.lisp code anymore, so that feature has been removed from the worker.

  • Bugfix: scores that included scheduled Clojure function calls were breaking JSON serialization. In the long term, I need to think about how these can be serialized, but in the short term, we don't really need them in the score JSON, so as a hack, we just aren't including them in the score the server returns.

0.2.0 (2017-05-25)

  • Updated ezzmq dependency to 0.5.3. This updates the transitive JeroMQ dependency from 0.3.6 to 0.4.0.

  • Partially solves #8 by implementing a job system. Requests from the client must include a jobId (a UUID generated by the client), which allows the worker to track jobs separately.

    A worker should only be processing one job at a time, but it's possible for requests to arrive out of sync, so we want to make sure that a play request followed by a play-status request will receive status for the correct score.

    There is still some work to be done here. I'd like to move the job cache into the server, so that the server can deduplicate multiple requests to play the same score (i.e. same jobId). The worker will do that, as of this release, but it doesn't really matter because multiple requests to play the same score will be handled by multiple workers, so each worker will still play the score, thinking the job hasn't been done yet. The client is currently only sending one request to play a score, so multiple play requests aren't sent, however it would be nice to be able to retry on the client side. This will be a work in progress.

  • Bugfix: don't reuse the same MIDI synthesizer instance (which now has a dirty state) after playing a score.

0.1.7 (2017-05-19)

  • Each worker process now has a lifespan of 15-20 minutes. Once its lifespan is up, it finishes doing whatever work it might be doing and then shuts down so that the server can replace it with a fresh worker.

    This ensures that available workers are always fresh (spawned within the last 20 minutes), which helps us avoid audio errors like delayed MIDI audio.

    Fixes issue #5.

0.1.6 (2017-05-18)

  • Improved the reliability of including the score map in play-status responses.

    Prior to this version, we were storing the state of a worker in three separate (isolated) atoms: current-status, current-score, and current-error. Because we were storing state this way, it was possible for one state to be updated independently of another, when we actually wanted to update them at the same time as part of a transaction. For example, the status could be updated to "playing," and then the worker could answer a request for status before it updated the score to the score it responds with, so the status and score could be out of sync.

    Clojure provides the ref type to solve problems like this; they allow you to update multiple values transactionally. As of this version, we are using refs instead of atoms, which should make the play-status responses more consistent.

0.1.5 (2017-05-17)

  • Include the score map (as a JSON string) in response to play-status requests, if the score has been parsed at that point.

    This will enable the upcoming client-side (Java) Alda REPL to determine the current instruments of the score and display them in the REPL prompt.

0.1.4 (2017-02-19)

  • Fixed a regression introduced in 0.1.3 that was causing the from and to options not to have an effect.

0.1.3 (2017-02-09)

  • Added support for play requests that have a history field for context.

    For example, given a request like this:

    {
      "command": "play",
      "history": "bassoon: (tempo 200) c d e",
      "body":    "f g2"
    }

    The server will play just the two notes f and g2, on a bassoon at 200 bpm.

0.1.2 (2016-12-07)

  • Fixed a regression introduced by 0.1.1. There was a bug causing worker processes not to cycle after suspending the process, e.g. closing and later re-opening your laptop's lid.

0.1.1 (2016-12-03)

  • Refactored JeroMQ code to use ezzmq.

  • Minor bugfix in shutdown code: in some cases if the timing was just right, a java.util.concurrent.RejectedExecutionException was being thrown. The cause of this was the blacklist-worker! function trying to schedule the blacklist removal for after the server was shut down.

0.1.0 (2016-11-19)

  • alda-server-clj extracted from the Alda main project, version 1.0.0-rc50.