| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* It still results in gaps (???).
Under FreeBSD, even the expression `InputStream():play()` produces noise.
Apparently, there is some kind of data corruption.
* it's probably necessary to increase the input buffer size
and tell Jackd about the difference (output - input buffer size) as
an additional latency.
|
|
* This allows the native syntax `for f in Stream:iter() do ... end` without using lambda
functions.
Also you can use `break` and `return` statements.
* On the other hand we cannot exploit the extended xpcall() semantics and had to introduce
another lambda in Stream:play().
* In general the number of function calls per tick stays the same.
Stream:gtick() itself could be used as an iterator, but Stream:iter() adds checking for CTRL+C,
resetting of the sample cache and binding functions.
|
|
* Especially useful to generate PDF plots for my thesis.
|
|
|
|
|
|
playpack speed
* The old implementation was simple but severely limited:
* the resample factor (playback speed) could only be scalar
* for infinite source streams, the algorithm would require infinitely growing memory.
The algorithm therefore also wasn't realtime-safe and quite slow (probably because of reallocations).
* This could be made to work with stream-factors if the source stream is infinite,
but we couldn't get rid of the memory requirements due to being based on IndexStream.
* Instead, there is a custom ResampleStream now that backs Stream:resample().
It also performs linear interpolation but has constant memory requirements and works with factor-streams.
Even for finite source streams and constant factors this implementation will be faster and more
real-time safe.
* You cannot play backwards, due to missing buffering.
This can still be done manually using IndexStream if necessary.
|
|
instead directly from Lua
* the structure is highly platform-dependant and might even differ between 32-bit and 64-bit systems
* in particular this fixes EvdevStream on FreeBSD
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* license of the project is GPLv3 now
|
|
* This still refers to a wave file that shouldn't be checked in.
|
|
* Allows one-time analysis of arrays or short streams.
* Transformation on real-time streams
* Magnitude and phase extraction
* Windowing (only Hamming for the time being).
|
|
* Inspired by APL's partition function, although this always partitions into
chunks of the same size.
* Meant to be used for real-time FFT analys and synthesis.
* Added Stream:each() and Stream:reduce() as APL-like aliases for
Stream:map() and Stream:fold().
|
|
|
|
* This now preserves the original traceback.
|
|
* Just like the original LuaJIT interpreter, this will use a hook to automatically
raise an error from Lua code.
* Unfortunately, as long as Jit compilation is enabled, this cannot reliably work.
Therefore we still set an `interrupted` flag that must be
polled from tight loops.
* Instead of polling via applause_push_sample() which gave interruption-support only
to Stream:play(), we now have a separate checkint() function.
* checkint() should be manually added to all tight loops.
* Stream:foreach() and everthing based on it is now also supporting interruptions
(via checkint()).
* This internally works via applause_is_interrupted().
A C function was exposed only because LuaJIT does not support volatile-qualifiers and
would optimize away reads to the interrupted-flag.
As a side effect, we can also reset the hook.
* Flags set in signal handlers should be `volatile`.
* Added likely() and unlikely() macros to C code.
* Updated sample.ipynb Jupyter notebook: Everything important is now supported, albeit
requiring custom ILua patches.
|
|
|
|
* Renders SVG into a cell instead of a separate window
* currently requires some not-yet-merged patch for ILua (see https://github.com/guysv/ilua/issues/5)
|
|
display graphics and rich text
|
|
* This is at the very least cool to have and will be worthwile to write about in the dissertation.
* Added ilua-wrapper.sh script which can be used as the ILua interpreter and/or can be symlinked to `lua` in PATH,
so ILua will pick up Applause even in Notebooks without any additional tweaks.
|
|
* This should be largely compatible with the standard Lua interpreter.
The `arg` array is also initialized.
|
|
encoders)
* currently, this does only support two's complement encoding of signed 7-bit integers
|
|
Stream:ccscale()
* Stream:CC14() allows reading 14-bit CCs (split over two 7-bit MIDI messages).
It's actually capable to handle regular 7-bit controllers just fine.
The question is whether we still need a distinction between Stream:CC() and Stream:CC14().
Stream:CC14() has a slight overhead, but only when actually receiving MIDI messages.
* Stream:CC14() and Stream:CC() output values normalized to [-1,+1] now.
We actually never made use of raw CC values and the scaling can be done only once whenever
a matching MIDI message is received, so the runtime overhead is irrelevant.
* This means we could also get rid of Stream:ccscale() now.
Just use Stream:scale() from nowon.
* Use Stream:scan() now whenever relying on previous values.
That way, you can often avoid having to keep an accumulator variable in the closure.
|
|
* The old implementation would require scaling operations at sample rate, even though
the value changes only very seldom.
* We are working with fractions, so we don't actually need to store the unscaled value in the closure.
|
|
* Iterating by /dev/input/eventX ids was too simplistic as there can easily be gaps.
* Instead, we now iterate the directory using opendir(), readdir() etc.
* Unfortunately, struct dirent might not be easily definable portably. (FIXME?)
* Also added EvdevStream.list(), so you now longer have to invoke evtest for finding out ids and names of HID devices
for EvdevStream:new().
|
|
pressed, as it was previously documented
|
|
|
|
|
|
|
|
* in particular: SndfileStream(...):sub(...) for multi-channel audio files.
* The fix is more of a workaround just like the initial skipping of samples by sub()
is a workaround.
I couldn't yet think of a way how to seek in streams elegantly.
|
|
|
|
* gives a useful overview of everything supported right now
* especially the type documentation is useful, as these things are not self-evident in Lua (because of dynamic typing).
* The LDoc page can later be published as the Github pages of the project.
This can even be done automatically by a Github action.
However, we should first make sure that it's okay to publish the project before defending the thesis since
Github pages will always be public even for private repositories.
* Documentation of command-line parameters is lacking (TODO).
* It may be possible to use types like "Stream(number)" to describe streams of numbers.
The LDoc documentation mentions boxed types.
Perhaps there can even be Streamable(number)?
* We are also lacking good example programs and/or introductory material.
|
|
|
|
* analyzing the bytecode via tostream(...):jdump() has shown that this might be more efficient
|
|
|
|
directly as well
|
|
|
|
|
|
|
|
|
|
* common definitions are now in midi.h
|
|
|
|
* This works for relative, absolute and keyboard devices
* devices can be grabbed, so they do not interfere with the rest of the system
|
|
* some internal datastructures were freed, but Jack was not properly shut down.
This resulted in occasional crashes on shutdown.
* The (incomplete) cleanup code has been commented out,
which should work for the time being.
Of course, the program should clean up properly but this is tedious
and the internal datastructures will change in the forseeable future.
|
