hi everyone!
for those among you who will make it to LAC 2009 in parma: we are
looking for 1-2 more people to help with the streaming. your job would
be to watch the paper sessions, hang out on IRC and relay the questions
of remote participants to the local audience. if you're interested, you
also get to play with some interesting video gear and the blazing new
thusnelda encoder :)
please get in touch!
volunteers will be fed and watered as required, according to the Marije
Baalman StreamTeam Sustenance Plan(tm).
unfortunately, stream overlord eric rzewnicki can't be with us this year
- i'd like to take the opportunity to offer HUGE (and i mean, like,
HUMONGOUS) kudos to edrz for many years (and many more hours) of
volunteer work for this community (not to mention shouldering
frightening travel expenses year after year to haul himself to old
europe). edrz: thanks! i hope we'll see you on IRC.
best,
jörn
Hi
There are bugs which are resilient. One is never sure whether squashing
one doesn't let a plethora of lurking others get loose, like one's
skeleton in the closet falling apart. Paraphrasing Linus' Law, after
ESR: given enough eardrums all bugs are shallow. Thanks to all the brave
souls who keep harnessing the toy to the bone, some of those nasties
could be whipped off. At least for the time being ;)
Trivially speaking, this dot-release marks the 4th anniversary of
Qtractor as an active/personal project and, putting numerology to the
side, it is being released on this April, 4th (04/04). But then, I do
confess, this was just reckoned as an accidental after-thought, as
everything in numerology, I guess :)
Although only one developer is still responsible for 99% of the code
(that's me!:), there's some outsourcing (kind of) shaping and already
pending in its early stages: MIDI event list editing; Windows native VST
plugin support, much in the lines of FST/WINE, as in Ardour, perhaps; a
new logo and/or splash-screen design is also under this way. Keep in
mind that all translations will be asked only after the end of the
current alpha phase, whenever it would be an end to it :P
Most importantly, there's serious help being needed on drafting the user
manual. The current one available is getting outrageously outdated, ever
since the 0.2 situation. It's already getting tough to play catch up.
And everyone knows about developer(s) not feeling like doing
documentation in the first place. Move on. The more participation the
better.
In general, if you ever feel like, please pick up your favorite line on
the ever still TODO list and do step in. You'll be more than welcome:
eardrums, which usually come in pairs, just like eyeballs do, are pretty
wanted!
So dress up your blacky leather and vinyl, put up the spiky collars and
whip it, whip it good B)
Here we go:
Qtractor 0.4.1 (funky dominatrix) unleashed!
Release highlights:
* MIDI editor snap grid. (NEW)
* Multi-clip selection normalize and quantize (NEW)
* Audio export & sample-rate conversion (FIXED)
* MIDI & audio playback sync (FIXED)
* SSE optimization enabled (FIXED)
* and a few more fixes and same lurking bugs ;)
Same old intro/description:
Qtractor is an audio/MIDI multi-track sequencer application, written in
C++ on top of Qt Software's Qt4 framework, having JACK and ALSA as its
main infrastructures and Linux as native and exclusive platform.
Specially suited to the lone-wolf composer, arranger and (re)creative
music-maker personal home-studio, it still hopes to evolve as a fairly
featured desktop audio/MIDI workstation or at least, a prototypical part
of it ;)
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
- source tarball
http://downloads.sourceforge.net/qtractor/qtractor-0.4.1.tar.gz
- user manual (outdated)
http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf
Weblog (upstream support):
http://www.rncbc.org
License:
Qtractor is free, open-source software, distributed under the terms of
the GNU General Public License (GPL) version 2 or later.
Features:
- Multi-track audio and MIDI sequencing and recording.
- Developed on pure Qt4 C++ application framework (no Qt3 nor KDE
dependencies).
- Uses JACK for audio and ALSA sequencer for MIDI as multimedia
infrastructures.
- Traditional multi-track tape recorder control paradigm.
- Audio file formats support: OGG (via libvorbis), MP3 (via libmad,
playback only), WAV, FLAC, AIFF and many, many more (via linsndfile).
- Standard MIDI files support (SMF format 0 and 1).
- Non-destructive, non-linear editing.
- Unlimited number of tracks per session/project.
- Unlimited number of overlapping clips per track.
- XML encoded session/project description file.
- Point-and-click, multi-select, drag-and-drop interaction (drag, move,
drop, cut, copy, paste, delete, split)
- Unlimited undo/redo.
- Built-in mixer and monitor controls.
- Built-in connection patchbay control and persistence (a-la QjackCtl).
- LADSPA, DSSI and native VST plug-ins support.
- Unlimited number of plug-ins per track or bus.
- Plug-in presets, programs and chunk/configurations support.
- Audio/MIDI clip fade-in/out (linear, quadratic, cubic).
- Audio/MIDI clip gain/volume, normalize and export.
- Audio clip time-stretching (WSOLA-like or via librubberband),
pitch-shifting (also via librubberband) and seamless sample-rate
conversion (via libsamplerate).
- Audio/MIDI track export (mix-down, merge).
- Audio/MIDI metronome bar/beat clicks.
- Unlimited tempo/time-signature map.
- MIDI clip editor (matrix/piano roll).
- MIDI instrument definitions (a-la Cakewalk(tm))
- JACK transport sync master.
- MMC control surface enabled.
- MIDI Song Position cueuing support.
- Configurable keyboard shortcuts.
Change-log:
- MIDI editor command item execution order has been fixed, correcting
the redo/undo adjustment of overlapping note events (probably fixing bug
#2723861).
- MIDI clip editor (aka. piano-roll/matrix editor) sees one of its most
wanted features introduced: visual snap grid, now accessible through
View/Snap/Grid option toggle.
- Actual non-zero session length gets back to status bar of main
application window.
- One potential buffer-overflow/memory-corruption crash bug has been
fixed, long due on most audio (down) sample-rate conversions and
affecting audio export in particular.
- MIDI track/channel patch information, ie. bank-select and
program-change events, are now being properly set on MIDI track/clip export.
- SSE optimization is back in town after being mysteriously disabled
since its dawn :/
- Looping and punch-recording now actively mutual exclusive states:
setting either one unsets the other off and vice-versa. Also,
punch-in/out is now made an undoable command.
- Moving tracks, any track, up or down, were leaving MIDI playback and
meter monitoring completely out-of-sync, now fixed.
- Automatic crash-dump reports, debugger stack-traces (gdb),
back-traces, whatever, are being introduced as a brand new configure
option (--enable-stacktrace) and default enabled on debug build targets
(--enable-debug).
- Audio/MIDI drift correction is now progressive, taking a least
significant differential approach, on every read-ahead cycle and
swallowed on loop turn-arounds, as before.
- Improved Edit/Clip/Normalize and Quantize commands, now affecting the
whole extended multi-clip selection.
- Playback is now being temporarily suspended while either transport
rewind or fast-forward rolling is engaged.
- A bad and shame-on-me bug was fixed: this was hideously affecting any
track/clip playback synchronization, most noticeable after toggling
solo/mute track states while playback is rolling and skipping the
play-head backward over more than one clip under the same track.
- A floating-rectangle flip that showed while dragging new files beyond
the left of main track view is now gone.
- MIDI note event truncation on both track and clip export has been fixed.
Cheers && Enjoy!
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Dennis Schulmeister wrote:
> Hi,
>
> On Wed, 2009-04-01 at 14:48 +0200, Grammostola Rosea wrote:
>
>>> 3. Documentation - especially man pages which are required for all
>>> binaries (even if they just refer to online documentation or info
>>> pages). This requirement is often skipped for Ubuntu-only packages which
>>> makes me as a user sad.
>>>
>> Yeah an manpage is required. You can use the app gmanedit for example to
>> create one.
>>
>
> I really got accustomed to help2man because creating man pages is a snap
> with it. All it takes is the following:
>
> * A sanely formated text file (w/ optional troff commands)
>
What is a sanely formated text file and what do you mean with (w/
optional troff commands)?
> * Your program's --version string
> * Your program's --help string
>
> That's it. With such tools available there's really no excuse for not
> having a man page.
>
>
>
> Yours sincerely,
> Dennis Schulmeister
>
>
Dennis Schulmeister wrote:
> Hi,
>
> On Wed, 2009-04-01 at 14:48 +0200, Grammostola Rosea wrote:
>
>>> 3. Documentation - especially man pages which are required for all
>>> binaries (even if they just refer to online documentation or info
>>> pages). This requirement is often skipped for Ubuntu-only packages which
>>> makes me as a user sad.
>>>
>> Yeah an manpage is required. You can use the app gmanedit for example to
>> create one.
>>
>
> I really got accustomed to help2man because creating man pages is a snap
> with it. All it takes is the following:
>
> * A sanely formated text file (w/ optional troff commands)
> * Your program's --version string
> * Your program's --help string
>
> That's it. With such tools available there's really no excuse for not
> having a man page.
>
>
>
Thanks for the tip!
What do you think, should an upstream author take care of the manpage or
the package maintainer?
\r
Hi,
Many of the people of the Linux audio community uses Debian or a Debian
based distro (Ubuntu (Studio), 64Studio, Musix, Sidux, Mepis etc. etc.).
Most of those distro's uses and rebuild the packages of Debian (unstable).
There are a lot of audio packages build by the Debian Multimedia Team,
but there are also a lot which are not in Debian yet (and so also not in
Ubuntu (Studio), Sidux, 64studio etc.)
So there is a need for more people who wants to contribute to the Debian
Multimedia Team. Again, you don't have to be a plain Debian user to
contribute or to take advantage of it. You will help to improve the
state of Linux audio in general (at least the Debian based distro's and
their community), which will be good for us all, but also for newbies
who are not able yet to build all the packages themselves to enjoy all
the nice things Linux audio has to offer. Also note that it is possible
to build Debian unstable packages on other distro's then Debian itself
(search for Pbuilder on the Internet for instance)!
It will also be good for the Linux audio developers and their software.
It would be more easy to install, use, test and enjoy the software by
the Linux audio community!
There are a lot of people these day who has an own (PPA) repo. This is
ok, (and maybe it will be a good thing if the Linux audio developers
make their packages available as much as possible in a Debian unstable
repo/package, so it can be used on Debian and it is easy to rebuild it
for Debian based distro's),
But to bundle forces and to get safe, stable and quality packages,
joining the Debian Multimedia Team will get much better quality packages
and you will help far more people then having your solo private repo...
*Why the Debian Multimedia Team? *
1) Because they want to improve Debian for music production!
2) Debian has an flexible, fast and easy package management
3) A lot of people use Debian (based) distro's, Debian itself, Ubuntu
(Studio), 64studio, Sidux, Mepis etc.
4) You will learn to build quality packages
5) You don't have to become a Debian developer (DD), you can just become
and stay a package maintainer.
*What can I do?*
1) Build or improve packages for the Debian Multimedia Team. It's
recommended to maintain packages you use yourself often.
2) Report bugs and wishes
3) Join the Debian multimedia team mailing list:
http://lists.debian.org/debian-multimedia/
*Where can I find more info?*
Wiki:
http://wiki.debian.org/DebianMultimedia
Packaging:
http://wiki.debian.org/DebianMultimedia/DevelopPackaging
Existing packages which needs help:
http://wnpp.debian.net/
Debian New Maintainers' guide:
http://www.debian.org/doc/maint-guide/ (!)
Bugs:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-multim…
It would be great if you choose one package which you uses a lot and
maintain it for the Debian Multimedia Team! It would improve the quality
of Linux audio and it will help the whole community!
Kind regards,
\r
ps. If you like to join, please subscribe to the Debian Multimedia Team
mailinglist and ask for more information:
http://lists.debian.org/debian-multimedia/
Hi,
I'm just an Lilypond user, not an programmer. I really think Lilypond is
a core app for GNU/Linux musicians and many apps has Lilypond export
functions. To keep improving Lilypond and because some people are
starting to work on some Tablature improvements, which makes me really
excited, I thought, let's make a call.
Maybe you are a Lilypond user with a little programming background and
want to contribute to Lilypond or you need a special feature/
improvement in it. Then you can start learning to do the programming
yourself.
You can start as a Frog, some kind of 'Lilypond student programmer'. You
start learning the basics, maybe fix some bugs (like Frogs eat flies)
and add some features you want with the help of the Lilypond developers.
More info about developing for Lilypond:
http://lilypond.org/web/devel/participating/
You can see the Contributors' Guide for some detailed information about
participating:
http://lilypond.org/doc/v2.13/Documentation/devel/contrib-guide/index#index
At this moment there are some guys beginning to work on more and better
Tablature functionality for Lilypond. Which is great imo also to get
better Tablature functionality in GUI apps like Mscore and Tuxguitar.
So maybe it's a good moment to jump in, and I think they can use some
man power!
See for example these threads:
http://www.nabble.com/guitar-tab-feature-request-td21995370.html
Thanks in advance,
\r
(Just an happy Lily user/ guitarist)
Greetings all;
1: I installed the jack suite about a week ago, recommended by a friend and
I've had it grab core0 of my quad core phenom and loop at 100% several times,
however, using qjackctl to stop and restart it always fixes it. Is there a
buglet still around?
2: I have kmail set to play its usual pling as incoming mail arrives, and
since I installed jack, its quite distorted and just a nearly mote whisper.
Is this a possible config error?
It may be that 1 above is related to 2 above as it seems to occur at some
point when the machine is quiet for the night, but fetchmail/procmail/kmail is
still running, so it would be getting tapped at that input several hundred
times by the time I get up the next morning.
Comments/hints welcomed.
Thanks.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
I have replaced NT with Linux.
Linux -- heir of the byte that dogged me.
-- Allan Willis
Hi all!
I have a simple question about OSC, or more specifically, the liblo
implementation: Is it possible to broadcast OSC messages to multiple
receiving ends *in different processes*? That is, without needing to
create N 1-1 communication channels, using N ports?
The obvious thing would be to create two servers listening to the same
port (using lo_server_thread_new ). But liblo doesn't allow creating two
servers listening the same port.
Ideas to work-around this?
P