| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
* 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.
|
|
* This should be largely compatible with the standard Lua interpreter.
The `arg` array is also initialized.
|
|
|
|
* 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
|
|
command line help is provided using -h or when specifying an unknown option
|
|
* 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.
|
|
|
|
* This is implemented without introducing the notion of frames into the tick() methods
since most multi-channel stream operations can be understood as duplicating the
operation on each channel.
* Instead there is only ONE explicitly multi-channel stream: MuxStream.
It can be used to construct a multi-channel stream from various normal mono streams
and is also used internally.
* MuxStreams can still be used just like any other stream since the new base class
MuxableStream will automatically apply the class constructors on each channel in order.
The channels of streams being combined must be equal, unless mono streams are involved.
* Mono-streams are automatically blown-up to multi-channel streams when involved in
operations with a multi-channel stream.
* The remaining multi-channel specific code has been isolated in Stream:foreach()
which now receives frames instead of individual samples.
* When playing() a multi-channel stream, the applause output ports are played in order.
I.e. playing a mono-stream fills output_1. A stereo stream, output_1 and output_2.
* The number of Jack output ports can be specified on the applause command line.
* All system playback ports are tried to be connected to corresponding applause output ports.
|
|
working directory
|
|
|
|
* should speed up things since the C function calls can be inlined
* the C function does only rudimentary argument checking using assert()
since they are only called internally.
This means, calling it with wrong arguments can result in controlled
crashes. This will point to programming errors since the real argument
checking is done in Lua code at stream construction.
* The MIDI*Stream.getValue() functions have been kept as wrappers around
the native functions, to ease using them in other stream implementations
that want to support MIDI natively.
|
|
|
|
* the low-level C part is now implemented in a normal
C function applause_push_sample() which is called using the FFI
API
* this is supposedly faster than the old Lua/C way, but the
speed improvement seems to be miniscule.
However changes like this are still good since they simplify
the C core.
* speed improvements will probably be larger for the
MIDI*Stream functions since here we call Lua/C functions at
sample rate.
|
|
* the server is basically a second way to modify the Lua state of Applause
* concurrently to interactive input, messages can be sent over a TCP socket
which are evaluated just like command lines.
All stdout/stderr output is returned and the socket is closed.
* Server currently hardcoded at 127.0.0.1:10000
* Interruptions are currently not possible.
This would require another thread.
* The threading could be simplified by making the applause binary
a server-only application.
The Read-Eval-Print loop could then be a standalone LuaJIT script.
|
|
and print stack tracebacks
|
|
graph without recomputation
* Since it comes with an overhead, it has to be enabled by constructing a SyncedStream
or calling Stream:sync()
* Reusing samples works by sharing generator functions and caching samples until a clock signal changes.
The clock signal is currently a global variable "clock_signal" that oscillates between
true and false.
* This means that all sample generating methods like :play() or :totable() will have
to advance the clock using the global clockCycle() function.
It is a global function, so it can be invoked more or less efficiently by the :play()
implementation (currently using the old-school Lua/C API).
These restrictions might fall when using the LuaJIT way of interacting with
native code.
* Since playback must begin from the beginning for every :play(), an explicit reset()
mechanism has been introduced which can usually be ignored in Stream implementations.
It does however allow SyncedStream to reset the generator closure.
* SndfileStream has been simplified since now it is possible to keep the file handle
open. However as long as Stream synchronization is not automatic, SndfileStreams must
be explicitly synced when using one stream multiple times.
* Syncing is thought to be performed automatically by an optimizer when one object
is used more than once e.g. in a :play() call.
* Non-synced streams are currently slightly slower than before this commit,
probably because of the additional clockCycle() call.
|
|
|
|
|
|
* there are at most 128 different MIDI notes; mtof() will now also work
for all of them
* channels have origin 1 now in the public APIs.
This is what most applications seem to use, so in order to avoid
confusion it's probably a good idea to use it as well.
|
|
* MIDIVelocityStream will report the velocities on a particular
note. This can be used to build polyphonic instruments.
* MIDINoteStream will report all possible notes on a particular
channel. The velocity of the note last triggered is also encoded
into the stream values. This can be used to build simple
monophonic instruments.
* Map bit methods to stream methods, e.g. Stream:band()
Is especially useful for streams that encode multiple values
into single integers for performance reasons.
* mtof() and ftom() methods for converting from and to MIDI note
numbers. mtof() is very efficient since its values are all
precalculated in a lookup table.
* fixed tostring() method for streams smaller than 1024 samples
|
|
* MIDICCStream provides a stream of CC values as if
polled from the controller (this is emulated in
applause.c)
|
|
jack_get_buffer_size()
|
|
|
|
* more precisely, Stream:play() will now throw
an error whenever the process receices SIGINT.
* this allows us to interrupt long playbacks
|
|
in milliseconds
* default buffer size: 100ms
|
|
* allows the Lua thread to block when the ringbuffer is full
while keeping the realtime thread (jack_process()) realtime-safe.
Hopefully :-)
* since audio generation is usually faster than consumption
(if you don't want to have buffer underruns),
this fixes audio generation longer than BUFFER_SIZE (currently 1s)
|
|
|
|
This improves the real-time properties of sample generation
since it avoids CPU spkikes.
On the other hand, this may not be ideal as playing a long streams could have
non-constant space requirements now.
A proper solution would probably involve calling the garbage collector incrementally
during the play() loop.
|
|
* implements Stream:play() using Jack as the audio backend
|
