RE: [microsound] pixels per minute?

[Eloy Anzola <eloy@xxxxxxxxxxxxx>]

Graham,

Your Sample to Pixel idea is probably very close.

A sample is to a digital sound file what a pixel is
to a digital image file, in that they are both (sample
and pixel) the smallest thing you can zoom into or edit.
They can't really be divided.

Also, higher resolutions will result in more pixels
or samples.

Silence and Transparancy are similar too: A silent
sample is present but it's amplitude is 0, a transparent
pixel is also present but it's opacity set to 0.

I wonder how much of this analogy is due to the way the
applications display and allow us to interact and work
with sound.

That is, is this purely perception?

Altough sound happens in time, most editing happens to
a static reprensentation of the sound. With which we
interact in the same basic manner than a digital image.

It could also be argued that a sound file is closer to
a movie file, than to a static image. Both sound and movie
happen in time.

One digital movie frame, contains many pixels and it's
corresponding sound many samples. A sample is more like a
very quick/short frame.

or whatever...,

Eloy
 -----
eloy@xxxxxxxxxxxxx
http://groovylab.com/



> -----Original Message-----
> From: Kassen [mailto:kassen@xxxxxxxxxxxxxx]
> Sent: Friday, December 10, 2004 1:10 PM
> To: microsound
> Subject: Re: [microsound] pixels per minute?
>
>
> graham miller wonders;
>
>
> > i know this may sound like a ridiculous question, but how
> many pixel per
> > minute of audio is processed in real time? i'm not talking visual
> > waveforms here, but rather 'pixels' of sound (as in the
> smallest measure
> > of computer detail in the visual realm).
>
> I think it´s perfectly valid to look at it that way but I
> also think it´s
> heavy context dependant. Many audio programs process audio in
> blocks of a
> set of samples (sample as in a single value) where each block
> will have the
> same values for controling signals. You could look as those
> blocks as pixels
> or as clusters of pixels, both are valid, I think, but the
> size of such a
> block will depend on the buffer of your soundcard or your
> program´s settings
> or.....
>
> It gets harder if if you chain up several operations in some
> modular system.
> It´s clear that everything that arives at the output was processed but
> suppose we have a chain that goes like; VCO, VCF, envelope,
> chorus (heresy
> on this list!). clearly everything that got out of the chorus
> was processed
> but you could argue that the filter and the envelope are
> processing just as
> many "pixels". Worse yet, some packages will use internal
> processing at a
> higher bit rate then the processed sample is. That would mean
> that arguably
> many more pixels are processed then will ever be heard. Also;
> what exactly
> is "one process"? a reverb might be seen as one process but
> your homebuild
> contraption that uses a reverb after a granulator might be
> "one process" to
> you.
>
> If we could agree on what standard to adhere to when talking
> about "pixels
> per second" it might be a interesting unit, for example to compare
> workstations and digital processors but practically speaking
> I think the
> only thing that realy matters is the percentage of cpu time
> (and perhaps
> memory) a certain operation or patch will cost on your tool of choice.
>
> I think it´s a interesting question to contemplate but i fear it won´t
> result in a very usefull standard of measurement.
>
> Kas.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: microsound-unsubscribe@xxxxxxxxxxxxx
> For additional commands, e-mail: microsound-help@xxxxxxxxxxxxx
> website: http://www.microsound.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: microsound-unsubscribe@xxxxxxxxxxxxx
For additional commands, e-mail: microsound-help@xxxxxxxxxxxxx
website: http://www.microsound.org