Doepfer

> yes that would be a very nice aproac to it.
> also:
> -every grain could even be externally trigered by an lfo or oscilator.
Yeah, that's basically what i meant. Let me focus on a grain playback  
module. It would get it's source files via USB, up to one file per  
voice, or possibly from the memory of a possible other grain module  
( like a realtime memory recorder....). One voice would have the  
following inputs/functions:

- trigger input to start playback of a grain.

- 3-way trigger-mode switch
--------mode 1:   starts a grain on every trigger; if a new trigger  
arrives while a grain is still running, the voice crossfades to the  
new grain
--------mode 2: starts a grain when a trigger is received UNLESS a  
grain is already being played back. the trigger signal is forwarded  
to a trigger output socket (which could be used to trigger a  
different voice)
--------mode 3: sampler mode, where the input expects a GATE rather  
than a trigger. rising gate will start a grain, which will continue  
playing looped while gate is high

---trigger thru socket which forwards either the trigger signal like  
a multiple (mode 1), routes non-played triggers thru (mode 2) or  
outputs a trigger whenever the loop "turns around" (mode 3)

--- "grain is playing" gate output: outputs a gate whenever a grain  
is being played, gate becomes low when the grain fade-out starts (so  
you wont get just a permanent high level in case of mode 1 and  
overlapping grains); this makes triggering envelopes etc for  
processing grains possible

- manual control and attenuated CV input for grain length:   these  
values will only be evaluated at grain start time

- mode switch for grain length
--------mode 1: absolute mode #1, where a CV of 5V results in a grain  
length of 500ms
--------mode 2: absolute mode #2, where 5V = 2.5
--------mode 3: relative mode, where 5V equals the length of the  
entire file in seconds

----grain length CV output, that outputs the current grain length as CV

- manual control and attenuated CV input for grain transposition;  
only evaluated at grain start

- attenuated CV input for grain pitch; evaluated in realtime at  
sample rate (for "pitch jitter" effetcs or envelope control of pitch  
variation during a grain etc)

---- pitch CV output, which is the transposition (in S/H form as used  
by the grain module) plus pitch CVs summed

- manual control and attenuated CV input for grain start location  
within file; only evaluated at grain start

- grain start location mode switch:
-------mode 1:  relative mode, where 5V = last sample word of file  
(in which case a grain would start at the beginning of the file); the  
manual start time control acts as an offset and has a range over the  
entire file
-------mode 2: absolute mode, where 5V = 1 second; manual control is  
offset as in mode 1
-------mode 3: stepped mode, where the CV input is quantised into 16  
or 32 steps, which step through the file in 16 or 32 equal steps  
(making beat-rearrangement possible etc); manual control is an offset  
for fine-tuning the virtual "1" of the file.

---grain start CV output, which outputs the starting position within  
the file of the current grain, where the last sample word of the file  
equals 5V, updated on grain start

--- current playback position CV output, which outputs the current  
position within a grain (!!) as a CV, where start of grain equals 0V  
and end of grain equals 5V....this is basically a rising ramp at the  
length of the current grain, or a sawtooth oscillator in case of  
looped playback. yummy!

- manual control for fade-in/out time of the grain from 0 to 50% of  
grain length value OR absolute from 0 to 20 ms dpending on the state  
of the

- fade mode switch as described above

--- fade envelope CV output, which outputs a rising ramp while grain  
fades in, falling ramp while grain fades out and 5V while grain is  
playing

- grain playback direction switch and gate input where 0V = forward  
and 5V = reverse. when in looped mode 5V means alternating forward- 
backward loop

- grain audio output



This would result in a total of 14 sockets, 9 pots and 4  
switches......so a 4-voice module would basically be around the size  
of an a-154 + a-155 combo.

Gotta forget about the 8-voice. Just get two or three of the 4-voice  
ones.

Yeah.


Oh and whoever builds this, get me a free one ;-)



l8a,
d

i think a grain generator should have a very diferent aproach than a grain
processor.

this is how i see a grain generator:


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


- a grain generator should be able to stock a series of more or less long
samples (stored into a usb memory or a SDcard or whatever)

- a cv select input would allow to choose the sample to be granulated

- a cv position pointer would allow to choose where from that sample the
grain is taken.

