| Howdy. I have an interesting (I hope!) signal processing question that
arose on a pc soundcard newsgroup. Some web searching didn't turn up
much, so I thought I'd see if anyone here had some ideas.
The goal is to extract the "center" portion of a stereo soundfile; that
is, to be able to end up with three outputs:
--"pure" left information--nothing that is also found in the right input
channel
--"center" information--only things found in both channels
--"pure right" information--nothing found in the left input channel.
The first thing I thought of was to simply subtract one channel from the
other, i.e. L-R. The problem is that, while this does eliminate all
"center" information, it also results in the pure left combined with an
out-of-phase pure right, and no way to separate the two.
Someone else suggested doing this:
L output= 2L - R
R output= 2R - L
...which doesn't help all that much. We now have two different signals,
each of which has attenuated "center" information, but each also
contains some out-of-phase information from the other. It looks like
there is just no simple arithmetical way to do the job.
The last suggestion that came up was to do a FFT of each channel,
compare the information from the two FFTs, and use that to filter each
channel. Implementing this is a bit beyond me and I can't figure out
whether or not it would be effective.
Any ideas?
Alternatively, has anyone already designed a csound instrument to
accomplish this task? Or is there any other shareware/freeware tool
that might do the job?
Thanks much,
Paul
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10892;
8 Dec 97 2:31 GMT
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa06964;
8 Dec 97 2:31 GMT
Received: (qmail 12007 invoked from network); 8 Dec 1997 02:31:22 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
by pat.bath.ac.uk with SMTP; 8 Dec 1997 02:31:22 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (CAA00797); Mon, 8 Dec 1997 02:24:30 GMT
Received: from hermes.ex.ac.uk by maths.exeter.ac.uk; Mon, 8 Dec 97 02:24:13 GMT
Received: from root@solar.sky.net [209.90.0.4] (may be forged) by hermes via ESMTP (CAA18535); Mon, 8 Dec 1997 02:24:01 GMT
Received: from 209.90.4.131 (ts-2-ip3.kc.sky.net [209.90.4.131])
by sky.net (8.8.5/8.8.5) with ESMTP id UAA25452;
Sun, 7 Dec 1997 20:26:54 -0600 (CST)
Message-Id: <348B5B8C.C41BD043@solar.sky.net>
Date: Sun, 07 Dec 1997 20:29:34 -0600
From: Cliff Caruthers
Reply-To: cliffc@sky.net
Organization: Glacial Erratica
X-Mailer: Mozilla 4.01a (Macintosh; I; 68K)
Mime-Version: 1.0
To: csound@maths.ex.ac.uk
Subject: Re: Removing
X-Priority: 3 (Normal)
References: <19971208012235.19417.qmail@hotmail.com>
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Hey Paul,
Sounds like what you're looking for is a way to matrix a stereo file
into m/s (middle/side) format. As I understand it, the formula to
accomplish this is as follows:
L+R = M
L -R = S
The M signal is your middle channel. The S signal you pan left (S+),
then bus to the right channel and throw out of phase (S-). If this is
done correctly, summing the S+ and S- signals should cause total
cancellation.
This should create the three channel effect you're looking for, and it
can be derived from stereo files. I've never done this with csound, but
it should be possible, and I would be very interested in seeing any
working or betaexamples...
Hope this helps.
Cliff
Paul Winkler wrote:
> Howdy. I have an interesting (I hope!) signal processing question that
>
> arose on a pc soundcard newsgroup. Some web searching didn't turn up
> much, so I thought I'd see if anyone here had some ideas.
>
> The goal is to extract the "center" portion of a stereo soundfile;
> that
> is, to be able to end up with three outputs:
>
> --"pure" left information--nothing that is also found in the right
> input
> channel
> --"center" information--only things found in both channels
> --"pure right" information--nothing found in the left input channel.
>
> The first thing I thought of was to simply subtract one channel from
> the
> other, i.e. L-R. The problem is that, while this does eliminate all
> "center" information, it also results in the pure left combined with
> an
> out-of-phase pure right, and no way to separate the two.
>
> Someone else suggested doing this:
>
> L output= 2L - R
> R output= 2R - L
> ...which doesn't help all that much. We now have two different
> signals,
> each of which has attenuated "center" information, but each also
> contains some out-of-phase information from the other. It looks like
> there is just no simple arithmetical way to do the job.
>
> The last suggestion that came up was to do a FFT of each channel,
> compare the information from the two FFTs, and use that to filter each
>
> channel. Implementing this is a bit beyond me and I can't figure out
> whether or not it would be effective.
>
> Any ideas?
>
> Alternatively, has anyone already designed a csound instrument to
> accomplish this task? Or is there any other shareware/freeware tool
> that might do the job?
>
> Thanks much,
>
> Paul
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa10998;
8 Dec 97 3:06 GMT
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa11493;
8 Dec 97 3:06 GMT
Received: (qmail 12963 invoked from network); 8 Dec 1997 03:06:41 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
by pat.bath.ac.uk with SMTP; 8 Dec 1997 03:06:41 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (CAA14688); Mon, 8 Dec 1997 02:59:59 GMT
Received: from hermes.ex.ac.uk by maths.exeter.ac.uk; Mon, 8 Dec 97 02:59:43 GMT
Received: from SYSTEM@alpha.cc.oberlin.edu [132.162.1.245] by hermes via ESMTP (CAA12164); Mon, 8 Dec 1997 02:59:36 GMT
Received: from RN2713.resnet.oberlin.edu
("port 1203"@RN2713.resnet.oberlin.edu) by OBERLIN.EDU (PMDF V5.1-8 #24033)
with SMTP id <01IQWP23HY36000A02@OBERLIN.EDU> for csound@maths.exeter.ac.uk;
Sun, 7 Dec 1997 22:02:36 EDT
Received: by RN2713.resnet.oberlin.edu with Microsoft Mail id
<01BD035B.F46AF740@RN2713.resnet.oberlin.edu>; Sun, 07 Dec 1997 22:03:31 -0500
Date: Sun, 07 Dec 1997 22:03:29 -0500
From: Christopher Neese
Subject: RE: Opcodes
To: "Csound (E-mail)"
Message-Id: <01BD035B.F46AF740@RN2713.resnet.oberlin.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
-----Original Message-----
From: Richard Dobson [SMTP:RWD@cableinet.co.uk]
Sent: Sunday, December 07, 1997 5:22 AM
To: csound@maths.exeter.ac.uk
Subject: Re: Opcodes
Christopher Neese wrote:
>=20
> I hope this message gets through OK; the last time I posted my =
messages were delayed about five days.
>=20
> ABOUT OPCODES:
>=20
> This message is aimed at beginners. Hans Mikelson's Introduction to =
Csound should be a great help to beginners, but there is one point that =
needs elucidation. Both the score and the orchestra make use of =
opcodes, and this can lead to confusion when the manual talks about =
opcodes.
>=20
> The score opcodes are the first letter on each line of the score. The =
legal score opcodes are f, i, a, t, s, and e.
> Score opcodes are always single alphabetic characters.
>=20
> On the other hand, a orchestra opcode is an alphanumeric string, such =
as oscil. It is confusing that both score opcodes and orchestra opcodes =
are simply referred to as opcodes in the manual.
>=20
> For those of you that need a justification for this [like me 8-)], =
suffice it to say that the word opcode has a specific meaning in =
computer science. Both score opcodes and orchestra opcodes are opcodes =
in this sense. However, score and orchestra opcodes are not =
interchangeable, just as English words are usually not interchangeable =
with Latin words.
>=20
Sorry, but I want to quibble about this:
My feeling is that we should restrict the term 'opcode' to the orchestra
file, and use the term 'event' with respect to the score.
With a few exceptions, the basic Csound opcodes are not defined with
respect to absolute time - an instrument can be activated at any time.
Indeed, the code for an instrument could in principle be loaded into
permanent memory - for example, as the basis of a hardware synthesizer.=20
A score event is however entirely defined in absolute time - even the
function tables (I'm talking about 'standard Csound here, not the the
new Extensions), and one would not normally want to frezze an event
stream in hardware, unless one was making a musical doorbell or
something! It is quite natural to refer to MIDI events; a score is
essentially Csound-speak for an event stream.
Richard Dobson
I agree with you, Richard, we should restrict the use of the word opcode =
for the Csound orchestra. "Event" is a better description for the =
Csound score. Unfortunately, the manual does not use this term, but =
maybe it should in a future edition. (I am not sure that the time =
dependence of score events makes them no longer opcodes in a technical =
sense though. My understanding of the word opcode is that it is simply =
a syntactical form used in programming. However, event is still a much =
clearer term for the score.) I do have one problem with the word event =
though, and that is that it really refers to an entire statement (or =
line) of the score file, where as opcode only refers to the first =
character of a statement. Maybe the term event should be used, instead =
of statement, to describe each line of a score file. The term "event =
type" could then replace the term opcode in discussions of scores. This =
would give separate vocabulary for the score and orchestra, and could =
reduce confusion in future editions of the manual. I also must had that =
it does not matter how well we refine our vocabulary on this listserv, =
if the manual still uses vocabulary confusing to newcomers, so I =
strongly ask anyone working on future editions of manuals, in any form, =
to consider making these changes.
Christopher Neese
Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa11458;
8 Dec 97 6:33 GMT
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa15513;
8 Dec 97 6:33 GMT
Received: (qmail 17942 invoked from network); 8 Dec 1997 06:33:13 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
by pat.bath.ac.uk with SMTP; 8 Dec 1997 06:33:13 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (GAA05334); Mon, 8 Dec 1997 06:24:25 GMT
Received: from hermes.ex.ac.uk by maths.exeter.ac.uk; Mon, 8 Dec 97 06:24:09 GMT
Received: from server3.syd.mail.ozemail.net [203.108.7.41] by hermes via ESMTP (GAA10718); Mon, 8 Dec 1997 06:24:01 GMT
Received: from oznet07.ozemail.com.au (oznet07.ozemail.com.au [203.2.192.122]) by server3.syd.mail.ozemail.net (8.8.4/8.6.12) with ESMTP id RAA02886 for ; Mon, 8 Dec 1997 17:26:59 +1100 (EST)
Received: from [203.108.202.80] (slmel13p64.ozemail.com.au [203.108.202.80]) by oznet07.ozemail.com.au (8.8.4/8.6.12) with SMTP id RAA17371 for ; Mon, 8 Dec 1997 17:26:53 +1100 (EST)
Message-Id: <199712080626.RAA17371@oznet07.ozemail.com.au>
Subject: RE: Opcodes
Date: Mon, 8 Dec 97 17:28:39 +1200
X-Mailer: Claris Emailer 2.0v2, June 6, 1997
From: Graeme Gerrard
To: "Csound (E-mail)"
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
I agree that "opcode" is an inaccurate use of the term for score events,
but it is not like this was just a Csound error, it goes way back in
MusicN time. I am not saying that it shouldn't be changed simply because
it already has an established meaning, but that it will be difficult
because there is already a large group of users who already use the term
opcode to refer to score events.
It is not even a good word to use for orchestra function calls; I guess
the whole idea was that Csound orch was a "patch" language that
non-programmers (whatever they are) could easily learn. But I suspect
that Csound users who build new instruments are probably programmers
anyway, i.e. they also program in conventional programming languages.
The other main group of Csound users are those that create new scores
that use existing instruments. (I have never actually met anybody who is
a pernmanent member of this group. It seems to be more of a phase that
people go through when they first learn Csound - or something that people
who build instruments might do when they come across a new technique.)
Why not use the term function to refer to ...er... the function calls in
the Csound orch and a generic term like statements to refer to everything
else?
Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa11553;
8 Dec 97 8:19 GMT
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa17655;
8 Dec 97 8:19 GMT
Received: (qmail 20524 invoked from network); 8 Dec 1997 08:19:11 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
by pat.bath.ac.uk with SMTP; 8 Dec 1997 08:19:11 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (IAA10692); Mon, 8 Dec 1997 08:11:51 GMT
Received: from hermes.ex.ac.uk by maths.exeter.ac.uk; Mon, 8 Dec 97 08:11:35 GMT
Received: from pop.cs.wisc.edu [128.105.22.11] by hermes via ESMTP (IAA16430); Mon, 8 Dec 1997 08:11:28 GMT
Received: from haha.cs.wisc.edu (haha.cs.wisc.edu [128.105.101.31])
by pop.cs.wisc.edu (8.8.6/8.8.6) with SMTP id CAA06472
for ; Mon, 8 Dec 1997 02:14:29 -0600 (CST)
Message-Id: <348BABA0.FF6@cs.wisc.edu>
Date: Mon, 08 Dec 1997 02:11:12 -0600
From: Zhenhai Lin
Organization: University of Wisconsin-Madison
X-Mailer: Mozilla 3.01SGoldC-SGI (X11; I; IRIX 6.3 IP32)
Mime-Version: 1.0
To: csound@maths.ex.ac.uk
Subject: instruments
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Hello:
I am a beginner in CSound. I hope to get some orchestra
files to produce sound near real instruments (like piano, violin, drums
etc.).
I found many files available on the net produces very nice and fancy
sounds but they are not close to any real instruments (rather like
sounds in science fiction movies). One site contains orchestra files
quite close to real instruments but it's not so easy for use because
there are many parameters that a line in score file needs to write. I
have to guess a lot of them to just make it sound right. (I only partly
understand what the orchestra file's implementation of the instruments.)
I wonder if there are some collections of orchestra that emulates
real-life instruments and are easy to use. For example, maybe I just
need to specify the begin time, duration and frequency.(Or amplitude as
extra.)
Thank you very much!
--
Zhenhai Lin
Department of Computer Science, University of Wisconsin-Madison, USA
URL: http://www.cs.wisc.edu/~zhenhai
Email: zhenhai@cs.wisc.edu
Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa12220;
8 Dec 97 13:08 GMT
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa28095;
8 Dec 97 13:08 GMT
Received: (qmail 19931 invoked from network); 8 Dec 1997 13:08:31 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
by pat.bath.ac.uk with SMTP; 8 Dec 1997 13:08:31 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (MAA03035); Mon, 8 Dec 1997 12:47:02 GMT
Received: from hermes.ex.ac.uk by maths.exeter.ac.uk; Mon, 8 Dec 97 12:46:43 GMT
Received: from messiah.cableinet.net [194.117.157.68] by hermes via SMTP (MAA04992); Mon, 8 Dec 1997 12:46:36 GMT
Received: (qmail 25375 invoked from network); 8 Dec 1997 12:49:15 -0000
Received: from lions.cableinet.net (193.38.113.5)
by messiah with SMTP; 8 Dec 1997 12:49:15 -0000
Received: from igor (usr128-haw.cableinet.co.uk [194.117.146.138]) by lions.cableinet.net (950413.SGI.8.6.12/951211.SGI) via SMTP id MAA00150 for ; Mon, 8 Dec 1997 12:48:34 GMT
Message-Id: <348BEB86.879@cableinet.co.uk>
Date: Mon, 08 Dec 1997 12:43:50 +0000
From: Richard Dobson
Reply-To: RWD@cableinet.co.uk
Organization: Composers Desktop Project
X-Mailer: Mozilla 3.0 (Win95; I)
Mime-Version: 1.0
To: csound@maths.ex.ac.uk
Subject: Re: Opcodes
References: <199712080626.RAA17371@oznet07.ozemail.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Graeme Gerrard wrote:
>
> Why not use the term function to refer to ...er... the function calls in
> the Csound orch and a generic term like statements to refer to everything
> else?
Well, yes, that is what they are, for a programmer's point of view, but
a Csound programmer could also write a mathematical function as part of
an instrument, so I don't think that will eliminate confusion.
The other classic term for a Csound opcode is 'Unit Generator', which is
explicit and unambiguous. Unfortunately, it is a bit of a mouthful, and
'UG' is little better.
Csound has been compared by some to a species of assembly language = the
mnemonic representation of the raw low-level instructions a processor
uses, and the 'opcode' term really arises from that analogy.
On the other hand, many of the instructions in a score file are really
directives to the score preprocessor (to reinterpret start times,
recalculate times with respect to tempo changes, and so on), so neither
'opcode' nor 'function' would be appropriate here - though the latter
does legitimately apply to GEN functions, of course.
My vote is to keep 'opcode' for the orchestra, and to refer as we do to
'GEN functions', 'score statement' or 'score directive' for preprocessor
instructions 't', 's', 'a' etc, and 'event' specially for 'i'
statements. The term 'event' is explicitly used in Cscore, for example,
for almost all the functions which write text to a score file. The only
problem with 'statement' is that it is so general that it covers
everything and distinguishes nothing.
This should minimize confusion for those new to Csound, and especially
those without a background in programming. Those active in other
disciplines will know that some of these terms can mean other things,
but hopefully that will not bother them at all!
Richard Dobson
|