"High-resolution audio (float samples at 96 KHz, say), which is now
standard in professional audio, covers the full range of human
perception, so is no longer at a loss compared to acoustical
instruments. If you have good enough speakers"--- Yes.

And HiRes is more than just 24-Bits at 96kHz/192kHz and 2.8224MHz 
(for streaming across the net/web). It gets into a wider range of 
aspects of recording, processing, storage and playback. Michael is
essentially correct. Check out or google Audio Engineering Society's 
31st International Conference on High Resolution Audio, 25-27 June
2007, London in the UK. Very educational.

-Partev



=====================================================================================



--- michael.gogins@gmail.com wrote:

From: Michael Gogins 
To: csound@lists.bath.ac.uk
Subject: [Csnd] Re: Re: ease (was Re: Re: Re: Re: Re: Re: [OT] Human speech is music to out ears)
Date: Thu, 10 Dec 2009 09:30:11 -0500

In my view, there is much to do -- very much to do.

To begin with, computer music sounds are not comparable to
instrumental music sounds. Generally, frankly, they are not as good.
This is not due to lack of potential, which is far greater for the
computer, but rather to lack of (a) understanding and (b) traditional
evolution towards quality.

Next, without quality sounds, quality performance is (a) less
rewarding, and (b) harder to improve through practice.

However, I believe the future is very rosy.

CD-quality audio covers a subset of human perception - a large subset,
but with less than the full audible dynamic range and frequency
response. Using this level of quality means that the sheer precision
of the sound is inherently inferior to what you get off a fiddle,
piano, or horn on stage. This is where computer music has been stuck
until very recently.

High-resolution audio (float samples at 96 KHz, say), which is now
standard in professional audio, covers the full range of human
perception, so is no longer at a loss compared to acoustical
instruments. If you have good enough speakers.

Synthesis algorithms continue to evolve. They evolve faster than the
acoustical instruments have evolved. Ergo, they will equal or surpass
the synthesis beauty of acoustical instruments in the future, probably
the near future.

Robotics and human user interface design principles also are
continuing to evolve and afford the possibility of musical performance
interfaces that exploit the full speed, precision and number of
degrees of freedom afforded by trained human performers (which, as I
am sure we all understand, is phenomenally beyond the capacity of the
most advanced robots today).

Indeed, I expect new interfaces to surpass acoustical instruments in
exploiting the potential of the body for expression. We can exploit
not only pressure and impact, but also orientation, speed of motion,
wireless sensing, the whole body, you name it.

Again, these performance interfaces are evolving rapidly.

When the "musical payoff" of the combination of synthesis beauty,
acoustical precision, and (potential) performance precision and
bandwidth hits a "sweet spot," performers will have an incentive to
practice. Not before. Where new musical possibilities are afforded,
for some performers these spots are already being exploited, e.g. Pat
Metheny and the MIDI guitar. More of these spots will appear -- at
least, in potential.

I would advise designers of computer performance system to view
synthesis beauty and performance interfaces as unified systems, and
not to work on one side while neglecting the other side. Otherwise,
the sweetness of the work will not be heard and nobody will feel
motivated to practice enough to get the music out of the system.

Regards,
Mike