- a couple of cv start and end loop position pointers would allow the
whole sample to be put in loop (0v=start of the sample, 5v=end of the
sample)

- a cv lag processor for the position pointer would allow to smooth the
transition of granulation travelling thru the long sample

- a cv lenght would control how long is the grain lasting.

- a clock/trig input would control the density of grains

- a gate input would trigger the playback of the grains

- a cv input to control grains pitch

- a cv input to control main sample's pitch

- 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

- a cv delay time would allow to delay the signal for grain's feedback


more thoughts on this later


--- In Doepfer_a100@yahoogroups.com, Denis Gökdag <q-art@...> wrote:

>
> 
> > yes that would be a very nice aproac to it.
> > also:
> > -every grain could even be externally trigered by an lfo or oscilator.
> Yeah, that's basically what i meant. Let me focus on a grain playback  
> module. It would get it's source files via USB, up to one file per  
> voice, or possibly from the memory of a possible other grain module  
> ( like a realtime memory recorder....). One voice would have the  
> following inputs/functions:
> 
> - trigger input to start playback of a grain.
> 
> - 3-way trigger-mode switch
> --------mode 1:   starts a grain on every trigger; if a new trigger  
> arrives while a grain is still running, the voice crossfades to the  
> new grain
> --------mode 2: starts a grain when a trigger is received UNLESS a  
> grain is already being played back. the trigger signal is forwarded  
> to a trigger output socket (which could be used to trigger a  
> different voice)
> --------mode 3: sampler mode, where the input expects a GATE rather  
> than a trigger. rising gate will start a grain, which will continue  
> playing looped while gate is high
> 
> ---trigger thru socket which forwards either the trigger signal like  
> a multiple (mode 1), routes non-played triggers thru (mode 2) or  
> outputs a trigger whenever the loop "turns around" (mode 3)
> 
> --- "grain is playing" gate output: outputs a gate whenever a grain  
> is being played, gate becomes low when the grain fade-out starts (so  
> you wont get just a permanent high level in case of mode 1 and  
> overlapping grains); this makes triggering envelopes etc for  
> processing grains possible
> 
> - manual control and attenuated CV input for grain length:   these  
> values will only be evaluated at grain start time
> 
> - mode switch for grain length
> --------mode 1: absolute mode #1, where a CV of 5V results in a grain  
> length of 500ms
> --------mode 2: absolute mode #2, where 5V = 2.5
> --------mode 3: relative mode, where 5V equals the length of the  
> entire file in seconds
> 
> ----grain length CV output, that outputs the current grain length as CV
> 
> - manual control and attenuated CV input for grain transposition;  
> only evaluated at grain start
> 
> - attenuated CV input for grain pitch; evaluated in realtime at  
> sample rate (for "pitch jitter" effetcs or envelope control of pitch  
> variation during a grain etc)
> 
> ---- pitch CV output, which is the transposition (in S/H form as used  
> by the grain module) plus pitch CVs summed
> 
> - manual control and attenuated CV input for grain start location  
> within file; only evaluated at grain start
> 
> - grain start location mode switch:
> -------mode 1:  relative mode, where 5V = last sample word of file  
> (in which case a grain would start at the beginning of the file); the  
> manual start time control acts as an offset and has a range over the  
> entire file
> -------mode 2: absolute mode, where 5V = 1 second; manual control is  
> offset as in mode 1
> -------mode 3: stepped mode, where the CV input is quantised into 16  
> or 32 steps, which step through the file in 16 or 32 equal steps  
> (making beat-rearrangement possible etc); manual control is an offset  
> for fine-tuning the virtual "1" of the file.
> 
> ---grain start CV output, which outputs the starting position within  
> the file of the current grain, where the last sample word of the file  
> equals 5V, updated on grain start
> 
> --- current playback position CV output, which outputs the current  
> position within a grain (!!) as a CV, where start of grain equals 0V  
> and end of grain equals 5V....this is basically a rising ramp at the  
> length of the current grain, or a sawtooth oscillator in case of  
> looped playback. yummy!
> 
> - manual control for fade-in/out time of the grain from 0 to 50% of  
> grain length value OR absolute from 0 to 20 ms dpending on the state  
> of the
> 
> - fade mode switch as described above
> 
> --- fade envelope CV output, which outputs a rising ramp while grain  
> fades in, falling ramp while grain fades out and 5V while grain is  
> playing
> 
> - grain playback direction switch and gate input where 0V = forward  
> and 5V = reverse. when in looped mode 5V means alternating forward- 
> backward loop
> 
> - grain audio output
> 
> 
> 
> This would result in a total of 14 sockets, 9 pots and 4  
> switches......so a 4-voice module would basically be around the size  
> of an a-154 + a-155 combo.
> 
> Gotta forget about the 8-voice. Just get two or three of the 4-voice  
> ones.
> 
> Yeah.
> 
> 
> Oh and whoever builds this, get me a free one ;-)
> 
> 
> 
> l8a,
> d
>

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

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@reuters.net
(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: [Doepfer_a100] 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]

