Age | Commit message (Collapse) | Author | Files | Lines |
|
* 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.
|
|
|
|
* introduced MIDIStream which provides a raw stream of MIDI messages
(mangled into a single integer).
* MIDIVelocityStream has been replaced by
MIDIStream:mvelocity()
* MIDICCStream has been replaced by
MIDIStream:CC()
* MIDIStreams can be directly passed to DSSIStreams
|
|
* The LADSPA module has been extended to support DSSI plugins as well.
If DSSI support is detected, the first input stream is considered a MIDI
event stream.
* The MIDI event handling must be updated to allow streams of MIDI messages
for this to be useful.
* ladspa.lua has been subsequently renamed to dssi.lua
|
|
* this has long been broken. ZipStream implicitly assumes an associative
operation when "inlining" nested ZipStreams.
Since the above mentions operations are not associative,
the result was a faulty calculation.
Example: s1 - (s2 - s3) was calculated like (s1 - s2) - s3.
* For the time being, the inlining is avoided by using unique
lambdas.
|
|
|
|
* only really useful for DSSI plugins that do not expose a LADSPA
entry point and do not need MIDI NOTE commands (ie. effects).
* full DSSI support might be added in a subclass that adds a MIDI
command stream.
Applause's MIDI handling could be extended to directly provide
such streams (ie. by having a queue of these events and producing
0 if they are empty) with MIDICCStream and MIDIVelocityStream being
refactored into pure Lua classes which extract the relevant
information and cache the previous value.
|
|
* User-provided arguments should correspond to the n'th input port
instead of the n'th overall port.
This failed if output ports were mixed with input ports (or come first)
in the list of ports that the LADSPA plugin defines.
|
|
* When specified as part of a port-mapping array or list, they
are automatically expanded.
I.e. if `stream` is stereo, LADSPAStream(..., stream) is equivalent to
LADSPAStream(..., stream:demux(1), stream:demux(2))
* This is often handy because stereo input ports are usually
defined consecutively by LADSPA plugins.
|
|
* Constants were converted to infinite streams.
This allows them to be handled specially. They are stored in their own
input buffer now, initialized and connected once but need no ticking.
* In contrast to the Applause primitives, this can be done centrally and
for all possible LADSPA plugins.
* This gives a speed increase of up to 20% if all input ports are mapped
to constants (measured with the "sine" plugin).
|
|
* E.g. LADSPAStream("sine", 880):play().
The sine plugin is currently twice as fast as the native Applause implementation
even though a block size of 1 sample is used (ie. compared to Stream.SinOsc).
* all LADSPA features should be supported
* Takes arbitrary Streams as input and produces a normal Applause stream.
* multi-channel output plugins supported
* LADSPA port mapping is possible by array, by name and by argument
list.
* Even though LADSPAStream is not muxable (it is more like SndfileStream),
every input stream or default value is currently converted to a Stream.
This can be optimized by storing scalars in their own arrays.
They don't have to be ticked.
|
|
it should have no runtime penalty and eases debugging core dumps
|
|
* all of these filters were ticking the input stream twice, effectively
resulting in the input signal to be pitched.
* the quality factor should be allowed to be a stream since there is no
technical reason against it.
|
|
metamethod
|
|
stream determines the length
* this makes them compatible with the scalar operations like Stream:mul(), Stream:add() etc
when the right stream is a scalar turned into an infinite stream.
* Consequently, both operations could be merged: Stream:mul() and the __mul operator
are now synonymous.
The methods are kept since they are sometimes handy to avoid braces when writing
from left to right.
Since the old way of mapping a stream for scalars is still a bit faster compared to using
a ZipStream, this method is still applied for scalars as an optimization.
Both the methods and the operators will now work with scalars and arbitrary streams, though.
* This means that many primitives based on scalar operations previously will now
work with streams as well. This applies to Stream:scale(), Stream:ccscale(), Stream:mix(),
Stream:pan() and even line().
* Added Stream:min() and Stream:max() as shortcuts for binary operations from the
math package.
* All the binary operations from the math and bit packages will work with streams now
as well (without performance penalties).
* Stream:clip() has been revised and works with stream arguments now as well.
* Optimized ConcatStream, MapStream, ScanStream, FoldStream and esp. ZipStream.
* The new ZipStream semantics allow for new useful idioms.
For instance, to add an envelope to an infinite stream (stream*env), a SubStream
was often necessary to restrict the resulting stream to the length of the envelope
as in (stream*env):sub(1,env:len()).
This can now be written more elegantly as (env*stream).
To extend a stream to infinite length, you may still write 0+stream or
stream..0
|
|
* SawOsc has been broken for a long time
* phases are useful since they are trivial to implement at the Phasor level
and cumbersome to emulate using SubStream (basically you would need
:sub(sec(1)/freq*phase)).
Also, this way, phases will work even for modulated frequencies
or if the frequency is unknown.
They should come with no additional runtime overhead.
|
|
|
|
InstrumentStream for finite on-streams
|
|
* an explicit FFI finalizer must be used.
* fixes "Too many open files" errors
|