Due to terminal health problems, I am no longer able to further (re)develop het RME hdspe driver I started about a year ago. If anyone would love to take over, please drop me a message. I will transfer the github repositories (https://github.com/philippebekaert <https://github.com/philippebekaert>) to you, pass on all documentation I have, and bring you in contact with the people at RME I have been working together.
Let me know.
Best,
Philippe.
liquidsfz-0.3.0 has been released
The main goal of liquidsfz is to provide an SFZ sampler implementation
library that is easy to integrate into other projects. A standalone jack
client and a LV2 plugin is also available.
liquidsfz is implemented in C++ and licensed under MPL-2.0. The release
tarball can be downloaded here:
https://github.com/swesterfeld/liquidsfz#releases
or from github
https://github.com/swesterfeld/liquidsfz/releases/tag/0.3.0
Overview of Changes in liquidsfz-0.3.0:
* Change license to MPL-2.0
* Load sample data on demand (preload start, background load as needed)
* Improve sound quality by using better interpolation / resampling
* Support CC7=Volume and CC10=Pan if not defined in .sfz file (#30)
* Various performance optimizations
* Fix LFO ranges for square like LFOs
* Implement sustain loops (loop_mode=loop_sustain)
* Added new public API functions for new features
* Make it possible to use absolute paths in .sfz file
* Use mmap() for soundfiles on 64bit platforms
* Add a few new commands / command line options to liquidsfz jack client
* Statically linked plugin is compiled using Ubuntu 18.04 (instead of 16.04)
* Minor fixes and cleanups
--
Stefan Westerfeld, http://space.twc.de/~stefan
The FFADO project announces the availability of FFADO version 2.4.6. This
is a bug-fix release to address issues encountered since version 2.4.5.
This is a source-only release. It can be downloaded from
http://ffado.org/files/libffado-2.4.6.tgz
A release announcement can be found at
http://ffado.org/posts/ffado-2.4.6-release/
Changes since FFADO 2.4.6:
* Address additional type-related issues encounted in ffado-mixer when using
python 3.10. Components affected were the MatrixMixer control and the
M-Audio device mixer.
Thanks to those who have helped with this release, including Nils
Philippsen, Edmund Raile and Salvador O.G.
Jonathan Woithe
(on behalf of ffado.org)
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,
⡍⠁⠗⠊⠕
