Hi folks,
Some of you may recall that about ten years ago I wrote some LADSPA and DSSI plugins and hosted them on a Trac install on www.nekosynth.co.uk until I moved away from doing music with computers, and gradually the site became abandoned and the domain lapsed.
Someone pointed out that the site is back up on https://www.nekosynth.co.uk with a load of content downloaded from archive.org and indeed
there it is - loads of it although the audio examples are missing.
This is seriously weird. Like, really, really weird.
It wasn't one of you lot, was it?
I'd love to try and get in touch with whoever put considerable effort into setting it up. If anyone knows anything I'd appreciate the information.
--
Gordonjcp
DrumGizmo 0.9.19 Released!
DrumGizmo is an open source, multichannel, multilayered, cross-platform
drum plugin and stand-alone application. It enables you to compose drums
in midi and mix them with a multichannel approach. It is comparable to
that of mixing a real drumkit that has been recorded with a multimic setup.
This release is a feature release with some rather interesting new
features in it.
Highlights:
* Default midimaps now read from drumkit file so no explicit loading
of midimap are needed for kits that provide these.
* Add OSX retina display UI scaling.
* Sample selection default values improved
* UI rendering speed improvements
* New powermap feature, to make it easier to get a good natural
feeling when playing a midi-drumkit.
* Improved dgvalidater tool to include a lot more validation checks.
* Add gettext support to plugin UI with French translation.
* Per instrument voice limit feature to enable playing very fast with
low latency without the engine dropping out.
* Resampling quality (and thereby cpu usage) can now be controlled.
And a lot of bugfixes.
As usual read the detailed description of all the new shiny features,
see the detailed changelog: [1].
And now, without further ado, go grab 0.9.19!!! [2]
[1]: https://drumgizmo.org/wiki/doku.php?id=changelog:drumgizmo-0.9.19
[2]: https://drumgizmo.org/wiki/doku.php?id=getting_drumgizmo
Zita-avc1 0.1.0
----------------
'Analog' style vocoder, inspired by the famous EMS vocoders
from the 1970's. Standalone app, using Jack for audio and
MIDI I/O.
Zita-avc1 uses two sets of 24, 6th order bandpass filters
to analyse the voice input and to impose the same spectral
envelope on another signal. The filters span a frequency
range from approx. 70 Hz to 14 kHz. Filter spacing is 1/4
octave over most of this range.
Voiced / Unvoiced detection is based on the power ratio of
the high vs low frequency bands.
A sawtooth oscillator and a noise source are provided, but
normally you should use external signals, at least for the
voiced excitation. Bright strings-like signals seem to work
well, but anything with a dense 'pinkish' spectrum should do.
The voice input should be a clean, full-bandwidth voice signal,
speaking or singing.
This is very much an alpha version, released to invite comments
and suggestions.
Future developments may include:
- Pitch tracking.
- Filter band matrix.
- Store and recall formants with MIDI control.
- ...
See the README for a quick guide.
Available at the usual place:
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/zita-avc1-0.1.0.tar.…>
Ciao,
--
FA
Hi
Mamba release v1.8 is out
Mamba is a Virtual MIDI keyboard with some extended, unique features.
Virtual MIDI Keyboard
Mamba comes with some predefined key-maps, qwertz, qwerty, azerty(fr)
and azerty(be), but you could define your own with the included Key-map
Editor as well. Beside the computer keyboard and mouse, Mamba supports
jack-interconnect-ALSA MIDI I/O. Every channel use it's own Color to
display the played Notes per channel.
Jack and ALSA connections could be managed within the connection menu.
16 Channel Live MIDI Looper:
To record a loop, press "Play" and then to start recording press
"Record". To stop recording press record again. Playback will start
immediately.
The first recorded channel will become the Master channel. This one set
the time frame for all later recorded loops. For the Master Channel the
recording time will be stretched/clipped to match the next full beat
time point.
To record a new loop, switch to a other channel, select your instrument
and press "Record" again to start recording.
The later recorded loops will be synced to the master loop. When the
recording time extend the absolute Master loop time record will be
switched off. Absolute time is not bound to the loop point, so you could
record loops crossing it. You could as well stop recording by press
"Record" again before the time expires.
Each Channel could be cleared and re-recorded separate at any time. even
when you press "Record" on a already recorded channel, it will be
cleared before recording starts.
You could record the connected input device or play the Keyboard itself.
MIDI File player
You could select a MIDI file with the File Selector, or just drag'n drop
it in from your Filemanager. It will be loaded in the play buffer of the
first channel, regardless how much channels it use. You could use then
channel 2 - 16 to record your own playing into it. To play along with it
you could use any channel. A loaded file will become the Master channel
for the looper.
To save your work just go to Menu -> "File" -> "Save MIDI file as",
select the path and enter a file name. If you don't give the usual file
extension Mamba will add the extension .midi befor save it.
Fluidsynth
When you load a Sound-font via the Menu -> "Fluidsynth" -> "Load
Sound-font", or just drag'n drop it in from your Filemanager Mamba will
start the Fluidsynth engine and do the needed connections so that you
could just play along. Menu -> "Fluidsynth" -> "Settings" will pop-up a
new Window were you could select the Instrument for the channel and do
settings for Fluisynth Reverb and Chorus. All your Settings will be
saved on exit, so on next start you could just play along.
Mamba is released under the BSD Zero Clause License license
The GUI is build on libxputty - A damn tiny abstraction Layer to create
X11 window/widgets with cairo surfaces
https://github.com/brummer10/libxputty
To build Mamba from source, the following dependencies must be meat.
* libfluidsynth-dev
* libc6-dev
* libsmf-dev
* libcairo2-dev
* libx11-dev
* liblo-dev
* libsigc++-2.0-dev
* libjack-(jackd2)-dev
* libasound2-dev
So, here is the project page:
https://github.com/brummer10/Mamba
and here you'll find the last release:
https://github.com/brummer10/Mamba/releases/tag/v1.8
regards
hermann
It may be old news for seasoned programmers, but I found this to be a
trove of information that goes a bit beyond of the traditional wisdom of
"what's safe in a jack process() thread", so I thought I'd share it here
(courtesy of LWN's free subscriber link feature, please check out LWN!)
https://lwn.net/SubscriberLink/837019/e323ab1009054668/https://ogness.net/ese2020/ese2020_johnogness_rtchecklist.pdf
All best,
Jörn
--
Jörn Nettingsmeier
Tuinbouwstraat 180, 1097 ZB Amsterdam, Nederland
Tel. +49 177 7937487
Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT
http://stackingdwarves.net
Hello all,
I'm having a strange problem with G++...
In one source file 'fb3data.cc', I define arrays like this:
const float svcoeff44 [216] =
{
1.631996e-03, 6.335480e-02, ...
...
};
There are five of these. In 'fbdata3.h' I have
extern const float svcoeff44 [216];
extern const float svcoeff48 [216];
extern const float svcoeff88 [216];
...
Finally in 'filtbank3.cc' there is
const float *c;
switch (fsam)
{
case 44100:
c = cvcoeff44;
break;
case 48000:
c = cvcoeff48;
break;
...
}
Everything compiles without errors or warnings, but the linking
step fails:
/usr/bin/ld: filtbank3.o: warning: relocation against `svcoeff88' in read-only section `.text'
/usr/bin/ld: filtbank3.o: in function `VocFiltbank::init(int)':
filtbank3.cc:(.text+0x159): undefined reference to `svcoeff192'
/usr/bin/ld: filtbank3.cc:(.text+0x1d3): undefined reference to `svcoeff48'
/usr/bin/ld: filtbank3.cc:(.text+0x1e3): undefined reference to `svcoeff96'
/usr/bin/ld: filtbank3.cc:(.text+0x1f3): undefined reference to `svcoeff44'
/usr/bin/ld: filtbank3.cc:(.text+0x1ff): undefined reference to `svcoeff88'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status
When I put the arrays in 'filtbank3.cc' instead, everything works.
Any hints ??
Ciao,
--
FA
Alexandre DENIS:
> On Mon, 16 Nov 2020 09:43:42 +0100
> Fons Adriaensen <fons(a)linuxaudio.org> wrote:
>
> > Hello all,
> >
> > I'm having a strange problem with G++...
> >
> > In one source file 'fb3data.cc', I define arrays like this:
> >
> > const float svcoeff44 [216] =
> > {
> > 1.631996e-03, 6.335480e-02, ...
> > ...
> > };
> >
> > (...)
> > /usr/bin/ld: filtbank3.o: warning: relocation against `svcoeff88'
> in
> > read-only section `.text'
>
> Hi,
>
> I've already seen this strange behavior with gcc 9.x : symbols with
> a const definition are by default not publicly visible. It works
> if you explicitly add an "extern" in the definition:
>
> extern const float svcoeff44 [216] = (...)
>
> I am not sure whether it is a bug in gcc or a strict application of the
> standard.
Yeah, I just read this: https://gcc.gnu.org/gcc-10/porting_to.html
"
C language issues
Default to -fno-common
A common mistake in C is omitting extern when declaring a global
variable in a header file. If the header is included by several files
it results in multiple definitions of the same variable. In previous
GCC versions this error is ignored. GCC 10 defaults to -fno-common,
which means a linker error will now be reported. To fix this, use
extern in header files when declaring global variables, and ensure
each global is defined in exactly one C file. If tentative definitions
of particular variables need to be placed in a common block,
__attribute__((__common__)) can be used to force that behavior even in
code compiled without -fcommon. As a workaround, legacy C code where
all tentative definitions should be placed into a common block can be
compiled with -fcommon.
int x; // tentative definition - avoid in header files
extern int y; // correct declaration in a header file
"
Guess that could explain it.
On Mon, Nov 16, 2020 at 12:59 PM Roman Sommer <roman.sommer(a)fau.de> wrote:
>
> Kjetil Matheussen <k.s.matheussen(a)gmail.com> writes:
> >
> > Yeah, I just read this: https://gcc.gnu.org/gcc-10/porting_to.html
> >
> > "
> >
> > C language issues
> >
> > Default to -fno-common
> >
> > A common mistake in C is omitting extern when declaring a global
> > variable in a header file. If the header is included by several files
> > it results in multiple definitions of the same variable. In previous
> > GCC versions this error is ignored. GCC 10 defaults to -fno-common,
> > which means a linker error will now be reported. To fix this, use
> > extern in header files when declaring global variables, and ensure
> > each global is defined in exactly one C file. If tentative definitions
> > of particular variables need to be placed in a common block,
> > __attribute__((__common__)) can be used to force that behavior even in
> > code compiled without -fcommon. As a workaround, legacy C code where
> > all tentative definitions should be placed into a common block can be
> > compiled with -fcommon.
> >
> > int x; // tentative definition - avoid in header files
> >
> > extern int y; // correct declaration in a header file
> > "
> >
> >
> > Guess that could explain it.
>
> Hm? Why would that explain this behaviour?
> It seems to me Fons already (correctly) uses "extern" in his header
Guess you're right. I didn't read the posts very thoroughly. That's
also why I wrote "could' and not "would".