On 12/10/09, DavidW  wrote:
>
> On 10/12/2009, at 11:20 PM, Victor Lazzarini wrote:
>
>> That brings us to an interesting question: Need computer music
>> instruments (software or hardware) be 'easy to play'? This is
>> something I have always asked myself. Often we hear about how
>> something is either hard or easy, and whether in people's opinions
>> this makes it good or bad.
>>
>> In the case of traditional music instruments you don't seem to see
>> the same things. OK, players can complain some music is hard to
>> play, students complain that their instrument is difficult to
>> master, etc. But you don't see people going to redesign a violin to
>> make it easier to play; or attempts to do something like this seemed
>> to have taken away so much of the expressive possibilities that they
>> are disregarded as serious.
>>
> My experience with acoustic instruments, also backed-up by far better
> players than I, is that good instruments are harder to play than el-
> cheapo ones because they are more responsive, had a greater tonal
> range etc; these characteristics make them difficult for a beginner to
> play, not less.
> So the issue fro me is not ease of play, it is a sort of ratio of
> potentiality / skill. As skill develops software potentiality can be
> increased for more expressive power.
> What I don't find interesting, except in a perverse party-trick kind
> of way,  is a piece of software written and locked off by an anonymous
> 3rd party that generates a "composition" for you on the click of
> mouse. Or, at the other extreme, the sort of software that makes tasks
> harder than they should be, given the required level of skill;
> requiring dogged determination because of the way the SW forces you to
> deal with it.
>
>> This links to another question: should we not be regarding 'computer
>> music' as a field of study and development that is every bit as
>> complex and with long-term-development goals as standard musical
>> instruction?
>>
> Do you mean the standard music performance instruction? If so, I'm
> sure there's as much work involved - probably more - but it is
> different class of work - very little concerned with learning through
> embodied memory, for example.
>
>> Victor
>>
>>
>> On 10 Dec 2009, at 12:06, Stéphane Rollandin wrote:
>>
>>> same here. by ease, I meant practicability. some concepts can
>>> really be played with only when the software supports them
>>> comprehensively, else it gets very tedious. we (as composers and
>>> software developer) have to reify the lower structural aspects of
>>> our composition in order to use them effectively; and while these
>>> are lower in the view of the composition, they are very high-level
>>> in terms of software engineering.
>>
>>
> Yes, I think that's what I was meaning above re brute force.
>
> David
> ________________________________________________
> Dr David Worrall.
> - Experimental Polymedia:	  worrall.avatar.com.au
> - Sonification: www.sonifiction.com.au
> - Education for Financial Independence: www.mindthemarkets.com.au
>
>
>
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



_____________________________________________________________
Netscape.  Just the Net You Need.
Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 21/12/2009, at 11:19 PM, peiman khosravi wrote:

> To begin with, computer music sounds are not comparable to
> instrumental music sounds. Generally, frankly, they are not as good.
> This is not due to lack of potential, which is far greater for the
> computer, but rather to lack of (a) understanding and (b) traditional
> evolution towards quality.
>
and as pointed out both by me and emphasised by Mike re interfaces,  
and in different words:

(c) sounds in the real world are not synthesised, they occur as the  
result of interaction between physical objects. Such interaction  
involves the transduction of kinetic energy. Music is not usually just  
the arbitrary  stringing together sounds; it involves human-initiated  
transduction, the ongoing nature of which involves complex impedance  
etc control and feedback processes.  With respect to physical  
modelling synthesis, this implies that musical action (playing) i.e.  
the ongoing imparting of energy to resonators, is at least as complex  
as the dynamic vibrational structure of the resonators themselves. (I  
would argue it is more complex). By way of illustration, consider how  
much less convincing are the computer syntheses of sounds  
traditionally under continuous human control (such as those of bowed  
strings) than those of (not quite instantaneously) activated isolated  
sounds, such a the striking of a drums.


David
________________________________________________
Dr David Worrall.
- Experimental Polymedia:	  worrall.avatar.com.au
- Sonification: www.sonifiction.com.au
- Education for Financial Independence: www.mindthemarkets.com.au








Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

cameron bobro  wrote:
> Correct me someone if I'm way off here- if Brownian noise
> is integrated white noise, and given a presumably good
> white noise in Csound, why not just integrate white noise
> to get "brown"(red)? 

"Integrated white noise" is a high falutin' way of putting
it.  What it means is that each sample is a random amount
above or below the one before.  And yes, that's a good way
of generating Brownian noise with only a marginally good
random number generator.  I don't know where the thread
came from to know what other method the "just" is an
alternative to.

> This is what I do simply because it sounds very nice and
> organic. But is it accurate Brownian noise? And if this
> is more or less accurate, wouldn't taking the RMS of this
> and the white noise give a "pinkish"? This also sounds
> good. 

Random-walk noise is Brownian noise is a 1/f^2 spectrum.
Adding it to white noise (a flat spectrum) will not give
you 1/f noise (pink noise).  It'll be 1/f^2 + c for
your chosen value of "c".  You can call it "pinkish" if you
want.  It isn't what the pinkish opcode does.

