schoappied <schoappied(a)gmail.com> writes:
> There is posted a message for testers here:
> http://linuxmusicians.com/viewtopic.php?f=24&t=622
> and a discussion about lash here:
> http://linuxmusicians.com/viewtopic.php?f=28&t=609
>
> If you need testers in the future maybe good to left a message there
> or/ and on the LAU mailinglist?
Thank you for your forum post about rc1. Posting announce of rc1 to
dev-only lists only was intetional. The reason is to avoid user
frustration that can be caused by "unpolished" software. Also devs are
supposed to be able to give better feedback for crashing software.
If everything goes as I expect, rc2 announce will probably be posted in
laa and lau mailing lists too.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
I would like to ask LASH beleivers and other interested parties to test
the first release candidate for 0.6.0. Juuso Alasuutari and me have been
doing some major changes to the lash code. We have done lot of work,
we've fixed several big implementation issues and we need stable point
before doing more changes (0.6.1 and 1.0 milestones).
In the tarball there is simple lash_control script. One can also control
LASH through patchage-0.4.2 and through lpatchage (availabe through
git).
User visible changes since 0.5.4:
* Use jack D-Bus interface instead of libjack, enabled by default, can
be disabled. Ticket #1
* Allow controlling LASH through D-Bus. Ticket #2
* Use D-Bus autolaunching instead of old mechanism. Ticket #3
* Log file (~/.log/lash/lash.log) for LASH daemon. Ticket #4
* Client stdout/stderr are logged to lash.log, when clients are
launched by LASH daemon (project restore). Ticket #5
* Improved handling of misbehaved clients. Ticket #45
* Projects now can have comment and notes associated. Ticket #13
Download:
http://download.savannah.gnu.org/releases/lash/lash-0.6.0~rc1.tar.bz2http://download.savannah.gnu.org/releases/lash/lash-0.6.0~rc1.tar.bz2.sig
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Hello,
Few days ago I came up with an idea about an open source guitar
modeling software. But because of my lack of knowledge on both
electronics and audio engineering I couldn't decide if it worths
something. Here it is directly quoted from linuxmusicians.com
**QUOTE**
Okay! My idea is to use GNUCAP or SPICE to process the guitar signal.
These are the top open source analog circuit simulators that are also
widely used in the industry for general purpose circuit simulation
(not audio specific). You basically feed them the schematics of a
circuit and wait for magic to happen. I believe they may be hacked to
accept a guitar signal as a varying voltage source. Now there are 3
questions: Is that even possible? If yes, is it possible in
real-time? If yes, would results be satisfying (quality and accuracy
wise)
**END_QUOTE**
thanks very much, and sorry in advance if I missed something obvious
and this is a completely useless idea
It would be great though since it would take a minimal amount of
effort to make it work with a guitar signal but no real-time means
the end of this idea
thanks very much for the quick answers
I'm trying to set up an E-Mu ESI4000 sampler for SMDI sample transfers on
Ubuntu Studio 8.04, but I'm having some trouble figuring out how to
communicate with the sampler. OpenSMDI relies on SCSI devices being listed
as /dev/sga[a-n] and the SMDITools docs suggest setting up a symlink if SCSI
devices aren't listed that way on the system you're using. The problem is
that it appears that the ESI4000 is not being associated with a device
file. Here's the output from lsscsi:
[0:0:0:0] disk ATA WDC WD800JB-00FM 13.0 /dev/sda
[1:0:0:0] cd/dvd HL-DT-ST RW/DVD GCC-4521B 1.00 /dev/scd0
[1:0:1:0] cd/dvd SONY CD-RW CRX230EE 2YS3 /dev/scd1
[2:0:4:0] process E-mu ESi-4000 Sampler 3.02 -
[2:0:4:1] process E-mu ESi-4000 Sampler 3.02 -
[2:0:4:2] process E-mu ESi-4000 Sampler 3.02 -
[2:0:4:3] process E-mu ESi-4000 Sampler 3.02 -
[2:0:4:4] process E-mu ESi-4000 Sampler 3.02 -
[2:0:4:5] process E-mu ESi-4000 Sampler 3.02 -
[2:0:4:6] process E-mu ESi-4000 Sampler 3.02 -
[2:0:4:7] process E-mu ESi-4000 Sampler 3.02 -
[2:0:5:0] disk IOMEGA ZIP 100 K.05 /dev/sdb
The SCSI ID setting on the ESI4000 itself is set to 4. There is an Iomega
Zip 100 drive (SCSI ID 5) between the sampler and the computer.
SMDITools/OpenSMDI can be found at http://nolv.free.fr/SMDITools/
Thanks,
Dan
Jkmeter-0.4.0 is now available at the usual place:
<http://www.kokkinizita.net/linuxaudio/downloads>
Jkmeter is a combined RMS/digital peak meter based on
the ideas of mastering guru Bob Katz.
New options in this release:
-type k14 : K14 scale instead of the default K20.
Use this for mixing to a higher average level.
-A : Ambisonic (4ch) mode.
-C : Adds a stereo correlation meter.
Used on a Ambisonic B-format signal the correlation
meter uses W and X, and indicates how 'forward' the
sound stage is.
Enjoy !
Ciao,
--
FA
Follie! Follie! Delirio vano e' questo!
Hi list.
My name is Holger Ballweg, I am a student of Musikinformatik (musical
computer science?!) and musicology at the university of music in karlsruhe.
I'm using Linux for quite some time now, often using audio applications.
To discover new applications, there luckily is linuxaudio.org's appdb.
Unfortunately many of the apps aren't actively developed, some are
nowhere to be found because the homepage has vanished.
I just started editing the wiki and wanted to know, if we could add a
tag, which in some way makes it possible to see which projects are still
active or which not.
A possible solution could be to include some mechanism to show which
packages were updated in the last couple years by including a timestamp
for the last release (like proposed in the wiki) in the app entry and to
add an to the listings, which shows projects updated in the last 12 months.
I'd like to mess with the wiki some more, but first I'd like to have a
possibility to mark those old projects...
Cheers,
Holger
Qtractor 0.2.2 (flirty ditz) is out!
------------------------------------
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 prototypal part
of it ;)
Release highlights:
* Stephen Doonan joined documentation team and revised the user manual.
* Spurious MIDI events recording bug ow fixed.
* Audio track monitoring and plugin loop processing slightly improved if
not fixed.
* MIDI clip editor improved precision and correct snapping.
* Multiple track mute and solo one-click toggling (NEW).
* Better MIDI connection persistance across sessions.
* Record-armed tracks aren't muted on playback anymore (NEW).
* Optimized audio clip waveform caching and drawing.
* Many more or less fixes (see change-log)
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Download:
- source tarball
http://downloads.sourceforge.net/qtractor/qtractor-0.2.2.tar.gz
- user manual
http://downloads.sourceforge.net/qtractor/qtractor-0.2.2-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 (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 files (SDI).
- 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 VSTi 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 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.
- MIDI clip editor (piano roll).
- MIDI instrument definitions (a-la Cakewalk(tm))
- JACK transport sync master.
- MMC control surface enabled.
- Configurable keyboard shortcuts.
Change-log:
- Slight optimization in audio and MIDI meters refresh rate.
- Another ancient bug has been squashed: MIDI events were being recorded
even though recording wasn't rolling; spurious event times were being
recorded due to an absent started queue.
- Major fix applied to audio track monitor metering, and most
importantly to plugin processing, correcting tentatively all audio
buffer offsetting and slicing due on loop turnarounds.
- Fixed a potential crash and/or simple record dismissal when changing
properties of a track already armed for recording; prevent record
engaged tracks from editing or removal.
- Lighten up the connections line and highlight colors, as seen to fit
best on some darker background themes.
- Several icons refined with slight transparent shadowing.
- Send/reset all MIDI buses and track controllers (ie. volume and
panning) only when main transport playback is started, avoiding the
pouring on eg. loop, playhead or tempo changes.
- Pressing the Escape key also clears current selection in the main
track-view and MIDI clip editor; resizing multiple events at once
doesn't need help from Shift or Ctrl modifiers anymore.
- DSSI and VSTi plugins get all their default parameters values reset on
MIDI program change.
- Several major fixes have been applied to the MIDI clip editor,
regarding snap precision and correctness, most specially due on clips
which weren't located on exact bar boundaries.
- Brand new usability feature introduced: mute, solo and monitor
toggling may now be applied to all tracks in session at once, when
issued with either the Shift or Ctrl keyboard modifiers, which will set
or reverse respectively all other tracks state.
- Audio buses plugin chain may be also accessed and edited from the
extended bus management dialog (View/Buses...).
- MIDI meter level default color is now set distinct from the old
lime-green one as in audio level meters.
- MIDI clip editor is now a genuine top-level window, fixing all
keyboard shortcut ambiguities with main application window.
- Mixer splitter panes are now collapsible and optionally hidden.
- Make MIDI instrument patch management a little more sane, as for
preventing the accidental insertion of blank instrument names and
automatic default bank/program selection in track properties.
- All connections are now based exclusively on the textual client and
port names, effective in particular to match MIDI bus ports with
disregard to their volatile numerical identification.
- MIDI file (SMF) header endianess fix (PPC users rejoyce:))
- Record armed tracks aren't muted for playback anymore, as this was a
severe crippling nuisance regarding input monitoring and all mighty user
experience after recording a simple take; for instance, as the bottom
line goes, there's no need to un-arm a track from its record-enabled
state anymore, for just recorded material get heard on immediate
playback; kick on the jam!
- Playhead position overflow fixed on negative MMC STEP commands.
- Thumb-view width proportions now based on minimal slack session length
instead of the auto-extending track-view contents width.
- Optimize audio clip drawing, most specially on zoomed-out levels.
- Bring the audio peak frames into some sort of cache, preventing
recurrent peak frame buffer reallocation and trashing.
Cheers && Enjoy!
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On Fri, Oct 3, 2008 at 8:03 AM, plutek-infinity <plutek(a)infinity.net> wrote:
>>Fons Adriaensen wrote:
>>> New options in this release:
>>>
>>> -type k14 : K14 scale instead of the default K20.
>>>
>>> Use this for mixing to a higher average level.
>>>
>>> -A : Ambisonic (4ch) mode.
>>> -C : Adds a stereo correlation meter.
>
> just want to add my sincere thanks for this meter! i've been looking for a k-type meter for a while now, and with the inclusion of both k20 and k14 scales, as well as correlation, this is now going to be *permanently* glued to my screen! (not only for function, but it also just looks really tasty!)
Yes, Thanks Fons. Very handy!
I noticed that jnoise link on your download page goes no where. Is it available?
--
Brad Fuller
www.bradfuller.com
I've been playing with and watching various tutorials for Processing,
the Java framework for generative video and video effects.
http://processing.org/
What blew me away recently, though, was this video from Wesen on
building a "game of life" MIDI sequencer with it (watch the whole thing,
it's worth it):
http://vimeo.com/1824904?pg=embed&sec=1824904
(Of course, Paul reads the same blog that I do, so he'll know about this
already.)
Notice that Processing has its own editor, with controls to compile and
run any program you make in it, single-click. Not much different than an
IDE, I suppose, though I would be hesitant to say that an IDE is better
because it's more powerful, as I would have to disagree: what makes
Processing so powerful and so popular is because it's so specific to its
niche. Combine it with a very thorough (and expandable) framework and it
becomes very powerful.
Why couldn't we make something like that for audio? It would most likely
be C++ rather than Java, but the idea of building up DSP networks using
a large framework of code, plus some pre-defined functions and settings,
and being able to launch our new code with a one-touch button into a
JACK client (or whatever), is extremely appealing to me. Throw in some
GUI-building elements (Cairo-based, perhaps) that can handle
mouse-clicks, keyboard input, and the like, then suddenly people who are
good at math and DSP but not so good at coding might have a shot at
making some great programs.
Consider this a feeler post for a potential project. I am unfortunately
not a great coder, but at this point, I can't help but think that
something badly-coded and working is still better than well-written code
that never actually gets written.
-- Darren Landrum