Doepfer

-by "density" i mean "distance between grains", which could go from 
almost total overlap of the grains when a high frecuency clock is 
used with long grains. 

when using a lower frecuency clock (lfo range) then gaps between the 
grains could appear if the frecuency of the clock is lower 
than the lenght of the grain. 

-by saying "dynamics" i simply mean "changes of volume in time" of 
each grain (that is the vca+envelope of each grain).

im not very sure that having so much control of evey single grain 
would be so much usefull. i think more of grains as being controlable 
all togheter, apliyng the polyfonic envelope to all of them at the 
same time from inside the dsp but controling the general atack and 
release from cv.


i'm a bit confused about the "voice" term you use:

i understand a "granular generator" as being a "granular processor" 
intimatelly associated to a sample player or "source file" as you 
call it. 

being able to select diferent files for that "source file" doesn't 
mean having several voices. it's allways the same single voice but 
having a diferent basic sound.

the grains are "riden" in realtime from the basic "source file" at 
the point of a "moving cursor" (sort of). (a totally agree that an 
external lag processor could be used if the "cursor" is controlable 
via external cv)

the audio signal "contained" in a grain is constantly changing 
depending on where of the "source file" the grain is being taken and 
depending on how much feedback+delay is aplied to the grains.

only when a "freeze" function is used the grain's audio content is 
totally stabilized.

it makes absolute sense to be able to refeed the grains with their 
output signal with some possible delay so timbre can be alterated in 
many ways. if pitch pitch changes are aplied to the grains or to the 
main "source file" many great sounds can be obtained (from pitch 
shifts to vapourous sounds, time streching, reverbs or infinite kinds 
of digital glitch effects)

more later...













--- In Doepfer_a100@yahoogroups.com, Denis Gökdag <q-art@...> wrote:
>
> >
> > 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
>