> Both these colors are strikingly reminiscent of noise
> sources I've heard from analog synths (the brownish my
> old Vermona, the pinkish an old ARP), I'm just wondering
> how (in)accurate the methods really are. 

Dunno about that.  I had (maybe still have somewhere) some
Fortran code to produce colored noise by mid-point
perturbation.  I found the redder-than-pink noises sounded
good, some of them like breath noise or vinyl crackle.  But
I'm pretty sure that some of what I heard was artifacts of
a cheap sound card and speakers because I was generating
stupidly low frequencies.

Pink noise is harsh. It reminded me of television static
noise, from the days before sets blocked that out.

The most straightforward way of experimenting with Csound
would be to start with white noise and filter it.  If you
don't get a correct power spectrum it doesn't really
matter.  If you decide it *does* matter, try re-writing the
"pinkish" opcode, because I don't think there's anything
special about 1/f that makes it easy to produce.  Perhaps
that's where the discussion started.


                                      Graham


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

cameron bobro  wrote:

> Well I don't know if is a high falutin' expression or
> not, it is a perfectly normal description AFAIK. And I
> think it is a good way of describing Brownian noise
> because it suggests that purple noise is going to be
> white noise differentiated- which it is.  There was no
> previous discussion, I was referring to Csound noise
> articles in  general- I found the
> integrating/differentiating methods just by tinkering,
> and googling afterwards confirmed that it does what I
> think it does: I just wasn't sure about the accuracy.
> And, I can only judge so far using Adobe Audition
> spectral analysis. 

There was a "Re" in the subject line.  That's what made it
look like there was a previous discussion.

Note that there are different kinds of white, and therefore
Brownian, noise.  White noise is, of course, a list of
uncorrelated random numbers.  But they can have different
distributions, like flat or Gaussian.  The spectrum is
always the same, so they should sound the same.  If you use
them to generate Brownian noise, it should work the same
way.

> >Random-walk noise is Brownian noise is a 1/f^2 spectrum.
>  
> Obviously I know that- but "1/f^2" really needs a
> footnote, because if we talk about, say, a 1/f sprectrum
> of a periodic waveform, we just need a single complete
> waveform to verify this. When it comes to noise, a brief
> burst may give a very misleading picture of how the noise
> is weighted over a period of time. 
> Integrating white noise in Csound, I get a brown (red)
> that is consistently a tad dark (over seconds to
> minutes)- more toward -7dB per octave.

I've seen plenty of references that say Brownian noise is
1/f^2.  You'll have to check exactly what they're measuring
if you see a discrepancy -- there's power, energy, and
autocorrelation for example.  I can't find a proof and I
don't remember one.  Maybe somebody can say whether it's
only an approximate relationship or this Adobe Audition is
inaccurate.

Yes, a brief burst may give a misleading picture.  So don't
do that.

Are you looking at looping noise to give waveforms then?  I
found that was interesting when I was playing with
fractional noise.

> >Adding it to white noise (a flat spectrum) will not give
> >you 1/f noise (pink noise).  
>  
> Simply averaging the white and the integrated white, I
> get something between pink and red, at about - 4-5dB down
> an octave. 

You'll get a kind of noise which you may like but doesn't
follow a power law and so isn't pink noise.  Whether you'd
prefer noises that do follow power laws I can't say --
you'd have to try.  Unfortunately they aren't that easy to
generate.

> >Dunno about that.  I had (maybe still have somewhere)
> >some Fortran code to produce colored noise by mid-point
> >perturbation.  I found the redder-than-pink noises
> >sounded good, some of them like breath noise or vinyl
> >crackle.  But I'm pretty sure that some of what I heard
> >was artifacts of a cheap sound card and speakers because
> >I was generating stupidly low frequencies.
>  
> Yeah I would think that vinyl crackle would be artifacts
> of some kind, as reddish-pink and red are consistently
> pleasant sounding as far as I've ever heard.

The noise I got was pleasant sounding.  I think the
artifacts came up when I tried to push it beyond Brownian
noise, to infra-red noise if you like.

