|
> > P.S I think I like Wronsky's definition of music still best:
> > Music is intelligence embodied in sound.
>
>
> I do like this one very much - can you give me the reference?
Musical references can be found in his entire philosophical corpus;
try: Philosophie critique découverte par Kant --from 1803
or: Philosophie de l'infini --1814
Better still ( and a tome I would LOVE to have ) is the commentary written
by his pupil Camille Durutte; Technie harmonique, from 1876. This is, as
far as I know,
one of the first attempts to design a mathematics of music, that
incorporates
classical harmony, which does not fall in what I would call the Helmholtz
trap;
i.e. ascribing musical characteristics to nature --Hearing waterfalls in C
major
and what have you! Art is art, that is; artificial. Man made.
> However, it works less well in one unusual circumstance, where plants
have
> been observed to prefer certain types of music, by leaning towards, or
away
> from, the speakers. I also recall seeing a program which featured a farmer
> playing music to his cows (I think it was Mozart), who showed their
> appreciation by an increased milk yield. Truly we are living in an Age of
> wonders!
I have always been troubled by `observations' of this kind.
Antropomorphizing
responses from non-humans is tricky at best and most times totally
fallacious. Response to stimuli does not equal interpretation;
interpretation does
not equal a value judgement.
If I recall correctly, the choice of stimuli was between heavy metal and
classical chamber music. From a purely physical point., we are dealing with
two very different types of vibratory stimuli. With what I know now about
biological membranes, it might all be explained by pretty crude mechanisms
on the cellular level. And this does not even touch the topic of
interpretatio
Stemming from a family that has been breeding dairy cattle for more than
ten generations, I must break a lance for the cow as an underestimated pet.
Cows
are surprisingly sensitive and they LOVE human attention --Mechanized
agriculture
comes straight from the pit, as far as I am concerned. Soft noises tend to
attract them strongly. Silence in nature is almost always accompanied by a
state of alarm.
Just as loud noises. Metallica at 110 db SPL would probably have turned
the entire farm instantaneously into a buttermilk factory!!
Yours,
Hans Pelleboer
Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa01735;
14 Feb 98 19:21 GMT
Received: from mercury.bath.ac.uk by stork.maths.Bath.AC.UK id aa10707;
14 Feb 98 19:21 GMT
Received: (qmail 484 invoked from network); 14 Feb 1998 19:21:26 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
by mercury.bath.ac.uk with SMTP; 14 Feb 1998 19:21:26 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (TAA03792); Sat, 14 Feb 1998 19:09:08 GMT
Received: from hermes.ex.ac.uk by maths.ex.ac.uk; Sat, 14 Feb 98 19:08:50 GMT
Received: from root@[194.184.60.149] by hermes via ESMTP (TAA03739); Sat, 14 Feb 1998 19:08:40 GMT
Received: (from nicb@localhost)
by ax-nicb.axnet.it (8.8.8/8.8.8) id TAA29422;
Sat, 14 Feb 1998 19:17:01 +0100
Date: Sat, 14 Feb 1998 19:16:59 +0100 (MET)
From: Nicola Bernardini
Reply-To: Nicola Bernardini
To: Csound mailing list
Subject: csound parser (was Re: entry.c and dynamic linking)
In-Reply-To: <34E56DA7.1B819BC5@cableinet.co.uk>
Message-Id:
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
Dear csound list,
thank you for your kind feedback. I was very pleased that these ideas
sound interesting to people that are csound old-timers and that have
already contributed in many ways to the growth of csound. I will try
to reply below to individual questions, and then I'll make a proposal.
On Fri, 13 Feb 1998, Paul Winkler wrote:
[snip]
> interested in the results. I have to work pretty hard just to get csound
> instruments working, though-- no programming experience-- so that puts
> me out of the development team.
well, you could be part of the testing team (if such thing existed)...
On Sat, 14 Feb 1998, Richard Dobson wrote:
[snip]
> I too am interested in this idea, though I don't think the cross-platform
> issues should be under-estimated (different flavours of lex and yacc -this
> comment also applies to the dynamic library question), both in the coding,
> and in the matter of ongoing maintenance and development thereafter. It is,
> of course, an enormous task, as no doubt most, if not all, of the current
> Csound data structures and access routines might need to be recast to suit
> the parser. Just how incrementally could such change be made? What would
> be the minumun number of opcodes needed to excercise the parser?
1) I don't under-estimate different platforms, I am ready to discuss to
any depth how they should be handled (among other things, porting software
is what I do for a living...); besides, the different flavours of lex
and yacc is easy to handle: let's just use flex and bison which are good
and quite standard lex and yaccs. These are ported under any known platform
(even mac, I believe...), and even if they were'nt, the output of these
tools is plain c code: those who don't have lex and yacc won't be able
to make changes to the syntax and grammar of csound, but will still be
able to compile the parser with a standard C compiler
2) I don't think it is such an enormous task: I think that, for the sake of
making everything work, we should not *touch* even in the smallest detail
csound data structures (if needed, these can be enclosed in other data
structures); I think this is mandatory to be backward compatible. I think
the parser could and should access the entry data structure just as it is
(right after, we could implement a fast hash search of the entry array
to speed up things - but this can be postponed, and if somebody can help
there: I am not good at these things)
3) thus, we can very well include all the opcodes right away, because
we just look in the entry table, right?
>
> I can imagine that the creation of a reasonably self-contained parser might
> lead to a new range of Csound facilities - perhaps even a source-file
> debugger to step through an orc file?
very nice idea indeed. Now that is a fairly difficult thing to do, at least
for my abilities. But once somebody wrote something like that,
it would be very easy to make a separate utility (one of those -U things).
One thing that is certain is that error checking could be made to be
much better and informative. (It is also true that error checking is
one of the most difficult parsing activities: now that should not be
underestimated).
Another nice thing would be to use the parsers for visual display,
or to go to/from nice programs like Miller Puckette's PD.
>
> I would be interested, to the extent that my un-schooled knowledge permits,
> to contribute to some work on this; apart from anythig else, I am keen to
> learn to use flex and bison on a real project. The SAOL/MPEG-4 team at MIT:
> http://sound.media.mit.edu/~eds/mpeg4
> have included yacc and lex scripts in the source distribution for saol - it
> might be a useful model.
Actually, that was exactly what I had in mind: let's pick up the lex and
yacc files from saol as an inspiration and let's produce an initial csound
parser. I have already studied that code, and to tell you frankly, I
don't like it very much: I don't want to be presumptous, but I think we
should/could do much better and I'll try to demonstrate that. It is a
useful model, though, and we'll certainly make use of it.
Thanks, Mr. Dobson, for your words.
On Sat, 14 Feb 1998, Gabriel Maldonado wrote:
[snip]
> I think that all these are very good things, of course only if backward
> compatiblity with old orc/sco will be completely kept back.
of course: this is absolutely essential *BEFORE* writing any extension.
> I think that all these are very good things, of course only if backward
> compatiblity with old orc/sco will be completely kept back.
> BtW what are exactly lex, yacc, flex and bison? Do they work with all
> platforms and with all C-C++ compilers?
lex is a lexical analyzer generator, a finite-state automaton generator
which is able to produce c code that does lexical scanning on standard
input. Flex is the GNU public domain lex, available all over. yacc
is a grammar generator, and bison is its GNU counterpart. yacc too
produces c code, so as I said, these tools produce code that can
be compiled with standard c compilers. I believe the GNU extensions
would allow to englobe lexer and parser in C++ objects, a nifty feature
to have multiple parsers, and very useful for us in order to produce
different parsers for the orc and the sco files (I'll look into that).
These tools come out of the best intelligence products back in the seventies
in the creation of unix platforms (you know: Kernighan, Bentley, Aho,
Ullman, all these geniuses which were working at AT&T along with our
guru Max Mathews). If you don't know them, be ready to meet some
very very powerful tools. Besides, you might be able to find Kernighan
documentation on the net (the famous papers) and there is a very
good book on lex/yacc from O'Reilly (called "lex & yacc", what would you
know).
Ok: I think all these nice answers are a good enough stimulus to start
working. Let me tell you what I am going to do:
1) I will try to produce a testing parser for orcs (let's start from orcs,
if you agree) *as quickly as I can*. I'll try to include everything,
but I think it is mandatory now to be very very quick, otherwise
this thing will go stale... The testing parser will be a separate
application that just groks orchestras and if it works, it should never barf.
It should just report on standard output what it is reading on
standard input (that would be enough to understand wheter it works
or not).
2) All the interested people should compile and test the parser with
their orchestra and report any errors and bugs. What especially
worries me is error reporting: the parser should be tested against
anything: wrong syntaxes, random files, binary input, everything.
3) then we'll attack the score part (as a matter of fact, if somebody
would like to attack that in parallel, it's fine...).
To produce an intelligent parser for sco files, I need some informed
advice on whether it would be useful to run the sco parser on the sorted
sco file or on the original sco file: I believe the first option poses limits
on what could be the future types included in sco files (would it be
able to handle string constants for example, an interesting extension);
while the second option would imply re-building sort and extract
features, a useless task IMHO (if it's not broken, don't
fix it, an old programming adagio).
Sorry for the very long post.
I'll be right back with the goods
Nicola
------------------------------------------------------------------------
Nicola Bernardini
E-mail: nicb@axnet.it
Re graphics: A picture is worth 10K words -- but only those to describe
the picture. Hardly any sets of 10K words can be adequately described
with pictures.
Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa02008;
14 Feb 98 21:00 GMT
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa13345;
14 Feb 98 21:00 GMT
Received: (qmail 9285 invoked from network); 14 Feb 1998 21:00:25 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
by pat.bath.ac.uk with SMTP; 14 Feb 1998 21:00:25 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (UAA12115); Sat, 14 Feb 1998 20:49:22 GMT
Received: from hermes.ex.ac.uk by maths.ex.ac.uk; Sat, 14 Feb 98 20:49:05 GMT
Received: from dratajcz@TECHNOMANCER.MIT.EDU [18.238.0.90] by hermes via ESMTP (UAA15217); Sat, 14 Feb 1998 20:48:58 GMT
Received: (from dratajcz@localhost)
by technomancer.MIT.EDU (8.8.5/8.8.5) id PAA03355;
Sat, 14 Feb 1998 15:48:53 -0500
Message-Id: <199802142048.PAA03355@technomancer.MIT.EDU>
To: Nicola Bernardini
Cc: csound@maths.ex.ac.uk
Subject: Re: csound parser (was Re: entry.c and dynamic linking)
In-Reply-To: Your message of "Sat, 14 Feb 1998 19:16:59 +0100."
Date: Sat, 14 Feb 1998 15:48:51 EST
From: David Ratajczak
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
>
> 2) I don't think it is such an enormous task: I think that, for the sake of
> making everything work, we should not *touch* even in the smallest detail
> csound data structures (if needed, these can be enclosed in other data
> structures); I think this is mandatory to be backward compatible. I think
I agree that getting rid of the parsing code in csound in favor of a
more flexible bison/flex approach is a good idea. I also agree that
this can be done with very little change to the existing data
structures. However, I think that in the (near) future, it would be a
good idea to consider dramatic structural changes to csound.
Problems with current csound implementation:
1) It's organic code written by many people over a long period of
time. Little documentation is available to make things clearer.
2) It's written in a style conducive to saving memory and could
perhaps better utilize the speed of current processors if it paid less
attention to memory management.
3) It lacks extensibility. Adding opcodes seems prohibitively
esoteric, and the messy implementation is the major reason why it is
so difficult to extend the csound language itself (for instruments to
turn on other instruments, to include local state variables within
instruments, to support opcode arrays, etc.) It seems the creators of
the MPEG4 standard have thought this through. The orc/sco files I've
seen for SAOL/MPEG4 seems to have a sort of "csound++" flavor. I
especially like the ability to define new opcodes in the orc file.
However, they have made a number of design decisions that have made
realtime performance implausible.
4) It's written in C (ugh..) I am considering undertaking a total
rewrite in C++ that would alleviate many of the current problems. I'd
be interested to hear ideas from other people as far as object
hierarchy, etc.. A good rewrite *should* have future extensibility as
a primary goal.
> the parser could and should access the entry data structure just as it is
> (right after, we could implement a fast hash search of the entry array
> to speed up things - but this can be postponed, and if somebody can help
> there: I am not good at these things)
>
This is trivial to do with the builtin hashtable class in the libg++
library.
> > I think that all these are very good things, of course only if backward
> > compatiblity with old orc/sco will be completely kept back.
>
> of course: this is absolutely essential *BEFORE* writing any extension.
>
For the time being I would agree with this. In the future, if any
major changes are made to the csound language, it would be relatively
trivial to maintain backward compatibility simply by providing a
translator.
> 1) I will try to produce a testing parser for orcs (let's start from orcs,
> if you agree) *as quickly as I can*. I'll try to include everything,
> but I think it is mandatory now to be very very quick, otherwise
> this thing will go stale... The testing parser will be a separate
> application that just groks orchestras and if it works, it should never barf.
> It should just report on standard output what it is reading on
> standard input (that would be enough to understand wheter it works
> or not).
>
Just remember that people in the future may be building on whatever
code is written.
> produce an intelligent parser for sco files, I need some informed
> advice on whether it would be useful to run the sco parser on the
> sorted sco file or on the original sco file: I believe the first
> option poses limits
> on what could be the future types included in sco files (would it be
> able to handle string constants for example, an interesting extension);
> while the second option would imply re-building sort and extract
> features, a useless task IMHO (if it's not broken, don't
> fix it, an old programming adagio).
>
Unfortunately, right now csound reads the sorted sco file line by line
during actual processing. This would have to be changed before you
get fancy with pre-processing.
__________________________________________________________________________
David Ratajczak
Web: http://web.mit.edu/dratajcz/
E-mail: dratajcz@mit.edu
Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa02509;
15 Feb 98 3:07 GMT
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa27665;
15 Feb 98 3:07 GMT
Received: (qmail 18379 invoked from network); 15 Feb 1998 03:07:44 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
by pat.bath.ac.uk with SMTP; 15 Feb 1998 03:07:44 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (CAA25018); Sun, 15 Feb 1998 02:58:21 GMT
Received: from hermes.ex.ac.uk by maths.ex.ac.uk; Sun, 15 Feb 98 02:58:03 GMT
Received: from ella.mills.edu [144.91.3.20] by hermes via SMTP (CAA22445); Sun, 15 Feb 1998 02:57:55 GMT
Received: (qmail 15037 invoked by uid 1964); 14 Feb 1998 18:57:36 -0800
Date: Sat, 14 Feb 1998 18:57:36 -0800 (PST)
From: "Matt J. Ingalls"
To: David Ratajczak
Cc: Nicola Bernardini , csound@maths.ex.ac.uk
Subject: new csound/parser/SAOL/strings in sco
In-Reply-To: <199802142048.PAA03355@technomancer.MIT.EDU>
Message-Id:
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
seems like we had a similar thread a few months back...
ive sort of skimmed the recent posts, so i might have not caught
everything, but:
here are my thoughts and *personal* wishes for a "new" csound:
> > 2) I don't think it is such an enormous task: I think that, for the sake of
> > making everything work, we should not *touch* even in the smallest detail
> > csound data structures (if needed, these can be enclosed in other data
> > structures); I think this is mandatory to be backward compatible. I think
> good idea to consider dramatic structural changes to csound.
> rewrite in C++ that would alleviate many of the current problems. I'd
> be interested to hear ideas from other people as far as object
i would propose the exact opposite: start from the ground up by
rewriting the (at least basic) opcodes as a platform independant Shared
Library in C (if this is done right, will secure the longevity of the code
-
how much can an oscilator change? - plus open-ended for many types of
applications). then can write a synthesis engine that will make the
opcode calls - a csound orc/sco parser can sit on that.
yes having orc/sco backwards compatibility is essential,
but i usually want something else: there are
so many users of CSound that are programmers too, there
must be alot of you who share my experience: wanting to at times just use
CSound (or even something of a higher level - maybe a GUI) and some times
wanting to either temporarily drop down into C/C++ or just write your own
code that makes certain calls to CSound (so far
the only thing we can really do is write score generators and write our
own opcodes)
> the MPEG4 standard have thought this through. The orc/sco files
I've > seen for SAOL/MPEG4 seems to have a sort of "csound++" flavor. I
> However, they have made a number of design decisions that have made
> realtime performance implausible.
Can someone explain to me what is the *intent* of SAOL/MPEG4?? Is
it indeed a "new Csound"? i was thinking it was intended as sort of a
real-time java for sound? is SAOL designed to be a composer's tool or for
(commercial) developers? please explain..
>
> > on what could be the future types included in sco files (would it be
> > able to handle string constants for example, an interesting extension);
i actually just last night was looking into this (for existing
CSound) i was going to try something a bit simpler by making a GEN02-kind
of thing but with strings for values. (this is to have a lookup table for
a soundfile so i dont have to rename all my files to soundin.xx) anybody
ever do anything like this?
-matt
Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa02979;
15 Feb 98 11:30 GMT
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa13205;
15 Feb 98 11:30 GMT
Received: (qmail 27813 invoked from network); 15 Feb 1998 11:30:51 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
by pat.bath.ac.uk with SMTP; 15 Feb 1998 11:30:51 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (LAA09153); Sun, 15 Feb 1998 11:27:00 GMT
Received: from hermes.ex.ac.uk by maths.ex.ac.uk; Sun, 15 Feb 98 11:26:42 GMT
Received: from agora.stm.it [195.62.32.1] by hermes via ESMTP (LAA21139); Sun, 15 Feb 1998 11:26:35 GMT
Received: from default (ppp03-14.stm.it [195.62.37.142]) by agora.stm.it (8.8.8/8.8.5) with ESMTP id MAA19512 for ; Sun, 15 Feb 1998 12:26:38 +0100 (ITA)
Message-Id: <34E6D048.B9840873@agora.stm.it>
Date: Sun, 15 Feb 1998 12:23:52 +0100
From: Gabriel Maldonado
X-Mailer: Mozilla 4.0 [en] (Win95; I)
Mime-Version: 1.0
To: Csound Mailing List
Subject: Re: csound parser
X-Priority: 3 (Normal)
References: <199802142048.PAA03355@technomancer.MIT.EDU>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
I think that any Csound change should increase its portability and,
above all, its efficiency in terms of speed. So I'm not completely sure
that a total C++ port of Csound is the best idea. I think it is better
to keep the critical parts of code in C. Also, some time ago somebody
observed that C++ language is not a real standard, at least until now.
With respect of adding new features to the ORC language, I suggest the
following things:
1) the possibility to implement multi-arguments functions and
subroutines that can be written directly in the orc code with following
form:
;****CALLING A FUNCTION (named 'anyfunc1' in this example)
a1 oscili anyfunc1(a2,a3,a4) * kamp, anyfunc2(a3,a4,a5), 1
;**** BODY OF A FUNCTION
func anyfunc1(aparm1,kparm2,iparm3,kparm4)
avalue = aparm1+sqrt(parm2)
avalue2 oscili avalue, kparm2 ,iparm3
areturn avalue2 * kparm4
endfunc
;**** CALLING A SUB (named 'anysub' in this example)
aoutarg1, aoutarg2 anysub ainarg1,ainarg2, kinarg3
;**** BODY OF A SUB
sub anysub(aoutarg1,aoutarg2,ainarg1,kinarg2,inarg3)
aoutarg1 oscili 1,ainarg1,1
aoutarg2 oscili 1,kinarg2,1
aoutarg3 oscili 1,inarg3,1
endsub
The difference beetween functions and subs is that function can be
called from within an expression and allow only one output argument
implicitly sent to the expression context. Note that the opcodes
areturn, kreturn and ireturn will decide the type of return value of a
func.
Subs allow more output arguments but should be called in its own line of
code, they don't use 'areturn' 'kreturn' or 'ireturn'.
All functions and subs should be compiled as inline possibly storing the
result into temporary variables for keeping speed efficiecy.
2) the possibility of turning on and turnig off an instrument from
another instrument and/or to define its duration into the caller instr.
3) standard structured languages conditional flow of control statements:
if...elseif...else...endif,
switch...case...default..endswitch,
for...endfor,
while...wend,
do...while
(all operating at both i and k-rate)
4) semi-global variables, shared within several instances of the same
instr during the performance, but not within instrs of different number.
5) multi-dimensional tables and gen functions
6) multi-dimensional arrays which can be accessed from within an
expression:
;******EXAMPLE:
a1 = array[a2,a3] * 8 + koffset
obviously this will make tables redundant but they should be kept for
backward compatibility. Furthermore these arrays should be enabled for
both read and write operations.
7) more ideas......(from Csound community)
SCO language additions:
1) using symbolic constants as i and f p-fields
2) sending string values to the orchestra
3) macros containing a block of any number of notes of the same instr,
processed with arithmetic and logical operators by user calling
parameters
4) variables
5) functions and subroutines
6) arithmetic and logical operators
7) standard structured conditional and iterative statements
8) more ideas.....(from Csound community)
P.S. It would be very useful a documentation of data structure members
and functions used in Csound parser and engine. If anyone has explored
and learned them, is invited to share his knowledge with Csound
community. I will post my (very limited) part of comprehension in some
later message if you agree.
--
Gabriel Maldonado
mailto:g.maldonado@agora.stm.it
http://www.agora.stm.it/G.Maldonado/home2.htm
http://www.geocities.com/SiliconValley/Way/7041/home2.htm
Received: from stork.maths.bath.ac.uk by omphalos.maths.Bath.AC.UK id aa03067;
15 Feb 98 13:09 GMT
Received: from pat.bath.ac.uk by stork.maths.Bath.AC.UK id aa15781;
15 Feb 98 13:09 GMT
Received: (qmail 396 invoked from network); 15 Feb 1998 13:09:27 -0000
Received: from hermes.ex.ac.uk (HELO exeter.ac.uk) (144.173.6.14)
by pat.bath.ac.uk with SMTP; 15 Feb 1998 13:09:27 -0000
Received: from noether [144.173.8.10] by hermes via SMTP (NAA24909); Sun, 15 Feb 1998 13:06:40 GMT
Received: from hermes.ex.ac.uk by maths.ex.ac.uk; Sun, 15 Feb 98 13:06:23 GMT
Received: from mail.utexas.edu [128.83.126.1] by hermes via SMTP (NAA03436); Sun, 15 Feb 1998 13:06:17 GMT
Date: Sun, 15 Feb 1998 13:06:17 GMT
Message-Id: <199802151306.NAA03436@hermes>
Received: (qmail 28731 invoked by uid 0); 15 Feb 1998 13:06:17 -0000
Received: from dial-45-5.ots.utexas.edu (128.83.112.37)
by mail.utexas.edu with SMTP; 15 Feb 1998 13:06:17 -0000
X-Sender: r.pinkston@mail.utexas.edu
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: David Schuyeteneer
From: Russell Pinkston
Subject: Re: unwanted "line" sweepback
Cc: csound@maths.ex.ac.uk
Sender: owner-csound-outgoing@maths.ex.ac.uk
Precedence: bulk
>I try to pitchdown a loscil unit with a line opcode but it sweeps back
>pitching up !!
>I don't understand this because i clearly set the idur of the line to p3
>and not p3/2 or something...
>
>Please explain me this fellow Csounders...
>
>orc & sco are included below and the needed soundfile was 710kb, a little
>too much...so create
>a soundfile yourself of 363791 sampleframes at 16bit at 44100 Hz.
>
>
>David.
>
>*** ORC *********************
>*******************************
>sr = 44100
>kr = 441
>ksmps = 100
>nchnls = 1
>
>;---------------------------------------------------------------------------
>-------
>;
>; loscil test instrument.
>;
>;---------------------------------------------------------------------------
>-------
>
>instr 1
>
>
>khold oscil 50,0.3,2
>kvib randh 1,abs(khold)
>kdown line 1,p3,-5
This is the problem. line will output values that start at 1 and go to -5.
As soon as it goes below 0, it effectively starts up again. (A negative
frequency is the same as a positive one, but with an inversion of phase - in
other words, it sounds the same.) Your orchestra should work fine if you
replaced the line with:
kdown line 1, p3, .125 ;cause a 4 octave drop over p3 seconds.
----------------------------------
Russell F. Pinkston, D.M.A.
Associate Professor of Composition
Director, Electronic Music Studios
School of Music
The University of Texas at Austin
Austin, TX 78712
[512-471-0865]
|