Doepfer

>
> 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