| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
channels and libsndfile format
|
|
command line help is provided using -h or when specifying an unknown option
|
|
|
|
vice versa
* mton() can handle MIDINoteStream values just like mtof()
* both are exposed as Stream methods as well (e.g. Stream:mton())
* MIDIVelocityStream accepts note names now as well in addition to MIDI note numbers
* added scoping to the cache used by mtof()
|
|
|
|
* properly named attributes can be used instead of putting all
stream arguments into a `streams` attribute. This is no longer
necessary since there is no more Stream:reset() method.
|
|
* this function is not the tick function itself but rather a generator
(returning the tick function).
* Calling these methods gtick() is less confusing but still concise.
|
|
* allows a stream of note velocities to trigger a note-on and note-off stream.
* usually used on a MIDIVelocityStream
* allows a single note to be triggered including attack, sustain and decay
phases
* by letting the note-on and note-off streams depend on the note/velocity stream,
the note can use the NOTE ON velocity.
* The InstrumentStream constructor will also accept functions on the note_stream,
so it is possible to define the note-on/off streams depending on the velocity stream
on a single line of source code.
* A NOTE OFF velocity is currently not used, though that could be achieved by
letting MIDIVelocityStream generate negative numbers for NOTE OFF velocities.
* This will only work with a single note (ie. a fixed frequency);
when wanting to play polyphony, users will have to mix many different InstrumentStreams, e.g.
iota(69, 79):map(function(note)
return MIDIVelocityStream(note, 1):instrument(function(v) return InstOn(note, v) end,
InstOff(note))
end):fold(function(x,y) return x+y end):ravel()
|
|
* the syncing had some serious issues: It was not possible to repeat
a synced stream since its tick() iterators were not independant.
E.g. Foo = Bar:sync(); (Foo..Foo):play()
would not have the expected result (Bar..Bar):play()
* syncing required the Stream.reset() mechanism
* instead of syncing, we now do caching (CachedStream) in a dedicated
sampleCache table. Instead of alternating the clock signal, the
cache is now simply table.clear()ed for each output sample.
This results in some allocation overhead on the first sample since
sampleCache will not yet have its final size.
(Although this overhead could be avoided by counting the
number of cached streams recursively and allocating sampleCache
using table.new())
* SndfileStream suffered from similar problems, it could not be repeated
because every object's tick() shared the same handle.
Instead every tick() now opens its own handle.
This means that using the same SndfileStream multiple times no longer
requires explicit syncing/caching and SndfileStreams can be repeated.
On the down-side we must check whether the file changed after
the initial object construction.
|
|
* Unicode identifiers allowed in LuaJIT 2
* We add the shortcuts directly to applause.lua but using Unicode escapes.
Thus we don't have to maintain a separate file and we can still edit applause.lua
using a non-UTF editor like SciTECO
* Stream:sub (subtract) renamed to Stream:minus. This was previously overwritten by
the SubStream wrapper.
|
|
* DelayStream must currently have a constant length (ie. duration)
* Stream:mix() allows mixing two streams by a constant wet/dryness factor.
0 means only the first stream, while 1 is only the second stream.
* Stream:echo() builds on this for an echo effect with constant delay
and wetness factor. The source stream is automatically synced.
|
|
* use socat now for SciTECO integration. It correctly shuts down
the connection when interrupted.
This has the effect as cancelling the current command, just as
^C would on the Applause command line.
|
|
|