yes, indeed.
i have been lost in this detailed discussion and you
guys (D&G) seem to really dig deep...
so, a granular proccesor/generator module would be
great.    :-)
best regards,
Bakis.


--- David Salter <david.salter@reuters.com> wrote:

> 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@reuters.net
> (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: [Doepfer_a100] 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
> >
> 
=== message truncated ===


Bakis Sirros - Parallel Worlds / Interconnected / Memory Geist
[Doepfer_a100] group owner
http://www.parallel-worlds-music.com
http://www.myspace.com/parallelworldsmusic
http://www.myspace.com/interconnectedmusic
http://www.myspace.com/memorygeist
http://www.DiN.org.uk
http://www.musicamaximamagnetica.com
http://www.shimarecords.co.uk
http://www.rubber.gr
Athens-Greece


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

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: [Doepfer_a100] 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@reuters.net
  (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: [Doepfer_a100] 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]

I understand the process (if not all the technical stuff) as I use Metasynth on my Mac and the end results are amazing.
 
To be able to apply a similar - though in reality probably a cut down - process in real time with in a modular system would be wonderful.
 
david
 
 
 
David Salter
Senior Consultant
PSG 

Reuters Messaging: david.salter.reuters.com@reuters.net
(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 Richard Scott
Sent: 07 March 2008 15:39
To: Doepfer_a100@yahoogroups.com
Subject: Re: [Doepfer_a100] Re: granular processor & generato



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 <mailto:Doepfer_a100%40yahoogroups.com>  
Sent: Friday, March 07, 2008 3:32 PM
Subject: RE: [Doepfer_a100] 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@reuters.net <mailto:david.salter.reuters.com%40reuters.net> 
(t) +44 (0)20 7542 2402 | (m) 07990562402 | (f) 52699 

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

________________________________

From: Doepfer_a100@yahoogroups.com <mailto:Doepfer_a100%40yahoogroups.com>  [mailto:Doepfer_a100@yahoogroups.com <mailto:Doepfer_a100%40yahoogroups.com> ] On Behalf Of Denis Gökdag
Sent: 07 March 2008 14:11
To: Doepfer_a100@yahoogroups.com <mailto:Doepfer_a100%40yahoogroups.com> 
Subject: Re: [Doepfer_a100] 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 <http://www.spamfighter.com/len> 

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



 


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]

>
> To be able to apply a similar - though in reality probably a cut  
> down - process in real time with in a modular system would be  
> wonderful.
>

Not cut-down at all! Imagine taking the CV's for grain parameters  
from a vocoder analysis section, and using sequencers and VCOs for  
triggering/parameter automation....grains "synced" to an  
oscillator....etc etc....*grin*

Compared to Metasynth you'd get less grains simultaneously, and no 2D/ 
3D control.....but a ton more options.


d

I would be interested if anyone on this board had the capability to design and cost out this module.
 
It would be interesting to know if it's commercially viable to build.
 
David
 
David Salter
Senior Consultant
PSG 

Reuters Messaging: david.salter.reuters.com@reuters.net
(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 16:21
To: Doepfer_a100@yahoogroups.com
Subject: Re: [Doepfer_a100] Re: granular processor & generato



>
> To be able to apply a similar - though in reality probably a cut 
> down - process in real time with in a modular system would be 
> wonderful.
>

Not cut-down at all! Imagine taking the CV's for grain parameters 
from a vocoder analysis section, and using sequencers and VCOs for 
triggering/parameter automation....grains "synced" to an 
oscillator....etc etc....*grin*

Compared to Metasynth you'd get less grains simultaneously, and no 2D/ 
3D control.....but a ton more options.

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 totally agree with you, denis, that to leave as much external 
control as possible would not only lower the strain on the dsp but 
would also allow to experiment a lot with these controls.

but at the same time that implies the absolute need more modules to 
control even its most basic parameters.

that's maybe more simplicity versus verstility question...

i'm not sure about what i would prefer: to be able to do incredible 
things with a complex system involving many modules to do granulation 
or to have more "concentrated" kind of granular module needing much 
less external stuff so i can get more granulators in a smaller rack 
space for concerts.  

i'm very atracted on both ways...


for the details of our discussion please see my next message




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

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

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

well, lets just hope this nice discussion could serve to push a 
little bit of granulation into the physical electronics world and 
that doepfer (or any one else) would soon bring us some cv 
granulation solution of whatever kind, that being deterministic, 
heuristic, stochastic or whatever ic ...

it is quite amazing that with the long time granulation exists no one 
have ever made any comercially avaible module nor stomp box of any 
sort using this great sound technique without computers.

if any one knows about anything of the sort out there, please tell me!

by the way, to patch an output from reaktor must be a joke, heh?
if i had to use a computer then why would i need any external modular?

;)
best regards
gaspar




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

Gaspar,
 
Historically I think you'll find that manufacturers were content to replicate, improve and innovate in the analogue domain.
 
Only very recently have we seen digital electronics being used in modular systems.
 
However there is a commercial aspect that because of the need of decent DSP (which is expensive) to make real time processing viable and the number of potential buyers it may not be worth the development cost.
 
I for one would love a granular module but not if it cost 1000 Euros or even 500 Euros.
 
What is a realistic price point for buyers?
 
David
David Salter
Senior Consultant
PSG 

Reuters Messaging: david.salter.reuters.com@reuters.net
(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 gasp_uleg
Sent: 11 March 2008 15:55
To: Doepfer_a100@yahoogroups.com
Subject: [Doepfer_a100] Re: granular processor & generato



well, lets just hope this nice discussion could serve to push a 
little bit of granulation into the physical electronics world and 
that doepfer (or any one else) would soon bring us some cv 
granulation solution of whatever kind, that being deterministic, 
heuristic, stochastic or whatever ic ...

it is quite amazing that with the long time granulation exists no one 
have ever made any comercially avaible module nor stomp box of any 
sort using this great sound technique without computers.

if any one knows about anything of the sort out there, please tell me!

by the way, to patch an output from reaktor must be a joke, heh?
if i had to use a computer then why would i need any external modular?

;)
best regards
gaspar

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



 


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]

