>
> On 08/11/12 06:54, Thijs van severen wrote:
>
> Last week my brother got his new digital drum. its an octapad clone
>> (only cheaper) that fits our needs perfectly.
>>
>
> Heh, you left out the most important information - which device is it? :-))
>
> K.
>
>
details, details ... ;-)
it's this one http://www.thomann.de/be/millenium_dp2000_multi_pad.htm
it is class compliant, so i guess it's to be expected that it works, still
i personally prefer hearing that from someone that actually owns one (and
uses it with linux of course)
if there is no such page, wouldnt it be a good idea to create something
like this ?
i could create one on the Hydrogen site, but that would be more aimed at
drum midi devices and maybe we shouldnt limit it to that specific type of
device
a more generic page would be better IMO (something like the ffado device
list : http://www.ffado.org/?q=devicesupport/list)
ideas ?
grtz
Thijs
--
follow me on my Audio & Linux blog <http://audio-and-linux.blogspot.com/> !
Hi all
Last week my brother got his new digital drum. its an octapad clone (only
cheaper) that fits our needs perfectly.
Before we decided to get this model i googled to see if it is linux
compatible, but couldnt find anything.
Now that we have it i can confirm that it works :)
However, i was wondering if there is a page/wiki/list where i could add
this info so others can see this?
Grtz
Thijs
Hello all,
Jmeters-0.4.1 is now available at the usual place:
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html>
Jmeters is a Jack app offering software versions of various
traditional analog audio level meters.
This release is a major update. It offers VU meters, BBC, EBU
and DIN style PPM meters, stereo versions (using red and green
'needles') of the three PPMs, and correlation meters matching
the VU, BBC and DIN styles, most of them in different sizes and
shapes.
The Jmeters instruments have the correct 'ballistics' for both
the VU and the PPMs. Given the same input, they will indicate
exactly as the original electro-mechanical meters, all of which
are rather strictly specified in various standards documents.
New features:
* DIN style peak program meter (IEC type I).
* Stereo correlation meters.
* The default 'style' is now a rectangular frame of around 300 by
170 pixels. There is also a smaller rectangular form, and the two
original round 'Meterbridge' styles are still available for all
types except the DIN style PPM.
* The meter 'needles' are now plotted using the Cairo library which
provides much better visual quality than the raw X11 graphics used
previously.
* It is now possible to put labels on the meters, just include
them on the command line, either mixed with the Jack port names
or after them. Anything not containing a ':' is considered to be
a label instead of a Jack port name.
Many thanks to Richard Lamont for all comments and suggestions.
Enjoy !
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi LADs,
I'm pleased to declare http://ltcsmpte.sourceforge.net/ as deprecated
and release libltc-1.0.2 into the wild.
Linear (or Longitudinal) Timecode (LTC) is an encoding of SMPTE timecode
data as a Manchester-Biphase encoded audio signal. The audio signal is
commonly recorded on a VTR track or other storage media.
libltc is a LGPL library which provides functionality to encode and
decode LTC to/from timecode.
source: https://github.com/x42/libltc
documentation: http://x42.github.com/libltc/
In addition to a major API overhaul, libltc adds support for
vari-speed en/decoding and reverse LTC. Furthermore the LTC decoder's
accuracy and efficiency has been improved. The various tools that came
with ltcsmpte have been migrated to https://github.com/x42/ltc-tools .
A fully functional LTC slave and latency free encoder can be found in
Ardour3 since svn rev. 13390.
Many thanks to Chris Goddard who spent countless hours staring at
scopes, listening to LTC and doing real-world tests to assure sample
accuracy and quality in general.
Thanks to JaromÃr MikeÅ¡ and Alessio Treglia libltc has already found
its way into debian.
happy A/V syncing,
robin
PS. The timecode conversion functions of ltcsmpte are in progress to
find their way into a standalone library which is still in the works.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJQmUUhAAoJEKCQvOAs9X8Ec1MP/iarf4wfOyjxqA2HhDz4dZIS
QwUa7u7G3XwuJeHLnRPqgXxAyf9sh8lbjbGdz36TxCPU+7uWOnyQ9bjJ5OnNObae
c0J3etwhzbSMAlWBykLgUh7rGfhd998wArqnIYmruC8OwNrSNi0A1SWITwN1IGc/
tWJAz0RfTcLT89OekaH2HQOmiLolOkKP5b1MjeMb+cRK/V8Q2p1RFDzYbUTbqiAo
7htOMNGlRu9DkGq8PGeTc5C4IeLkktpvv/WatSTbFWazc9g/tJqlAzUUMeghWHN/
UanlPQC5p/a9ETFXlcmUFpW+RVE3M6nNCrHoi5EZiK3PkPdFJYvPFe6o3ITrKwkY
tBntWjp+j/nrOHeloBQLMKHBQEpqkNJYNKTIoJlvJTCoQH3798APwE2DHDW0ImJl
9tvu7otjCTsWECJ6CWqIo7sLcKfHsmtLm7kDiwdeIAnut230FwBAd7v/tGDBtZDh
7/JmrvWYQ37NXI2onl8hW3CJAfaAv7GAEeisAdzjADMnZb17uCRPRm8qw/StrjPS
od7k/oEcrxWSNk7m6WIg2M6NfzB1N1tGMSVxiK3f5YMb91CZ/buRDC4myWMMKibf
ST+HNhjWI9VpmOUymGqLV0jpkc4Gmym0pjqDfndCEkgVMmzUCtK/861ou4LS7GUq
YqFur38zbcUhsd+E3z6Z
=b5Mo
-----END PGP SIGNATURE-----
Hi
With some threads running on different CPU,
accessing a shared pointer (in RAM) atomically (with gcc atomic methods)
my current understanding is:
- each cpu has its own cache line
- which is updated on every atomic read/write operation
1. is that applicable ?
2. is there a faster or more convenient method, such as
storing the pointer in fast register shared among different cpu ?
--
E.R.
Hello all,
I want to write an application that monitors in realtime changes in an Alsa dummy mixer control (though not sure which language yet). I think its best to try to track those changes through the filesystem. For non-dummy mixer controls I can access them through: /proc/asound/cardx/codecxxx/xxxx+regs. However, it seems that this does not work for this dummy mixer control. Can someone point me a bit in a direction where I should for a solution (language/library)?
Whichever language I use I still have quite a bit to learn. However, I do would like to find out whether it is even possible in a certain language before I invest a lot of effort in it (without result). I've tried Python, but getting it working in realtime is likely going to be very hard (if possible at all).
Kind regards, Maarten
ps. I've defined the dummy mixer control in /var/lib/alsa/asound.state
as shown below:
state.DAC {
control.12345 {
iface MIXER
name 'Fake Playback Volume'
value 100
comment {
access 'read write user'
type INTEGER
count 1
range '0 - 100'
}
}
}
Hello all,
Version 1.3.0 of libzita-resampler is now available on
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html>.
This release fixes a bug in the VResampler class that showed up on
64-bit systems only. This also made zita-a2j and zita-j2a fail.
Many thanks to Jannis Achstetter for reporting the problem and
testing the fix.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
