QasTools version 0.16.0 is now available.
QasTools is a collection of dektop applications for ALSA.
Changes:
* QasTools replaces separate QasConfig and QasMixer packages
* QasHctl: QasHctl forked out of QasMixer into separate application
* QasHctl: Wrong pixmap in switch widgets fixed
* QasMixer: Command line arguments -D and -c fixed
* QasMixer: Command line arguments descriptions added in manpage
* All: Info dialog adapted to QasTools
Homepage with more information
http://xwmw.org/qastools
Project page
http://sourceforge.net/projects/qastools/
Happy volume changing!
-- Sebastian Holtermann
>From El Reg:
- Nvidia had better watch out. Texas Instruments is not only its rival
when it comes to making ARM processors that might end up in servers
someday, but it is also repositioning its digital signal processors so
they can be used as math coprocessors for standard x86 CPUs – and
perhaps ARM processors one day.
... TMS320C66x family of DSPs needs a much easier nickname if it is to
become cool and talked about ...
C66x delivers 160 gigaflops of single-precision floating point ...
8MB L2 cache ... 12.8GB/sec of bandwidth ...
only consumes 10 watts ...
www.theregister.co.uk/2011/11/28/ti_dsp_supercomputer/print.html
--
JMA - Harlequin
http://www.youtube.com/watch?v=inu-kkBnJKg
Hi all,
since the NASPRO bridges 0.3.0 release has a small but annoying build
system-related problem, here I am announcing NASPRO 0.3.1, that is
identical to the previous release except for the updated NASPRO
bridges 0.3.1 package.
More information on the website: http://naspro.atheme.org/
Enjoy!
Hello
I’m happy to announce a update release of gxtuner, a simple, small and
lightweight guitar/bass tuner for jack.
It's a break out of the guitarix tuner module,
gxtuner-1.5
changes:
* added reference pitch controller
* added threshold controller
* added command-line option (-i) to connect at start up
gxtuner comes with a analogue like, full arbitrary scaling interface (scale),
show the tune, the octave and the accumulated frequency in Hz,
and it comes with full jack-session support.
gxtuner use a equal-tempered scale based on A4 = 440 Hz (427Hz <-> 453Hz)
gxtuner is licensed under the GPL.
for more information please read the included README file.
get it here:
http://sourceforge.net/projects/guitarix/files/gxtuner/
direct link
http://sourceforge.net/projects/guitarix/files/gxtuner/gxtuner-1.5.tar.bz2/…
have fun
Guitarix developers
As I slowly figure out audio architecture, I've gotten to here:
main()
- sets up jack, instantiates and Engine class and a Controller class
Engine
- the engine is passed to the jack audio callback, and has a .tick() to
calculate audio
- engine will receive messages over ToEngineQueue ( with a ringbuffer )
- engine will send messages back to controller over a second queue,
ToControllerQueue
Controller
- started in main thread
- will handle all input and output and instantiate any guis
- sends messages to engine over queue
- receives messages from engine over the ToControllerQueue
Message
- struct for passing messages, holds simple numbers, keeping individual
messages of known size for now
I've seen a few ways now in tutorials of handling some things and would
love opinions.
- Should the ToEnqineQueue be a part of Engine? ie, do we pass messages to
engine
with engine->newMessage( msg );
- or should the queue's be instantiated in main and should Engine and
Controller each get pointers to the queues?
- I think the stk examples do the former and SuperCollider the second
- is it a bad idea to have both engine and controller need pointers to each
other?
- is this an example of an undesired circular dependency?
- is avoiding that by having them each only depend on Queue and Message a
good plan?
- or should I avoid it by using an ABC for MessageReceivingComponent and
allow them each to have pointers
of type MessageReceivingComponent?
- how should one handle memory management of the messages? Is it ok for
Engine to allocate memory for new
messages and have them destroyed on receipt,
- or should I have queue delete the memory and return by value when
messages are fetched?
- what is the crustimony proceedcake for allocated memory from an engine?
thanks to anyone who feels like they have the time to answer these!
iain
David,
With the greatest respect to you, and I have a lot of sympathy with
your ideas of GUI's using browser / JS technology, your comments on
Java are bordering on FUD. Â I also don't understand the general
anti-Java diatribe - it's a library, and it has its uses - why treat
it as somehow different to any other library. Â It's still the best
performing VM out there. Â Once JavaScript allows me to write a single
JIT'ed executable that runs cross-platform; links to JACK on Linux,
Windows and Mac; allows sub-5ms latency; and lets me drop live-coded
fragments into the audio graph - then it gets interesting, but until
then JS is still playing catchup! :-)
On 21 November 2011 01:15, David Robillard <d(a)drobilla.net> wrote:
> * Most Windows computers do not have Java.
Source??? Â Last stats I saw showed Java installs not far behind Flash.
 And if you take the "link your own VM" option (which is similar to
the suggestion re. webkit) it's irrelevant anyway.
> * Java is officially deprecated on Mac OS X.
hmm .. Java on Mac is actually looking rosier than it has in a long
time, now that development is taking place officially as part of
OpenJDK.
> * Java will never, ever be available by default on any Microsoft
> platform
That depends - lots of manufacturers install it by default.
> * Java is not included in the default installation of the overwhelming
> majority of free software operating systems
Good! Â Too many distros install far too much by default. Â It's a
library, it's a dependency, and it's there if it's needed.
> * Java requires software installation of some variety (unless you're
> seriously going to suggest using Java applets in 2011 with a straight
> face...)
Applets? Â God, no! :-) Â I've no problem with installation though. Â As
I said before, I don't necessarily see web-apps as the ultimate way
forward - I personally think the app-store model will hold out because
a) app-stores allow certain companies to keep their walled gardens,
and b) writing for the browser is always going to be writing to the
lowest common denominator.
> * Java recently has acquired a lot of legal questions making it not
> exactly the wisest investment for new technology.
Nothing that affects OpenJDK though.
> * There are many cutting edge modern browser implementations, and
> activity here is moving at an astonishing pace. Â Java is a dinosaur.
>
A dinosaur that the others are still trying to catch up with, mind you!
> Regardless, if I may take the liberty of speaking for this community,
> making people use Java for something is a sure-fire way of ensuring they
> don't use it.
And I'll take the liberty of saying I think that's a daft attitude to
have! :-) Â If the application performs a function I need, then I'll
consider using it, regardless of what technology underlies it.
Best wishes, Neil
--
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net
Thanks guys!
I actually tried j2a but now i realise that i forgot the -e option to
expose the hw ports. Doh!
I'll give it another try tonight.
Thanks!
Grtz
Thijs
On 9 Dec 2011 00:12, "Harry van Haaren" <harryhaaren(a)gmail.com> wrote:
Hello Thijs,
I think you might be under the impression that FFADO MIDI and ALSA MIDI are
roughly the same, they're not...
FFADO is a backend that you can run JACK on top of. If you run JACK with
the FFADO as the "driver", then JACK will be able to send MIDI commands to
your Saffire. ALSA MIDI is a totally different "MIDI".
The upside: There's a program "a2jmidi" which will put all your ALSA MIDI
ports into the JACK MIDI graph, then you can connect any ALSA MIDI out to
JACK MIDI in, and vice versa.
"a2jmidid" is the name of the package on debian based systems.
Running is usually most benificial like so:
a2jmidid -e &
so that it keeps scanning the ALSA MIDI graph for changes, and will update
the JACK MIDI ports available.
Good luck! -Harry
On Thu, Dec 8, 2011 at 9:57 PM, thijs van severen <thijsvanseveren(a)gmail.com>
wrote:
> >
> > Hi all
> >
> > i'm trying to use 'amidi' to send a simple midi message to the midi out
> port of my fi...
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>
Hi all
i'm trying to use 'amidi' to send a simple midi message to the midi out
port of my firewire (FFADO backend) audio device. a Saffire LE.
to do this i simply need to specify the port i want to send the data to,
however i can only select one of the ALSA midi devices listed under
/dev/snd/ and the firewire midi ports are all Jack midi ports and thus not
listed here.
but where are these listed ?
or should i be doing things differently ?
grtz
Thijs
--
follow me on my Audio & Linux blog <http://audio-and-linux.blogspot.com/> !
Hello all,
First release of zita-dpl1. Look-ahead digital peak limiter.
1-16 channels (highest one determines gain reduction).
More at <http://kokkinizita.linuxaudio.org/linuxaudio>.
Enjoy !
--
FA
Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.