> by the way, to patch an output from reaktor must be a joke, heh?
> if i had to use a computer then why would i need any external modular?
>
hmmm, no, no joke...."the best of both worlds" is what i'd call it ;-)

i got a lot of great results from running reaktor through my modular  
and the other way around. also cool is metasynth through a modular.....

only thing that lacks is an easy way to get DC CV's into the computer  
for controlling parameters.


anyway, i'll go meet dieter tomorrow at the messe and i'll try to  
convince him to build us something grainy ;-)


###d

Korg's Kaosspad III uses granular processing as far as I know, but haven't
tried one yet.



On 3/11/08, gasp_uleg <uleg2@hotmail.com> wrote:
>
>   well, lets just hope this nice discussion could serve to push a
> little bit of granulation into the physical electronics world and
> that doepfer (or any one else) would soon bring us some cv
> granulation solution of whatever kind, that being deterministic,
> heuristic, stochastic or whatever ic ...
>
> it is quite amazing that with the long time granulation exists no one
> have ever made any comercially avaible module nor stomp box of any
> sort using this great sound technique without computers.
>
> if any one knows about anything of the sort out there, please tell me!
>
> by the way, to patch an output from reaktor must be a joke, heh?
> if i had to use a computer then why would i need any external modular?
>
> ;)
> best regards
> gaspar
>
> --- In Doepfer_a100@yahoogroups.com <Doepfer_a100%40yahoogroups.com>,
> Denis Gökdag <q-art@...> wrote:
> >
> > 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
> >
>
> 
>


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