Tk Ecasound 0.6.0 was released!
Dowload it: http://www.sourceforge.net/projects/tkeca
Changes:
- Options button works . Allows to edit ecasoundrc file
- Entry for selecting current directory
- Bug fixes on "Save as" button, open file where there was an existing
project, play with choosing a different device (<> /dev/dspN)
- Autodetect external audio editor and ladspa directory
- Visual changes in effect windows
Regards,
Luis Pablo
Cobertura especial de la Copa Mundial de la FIFA Corea-Jap�n 2002, s�lo en Yahoo! Deportes:
http://ar.sports.yahoo.com/fifaworldcup/
Interestingly enough, the FinalScratch system does not allow cueing to
different positions in the record by lifting the needle up off the record. I
saw Richie Hawtin playing on one in DC and I didn't realize what it was at
first. I was really perplexed because it seemed like everytime I looked up
he was just at the beginning of a record: the tonearm was always very far
out towards the edge of the record. Then I figured out that he was using
final scratch because he was picking the tracks from a laptop nearby running
a program that was basically two lists of tracks. I didn't even think the
position signal was running through the audio, I thought they had a separate
system magnetically measuring the record position. But it must be something
like the saw tooth signal described in this discussion.
I wouldn't worry too much about using the cueing of the needle on the
record to move through the track. It's more useful on a real record because
different sections of a track actually are visible to the naked eye on black
vinyl, which jogs your memory into remembering the layout of the track. The
final scratch record must have a single loop out at the edge of the record.
Such a loop is called a locked-groove when put on a real record: certain
styles of dance music have a convenient bpm that allows putting a complete 4
bar pattern into one seamless loop towards the end of the record (the
middle). I've only encountered this in techno tracks. There can be a
complete track which ends by moving into the lock groove which plays
endlessly until the dj stops the record. The beat must perfectly fit one
rotation of the record in the lockgroove or else the rhythm will be broken.
The same constriction applies to making a lock groove of a control signal. I
am convinced final scratch records have a few locked grooves of a control
signal at the edge of the record.
Adding positional cueing would be a nice feature but consider some of
the following circumstances: -you have to put a lock groove at the end of
the spiral groove anyway or else you limit the length of track that you can
control to some arbitrary amount of time. -if you try to get around this by
making a 30 minute track you'll find that the groove is cut smaller so that
the record will wear faster and will skip much easier when you scratch it.
This is why dance singles have one 6-10 minute track cut on the entire side
of a 12" record; record wear is a factor for a dj playing a track many times
and bigger grooves hold up longer to repeated playing. They will also sound
better longer which is not really an issue here. records tend to wear by
pushing towards the outside of the groove from centripedal acceleration. -if
you make a 10 minute position-coded section leading into a lock groove you
will have to have the standard width of the 10 minute section map to the
length of the entire track being played. This means that moving the needle
to the middle amounts to saying "move 50% of the way through the track"
(which is pretty useful). But it's probably going to end up being easier to
cue through the software. Hell it will be easier to do everything through
the software. The only advantage I see a turntable controller having is for
scratching effects and for dj's who don't want to carry a lot of records.
And maybe for beatmatching audio files but programs are leaning towards
doing that ahead of time (GDAM). As such I wouldn't worry too much about the
positional thing, in favor of getting very tight velocity response for
scratching and beatmatching. 8 ms will kill you in beatmatching and final
scratch has to have closer than 8 ms "grip" on the audio file being
controlled. ~4 ms off is audible phasing. I think it's very interesting to
investigate it but it might be easier to just cut a lock-groove control
signal and not bother about encoding digital signals on a record.
---jacob robbins;;;;;;;;;
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
---------- Forwarded message ----------
Date: Mon, 7 Oct 2002 23:07:47 -0400 (EDT)
From: J.F.Quackenbush <hormonex(a)yankthechain.com>
To: linux-audio-dev(a)music.columbia.edu
Subject: Re: [linux-audio-dev] Final Scratch, custom kernel?
On Mon, 7 Oct I wrote:
records include stereo information by having different sounds on each wall
of the groove. It seems like teh easiest solution would be to just write
SMPTE LTC to one side and something like word clock or black burst on the
other.
<relurk>
I just read this and realize that I was wrong as this reads. One track is
recorded in the depth of the groove, the other in the width, so the needle
vibrates up and down and side to side simultaneously creating two separate
signals. just wanted to clarify.
<relurk again>
--
/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\-/+\
YankTheChain.com - You can pretend we're not here. That's what I do.
http://www.yankthechain.com/http://www.digitalblack.org/
I read:
> Well i guess encoding absolute time should not be too hard.
> A simple solution could be to have the two stereo channels with different
> frequencies, with the ratio corresponding to the radial position.
forget it there is no such thing as a clean channel separation on
vinyl.
regards,
x
--
chris(a)lo-res.org Postmodernism is german romanticism with better
http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)
here's how i do it:
1st channel:
1.5khz control tone
2nd channel:
bits encoded as follows:
0 : 1 3khz cycle
1 : 2 6khz cycles
marker: 1 1.5khz cycle
so each timecode looks like this:
marker cycle
encoded 0
checksummed bit sequence
encoded 1
marker cycle
each one ends up being about 8ms. so my "latency" is better than theirs!
[i'm pretty sure finalscratch's 12ms assumes the record is moving at
normal speed]
since the frequencies are multiples of each other, the crosstalk from the
cutting head or even from the cartridge that gets used is mitigated
the 0 and 1 starter bits help figure out what's going on depending if the
record is playing backwards or forwards
counting zero crossings works...but don't forget to filter out the low
frequencies [like 80hz and below], since the noise from the person's hand
will fuck things up
i'm fiending to buy one of the finalscratch control records [the guys at
platinum are telling me they're gonna be like 25 dollars], to see what
they're doing
--
John Ketchpaw
kungfu(a)alumni.cmu.edu
On Mon, 7 Oct 2002, CK wrote:
> I read:
> > Well i guess encoding absolute time should not be too hard.
> > A simple solution could be to have the two stereo channels with different
> > frequencies, with the ratio corresponding to the radial position.
>
> forget it there is no such thing as a clean channel separation on
> vinyl.
>
> regards,
>
> x
>
> --
> chris(a)lo-res.org Postmodernism is german romanticism with better
> http://pilot.fm/ special effects. (Jeff Keuss / via ctheory.com)
>
>
> > To me, serial metering is a kludge. Taps are the way. Metering is a
> > visual form of monitoring. I would like to see jack provide the ability
>
>
> Uggh. There should be no special purpose taps IMHO.
In the most generic sense, a tap is simply a read. I would define your
alternative drawing as a tap.
> I don't have a real problem with connecting to inputs (as long as it
> doesn't complicate the graph code too much), but there only needs to be
> oneclass of connection.
There are already two kinds of connections. If a client's input port is
connected to only one output port, the connection is a read. If the
client's input port is connected to more than one output port, the
connection is a write. This kind of connection, many to one, is where
the problem is. I agree that JackPortIsTerminal has nothing to do with
this.
> > the port reconnection code is evil. i think its completely the wrong
> > approach. its just a kludge to avoid using a patch bay.
>
>
> I disagree, its only a kludge because there is no clean way to implement
> it with the current API.
>
>
> The insert connection mode is a feature people want (without dicking about
> with patchbays) and the reconnection code is a logical extension of that.
Insert connection mode for metering is the kludge, metering is
parallel. I don't want to use a patch bay (ever), I think that this
problem indicates that an api change is called for, and I think that
this problem is indicative of a greater general problem regarding the
lack of comprehensive monitoring functionality in jack.
If Client A's input port is connected to only Client B's output port,
then a meter client can effectively monitor A's input port by reading
from B's output port. Reading from an output port is allowed so no
insert connection is necessary. If A's input port is connected to B and
C's output ports, then jack sums B and C's output ports and then writes
the result to A's buffer before A begins its process. It is this moment
after jack has written and before A begins its process that this buffer
could be treated like an output port, and the meter client could read
from this port. Of course jack would need to be modified to allow this.
The larger issue is this. In a jack client/server network the recording
engineer (system administrator) would benefit greatly from having tools
that allow monitoring of data traffic at any node in the network,
visually and audibly. Not just input or output ports, but any node
including different stages of a client process (such as if two plugins
are connected in series in an ardour route and I want to monitor the
output of plugin 1). The connections to these monitoring tools are made
and broken in real time and don't interrupt the graph, as they are
terminal. These tools are Solo, Control Room Out, and Meter.
Tom
GStreamer Pipeline Editor "Thanks for all the fish" 0.2.0 released
A first release of gst-editor, the GStreamer graphical pipeline
editor, is now available for public consumption! This tool allows
easy, graphical construction, inspection, and operation of media
processing pipelines. It can be used as a rapid prototyping tool as
well as a method to learn more about [1]GStreamer. More information
about gst-editor is available on the project's [2]home page.
Work on gst-editor was originally started in 2000 by Erik Walthinsen,
but was left unfinished and unmaintained for a year or two.
Development was picked up in mid-2002 by Andy Wingo, resulting in a
port to Gnome 2, adaptation to the current GStreamer API, and general
UI improvements and modularization. While much progress has been made
in the area of stabilization, crashes still occur from time to time.
Reproduceable bugs should be reported to [3]Gnome bugzilla.
To rehash, for the impatient: THIS CODE IS VERY ALPHA.
Screenshots
* Thomas Vander Stichele took [4]this shot while designing the
pipeline topology for a radio station mixing project:
"It shows two decoding threads that read files from disk,
connected to an adder, which does threaded output (in the
actual app, osssink is replaced again by tee, which sends
data to various output methods).
"After some experimentation, this seemed to be the ideal
pipeline setup, which I was able to verify by setting the
whole pipeline to play (using the buttons at the bottom), then
only pausing the adder (as shown in the screenshot - see the
adder being in pause and everything else in play). Pressing
pause here kept osssink playing for a little bit more until
the queue is empty. In the app, this gives me the time to
disconnect an input pipe, or connect a new one, with the adder
being paused, so as to have seamless playback."
* Andy made [5]this shot while playing around with [6]LADSPA
plugins. Note the automatically generated controls for element
properties, as well as the quick launch palette showing all
available elements.
Download
gst-editor requires GStreamer 0.4.1. It could probably work with
0.4.0, but that is untested.
You can find the source release of gst-player in [7]tar.gz format.
RPM packages will be available from our [9]apt for rpm repository, and
Debian packages should be coming soon to an experimental near you.
Maintainer needed
Andy is heading off to teach physics in rural Namibia for two years.
Needless to say, he won't be doing much development on the editor.
Patches should be submitted to the [10]gstreamer-devel mailing list.
References
1. http://gstreamer.net/
2. http://gstreamer.net/apps/gst-editor/
3. http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer&component=gst-edi…
4. http://gstreamer.net/images/gst-editor-gstreamix.png
5. http://gstreamer.net/images/gst-editor-ladspa.png
6. http://www.ladspa.org/
7. http://prdownloads.sourceforge.net/gstreamer/gst-editor-0.2.0.tar.gz?downlo…
8. http://prdownloads.sourceforge.net/gstreamer/gst-editor-0.2.0.tar.bz2?downl…
9. http://gstreamer.net/releases/redhat/
10. http://gstreamer.net/contact/lists.php
To me, serial metering is a kludge. Taps are the way. Metering is a
visual form of monitoring. I would like to see jack provide the ability
to tap any port, input or output, audio or control data, for monitoring
purposes. This monitoring could be meters, solo while tracking, control
room outs, and anything else that ardour doesn't do. Monitoring doesn't
have any dependencies downstream, so graph issues are minimal. Maybe
the client api could include a way of allowing clients to write to jack
monitor buffers, so that each client doesn't need to implement its own
metering/monitoring/solo scheme.
Tom
I have some wierd performance problems in my convolution software. The
programs does this:
1. read configuration file
2. load some modules with dlopen() and run some init code in them
3. fork a convolution process which starts convolving as fast as it can.
4. provide I/O through shared memory to the convolution process
Although I have disabled the use of the dlopen()'d modules (for
debugging this problem), running the init code in the beginning causes
the convolution loop to take 109ms instead of 62ms.
Even if I close all dlopen()'d modules after fork in the convolution
process, it still runs at 109ms. However, if I replace the init code in
the modules (which just initialises some data structures and read some
configuration) with just a return statement, or load only two modules
instead of three, the filter loop starts running at 62ms again.
Of course it is hard to debug with only this scarce information,
however, if anyone know about general performance problems caused by
loading dynamic stuff into the software with dlopen(), and how they
should be avoided, I'd be glad to know.
Oh, I use a 2.4.17 kernel, low-latency patched.
/Anders Torger
