A long time ago ... in a land far away :)
I did some assembler programming on the Acorn Archimedes (ARM 2/3) and worked
out a series of additions and subtractions that would perform very fast
multiplication of awkward numbers by known amounts.
Is there any point in doing this for C programs, or are modern compilers
sophisticated enough to do such things themselves?
If anyone is interested *7 is:
RSB R1, R0, R0, LSL #3
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
On Mon, 11 Aug 2014 15:06:24 +0200 Adrian Knoth wrote:
> On 08/11/14 05:47, D. Sen wrote:
> > I was advised by Paul Davis to inquire on this list whether there has
> > been or is likely to be any activity in developing ALSA drivers for the
> > RME Madiface XT device. Its a USB device and as such makes it very
> > amenable to a portable audio work.
> >
> > I have used PCIe based Madiface in the past using ALSA. However, I could
> > not get the USB based Madiface XT to work. The device was recognized
> > correctly (as per the SYSLOG) - however no drivers were loaded.
> >
> > Any help would be very much appreciated.
>
> As I said a year ago, it should also be possible to sniff the USB
> connection, but this requires a device and a volunteer to do so. You'd
> then run Windows in a VM and capture the USB packets with wireshark or
> any other USB sniffer.
>
> Jonathan Woithe may have additional information, since he wrote the
> drivers for FF400 and FF800.
The FF400 and FF800 are, obviously, both firewire devices. Due to the bus
structure and the way it operates there will be nothing in common between
this and any of the RME USB or PCIe interfaces. The drivers for the FF400
and FF800 are in FFADO, and while you may get some high level ideas from
things like our mixer interface, unfortunately our existing code is unlikely
to provide much in the way of direct assistance when looking at devices
using other interfaces.
Having gone down the protocol analysis route before (albeit not on the RME
devices) what Adrian has suggested is entirely feasible for the USB variant.
It will be time consuming, but sniffing the USB bus isn't difficult
technically speaking and - most importantly - doesn't require special
hardware now we have VMs. Obviously the ideal situation is to obtain
documentation from the manufacturers, so contacting them as Adrian suggested
would be worth a shot.
Regards
jonathan
Zita-at1-0.4.0 is now avaliable at the usual place:
<http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html>
Bugfixes, MIDI channel selection added.
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)
Hello all,
The first release of stoat is available.
Stoat is a S.T.atic (LLVM) O.bject file A.nalysis T.ool which is a rewrite of
sfpv (Static Function Property Verification) due to the very quick bitrot of the
clang API (stoat uses only the llvm optimizer pass API).
This tool is designed to evaulate if any realtime function can end up calling a
non-realtime function eg a jack process callback being able to call malloc or
free.
It does this by:
1) Using either inline or external function whitelists and function
blacklists to establish which functions are safe and unsafe.
2) Extracting a function callgraph (including virtual function calls)
from the LLVM IR representation of code (which is effectively one level above
assembly)
3) Perform simple deductions based upon the callgraph
This approach is designed to work best for C/C++ projects and for realtime
verification, but fairly little stops it from generalizing to other languages
(assuming the other languages compile with llvm) and other function properties.
Existing annotations from sfpv should still work, though the only project that
I've seen using them has been jalv so far.
As this might seem quite abstract, here is an example usage with non-timeline:
http://log.fundamental-code.com/2014/08/15/stoat-tutorial-example
Project Home:
https://github.com/fundamental/stoat
Report bugs to:
https://github.com/fundamental/stoat/issues
Mark
On Tue, 12 Aug 2014, Max wrote:
>> Pulse on jack.
>
> Would you suggest that your method is better and should be the
> canonical way to do pulse on jack? If so, shall we write up an
> alternative WalkThrough on the jackoudio wiki that helps people
> setting that up?
Something more to add. If you are using a debian based distro (ubuntu for
example) the jackd executable needs to be chmod -x or you will find odd
things happen if you manage to crash jackdbus. Generally some well meaning
program will come along and start jackd making qjackctl of no use and
making module-jackdbus-detect unable to set up the pa-jack bridge. The
command killall -9 jackd needs to be run. I now concider this has rissen
above anoyance to bug. Jackd2 and jackdbus should be packaged separately.
If needed the jackdbus version can come with a script that has
jack_control's innards, but acts like jackd. (uses jackd's config file and
takes jackd's arguments on the CL... may as well give it jackd's name
too). For my use, all it would have to do is ignore the arguments and run
jack_control start which would restart with the parameters I chose before
or do nothing if it is already running.
--
Len Ovens
www.ovenwerks.net
Greetings Linux Audio Users and Developers !!!
I'm very happy to inform that we will launch the MOD Duo's Kickstarter
campaign in mid September.
The MOD Duo is our second model and we've been putting a lot of engineering
in it based on the feedback we had from the MOD Quadra experience.
We deeply hope it becomes a device that empowers the Linux Audio community,
bringing together developers and musicians.
A pre-campaign site was created to warm up the communication engines:
http://stepontothefuture.com.
Hope you all enjoy and spread the word
Kind regards
Gianfranco Ceccolini
The MOD Team
Hi List-members,
I was advised by Paul Davis to inquire on this list whether there has
been or is likely to be any activity in developing ALSA drivers for the
RME Madiface XT device. Its a USB device and as such makes it very
amenable to a portable audio work.
I have used PCIe based Madiface in the past using ALSA. However, I could
not get the USB based Madiface XT to work. The device was recognized
correctly (as per the SYSLOG) - however no drivers were loaded.
Any help would be very much appreciated.
Best Regards,
Deep
Announcing a new C++ library and Vamp plugin implementing the Constant-Q
transform of a time-domain signal.
https://code.soundsoftware.ac.uk/projects/constant-q-cpp
The Constant-Q transform is a time-to-frequency-domain transform related
to the short-time Fourier transform, but with output bins spaced
logarithmically in frequency, rather than linearly. The output bins are
therefore linearly spaced in terms of musical pitch. The Constant-Q is
useful as a preliminary transform in various other methods such as note
transcription and key estimation techniques.
This library provides:
* Forward transform: time-domain to complex Constant-Q bins
* Forward spectrogram: time-domain to interpolated Constant-Q magnitude
spectrogram
* Inverse transform: complex Constant-Q bins to time domain
The Vamp plugin provides:
* Constant-Q magnitude spectrogram with high and low frequency extents
defined in Hz
* Constant-Q magnitude spectrogram with high and low frequency extents
defined as MIDI pitch values
* Pitch chromagram obtained by folding a Constant-Q spectrogram around
into a single-octave range
The code is provided with full source under a liberal licence, and
plugin binaries are provided for Windows, OS/X, and Linux.
The method is drawn from Christian Schörkhuber and Anssi Klapuri,
"Constant-Q transform toolbox for music processing", SMC 2010. See the
file CITATION for details. If you use this code in research work, please
cite this paper.
Zita-njbridge-0.1.0 is now available.
Zita-j2n and zita-n2j are command line Jack clients to
transmit full quality multichannel audio over a local IP
network, with adaptive resampling by the receiver(s).
Main features:
* One-to-one (UDP) or one-to-many (multicast).
* Sender and receiver(s) can each have their own
sample rate and period size. No word clock sync
is assumed.
* Up to 64 channels, 16 or 24 bit or float samples.
* Receiver(s) can select any combination of channels.
* Low latency, optional additional buffering.
* High quality jitter-free resampling.
* Graceful handling of xruns, skipped cycles, lost
packets and freewheeling.
* IP6 fully supported.
* Requires zita-resampler, no other non-standard
dependencies.
Note that zita-njbridge is meant for use on a *local*
network providing more or less reliable delivery with
low to moderate delay. It may work or not on the wider
internet if receiver(s) are configured for additional
buffering, and if you are lucky. Performance on wire-
less networks is just a matter of chance.
You will need a fairly recent Jack version, as the
code uses jack_get_cycle_times() and no fallback for
that is provided.
Download from <http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html>
See man zita-njbridge for more info.
--
FA
A world of exhaustive, reliable metadata would be a
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Please excuse my "youthful" enthusiasm...
I am having some success with my usb computer keyboard as a midi control
surface.
All things are assignable to any key.
the key events press, release, and repeat can be set separately (or
ignored)
Key presses can control:
- Jack transport:
roll
stop
zero
1 or ten sec forward or back (will make this settable)
I have press do one second and repeat do 10
- midi messages these are all in hex and can include:
channel messages like key, ctl, pgm, etc
sysex up to 20 char in total
I am not sure what the limit is for jack
but any of the control surfaces I have
studied seem to send less.
The reality is that there are lots of control surfaces out there and sw
has to handle what they send.
I do have a question though about ardour control by midi. The Mackie IF
says it sends control messages that are in the form num of ticks up or
down. This means I should be able to have a key send ticks up and another
ticks down, but this doesn't seem to work.
Also, It seems the master rec-enable is not toggle-able. Odd. I have tried
both making a map file and using the learn function. Is there more
documentation for this somewhere? It would not be impossible to toggle
things from inside the controler or take ticks up and down and convert to
127 or 1024 steps. This is not just for ardour but I am wanting to know
what is standard.
--
Len Ovens
www.ovenwerks.net