So far, nobody's mentioned how to get to the aforesaid knob in the
first place, or alternatives
to manipulating it.
Navigating with the mouse is a poor second to precise locating, and
using qwerty actions to set values, be it a knob or slider, is more
accurate.
So, tab, or an associated action to get to the knob in the first
place, and something like ALT+ up/down arrows (as an example) to change the knob
value. Then it's irrelevant whether the knob responds to mouse
up/down/left/right, or mouse wheel, for users who find those options
second best, when a more efficient and precise option already exists.
For graduated speed in the case of a spin knob (starting slow and
getting faster), the user only needs to
keep the actions pressed.
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
Hello
EMutrix is a simple, easy-to-use graphical mixer application for EMU
1010 based cards like the E-MU 1212m, E-Mu 1616m and E-MU 1820 models.
I am releasing the first source package of EMutrix, version 0.1 at
http://emutrix.googlecode.com
It is mostly functional, allowing arbitrary routing between the card's
multiple inputs, outputs and ALSA, setting clock rate and pads. More
features to come in future versions. Try it out if you have an E-Mu
card!
Any comments welcome.
Greetings,
Camilo
After many month of development, we are proud to announce the version
0.6 beta of jMax Phoenix.
The major highlights for this version are:
- A first version of the puredata source compatibility kit, including
the build system and a full example of recompiled object library.
- A large set of usability bug fixed; all the bugs preventing a
smooth work flow have been fixed.
- Error handling improvements: most of the bugs and configuration
errors now results in error messages, and not unexplained freezes.
- A set of examples and tutorials has been recovered from old ISPW
archives; they are not updated to include all the major jMax
functionalities, but it is better than nothing.
Full release notes are available in the release notes section of the
projet site.
This release has been tested on Ubuntu and Ubuntu Studio 10.04, Debian
5, Fedora 13 and Mandriva Spring 2010; check the installation
instruction on the projet site for specific caveats for Debian and Fedora.
The Puredata compatibility sub-project has been *very* time consuming;
in order to better manage my scarce time resources,
we need some user feedback (and possibly help) to be able to evaluate
the actual interest of pursuing this development direction.
For more information and download and installation instructions go to
http://www.jmax-phoenix.org/.
For contacting the project team: contact(a)jmax-phoenix.org
The jMax Phoenix team
Thank you very much for your advice everyone.
As mentioned I have already made the LADSPA plugin and tested it with PulseAudio, so I will take a look at the PulseAudio LADSPA plugin module loader and see if I can add the functionality I need (multichannel audio and detection of when headphones are plugged in). Then I will see how it goes from there.
/Kim
Hi,
I want to make is a DSP module that improves the sound quality
of the sound coming from the laptop builtin speakers by applying DSP
(FIR/IIR filters).
I want to route all audio played back (from for
instance an offline WAV or MP3 file, from a movie, or streamed from the internet) to
pass through the
DSP plugin whenever headphones are NOT connected. When headphones are connected no processing should be applied.
I
want to place the DSP module as close to the hardware as possible to
make sure all audio is really routed through the DSP plugin so I always
can enjoy
the DSP improvements made to the sound.
Where should I place this module/DSP code?
- As a plugin to PulseAudio?
- As a plugin to ALSA?
- As its own virtual sound card?
- In the audio driver for my built-in sound card?
- As a kernel module?
I have tried loading the LADSPA-module using the module-ladspa-sink in PulseAudio but I am not sure this is the best solution.
I need to remove some limitations in module-ladspa-sink to get it working properly ( multichannel audio, only DSP processing for internal speakers).
My requirements:
1) Must be able to detect if headphones are connected
2) Must be able to process stereo and multichannel (5.1/7.1) formats. I
need the multichannel formats to perform binaural downmixing to
stereo.
So it is important that I can receive multichannel audio and mix it down to stereo and output it to a stereo soundcard.
/Kim
Alex, I hope you don't mind quoting part of your message on the list,
as the subject is of general interest.
Alex stone wrote offlist:
> Fons, i've read in the mailing list in the thread concerning mixers,
> that you have something you're working on.
> ...
> More than any other facet of working in software for audio/midi/vid,
> i've been frustrated and tired out by poor navigation options, and i
> don't think i'm on my own.
> The mouse is insufficent for ease, speed, and pain free day in day out
> use, and i ask you to at least consider (or not, as you decide)
> alternatives such as the one above, to make a difference in the way
> users commonly interact with this type of software.
I more than agree with this. Defining the way a user interacts with a
large software mixer is 90% of the work of writing one. Common GUI
methods just don't work for this sort of thing.
The thing that is slowly taking some form here will observe some
GUI guidelines quite strictly, in particular there will be *NO*
repeat *NO* resizing, scrolling or moving of windows, menus will
be used sparingly and be small, and popup dialogs will be used
only for operations that can be assumed to be infrequent (mainly
setting up things, selecting and connecting plugins, etc.).
When setting up a new session, you define the resources:
- number of channel strips
- number of real groups
- number of control groups
- number of visible sections
- number of strips per section
- number of jack/alsa inputs
- number of jack/alsa outputs
These are more or less fixed afterwards, in the sense that you
can't remove any, but probably I can allow to increase these
numbers (the point here is that all snapshots taken for such
a configuration must remain valid without requiring changes
to the resources). Anyway there is no penalty (apart from a
small amount of memory used) for providing more than you need.
A _section_ is a group of strips, typically 8, 10 or 12.
Normally you should select the section size so you can have
two of them side by side, as this facilitates many operations.
For each visible section there is a control strip, which
contains e.g. buttons to select which strips are shown.
You will have default sections, e.g. inputs 1-8, 9-16, 17-24,
etc, same for real groups and control groups. There are also
user-defined sections: these can contain copies of any strip
you want in any order you want. For example you could group
all inputs used for drums in a secion, or have a 'master'
section that contains mainly groups and maybe some solo mics.
There is some 'intelligence' in the section selection buttons,
for example, if you select to see inputs 17-24 in the right
section, you click that button (or use a kb shortcut), then
clicking again restores the previous view. Or selecting a
section that is already visible will swap the two, etc.etc.
Each visible section is vertically divided in two, the bottom
half showing the faders, channel ID, mute, solo etc. most of
the time, while the top half can show parts of the strips, e.g.
EQ, sends or dynamics. Again this layout is configurable to some
extent, you can e.g. select to have some aux sends visible all
the time. The top part of each visible section can also be used
for plugins, metering, 'visual' panning, or whatever extra
functions that would need to be displayed.
All Jack/Alsa ports are generic, each of them can be assigned
to any function inside the mixer. That means e.g. that Jack
connections can remain fixed no matter how you 'rewire' the
mixer, and this in turn means that nothing is lost if you
connect directly to a multichannel Alsa device, e.g. a MADI
card.
The mixer will have its own plugin interface, and it will not
accept any of the existing standards. If someone wants to use
a LADSPA or LV2 I will consider porting it. Condition for this
will be the *quality* of the plugin, and nothing else.
Ciao from very hot Crete (I'll be cooling down 20m below the
water surface in a short time).
--
FA
There are three of them, and Alleline.
Comments anybody :-)
http://techrights.org/2010/08/27/throwing-a-wrench-at-protools/
...........................
I have heard from a reliable source, inside Digidesign, that they
actually have Protools running on Linux, and that the port from OSX
isn’t that hard, but are under contract obligation to Microsoft to not
release a Linux port. Otherwise Microsoft can revoke their access to
the Windows SDK.
..........................
Niels
http://nielsmayer.com
On Sat, Aug 28, 2010 at 6:44 PM, Alexander Kojevnikov
<alexander(a)kojevnikov.com> wrote:
> You can try running spekle under valgrind [1]. After testing it on a
> flac file I already see that spek_spectrogram_put_pixel() is used with
> wrong arguments causing an out-of-bounds memory write.
Thank you for the clue. I'm especially thankful that I won't have to
run valgrind for hours on end with my CPU fans whining at top-speed
just to decode a video or mp3 :-) ... I will just go straight to
debugging spek_spectrogram_put_pixel().
I've added your suggestion to my issue:
http://code.google.com/p/spekle/issues/detail?id=1#c3
> On a side note, feel free to submit patches adding batch support to
> Spek, there's even an open issue for it [ http://code.google.com/p/spek/issues/detail?id=6 ]
I added the following comment on your issue:
http://code.google.com/p/spek/issues/detail?id=6#c5
...........
http://spekle.googlecode.com is a fork of Spek 0.6 specifically
designed for batch use and for usage without an X server or GUI. It
would be great if the changes for spekle could be incorporated back
into Spek. Although down the road, some functionality I plan to add in
spekle ( http://vamp-plugins.org ) may be out-of-scope for Spek.
It's not something that'll be an obvious patch since I replaced spek.vala with
http://spekle.googlecode.com/svn/trunk/spekle/src/spekle.vala and
and spek-window.vala turned into
http://spekle.googlecode.com/svn/trunk/spekle/src/spek-object.vala and
there's a different set of build targets as well
http://spekle.googlecode.com/svn/trunk/spekle/src/Makefile.am ...
...........
Other code-mangling includes needing to add an extra callback
parameter to the Pipeline() constructor:
http://spekle.googlecode.com/svn/trunk/spekle/src/spek-pipeline.vala
and lots of small changes to
http://spekle.googlecode.com/svn/trunk/spekle/src/spek-spectrogram.vala
. To recognize what changed, comment-outs of your original 'spek-0.6'
code are done with "//" at the beginning of a line, and most of my
changes are marked with an "NPM" comment.
Since I just got 'spekle' running, and my current changes are a
first-pass hacking of your original spek sources, it probably makes
sense for me to continue doing development and debugging on 'spekle'
and at some point in time in the future, submitting a more definitive
patch for http://code.google.com/p/spek/issues/detail?id=6 .
In case you're interested in collaborating on spekle, I added you as a
committer (akojevnikov). It may also make sense to test out batch-mode
ideas in spekle first and then move them back to 'spek' when they've
settled down.
Let me know how you wish to proceed, and thanks for making Spek
available and GPL!
-- Niels
http://nielsmayer.com
Anybody have any ideas on
http://code.google.com/p/spekle/wiki/EvidenceOfMemoryCorruptionOnExit
(warning contains large images,
http://spekle.googlecode.com/svn/wiki/evidence-of-memory-corruption-on-exit…
for error text only).
issue: http://code.google.com/p/spekle/issues/detail?id=1
Summary: after successfully writing a spectrogram image in my first
Vala programming http://spekle.googlecode.com/ (a displayless-version
of
Alexander Kojevnikov's http://www.spek-project.org/ ) I get the
following error, despite not explicitly calling free() out of my Vala
code:
Spekle: saving 'j_s_bach-d_minor_invention.ogg.png'... DONE!
*** glibc detected *** spekle: free(): invalid pointer: 0x00007fa7e05ca010 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3ac0874ac6]
/usr/lib64/libpixman-1.so.0(pixman_image_unref+0x83)[0x3ac9e161b3]
/usr/lib64/libcairo.so.2[0x359c016b85]
/usr/lib64/libcairo.so.2(cairo_surface_finish+0x36)[0x359c02c9d6]
/usr/lib64/libcairo.so.2(cairo_surface_destroy+0x55)[0x359c02ca45]
spekle[0x406b1e]
/lib64/libgobject-2.0.so.0(g_object_unref+0x15f)[0x3ac380da1f]
spekle[0x407d3d]
/lib64/libgobject-2.0.so.0(g_object_unref+0x15f)[0x3ac380da1f]
spekle[0x403857]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x3ac081eb1d]
spekle[0x403439]
The errors seems to occur intermittently, and more often when using
media that is ogg. Retrieving via HTTP seems to reduce the error
potential, but it still happens that way too...
The relevant libraries and compiler I'm using:
vala-0.9.3-1.fc12.x86_64
vala-tools-0.9.3-1.fc12.x86_64
vala-devel-0.9.3-1.fc12.x86_64
libpng-devel-1.2.44-1.fc12.x86_64
libpng-1.2.44-1.fc12.x86_64
gtk2-devel-2.18.9-3.fc12.x86_64
gtk2-2.18.9-3.fc12.x86_64
ffmpeg-0.6-2.fc12.x86_64
ffmpeg-libs-0.6-2.fc12.x86_64
ffmpeg-devel-0.6-2.fc12.x86_64
See http://spekle.googlecode.com/svn/trunk/README for instructions on
obtaining by 'svn' and building on Linux.
Niels
http://nielsmayer.com
Hi,
As I was checking out the new mudita24, I noticed that the peak
line on the meters doesn't go to zero after the signal is
'silence'. I have to manually click "reset peaks".
Is this on purpose?
David
PS: nice overhaul, great work, thanks.