seriously, the fact that ideas and designs get hammered out on this list and that doepfer actually listen to users needs and builds a fair prortion of what we discuss is great. Part of loving modulars is the playing and the sound, but part is the planning, thinking, design... its great that we can be involved in this aspect too

BTW I have no real idea what they are talking about either!

Richard

----- Original Message -----
From: David Salter
To: Doepfer_a100@yahoogroups.com
Sent: Friday, March 07, 2008 3:32 PM
Subject: RE: 1 Re: granular processor & generato


D&G,

How about you guys getting together, producing a spec and building it so the rest of can enjoy the pleasures of granular synthesis in a modular :o)



David Salter
Senior Consultant
PSG

Reuters Messaging: david.salter.reuters.com@...
(t) +44 (0)20 7542 2402 | (m) 07990562402 | (f) 52699

Get the latest news at Reuters.com < http://www.reuters.com/ >

________________________________

From: Doepfer_a100@yahoogroups.com [mailto: Doepfer_a100@yahoogroups.com ] On Behalf Of Denis Gökdag
Sent: 07 March 2008 14:11
To: Doepfer_a100@yahoogroups.com
Subject: Re: 1 Re: granular processor & generato

>
> grains are not fixed samples, they are bits of samples put togheter or
> more correctly: a long sample is smashed into smaller samples
> (grains).
>
> grains parameters (position, pitch, lenght, density and dynamics)
> should
> be controllable independently from those of the main sample (loop
> points,
> pich/speed, direction...)

well i do not see where this is any different from what i wrote,
sorry if i made my points in a too involved or technical way; i've
been thinking about making a grain module for quite a while but so
far have been lacking the time and infrastructure to do, hence the
dsp-nerd-style ;-)
it i will use the term "source file" instead of "sample" from now
on to make clearer what i am saying. there are two main differences
between what you wrote and what i wrote:

a) you introduce the idea of selecting between multiple "source
files" *per voice*, while i was suggesting using one source file per
voice. your approach would be more "intuitively shaping semi-random
results", while mine would be more "constructivist". i do like the
idea of selecting a source file per CV, but it could be done by
switching/fading between the individual outputs of the voices with an
a152 or 144/135 combo for example....lowering the strain on the DSP
and giving more acces to what happens with every single grain.

b) you're more into "meta attributes", like "density" and
"dynamics" (which are not clearly defined, and could technically be
interpreted as "average # of grains started per time unit"/"average
amount of grains overlapping at any given time" and "amplitude
envelope within a grain"/"time varying amplitude scaling of whole
grains".....so we're basically talking about statistics and sequencer-
like terms here), i'm more into "discrete control" and leaving as
many functions outside the module as possible, again lowering the
workload on the DSP and giving access to every single grain. call me
a control freak but i much prefer to be able to process every single
grain independently in my a100 and leave the random/statistic
distribution stuff to other dedicated modules :-)

I may be wrong, but i believe it is important to leave the processor
load as low as possible if you want to both have realtime control of
all parameters at audio rate (where it maakes sense) *and* a good
audio quality. In the module i proposed, we're already lloking at the
following operations per grain:

- evaluate all A/D inputs and write their values to memory (to have
the data needed for all following operations)
- read from memory location in source file specified by input parameters
- perform real-time interpolating sample rate conversion (for the
transposition)
- create from input parameters and read from two look-up tables for
the fade curves
- multiply sample values with that data for the fades
- possibly crossfade into next grain (which means that all the above
operations will have to be executed *before* the next grain arrives,
which might be 1/samplerate seconds later only...AND for the
following grain as well.)
- write audio to D/A buffer, write data to control output buffers.

I think this already is quite a lot of work for a DSP, especially if
you take into account that the sample rate would probably have to be
at least 88.2khz or higher to avoid aliasing when performing audio-
rate FM on the grains, as the sidebands introduced will easily go
above the nyquist frequency on most material. And you probably don't
want such a module to have a latency of more than 10ms (and even that
would be a lot for a module in an analog setup).
>
> - a cv lag processor for the position pointer would allow to smooth
> the
> transition of granulation travelling thru the long sample
simply use a lag processor before the cv input. you don't want to
switch position while a grain is playing, as that either introduces
signal discontinuities aka clicks'npops, OR requires a lot of
interpolation going on all the time.
>
> - a clock/trig input would control the density of grains
>
> - a gate input would trigger the playback of the grains
these two exclude each other. you *either* have a statistical
distribution aka "density" (which is more or less random,
controllable from a fixed rate to noise sampled at a clock rate
specified by "density") OR you trigger an individual grain at a
specified point in time. the only way to mix these is to force a
grain on grain trigger, overriding the automatic triggering set by
the "density" parameter.....but you could simply switch between a
controlled trigger source and digital noise (a117) before the trigger
input.
also no *gate" is required in the setting you describe, just a
*trigger* (as the length of the grain is defined by its own parameter)

>
> - a cv input to control grains pitch
>
> - a cv input to control main sample's pitch
These both affect the same parameter and thus one is redundant.
>
> - a cv input for atack time of the grains
>
> - a cv input for the release time of the grains
>
> - a cv feedback would allow to feed the grains back to themselves
What do you want this to do Overwrite the source file with the
output signal Or just repeat a grain The latter is what the looped-
mode in my suggestion would do, the other would basically pose the
question to which location in the source you want to write....or
wether you want a grain *processor* (which would be about writing to
and reading from the same memory).

>
> - a cv delay time would allow to delay the signal for grain's feedback
Again, this mixes up a processor and a generator.....there is no need
for a delay parameter as you have full control of when a grain is
started and from which part of the file it is being "grabbed"....and
writing to the memory that is being read from is more of a grain
*processor" application. Echoes on the grains could be done with an
external delay module with greater flexibility.

ahw, got awfully dsp-nerdy again ;-)

l8a,
d

This email was sent to you by Reuters, the global news and information company.
To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of Reuters Limited.

Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company.
Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom
Registered No: 3296375
Registered in England and Wales

[Non-text portions of this message have been removed]





--
I am using the free version of SPAMfighter for private users.
It has removed 378 spam emails to date.
Paying users do not have this message in their emails.
Get the free SPAMfighter here: http://www.spamfighter.com/len


[Non-text portions of this message have been removed]