| Age | Commit message (Collapse) | Author |
|---|
|
This more generic name will better reflect the purpose of the widget in
the future, as this commit begins the long process of enhancing the
widget into a container for all controls of Piano's currently selected
track.
|
|
This exposes that the export is pretty slow, but it's much nicer than
having the GUI lock up for 20s :^)
|
|
The audio player loop uses custom IPC plumbing to safely bypass any
event loop shenanigans. There is still work to be done, but this already
improves the realtime capabilities of Piano.
|
|
:greenlinus:
|
|
Otherwise, we end up propagating those dependencies into targets that
link against that library, which creates unnecessary link-time
dependencies.
Also included are changes to readd now missing dependencies to tools
that actually need them.
|
|
This automatically creates the correct collection of name label, value
label and "editor" (knob, checkbox, dropdown) depending on the processor
type and layouts them vertically.
|
|
This is a tangly commit and it fixes all the bugs that a plain move
would have caused (i.e. we need to touch other logic which had wrong
assumptions).
|
|
|
|
These widgets attach to a processor parameter and keep the two sides in
sync. They will become very useful for smart processor interfaces.
|
|
This is the first step in transitioning Piano to a full LibDSP backend.
For now, the delay effect is replaced with a (mostly identical)
implementation in LibDSP.
The new ProcessorParameterSlider attaches to a LibDSP::Processor's
range parameter (LibDSP::ProcessorRangeParameter) and changes it
automatically. It also has the ability to update an external GUI::Label.
This is used for the three delay parameters and it will become useful
for auto-generating UI for Processors.
|
|
Piano now has a toolbar allowing the playback to be paused,
or to be stepped forward or back a note.
|
|
This adds component declarations so that users can select to not build
certain parts of the OS.
|
|
|
