Hey hey,
if a simple - possibly outdated - documentation can help, I'd be happy about
any pointer. Current GTK+ and QT documentation comes with far too much
overhead, even in the "trivial" basic apps.
Consider this: An application with a toggle button (on/off), some load from
file button and a class holding one bvoolean value connect to the on/off
button. The class could look like this:
class Data
{
public:
Data(bool value): its_value(value) {}
~Data() {}
void set(bool value) { its_value = value; }
bool get() const { return its_value; }
private:
bool its_value;
};
The button is connected to a Data object, via a signal, so its set(bool)
function is called.
The load function will load a value from a file.
How would you normally reflect that on GUI? What's the method to not
only set the Data object value, but also the corresponding button state?
What's the current practise to make this two-way connection? Combine
both button and object in a wrapper? Have some other kind of signal?
Simple change button state in every place the Data object is changed?
As stated above: even an old resource or documentation for a limited UI
library will do, as long as the method shines through with little
overhead and without anything like QML or a UI builder.
Best wishes and thanks for any help,
Jeanette
--
* Website: http://juliencoder.de - for summer is a state of sound
* Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g
* Audiobombs: https://www.audiobombs.com/users/jeanette_c
* GitHub: https://github.com/jeanette-c
Make all the clouds disappear
Put all your fears to rest <3
(Britney Spears)
Hi.
std::span<>, std::lerp, std::clamp, just to name some, C++
standardisation has been good to audio devs in recent years.
I always wanted to have a concise modern C++ wrapper class for a JACK client.
Here is my latest (very incomplete) attempt:
https://github.com/mlang/ladxx20
#include <algorithms>
#include <processor.hpp>
using namespace std;
struct null : lad::processor {
null(): lad::processor("null", 0, 1) {}
void process(audio_buffers audio) override {
for (auto buffer: audio.out) ranges::fill(buffer, 0.0);
}
};
int main() {
null client;
client.start();
this_thread::sleep_for(chrono::seconds(5));
return EXIT_SUCCESS;
}
The idea is to make it as easy as possible to write custom JACK clients.
No callback registration, no port naming, no remembering flags.
Just declare a class and implement a single method.
Buffers are passed to you as spans, so modern for-loop and
all stl algorithms can be used immediately.
This is sort of like a template project for now.
Clone and write your own tool to experiment with DSP.
If you have productive feedback, I am all ears.
I am not looking for language flamewar activity though.
If you are not into C++ for some reason, just go on, there is nothing to see here...
--
CYa,
⡍⠁⠗⠊⠕
----- Forwarded message from Fons Adriaensen <fons(a)linuxaudio.org> -----
Date: Thu, 19 May 2022 22:22:12 +0200
From: Fons Adriaensen <fons(a)linuxaudio.org>
To: "Jeanette C." <julien(a)mail.upb.de>
On Thu, May 19, 2022 at 07:52:33PM +0200, Jeanette C. wrote:
> I know about one or two applications that use the timeofday/sleep mechanism,
> but from first hand experience I know that these tend to drift and wobble.
The key to do this is to have a high priority thread waiting for an
*absolute* time, and then each time increment that time by the
required delta.
Note that this is fundamentally different from using sleep or similar
functions. With those you wait for a certain time. So if your previous
event was late, the next one will be late as well just because you
start waiting for it too late. So all the errors will add up, and
you will *never* get the correct event frequency.
When you wait until an absolute time, any latency on the previous
event does not affect the following ones. The errors don't accumulate.
So what to wait for ? That could be any system call that takes an
absolute timeout rather than a maximum waiting time. On Linux I'd
use something like sem_timedwait(). To set the initial timeout,
the corresponding clock can be read with clock_gettime(), using the
CLOCK_MONOTONIC option.
Don't know about Apple. Last time I looked it didn't have clock_gettime(),
but it has gettimeofday(). Note that it is not gettimeofday() that is
the cause of the problem you mentioned, it is using sleep() or usleep().
Ciao,
--
FA
----- End forwarded message -----
Hey hey,
I wonder how would you best derive a steady MIDI clock in software for a cross
platform application? Cross platform in this case almost certainly means Linux
and mac.
I know about one or two applications that use the timeofday/sleep mechanism,
but from first hand experience I know that these tend to drift and wobble.
This becomes apparent when syncing a synth with clock synced delays to that
clock. There is a slight chorus effect. Furthermore, subsequent renderings of
the same song is too much out of sync. Exact re-runs are necessary with
connected mono timbral instruments that have to contribute several sounds to
the same song.
I did think about using RtAudio with a very low blocksize. The callback
function could supply a steady time source at the connected soundcard's
samplerate (or any subdivision thereof). Is that feasible? Or will some
function from any of the Boost libraries do? I haven't found the right one
yet. The Thread library contains its versions of sleep (i.e. sleep_for) and
other libraries supply all kinds of finely grained time formats. But
apparently, they too are based on a timeofday based mechanism.
Being new to this kind of task, I am a bit at a loss. So any practical
pointers and hints are welcome.
Best wishes,
Jeanette
--
* Website: http://juliencoder.de - for summer is a state of sound
* Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g
* Audiobombs: https://www.audiobombs.com/users/jeanette_c
* GitHub: https://github.com/jeanette-c
If there's nothing missing in my life
Then why do these tears come at night <3
(Britney Spears)
Hello all,
Version 0.10.1 of Aeolus is now available at the usual place:
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html>
* Cleanup, maintenance, bug fixes.
The biggest bug was probably that the 'instability' and 'release
detune' parameters set in the stops editor were correctly stored
into the *.ae0 files which contain the stop definitions, but NOT
copied into the *.ae1 files which contain the precomputed wavetables
and run-time synthesis parameters.
So they would work only when the wavetables were recomputed
on a running Aeolus instance (e.g. by changing tuning or
temperament), and not when previously stored ones were reloaded.
This makes quite a difference, as without the random delay
modulation which is controlled by 'instability', the looped
parts of the wavetables just become a static sound.
You may also get stops-0.4.0. This includes some tweaks that I
have done on my local copy over the past years, but is probably
not much different from 0.3.0. You may need to modify your
~/.aeolusrc to use these.
-------
Apart from bug fixes, this will be the last release using the
current Aeolus framework.
A completely new one is in the pipeline, but it still requires
a lot of new code, testing and tuning. This will provide:
* 'Chiff', the filtered noise that some pipes generate.
I've finally found an algorithm that produces realistic
results and that is efficient enough to work on lots
of pipes.
* Using multiple CPU cores.
* Higher order Ambisonics output.
* Binaural output (with optional head tracking).
* Full separation of UI and synthesis processes,
connected via a network connection.
Ciao,
--
FA
