>>>it's easy for non-programing people to bring "visions" regarding
>>>interface design. (and i love do so :) as i know programers, it's quite
>>>hard to establish a new standard. but imho the interface standards
>>>(buttons, dropdown boxes, scrolling, menu-structure, etc.) are now a
>>>couple of years old, and there might be better solutions for specific
>>>tasks. audio seems to me like a good point to start.
>
>
> i wasn't talking about such rudimentary stuff. of course there are
> alternatives to these basic widgets and several audio applications (even
> free ones) have begun to support them.
>
> the point about a visual interface is that it acts as a "memory buffer"
> for the user: you do not have to remember much about the structure of
> the session because the structure is made visible on the screen. can't
> remember precisely where you put a certain sound? how many copies of the
> bridge riff did i put in? is the door slam before or after the creak?
> its all there on the screen, just waiting for you to look at it.
>
> as soon as you move away from a visual UI, you have to find some way to
> avoid requiring the user to remember everything about the session.
when i try to remember a poem my brain creates images and i walk trough
them, when i reproduce it. when i learn a piece of music it does other
stuff (i'm a pianist and singer) but in the end i have a very complex
thing in my mind, just think of a bach fugue. i have the fugue also in
"the fingers". different areas of the brain work together. i have the
same oppinion as you, we are very good in using a visual UI. we trained
it for a long time. but there could be other combinations that work
nearly as good as "mouse-to-eye".
> the visual interface offers another hard-to-replicate feature as well:
> trivially variable precision. if you try doing cut-n-paste based only on
> audio feedback, you will find it quite hard/laborious to be as precise
> as you might want to be. with the visual interface, its much easier to
> use visual information to get the rough location of an edit and then
> get to precisely where you want, without many steps. with audio feedback
> based approaches, i think you will find yourself needing many more
> iterations through the edit-play-edit-play cycle before you get the
> location correct.
i think it's all a matter of training. you do the
"display-keyboard-mouse-combination" for long years and you became
professional in speed and precision. watch a pro-gamer gaming with
mouse.. what's about data-gloves? whats with feet-controlers and other
"non-standard" devices?
greets,
gabriel
(sorry for my clumsy english)
I am looking for suitable hardware to handle digital i/o between a Linux
system and an RME ADI-2 ad/da converter that I just bought. I don't need lots
of channels, but reliability of the data transfer is important, including
jitter reduction. An RME card would be excellent but it is somewhat outside my
budget. Also, connectivity to a laptop would be desirable, suggesting either a
USB interface or waiting until http://freebob.sourceforge.net/ (the Alsa
firewire project) matures. I don't plan to run any OS besides Linux with this
hardware, so Alsa support is crucial. As this is for home/personal use I'm not
in a hurry. M-Audio hardware is high on my list of possibilities at the
moment.
Now to the software question: does there exist any sound editor with a
non-graphical interface, i.e., one that can be operated from the Linux console
for inserting, deleting, copying and otherwise editing audio? Due to a
vision-related disability I can't use a graphical display and therefore need a
text-only solution - but all the sound editors appear to require X11. Surely
it should be possible to design an audio interface to a digital sound editor.
Suggestions welcome.
I've discussed hardware on this list once before, and the USB options weren't
highly regarded at the time.
hello all - got a question - I've only recently been stopping and taking a
look at my studio computer's performance and in the almost year since I
change from Red Hat 9 to gentoo, it's been more solid on some things, but I
notice a huge latency difference - ie: I have to run Jack at -p 8192 to get
anything done in Ardour
Anybody have any tips on what to look at to tweak it? Seems like it should
do better than that... I didn't see it as a problem until in the last few
days I started playing with playing softsynths live directly into Ardour -
you've gotta be running at -p 1024 or there's a latency that screws up your
playing - at 8192 it's a downright 8th note delay...
Here's some vitals that I can think of:
OS: gentoo 2.6.6-rc1 kernel (alsa built in)
jack: 0.99.0
ardour: beta28
jack command line:
jackd -R -d alsa -d hw:0 -r 48000 -p 8192 <------- (or whatever)
harddrive:
multicount on
io support: 32 bit
unmaskirq on
use dma on
keepsettings off
readonly off
readahead on
chip: 2ghz amd (I THINK - not at computer now)
ram: 512MB
thanks for any ideas! :)
---------------------
Aaron Trumm
www.nquit.com
-----------------------
( LAU folk: this is an initial outline of an email I want to dispatch to
the desktop-architects list in the very near future. Your comments
are eagerly sought. Note that this section specifically seeks to
avoid any discussion of implementations or specific approachs. I
would like to fully flesh out the list of tasks ASAP )
Making Sound Just Work
------------------------
One of the "second tier" of requirements mentioned several times at
the OSDL Portland Linux Desktop Architects workshop was "making audio
on Linux just work". Many people find it easy to leave this
requirement lying around in various lists of goals and requirements,
but before we can make any progress on defining a plan to implement
the goal, we first need to define it rather more precisely.
DEFINING THE GOAL
=================
The list below is a set of tasks that a user could reasonably expect
to perform on a computer running Linux that has access to zero, one
or more audio interfaces.
The desired task should either work, or produce a sensible and
comprehensible error message explaining why it failed. For example,
attempting to control input gain on a device that has no hardware
mixer should explain that the device has no controls for input gain.
PLAYBACK
- play a compressed audio file
* user driven (e.g. play(1))
* app driven (e.g. {kde,gnome_play}_audiofile())
- play a PCM encoded audio file (specifics as above)
- hear system sounds
- VOIP
- game audio
- music composition
- music editing
- video post production
RECORDING
- record from hardware inputs
* use default audio interface
* use other audio interface
* specify which h/w input to use
* control input gain
- record from other application(s)
- record from live (network-delivered) compressed audio
streams
MIXING
- control h/w mixer device (if any)
* allow use of a generic app for this
* NOTE to non-audio-focused readers: the h/w mixer
is part of the audio interface that is used
to control signal levels, input selection
for recording, and other h/w specific features.
Some pro-audio interfaces do not have a h/w mixer,
most consumer ones do. It has almost nothing
to do with "hardware mixing" which describes
the ability of the h/w to mix together multiple
software-delivered audio data streams.
- multiple applications using soundcard simultaneously
- control application volumes independently
- provide necessary apps for controlling specialized
hardware (e.g. RME HDSP, ice1712, ice1724, liveFX)
ROUTING
- route audio to specific h/w among several installed devices
- route audio between applications
- route audio across network
MULTIUSER
- which of the above should work in a multi-user scenario?
MISC
- use multiple soundcards as a single logical device
>From: Neil Durant <lists(a)sphere3.co.uk>
>
>I'd be happy to sample the full lengths of all 35 notes for all six sounds,
>storing them as wavs. I don't have a lot of spare time these days, so I'll
>let someone else have the pleasure of cropping/editing!
Please do so. Make the files available from your site or
upload to
ftp://ftp.funet.fi/incoming/audio/
Note: If we end up to conclusion that the samples cannot
be put freely available, then I could make the samples
privately available for the following kind of project.
Research experts should analyse the sounds and come up
with synthesis method which generates as similar sounds
as possible. I'm aware of such research teams and I could
ask them to analyse the samples.
I also have a plenty of research papers on such analysis/synthesis
methods. I could place the papers privately available for anyone
who wish to write the analysis/synthesis software.
Regards,
Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev
for developers of open source graphics software
http://www.notam02.no/arkiv/src/
ABOUT
-----
jack_capture is a small simple program to capture whatever
sound is going out to your speakers into a file.
This is the program I always wanted to have for jack, but no
one made. So here it is.
USAGE
-----
jack_capture [-f filename] [ -b bitdepth ] [-c channels] [ -B bufsize ]
Filename is by default auotogenerated to something like "jack_capture_<date+exact_time>.wav"
Bitdepth is by default FLOAT.
Channels is by default 2.
Bufsize is by default 262144.
ACKNOWLEDGMENT
--------------
Mostly based on the jackrec program in the jack distribution
made by Paul Davies and Jack O'Quin. Automatic filename generation
code taken from the timemachine program by Steve Harries.
--
> 2. Re: Re: A bit of homemade music (Steve D)
> Date: Fri, 23 Dec 2005 19:08:02 -0700
> From: Steve D <groups(a)xscd.com>
>
> Thank you, Gavin, and also to Ron P. and James S. for your compliments
> and comments.
>
> And Gavin, I hope you post a few links to your music so that others on
> the LAU list can hear them. ;-)
>
Hi Steve,
Here is where about half of my electronic tracks reside:
http://stage.vitaminic.co.uk/main/gavin_stevens/all_tracks/
These tracks weren't made with Linux - they weren't even made on a
computer as such, just using my keyboard's onboard sequencer. They date
from 1990-1998.
I now have my digital piano back at home & I shall soon have everything
moved into our new extension at home. Then I hope to upload some of my
classical piano music & maybe do some new electronic music, all of which
definitely will be using Linux. I also have another album's worth of
tracks hanging around from the 1990s that I have never finished off
properly, so I hope to polish those up as well.
Anyway, for all who are interested, the Vitaminic site has plenty to be
going on with.
Gavin.
The possibility of using and contributing to studio
quality audio software is really what first sparked my
interest in linux. So I installed Mandrake 10.1,
because someone gave it to me and it sounded cool.
Since then i've had a lot of fun with it, using their
mm kernel and running jack with seq24 and trying to
come up with something cool enough to use ardour for,
and everything ran relatively reliably. BUT... The
lan componets of the distro simply don't work, the USB
plug and play is more like
plug-and-if-i-feel-like-it-play, and the printer
suport is also compleatly unreliable. So, just use
mandrake for when i'm feeling musical and reboot to
Micro$oft whenever i need to do anything else, right?
well, that's getting old.
So i took a friends advice and started playing with
gentoo. After all, it's well documented. and it was
fun writing all those config files and oh so neat to
DIY, but then i tried to install Gnome, and after like
a 7 hour compile that i can't yet figure out how to
use i'm thinking, what have i gotten myself into...
So does anybody out there have the best of all worlds?
good free documentation, reliable hardware support,
binary packaging, a fast audio kernel, and config
files that don't get re-written by some user friendly
script somewhere that would be oh so convinient except
for the whole doesn't work thing?
If your system works the way you want it too most of
the time, i want to hear your opinion.
gratefull,
Brian
I am thinking of getting an AMD X2 system. I want to avoid Nvidia
chipsets as their hardware is too closed and the Via stuff seems cheap
which leaves me with ATI (I realize the latest stuff does not have open
drivers, but at least there's a chance they'll release one eventually)
Does anyone have any experience with the ASUS A8R-MVP?
http://www.mwave.com/mwave/viewspec.hmx?scriteria=BA22189
Thanks,
Lee
hi...
just wanted to tell you all that the netjack effort is approaching full
functionality.
i need some evaluation on the transport sync code now.
it should be possible to have two network synched ardours now.
however it is possible, that there is a constant delay between the two.
and i have seen some latency which accumulated between the two jackds
once. so please give this thing a field test.
the current version i would like you all to test is the cvs version
which can be obtained at
http://www.sourceforge.net/projects/netjack
sorry that for building you still need a compiled jack-build directory.
i hope the instructions are good enough.
ok... i go to bed now... good night.
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language