Folks,
I am new to LAD, and I have a personal mission in which I hope I'm not
alone. I am trying to scope the work involved in interfacing the Line6
GuitarPort to Linux. I've searched the LAD archives, but can't find a
thread about it. Would those of you who gotten further along the curve
than I, please clue me in: where is this being discussed? I've also
emailed Line6's bizdev but have no answer. Is the interface spec
available for $$$?
Thanks in advance,
Ike, stoddard_AT_ghg.net
I have released GWC 0.17-6 (beta). This release primarily is an
integration with libsndfile, and also improvement in denoising
using a hanning-overlap-add (well, kinda) windowing method.
Find it at:
http://gwc.sourceforge.net/
While I believe improvements could be made in the click detection
algorithm in regards to reducing the false positives, I am going
to forgoe that effort because --
At long last, I am going to take the first steps toward making
the algorithms plugin-able, by creating a library interface first.
This is largely due to prompting by Conrad Parker. I've looked
at the LADSPA thing, and asked a couple of people, and these algorithms
are not LADSPA-ize-able. So, a first reasonable step is to just
create a library of routines, with a well defined API which other apps
can code against, eventually a plugin of some sort could be coded against
the library.
Over the next month, I hope to have the denoising algorithm converted
to a library interface (having a day job really does get in the way :-)
I'll post here along the way for help/tips -- and if anyone has some
suggestions for me now, speak up! I am still relatively ignorant on
linux audio, I need all the help I can get...
jw
> will try to create an input -> input connection sometime tommrow and see
> what happens.
In case this doesn't work, I'll offer more detail on how to do it with
busses. The more I think about it, the more I like the idea of
preserving output -> input semantics anyway.
Currently, when connecting more than one output to Client A's input,
jack automatically adds the outputs and writes the result to A's
buffer. This is now an input port, so its contents are only available
to A. The lazy way to make the result of the add available to a meter,
or any other clients, is to refrain from connecting the output ports to
A's input and create a dummy jack client that just passes its input to
its output. Connect the multiple output ports to the input of the dummy
and connect the output of the dummy to the input of A. JACK
automatically adds the multiple outputs as before, but this time it
writes the result to a buffer that is an output port, so it is readable
by all other clients. The dummy client is a perfect audio bus.
I call this the lazy way because telling the user to use a client that
does nothing, as a way of allowing the user to do something, is absurd.
Also, if A's input is already connected to one output and the user wants
to add another output to A's input, the user must first disconnect the
first connection, then create the dummy, then connect the dummy's output
to A's input, then connect all other outputs to the dummy's input.
That's a lot of stuff for the user to do, indicating a lazy program.
A more ambitious approach is to modify jack to create an input bus
automatically whenever an input port is connected to more than one
output port. First eliminate the ability for a client's input to be
many-to-one. Every input port can now connect to only one output port.
This might seem drastic but it's not, and it perfectly models the
physical world (in the physical world, connecting two outputs to one
input also connects their outputs to each other. Since output impedance
is lower than input impedance, the signals flow from output to output
with excessively high current and the input sees almost nothing. Using
a bus to buffer the outputs is mandatory). This change is hidden from
the user, who will still be allowed to connect as many outputs to A's
input as he desires. The next change is to redefine how jack makes a
many-to-one connection. When the user adds or deletes a connection to
A's input port, jack checks to see if the new total number of
connections is greater than 1. If so, jack inserts a bus, which is just
a buffer, in front of A's input port and writes the sum of the outputs
to this bus. The existence of this bus is hidden from the user (busses
are always hidden internal mechanisms). Now any client can read from
A's input port by reading from the bus output port. The state of the
bus buffer with this technique is more stable than the state of A's
buffer with the current technique, in that it changes only once per jack
cycle while A's buffer currently changes twice per jack cycle.
Tom
For those of you who haven't yet check out the LAU guide (see below) and
quicktoots. There is a new tutorial explaining how to do what you want
with JACK, Ardour and MusE.
I have been trying to get some of the news sites to report on this
latest tutorial. I believe it is a huge step and very important
milestone that has been reached. However they don't seem to want to
report my words. It would be great if a *few* other people made an
attempt then we might be able to catch their attentions.
I have tried linuxnews, slashdot, linuxtoday, and a few others. It would
also be great if someone who has contacts with the pro magazines would
let them know.
As it stands I'm going to keep trying but one voice is not so easily
heard in this big bad world.
--
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.comHttp://www.djcj.org - The Linux Audio Users guide
========================================
"Um...symbol_get and symbol_put... They're
kindof like does anyone remember like get_symbol
and put_symbol I think we used to have..."
- Rusty Russell in his talk on the module subsystem
Hello,
My name is Jane and I am the marketing director of Netsubmissions.net. We are a website submission company that can submit your site to the top search engines such as Google and Lycos utilizing our proprietary custom software. Our packages start as low as $8.99 and we're offering great articles about online marketing with most of the packages. Please check us out at http://www.net-submissions.net
The process takes less than 2 minutes. Check our web site - we will help you obtain more sales. If you have any questions that are not answered at http://www.net-submissions.net please use the contact form or email me.
Once again, I would like to thank you for your time, and if this email was an inconvenience to you, I would like to apologize. If you would like to be removed from our mailing list, please type ¡°remove¡± on the subject and we will make sure to not send you any more emails.
Thank You,
Jane L.
Marketing Director
Cust_service(a)net-submissions.net
Http://www.net-submissions.n
has anyone looked at the distribution of linux that FinalScratch comes with?
I read on their website that you basically install their distribution of
linux and use it, along with their program for selecting audio files, to
play their electronic turntables. I'm just wondering if there was anything
in particular they tweaked for realtime response or if they used the same
low-latency patches as the rest of us?
In case you've never seen it in action, final scratch is a record sized disc
that you place on a turntable that reports it exact position to some sort of
computer interface. The position signal is then used to control playback of
audio files (pcm or mp3) on the computer. You load a file into the program
and mark a certain point as the current point on the record and then the
playback and cueing of the file can be done entirely on a regular turntable
as if you were playing a record. Given that this is just a piece of
hardware, I'm wondering what would stop you from hooking up the hardware to
a regular version of linux.....
besides using a proprietary interface i mean.
--jacob robbins:::::::
_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
What am I missing here? I don't mean to tell the direction from the time,
but to tell the position from the time. The sawteeth all look the same,
right? Don't we need to tell position somehow?
-----Original Message-----
From: Steve Harris [mailto:S.W.Harris@ecs.soton.ac.uk]
Sent: Tuesday, October 08, 2002 8:59 AM
To: 'linux-audio-dev(a)music.columbia.edu'
Subject: Re: [linux-audio-dev] Final Scratch, custom kernel?
On Tue, Oct 08, 2002 at 07:17:43 -0600, Cornell III, Howard M wrote:
> But encode the time so that it can be read forward or backward.
You dont have to, because you know what direction its being read in from
the saw.
An obvious problem is if you jump, then hold the disk and let it turn
slowly, it might take a fair turn before the position can be read...
45rpm = 1 1/3 sec per rev
assume 2400 baud timcode, 16 bits of timecode info (inc. stop bits etc)
= 13.3ms for 2 whole timecode blocks
therefore (max) 1/100th of a revolution to pick up the timecode position
= 1" at the edge of a 12" record. min would be 1/2"
hmm... that doesn't sound too bad to me, and you may be able to get better
than 16bits @ 2400 baud.
- Steve
> It doesn't need an extension to the API, you just have to be able to make
> input -> input connections. I belive that makes more sense in an abstract
> sense (eqivalent to wiring it that way in hardware) and internaly (reduced
> complexity).
This will work if the powers that be agree to allow input -> input
connections. If not, there is another way. In a hardware mixer,
many-to-one connections always require a bus, which is nothing more than
a unity gain summing node. Since jack performs unity gain summing for a
many-to-one connection, then the buffer that the sum is written to could
be redefined as a bus. Then any client could read from the output port
of this bus. I am not necessarily in favor of this, nor am I against
it. I don't know enough about coding to have an opinion either way.
What I do know is that this approach preserves the output -> input
semantics.
Tom
But encode the time so that it can be read forward or backward.
-----Original Message-----
From: Steve Harris [mailto:S.W.Harris@ecs.soton.ac.uk]
Sent: Tuesday, October 08, 2002 2:52 AM
To: linux-audio-dev(a)music.columbia.edu
Cc: Paul Winkler
Subject: Re: [linux-audio-dev] Final Scratch, custom kernel?
On Mon, Oct 07, 2002 at 02:33:54 -0700, Paul Winkler wrote:
> Encoding stereo to an LP is no problem - the needle vibrates along
> two axes. There's a limit to how much stereo separation you can
> get (I forget, it might be like 40-45 dB) but that shouldn't be
> too hard to account for.
OK, but as long as there are no other restrictions on the channels it
should be no problem, something like a saw on one side (to detect speed
and corresponding carrier wave speed), and an AM modulated timecode signal
on the other.
Use the say to calculate the carrier wave for the 2nd channel, then decode
the timecode.
- Steve
