Doepfer

one reply to both of your posts :-)

i can see your point about a "less access to individual grains, more  
complex results on a single (small) module" approach. generating a  
typical grain "cloud" would be a lot of modules and patching with my  
approach....but then what i do if i want the "cloud" effect i just  
patch an output from reaktor or an audio track containing such a  
texture into the a100. i agree that it would be a lot more  
comfortable to have this sort of capability in a module,  
though....ideally there would be both. but if there could only be one  
of the two, i'd opt for the "discrete access" one, as this allows for  
stuff you don't get from an external source.


On 07. Mar 2008, at 9:28 PM, gasp_uleg wrote:

> -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.
k, that's the way i'd use the term too. see my reply to the "voice"  
issue further down.

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

Well this is true for texture-type granular sounds, but if you want  
to go down the "sequence of extremely short grains" route,  
essentially building a highly complex, time-varying waveform rather  
than a dense soundscape, control of individual grain fade curves  
makes for a rather huge difference.



>
> 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.
basically a "grain" is the same as one voice of a sampler playing  
back a specific section of a larger sample ("source file"). If i.e. 2  
grains overlap, you technically need to play back two voices, or  
"streams". In more complex, "meta-style" grain generators like the  
reaktor grain cloud this fact is simply hidden, as this technical  
aspect is not of any interest by itself in the context of generating  
a "cloud", all you want to know there is how "dense" the result will  
be (in whichever way the module achieves this). But when you *build*  
such a module in hardware, it is, as every grain needs to be treated  
as a separate "entity" in memory anyway (thats just the way the  
method works).....so as you already have the grains available  
seperately you might as well make them have their individual outputs  
and individual parameters to better fit the pradigm of a modular  
analog synthesizer. I call this combination of parameter controls,  
one playback "stream" and a set of outputs a "voice". In my proposal  
there would be four of these "voices", effectively making it possible  
for four grains to overlap at any one time. This would make the  
"cloud" type application somewhat possible (though not very dense),  
while making lots of really cool resonation, electrification,  
glitching, noisy, scraping pulsed digital stuff possible :-)



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

Absolutely. Best example is CDPs "brassage(old)" for this kinda  
thing, or waveform software's "amber-x". Even reaktors grain cloud  
can select a different source file per grain triggering event. BUT  
the reason i recommend having one fixed sample/source file for each  
voice is quite simple: this way i can keep track (and thus control)  
of which source file is being used by which grain, as a eurorack  
module will not have a display telling me which file is currently  
being referenced by which voice. This is both of use on stage (or in  
any other "i gotta know my stuff"-performance situation) as well as  
it (ever so slightly) slightly reduces DSP-load (no switching between  
different address spaces in memory) and makes constructing specific  
results more straight-forward and manageable. And you can still  
reference a variety of source files by defining which voice plays at  
which time and possibly using more than one module for more than four  
source files simultaneously. But then tha's just me, i don't mind  
buying multiple modules, i even went and bought two vocoder core  
systems for midi-automated stereo filterbanks ;-)

In general it would be smart to keep a *realtime*, near-to-zero- 
latency granular processor as dumb (or "mechanical"/"close to  
hardware" )as possible, because every additional layer of software  
makes timing more and more inaccurate (or at least it steadily  
becomes more challenging to code the algorithm in such a way that the  
order of things is right) on financially viable DSP setups. If you'd  
want to do it perfect, you'd build it discreetly with counter-ICs for  
memory pointers and only supply these with offsets and reset values  
generated in higher level software as these values are only generated  
once per grain. You'd simply clock the playback and D/As off an on- 
board or external VC-clock (like in the BBD), skipping the common  
system clock/sample rate and hence avoiding aliasing when doing FM  
(as you'd do this at the clock, not in the grain module's memory).  
BUT this approach would basically draw tons of current and require a  
lot of ICs and thus a rather complex board layout etc, making it  
rather unaffordable and large ;-)


>
> 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.
correct except for that feedback+delay+"freeze"is typically not found  
in *generators* but in *processors*, because:


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

a *generator* takes grains from files, a *processor* takes grains  
from a writable memory, as in a delay module or pitch-shifter. While  
the memory content is static in case of a generator (and you'd want  
it to be to be able to take the "colour" of a *specific* source file  
and bring it in to your new sound), the memory content of a  
*processor* is dynamic....the latter could be triggered to record  
from an input (including a delayed and fed-back version of the  
processor's output) and would reference *this* when generating  
grains, instead of a file. A "freeze" function simply sets this  
memory to be un-writable, so it effectively turns into a static  
content as you would have hwen using a file. You wouldn't be able to  
have repeatable and clearly determined results with a *processor*,  
and you wouldn't have the organic uncertainty with the  
*generator*....hence the differentiation between the two, as they are  
used for quite different applications. One is deterministic/ 
constructivistic, one is heuristic.

I fully agree that delayed feedback is of great use in a *processor*.

In my suggested module the *processor*-behaviour could simply be  
implemented with a memory-writer add-on module (except for the  
feedback, which you would have to patch manually).....all this add-on  
would do is provide the generator module with sound that the mem- 
writer records, which the generator would use instead of a loaded  
file. so you'd swap the static file for a writable memory. in this  
case creating a "delay" is simply creating an offset between the  
writing pointer's and the reading pointer's position (which is  
exactly how a delay is implemented). "Freezing" would simply be  
achieved by blocking the "record" control (with an inverter and an  
AND gate, to be specific ;-) )

l8a,
d