Hey All,
I'm delighted to say that 5 days after announcing, Luppp has reached its
target donation!
That means that its now available under the GPLv3+ license, to everybody!
Grab the details & source from here: http://openavproductions.com/luppp
I'd like to thanks the community, for the awesome support Luppp has
recieved!
Thanks to LeatusPenguin, ZthMusic, AutoStatic, and others for beta-testing,
making this release much more polished before this release. Thanks to
Jonathan Liles for writing NTK, the user-interface toolkit behind the
OpenAV software interfaces.
Thanks to all the contributers: you are the reason this software is
available right now!
Thanks again, -Harry
Hello audio developers,
I have just updated a new release candidate for LibLo 0.28rc. Due to
a couple of bad bugs slipping into the last release I have decided to
take a more precautionary approach this time and ask for public
testing of this release candidate before a final 0.28 release.
That is to say, this release fixes several important issues from 0.27,
but is not intended for use in production until after this round of
testing.
To download liblo-0.28rc:
https://sourceforge.net/projects/liblo/files/liblo/0.28rc/liblo-0.28rc.tar.…
For more information, the liblo project page can be found at:
http://liblo.sourceforge.net/
-----------
2013-11-24: Release candidate 0.28rc
This is a release candidate 0.28rc of LibLo, the lightweight, easy to
use implementation of the Open Sound Control protocol.
Open Sound Control (OSC) is a protocol for communication among
computers, sound synthesizers, and other multimedia devices that is
designed for use over modern network transports.
This is mainly a bugfix release due to some deal breakers that
unfortunately made it through to the 0.27 release. Additionally, this
is the first release to include a modern C++11 object-oriented wrapper
for the LibLo API. Please test!
Important bug fixes:
* Fixed checking of vararg markers on 64-bit systems
* Fixed hang in TCP blocking test
* Several potential bugs prevented through static analysis
Additional changes:
* Add function lo_bundle_get_timestamp()
* Add C++11 wrapper, `lo_cpp.h', and test program
* Support for a few more build tools: clang/clang++, ccache
thank you,
Steve
Here's my first foray into the LV2 world. Kudos to the work of Steve
Harris, Nedko, Dave Robillard and Harry Van Haaren. I wrote these
initially because of a need, but maybe someone else can find use for
them also. Beta only at this stage:
https://github.com/bsjones/psi-plugins
hello,
tested successfully with a HDSP 9652.
great usefull tool !
notice that if hdspmixer has not been started after bootup (means the card is not initialized in some way), hdspdump throw no error, and creates a dump file filled with 0. It means that alsa is not throwing errors either as your programs goes nicely to the end.
I've been looking at hdspmixer code for some days now to make it console only, removing FLTK dependencies. Your program gives me motivation to go on with this hard task.
Raphaël
Le 26 nov. 2013 à 19:32, linux-audio-dev-request(a)lists.linuxaudio.org a écrit :
> Re: Headless RME HDSP/HDSPM mixer settings
As some of you know already, ive been busy porting OpenMusic to Linux
over the last months.
Theres a beta-release of OpenMusic 6.7 available as a RPM-package here:
http://repmus.ircam.fr/openmusic/linux
The standard functionality is in place. Its been tested, with most of
the standard OM-libraries from IRCAM, as well as quite many 3rd-party
libs, during the last weeks by me and others.
The development of OM for Linux is continuing in collaboration with the
main OM-developers at IRCAM.
Please check back at the download-area for updates every now and then.
Theres a mailing-list where announcements might come more often:
http://repmus.ircam.fr/openmusic/contact
OM installs and uses its source-code while running. If you want to
build your own or get into developing this further its presumably more
effective to work on a local checkout of the svn-tree, available through
the "Sources/Developer"-pane on the same page.
Please provide feedback, bug-reports, issues, questions.
Thanks,
-anders
These questions are really directed to Paul Davis (as the
main Ardour dev), Erik de Castro Lopo (libsndfile author),
and anyone with experience in this field.
Imagine a real-time audio processing app reading (or writing)
lots of audio files, possibly evaluating a complex timeline
consisting of many separte pieces. To make things work some
(or a lot of) buffering and lookahead will be necessary.
There are at least three distinct places where this can be
done:
1. the file system(s) and kernel
2. any library used to acess audio files,
3. the application itself.
Of these, only (1) will be aware of any hardware related
issues, and only (3) will be aware of what is expected to
happen in the (near) future. (2) sits somewhere between
the two.
In view of this, what is currently the best way for an
app to read/write audio files, the basic read() and write()
calls, or the stdio interface ?
More specifically, if one would write a library to access
a particular audio file format (not supported, or only
partially by e.g. libsndfile), how 'smart' in terms of
buffering, lookahead etc. should that library be, or not
try to be, in order to perform well with apps like e.g.
Ardour ? What form would the preferred API take ?
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)
It seems to be problem of gui, aeolus 0.8.4 and 0.9.0 both have this problem.
Backtrace below is got using 0.9.0. First time i reported directly to Fons,
but still no reply. Don't know, is it accepted at all for such things as bug
reporting.
(gdb) run
Starting program: /usr/bin/aeolus -J
warning: no loadable sections found in added symbol-file system-supplied DSO at
0x7ffff7ffa000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7faa700 (LWP 9934)]
[New Thread 0x7ffff7f29700 (LWP 9935)]
[New Thread 0x7ffff7ea8700 (LWP 9936)]
[New Thread 0x7ffff55fd700 (LWP 9937)]
[New Thread 0x7ffff55ec700 (LWP 9938)]
[New Thread 0x7ffff55db700 (LWP 9939)]
Reading '/usr/share/aeolus/stops/Aeolus/definition'
[New Thread 0x7ffff55ca700 (LWP 9940)]
[New Thread 0x7ffff4ecb700 (LWP 9941)]
Reading '/home/nick87720z/.aeolus-presets'
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff4ecb700 (LWP 9941)]
0x00007ffff5d78da1 in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
(gdb) backtrace
#0 0x00007ffff5d78da1 in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#1 0x00007ffff5d7dd1f in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#2 0x00007ffff5d7f5af in ?? () from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#3 0x00007ffff5d2bbd5 in FT_Render_Glyph_Internal () from /usr/lib/x86_64-
linux-gnu/libfreetype.so.6
#4 0x00000039bd40c670 in XftFontLoadGlyphs () from /usr/lib/x86_64-linux-
gnu/libXft.so.2
#5 0x00000039bd409c64 in XftGlyphExtents () from /usr/lib/x86_64-linux-
gnu/libXft.so.2
#6 0x00000039bd40a06a in XftTextExtentsUtf8 () from /usr/lib/x86_64-linux-
gnu/libXft.so.2
#7 0x00000039a840e7ff in X_textip::textwidth(int, int) () from
/usr/lib/libclxclient.so.3
#8 0x00000039a840ed6d in X_textip::update(bool) () from
/usr/lib/libclxclient.so.3
#9 0x00007ffff6533023 in Instrwin::show_tuning(int) () from
/usr/lib64/aeolus_x11.so
#10 0x00007ffff653c974 in Xiface::handle_mesg(ITC_mesg*) () from
/usr/lib64/aeolus_x11.so
#11 0x00007ffff653cab7 in Xiface::thr_main() () from /usr/lib64/aeolus_x11.so
#12 0x00000039a7c0309a in P_thread_entry_point () from
/usr/lib/libclthreads.so.2
#13 0x00007ffff7974e9a in start_thread (arg=0x7ffff4ecb700) at
pthread_create.c:308
#14 0x00007ffff6c873fd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#15 0x0000000000000000 in ?? ()
(gdb) kill
Dear all,
QMidiArp 0.5.3 fixes a number of bugs and should from now on replace 0.5.2. It also has some minor functional improvements, all is listed below.
With thanks to all reporters, contributors and translators.
And....enjoy!
Frank
------------------------------------
QMidiArp is an advanced MIDI arpeggiator, programmable step sequencer and LFO for Linux with ALSA and JACK MIDI backends.
------------------------------------
Downloads are available at
http://qmidiarp.sourceforge.net/
direct link:
http://sourceforge.net/projects/qmidiarp/files/qmidiarp/0.5.3/qmidiarp-0.5.…
------------------------------------
qmidiarp-0.5.3 (2013-11-26)
New Features
o Random functions for sequencer and LFO steps and arp repeat mode
(feature request #5 Keith Milner)
Improvements
o NSM support now handles import/export/clear to facilitate
getting started (Roy Vegard Ovesen)
o Tempo is now MIDI-controllable (MIDI-learn)
o Sequencer transpose slider is now MIDI controllable (MIDI-learn)
(feature request #7)
o Sequencer pattern maximum length extended to 32 bars
(feature request #6)
Fixed Bugs
o LFO offset jumped back to fixed value when MIDI controlled
(bug #6 distrozapper)
o Arp trigger behavior was not practical with chords pressed on keyboard
(bug #7 Burkhard Ritter)
o JACK Transport no longer worked when no JT Master tempo was present
(bug #5 Barney Holmes)
o Deleting an arp pattern in text window while running caused crash
o Note lengths were not consistent between alsa and jack backends
o Note lengths did not account for current tempo
o Sequencer did not honor "D" button when MIDI controlled
o Seq note length is now a 16th at half slider scale
