diff options
| -rw-r--r-- | .gitignore | 2 | ||||
| -rw-r--r-- | README.md | 59 | ||||
| -rw-r--r-- | TODO | 44 |
3 files changed, 105 insertions, 0 deletions
@@ -1,2 +1,4 @@ /applause *.o + +/.applause_history diff --git a/README.md b/README.md new file mode 100644 index 0000000..bd81e57 --- /dev/null +++ b/README.md @@ -0,0 +1,59 @@ +# Applause 2 + +## Installation + +You have to manually build and install LuaJIT v2.1: + + git clone -b v2.1 https://luajit.org/git/luajit.git + cd luajit + make + sudo make install + +Furthermore, install the following dependencies: + + sudo apt-get install build-essential libreadline-dev libjack-jackd2-dev \ + libsndfile1 libasound2 feedgnuplot + +## Usage + +Start qjackctl. + +TODO: How to use jack-plumbing? + + ./applause -o 2 + +This may require root rights for accessing HID devices. +You may also add the current user to the `input` group. + +Example (one channel): + + > Stream.SinOsc(440):play() + +# Applause Clients (Editor Integration) + + echo -ne "25 \nStream.SinOsc(440):play()" | socat -,ignoreeof TCP:127.0.0.1:10000" + +See also `client.tes` for a SciTECO integration. + +# Joysticks and Gamepads + +This is supported by EvdevStream(). + +Alternatively you can use aseqjoy together with `a2jmidid --export-hw` +to expose them as MIDI events. + +# Mice + +This is supported by EvdevStream(). + +Alternatively you can use [raton](https://github.com/GModal/raton) together with `a2jmidid --export-hw` +to expose them as MIDI events. + +# Other useful programs + +* jack_rec, QJackRcd or Audacity to record sessions +* midisnoop for diplaying MIDI events +* jack-keyboard for producing MIDI note events +* [midicontroller](https://sourceforge.net/projects/midicontrol/) for producing MIDI CC events +* MIDI Tracker ??? +* evtest to find and test HID devices @@ -0,0 +1,44 @@ +# Bugs + +* Stream:foreach() cannot be interrupted + Perhaps C core should export an interrupted variable that we can check from Lua.i + For Stream:play() this is solved differently. +* EvdevStream("TrackPoint"):evrel('REL_X'):scale(440,880):SinOsc():play() + Afterwards even Stream.SinOsc(880):play() will stutter. + However, this seems to happen only with the builtin speakers. + +# Features + +* Line Continuations on the CLI (like Lua's CLI) +* CLI auto completions via libreadline +* OSC support +* Audio input (see inputstream branch) +* File writing during live playback to avoid having to use jack_rec. +* Multi-core support via GStreamer-like queue: + https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-plugins/html/gstreamer-plugins-queue.html +* Stream optimizer + * Automatic caching (finding identical subtrees) + * Automatic paralellization + * ... +* Documentation. + Either we use LDoc or manually write a Markdown file. + +# Improvements + +* add optional Stream:gtickCtx() containing potentially real-time unsafe code. + Higher-order streams call Stream:gtickCtx() for all dependant streams only + once in their own gtickCtx() function. + This will allow gtick() to be called in tick-functions (that must be real-time safe). +* Inconsistent signal normalization. + Some signals like Stream:CC() are not normalized to [-1,1], so you need + special scaling methods like Stream:ccscale(). + The supposed advantage is that often a signal between [0,1] is needed, so you only + need a single division. E.g. Stream:mul(Stream:CC(...) / 127). + On the other hand, with normalized outputs, you could also write Stram:mul(Stream:CC(...):scale(1)). + Or there could even be a Stream:vol() method that takes signals between [-1,1]. + The question is whether the JIT compiler is smart enough to optimize this code. +* Does the compiler currently produce SIMD instructions? + Perhaps we need blockwise processing to faciliate those optimizations. + Unfortunately, this would complicate all of the code. + Unless we could define a block with metamethods to allow basic arithmetics to be + performed just like on scalars. |