Dear seq24 users,
a new seq24 release is out published by the Seq24team.
https://edge.launchpad.net/seq24/
This release fixes a few bugs and provides some new features which
mainly extend session functionality; for details please have a look
at the news list below. All users should upgrade to 0.9.2.
Please find source tarballs on the download page:
https://edge.launchpad.net/seq24/+download
For ready made packages Ubuntu users may refer to my PPA:
https://edge.launchpad.net/~gscholz/+archive/ppa
NEWS
====
seq24-0.9.2 (2010-11-27)
Fixed Bugs
* Fix tooltip usage for older GTK versions (GTK_MINOR_VERSION < 12)
* Fix sched_param memory leaks
* Fix doubled key event for screen set name line
New Features
* Add support for jack session, patch provided by Torben Hohn
* Add interrupt handler for SIGUSR1 to enable LADISH level 1 support
* Add interrupt handler for SIGINT to ask for unsaved file changes
* Remove "-f" command line option to be replaced by a simple <filename>
argument (see "seq24 --help" for more information)
General Changes
* Add mnemonics for bottom line widgets in main window and label for
screen set name edit line
* Add missing command line parameters to help message, display short
options as well
* Add command line option for program version
* Add missing command line parameters to man page
* Remove complaints about file read error if configuration files do not
exist
* Cleanup configure.in: remove unused variables, harmonize option
enabling/disabling
* Some code cleanups
Enjoy
Guido
--
http://www.bayernline.de/~gscholz/http://www.lug-burghausen.org/
Hi you all,
what do you think about that? Have you got some personal experience?
http://ck-hack.blogspot.com/2010/10/bfs-in-real-time.html
Regards
Raffaele
--
*L'unica speranza di catarsi, ammesso che ne esista una, resta affidata
all'istinto di ribellione, alla rivolta non isterilita in progetti, alla
protesta violenta e viscerale.*
I've been looking around for any tests made comparing the different
kernels, -rt, generic, or any other type of realtime enchanced kernel.
I haven't found any test results yet, at least none audio related. I did
find some testing tools at rt.wiki.kernel.org, but don't know if and how
they could be made relevant to audio low latency testing.
I suppose the most interesting results would come from testing different
kernels with jack/alsa and jack/ffado.
Has anyone done such tests?
--
ailo
An update of zita-at1 is available at the usual place:
<http://www.kokkinizita.net/linuxaudio/downloads>.
Changes:
* The resampler now uses cubic interpolation (at twice
the sample rate for 44.1 and 48 kHz), giving even
cleaner output.
* The offset control now has 400 steps of exactly 1
cent (1/100 semitone) each, and displays the set
value when touched. Default mousewheel step is 10
cents, 1 cent with Shift pressed.
Enjoy !
--
FA
There are three of them, and Alleline.
Greetings,
I've posted two new songs on my site. Both are rough mixes prepared for
my band, but I figured I'd post them anyway until I find the time to do
a more decent job. Yes, the second song has some tuning discrepancies,
and yes, I'm really that lazy.
Notes from my page at http://linux-sound.org/ardour-music.html :
Here in Ohio USA we have an interesting law that requires a convicted
drunk driver to put specially-colored license plates on his or her
vehicle (assuming s/he's still allowed to drive, of course). Law
enforcement officers can easily spot such plates, and of course everyone
else gets to cast humiliation on the idiot who decided to drink and
drive. The following song is dedicated to my foolish neighbor who
managed to fall afoul of the authorities, winning himself some brightly
colored tags for his truck. Hilarity ensues.
http://linux-sound.org/audio/Orange_Plates.mp3
Okay, so much for the poor unfortunate Floyd. The next song was inspired
by none other Rusty Campbell, my good friend and fellow musician, who
also happens to play drums in my band. Strange to say, this song has
become a crowd-pleaser and is one of our most-requested tunes. Of course
it isn't /really/ about Rusty (a.k.a. El Viejo). The poor fellow was
just minding his own business, then he gets hit with this assessment.
Inspiration can be so cruel.
http://linux-sound.org/audio/drummerinabluesband.mp3
Lyrics are on the page mentioned above.
Happy holidays to all !
Best,
dp
Hello all!
So here's some more from the organ and me. Oh, I forgot to mention: It's a
small instrument in a local church here. This time recorded from directly
behind me. The first take was done from the viccar's lectern. The organ has
five stops (gedackt 8ft., principal - probably 8ft. but sounds like 4ft. -,
Rohrfloete 4ft., Waldfloete 2ft. and two mixtures - for each half of the
keyboard and a 16ft. subbass, which sounds like gedackt 16ft.).
http://juliencoder.de/jb/xmas_10
The files endng in_close are the new ones. There's also the b minor prelude,
which I didn't take from the other session.
All files are available as ogg and mp3.
Enjoy!
Merry Christmas or wonderful holidays (whatever you prefer)
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
On 10/29/2010 02:23 PM, Andrew C wrote:
> Hi Rosea,
>
> Personally, I'd say that given the speed of SSDs, I'd say they'd be
> fine for audio.
> In terms of the technology used, it's just flash based memory anyway,
> so it's not anything particularly new or scary.
>
Thanks for the replies so far. Till now people seems to be positive
about SSD for audio data. More and/ or different views on this?
Best regards,
\r
Please excuse cross-posting.
Dear friends and fellow FOSS enthusiasts,
It is my great pleasure to share with the community a belated Holiday
present :-) in a form of latest snapshot of L2Ork iteration of
Pure-Data. Better than ever, the latest version comes with the following
improvements:
*implemented apply undo for array properties and partially implemented
apply undo for graph-on-parent object properties (does not apply to
abstractions or top-level windows currently until I figure out how to
address the indexing of toplevel windows inside the glist as well as how
to address to which window such an undo belongs).
*properties are disabled when right-clicking on an abstraction as
modifying its settings externally does not make sense when one does not
see the actual contents inside it. So, to edit the properties of an
abstraction, one has to open the actual abstraction.
*fixed how new arrays are created so that they always fit within the
specified boundaries. Please note arrays that have been already created
in prior patches remain untouched in terms of graph auto-resizing
(legacy code is provided in g_editor.c canvas_vis that deals with this
if anyone wishes to convert their arrays but is incomplete in that it
assumes all arrays require resizing--this is however unnecessary as
simple recreation of said arrays or manual readjustment of their
settings ought to do the trick.
-This feature needs further testing--feedback is most appreciated.
*fixed how arrays deal with moving array points via mouse by restricting
them within the array bounds--this should work for all gui-driven array
operations, while array alterations via snapshots and other external
ways of manipulating arrays remain unbound so as to allow for
traditional data-flow debugging--this may change down the road in part
due to introduction of the magicGlass option and in part due to belief
that data monitoring should only report ranges specified by the graph.
-This feature needs further testing--feedback is most appreciated.
*added new feature for arrays where they report a bang through the
<arrayname>_changed send (if one is provided) whenever they have been
altered by a mouse click'n'drag--this in conjunction with array graph
auto-resizing makes arrays formidable alternatives for multisliders.
-This feature needs further testing--feedback is most appreciated.
*when an array subpatch is opened and resized, the array automatically
now resizes to properly fill the window.
-This feature needs further testing--feedback is most appreciated.
*fixed where array was not visible after reopening the patch if any of
its points touched upon y graph limits.
*fixed couple of segfaults caused by gridflow incompatibility--more
problems remain with gridflow library compatibility, likely due to
widgetbehavior and possibly also magicGlass incompatibility. Further
investigation is necessary.
*fixed memory leak in the disis_phasor~ external where the destructor
was never properly called and updated its documentation (available in
the l2ork_addons package).
*fixed highlighting of signal nlets where nlet would revert to
non-signal appearance after being highlighted/connected.
*reintroduced array listview (this was a regression in respect to
pd-extended).
*improved appearance of the array listview.
*fixed a few broken links in the pddp documentation and added new
l2ork-specific array features to the pddp documentation.
Latest snapshot is available from the usual place:
http://l2ork.music.vt.edu/main/?page_id=56
Complete changelog since 11/25/2010 is available here:
http://l2ork.music.vt.edu/data/pd/Changelog
Happy belated Holidays!
Best wishes,
Ico