On 23 February 2011 22:11, David Robillard <d(a)drobilla.net> wrote:
> SLV2 is now based on two new libraries: Serd (RDF syntax) and Sord (RDF
> store). Both are roughly 2 thousand lines of C, solid and thoroughly
> tested (about 95% code coverage, like SLV2 itself). Serd has zero
> dependencies, Sord depends only on Glib (for the time being, possibly
> not in the future).
Can you point me at the API or code? I couldn't see it in a quick
browse on your SVN server.
I have a library (Dataquay,
http://code.breakfastquay.com/projects/dataquay -- preparing a 1.0
release of it at the moment, so if anyone wants to try it, go for the
repository rather than the old releases) which provides a Qt4 wrapper
for librdf and an object-RDF mapper.
It's intended for applications whose developers like the idea of RDF
as an abstract data model and Turtle as a syntax, but are not
particularly interested in being scalable datastores or engaging in
the linked data world.
For my purposes, Dataquay using librdf is fine -- I can configure it
so that bloat is not an issue (and hey! I'm using Qt already) and some
optional extras are welcome. But I can see the appeal of a more
limited, lightweight, or at least less configuration-dependent
I've considered doing LV2 as a simple example case for Dataquay, but
the thought of engaging in more flamewars about LV2 and GUIs is really
what has put me off so far. In other words, I like the cut of your
I've forked Specimen primarily to provide frequency Modulation of the
LFOs and to make all the LFOs and ADSRs independent so that there is
no longer a single dedicated ADSR and a single dedicated LFO for ie
pitch modulation, but two 'inputs' for pitch modulation for which the
choice of all ADSRs and all LFOs is available.
Please read the README for more information:
The current state of Petri-Foo is that the LFOs and ADSRs have been
made independant and are, AFAICT, working as should. The GUI is not
yet up to date, but changes have been made enough to get a basic idea
of what's going on.
Please do read the README before commenting. I've tried to do things
properly! I'm only human and only a hobbyist coder.
This is to bring a discussion from the Jack Dev list to this more
appropriate forum as suggested by Arnold Krille.
First, I hear lots of people seemingly thinking that AVB (IEEE 1722) and
the IEEE 1588 version of Precision Timing Protocol can be done in the
It cannot and it must not. They both need hardware assist. Period. A
timestamp is specified to be inserted based on the leading edge of the
header immediately after the preamble. If anyone ever makes some
neighboring equipment that has done these with the required precision,
then you will kill that clock network and there will be yet another good
reason not to bring Linux to the workplace.
The ONLY exception is that if the listener is a stream-to-disk system,
then the timestamp system can simply be ignored. Such a listener will
never turn on PTP, but that won't hurt, because it will just ask for the
1722 stream and the talker will spit it out without knowing that that
node doesn't play PTP.
The version of PTP that is used in AVB is from the 802.1AS
specification. The acronym PTP is now an ambiguous one that has at
least these two uses, and I have heard some other hardware-assisted
networked timing schemes called PTP.
IEEE 1588 specifies an epoch-based struct with 48 bits of seconds (This
gives 8.9 million years before a "y2k" hits IEEE 1588) and a 32-bit
number that specifies nano-seconds. the 802.1AS sub-spec also uses this
PTP maintains one suite of transactions to keep itself timed. This is
blind to AVB.
AVB creates Word Clock timeframes using the PTP wall-clock that MUST be
made available to the 1722 layer. IF YOU HAVE PTP, then you can
synthesize predictive wallclocks using a buffer-full scheme in a
PTP-capable NIC. That NIC has to be configured to pay out the frames
per the 802.1Qav forwarding and scheduling spec. This is how streamers
will deliver streams that are well-timed, low-jitter streams. There are
fruit companies doing this as we speak with new NICs that have been
enabled from Broadcom and Marvell (and any host of others.)
It is possible to fake a GrandMaster clock using kernel-timed
calculations. The Best Master Clock Algorithm (BMCA) of a two-node
system will be forced to accept such a sloppy clock and the slave will
achieve lock, but with jitter that will fail a normally specified PTP
system. Noisy environment listeners will not hear this, but clean
listening will reveal the various artifacts of such jitter.
You can just make a leaky-bucket PLL at a receiver and use the DPLL
frequency to inform SRC. This hack will be un-noticed by the average
media-player person, but not by the critical listener.
When the 1722 timestamp is constructed, it is a complex assembly from
the 802.1AS timestamp. The 802.1AS timestamp is a two-part thing, as
specified above with its first part being simply seconds. This will not
roll over in the lifetime of Linux, our species or even our continents,
let alone a recording session. The second part is specified to roll
over at decimal one billion-1 = 999999999 = 0x 3B9ACBFF. The timestamp
in IEEE 1722 rolls over at unsigned long = 4294967295 = 0xFFFFFFFF,
which is 4.294967296 seconds. I apologize for quoting "weeks between
rollover" in the previous thread.
IEEE 1588 and IEEE 1722 are Ethernet-Only protocols, do not shoe-horn
them into IP.
I have heard lots of people say that AVB is just some thing for consumers.
go to http://grouper.ieee.org/groups/1722/ and hover over some of the
names to find where they work. It was, in fact, designed FIRST to very
easily accommodate Pro Audio:
Multiple-Node Synchronization without the need for Sample Rate Conversion.
Unlimited (at least not limited by the protocol, only the bandwidth)
And then it would be a trivial subset to get two - or 5.1, 7.1 any
surround count - channels to go from my CD player to any media player
over some LAN. (However, as of two autumns ago, they were still
kvetching over Wi-Fi.)
Finally, Yes, the CLOCK_REALTIME can be very simply pasted from a good
The C* Audio Plugin Suite reaches version 0.4.5.
CAPS is a collection of refined LADSPA units covering a wide range of
applications, from stompbox classics to experimental oscillators.
CAPS is distributed as open source under the terms of the GNU Public
This release brings a new plugin, "Narrower", which reduces the
perceived width of a stereophonic image. Frequent users of headphones
will appreciate the increased subtlety of the listening experience as
well as the reduced fatigue caused by "superstereo" recordings.
Other than that, some minor bugs have been fixed and the accompanying
PDF data sheet has been improved (frequency response plots now use log
scale: http://quitte.de/dsp/caps-0.4.5.pdf ).
The build configuration tool "configure.py" has been modified to
handle python3's errant ways in graceful manner.
Upgrading is recommended unless you have no need for the new plugin
and the current version is working fine for you.
Enjoy, and thank you for using CAPS,
Hi, I'm messing arround with the source of TerminatorX. As it seems, tX
needs a total rewright of the mixer and the audio backend.
Since many programs (Ardour, Qtracktor) have built mixers, I was
wondering from which project I could 'borrow' the mixer component.
I need a mixermodel which is strictly C++, which idealy has jack support
built in, possibly multithreaded, GUI-Independant and easy to handle.
I started to wright my own mixermodel, but then I thought how stupid it
is to reinvent the wheel. It would really be nice something like a
libmixer with jack, lv2, ladspa and VST support.
> All plugins with the same URI MUST be compatible in terms of 'port
> signature', meaning they have the same number of ports, same port
> shortnames, and roughly the same functionality. URIs should probably
> contain a version number (or similar) for this reason.
> Rationale: When serializing session/patch/etc files, hosts MUST refer
> to a loaded plugin by the plugin URI only. In the future loading a
> plugin with this URI MUST yield a plugin with the same ports (etc)
> which is 100% compatible.
Having written a host myself. This is great advice when writing for ANY
I go as far as to reject (different) plugins with duplicate URIs to promote
From the "Better Late than Never Dept"...
Announcing the _*Linux Audio Musicians Best of 2010 mix*_
Download and view the full playlist of 116 tracks here:
Listen to the continuous radio stream here:
Congratulations!!! to the Artists and Bands that made 2010 a bumper year
for well produced and unique music from the Linux Audio Community. This
mix is the biggest yet with over 100 tracks included and over 12 hours
of music to listen to. A hefty selection of guitar music and rock
productions are included in this years mix to complement the large range
of electronica. The variation of styles and genres is superb and as
expected there was lots of off the wall and challenging music produced
during the 2010 period also.
The playlist has been ordered in terms of Genre/Style to make it easier
to separate the tracks out for those with specific tastes and to ensure
the radio stream flows nicely.
If you feel that there is a track missing please feel free to contact me
with details. This is a snapshot of the year so lets make it as complete
Boost Hardware Ltd.
Yesterday my main home system decided to 'meet its creator'.
The power supply sort of exited in a funny way, producing
unhealthy odors and some noises. I can still start the HW
using a spare PS, but the / filesystem seems beyond repair,
with fsck freezing the machine when trying to fix it - never
seen that before. Strangely enough I can still mount it and
was able to copy some directories from it that were more
recent than the last backup. I wonder if it's just the
file system being damaged or the disk HW itself.
Anyway after 8 years it's probably time for some new HW, and
I've been considering one of the 'Shuttle' boxes. Florian
Faber already recommended them some time ago, but I wonder
if anyone out there can report on them, or offer some advice
as to which series to prefer, what to avoid, etc.
I'm wondering how to approach creating a MIDI map to all controllers
available in the GUI. Needless to say I can hard code in a MIDI CC, and from
JACK's process callback call the function that I want to map that control
to, but that's a little rigid.
I like Ardour's one-click map idea, and I'm wondering how its implemented.
Here's what I concluded so far:
On mouse_3 down, pop up dialog, send message to JACK process to keep next
MIDI input stored somewhere. That's the CC to map
Where I'm getting stuck is how to make each CC point to a different
"parameter" in the software, or a different function in the code. Function
pointers come to mind, but somehow I don't like that idea much. Creating a
generic interface to map every control in the entire engine might work, but
I think that may be a little overkill?
I'd be interested to hear how various projects handles this internally, if
anybody wants to chip in?