> >Pink noise is harsh. It reminded me of television static
> >noise, from the days before sets blocked that out.
>  
> The darker pinkish I get is quite nice, maybe it's simply
> dark enough to avoid that harshness- or maybe there is
> a harshness that comes with an extremely consistenly
> weighted noise, a relentless feeling to it?

Yes, I think the latter.  Pink noise has equal power in all
octaves, so it sounds like it has equal power across the
spectrum.  Perceptually, it's white.  So-called white noise
has more high frequencies, and that isn't pleasant either.
Brownian noise has more low frequencies, and that is
better, but it's a bit extreme.  So you can use a
different power law, or mix in a bit more pink.

> Well I've done whole concerts of filtering white noise,
> LOL. At any rate, some more noise opcodes would be great
> of course!

Unfortunately, I checked the code for "pinkish" and there
isn't an easy way to change either method to follow a
different power law.  They're both efficient algorithms,
and specialized.

This site has a link to C code that could probably be
adapted:

http://local.wasp.uwa.edu.au/~pbourke/fractals/noise/

Mid point displacement is also interesting.  It's very
briefly described here:

http://www.tursiops.cc/fm/#noises

The point is, the amount you perturb the mid point gets
smaller each time you recurse.  If all perturbations are the
same size, you get pink noise.  If they're all zero, you
get a straight line.  If each perturbation is half as much
as the previous level, I think that's Brownian noise.
Something like that anyway.

It's not something that works as a noise generator because
it only interpolates.  But there are places where that
might be what you want, like a noisy version of "line".
The implementation's easy if recursion's supported.  I
don't think it is in Csound orchestra code :-(


                          Graham


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Looks good. Just to let you know, if you need constants such as pi,  
you can use $M_PI instead of 3.14. That will expand to float or double  
precision.

Victor

On 26 Dec 2009, at 11:09, Graham Breed wrote:

> Attached is the control rate fractional noise generator I
> was working on before.  Thank you Victor for the nudge on
> recursion because I was really stuck on that!
>
> I'll have a look at the UDO database.
>
>
>                         Graham
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Victor Lazzarini  wrote:
> Looks good. Just to let you know, if you need constants
> such as pi, you can use $M_PI instead of 3.14. That will
> expand to float or double precision.

Oh, sure.  The 3.14 is only there to be a number I
recognize in case the variable isn't over-written.  It's
redundant now.


                          Graham

> Victor
> 
> On 26 Dec 2009, at 11:09, Graham Breed wrote:
> 
> > Attached is the control rate fractional noise generator
> > I was working on before.  Thank you Victor for the
> > nudge on recursion because I was really stuck on that!
> >
> > I'll have a look at the UDO database.
> >
> >
> >                         Graham
> >
> > Send bugs reports to this list.
> > To unsubscribe, send email sympa@lists.bath.ac.uk with
> > body "unsubscribe csound"
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with
> body "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

cameron bobro  wrote:
> Great, thanks! I'll try it out as soon as I get the
> chance.

I've got it working much more efficiently now by only
taking one recursion path.  That stops the memory use
increasing exponentially and means you can set sr=kr to get
full spectrum noise.  I don't know about a local setksmps=1
and, this isn't the right way to do audio rate  noise, but
at least we can hear it the ugly way.

Incidentally, I have some things I forgot to mention at a
more pertinent part of the thread.  Flicker noise is
described as 1/f:

http://en.wikipedia.org/wiki/Flicker_noise

I remember this from my electronics lectures all those
years ago.  Maybe you already knew about it, but let's
bring it out into the open.  If you hear 1/f noise from an
electronic circuit that could be the origin.

We're all familiar with white noise:

http://en.wikipedia.org/wiki/Johnson-Nyquist_noise

I, at least, don't know of other fractional noises that
come up naturally.  If you hear something like Brownian
noise through a synth I'm guessing it's one of these other
noises passing through the filters.  If you want to
re-create it the best way is to duplicate the filter path
instead of looking at mathematically perfect spectra.

That said, the fractal lobby does have a lot to say about
how natural phenomena tend to be self similar across a
given range.  Perhaps mixing in a bit of fractional noise
will take the electronic edge off sounds.

                             Graham


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"