Hi all!
I have recently released the second preview of SoundTracker v1.0.3. Here
are new features of this pre-release:
* General:
- Copy / Cut buffers contents can be viewed (yaliaev)
- Quick instrument selection (yaliaev)
* Sample editor:
- Automatic Gain Control sample processing procedure (yaliaev)
- Selection from loop and to the left / right of the exising selection
(yaliaev)
- Navigation improved (yaliaev)
- Optional loop playback when playing selection (yaliaev)
- Waveform value indication (yaliaev)
- Loop Facility, an advanced tool for manipulations with sample loops
(yaliaev)
* Fixes and minor improvements (yaliaev)
I invite everyone to test this pre-release and look forward your
feedback (bug reports and feature requests). Also, with this release I
announce feature freeze, this means that pre2 includes all features of
the "mature" release.
Download: https://sourceforge.net/projects/soundtracker/files/
Regards,
Yury.
Over a hardware DIN port this is of course approx. 1mS, but does anyone know
if it's the same over a USB link?
Presumably, it would have to be if the source was also sending to the DIN
route.
Following on from that, what about the multiport adaptors that have 4 hardware
ports going down one USB cable. I would guess that these could be interleaved
so that (assuming the 1mS granularity holds) the overall rate is still 1mS with
the ports spaced up to 250uS apart.
This is of course pure guesswork, so I'd be interested if anyone knows exactly
what the situation is.
--
Will J Godfrey
https://willgodfrey.bandcamp.com/http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
As a {cough} sprightly 73 year old I'm starting to have sight difficulties -
especially dark colours and night vision. With the current trend of dark GUI
shades this presents me with a problem when using new software. Some, but not
all of these programs do provide alternatives. However they default to dark, and
I have a hard time finding how to change this, or indeed, even seeing which
options are available.
Therefore please consider either defaulting to a lighter layout, or
alternatively, at first time start give a choice using a system alert/choice
window. If you don't provide a lighter option, maybe consider doing so.
--
Will J Godfrey
https://willgodfrey.bandcamp.com/http://yoshimi.github.io
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
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
Hello all,
zita-audiotools-1.3.0 and zita-jacktools-1.6.0 are now available at
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html>.
If you have previous versions, installing these updates will require
some extra work. This is for two reasons:
* The python package names have changed:
audiotools -> zita_audiotools
jacktools -> zita_jacktools
* The setup.py files now use setuptools instead of the deprecated
distutils, and will install a python 'egg' directory.
This requires the following actions:
* Before installation, remove all traces of any previous versions
from your python site-packages directory. Then just make; sudo
make install; sudo make clean.
* In existing applications, the import statements must be modified
to refer to the new package names.
Thanks to Marc Lavallée for both suggesting the name change and
testing the new releases.
Ciao,
--
FA
