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
On Fri, Oct 04, 2002 at 09:43:18 -0400, Paul Davis wrote:
> 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.
- Steve
> From: Steve Harris [mailto:S.W.Harris@ecs.soton.ac.uk]
> Not that this is a good thing, it should be fixed. I didn´t
> check to see
> if there was a client name query function. If so I will use
> that, if not I
> will probably just move to always using bridge-<pid>. ¿comments?
The only thing I don't like about the <jack-client-name>-<pid> idea is when
you've got applications (ardour) that try to re-establish previous jack
connections it can't.
I'm not sure that you'd want to do this with the meterbridge but it's
something that needs to be handled if we want to be able to save and restart
a "jack session".
Regards,
Jake.
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
The Rosegarden development team would like to announce the release of
Rosegarden-4-0.8(*) for immediate download. Please go to the project
homepage for further details:
http://www.all-day-breakfast.com/rosegarden
We'll be demoing Rosegarden at the Linux Expo in Olympia, London, UK,
9th-10th October 2002. Come and see us there.
Major features of this release include:
- Improved Notation Printing (draft quality)
- realtime LADSPA plugin support (chainable plugins for each Instrument)
- Note entry using the PC keyboard in notation view
- Major Matrix view improvements (zooming, snapgrid size, quantizing)
- Major Performance improvements in sequencer
- "Stuck notes" problem fixed
- Matrix velocity setting dialog
- Segment positioning guides
- Turn repeating Segments to real copies
- Matrix view auto scrolling
- Rudimentary lyric editor
- Chorus, Reverb, Resonance, Filter, Attack, Release MIDI controls
- Specialised Rotary Control widget
- Repeating Segments work to end of Composition marker
- Composition Start and End Markers can be changed
- Splitting Segments fixed
- Audio volume faders
- EventList editor extended
- Better Audio Waveform Previews
- SysEx, Program Changes, Controller Changes, PitchBend all supported
and editeable at Composition level
- Toolbars & Settings saving fixed
- Some new useful keyboard shortcuts
- Optional Transport toolbars
- More preference settings
- A couple of new note transformation functions
- Some fixes to progress reporting
- More help text for Notation
* - We've adopted a new numbering scheme for tarballs and packages that
will hopefully make things less confusing in the long term. We've
also jumped several release numbers for this release in an effort
to make things more confusing in the short term.
This release is Version 4, Release 0.8 : rosegarden-4-0.8.tar.gz
Last release was Version 4, Release 0.2 : rosegarden-0.2.tar.gz
Now supports connecting to input ports and you can control the number of
columns of meters with -c, -c 1 will give you a vertical strip.
http://plugin.org.uk/meterbridge/meterbridge-0.0.4.tar.gz
Input monitoring "works" by disconnecting everything from the port,
connecting it to the meter in and connecting the monitor out of the meter
to the original port. When it quits it tries to put things back the way
they should be, but it might not always get it right.
If you run too many (8+) then things start to get dodgy, jack carries on
running, but you can't quit meters. I don't know why.
Thanks to Joern and Gerd for testing the extra-alpha versions, and Kai for
fixing the autoconf mess.
- Steve
